SCM 패키지의 메뉴와 API 이름을 읽을 때 계층을 알아야 구조가 보인다. 계획을 세우는 층, 계획을 실행 문서로 바꾸는 층, 실제 거래를 다루는 층이 따로 있고, API 구분키에 planexec 같은 접두어가 붙는다면 그것이 가운데 층을 가리킨다.
SCM 에 용어 사전이 있고, 이 문서는 문서 흐름과 동작을 다룬다.
계획 수립 S&OP — 월 단위로 판매·생산·재고·수급을 맞춘다
│ Release
▼
계획 실행 PO / STO / SO Proposal — 아직 정식 문서가 아닌 제안
│ 확정
▼
실행 모듈 정식 PO / STO / SO — split, merge, send, reload 가 붙는다
Proposal 은 시스템이 계획 결과로 만들어낸 제안이지 정식 문서가 아니다. 재고 할당도, 매출 인식도, 출하 지시도 일어나지 않는다. 사람이 수정하거나 반려할 수 있는 마지막 검토 지점이고, 확정되는 순간 정식 문서가 되어 실행 모듈로 넘어간다.
| 구분 | 뜻 | 확정되면 |
|---|---|---|
| PO Proposal | 수요·재고·안전재고·리드타임을 계산해 나온 구매 제안 | 정식 구매 오더 |
| STO Proposal | 사내 창고·법인·플랜트 사이의 재고 이동 제안 | 재고 이동 오더. 출고 측은 SO 처럼, 입고 측은 PO 처럼 동작한다 |
| SO Proposal | 계획에서 도출한 판매 오더 초안 | 정식 판매 오더 |
SO Proposal 이 존재한다는 것 자체가 그 회사가 계획 기반 판매를 한다는 뜻이다. 일반 고객 주문은 계획 없이 바로 SO 로 들어오므로 제안 단계가 필요 없다. SO Proposal 이 생기는 상황은 셋이다 — 계열사·법인 간 거래(한쪽 PO Proposal 이 상대 법인의 SO Proposal 이 된다), 연간 계약이나 VMI 처럼 미리 합의된 물량, 고객 예측을 근거로 한 선행 확보.
세 Proposal 은 Release 한 번에 함께 생성되지만, 대등하지 않다.
판매 계획(수요)
│
├─ 현재고·입고예정으로 충당되면 아무것도 생기지 않는다
│
├─ 부족한데 다른 창고·법인에 재고가 있으면 → STO Proposal
│ (내부 이동이 구매보다 빠르고 싸므로 먼저 검토된다)
│
└─ 그래도 부족하면 → PO Proposal
(외부 구매가 마지막 수단)
다만 STO·PO 가 SO 에만 매달리는 것은 아니다. 재고 정책이 두 번째 입력이다. 안전재고가 깨졌거나 최소 발주량을 맞춰야 하면 판매 계획과 무관하게 보충 제안이 나온다. 반대로 수요가 있어도 재고로 덮이면 아무것도 나오지 않는다. SO 와 STO·PO 는 1:1 이 아니라 "수요와 재고를 합쳐 계산한 결과" 로 이어진다.
계열사 거래라면 한 단계 더 이어진다. 우리 쪽 PO Proposal 이 상대 법인의 SO Proposal 이 되고, 그쪽에서 다시 STO·PO 가 파생되며 법인을 넘어 연쇄한다.
| 동작 | 의미 |
|---|---|
| Save | 편집 중인 계획 수치를 기록만 한다. 다른 부서나 하위 시스템에 아무 영향이 없다. 버전·시나리오 단위로 여러 번 저장할 수 있다 |
| Release | 저장된 계획을 공식 기준 계획으로 확정하고 실행 계층으로 내려보낸다 |
Release 순간에 일어나는 일은 셋이다 — 계획 버전이 잠기고, 확정 수량이 수요계획·소요계획의 입력값으로 넘어가며, 그 결과로 세 Proposal 이 생성된다. 즉 Release 가 계획 실행 계층의 시작점이다.
Release 는 되돌리기 어렵다. 이미 생성된 Proposal 을 취소하거나 다음 사이클 계획으로 덮어써야 하는 경우가 많다. 그래서 대부분의 시스템이 Release 앞에 승인 단계를 두거나, 권한을 계획 담당자가 아닌 책임자에게만 준다. 메뉴가 관리(Mgmt)와 운영(Operation)으로 나뉘어 있고 Release 가 관리 쪽에 있다면 그 이유다.
다른 계획 패키지에서도 대응되는 개념이 있다. 계획 결과를 실행 시스템으로 보내는 동작을 "Release to execution" 이라 부르거나, 계획 오더를 Release 하면 구매·주문 관리로 넘어가는 식이다. 작업본(Working)과 배포본(Published)을 구분하는 도구도 같은 구조다.
Release 이후에 계획을 바꿔야 할 때, 정식 재Release 없이 처리하는 경로를 두는 경우가 많다. 메뉴가 Request 와 Confirm 짝으로 되어 있으면 변경 요청·승인 워크플로우다.
Request (Save) 실무자가 품목·기간·변경 수량·사유를 등록
▼
Confirm (Save) 승인자가 검토 후 승인 또는 반려
▼
확정 계획에 반영 → 기존 Proposal 조정 또는 신규 Proposal 생성
이 변경이 실행 모듈의 reload 를 부르는 원인이 된다. 계획이 중간에 바뀌면 이미 내려간 제안이나 오더가 어긋나므로, 실행 모듈이 계획 실행 계층의 결과를 다시 끌어와야 한다.
| 동작 | PO 에서 | SO 에서 | 표준성 |
|---|---|---|---|
| Split | 발주 라인을 납기별·공급처별·속성별로 나눈다 | 하나의 SO 를 납기·창고·출하지·가용 수량별로 나눈다. 부분 출하와 백오더 처리에 쓴다 | 표준에 가깝다 |
| Merge | — | 같은 고객·납품처·납기 조건의 여러 SO 를 하나로 합친다. 출하·청구 단위 통합이 목적이다 | 표준에 가깝다 |
| Send | 승인된 PO 를 EDI·메일·벤더 포털로 내보낸다 | 창고 출하 지시, 고객 주문 확인 회신, 또는 상대 시스템의 PO 생성 | 표준. 이름은 Issue · Release · Output · Transmit 등으로 다르다 |
| Urgent | 긴급 발주. 별도 문서 타입으로 두기도 하고 우선순위 플래그로 처리하기도 한다 | — | 개념은 흔하나 구현은 회사마다 다르다 |
| Delegation | 결재 워크플로우의 위임·대결이면 표준이다. "PO 자체를 다른 담당자나 벤더에게 넘긴다" 는 뜻이면 커스텀이다 | — | 조건부 |
| Reload | 업스트림(계획·소요계획·구매요청·외부 연계)에서 데이터를 다시 끌어와 재생성·갱신한다 | 외부 채널에서 주문을 재수신하거나, 가격·재고·납기를 마스터 기준으로 다시 계산한다 | 표준 용어가 아니다. 연계 기반 시스템의 커스텀 메뉴 |
PO 와 SO 양쪽에 같은 동작 이름이 대칭으로 있으면, 그 시스템은 한쪽 SO 가 다른 쪽 PO 로 자동 생성되는 계열사 간 거래 구조를 전제했을 가능성이 높다. send 가 그 연결 고리이고 reload 가 연동을 다시 태우는 기능이다.
SOP 는 겹치는 약어가 많다. 화면에 수량·기간·품목이 격자로 나오고 Release 후 제안 문서가 생기면 S&OP(Sales and Operations Planning)다. 문서 관리 화면이면 표준 작업 절차서(Standard Operating Procedure)이고 계획과 무관하다. 시스템은 & 를 메뉴명이나 API 키에 쓰기 어려워 SOP · SnOP · S_OP 로 표기한다.