パイロットは成功した。展開は死んだ。10回中9回は、原因は3つに集約される。
この映画はもう何度も見てきた。2023年、インディアナ州プレーンフィールド郊外の3PLが、180,000平方フィートの施設でAI駆動のピックパス最適化ツールをパイロット導入するのを手伝った。6週間後には効率改善の成果に顧客が「いつ全拠点で稼働できるか」と聞いてきた。10倉庫だ、と言う。だがオハイオ州の二番目の倉庫で、プロジェクトは完全に停滞した。そこのピッカーたちはシステムの経路提案をまるごと無視した。三番目の拠点は始まることなく、契約書の展開条項は埃をかぶったままになった。そのプロジェクトが教えてくれたことを、今はすべての顧客に伝えている。パイロットが証明するのは、技術が「動く」こと。展開が試すのは、それが「他人の建物で生き残れる」かどうかだ。
死因その1：パイロットのデータは温室育ちだった
パイロットのデータは、決して自然なものではない。自分のパイロットを思い返してみよう。ベンダーのエンジニアが数週間も現場に常駐しなかったか？誰かが例外オーダーを1件ずつ手作業でラベル付けしなかったか？ピッカーたちに「システムの指示に従い、自己流はやめろ」と明示しなかったか？人は見られていると知れば振る舞いが変わる。データがきれいだったのは、現場全体が「モデルハウス」のようにお行儀よく振る舞っていたからだ。
その過保護なデータでモデルは学習した。そして二番目の倉庫には、そんな手厚いケアはない。スキャンは抜け、返品理由は適当に選ばれ、スロット変更は2日間も記録されない。同じモデル、違う夕食。そして劣化はゆっくり進む。1か月目は問題なく見え、3か月目には推奨がずれ始め、作業員は信頼しなくなり、不信がデータをさらに悪化させる。手遅れになるまで誰も気づかない死のスパイラルだ。
だから展開の第一歩は、すべての新規拠点でのデータベースライン監査だ。誰かを2〜4週間そこに住まわせ、何も変えない。観察するだけだ。スキャン遵守率、マスタデータの完全性、例外処理の速さ。パイロット倉庫のデータ品質に届かない拠点があれば、まずデータを直し、本稼働は後回しにする。この時間とお金は削れない。削れば10倍の代償を払うことになる。
死因その2：モデルは二番目の倉庫でホームシックになる
どちらも「倉庫」と呼ばれる建物が、中身はまったく別の生き物であることは珍しくない。プレーンフィールドのパイロットは、SKUプロファイルが集中したフルケースピッキングで、移動経路も固定だった。オハイオの拠点は小口ECを扱い、SKU数は桁違い、ウェーブのロジックもまったく違った。モデルが「学習」したことは、ほぼ無価値だった。
違いは3つの層に積み重なる。1つ目は商品と受注の構成。フルケース対バラ、法人向け対直販——モデルの前提が足元から変わる。2つ目はプロセス。2拠点がどちらも「ピッキング」と呼んでいても、片方はput wallに集めて再検証し、もう片方はトートに直接ピックしている。手順が変われば、モデルの提案アクションは現実と対応しなくなる。3つ目で最も厄介なのは、システムのバージョンだ。WMSのバージョンが2リリース違うだけで、同じ「ピック完了」イベントでもフィールドの意味やタイムスタンプのロジックが異なる。インターフェースをつなげば、データはズレたまま届く。
今の私のルール。本稼働前の新規拠点では、必ずパイロット拠点との差異レジスターを作成する。商品プロファイル、受注タイプ、主要プロセス手順、システムバージョンとインターフェースフィールドを1項目ずつ。差が大きいところは、モデルが来る前にプロセスを直し、データ定義を揃える。モデルがこちらの混乱に適応してくれるなどと期待してはいけない。無理だ。そして鉄則が1つ。展開期間中はWMSとインターフェースのバージョンアップを凍結する。最も理不尽な失敗は、展開中にITチームがWMSをアップグレードしたケースだ。1つのフィールド定義が変わり、稼働中3拠点のモデルが同時に壊れた。凍結とはアップグレードしないことではない。アップグレードするたびに、まずテスト環境でモデルの回帰検証を通すということだ。
新規拠点には必ずシャドー期間も設ける。システムは推奨を出すが、判断は任せない。作業員はいつも通りに働く。2〜4週間の比較で見るのは、システムの提案とベテランの判断がどこで食い違うか、そしてその差がデータの問題なのか、モデルがこの建物を本当に理解していない証拠なのかだ。シャドーのデータこそ、本格移行の判断の唯一の正当な根拠になる。勘で決めてはいけない。
死因その3：誰も使いたがらず、数字も合わない
パイロット期間中は、経営層が旗を振り、ベンダーが常駐し、作業員も好奇心を持っていた。展開期間はどうか。新拠点のマネージャーは「これは本社のプロジェクトで、俺のボーナスじゃない」と考え、作業員は「これのせいでスキャンが2回になるのに、なんでやるんだ」と考える。AIの提案と20年ベテランの勘がぶつかれば、ベテランが勝つ。AIの味方は誰もいないからだ。
技術と一緒に、組織の足場も届けなければならない。各展開拠点には指名されたビジネスオーナーが必要だ。ビジネス、だ。ITではない。その人の四半期目標に「AI展開を本稼働させ、パイロットで測定した水準で運用する」を入れなければならない。人はボーナスに連動するもののために戦う。それが人間の本性だ。本性と戦ってはいけない。
そしてパイロットチームを解散させてはいけない。よく見る最大の間違い。パイロットが成功し、ベンダーのスタッフは帰り、社内プロジェクトチームは解散し、各拠点は複製のやり方を自分たちで考えるしかなくなる。代わりに、パイロットチームを複製チームに転換する。差異レジスター、データベースライン基準、シャドー運用の手順書を持って、拠点を1つずつ回る。最初の3拠点はフルサポート、4拠点目からはレビューのみ、7拠点目の後は手を離す。このペースを急いではいけない。
ROIの計算も、展開「後」ではなく展開「前」に財務部門と合意しておかなければならない。パイロットのROIはたいてい「理想の計算」だ。人件費削減は数え、導入コストは無視し、誤った推奨によるやり直しは無視し、シャドー期間の二重運用の人件費も無視する。展開期に財務部門が全部足し戻せば、数字は薄く見えて、プロジェクトは疑問視される。先に自分で正直な計算をすべきだ。導入、データ修復、悪い推奨による誤ピックのコスト——全部入りで、拠点あたりに償却する。薄いが本物で再現可能なROIは、太いが再現不可能なROIに毎回勝つ。財務部門と向き合うときは、ベンダーのスライドではなく、自社パイロットの測定値を使おう。
そのパイロットを次の建物にコピーする前に、このチェックリストを歩いてみよう。拠点のデータベースラインは満たされているか。差異レジスターは記入済みか。システムバージョンは凍結されているか。シャドー期間は予定されているか。展開を目標に入れたビジネスオーナーは指名されているか。複製チームは無傷か。ROIの算出方法は財務部門と合意済みか。7つすべてに「はい」と答えられなければ、まだ何もインストールしてはいけない。パイロットに1回勝つのは運だ。その勝利を10回繰り返すのが、本当の腕だ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
