2024年の秋、私はカリフォルニア州ミラロマにあるEC倉庫のWMSデモに立ち会った。営業担当は丸1時間しゃべり続けた。インテリジェントなウェーブ最適化、デジタルツイン、何でもありだ。オーナーはうなずき、ITマネージャーはメモを3ページ埋めた。
私は手を挙げた。「止めてください。重要顧客の緊急オーダーが今日中に出荷しなければなりません。今リリースしたウェーブに追加してください。ライブでお願いします。」
デモ担当者は3秒間固まり、メニューを掘り始め、2分間クリックを続け、最後に微笑んだ。「緊急オーダーにはもちろん対応しています。今日のデモ環境では設定されていないだけです。」
5秒間の沈黙。オーナーはノートを閉じた。
この場面は数え切れないほど見てきた。スライドでは眩しいほど輝き、実際の倉庫シナリオが出た瞬間に無力になる。長年、十数件のWMS選定に立ち会って、私はひとつの厳しい教訓にたどり着いた。機能チェックリストはベンダーのゲームであり、すべてのチェックボックスには最初からチェックが入っている。本物のシナリオを渡してライブで実演させれば、それはあなたのゲームだ。10社中9社は3つ目のシナリオで汗をかき始める。
私の定番のやり方はこうだ。デモの1週間前に、自社の実運用から書いた5つのシナリオをベンダーに送る。データはマスク、ロジックは本物。デモ当日はスライド禁止、すべてシステム上でライブにやる。「この機能はありますか」とは聞かない。マウスクリックを数え、何画面を飛び回るかを見て、例外が本当にアラートを出すかを確かめる。WMSは1日に何千回も触られる。1タスクあたり3クリック余分にかかれば、年間で数十万回の無駄な操作になる。
「緊急オーダーをライブのウェーブに入れろ。今すぐだ。」
シナリオはシンプルだ。ウェーブはリリース済み、ピッカーはRFガンを持って通路を歩き回っている。そこにカスタマーサービスから電話だ。重要顧客のオーダーは今日中に出荷しなければならない、今のウェーブにねじ込め、と。
見るべき3つのポイント。リリース済みウェーブにオーダーを差し込めるか。新しいタスクがピッカーのハンディにリアルタイムで届くか、それとも次のウェーブまで待たされるか。半分ピックしたウェーブが台無しにならないか。
典型的な失敗回答：「緊急オーダーには対応していますが、今のウェーブを閉じて作り直す必要があります。」即失格だ。実際の倉庫ではウェーブをそう簡単に閉じられない。ピークシーズン、1日に数千オーダーをさばく中でウェーブを閉じれば、ピックライン全体が30分止まる。もっと陰湿な失敗もある。オーダーの差し込みはうまくいくのに、スーパーバイザーが無線で一人ずつ声をかけるまで、ピッカーのガンに何も表示されない。彼らの「リアルタイム」はスライドの中にしかないという証拠だ。
返品のミックスパレットは、システムが死ぬ場所だ
出庫ではどのWMSも美しく見える。返品は嘘発見器だ。シナリオ：ミックスパレットが返品されてくる。再販可能なもの、包装が潰れて廃棄行きのもの、誤出荷で返品と一緒に返ってきた2カートン。
見るべきは：返品の受領でQCタスクがワンステップで自動生成されるか。QCの「廃棄」判定が、再入力なしで廃棄フローと在庫調整を発動できるか。誤出荷のカートンが元の出庫オーダーに紐づき、代替出荷を立ち上げられるか。
多くのシステムの返品モジュールは「返品を入力できます」に毛が生えた程度だ。QCは紙、廃棄はスプレッドシートで集計。2023年、フォンタナの3PLがピーク中に返品エリアを丸2週間ため込み続けるのを見た。ようやく片付けたとき、大半はそのまま廃棄行きだった。オーナーはパレットが次々と廃棄されるのを眺めながら、顔を青くしていた。返品処理に3画面と「この品を廃棄」と書く自由記述のメモ欄が必要なデモは失格だ。返品係はそのメモ欄を決して埋めない。永遠に空白のままだ。
スロット移動と倉庫間移動：ニセのマルチ倉庫を暴く
ピークシーズンの前、売れ筋SKUは上段からゴールデンピックゾーンに降ろされる。シナリオ1：200ロケーション分の移動タスクを一括生成する。システムは一発でできるか、移動中の在庫は「移動中」と表示されるか、ただ凍結されるだけか、移動タスクはピッカーの作業ゾーンで自動割当されるか。
シナリオ2がキラーだ。倉庫Aが欠品、倉庫Bに在庫がある。BからAへ200ケース移動する。マルチ倉庫対応をうたうシステムの多くは、これをBの出庫オーダー＋Aの入庫オーダーで処理し、その間1日か2日、在庫は空中分解する。帳簿在庫と実在庫は永遠に合わない。私はまさにここで死んだプロジェクトを経験した。月末差異が大きすぎて財務が承認を拒否し、チームは3日間サイクルカウントに追われた。
本物のマルチ倉庫アーキテクチャは、これをひとつの書類フローで移動し、移動中の在庫が端から端まで見える。デモでは数えるだけだ。画面がいくつか、書類番号がいくつか、互いにリンクしているか。リンクしていない書類が2つを超えたら、それはニセのマルチ倉庫だ。
キーボードを悪役に渡せ
最後のシナリオは私のお気に入りだ。ピッカー権限だけのアカウントを作り、在庫調整の転記、原価レポートの閲覧、確定済み出庫オーダーの削除を試みる。
確認すべき3点。権限はボタンやフィールドのレベルまで降りているか。権限外の操作はエラーで止まるか、それとも黙って通されるか。誰が何をいつ試みたかを記録する監査ログがあるか。
定番のかわし方は「権限は完全に設定可能です」。「設定可能」と「存在する」は別物だ。ひとつライブで設定させろ、今すぐだ。できなければ存在しない。私が見た最悪は、ロールが管理者とオペレーターの2つだけ。オペレーターはオーダーを削除し、在庫を調整し、すべての原価レポートを読めた。営業は肩をすくめた。「小さい会社にはそこまで細かくいりません。」今日は小さい会社だ。3年後、倉庫が4つになったら？ その時点でシステムを移行するコストは、泣きたくなるほど高い。
5つのシナリオを終えれば、候補の70から80パーセントは消えている。残った相手と価格、スケジュール、サービスを交渉しろ。土台は検証済みだ、大敗はしない。
だが正直に言うと、どのベンダーを選ぶかより大事なことがある。そしてそれは常に見落とされている。この5つのシナリオをそもそも誰が書いたのか、ということだ。
何度も見てきた。ITが選定を主導し、テストはAPI、アーキテクチャ、シングルサインオンをカバーし、現場の本当の痛みはひとつも入っていない。ゴーライブの日、ITは承認する。ピッカーは通路で呪っている。緊急オーダーは差し込めない、返品は紙運用、移動はスプレッドシート。ITが聞いた質問は、現場ではひとつも意味がなかった。
だから最後に残しておきたい問いがある。次にあなたの会社がWMSを選ぶとき、試験を作るのは誰か。問いを作る者が、買うシステムを決めるのだ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
