OMS 구축: Go-Live 날짜를 정하기 전에 세 가지 마스터 데이터 세트를 정렬하라

먼저 결론부터 말하겠습니다. OMS 구축을 롤백해야 할 때, 원인은 거의 대부분 시스템 설치 오류가 아닙니다. 데이터가 준비되지 않았기 때문입니다. 주문, 재고 또는 채널 마스터 데이터가 어긋나 있으면, go-live 당일에는 과다 판매, 오배송, 그리고 공중에 뜬 주문이 발생하고, 어떤 일정도 당신을 구할 수 없습니다. 일정도 중요하지만, 데이터 준비 뒤에 옵니다. 각 단계가 보통 얼마나 걸리는지 알고 싶다면, 이 단계별 OMS 구축 일정이 유용한 참고 자료입니다. 이 글은 다른 주제, 즉 그 일정이 의미를 갖기 전에 반드시 해야 할 데이터 작업에 관한 것입니다. 저는 이 실패를 세 번 보았고, 패턴은 항상 같습니다. 2023년에 한 생활용품 고객은 제품 마스터 데이터를 이관하면서 채널 SKU를 한 번도 매핑하지 않아, 같은 제품이 두 마켓플레이스에서 두 개의 코드를 갖게 되었고 첫 주에 200건 이상을 과다 판매했습니다. 또 다른 고객은 WMS가 실시간 수치를 갖고 있는데도 수동 스프레드시트로 재고를 관리했습니다. 두 수치는 약 30% 달랐고, 베스트셀러가 막을 방법도 없이 품절되었습니다. 세 번째 사례는 제가 가장 좋아하는 경고 이야기입니다. "shipped"는 채널에는 "창고를 떠났다"는 뜻이었고 OMS에는 "택배사가 수거했다"는 뜻이어서, 하루의 간격이 "내 배송 추적이 움직이지 않는다"는 불만 홍수를 만들었고, 지원팀은 주문이 분실된 줄 알았습니다.

왜 이 세 가지인가: OMS 구축에서의 주문, 재고, 채널 데이터

주문 데이터 정렬은 모든 곳에서 같은 단어로 표현되는 전체 수명주기에 관한 것입니다. placed, paid, reviewed, picked, shipped, collected, delivered, cancelled, refunded. 각 단계마다 OMS에서의 이름 하나, 채널에서의 이름 하나, WMS에서의 이름 하나가 필요하며, 이를 하나의 매핑 테이블에 적습니다. 제가 작업한 가장 엉망인 프로젝트에는 취소 주문에 대한 이름이 네 가지나 있었고, OMS는 그중 하나만 인식했습니다. 나머지 세 개는 창고가 거의 출고할 때까지 "awaiting shipment" 상태로 남아 있었습니다. 규칙은 단호합니다. 세 측 모두가 승인한 매핑 행이 없으면 다음 단계로 넘어가지 않습니다. 재고 정렬은 정의와 최신성에 관한 것입니다. 정의란 무엇이 판매 가능으로 포함되는지를 정하는 것입니다. 운송 중 재고가 포함되는가, 검수 중 재고가 포함되는가, 예약 재고가 포함되는가, 파손 재고가 포함되는가? 각 답은 문서로 남겨야 합니다. 최신성이란 동기화 빈도입니다. 실시간, 15 minutes마다, 또는 하루 한 번. 이러한 선택은 겉치레가 아닙니다. 과다 판매 위험을 결정합니다. 2024년 프로젝트에서 고객은 재고가 "기본적으로 정확하다"고 했지만, 이커머스 창고는 하루 한 번만 동기화했고, 라이브 방송은 하루치 물량을 한 시간 만에 팔 수 있었습니다. 주문 시 실시간 예약으로 전환하기 전까지 과다 판매는 보장된 것이나 다름없었습니다. 채널 데이터 정렬은 제품과 가격 매핑에 관한 것입니다. 같은 제품도 채널마다 제목, 사양, 바코드, 가격, 프로모션 가격이 다를 수 있으며, OMS에는 깔끔한 매핑 테이블이 필요합니다. 마켓플레이스 SKU에서 내부 SKU로, 마켓플레이스 가격에서 내부 가격으로, 그리고 프로모션 시작과 종료를 어떤 시계가 관장하는지. 가격 매핑 오류는 재고 오류보다 비쌉니다. 재고 오류는 과다 판매하고, 가격 오류는 잘못된 가격에 판매하며, 그것은 되찾을 수 없습니다.

OMS 구축 데이터 준비 체크리스트 4단계

1단계, 데이터를 목록화합니다. 세 데이터 세트 모두에 대해 모든 원천 시스템, 소유자, 업데이트 빈도, 마지막 대조 날짜를 나열합니다. 소유자가 없는 데이터는 아무도 유지하지 않는 데이터이며, go-live 이후가 아니라 이전에 소유자가 필요합니다. 2단계, 정제합니다. 중복을 제거하고, 누락을 채우고, 코드를 통일합니다. 중복 SKU를 병합하고, 누락된 바코드를 채우고, 하나의 제품에 여러 코드가 있으면 하나의 마스터 코드를 선택합니다. 제 합격 기준은 구체적입니다. 정제 후 200건을 표본 추출하고, 오류율이 2%를 초과하면 다시 돌려보냅니다. 시스템이 용서해 주기를 바라며 더러운 데이터로 go-live 하지 마십시오. 3단계, 대조합니다. 세 테이블을 서로 교차 확인하면서 세 가지 차이, 즉 수량 차이, 상태 차이, 가격 차이를 찾습니다. 대조 보고서를 보관합니다. 누구든 서명하기 전에 차이는 0으로 만들거나 문서화된 처리 계획으로 커버해야 합니다. 4단계, 전환 리허설을 두 번 합니다. 1회차는 정상 경로를 실행합니다. 2회차는 장애만 실행합니다. 채널 연결이 끊기면 어떻게 되는가, 재고 동기화가 멈추면 어떻게 되는가, 주문이 두 번 전송되면 어떻게 되는가? 실제 물량으로 리허설합니다. 테스트 주문 10건이 통과한다고 해서 1만 건의 주문이 통과한다는 것이 증명되지 않습니다.

제가 계속 보는 실패 지점

첫 번째 실패 지점은 관계 없이 정적 데이터만 이관하는 것입니다. 제품은 도착하지만, 제품-창고 배정과 제품-채널 리스팅 관계는 도착하지 않아, 시스템은 위치를 찾을 수 없는 재고와 리스팅할 수 없는 창고를 갖게 됩니다. 마스터 데이터와 관계 데이터는 함께 이관하고 함께 검증해야 합니다. 두 번째는 과거 주문을 무시하는 것입니다. 어떤 팀은 오래된 주문을 예전 시스템에, 새 주문을 새 시스템에 남겨 두어, 지원팀이 한 고객을 위해 두 시스템을 검색해야 하고 반품이 맞지 않게 됩니다. 최근 3개월만 이관하더라도 문서화된 규칙이 필요합니다. 오래된 상태가 어떻게 매핑되는지, 환불 진행 중인 주문은 어떻게 되는지. 세 번째는 직관에 반합니다. 데이터가 많다고 항상 좋은 것은 아닙니다. 완전성을 명분으로 단종 제품, 죽은 채널, 테스트 SKU를 5년치 이관한 프로젝트에서 일한 적이 있습니다. 매핑 테이블이 너무 비대해져서 하나의 SKU를 찾는 데 진짜 탐정 작업이 필요했습니다. 올바른 규칙은 살아 있는 데이터만 이관하는 것입니다. 단종, 무효, 테스트 레코드는 운영 데이터베이스가 아니라 아카이브에 속합니다. 데이터 준비는 양이 아니라 청결함으로 측정됩니다. 올해 사례가 리허설의 요점을 구체적으로 보여줍니다. May 2025에 한 의류 고객은 처음 세 단계를 통과했지만 정상 경로만 리허설했습니다. go-live 후 둘째 주에 마켓플레이스 API가 2시간 동안 흔들리면서 300건 이상의 주문을 두 번 전송했습니다. 창고는 출고 검사가 이를 잡기 전에 중복분을 피킹했습니다. 연결 끊김, 중복 전송, 멈춘 재고 동기화를 다루는 장애 리허설을 추가하고 나서야 프로젝트는 진정으로 준비되었습니다. 정상 흐름은 리허설하기 쉽습니다. 준비가 결정되는 곳은 장애 흐름입니다. 그래서 제 의사결정 프레임워크는 이렇습니다. go-live 날짜를 확정하기 전에 네 가지 질문에 솔직히 답하십시오. 세 마스터 데이터 세트 각각의 소유자는 누구인가? 정제 후 표본 오류율은 얼마인가? 3방향 대조 차이는 0이 되었는가? 전환 리허설은 장애 시나리오를 다루었는가? 답이 하나라도 빠져 있으면 날짜를 미루십시오. 일주일의 지연은 잘못된 출시 후 한 달의 재작업보다 훨씬 저렴합니다. Lin Xiao, WMS 구현 컨설턴트 지음

영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.