결론부터 말하겠습니다. 주문 번호가 시스템 간에 맞지 않을 때, 통합이 깨진 경우는 거의 없습니다. 깨진 것은 아무도 관리하지 않는 매핑 테이블입니다.
2023년 가을, 캘리포니아 온타리오 외곽의 60,000제곱피트가 넘는 의류 3PL. 고객 서비스 책임자로부터 연락이 왔습니다. 그녀의 팀은 '내 주문은 어디 있나요' 티켓에 파묻혀 있었습니다. 온라인 스토어에서는 모든 주문이 '출고됨'으로 표시되는데, 추적 번호를 클릭하면 '그런 출고가 없습니다'라고 나오거나, 심하면 남의 소포가 표시됐습니다. IT팀은 일주일 동안 로그를 뒤졌고, 모든 인터페이스는 녹색이었습니다. OMS, WMS, 운송사 API, 오류 제로.
세 달 전, WMS 업그레이드로 분할 후 자식 주문 번호 생성 방식이 바뀌었습니다. OMS 쪽에는 아무도 알리지 않았고, OMS는 예전 방식으로 계속 ID를 만들었습니다. 운송사에서 추적 번호가 돌아오면, 라이트백 로직은 ID 문자열에 대한 추측으로 주문에 매칭했습니다. 추측을 틀리면 추적 번호는 잘못된 주문에 착지합니다. 파이프는 멀쩡했습니다. 깨진 것은 '한 시스템의 ID가 다른 시스템에서도 같은 의미다'라는 가정이었습니다.
이 장면은 20년 동안 최소 열 번은 봤습니다. 온타리오에서 발견의 순간은 녹색 로그가 왜 거짓말을 하는지 보여줍니다. IT 리드가 문제 주문 하나를 꺼내 화면 하나씩 함께 따라갔습니다. OMS에서는 주문 88412, 출고됨, 추적 번호 첨부. WMS에서는 주문 88412가 두 건의 자식 피킹으로 분할되었는데, 자식 번호는 새 체계인 88412-A와 88412-B였고, OMS 라이트백은 여전히 구 패턴인 88412-01과 88412-02에 매칭하고 있었습니다. 추적 번호는 무사히 돌아왔는데, 걸려 있던 주문 번호는 어디에도 존재하지 않는 번호였습니다. 모든 API는 제 일을 했습니다. ID의 형태에 대한 계약이 한쪽에서 다시 쓰이고, 다른 쪽에서는 다시 합의되지 않았던 것입니다.
체인은 세 군데의 예측 가능한 지점에서 끊어진다
주문 여정의 정류장은 네 곳입니다. OMS의 부모 주문, WMS의 피킹과 소포, TMS와 운송사의 라벨과 추적, OMS로의 상태 라이트백. 그리고 세 군데의 예측 가능한 이음새가 있습니다.
첫 번째, 분할 출고. OMS에서 주문은 하나의 번호입니다. WMS 안에서는 재고 위치에 따라 두 개의 웨이브와 세 개의 소포로 분할되고, 자식 번호는 WMS 안에만 존재합니다. OMS는 자식이 존재하는지조차 모릅니다. 추적 번호는 부모 앞으로 돌아오기 때문에 자식 번호로 검색하면 아무것도 나오지 않습니다. 더 지독한 변종은 부분 출고입니다. 소포 세 개, 운송사 두 곳, 세 번째는 재고 부족. OMS는 부모 전체를 '완료'로 표시합니다. 고객은 상자 두 개를 받고, 세 번째 추적 번호는 고아가 됩니다.
두 번째 이음새: 추적 라이트백. 운송사가 추적 번호를 발급하고, TMS가 이를 가져온 뒤 라이트백이 잘못된 주문을 가리킵니다. 전형적인 경우: 라벨이 잘못 인쇄되고, 누군가 재인쇄하는데, 기존 추적 번호는 무효화되지 않았습니다. 이제 하나의 소포에 두 개의 살아 있는 번호가 달립니다. 고객과 상담원은 각자 다른 번호를 추적합니다. 모두가 맞고 모두가 틀립니다.
세 번째 이음새: 배치와 팔레트, 이건 B2B 업계의 이야기입니다. 리테일러는 856 사전 출고 통지를 요구하고, 실물 팔레트의 SSCC-18 시리얼 번호는 ASN의 팩 레벨 번호와 한 글자도 틀리지 않고 일치해야 합니다. 한 글자만 틀려도 팔레트 전체가 반려됩니다. 한때 WMS에서 팔레트 ID를 자동으로 생성하면서 945 출고 통지는 손으로 입력하는 창고를 봤습니다. 그 두 번호는 애초에 같은 것이 아니었습니다. 세 달 뒤 정산에서 터졌고, 차지백 총액은 그럴듯한 지게차 한 대 값은 됐습니다.
통합은 데이터를 움직이고, 매핑 테이블은 데이터를 일치시킵니다. 그리고 두 번째 일에 모든 문제가 묻혀 있습니다.
반품 흐름에도 함정이 있습니다. 소포가 RMA 번호로 창고에 입고되는데, OMS의 환불은 원래 주문 번호에 걸려 있습니다. RMA-주문 매핑이 없으면 재무에는 고아 환불이 쌓입니다. 제가 본 최악의 경우는 한 달에 수백 건의 미매칭 환불이었고, 운영팀은 일주일 내내 손으로 매칭했습니다.
매핑 테이블을 지루하게 만들라
제 추적 방법은 동작 하나입니다. 체인을 따라가되, 건너뛰지 않습니다. 먼저 그 ID가 부모인지 자식인지, 어느 시스템에서 태어났는지 파악합니다. 하류로 한 홉씩 이동합니다. ID가 이어지지 않는 홉이 단절 지점입니다. 열 번 중 아홉 번은 두 번째 홉에서 찾습니다.
데이터를 고치기 전에 세 가지 질문을 던지십시오. 이 매핑을 시스템이 썼는가, 사람이 손으로 입력했는가? 최근 규칙이 바뀐 적이 있는가? 같은 식으로 깨진 것이 몇 건이나 더 있는가? 한 건의 레코드를 고치는 것은 소방, 배치로 고치는 것은 트러블슈팅입니다. 온타리오 사례에서는 지난 세 달간의 잘못 매핑된 추적 번호를 모두 제자리에 다시 걸어주는 스크립트를 작성했습니다. 한 번의 실행으로 4천 건이 넘는 주문. 하나씩 클릭했더라면 고객 서비스팀은 내년이 될 때까지 걸렸을 겁니다.
다음은 경화(hardening)입니다. 다섯 가지 규칙, 모두 수업료를 내고 배운 것들입니다.
하나의 정본 테이블. 주문에서 자식으로, 자식에서 소포로, 소포에서 라벨로, 라벨에서 추적 번호로, 배치와 팔레트까지. 전부 하나의 매핑 테이블에, 시스템 안에, 지명된 소유자와 변경 로그를 갖추고. 제가 본 썩은 매핑 테이블에는 공통의 조직 문제가 있었습니다. OMS 팀은 WMS 팀이 관리한다고 생각했고, WMS 팀은 3PL의 EDI 분석가가 관리한다고 생각했고, 분석가는 '그냥 참고 자료'라고 생각했습니다. 한 사람의 이름을 붙이십시오. 매달 변경 로그를 검토하고, 모든 업그레이드와 운송사 온보딩, 리테일러 스펙 변경에 참석하는 사람. 온타리오 사고는 WMS 업그레이드에 OMS 쪽 아무도 읽지 않은 릴리스 노트가 붙어 있어서 발생했습니다. 소유자가 있었다면 5분짜리 diff 리뷰에서 잡아냈을 겁니다.
ID에 네임스페이스를 붙이십시오. 모든 ID에 태어난 시스템의 접두사를 붙여, WMS에서 태어난 번호가 OMS에서 태어난 번호와 절대 충돌하지 않도록 합니다. 거칠게 들리겠지만 세 번은 구했습니다. 두 시스템 모두 순진한 자동 증가 정수를 사랑하고, 접두사 없이는 반드시 충돌합니다. 한때 두 3PL 고객의 주문이 하나의 WMS로 흘러들어왔는데, 둘 다 10001에서 시작했습니다. 시스템이 고객 A의 소포를 고객 B의 주문에 걸어버렸습니다. 팔레트 한 대 분량이 잘못된 고객에게 출고됐습니다.
소포 ID를 에코백하십시오. 추적 번호가 돌아올 때는 나갔던 소포 ID를 함께 들고 와야 합니다. 맨 추적 문자열만으로는 역으로 추적할 수 없습니다. 라벨을 두 번 재인쇄하고 나면 그 추적 번호가 어느 OMS 주문에 속하는지 맞혀보십시오. 856에는 이미 이 구조가 들어 있습니다. 운송사 고유의 번호와 함께 선하증권 참조로 추적 번호를 싣는 REF 세그먼트. 사용하십시오.
매일 정산하십시오. 스케줄 작업을 돌립니다. WMS에서는 출고됨, OMS에서는 업데이트 대기, 운송사 추적 이벤트 있음. 세 집합의 차이를 구합니다. 떨어져 나온 것이 내일 고객 서비스가 항의를 받을 몫입니다. 세 개의 버킷: WMS에서는 출고됐는데 OMS에서 한 번도 업데이트되지 않음. 라이트백 유실. OMS는 업데이트됐는데 운송사 이벤트가 없음. 라벨은 인쇄됐지만 화물은 움직이지 않음. 어느 쪽에도 기록이 없는 운송사 이벤트. 보통은 테스트 라벨이나 재인쇄된 낡은 번호. 먼저 분류하고, 그다음 행동합니다.
분할 로직을 버전 관리하십시오. 분할 규칙 변경은 모두 먼저 테스트 환경에서 매핑에 대해 검증합니다. 2분짜리 확인이 세 달 늦었습니다.
처음에 정해야 할 트레이드오프가 하나 있습니다. 추적 라이트백에서 운송사 실시간 콜백과 배치 정산 중 어느 것을 택할 것인가. 실시간은 빠르지만 비용이 더 들고 콜백이 유실됩니다. 배치는 반나절 늦지만 바위처럼 단단합니다. 소규모 운영은 부끄러워 말고 배치로 돌리고, 성수기 2주 전에 실시간으로 전환하십시오. 아낀 돈으로는 새벽 2시 소방 작업의 야근 수당을 감당하지 못합니다.
그리고 ID 문제와는 전혀 무관한 '불일치'가 하나 더 있습니다. 시간입니다. WMS는 태평양 시간으로 출고를 기록하고, OMS는 UTC로 해석합니다. 같은 주문이 시스템마다 하루씩 엇갈려 착지합니다. 상담원은 '오늘의 출고'를 검색해 아무것도 찾지 못하고 ID가 사라졌다고 생각합니다. 시간대를 넘나드는 창고는 이 함정에 늘 빠집니다. ID를 의심하기 전에 시계를 의심하십시오.
이제 여러분께 질문 하나. IT팀에게 물어보십시오. ID 매핑 테이블을 마지막으로 연 게 언제였는지. 답이 '뭔가 깨졌을 때'라면, 다음 단절은 이미 진행 중입니다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
