
목차
고객이 견적 요청서(RFQ)를 보내면 영업 흐름이 시작되고, 수주한 물량을 납품한 뒤 대금이 들어와 미수금이 0이 되면 끝납니다. 제조기업 한 곳이 적어 낸 업무 목록에서 이 흐름에 속한 업무는 6가지이고, 구매영업·설계·원가·재경 4개 부서가 나눠 적었습니다. 6가지 업무의 문서마다 필수 항목이 4개씩 정해져 있습니다.
제조 AI 운영체제 VEXPLOR를 만드는 웨이스가 제조기업 한 곳의 부서별 업무 목록을 흐름으로 다시 묶은 연재 「제조기업 업무 다시 정의하기」의 8편입니다. 이번 편은 고객 요청에서 수금까지를 시작 사건, 끝 산출물, 단계와 부서, 문서와 필수 항목, 사람의 판단, 끊기는 곳, AI 동작, 흐름 주인과 기록의 8가지로 정의합니다. 흐름 한가운데 있는 수주 확정에서 생산 흐름이 일을 넘겨받으므로, 넘겨주는 지점도 함께 적습니다.
영업 흐름은 견적 요청서로 시작해 입금 확인이나 실주 기록으로 끝납니다
시작 사건은 고객이 보낸 견적 요청서입니다. 요청서에는 고객사명, 요구 사양, 수량, 납기 요청일이 들어 있어야 합니다. 4가지 중 하나라도 비어 있으면 뒤의 설계와 원가가 일을 시작하지 못하므로, 요청서를 받으면 빈 항목부터 확인합니다.
끝 산출물은 2가지 가운데 하나입니다. 수주했다면 납품 뒤 대금이 들어와 그 거래처의 미수 금액이 0이 되는 것이고, 수주하지 못했다면 실주 사유가 기록으로 남는 것입니다. 실주도 끝으로 봅니다. 실패 사유와 경쟁사, 제출한 견적 금액이 남아야 다음 견적에서 다시 참고할 수 있기 때문입니다.
중간 산출물도 하나 있습니다. 수주 확정입니다. 수주 내역(고객사명·수주 금액·수주일·납기)이 확정되면, 고객 주문을 받아 생산 계획을 세우는 생산 흐름(4편)이 이 내역을 넘겨받아 시작합니다. 영업 흐름은 수주로 끝나지 않고, 생산과 출하가 끝나기를 기다렸다가 청구와 수금까지 챙깁니다.
견적 요청서는 구매영업·설계·원가·재경을 차례로 지나 입금으로 끝납니다
단계 | 부서 | 받는 문서 | 넘기는 문서 |
|---|---|---|---|
요청 접수 | 구매영업 | 견적 요청서 | 요청 번호 |
요구사양 분석 | 설계 | 고객 요구사양서 | 핵심 요건 목록 |
견적 원가 산정 | 원가 | 핵심 요건 목록 | 견적 원가 |
견적서 작성 | 구매영업 | 견적 원가·과거 견적서 | 견적서 |
수주 확정 | 구매영업 | 고객 발주 | 수주 내역 |
청구 | 재경 | 수주 내역·출하 기록 | 세금계산서 |
수금 | 재경 | 채권관리대장·거래처 메일 | 입금 확인 |
원가 되짚기 | 원가 | 견적서·실적 원가 | 차이 사유 |

구매영업이 요청서에 번호를 붙이면, 설계는 고객 요구사양서에서 반드시 지켜야 할 요건과 기준값(공차)을 뽑아 냅니다. 원가는 그 요건으로 견적 원가를 산정하고, 구매영업은 과거 견적서를 참고해 견적서를 만들어 고객에게 냅니다. 고객이 발주하면 수주 내역이 확정되고, 재경은 출하 뒤 세금계산서를 발행하고 입금을 확인합니다. 수주한 건은 생산이 끝난 뒤 원가가 견적 원가와 실적 원가를 비교해 차이 사유를 남깁니다.
이 가운데 요청 접수·견적 원가 산정·청구 3단계는 원본 목록에 업무로 적혀 있지 않습니다. 요청에 번호가 붙어야 뒤 부서가 일을 시작할 수 있고, 영업이 견적을 내려면 원가 산정이 있어야 하고 수금 전에는 청구가 있어야 하므로, 일반적인 제조기업 절차로 보강했습니다.
이 흐름의 문서는 고객 이름과 견적 값을 여러 번 다시 적습니다
원본 목록이 업무마다 적어 둔 문서와 필수 항목은 이렇습니다.
견적 요청서(RFQ)·과거 견적서 — 고객사명 · 요구 사양 · 수량 · 납기 요청일
고객 요구사양서 — 요구 항목 · 기준값(공차) · 적용 제품 · 발행일
견적서(원본 목록에 필수 항목이 적혀 있지 않아 일반 절차로 적음) — 품목 · 가격 · 날짜 · 조건
수주 내역·매출 데이터 — 고객사명 · 수주 금액 · 수주일 · 납기
실주 보고서 — 고객사명 · 실패 사유 · 경쟁사(해당 시) · 견적 금액
채권관리대장·거래처 메일 — 거래처명 · 미수 금액 · 발생일 · 회수 예정일
견적 원가·실적 원가 집계 자료 — 품목·프로젝트명 · 견적 원가 · 실적 원가 · 차이 사유
필수 항목을 나란히 놓으면 같은 값이 되풀이됩니다. 고객 이름은 요청서, 수주 내역, 실주 보고서, 채권관리대장(거래처명)까지 4개 문서에 다시 적힙니다. 견적 값은 실주 보고서의 견적 금액과 원가 비교의 견적 원가로 2번 나오고, 납기는 요청서의 납기 요청일과 수주 내역의 납기로 2번 나옵니다. 부서마다 앞 문서에서 같은 값을 옮겨 적는 셈이라, 요청 번호 하나에 이 값들을 한 번만 기록하면 옮겨 적는 일이 줄어듭니다.
견적 가격과 납기 약속은 AI가 정하지 않고 권한을 가진 사람이 정합니다
판단 | 누가 | 근거 |
|---|---|---|
만들 수 있는지 | 설계 책임자 | 요구사양서·기준값 |
견적 가격 | 견적 결재권자 | 견적 원가·과거 견적 |
납기 약속 | 영업 담당(생산 확인 뒤) | 납기 요청일·생산 능력 |
수주 여부 | 영업 결재권자 | 가격·납기·조건 |
독촉 여부 | 재경·영업 | 회수 예정일·거래 이력 |
원가 차이 원인 | 원가 담당 | 견적 원가·실적 원가 |
위 6가지는 AI가 채우지 않는 값입니다. AI가 견적서 초안을 만들어도 가격 칸은 비워 둡니다. 과거 견적과 견적 원가를 옆에 붙여 보여 줄 수는 있지만, 고객에게 낼 가격은 권한을 가진 사람이 정합니다.
납기도 같습니다. AI는 고객이 요청한 날짜를 옮겨 적을 뿐이고, 고객에게 약속하는 납기는 영업 담당이 생산 쪽 사정을 확인한 뒤 채웁니다. 요청서에 납기가 없으면 그 값은 빈 칸으로 두고 「미확인」으로 표시해 담당자 확인으로 보냅니다. 누가 어떤 값을 정하는지는 회사마다 결재 규정이 달라서, 위 표의 「누가」 열은 일반적인 제조기업 절차로 적었습니다. 판단 6가지 가운데 만들 수 있는지·독촉 여부·원가 차이 원인 3가지도 원본 목록에는 없어 일반적인 제조기업 절차로 더했습니다.
이 흐름은 부서 사이의 메일과 뒤늦은 비교에서 끊깁니다
요구사양 해석 — 고객 요구를 어떻게 읽을지 설계와 영업 사이에 메일이 여러 번 오갑니다. 설계가 뽑은 요건 목록이 견적서 조건에 그대로 옮겨지지 않으면 같은 질문이 반복됩니다.
수주 뒤 생산으로 넘길 때 — 수주 번호가 생산 계획 번호로 넘어가지 않으면 생산관리가 수주 내역을 계획에 다시 입력합니다. 원본 목록에는 이 업무가 없지만, 두 흐름이 만나는 지점이라 일반적인 제조기업 절차로 짚어 둡니다.
원가 되짚기 — 견적 원가와 실적 원가 비교는 수주하고 한참 뒤에야 이뤄집니다. 차이 사유가 다음 견적서 작성에 반영되지 않으면 같은 원가 오차가 다음 견적에서도 되풀이됩니다.
미수금 — 받을 돈과 회수 예정일이 재경 메일함에만 있어서, 영업 담당은 거래처가 대금을 미루고 있다는 것을 늦게 압니다.
실주 사유 — 실주 보고서가 구매영업 안에만 남아 설계와 원가는 가격 때문에 졌는지 사양 때문에 졌는지 모릅니다. 원본 목록에는 이 끊김이 적혀 있지 않아 일반적인 제조기업 절차로 짚어 둡니다.
원본 목록에서 이 흐름의 AI 동작은 6건이고 자동 입력과 초안 작성이 2건씩입니다
집계 기준은 같은 목록을 두 곳에서 적어 낸 부서를 한 번만 센 110건이고, 동작 분류는 웨이스가 업무의 「내용」 설명을 보고 나눈 것입니다.
동작 | 원본 건수 | 들어가는 단계 |
|---|---|---|
자동 입력 | 2 | 요구사양 분석·수금 |
초안 작성 | 2 | 견적서·수주 실적 리포트 |
대조·검증 | 1 | 원가 되짚기 |
요약·분석 | 1 | 실주 사유 |
검색·답변 | 0 | 과거 견적 찾기 |
기한 알림 | 0 | 회수 예정일 |
분류·배정 | 0 | 요청 담당 추천 |
자동 입력 2건은 설계의 고객 요구사양서 분석과 재경의 미수금 메일 정리입니다. 초안 작성 2건은 구매영업의 견적서 초안과 수주·매출 실적 리포트이고, 대조·검증 1건은 원가의 견적 대비 실적 원가 비교, 요약·분석 1건은 구매영업의 실주 사유 분석입니다.
아래 3줄(검색·답변, 기한 알림, 분류·배정)은 원본 목록에 없고, 흐름으로 묶어 보니 필요해 보여 웨이스가 설계안으로 더했습니다. 과거 견적을 찾는 일은 견적서 초안의 근거가 되고, 회수 예정일 알림은 미수금이 메일함에 묻히지 않게 합니다. 웨이스는 이 동작들을 고객 현장에 적용한 실적이 아직 없어, 여기 적은 것은 모두 설계안입니다.
영업 담당 한 명이 요청 번호부터 입금까지 한 줄로 챙깁니다
흐름 주인은 영업 담당 한 명입니다. 부서마다 자기 단계가 끝나면 손을 떼는 구조에서는 견적을 낸 뒤 대금이 들어왔는지까지 챙기는 사람이 정해져 있지 않습니다. 주인이 있으면 수주 뒤 생산을 기다리는 동안에도 이 건이 어디까지 왔는지 한 사람이 압니다.
남아야 할 기록은 번호 사슬입니다. RFQ 번호 → 견적 번호 → 수주 번호 → 생산 흐름의 계획 번호·작업지시 번호·로트 → 납품 → 세금계산서 승인번호 → 입금 확인이 한 줄로 찾아져야 합니다. 실주한 건은 RFQ 번호 → 견적 번호 → 실주 기록으로 끝납니다. 수주 번호가 생산 흐름에 그대로 넘어가야, 영업 담당은 생산 쪽에 따로 묻지 않고도 납품 시점을 알 수 있습니다.

이 정의가 말하지 않는 것
위 정의는 제조기업 한 곳이 한 번 적어 낸 「AI를 붙이고 싶은 업무」 목록에서 나왔고, 그 부서들의 업무 전체가 아닙니다. 업무를 흐름에 배정하고 AI 동작을 나눈 기준은 웨이스가 정한 것이라, 기준을 달리하면 결과가 달라질 수 있습니다. 견적 원가 산정, 청구, 생산으로 넘기는 단계, 판단 표의 「누가」 열은 일반적인 제조기업 절차로 보강한 부분이고, 흐름으로 바꿨을 때 시간이 얼마나 줄어드는지는 아직 측정하지 않았습니다.
영업 흐름은 수주에서 끝나지 않고 입금까지 가야 끝나며, 그 사이에서 가격과 납기만큼은 끝까지 사람이 정합니다.
WACE(웨이스)는 공장이 스스로 판단하고 멈추지 않게 하는 제조 AI 운영체제 VEXPLOR를 만드는 회사다.
함께 읽어보세요
이 글이 도움이 되셨다면 공유해 주세요
태그
작성자
새 글이 올라오면 메일로 알려드립니다
제조 현장에서 확인한 것들을 기록합니다. 새 글이 올라오면 보내 드리고, 언제든 해지할 수 있습니다.
우리 공장은 지금 어느 단계일까요?
제조 AI 성숙도 자가진단 — 회사 정보 없이 10문항이면 됩니다.
이 문제를 실제 현장에서 풀고 있습니다
MES·PLM·제조AI를 표준이 남는 방식으로 구축한 실적을 볼 수 있습니다.


