업무 시스템 기초 3/4 · 의류 오더가 세 회사의 시스템을 지나는 길: 기계가 읽는 구간과 사람이 읽는 구간
핵심 요약
의류 오더 한 건은 바이어의 PLM, 벤더의 ERP, 공장의 생산 계획과 실적 기록을 차례로 지나요. 회사와 회사 사이를 잇는 방법은 세 가지예요. 시스템끼리 표준 전자 문서를 주고받는 EDI, 상대 회사 시스템에 사람이 직접 접속하는 포털, 그리고 PDF와 엑셀을 메일로 보내는 방법이에요. EDI는 주로 바이어와 벤더 사이의 발주서, 선적 통지, 인보이스에만 쓰이고, 벤더와 공장 사이는 대부분 파일과 메일로 이어져요. 같은 오더를 부르는 번호가 회사마다 다르고, 연결할 상대가 오더마다 바뀌고, 연결 규칙을 정하는 쪽과 비용을 내는 쪽이 다르고, 보여 줄 수 있는 데이터의 범위가 달라서 회사 사이의 연결은 한 회사 안의 연결보다 훨씬 어려워요.
1편에서는 PLM, ERP, APS, MES, WMS가 무엇을 관리하는지를, 2편에서는 이 시스템들이 왜 다섯 갈래로 따로 자랐는지를 정리했어요. 2편 마지막에서는 이런 이야기를 했어요. 제조업은 수십 년 동안 한 회사 안의 시스템을 잇는 데 힘을 썼는데, 의류 오더는 그 시스템들이 바이어, 벤더, 제조 공장이라는 세 회사에 나뉘어 있다는 점이에요.
이번 글에서는 오더 한 건을 따라가면서, 정보가 회사의 경계를 넘을 때 어떤 형식으로 넘어가는지를 봐요. 기준은 하나예요. 넘어가는 정보를 받는 쪽 시스템이 바로 읽을 수 있는지, 아니면 사람이 눈으로 읽고 다시 입력해야 하는지예요.
회사 사이를 잇는 세 가지 방법
회사와 회사 사이에서 정보를 주고받는 방법은 크게 세 가지예요.
시스템끼리 주고받는 방법: EDI
EDI(Electronic Data Interchange, 전자 문서 교환)는 회사끼리 정해진 표준 형식의 전자 문서를 시스템 대 시스템으로 주고받는 방식이에요. 미국에서는 ANSI X12라는 형식이 널리 쓰이고, 문서마다 번호가 붙어 있어요.1
비유하면 전국 공통 택배 송장이에요. 송장 양식이 정해져 있어서 어느 택배사의 기계든 같은 칸에서 받는 사람 주소와 무게를 읽어요. EDI도 발주번호는 몇 번째 칸, 수량은 몇 번째 칸 하는 식으로 정해져 있어서, 받는 쪽 시스템이 사람 손을 거치지 않고 바로 읽어요.
| 문서 번호 | 이름 | 보내는 쪽 | 담는 내용 |
|---|---|---|---|
| 850 | 전자 발주서 | 바이어 → 공급자 | 발주번호·일자, 납기, 품목, 수량·단위·가격, 선적·지불 조건1 |
| 856 | 사전 선적 통지(ASN) | 공급자 → 바이어 | 발주번호, 선적일, 품목·수량, 카톤별 품목, 팔레트별 카톤, 운송사2 |
| 810 | 전자 인보이스 | 공급자 → 바이어 | 인보이스 정보1 |
바이어와 공급자 사이에서 흔히 쓰는 EDI 문서
상대 시스템에 사람이 접속하는 방법: 포털과 PLM
두 번째는 바이어가 운영하는 PLM이나 공급자 포털에 벤더 담당자가 로그인하는 방식이에요. TechPack을 내려받고, 샘플 코멘트를 읽고, 검사 리포트를 올려요. 정보는 바이어의 시스템 안에 있지만, 그 정보를 벤더의 ERP로 옮기는 것은 사람이에요. 두 시스템 사이를 잇는 일은 담당자가 맡고 있어요.
파일과 메일로 보내는 방법
세 번째는 PDF, 엑셀, 메일 본문, 메신저, 사진으로 보내는 방법이에요. 받는 쪽은 파일을 열어 읽고, 필요한 값을 자기 시스템이나 양식에 다시 입력해요. 공급망 워크플로우에서 정보가 옮겨 가는 구간은 어디인가에서 정리한 여섯 구간 대부분이 이 방식으로 이어져 있어요.
| 방법 | 넘어가는 형식 | 받는 쪽에서 읽는 주체 |
|---|---|---|
| EDI | 표준 전자 문서 | 시스템 |
| 포털·PLM 접속 | 상대 시스템 화면, 내려받은 파일 | 사람 |
| 파일·메일 | PDF, 엑셀, 메일 본문, 사진 | 사람 |
회사 사이를 잇는 세 가지 방법과 받는 쪽에서 정보를 읽는 주체
오더 한 건을 따라가 보면
이제 세 방법을 오더 한 건의 흐름에 놓아 볼게요. 스타일 번호는 지난 연작에서 쓴 가상 번호 WJ-2411로 할게요.
바이어가 발주를 내면 P/O가 벤더에게 가요. EDI를 쓰는 바이어라면 850 문서가 벤더 시스템에 바로 들어오고, 그렇지 않은 바이어라면 PDF가 메일로 와요. 같은 벤더라도 바이어마다 받는 방식이 달라요. 사양은 바이어 PLM에 올라온 TechPack을 담당자가 내려받아 읽어요.
벤더 본사에서는 이 정보를 ERP에 오더로 등록하고, 원가와 BOM을 만들고, 원부자재를 발주해요. 여기까지는 한 회사 안이라서 ERP 안에서 이어질 수 있어요.
그다음 오더가 제조 공장으로 넘어가는 구간이 달라요. 벤더는 작업 지시와 사양, 자재 입고 일정을 엑셀로 정리해 메일로 보내고, 공장은 그 파일을 읽고 자기 생산 계획표나 APS, MES에 다시 입력해요. 공장에서 매일 나오는 생산 실적과 검사 결과는 반대로 일보나 엑셀로 정리되어 메일로 벤더에게 가고, 벤더 담당자가 그 숫자를 다시 ERP나 사내 시트에 옮겨요.
선적 단계에서 다시 시스템이 등장해요. 벤더는 공장이 보낸 패킹리스트를 바탕으로 인보이스를 만들고, 바이어가 요구하는 형식에 맞춰 ASN을 EDI나 포털로 보내요.
정리하면, 오더 정보는 기계가 읽는 형식으로 들어와서 사람이 읽는 형식으로 바뀌었다가, 선적 직전에 다시 기계가 읽는 형식으로 돌아가요. 사람이 읽는 형식으로 바뀌는 구간마다 누군가 문서를 읽고 다시 입력해요.
회사 사이의 연결이 어려운 네 가지 이유
한 회사 안이라면 ERP와 MES 사이를 잇는 표준도 있어요. 2편에서 본 ISA-95가 따로 떨어진 기업 시스템과 현장 시스템의 연동 방식을 표준화하려고 만든 것이에요.3 회사 사이에서는 이런 연결이 훨씬 어려운데, 이유는 네 가지로 정리할 수 있어요.
같은 오더를 부르는 번호가 회사마다 달라요
바이어는 자기 P/O 번호와 스타일 번호로, 벤더는 사내 오더번호로, 공장은 자기 작업 번호나 로트 번호로 같은 오더를 불러요. 시스템을 이으려면 먼저 이 번호들이 같은 오더를 가리킨다는 대응표가 있어야 해요. 바이어마다 다른 P/O 양식을 사내 형식으로 맞추는 일이 얼마나 까다로운지는 PO 매핑, AI의 가능성과 코딩의 현실 사이에서 다뤘어요.
연결할 상대가 오더마다 바뀌어요
벤더는 여러 바이어와 거래하고, 오더마다 라인 일정과 단가를 보고 공장을 골라요. 공장을 고르는 기준은 단가가 저렴한 공장이 최적이 아닐 때에 정리해 두었어요. 예를 들어(예시예요) 벤더 한 곳이 바이어 세 곳, 공장 다섯 곳과 거래하면, 벤더는 바이어마다 다른 발주 형식 세 가지와 공장마다 다른 보고 형식 다섯 가지를 동시에 다뤄야 해요. 거래처끼리 하나씩 직접 연결하는 방식은 연결할 대상이 늘어날수록 연결 수가 훨씬 빠르게 늘어나요.4
연결 규칙을 정하는 쪽과 비용을 내는 쪽이 달라요
바이어와 벤더 사이의 EDI는 대개 바이어가 형식과 전송 시한을 정해요. 공급자가 이 요건을 지키지 못하면 리테일러가 대금에서 직접 공제하는 벌칙이 있는데, 이것을 차지백(chargeback)이라고 불러요. ASN 전송 시한을 놓치면 리테일러 시스템이 바로 차지백을 발생시키고, 카톤 라벨이 틀리면 창고에서 카톤과 ASN 데이터를 맞출 수 없어요.5 요건을 맞추는 부담은 공급자 쪽에 있어요. 반면 벤더와 공장 사이에는 이런 공통 형식을 정하고 관리하는 주체가 따로 없는 경우가 많아요.
보여 줄 수 있는 데이터의 범위가 달라요
벤더와 공장은 같은 오더를 함께 만들지만, 원가와 효율처럼 서로에게 모두 보여 주기 어려운 숫자도 있어요. 같은 임가공비를 두 회사가 어떻게 다르게 계산하는지는 벤더와 공장이 같은 임가공비를 반대로 계산하는 이유에서 다뤘어요. 그래서 회사 사이의 데이터 공유는 필요한 부분만 그때그때 뽑아서 주고받는 방식이 되기 쉬워요. 제조업 전반에서도 완성품 제조사와 부품 공급자 사이의 데이터 공유가 빨리 낡는 일회성 추출 데이터를 손으로 주고받는 과정으로 이루어진다는 지적이 있어요.6
한 회사 안의 연결과 무엇이 다른가
두 경우를 나란히 놓으면 차이가 분명해져요.
| 비교 항목 | 한 회사 안 | 회사와 회사 사이 |
|---|---|---|
| 연결 표준 | ISA-95 등 업무 시스템과 현장 시스템의 연동 표준 | 바이어와 벤더 사이의 EDI(발주·선적·인보이스)가 중심 |
| 번호 체계 | 한 회사의 기준정보 | 회사마다 다른 번호, 대응표 필요 |
| 연결 상대 | 사내 시스템, 잘 바뀌지 않음 | 거래처, 오더마다 바뀔 수 있음 |
| 결정 주체 | 한 회사의 경영진과 IT 부서 | 규칙은 대개 바이어, 비용은 공급자 |
| 공유 범위 | 사내 권한 설정 | 원가·효율처럼 공개가 어려운 숫자 포함 |
한 회사 안의 시스템 연결과 회사 사이의 연결 비교
EDI가 다루는 문서는 발주서, 선적 통지, 인보이스처럼 거래를 기록하는 문서예요.12 반면 의류 오더에서 자주 바뀌고 문제가 되는 정보는 TechPack 수정, 샘플 코멘트, 작업 지시, 시간대별 생산 실적처럼 거래 문서 바깥에 있어요. 이 정보들이 사람이 읽는 형식으로 오가는 구간이 오더 한 건에서 가장 긴 구간이에요.
마무리하며
의류 오더의 정보는 회사의 경계를 넘을 때마다 형식이 바뀌어요. 바이어와 벤더 사이의 거래 문서는 EDI로 시스템끼리 이어질 수 있지만, 사양과 작업 지시, 생산 실적은 대부분 사람이 읽는 파일로 오가고, 받는 쪽에서 다시 입력돼요. 회사마다 쓰는 시스템이 다르다는 것보다, 회사 사이를 이어 주는 공통의 기록이 없다는 점이 더 근본적인 원인이에요.
마지막 4편에서는 시제가 이 문제를 어떻게 풀었는지를 다룰게요. ERP, MES, PLM, WMS, APS의 기능을 3자 무역 구조 위의 하나의 소프트웨어로 만든 이유와, 바이어, 벤더, 공장이 같은 오더 기록을 보는 방식을 정리할게요.
함께 읽으면 좋은 글
- ERP, MES, PLM, WMS, APS의 차이: 의류 오더 한 건으로 정리한 다섯 가지 업무 시스템
- 제조산업 소프트웨어의 역사: MRP에서 ERP, PLM, APS, MES, WMS로 나뉜 과정
- 공급망 워크플로우에서 정보가 옮겨 가는 구간은 어디인가
- 오더번호를 끝날 때까지 반복적으로 입력하는 이유
참고 자료
- TrueCommerce, EDI 850: Purchase Order Transaction Set Explained. EDI 850의 정의와 담는 항목, 997·855·810 응답 흐름, ANSI X12 형식. ↩
- Cleo, What is an EDI 856? EDI ASN (Advance Shipping Notice). ASN이 담는 항목과 전송 시점. ↩
- ISA InTech, The ISA-95 Enterprise-Control System Integration standards. 기업 시스템과 제어 시스템 연동의 표준화. ↩
- Wikipedia, Enterprise application integration. 점대점 연결이 늘어나는 방식. ↩
- Orderful, 8 EDI Compliance Errors That Trigger Chargebacks. 차지백의 정의, ASN 시한 초과와 라벨 오류. ↩
- Palantir, Enabling Greater OEM Supplier Collaboration. 일회성 추출 데이터를 주고받는 수작업 왕복 과정. ↩
