小規模倉庫のAI拡大：最初のパイロットが成功した後に2番目のプロジェクトを選ぶ

小規模倉庫におけるAI拡大の2番目のプロジェクトを誤って選ぶことは、最初のパイロットが失敗することよりも高くつく。最初のパイロットが失敗すれば、失うのは1つの実験だけだ。2番目の選択を誤れば、その後に続くあらゆる新しいシステムに対する現場の信頼を失うことになる。小規模倉庫が最初のパイロットを成功させ、2番目で欲張り、現場のクルーが二度とツールを信じなくなった例を私は見てきた。率直に言えば、2番目のプロジェクトはご褒美ではない。節度を学んだかどうかを試すものだ。

これが、営業資料には決して載らないトレードオフだ。一方で、2番目のプロジェクトはこれまでに得られる最も安い拡大だ。データはすでに流れており、人々はすでに最初のツールを知っており、隣の部門を1つ加えることは、別の場所でゼロから始めるより安い。他方で、それはリスクの増幅器だ。最初のパイロットは1つのチームにしか触れなかったが、共有部門での2番目のプロジェクトは全員に触れる。だから結論を先に言おう。部門をちょうど1つ選び、具体的問題をちょうど1つ解決し、3つ目について話す前に3か月間安定して運用することだ。欲張りは、小規模倉庫のAI導入において最も高くつく習慣である。

私はこれを、他人がその代償を払うのを見て学んだ。2024年3月、カリフォルニア州オンタリオ郊外の小さな自動車部品倉庫では、2シフトで40人強が働き、素晴らしい最初のパイロットを実施した。AIは受入チームが納品書類と現物を照合するのを支援し、受入エラーは3か月で週7件から週1件に減った。その勢いに乗ったオーナーは、2番目のプロジェクトを倉庫全体の循環棚卸予測とした。システムが各ロケーションに何をいつ数えるかを指示するのだ。自然な次のステップに聞こえた。実際には、循環棚卸は建物全体に触れる。正確なロケーション・データ、正確な在庫残高、正確なマスタデータが必要で、そのいずれかが間違っていれば予測も間違う。稼働開始から2週目、システムは動きの遅いデッドストックを3日連続で優先カウントとしてフラグした。夜勤の作業員2人が、記録がすでに正しい品目を数えるのに6時間を費やした。3週目までには、カウントチームはこっそり経験に基づくカウント選びに戻り、システムを無視するようになっていた。損害はソフトウェア料金ではなかった。信頼だった。オーナーは後に自ら認めた。2番目の選択は最も痛い問題ではなく、最も印象的に聞こえるものだった、と。

この失敗が私の選定ルールになった。2番目のプロジェクトは直感で選んではならず、ベンダーのデモで最も派手なページから選んでもならない。3つの厳しいテストに合格しなければならない。データはすでにそこにあるか、人の手による修正なしに毎日生成されているか。誤った答えのコストは何か。余分な歩行か、それとも誤出荷とライン停止か。そして現場は本当にそれを望んでいるか。そのチームのリーダーが自らこの痛みを提起したのか、それとも経営層が、求めたこともないクルーにツールを押し付けているのか。その3つのうち1つでも不合格なら、その案は棚上げすること。大きくて印象的な2番目のプロジェクトより、小さくて少々退屈な2番目のプロジェクトのほうがよい。

小規模倉庫AI拡大の2番目のプロジェクト：部門を選ぶ前の3つの厳しいテスト

この表は採点ゲームではない。コストを声に出して言わせるためのものだ。補充が2番目のプロジェクトとして機能するのは、技術が高度だからではなく、安全に失敗するからだ。悪い提案はレビューで目に見え、修正され、それが原因で誤った注文が出荷されることはない。ピック経路最適化も同じ話だ。余分な歩行はコストであり、事故ではない。ほとんどのオーナーが逆に理解している、直感に反する判断はこうだ。2番目のプロジェクトは、しばしば最も痛い部門であるべきではない。最も痛い部門は通常、最も絡み合っており、データ面で最も汚れており、最初のパイロットを終えたばかりのチームには、それを解きほぐす力はまだない。ミスが安く、修正可能な部門を選び、そこで信頼を築き、現場が自分の部門の番はいつかと尋ね始めるまで待つこと。その後初めて、最も難しい問題に取り組むこと。野心よりも順序のほうが重要だ。

小規模倉庫AI拡大の2番目のプロジェクトにおける昇格順序

順序については、私は近いものから遠いものへという考え方だけを信じる。近いとは、最初のパイロットから隣の部門ということだ。同じデータ、同じ人々、同じシフトである。最初のパイロットが受入にあったなら、2番目のプロジェクトは隣の補充や入庫を見るべきで、出荷検証や建物全体の予測へいきなり跳ぶべきではない。遠いとは、決して、という意味ではない。近いものが安定した後の、後で、という意味だ。2025年1月、ダラス近郊の小さな家庭用品倉庫はまさにこれを行った。最初のパイロットは出荷検証を支援した。2番目のプロジェクトは、そのステップで例外注文だけを振り分けた。書類が不明瞭な注文や数量に疑問のある注文は集中的な手作業に回し、問題のない注文は流れ続けた。3か月で、例外処理の平均は注文あたり9分から4分に減り、人員の追加もなく、誤出荷の増加もなかった。オーナーが後に3番目の部門を提案したとき、検証リーダーが最初にうなずいた。それがよい順序の姿だ。経営層が次のプロジェクトを押し下げるのではなく、現場が次のプロジェクトを前に引っ張るのだ。

ペースについては、私のルールは厳しい。稼働開始後の最初の2週間は、エラーログを毎日レビューすること。3週目からは週次とすること。3か月で正式なレビューを行い、3つの質問だけを問うこと。この部門は本当に時間を節約したか、エラーを減らしたか。クルーは、それがなくなれば惜しむか。そして明日それを止めたら、誰か反対するか。2つの答えがノーなら、3番目のプロジェクトへ急いではならない。まず2番目を直すこと。

人員配置の点も、あまりにしばしば見落とされる。2番目のプロジェクトには現場オーナーが必要で、そのオーナーはソフトウェアだけを管理する人ではなく、その部門のリーダーか、その部門のベテランでなければならない。ベンダーはボタンのクリックを教えることはできる。最も頻繁に現れる例外はどれか、どの時間帯はミスが許されないか、クルーが実際に耳を傾ける言葉はどれかを、リーダーだけが知っている。技術サポートは優れているのに現場オーナーがいない2番目のプロジェクトを私は見たことがある。提案は実際のシフト計画と衝突し、夜勤クルーは独自に即興で対応し、やがて誰もツールをまったく確認しなくなった。エラーログに1日30分、ボスとの週次チェックイン1回で十分だ。その人物なしに、始めてはならない。

スケジュールにストップラインを書き込むこと

プロジェクト計画の中にしか存在しないストップラインは、ストップラインではない。「結果が期待外れなら止める」と書かれた計画を、私はたくさん見てきた。そしてその日が来たとき、誰も選択が間違っていたことを認めたがらなかった。だから2番目のプロジェクトが始まる前に、オーナー、部門リーダー、ボスは3つのラインについて一緒に合意すべきだ。稼働開始前よりエラーや手戻りが2週連続で多い場合、止める。シフトがシステムを迂回して5日連続で作業する場合、止める。ツールを維持するのに週4労働時間を超えるコストがかかり、少なくともそれだけの節約が得られない場合、止める。いずれかのラインに触れたら、2週間旧来の方法に戻り、次に決断する。直すか、やめるかだ。止めることは失敗ではない。止めることを拒むことが失敗だ。

最後の助言を、最初のパイロットが成功した直後に最も興奮しているオーナーに向けて言おう。2番目のプロジェクトの最大のコストはソフトウェア料金ではない。建物全体が新しいことを学ぶ間、出荷から引き離される注意力だ。出荷は止まれないし、信頼は使い果たせない。ミスが安い部門を1つ選び、3か月間安定して運用し、現場に次のものを求めさせること。それが拡大の実際の姿だ。あなたの2番目のプロジェクトは今、3つの厳しいテストのうちどれに不合格だろうか。

Lao Mi（サプライチェーン・ベテラン (20 yrs)）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。