まず結論から言おう。WES導入で最大のリスクはソフトウェアではない。誰も本当に承認していない波動ルールで本番稼働してしまうことだ。
ベンダーはシステムを統合し、サーバーにストレステストをかけられる。しかし「1つの注文がどうやってピッキングタスクの束になるのか」という問いには、君たちのチームしか答えられない。その答えに誰も署名しなければ、WES導入はプロジェクトではなく賭けだ。
「波動戦略は現状のまま本番稼働して、あとで微調整すればいい」という一文で死んでいくプロジェクトを、私は数え切れないほど見てきた。率直に言えば、それは流砂の上に建てるようなものだ。住もうとするまでは速く見える。
私自身が経験した話をしよう。2022年、Inland Empireの3PL倉庫、約120,000平方フィート、1日あたり約12,000オーダーを出荷していた——Eコマースの小包と、いくつかの小規模ブランド向け卸の混ざった現場だ。ブループリントの段階で波動ルールを固めた。注文の締め時間で波動を切り分け、各波動は90分分の注文をカバーし、主要顧客は専用の波動に入れる。3回のテストを回し、タスクオーケストレーション、ピッキング経路、ソート先はすべて一致した。導入チームは「これはもう決まりだ」と思っていた。
カットオーバーの3日前、オペレーション担当VPが「波動をキャリア別に切り直そう」と決めた。UPSの注文を1つの波動に、FedExを別の波動に——トレーラーの締め時間に間に合わせやすくするためだ。一文で、3か月分の戦略がごみ箱行き。チームは一晩でルールを組み直した。再テスト？時間がない。そのまま本番稼働へ。
カットオーバー当日、10 a.m.。最初の波動が落ち、WESはほぼ全員のピッカーを同じ通路に送り込んだ。キャリア別に切り直したことで、注文のロケーション分布はすっかり変わり、タスクエンジンの密度仮定はすべて外れていた。ピッカーは通路に列をなしてタスクを待った。ソーターはほぼ2時間、空回りした。午後の締め時間は一つも守れなかった。その夜、私たちはブループリントの波動ルールに戻し、システムが安定したのは翌朝だった。1回の往復で1日分のスループットを丸ごと燃やした——顧客の遅延ペナルティはその上乗せだ。
これには二つの側面がある。技術面：波動ルールを変えれば、WESはタスクオーケストレーション、人員配置、設備ペースをすべて再計算しなければならない——全部が一度に動くのであって、「ちょっとした変更」など存在しない。管理面：なぜカットオーバー3日前にルールが変えられたのか？ブループリントの段階で誰も署名しようとしなかったからだ。VPは「考えさせてくれ」と言い続けた。長年の導入経験から学んだのは、技術的な問題には必ず回避策があるということだ。誰も決断しない問題こそが、プロジェクトを殺す。
だからここに、WESを導入しようとするすべての倉庫に私が渡すチェックリストがある。8つのゲート、それぞれに1本の合否ライン。ラインを越えられなければ先に進むな——先に進むとは、ピークシーズンを希望に賭けることだ。
WES導入ゲート1：ブループリントを凍結し、すべての変更に署名する
プロジェクト全体で最も危険な瞬間は、本番稼働前日の夜、権限のある誰かが波動ルールに「ちょっとした調整」が必要だと決める時だ。ブループリントを凍結せよ。波動戦略、タスク優先度、例外フロー、すべてに署名して封印する。凍結後の変更はすべて正式な変更要求書を通す。口頭の依頼は無効だ。変更を求める者は自分の名前で署名する——この一つのルールだけで、直前の思いつきの九割が消える。
8ゲートWES本番稼働受け入れチェックリスト
| # | ゲート | 「完了」とは |
|---|---|---|
| 1 | ブループリント凍結 | 波動戦略、タスク優先度、例外フローに署名済み。凍結後の変更は正式な変更要求書が必要 |
| 2 | マスターデータ準備 | SKUマスター、ロケーションコード、梱包仕様を登録済み。物理ロケーションをシステムと突き合わせてスポットチェックし、欠落マスターレコードはゼロ |
| 3 | 統合テスト | WMS、ソーター、ピック・トゥ・ライト、プリンターがすべて通信。ネットワーク切断訓練と設備ダウン訓練を実施——メッセージの紛失も重複もなし |
| 4 | 波動・タスク設定 | ブループリント通りにルールを設定。少なくとも3回の実履歴注文を再生し、タスク割当を手で確認 |
| 5 | ストレステスト | 平均量ではなくピークシーズン量でテスト。ピーク時もタスク配分は応答性を保ち、何もクラッシュしない |
| 6 | 並行稼働 | 新旧システムを並行稼働。注文ごとの突き合わせを3日間連続で実施し、差異ゼロで初めてカットオーバーの話ができる |
| 7 | カットオーバー時間帯 | 最も量の少ないシフトを選ぶ。カットオーバーシフトは人員を倍増し、旧システムを温存してすぐロールバックできる状態に保つ |
| 8 | ハイパーケア | 本番稼働後2～4週間。コアチームが現場常駐、課題は重要度別にトリアージし、クリティカルな課題は2時間以内に意思決定者につなぐ |
2つのゲートは特に注意が必要だ。並行稼働は、ほとんどのチームがごまかすところだ——1日回して数件の注文を目視して「OK」と言ってしまう。3日間連続の差異ゼロがラインだ。遅く感じるが、1回のロールバックより安い。そしてハイパーケアは「ベンダーのサポートホットライン」ではない。自社のコアチームが物理的に建物にいて、判断を下せる権限を持っていることだ。ホットラインには、午前2時に波動を切り直すかどうかは決められない。シフトリーダーなら決められる——本番稼働前にその権限を文書で与えておけば。
一斉切替か、倉庫ごとか？二つの側面
誰も話したがらないトレードオフがここにある。一斉切替はリスクを集中させる。失敗すれば建物全体が止まる。見返りは痛みが短いことだ——チームは一度だけ集中すればよく、2つのプロセス体系を並行して維持する必要がない。1棟の建物で、日量が管理可能で、オペレーションがシンプルな現場に向いている。
倉庫ごとの段階切替はリスクを分散させる。1棟の失敗が他に波及せず、1棟目で得た教訓はそのまま2棟目に転用できる。代償は長いスケジュール、重複期間の管理工数倍増、そして倉庫間移送のための特別なロジックだ。複数拠点のネットワーク、または1棟で止まる日が骨身に響くほどの量を持つ現場に向いている。
私の判断：1棟なら一度で切れ、長引かせるな。複数棟なら1棟ずつ切れ、欲張るな。最悪のパターンは「名前だけ段階切りで、全棟が同じ締め切りを追いかける」——両方のコストを払って、どちらのメリットも得られない。
最後に一つ、逆説的な見解を。本番稼働で最大のリスクはソフトウェアのバグだと思っている人が多い。率直に言おう、バグには必ず回避策がある。プロジェクトを殺すのは、誰も本当に決断していない波動ルールで本番稼働することだ。ルールが固まっていれば、平凡なシステムでも普通に動く。ルールがなければ、どんなに美しい設定も当てずっぽうにすぎない。
だから、どのWESベンダーを選ぶかはもう聞かないでくれ。まず自分たちにこう問いかけなさい。波動ルールの文書に署名する気のある人はいるか？いなければ、ベンダーは誰でも同じだ。
Lao Mi（サプライチェーンのベテラン（20年））著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
