WMS 전환에서 가장 비싼 항목은 소프트웨어 라이선스가 아닙니다. 월요일 아침에 설명할 수 없는 재고입니다.
저는 2022년 가을에 이를 뼈저리게 배웠습니다. 토요일 새벽 2시, 캘리포니아 치노에 있는 3PL 창고 사무실에 앉아 있었습니다. 책상 위에는 노트북 두 대. 레거시 시스템은 4,218파렛을 보여줬고, 방금 올린 새 WMS는 4,204를 보여줬습니다. 14파렛이 사라졌습니다.
두 시간의 추적으로 진상이 드러났습니다. 우리는 금요일 밤 8시에 데이터를 동결했고, 가져오기가 끝난 건 토요일 새벽 1시였습니다. 그 5시간 사이에 야간 조가 구 시스템으로 긴급 주문을 통과시켰습니다 — 구 시스템은 여전히 살아 있었고, 사용자 권한도 켜져 있었습니다. 우리는 아무것도 동결하지 않았던 겁니다.
저는 이 이야기를 수없이 했습니다. 거의 모든 WMS 교체 프로젝트가 동결 시점에서 삐끗하기 때문입니다. 이걸 잘못 잡으면 go-live 후 첫 한 달을 창고 운영이 아니라 불량 데이터 청소에 쓰게 됩니다. 제가 본 최악의 케이스: "시스템은 있다는데 창고는 없다"는 불만이 6주간 이어졌고, 결국 사장은 건물을 이틀 통째로 닫고 전부 재집계했습니다. 그 이틀의 비용이 WMS 도입 전체보다 더 들었습니다.
동결은 순간이 아니라 순서입니다
대부분의 팀은 동결 시점을 하나의 타임스탬프로 취급합니다. 자정에 구 시스템을 끄고, 12:01에 새 시스템을 켭니다. 이렇게 하면 14파렛이 사라집니다.
창고는 살아 있는 현장입니다. 입고는 계속 들어오고, 출고는 계속 나가고, 순환 실사는 계속 조정합니다. 50명의 사람과 30대의 지게차를 같은 1초에 멈출 수는 없습니다. 진짜 동결 시점은 스케줄입니다 — 데이터 종류마다 동결 시점이 다르고, 동결 이후에 움직인 것은 정의된 프로세스로 잡아냅니다.
저는 전환 데이터를 네 개의 버킷으로 나눠 각각 동결 시점을 정합니다. 품목·로케이션·벤더·고객 같은 정적 마스터 데이터는 1~2주 일찍 동결할 수 있습니다. 거의 바뀌지 않으니 일찍 동결해도 비즈니스에 비용이 들지 않고, 그동안 집안 청소를 할 시간을 확보할 수 있습니다. 제가 만져본 레거시 시스템은 모두 마스터 데이터가 지저분했습니다. 한 품목에 코드 세 개, 대소문자가 뒤섞인 로케이션 ID. 새 시스템에 올리기 전에 청소하세요. 올린 뒤가 아닙니다.
재고 잔량은 위험한 버킷으로, 운영과 함께 동결해야 합니다. 제 규칙: 입고를 먼저 동결하고, 출고를 다음으로 동결하며, 사이에 실사 시간을 둡니다. 입고를 먼저 동결하는 이유는 도착 화물을 하루 이틀 스테이징에 두는 비용은 싸고 운송업체도 받아주기 때문입니다. 출고를 일찍 동결하면 고객 주문이 안 나가고 전화가 오기 시작합니다.
운송 중 문서와 열린 작업은 모두가 잊는 버킷입니다. 동결 순간, 구 시스템에는 항상 미완성 작업이 남아 있습니다. 반쯤 내린 트레일러, 반쯤 픽한 웨이브, 확정되지 않은 이동. 그대로 옮기면 새 시스템이 마감할 수 없는 반쪽짜리 트랜잭션을 가져오게 됩니다.
제 주말 전환 타임라인은 보통 이렇습니다 — 시간은 교대에 맞게 조정하세요. 금요일 오후 6시: 입고 동결. 이후 도착분은 격리된 스테이징 구역으로 갑니다. 물리적으로 분리하고 별도로 집계한 뒤, go-live 후 새 시스템에서 바로 입고합니다. 금요일 밤 10시: 출고와 내부 이동 동결. 웨이브 릴리스 중단, 보충 중단, 이동 중단. 이 순간부터 레거시 재고 수치는 움직이면 안 됩니다. 진짜 긴급 출하는 수기 전표로 처리하고, 나중에 이중 확인으로 새 시스템에 입력합니다.
이어서 실사 시간, 금요일 밤 10시부터 토요일 새벽 4시까지: 전체 실사, 최소한 A 무버(회전율 상위)의 전수 집계와 B·C의 샘플 집계. 조정분은 먼저 구 시스템에 등록하고 나서 내보냅니다. 프로젝트 전체에서 가장 힘든 시간이면서 가장 값진 시간입니다 — 그날 밤 치노에서 실사를 했다면 14파렛이 그 자리에서 나왔을 겁니다. 토요일 새벽 4시: 최종 스냅샷을 내보내 가져오고, 삼자 대사를 실행합니다 — 레거시 스냅샷, 새 시스템 가져오기, 집계 시트. 세 개가 마지막 1개까지 일치해야 합니다. 토요일 오전 8시: go-live. 구 시스템은 3~6개월간 읽기 전용, 접근은 IT와 재무로 제한. 조기에 폐기하지 마세요. 첫 2주 동안 반드시 누군가가 "옛 세상에서는 이 거래가 어떻게 보였냐"고 물어옵니다.
운송 중 문서에는 자체 규칙이 있습니다. 제한된 접근으로 구 시스템에서 끝내거나, 새 시스템에서 오프닝 작업으로 다시 만드세요. 한 장의 문서를 양쪽 시스템에 걸치지 마세요. 반품이 3개월간 방치된 걸 본 적이 있습니다. QC는 구 시스템에 기록됐고, 적치 확인은 새 시스템에 들어갔거든요.
go-live 후에 데이터가 썩는 세 곳
첫째, 열린 작업. "할당됐지만 픽 안 됨"과 "픽 진행 중" 기록은 동결 전에 닫거나 취소해야 합니다. 반쯤 픽한 웨이브 — 상품은 이미 선반에서 내려왔고, 시스템은 미확정 — 은 옮길 수 없습니다. 손으로 다시 만들어야 합니다. 제 정책: 동결 4시간 전에 모든 열린 작업을 강제 종료. 닫을 수 없는 건 취소. 느려도 됩니다. 뒷마무리는 안 됩니다.
둘째, 시리얼과 로트. 벌크 재고는 합계만 맞으면 되지만, 시리얼·로트 관리 제품은 한 줄씩 맞춰야 합니다. 가져오기 전에 검증 패스를 돌리세요. 시리얼 수와 로트 목록을 레거시 시스템, 새 시스템, 집계 시트 세 곳에서 비교합니다. 제약·식품 창고는 유의하세요 — 유통기한 불일치는 감사 지적 사항이 됩니다.
셋째, 재무 인계. 재고 잔량이 움직이면 재공품과 검수 완료 미청구 상품도 함께 움직입니다. 많은 프로젝트가 창고는 챙기고 재무를 잊는데, 재무는 첫날 맞지 않는 원가로 터집니다. 최소 일주일 전에는 재무를 동결 스케줄에 올리고, 전환 당일에는 현장에 있게 하세요.
전환 계획에 서명하기 전에 물어야 할 질문이 하나 있다면, 이것입니다. 리허설은 어디에 있습니까? 본 전환 전, 조용한 주말에 풀 스케일 섀도 동결을 실행하세요 — 입고 동결, 출고 동결, 실사, 내보내기, 가져오기, 대사, 스톱워치로 시간 재면서. 제가 본 모든 프로젝트 중 리허설을 한 쪽이 안 한 쪽보다 의미 있게 빠르고 침착하게 go-live했습니다. 잃어버린 주말 하나가 go-live 밤 모두의 밤잠을 사줍니다. 도입 파트너에게 리허설이 언제냐고 물어보세요. 대답이 멍한 표정이면, 그게 당신의 진짜 리스크 목록입니다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
