デモは完璧だった。45分間、クリックの一つひとつがピアノの音のように決まった。ERPから注文が流れ込み、ウェーブは定刻にリリースされ、作業員はハンディターミナルの指示に従い、ラベルは印刷され、トレーラーは積み込まれた。営業エンジニアは「ご質問は？」の時間にも笑顔だった。私のオペレーション担当VPはその後、私に向かって言った。「これだ。契約しよう」
6か月後、本番稼働の初週、私は同じ倉庫で、ハンディターミナルが40分間もキューに詰まったために、スーパーバイザーがクリップボードにピッキングを手書きする様子を眺めていた。ウェーブリリースが300件の注文を静かに落としてしまったせいで、トレーラーは予約時刻に間に合わなかった。ホリデーシーズンの返品は2日間も隅に置かれたままだった。誰がその業務の責任者なのか決まっていなかったからだ。その倉庫はインランド・エンパイアにある380,000平方フィートの3PL施設で、ピーク時には1日約4,000件の注文を扱い、WMS契約は年間$210,000だった。デモは何の関係もなかった。
20年間の倉庫運営とシステム選定で、少なくとも十数回のWMSデモを見てきた。どれも見事だった。ここに不都合な真実がある。デモは見事であるためにある。デモのデータセットはクリーンだ。SKUはすべて正しい寸法を持ち、バーコードは読み取り、在庫は一致する。フローはハッピーパスをなぞる。1回のピッキング、1つのカートン、1つのキャリア、破損なし、ショートピックなし、返品なし。そして営業エンジニアはそのクリックを100回も練習している。どのボタンを押し、どの画面を飛ばすか、正確に分かっている。あなたが見ているのはソフトウェアではない。パフォーマンスだ。
本物の概念実証（POC）はパフォーマンスの対極にある。敵対的なものだ。自分の現場の混乱をベンダーに渡し、それに耐えられるか問うのだ。
火傷を負ってから、私は今こう進めている。
第一に、POCは相手のデータではなく自社のデータで回す。2週間分の実際の注文をすべてエクスポートする。ひどいものも含めて全部だ。そして実際のSKUマスターも。寸法が間違った商品やバーコードが欠落した商品も含めて。私が管理してきたすべての倉庫にそういうものは存在する。自社データの投入を渋り、サンドボックスのデータセットを使いたがったら、それが最初のレッドフラグだ。クリーンなデータでしか動かないWMSは、動かないWMSだ。
第二に、POC開始前に受け入れ基準を書き、異常系の分岐に重みを付ける。通常フローは必ず通る。いつも殺されるのは例外処理だ。ショートピック、破損受領、シフト途中で作り直すウェーブリリース、分割出荷、RMAなしの返品。私は受け入れテストの少なくとも60%を例外系の脚本にするよう求める。ベンダーのチームに、キャリアの締め切りまで10分の状態でウェーブリリースを実行させ、その最中に2件の注文をショートピックさせてみる。何が起きるか見るんだ。本物の倉庫の火曜日はそういうものだ。
第三に、期間を区切る。2週間から4週間、ハードストップだ。それ以上長くなると、ベンダーがコンサルタントを常駐させ、カスタムの回避策を作り、それを「成功したPOC」と呼ぶ影の実装になる。求めるのは代表的な切り取りであって、平行宇宙ではない。4週間で自社データによるコア業務の実証ができないなら、その製品は自社には重すぎる。手を引こう。
第四に、インテグレーションの接点を例外なくスコープに入れる。WMSのデモではいつも、アーキテクチャのスライドに「ERP連携」というきれいな小さな箱が描かれている。現実には、そこで実装が死ぬ。POCでは実際の引き渡しを含めなければならない。ERPから降りてくる購買オーダー、ERPへ戻る出荷と在庫、そして梱包ステーションから実際の運賃比較で印刷されるキャリアの送り状ラベル。ERPの品目マスターとWMSでUOM（単位）の表記が異なり、テストの3週目まで誰もマッピングしなかったせいで、本番稼働が11週間遅れた現場を見たことがある。延長コンサルティング費用だけで約$60,000かかった。つなぎ目は早めに試すこと。漏れるのはいつもそこだ。
第五に、ベンダーにAPIドキュメントとエラーログの開示を求める。これは意外に思われる。デモが見せるのはUIだ。オペレーションチームが生きているのはログの中だ。POCの間、何かは必ず失敗する。ラベル印刷ジョブ、キャリアへのAPIコール、ERPとの同期。何が起きたのかをどうやって知るのか、見せてもらう。読めるエラーログはあるか。IT担当者はベンダーのサポートに電話せずにAPIを叩けるか。APIドキュメントをプレミアムな追加オプション扱いするベンダーは、本番稼働後のサポートがどうなるかを正確に物語っている。その通りだと思っていい。
さて、3つの罠だ。これらほど本番稼働を爆発させてきたものはない。
罠その1：異常系フローが一度もテストされなかった。これが一番大きい。受領ドックに雨で濡れて破損した200カートンの入荷が来る。作業員がカートンを落として商品が販売不能になる。ウェーブがリリースされた後に注文がキャンセルされる。私が関わったすべてのポストモーテムで、「テストしていなかった」リストは3ページに及び、すべて例外系だ。デモでは絶対に見せない。ほとんどのPOCでも飛ばす。脚本にするのが気まずいからだ。それでも脚本にしろ。あなたの倉庫は例外系で回っている。POCもそうあるべきだ。
罠その2：データ移行のボリュームがストレステストされなかった。POCでは通常、数百SKUだけ投入して問題なく動く。そして本番では18,000SKU、6か月分の未処理注文、3年分の顧客プロファイルの移行が来て、同期ジョブが9分ではなく9時間かかる。10月の月曜日、ピークシーズンの始まりに、初回在庫アップロードがテーブルをロックして注文がリリースできず、丸一日の出荷スケジュールを逃した施設を見たことがある。POCの間にフルボリュームの負荷テストを回すこと。週末1回分の手間で、最悪の種類のサプライズを避けられる。
罠その3：リファレンス顧客に誰も電話しなかった。ベンダーは輝かしいリファレンスのリストを渡してくるが、購買チームの半分は電話すらしない。全員に電話しろ。ただし「システムに満足していますか？」とは聞くな。具体的に聞くんだ。「例外系の業務フローでカスタマイズが必要だったのは何件ですか」「本番稼働の最初の1か月に何が壊れましたか」「サポートチケットが実際に回答を得るまでどれくらいかかりますか」。2019年、1件のリファレンスコールが7桁ドルの失敗から私を救った。倉庫のマネージャーは、本番稼働が5か月遅れ、ベンダーのコンサルタント2名が1年間常駐する必要があったと教えてくれた。ベンダーの営業チームは同じ顧客を「スムーズな導入」と説明していた。
まとめるとこうだ。POC開始前にベンダーに渡す受け入れチェックリストはこれだ。
私の実際の注文と実際のSKUで回すこと。汚いデータも含めて。ハッピーパスだけでなく例外系をカバーすること。ショートピック、破損、作り直したウェーブ、返品。4週間以内に終わらせること。ERPとの引き渡し、キャリアのラベル、APIドキュメントをスコープに入れること。何か失敗したら読めるエラーログを見せること。フルボリュームで負荷テストすること。そして具体的な質問でリファレンスに電話させてくれること。
ベンダーがこのいずれかに抵抗したら、それは交渉の問題ではない。情報だ。
明日やるなら
今まさにWMSベンダーを評価しているなら、今週ひとつだけやってほしい。先月のいちばんひどい例外を3つ選ぶ。雨に濡れた破損受領、作り直したウェーブ、誰も処理方法を知らなかった返品。それらを次のベンダーとの打ち合わせの前にテスト脚本に書き起こす。営業エンジニアに渡してこう言うんだ。「これをPOCで見せてほしい」。その時の表情が、その製品のすべてを物語る。そしてそれは無料だ。この業界でいちばん安い保険だ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
