本当に頭にくることがある。午前2時半。ウェーブは40件のオーダー遅れ、WESのダッシュボードは真っ赤に点灯し、12件のタスクが47分間も停滞したまま動かない。誰も気づいていない。シフトリーダーは外でタバコを吸っている。当直マネージャーは眠っている。そしてシステムは?遅延の1分1分を忠実に記録しながら、それに対して何も——本当に何もしなかった。
これは2023年、南カリフォルニアで生鮮食品の流通を手がける3PLで実際に起きたことだ。その夜、コンベヤの一区画がジャムを起こし、上流側にピックタスクが山積みになった。WES上でそれらのタスクは「進行中」から「タイムアウト」へ、さらに「例外」へと遷移したが——誰にも1件も通知が行かなかった。午前6時のシフトが気づいた頃には、冷蔵車の出発時間枠は閉じていた。1台分のトラックは午後の便にずれ込み、ペナルティと緊急残業の合計は、ひどい請求額になった。
事後検証で私は彼らのITに1つだけ質問し、彼らはただ私を見つめた。「WESで設定しているタイムアウトエスカレーションルールはいくつありますか?」答えはゼロだった。システムにはその機能があった。3年間、誰一人として設定したことがなかったのだ。彼らのWESは高額なダッシュボードだった——見栄えは良く、役に立たない。
停滞したタスクが自力で復旧することはない
倉庫実行システムについて広く誤解されていることがある。導入すれば例外が勝手に解決する、と。しない。タスクはありきたりな理由で十数通りも停滞する——コンベヤのジャム、自己位置を見失ってその場で旋回し続けるAMR、トイレに行くためにRFガンをポケットに入れたピッカー、印字貼付タスクを止めてしまうラベルプリンタのジャム。これらは1つも自力では直らない。すべて人間を必要とする。システムにできる唯一のことは、正しい人を正しいタイミングで起こすことだ。
タイムアウトエスカレーションは1文で言い表せる。すべてのタスクに「この時刻までに誰も触らなければ、問題だ」という期限を与え、期限が来たらその問題を解決できる人の目の前に自動的に押し出す。それがなければ、WESはスプレッドシートより少しマシな程度——もっと高価なだけの存在だ。
閾値はカンではなくタスク種別で設定する
最も多い間違いは、全タスクに単一のタイムアウト閾値を適用することだ——例えば一律30分。これは純粋な当てずっぽうだ。タスク種別ごとに通常の所要時間は桁違いに異なる。すべてに1つの物差しを当てると、結果は正確に2通りしかない。閾値が緩すぎて、本当に壊れたタスクが何時間も放置されるか、厳しすぎてシフトリーダーの電話が誤報で爆撃され、3日目には通知をミュートする——そうなれば本物の警報も失う。
私のアプローチはタスク種別ごとの段階設定で、各段階に2本のラインを引く。警告ラインはオペレーターを促し、エスカレーションラインはチェーンを上がっていく。下記の数値は私が使う初期設定であり、福音ではない。2週間分の自社データを取り、実際のタクトに合わせて調整すること。
| タスク種別 | 警告ライン | エスカレーションライン | エスカレーション先 |
|---|---|---|---|
| コンベヤ/ソーターのタスク | 進捗なしで3分 | 10分 | 設備リーダー → 当直マネージャー |
| AMR搬送タスク | 移動なしで5分 | 15分 | 自動化エンジニア → 当直マネージャー |
| マニュアルピックタスク | 標準時間の50%超過 | 標準時間の2倍 | シフトリーダー → 運営スーパーバイザー |
| 補充タスク | 未着手で30分 | 1時間 | シフトリーダー → プランナー |
| ウェーブ全体の進捗 | 計画より15分遅れ | 計画より30分遅れ | 当直マネージャー → 運営マネージャー |
ラインを引く原則は1つ。エスカレーションラインは「災害」の期限より十分手前に置くことだ。冷蔵車が午前6時に出るのに、ウェーブのエスカレーションラインが5時50分では冗談にならない——人間が実際に介入できるだけの滑走路が必要だ。私は普段「物事が悪化する30分前」から逆算している。もう1つの原則:シフトに入っていて判断できる人にエスカレーションすること。夜勤のエスカレーションを日勤のオペレーションマネージャーに送るのは、どこにも送らないのと同じだ——エスカレーションチェーンは勤務表と一致しなければならない。
本当に起きてほしい人が起きるチェーンを作る
閾値が決まれば、次はエスカレーションパスだ。私が見た中で最高の構成は3段階で、各段階とも「応答がなければどんどん上がっていく」。
第1段階:システム内通知+RFガンの振動でオペレーターまたはシフトリーダーに知らせ、5分間無応答で自動エスカレーション。第2段階:当直マネージャーへのSMS+電話。同時にWESは影響を受けたタスクを赤色で上部に固定表示する。第3段階:自動プレイブック——そのウェーブの新規タスクリリースを一時停止し、停滞タスクをマニュアル対応に切り替え、オペレーションマネージャーにサマリーを送る。この第3段階はたいていカスタム開発かWMS連携が必要になるので、稼働開始後ではなくベンダー選定の段階で確認すること。

常に見落とされる層が1つある。WESのエスカレーションをWMSやWCSのアラームに結びつけることだ。WESのタイムアウトエスカレーションは孤島であってはならない。コンベヤのジャムでは、WESタスクがタイムアウトする10分前にWCSはすでに気づいている——モーターの過負荷アラームはすでに鳴っている。2つのアラームの流れが分断されると、2つのチームが2つの画面を見つめ、相手がすでに対応していることに誰も気づかない。私のルールはこうだ。設備の例外はWCSアラームに従い、タスクの例外はWESに従い、両方とも1つのエスカレーションチェーンに流れ込み、当直マネージャー向けに1つの要約を作る。できるならWMSのウェーブ状態も取り込もう——WMSは、個々のWESタスクがタイムアウトし始める前に、ウェーブが計画より遅れていることを知っている。ウェーブがすでに知っていることを、タイムアウトが教えてくれるのを待つな。
明日からできることが1つある。今夜、WESの管理コンソールを開いて、タイムアウトエスカレーションルールが存在するか確認すること。なければ、ちょうど1つだけ設定しよう——ピックタスク用、警告は標準時間の1.5倍、エスカレーション先はシフトリーダー。1つのルールだ。1週間運用してみる。きっと戻ってきて私に感謝するだろう。システムは使うために買ったのであり、眺めるために買ったのではない。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。








