WESが稼働したら、人は完全に手を引くべきなのか。私はこの問いに逆方向で間違えた2つの倉庫を見てきた。ひとつではスーパーバイザーが毎日手動でウェーブを調整し続け、システムは高価な文鎮と化した。もうひとつではコンベヤが詰まって30分も止まったままだった。誰も引き継ぐ勇気がなく、注文はキューで腐っていった。どちらも授業料を払った。
まず地理関係を正しく押さえよう。WESはWMSと自動化レイヤーの間に位置する——WCS、コンベヤ、AMRだ。WMSは「今日何を、どの積載で出荷すべきか」を伝え、WESはその注文をタスクに分解し、ソーターやボット、ピックステーションへリズムよくリリースする。実行とリリースの交通整理役だ。ルーチンの95%は見事にこなす。だが残りの5%は例外の山であり、交通整理役も人の手が必要なときを認めなければならない。
問いはいつだって「人が介入すべきか」ではなかった。「介入にプロセスがあるか」だ。誰に権限があり、どのシナリオで、システムに痕跡を残したか——この3つが文書化されていなければ、介入は善意の妨害行為にすぎない。私が思う、人の手がまだ属すべき5つの境界線は以下だ。
ウェーブリリース：カットオフ前30分はスーパーバイザーのもの
WESのウェーブリリースロジックは通常固定だ。キャリアのカットオフ時刻から逆算し、経済的なバッチが組めたらウェーブをリリースする。平常日なら問題ない。トラブルはカットオフ前の30分に潜んでいる。
実際のドックで起きた光景だ。キャリアのカットオフは20時、19時30分に主要顧客から緊急注文が入った——300個を超えるユニットだ。システムはすでに20時前の予定分をすべてリリース済み、コンベヤは満載。ルール通りなら、その注文は次のウェーブを待って翌日出荷だ。スーパーバイザーはWESコンソールに入り、通常ウェーブを手動で15分遅らせ、大口注文を次のリリースに滑り込ませた——すべてが20時のトレーラーに間に合った。
なぜシステムでは対応できないのか。「トラックを逃したらこの顧客を失う」が見えないからだ。システムが知っているのはルールとキャパシティだけだ。手動引き継ぎはこう動く。スーパーバイザーには「今すぐウェーブをリリース／ウェーブを遅らせる」権限があり、使うたびにシステムで理由を選ぶ——「顧客の緊急注文」「キャリアの早期到着」——ウェーブログが自動で記録する。返還はクリーンだ。次のウェーブは自動リリースに戻り、システムが自力で再シーケンスする。介入は一度きりのアクションであり、戻し忘れるマスタースイッチではない。
優先度の上書き：すべてが緊急なら、何も緊急ではない
欠品時の緊急補充、VIP注文——順番を抜かすのは正当だ。だが私が関わったある倉庫では、3人のスーパーバイザーがそれぞれ上書き権限を持ち、毎朝WESのタスクキューには200件の「最優先」注文が並んだ。システムは誰が本当に先か判断できない。一番大声を出した人が先に出荷した。これは優先度のインフレ——お金を刷るのと同じ経済学だ。刷りすぎれば価値はなくなる。
システムの限界はここだ。今週どのVIPが本物のVIPか、システムは知らない。WESの顧客ティアは静的な設定だが、現実は動的だ。今月守るべき顧客は、先月の顧客とは限らない。
解決策は枠（クォータ）だ。各シフトのスーパーバイザーに、たとえば20枠の上書き枠を与える。使えば1枠減り、残枠はWESに表示される。上書きされた注文はすべてタグ付けされ、月次レポートで上書き件数と承認者が見える。枠を使い切ってもまだ注文を上げたい？オペレーションマネージャーの承認を取れ。上書きにコストがかかるようになった瞬間、気軽な上書きは消える。
設備劣化：コンベヤが止まる前に引き継ぎ台本を書け
5つの中で最も危険なのがこれだ。WESは設備の協調制御で存在価値を発揮する——設備がダウンしたとき、それがまさに問題になる。詰まったコンベヤ、通路で動かなくなったAMR、ラベルを噛む印字貼付ユニット。WESはアラームを上げる。だがゾーンBの作業をゾーンC経由に迂回させる判断は、独断では下さない。
なぜか。劣化プランはアルゴリズムの問題ではなく、ビジネスの判断だからだ。ゾーンを切り替えればピックパスは一変し、人員は再配置され、ウェーブは再計算が必要になる。システムはそのトレードオフを計算できないか、計算できても無監督で実行させる勇気が出ない答えを出す。
だから劣化プレイブックは事前に書く——そしてリハーサルする。どの深刻度で人が引き継ぐか（たとえば単一コンベヤのダウンが10分超）、引き継ぎ後の最初の3つのアクション（影響を受けたウェーブを手動でバックアップゾーンへ切り替える）、WESのどの画面を叩くか、各ステーションに何をアナウンスするか。2回のリハーサルで、スーパーバイザーは本番で凍りつかなくなる。代替案も見てきた。詰まったライン、無線で異なる指示を叫ぶ5人のスーパーバイザー、WESに溜まるタスク。誰かがライン全体を止めて手作業で片付けるまで続いた。20分の復旧が2時間になった。
返還はこうだ。設備が復旧したら、スーパーバイザーがWESで「自動ディスパッチ再開」を押す。システムがゾーン横断でタスク状態を再スキャンし、迂回したウェーブを自動で再シーケンスする。譲れないのは一点。引き継ぎ中の手動アクションはすべてシステムログに残ることだ。ポストモーテム（振り返り）は人の記憶ではなく、ログを読む。
人員移動：システムは助言し、スーパーバイザーが決める
現代のWESプラットフォームには人員管理の筋肉がついている。どのゾーンが詰まり、どこに余裕があり、「AからBへ3人移動」のような提案も出す。提案は聞け。だが決めるのはスーパーバイザーだ。
システムは知らないのだ。誰かにとって今日が初めての単独勤務だとか、ベテランの腰がステーションでの2時間立ち仕事に耐えないとか。ゾーン横断の移動には人のスキルチェックが要る——put-to-lightを回したことがない人を光誘導ゾーンに送っても、スループットは上がらず、エラーが増えるだけだ。
ワークフローはシンプルだ。システムが提案し、スーパーバイザーが画面で承認または調整し、システムがゾーン間のタスク配分を更新する。私の定番の習慣：スーパーバイザーはシフト開始時と昼に人員提案をレビューし、変更は必ずシステム内で行う——グループチャットで叫ばない。「ねえ、ゾーンBを手伝いに行って」がチャットのメッセージにしか存在しない瞬間、WESは古い人員配置を表示し続け、タスクはゾーンAに流れ続け、システムと現実がずれ始める。
棚卸カウントとロックされたロケーション：凍結解除には人のサインが必要
WESがロケーションをロックしたら——帳簿と実在庫の不一致、センサーの異常、3回連続のピックエラー——関連タスクは自動で一時停止する。自動ロックは正しい。問題はアンロックだ。
私のルール：システムがロックしたロケーションの凍結解除は、人の確認があって初めて行う。自動解除は絶対にしない。手間を省こうと「30分間人のアクションがなければ自動アンロック」を有効にした倉庫を見たことがある。センサーの誤検知ロケーションが3回自動でアンロックされ——3回誤出荷した。自動アンロックは安全弁を溶接して塞ぐようなものだ。
確認は低摩擦でいい。ロケーション監査員が現場で目視し、実在庫が合っていれば、WESで理由付きで凍結解除をタップする——「実在庫一致」「補充済み」「センサー誤検知」。システムが記録する。シフト終了前に、スーパーバイザーがその日の凍結解除リストをスキャンする。3回以上解除されたロケーションは、翌日の詳細チェック対象としてフラグを立てる。この習慣を続ければ、在庫精度は本当に上がる。
5つの境界線、ひとつの主張：手動介入そのものを手順化しなければならない。誰が介入でき、どのシナリオで、システムにどんな痕跡を残すか——SOPに書き、WESの権限とログで裏付ける。グループチャットの叫び声ではない。
WESはルーチンの95%を回し、人は例外の5%を回す。この分業は正しい。最も危険だったのは人の介入などではない——プロセスなき介入だ。一方はシステムを修繕し、もう一方はその下に穴を掘る。あなたがどちらかは、終わったときにログエントリがあるかどうかで決まる。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
