결론부터 말하면, WMS와 ERP 재고가 맞지 않을 때 그 원인은 보통 시스템이 잘못 계산했기 때문이 아니다. 두 시스템이 같은 것을 다르게 정의하기 때문이다. 끊긴 인터페이스는 가장 눈에 띄는 실패 유형에 불과하다. 더 흔한 것은 배치, 단위, 상태 매핑이 어긋난 경우로, 실물 재고는 전혀 움직이지 않았는데 장부가 한 건만큼 달라진다. 창고 WMS·ERP 통합 작업에서 트리아지는 엄격한 순서가 있다. 먼저 인터페이스가 흐르고 있는지 확인하고, 다음으로 매핑이 맞는지 확인한 뒤, 그제야 차이의 책임이 누구에게 있는지 이야기한다. 이 순서를 뒤집으면 엉뚱한 곳을 고치는 데 한 달을 쓸 수 있다.
나는 이 함정을 세 번 보았다. 가장 최근 사례는 가동 시작 3주차의 소비재 고객이었다. 재무팀은 ERP에 종이 제품이 2천 단위 이상 부족하다고 했고, 창고는 실물 재고가 모두 있다고 했으며, 순환 실사가 창고의 말을 뒷받침했다. 양측 모두 상대가 틀렸다고 확신했고, 프로젝트팀은 인터페이스를 처음부터 다시 만들 뻔했다. 실제 원인은 거의 민망할 정도였다. ERP는 케이스 단위로 재고를 관리했고, WMS는 낱개 단위로 관리했으며, 인터페이스가 보낸 케이스 수량을 수신 측이 낱개로 장부에 올렸던 것이다. 한 케이스에 24낱개라면, 주문 한 건이 23단위의 차이를 만든다. 고장 난 것은 아무것도 없었다. 단위 매핑 표에 한 행이 빠져 있었을 뿐이다.
WMS·ERP 통합의 인터페이스 장애: 네 가지 유형, 순서대로
인터페이스가 실패하면 먼저 서비스를 재시작하지 마라. 재시작은 일시적인 중단만 고친다. 설정 오류는 고치지 못한다. 나는 인터페이스 장애를 네 가지 유형으로 나누고 하나씩 제외해 나간다. 첫째, 메시지가 출발조차 하지 않은 경우다. WMS의 보류 큐에 발신 문서가 머물러 있는데, 대개 상태가 잘못되었기 때문이다. 예를 들어 인터페이스가 절대 가져가지 않을 미승인 주문이 그렇다. 둘째, 출발했지만 도착하지 않은 경우다. 미들웨어 큐가 밀려 있거나 인증서가 만료되었고, 큐 깊이와 오류 로그를 보면 명백하다. 셋째, 도착했지만 거부된 경우다. 누락된 필드나 상대 시스템 마스터 데이터에 없는 코드 때문에 메시지가 튕겨 나간다. 넷째, 가장 위험한 경우로, 도착해서 기장되었지만 잘못 기장된 경우다. 예를 들어 단위 환산 오류나 창고 코드 불일치로 장부가 조용히 벌어지고, 문제는 며칠 뒤에 폭발한다.
모든 가동 시작 밤 체크리스트에서 나는 세 가지를 고집한다. 인터페이스 큐 적체에 대한 알림, 실패 문서에 대한 재시도 버튼과 재시도 이력, 그리고 상대가 거부한 문서에 대한 일일 정리 담당자다. 이 세 가지가 없는 인터페이스는 벌거벗고 돌아가는 셈이다. 예전에 매일 밤 같은 시간에 인터페이스가 끊기는 고객과 일한 적이 있는데, 예약된 전송이 상대 시스템의 야간 유지보수 시간대와 충돌했기 때문이었다. 전송 시간대를 옮기니 해결되었다. 코드를 의심하기 전에 시간대와 로그를 확인하라.
WMS·ERP 통합을 위한 매핑 표: 배치, 단위, 상태
인터페이스가 흐르는데도 장부가 여전히 맞지 않으면 세 가지 매핑 표를 확인한다. 첫째는 단위 매핑이다. 케이스, 팔레트, 낱개, 내포장, 어느 시스템이 기준 단위를 소유하는지, 환산은 어디에 있는지, 예외인 제품 카테고리가 있는지. 둘째는 배치 매핑이다. ERP 배치 번호가 WMS 배치 번호와 같은 것인가? 어떤 기업은 ERP에서 생산일을 배치로 쓰면서 WMS에서는 입고 배치 번호를 쓰는데, 둘은 닮았지만 일치하지 않는다. 셋째는 상태 매핑이다. 검사 대기, 운송 중, 동결, 파손 등 WMS 재고 상태가 ERP에서 각각 무엇에 대응하는지, 파손 재고는 가용으로 계산되는지, 동결 재고는 장부에 남는지.
내가 본 가장 전형적인 실패는 "검사 대기" 상태가 빠져 있던 경우였다. 품질 검사 대기 상품이 WMS에서는 대기 상태에 머물렀는데, ERP는 이를 가용 재고로 counted해서 영업이 그 숫자를 보고 주문을 받았다가 출하할 수 없었다. 해결책은 복잡하지 않았다. 상태 매핑 표를 인쇄하고, 양측 업무 책임자가 한 줄씩 서명하게 하고, 대기, 동결, 파손 재고를 각각 별도 구분에 넣고, 영업은 가용 상태만 보게 한 것이다. 구두 합의가 아니라 가동 시작 전에 표에 서명을 받아야 한다.
차이 조정에는 문제가 생길 때마다 새로 데이터를 뽑는 것이 아니라 고정된 차이 표 하나가 필요하다. 그 표에는 최소 네 열이 필요하다. 제품, WMS 수량, ERP 수량, 차이 사유다. 사유 열에는 다섯 가지 값만 허용된다. 인터페이스 미도착, 단위 환산, 상태 매핑, 배치 차이, 실물 차이. "기타"로 표시된 행은 재조사로 되돌아간다. 그 표를 한 달 돌리면 차이 사유가 크게 집중된다는 것을 알게 되는데, 보통 한두 가지 카테고리가 반복된다. 그 규율이 창고 WMS·ERP 통합의 차이 조정을 시간이 지나도 유지되게 한다. 그 한두 곳을 고치면 전체 차이는 급격히 떨어진다.
숫자의 책임자는 누구인가: 다투기 전에 규칙을 정하라
장부가 맞지 않을 때 가장 비싼 부분은 좀처럼 숫자 수정이 아니다. 양측이 서로를 탓하는 것이다. 창고는 시스템이 잘못 보냈다고 하고, IT는 현업이 잘못 입력했다고 하며, 재무는 어느 쪽도 믿을 수 없다고 한다. 그래서 책임은 문제가 나타나기 전에 정해져야 하고, 사후 논쟁이 아니라 가동 시작 문서에 적혀 있어야 한다.
우리가 쓰는 구분은 단순하다. 인터페이스 전송 문제는 IT의 책임이며, 전송 로그로 판단한다. 로그에 전송되었다고 나오는데 상대가 받지 못했다면 중간 계층의 책임이다. 매핑 규칙 문제는 프로젝트팀의 책임이며, 서명된 매핑 표로 판단한다. 표에 적힌 대로 계산되는 것이다. 실물 문제는 창고의 책임이며, 실사 결과로 판단한다. 실사와 WMS가 맞지 않으면 먼저 실물 재고를 확인한다. 데이터 입력 문제는 문서를 입력한 사람의 책임이며, 원본 문서 값으로 판단하고, 모든 변경은 흔적을 남긴다. 규칙이 생기면 차이는 먼저 분류되어 책임자에게 전달되고, 누구의 잘못인지 정하느라 회의 절반을 쓸 필요가 없어진다.
| 차이 유형 | 결정적 증거 | 책임자 |
|---|---|---|
| 인터페이스 미도착 | 전송 로그, 큐 기록 | IT |
| 단위, 상태, 배치 매핑 오류 | 서명된 매핑 표 | 프로젝트팀 |
| 실물 재고가 WMS와 다름 | 실사 결과 | 창고 |
| 문서 입력 오류 | 원본 값과 변경 이력 | 입력자 |
여기 직관에 반하는 판단이 있다. 차이가 작을수록 더 심각하게 받아들여야 한다는 것이다. 2천 단위의 차이는 모두가 조사한다. 3단위나 5단위의 차이는 충분히 가깝게 느껴져 수동 조정으로 넘겨버린다. 하지만 작은 차이는 종종 매핑 오류의 초기 신호다. 오늘의 3단위가 다음 달에는 3천이 될 수 있다. 우리의 규칙은 실사 중 여분의 스캔 한 번으로 밝혀지더라도 모든 차이를 사유 카테고리와 함께 표에 올리는 것이다. 작은 차이를 기록하지 않으면, 큰 차이가 왔을 때 어디서부터 찾아야 할지조차 모르게 된다.
창고 WMS·ERP 통합 가동 시작 체크리스트
마무리로, 바로 쓸 수 있는 체크리스트를 제시한다. 가동 시작 밤에 각 항목에 체크하라. 단위 매핑 표가 예외 카테고리를 포괄하는지, 상태 매핑 표가 양측 책임자에게 서명되었는지, 배치 번호 규칙이 양 시스템에서 같은 것인지, 인터페이스에 실패 알림과 재시도 메커니즘이 있는지, 차이 표가 매일 자동으로 돌아가는지, 차이 사유가 그 다섯 가지 카테고리로 제한되는지, 책임 문서가 세 당사자 모두에게 전달되었는지. 일곱 항목, 모두 통과하면 가동 시작이다. 하나라도 빠지면, 가동 시작 후에 고치는 비용은 지금의 몇 배가 된다.
직설적인 진실은 이렇다. 맞지 않는 WMS와 ERP 장부는 거의 절대 기술 문제가 아니다. 경영진이 마무리 짓지 않은 정의의 문제다. 정의를 적고, 서명을 받고, 매일 조정하라. 그것은 시스템을 교체하는 것보다 훨씬 효과적이다. 나는 이 함정을 세 번 보았고, 원인은 매번 달랐지만 해결책은 같았다. 먼저 트리아지, 다음으로 책임 배정, 마지막으로 시스템 수정이다.
Lin Xiao, WMS 구축 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.





