서비스업 ERP는 어디서부터 시작해야 할까: 제안·견적·계약·프로젝트·청구 흐름 체크리스트
서비스업 회사가 ERP 프로그램을 검토할 때 가장 먼저 부딪히는 질문은 “어떤 기능이 있나”입니다. 고객 관리, 견적서, 계약서, 프로젝트, 작업, 타임시트, 청구서, 수금, 권한 관리까지 기능 이름을 나열하면 필요한 것이 많아 보입니다.
하지만 실제 운영에서 더 중요한 질문은 따로 있습니다.
“우리 회사의 일이 어떤 순서로 흘러가고, 그 흐름이 어디서 끊기는가?”
개발대행, SI, 유지보수, 에이전시, 컨설팅, MSP처럼 사람의 작업과 프로젝트 수행이 매출로 이어지는 서비스업은 단순 재고 중심 ERP와 다릅니다. 계약 전에는 제안과 견적이 중요하고, 계약 후에는 프로젝트 수행과 투입 시간이 중요하며, 마지막에는 거래명세, 청구, 수금 상태가 정확히 이어져야 합니다.
이 글은 서비스업 ERP를 검토할 때 확인해야 할 흐름을 제안 -> 견적 -> 계약 -> 프로젝트/작업 -> 타임시트 -> 거래명세/청구 -> 수금 순서로 정리합니다. 예시는 DevScent 포트폴리오에 공개된 Devscent ERP의 멀티테넌트, 모듈형 권한, 서비스업 프리셋 방향을 기준으로 설명합니다. Devscent ERP는 현재 공개 자료 기준 고도화중인 SaaS / Multi-tenant ERP입니다.
기능 많은 ERP보다 업무 흐름이 먼저입니다
ERP를 고를 때 기능표만 비교하면 거의 모든 제품이 비슷해 보입니다. 고객 관리가 있는지, 견적서를 만들 수 있는지, 프로젝트 화면이 있는지, 청구서가 있는지 같은 항목은 체크하기 쉽습니다.
문제는 기능이 “있다”와 실제 업무가 “이어진다”는 전혀 다르다는 점입니다.
예를 들어 제안서가 별도 문서로 남고, 견적서는 엑셀로 만들고, 계약서는 PDF로 저장하고, 프로젝트 진행은 메신저에서 관리하고, 작업 시간은 담당자별 스프레드시트에 적는다면 ERP를 도입해도 핵심 병목은 그대로 남을 수 있습니다. 담당자는 같은 정보를 여러 번 입력하고, 관리자는 최신 상태를 매번 물어봐야 하며, 청구 시점에는 어떤 작업이 청구 대상인지 다시 확인해야 합니다.
서비스업 ERP는 기능 묶음이 아니라 업무 흐름을 기준으로 봐야 합니다. 최소한 아래 질문에 답할 수 있어야 합니다.
- 고객사가 등록되면 제안과 견적이 같은 흐름 안에서 이어지는가?
- 승인된 견적이 계약과 프로젝트 시작으로 자연스럽게 연결되는가?
- 프로젝트 아래 작업, 타임시트, 산출물, 티켓이 남는가?
- 작업 근거를 바탕으로 거래명세나 청구서를 만들 수 있는가?
- 청구 후 수금과 미수금 상태를 확인할 수 있는가?
- 역할과 권한에 따라 영업, PM, 회계, 실무자가 다른 화면을 볼 수 있는가?
1. 계약 전 흐름: 고객사, 제안, 견적
서비스업의 매출은 보통 고객사와의 대화에서 시작됩니다. 이 단계에서 필요한 것은 단순 연락처 목록이 아니라 고객사별 제안 이력과 견적 이력입니다.
먼저 고객사를 등록하고, 고객사별로 어떤 제안을 했는지 남겨야 합니다. 제안이 승인 가능한 단계로 올라오면 견적으로 전환합니다. 견적에는 범위, 금액, 조건, 기간, 포함 항목과 제외 항목이 정리되어야 합니다.
이 흐름이 끊기면 계약 직전에 문제가 생깁니다. 제안 당시 약속한 범위와 견적서의 범위가 달라지고, 담당자가 바뀌면 왜 그 금액이 나왔는지 설명하기 어려워집니다. 그래서 서비스업 ERP는 “견적서 작성 기능” 하나보다 “고객사 -> 제안 -> 견적” 흐름을 보존하는지가 중요합니다.
Devscent ERP의 서비스업 프리셋 문서도 고객사, 제안, 견적, 계약 순서를 권장 흐름으로 둡니다. 공개 포트폴리오에서는 Devscent ERP가 멀티테넌트 모듈형 SaaS ERP MVP를 위한 API, Web, AI 서비스 스캐폴드로 정리되어 있으며, 업종별 프리셋과 모듈형 권한 전략을 함께 다루는 방향이 공개되어 있습니다.
2. 계약 후 흐름: 계약, 프로젝트, 작업, 타임시트
서비스업 회사에서 계약은 끝이 아니라 수행의 시작입니다. 승인된 견적이 계약으로 이어지고, 계약을 기준으로 프로젝트가 시작되어야 합니다.
프로젝트가 시작되면 실제 운영은 더 잘게 나뉩니다. 프로젝트 아래 작업이 생기고, 담당자가 배정되고, 투입 시간이 기록되고, 고객 문의나 장애는 티켓으로 남습니다. 여기서 중요한 것은 “프로젝트 관리 화면이 있는가”가 아니라 계약, 작업, 시간, 이슈가 한 맥락에서 보이는가입니다.
작업과 타임시트가 따로 놀면 청구 단계에서 근거가 약해집니다. 어떤 작업이 완료되었는지, 어느 정도 시간이 들어갔는지, 유지보수 범위인지 추가 과금 대상인지 다시 확인해야 합니다. 반복되는 확인은 청구 지연과 미수금 관리 지연으로 이어집니다.
따라서 서비스업 ERP를 검토할 때는 프로젝트 화면에서 아래 항목을 확인해야 합니다.
- 계약 또는 견적과 프로젝트가 연결되는가?
- 프로젝트 아래 작업과 담당자를 관리할 수 있는가?
- 실제 투입 시간을 타임시트로 남길 수 있는가?
- 고객 문의, 장애, 유지보수 이슈를 티켓으로 연결할 수 있는가?
- PM, 회계 담당자, 실무자의 권한이 분리되는가?
3. 청구와 수금 흐름: 거래명세, 인보이스, 미수금
서비스업 ERP에서 가장 현실적인 효과는 청구와 수금 흐름에서 드러납니다. 매출은 계약서에 쓰인 순간이 아니라 청구하고 회수할 때 회사의 현금 흐름으로 이어집니다.
서비스업에서는 작업 근거를 기준으로 거래명세를 만들고, 확정된 거래명세를 인보이스로 발행한 뒤, 수금 내역을 반영하는 흐름이 필요합니다. 프로젝트가 길거나 단계별 검수가 있는 경우에는 청구 예정, 청구 완료, 일부 수금, 미수금 상태를 구분해서 봐야 합니다.
이 단계가 엑셀과 메신저에 흩어져 있으면 관리자는 세 가지 질문을 반복하게 됩니다.
- 이번 달 청구해야 할 프로젝트가 무엇인가?
- 이미 청구했지만 아직 회수되지 않은 금액은 무엇인가?
- 고객사가 문의했을 때 청구 근거를 바로 보여줄 수 있는가?
Devscent ERP의 서비스업 문서에서는 작업 근거를 기준으로 거래명세를 작성하고, 확정된 거래명세를 서비스 인보이스로 발행하며, 수금 내역을 서비스 수금 화면에 반영하는 순서를 권장합니다. 공개 자료 기준으로는 서비스업 운영 흐름이 계속 고도화되는 단계이므로, 도입 검토 시에는 실제 사용 범위와 필요한 세부 기능을 함께 확인하는 것이 좋습니다.
4. 테넌트, 권한, 모듈 설정도 운영 흐름의 일부입니다
소규모 회사라도 ERP에서는 권한 구조가 중요합니다. 대표나 운영 관리자는 전체 흐름을 보고 싶지만, 실무자는 본인 작업과 타임시트 중심으로 보면 됩니다. 회계 담당자는 청구와 수금, 거래명세를 중심으로 봐야 합니다.
멀티테넌트 SaaS ERP에서는 이 구조가 더 중요해집니다. 하나의 플랫폼 안에서도 고객사 또는 운영 조직별로 데이터가 분리되어야 하고, 테넌트별로 활성화된 모듈과 권한이 달라질 수 있어야 합니다.
Devscent ERP 공개 포트폴리오의 실제 화면 갤러리는 이 방향을 보여줍니다. 테넌트 운영 대시보드는 매출, 태스크, 최근 활동을 한 화면에서 확인하는 구조로 소개되어 있고, 모듈 네비게이션 셸은 서비스, 계약, 청구, 설정 모듈을 한 셸 안에서 이동하는 ERP 백오피스 구조로 설명됩니다. 권한/엔타이틀먼트 설정 화면은 테넌트별 기능 접근과 모듈 활성화 상태를 관리하는 화면으로 공개되어 있습니다.
이런 구조는 “모든 직원에게 같은 메뉴를 보여주는 ERP”보다 운영 현실에 가깝습니다. 서비스업 회사는 영업, 수행, 회계, 지원 업무가 서로 연결되어 있지만, 각 역할이 매일 보는 화면은 달라야 하기 때문입니다.
서비스업 ERP 도입 전 체크리스트
ERP 프로그램을 비교하기 전에 아래 체크리스트를 먼저 정리해보면 좋습니다.
- 고객사 정보는 어디에 있고, 제안 이력과 연결되어 있는가?
- 제안이 승인되면 견적으로 전환되는 흐름이 있는가?
- 승인된 견적이 계약과 프로젝트 시작으로 이어지는가?
- 프로젝트 아래 작업, 담당자, 일정, 투입 시간이 남는가?
- 고객 문의와 장애가 계약 또는 프로젝트와 연결되는가?
- 작업 근거를 기준으로 거래명세나 청구서를 만들 수 있는가?
- 수금 상태와 미수금 aging을 확인할 수 있는가?
- 영업, PM, 회계, 실무자, 지원 담당자의 권한이 분리되는가?
- 우리 업종에 맞는 메뉴와 대시보드로 시작할 수 있는가?
- 현재 제품 상태가 완성형인지, 고도화중인지, 도입 전에 확인해야 할 범위는 무엇인가?
이 질문에 답하지 않은 상태에서 ERP 기능표만 비교하면 도입 후에도 기존 엑셀과 메신저가 계속 남을 수 있습니다. 반대로 업무 흐름을 먼저 정리하면 필요한 기능과 나중에 붙여도 되는 기능이 분명해집니다.
Devscent ERP를 어떻게 보면 좋을까
Devscent ERP는 DevScent 포트폴리오에 SaaS / Multi-tenant 카테고리로 공개되어 있으며, 현재 상태는 고도화중입니다. 공개 설명 기준으로는 멀티테넌트 모듈형 SaaS ERP MVP를 위한 API, Web, AI 서비스 스캐폴드이며, NestJS, Next.js, Prisma 기반의 구조와 모듈형 권한, 업종 프리셋, 운영 스크립트 방향이 소개되어 있습니다.
즉, 이 글에서 Devscent ERP를 완성형 범용 ERP로 과장해 설명하지 않습니다. 대신 서비스업 ERP를 검토할 때 어떤 흐름을 봐야 하는지, 그리고 DevScent가 어떤 구조와 운영 관점으로 ERP를 고도화하고 있는지 보여주는 포트폴리오 사례로 보는 것이 정확합니다.
서비스업 운영 흐름을 ERP 관점에서 정리하고 싶다면 DevScent ERP 포트폴리오에서 공개 화면과 구조 설명을 먼저 확인해보세요. 구체적인 범위, 예산, 일정이 있다면 DevScent 견적 페이지에서 프로젝트 조건을 정리해 상담을 시작할 수 있습니다.
다음 단계
- Devscent ERP 포트폴리오 보기: https://devscent.com/portfolio.html?case=erp
- 프로젝트 견적 계산하기: https://devscent.com/estimate.html
- DevScent 서비스/가격 보기: https://devscent.com/pricing.html
- 다른 DevScent 글 보기: https://devscent.com/blog/