WMS go-live에 대해 아무도 말해주지 않는 것이 있습니다. 문제는 소프트웨어가 아닙니다. 첫 번째 주간입니다.
시스템이 모든 테스트를 통과하고, 모든 인터페이스가 녹색으로 돌아오고, 전환 계획이 40페이지에 달하는 go-live를 본 적이 있습니다. 그런데도 첫날 오전 9시에는 현장에 불이 났습니다. 새로운 프로세스, 새로운 로케이션 코드, 새로운 단말기가 같은 아침에 한꺼번에 착륙했고, 이를 마주한 사람들은 3주 전 2시간 교육에서 새 흐름을 배운 사람들입니다. 워룸은 그 혼란과 운송사 마감 미준수 사이에 서 있는 유일한 것입니다. 하지만 제가 본 워룸 대부분은 그냥 전화 받으며 앉아 있는 몇 사람뿐이었습니다. 불은 어쨌든 타오릅니다. 첫 주간이 실제로 어떻게 될지 아무도 미리 정하지 않았기 때문입니다.
보장된 세 가지 화재
첫 번째 화재는 마스터 데이터입니다. 스캔되지 않는 바코드, 맞지 않는 로케이션 코드, 틀린 측정 단위 환산. 2023년에 저는 캘리포니아 온타리오의 120,000평방피트 3PL 창고 go-live를 지원했습니다. 마감일을 맞추기 위해 팀은 200개가 넘는 저회전 SKU의 바코드 등록을 "go-live 이후"로 미뤘습니다. 첫 주간의 매 아침, 스캔할 바코드가 없다는 이유로 십여 건의 웨이브 주문이 검수 스테이션에서 막혔고, 검수 담당자들은 카톤을 손으로 뒤져야 했습니다. 기술적 난이도 제로, 순전히 불완전한 사전 작업 — 그러면서도 그 주 가장 지긋지긋한 화재였습니다. 당신을 죽이지는 않습니다. 그냥 매일같이 타오를 뿐입니다.
두 번째 화재는 인터페이스입니다. WMS에서 OMS로, 운송사로, EDI로 — 첫 주간에는 뭔가가 반드시 말썽을 부립니다. 주문이 내려오지 않고, 상태 업데이트가 유실되고, 웨이브 릴리스가 중간에 멈춥니다. 골치 아픈 점은 현장이 이런 종류의 문제를 볼 수 없다는 것입니다. 피커가 아는 건 "피킹할 주문이 없다"는 것뿐입니다. 워룸이 인터페이스 큐를 지켜보지 않으면, 밀린 물량이 이미 수천 건이 된 두 시간 후에야 알게 됩니다. 그리고 핵심은 — 많은 경우 WMS 탓이 전혀 아니라는 것입니다. 상대방이 필드를 하나 바꾸고 알려주는 걸 깜빡한 겁니다. 그래서 워룸에는 로그를 읽을 줄 알고, 한 번의 전화로 상대방 엔지니어를 연결할 수 있는 사람이 필요합니다.
세 번째 화재는 사람입니다. 새 흐름이 어색하게 느껴지니 작업자들이 조용히 시스템을 우회합니다. 먼저 종이로 피킹하고 나중에 입력하고, 손으로 쓰는 게 더 빠르니까 RF 건을 건너뜁니다. 이런 섀도우 프로세스를 첫 주간에 잡지 못하면 영원히 못 잡습니다. 데이터가 한 번 오염되면 재고 정확도는 절대 회복되지 않습니다. go-live 3개월 후에도 재고 조정을 계속하던 프로젝트 중 10개 중 9개는 첫 주간에 문제를 묻어뒀습니다. 저의 워룸 규칙: 시스템 우회는 첫 번째면 당일 면담. 두 번째면 바로 창고 관리자에게 보고합니다. 가혹하게 들리죠. 데이터를 지키는 유일한 방법입니다.
워룸은 위치보다 누가 앉느냐가 중요합니다
가장 잘 작동하는 구성은 세 진영에서 각 1~2명씩입니다. 오퍼레이션에서는 창고 슈퍼바이저 — 프로세스를 알고 "이 주문은 수동으로 출고할 수 있다"는 판단을 내릴 수 있는 사람. IT에서는 인터페이스와 인프라 담당 — 로그를 읽고 티켓 없이 서비스를 재시작할 수 있는 사람. 구축사에서는 구성을 아는 컨설턴트 — 잘못된 파라미터를 그 자리에서 고칠 수 있는 사람. 셋 다 필수입니다. 오퍼레이션이 없으면 이슈를 분류할 수 없습니다. IT가 없으면 인터페이스 문제에 멍하니 바라보기만 합니다. 구축사가 없으면 설정 하나에 반나절이 날아갑니다.
교대는 3교대가 아니라 2교대로 돕니다. 이른 교대가 웨이브 릴리스부터 저녁 피크까지 커버하고, 늦은 교대가 야간 마감을 커버하며, 인수인계를 위해 2시간을 겹칩니다. 스케줄은 go-live 3일 전에 확정하고, 인쇄해서 벽에 붙입니다. 휴가를 쓰고 싶으면 스스로 대타를 구합니다. "전화 지원"은 인정되지 않습니다. 첫 주간에 방 안에 있는 사람과 전화 너머에 있는 사람은 화력 수준이 완전히 다릅니다.
가장 중요한 것: 의사결정자를 한 명 지명하세요. 보통은 비즈니스 측 프로젝트 매니저입니다. 워룸의 가장 치명적인 병은 사람이 셋인데 결정이 없는 상태입니다. P1이 터지면 의사결정자는 한 문장으로 말합니다 — 라인을 멈추고 고칠지, 우회해서 출고를 지킬지. 그 사람은 출고를 중단할 권한과 "2시간은 수동으로 간다"고 말할 권한을 가져야 합니다. 권한이 모호한 워룸은, 명확한 의사결정자가 한 문장으로 끝낼 일을 두 시간 동안 토론합니다.
대시보드 숫자는 여섯 개. 그 이상은 안 됩니다.
첫 주간 대시보드는 간결해야 합니다. 제가 보는 숫자는 여섯 개입니다. 미릴리스 주문 밀림, 웨이브 릴리스 성공률, 가동 중인 RF 단말기 수, 인터페이스 큐 깊이와 최장 대기 시간, 검수 예외율, 당일 정시 출고율. 각각에 레드라인을 둡니다 — 예컨대 15분간 움직임 없는 200건 초과 인터페이스 큐는 보고 없이 자동으로 P1으로 격상됩니다. 세 진영은 go-live 전에 레드라인에 합의하고, 종이에 써서 벽에 붙이며, 그 주 내내 건드리지 않습니다. 매일 바뀌는 레드라인은 레드라인이 아닙니다.
P1/P2/P3 심각도 등급은 첫날부터 존재해야 하고, 정의는 명확하고 구체적이어야 합니다. P1: 출고할 수 없거나, 데이터가 오염된다. P2: 처리량이 절반 이하로 떨어지지만 출고는 된다. P3: 출고에 영향 없는 사용성 이슈. 심각도가 명확하지 않은 워룸에서는 모든 것이 "어느 정도 급함"이 되어 아무것도 우선순위가 정해지지 않습니다. 철칙 하나 더: P1 발견부터 담당자가 지정되기까지 15분을 넘기지 않습니다. 초과하면 의사결정자의 전화가 바로 울립니다.
롤백 플랜은 창피한 것이 아닙니다. 보험입니다.
go-live 전에 두 가지를 준비해야 합니다. 첫째, 종이 백업 주문 양식과 수동 프로세스. 시스템이 정말로 다운돼도 창고는 멈추지 않습니다. 종이로 피킹하고, 손으로 기록하고, 나중에 입력합니다. 양식은 미리 인쇄해서 현장에 둡니다 — 이미 망가진 상황에서 프린터를 찾으러 다니지 마세요. 수동 흐름은 최소 한 번 리허설합니다. 시프트 리드는 종이 프로세스 전체를 직접 손으로 걸어봐야 합니다. 그렇지 않으면 안 좋은 날에, 손에 쥔 종이를 어떻게 써야 할지조차 모릅니다.
둘째, 데이터 복구 시점. 매일 밤 전체 백업에, 중요한 마스터 데이터 변경 전에는 별도 백업. 롤백이란 시스템을 제거하는 게 아닙니다 — "오늘의 구성 변경이 뭔가를 망가뜨렸고, 어젯밤 상태로 돌아갈 수 있다"는 뜻입니다. 솔직히 말하면, 첫 주간에 롤백 플랜을 실제로 쓰는 프로젝트는 드뭅니다. 하지만 있느냐 없느냐가 팀 심리를 완전히 바꿉니다. 플랜이 있는 팀은 구성을 만집니다. 플랜이 없는 팀은 파라미터 하나도 바꾸지 않고, P2 문제가 P1이 될 때까지 질질 끕니다.
정리하면: go-live 주간 전에 P1/P2/P3 정의와 에스컬레이션 연락처 목록을 인쇄해 워룸 벽에 붙이고, 그 옆에 종이 백업 양식 뭉치를 놓습니다. 첫 주간 마지막 날에는 세 가지 질문으로 회고를 합니다. 어떤 화재가 가장 뜨거웠는지, 어떤 지표가 가장 먼저 알람을 울렸는지, 어떤 수동 우회책을 영구 시스템 프로세스로 만들어야 하는지. 그리고 워룸을 해산합니다 — 계속 열어두는 건 시스템을 아직 믿지 못한다는 뜻입니다.
마지막으로 질문 하나. 첫날 아침에 구 시스템을 직접 내려야 한다면 — 감당하시겠습니까? 아니라면 당신의 롤백 플랜은 준비가 안 된 겁니다. 지금 고치세요. 아직 시간이 있습니다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
