WMS 데모에 대한 불편한 진실부터 말하겠다. 데모는 연극이다. 리허설하고, 각본 짜고, 안무까지 짠 연극이다. 그리고 대부분의 구매자는 극장을 나와 계약서에 서명한 뒤, 프로젝터 화면에서는 그렇게 쉬워 보이던 소프트웨어가 왜 자기 창고에서는 무너지는지 이해하지 못한 채 1년을 보낸다.
나는 2019년 로스앤젤레스 외곽의 가정용품 유통업체에서 이 광경을 목격했다. 데모는 완벽했다 — 바코드 스캔, 웨이브가 순식간에 릴리즈되고, 피킹 경로는 교과서 도표처럼 최적화됐다. 사장은 그 자리에서 계약했다. 9개월 후, 고라이브 주에 창고에는 6,000건의 백오더가 쌓였고, 사장은 도크 건너편에서 나에게 소리쳤다. "데모에서는 잘 됐잖아!"
당연히 그랬다. 그게 목적이었으니까.
조심해야 할 데모 트릭 세 가지
첫째, 정제된 데이터. 데모 데이터베이스에는 잘해봐야 500개의 완벽한 SKU가 들어 있다 — 모든 품목에 바코드, 모든 로트 깨끗, 모든 슬롯 배정 완료. 당신의 창고에는 20,000개의 SKU가 있다. 바코드가 누락된 것, 찌그러진 카톤, 한 파렛에 세 개 로트가 섞인 것까지 포함해서 말이다. 소프트웨어가 빨라 보이는 이유는 더러운 데이터를 만나본 적이 없기 때문이다.
둘째, 해피 패스. 영업 데모는 항상 황금 루트를 걷는다. 입고, 적치, 피킹, 포장, 출고. 반품 처리를 물으면 "설정 가능합니다"라는 답이 돌아온다. 시리얼 번호 추적성을 물으면 "지원합니다"라는 답이 돌아온다. 이 두 단어 — 설정 가능, 지원 — 은 구현 단계에서 커스텀 개발 두 번째 청구서로 번역되는 것이 일상이다. 당신의 실제 반품 플로우를 그 자리에서 라이브로 돌려달라고 해보라. 대부분 못 한다.
셋째, 잘못된 오퍼레이터. 데모를 진행하는 사람은 대개 눈을 감고도 시스템을 조작할 수 있는 프리세일즈 엔지니어나 시니어 구현 컨설턴트다. 당신의 프로젝트를 실제 구현할 팀은 다른 사람들이다 — 아마 교육받은 지 세 달 된 컨설턴트들일 수도 있다. 데모가 얼마나 매끄러웠는지는 당신의 구현이 얼마나 좋을지와 거의 무관하다.
벤더에게서 대본을 빼앗아라
진짜 PoC의 원칙은 하나뿐이다. 구매자가 시나리오를 쓴다는 것.
벤더가 무엇이든 만지기 전에 당신이 먼저 쓴다. 약 열 개 시나리오로 제한하고, 전부 지난 3개월간 당신의 창고가 실제로 처리한 주문에서 가져온다. 내가 권장하는 목록: 표준 입고와 적치, 파손 있는 풀파렛 입고, 긴급 주문 웨이브 삽입, 쇼트픽 재할당, 시리얼 아이템 반품, 파손 파렛 보충, 순환 재고 조사 차이 조정, 재라벨링. 실제 데이터도 첨부한다 — 못생긴 것을 포함한 실제 SKU 최소 2,000개와 실제 한 주 분량의 주문 물량을.
그리고 규칙을 정한다. 벤더 사전 로드 데이터 금지, 당신의 데이터를 그 자리에서 임포트할 것. 오퍼레이터는 당신의 창고 슈퍼바이저여야지, 마우스를 잡는 그들의 컨설턴트가 아니야. 모든 시나리오는 시간 측정.
이 "도움 금지" 규칙이 가장 중요하다. 나는 벤더 컨설턴트가 오퍼레이터 뒤에 서서 매 클릭을 중계하며 사실상 마우스를 대신 움직여주는 PoC를 본 적이 있다. 그건 컨설턴트를 테스트하는 것이지 소프트웨어를 테스트하는 게 아니다. 기술에 가장 약한 슈퍼바이저를 의자에 앉혀라. 세션 중에 배울 수 있으면 그 시스템은 쓸 만하다.
합격선을 정량화하거나, 하지 마라
PoC가 끝나면 회의실에 "어땠어요?"라고 절대 묻지 마라. 감정은 지금까지 발명된 최악의 인수 기준이다.
PoC 시나리오 1페이지에 합격 기준을 쓰고 벤더에게 서명하게 해라. 예를 들면: 벤더 도움 없이 8개 중 최소 7개 시나리오를 엔드투엔드로 완료할 것. 500건 웨이브 릴리즈를 2분 이내에 완료할 것. 순환 재고 조사 조정은 5클릭 이내. 당신의 슈퍼바이저가 2시간 동안 오류 없이 독립적으로 조작할 것.
선을 못 넘으면? 선택지는 두 가지다. 벤더가 커스텀 개발이 필요하다고 인정하고 범위와 가격을 문서화하거나, 탈락이다. 두려워해야 할 문구는 "검토하겠습니다" — "지금은 안 됩니다"라는 뜻이다.
특히 지적해야 할 트랩이 하나 있다. 가이드 투어다. 일부 벤더는 당신의 시나리오를 대신 돌려준다 — 그들의 컨설턴트가 운전하고 당신 사람들은 구경만 — 그리고 그걸 PoC라고 부른다. 그건 당신 로고를 붙인 데모지 개념 증명이 아니다. 당신의 팀보다 벤더의 손이 키보드에 더 오래 있으면 세션을 멈추고 규칙을 리셋해라. 구매자가 소프트웨어를 한 번도 만지지 않은 PoC가 증명하는 것은 벤더가 자기 제품을 조작할 수 있다는, 처음부터 의심의 여지가 없었던 사실뿐이다.
하나 더: IT 리드를 PoC에 데려가서 통합 레이어를 평가하게 해라. 당신의 WMS는 ERP, TMS, 이커머스 플랫폼과 대화할 것이다. 반나절이면 API 문서가 진짜인지, 샌드박스 환경이 있는지 알 수 있다. API 레이트 리밋도 물어봐라 — 시간당 수백 콜로 제한하는 시스템은 주문 물량이 급증하는 순간 질식한다. 인터페이스가 썩은 시스템은 당신의 구현을 바닥으로 끌어내릴 것이다.
계약 전 세 가지 질문
PoC를 통과했다. 계약 전에 이 세 가지 답변을 계약 별첨으로 문서화해라.
하나: PoC를 통과한 시나리오마다, 고라이브에서 작동하지 않으면 커스텀 개발 비용은 누가 내는가? 많은 계약이 구현을 "견적"으로 제시하고 초과분은 별도 청구한다. 통과한 시나리오 목록을 인수 기준으로 첨부해라 — 작동하지 않으면 그건 벤더의 문제다.
둘: 구현 팀원은 정확히 누구인가? 리드 컨설턴트 이름을 계약서에 명기하고, 교체에는 당신의 승인이 필요하다는 조항을 넣어라. "최고의 팀"이라는 구두 약속은 가치가 없다.
셋: 고라이브 후 첫 90일간의 응답 시간. 뭔가는 반드시 고장 난다 — 문제는 얼마나 빨리 나타나는가다. 문서화해라. 심각한 장애는 4시간 이내 원격 대응, 24시간 이내 현장 출동.
그 가정용품 고객은? 시스템을 갈아탔다. 두 번째 선정 라운드에서 나는 그들에게 실제 데이터와 200건 이상의 실제 주문으로 3주간 PoC를 돌리게 했다. 새 시스템 고라이브 당일, 창고는 2시간 잔업으로 마감했다. 사장은 나중에 처음부터 그렇게 했으면 좋았을 거라고 말했다.
PoC는 서명 전에 벤더에게 진짜 일을 시킬 수 있는 유일한 순간이다. 낭비하지 마라.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
