「あなたのシステムはわざとこうしてるのか？」
2019年、私はフォンタナのeコマース・フルフィルメントセンターでWESを導入していた——120,000平方フィート、1日8,000件の注文、ピックエリアに40人以上。朝10時30分、その日最初のウェーブが落ち、ピック・スーパーバイザーのChenが印刷したてのタスクリストを振りかざして私のデスクにやって来て、紙を指で突いた。
「UPSの集荷は2時だ」と彼は言った。「なのにその注文はタスク番号180にいる。一方で、うちの連中にFedExの分を先にピックしろって——あのトラックは5時まで動かないぞ？UPSの集荷を逃したら、誰の責任だ？」
隣のデスクからシステム管理者のLiが説明しようとした。「システムは注文のカットオフ時刻でソートしています。あのFedExの注文は昨夜入ったもので……」
「昨夜の注文は緊急じゃない」とChenは遮り、リストを机に叩きつけた。「で、どっちなんだ——カットオフ時刻か、集荷時刻か？」
それ以来、私はこの議論のどこかしらのバージョンを半ダースの倉庫で見てきた。ウェーブはその日の作業の周りに円を描くだけだ。その円の中で何が起きるか——何百ものタスクのどれが先に行くか——こそ、WESが真価を発揮する場所だ。その順序を間違えると、建物は毎日静かにお金を垂れ流す。ドックでアイドリングするトラック、監査ステーションの残業、遅延出荷についての顧客からの電話。
ハンドルを握る四つの手
一つ目の手：キャリアの集荷時刻。これは建物の中で最も厳しい制約だ。トラックが来る前に注文がピック・監査・封印されていなければ、その注文は翌日まで待つ。顧客は1日遅れの追跡更新を見て、サポートラインが鳴りっぱなしになる。私が訪れた多くの倉庫では、WESのこのフィールドはメンテナンスされていないか、メンテナンスされていても優先度ルールで実際に使われていないかのどちらかだ。どちらにせよ、ただのデッドウェイトだ。
二つ目の手：注文のカットオフ時刻。これは四つの手の中で最も乱用されている。カットオフが早いということは、顧客が早く注文したということだ。緊急だという意味ではない。昨夜11時に入ったバッチと、今朝9時に入ったが午後2時のUPS集荷に間に合わせなければならないバッチ——どちらが緊急か？明らかに後者だ。それなのに多くのシステムは、カットオフ時刻ソートをデフォルトルールとして出荷してくる。まさにその朝、Chenがぶつかったのがそれだ。
三つ目の手：ピック動線。同じルート沿いのタスクを束ねれば、ピッカーの歩行距離が減り、1時間あたりのピック数が増える。この手に何も問題はない——ただ、これは金を節約する手であって、日を救う手ではない。ヒエラルキーを混同すると物事はおかしくなる。詳しくは後ほど。
四つ目の手：欠品リスクと顧客ランク。最初からトラブルの種がある注文がある。システム上は在庫があるのに棚が空っぽのロケーション、厳格なロット・有効期限要件のある注文、クレームがオーナーの机に直行するVIP顧客だ。そういう注文は早めにピックして問題を早期に表面化させるか、通常フローから完全に外す。ウェーブの最後尾に置き去りにしてはいけない。
四つの手がすべてハンドルを握りたがる。WESにはこの争いを収める方法が必要だ。
ルール同士が争うとき
現実的な問いを一つ。注文A：昨夜注文、カットオフ時刻は最も早い、建物の最奥のロケーションにある、キャリア集荷は午後5時。注文B：今朝注文、カットオフは遅い、ピックゾーン入口のすぐ横にある、キャリア集荷は午後2時。どちらが先か？
答えは明らかだ：Bだ。集荷時刻はハードな制約。ピック動線はソフトな最適化。ハードな制約は常にソフトなものを上回る。
私のアプローチは加重平均ではなくティア（階層）だ。加重は科学的に聞こえるが、実際はお粥だ——「カットオフ時刻40%、集荷時刻30%、動線30%」——そうして出てきた順序は誰にも意味が通じない。フロアのスーパーバイザーにはとりわけ。ティアの方がシンプルだ：まず集荷時間枠でタスクをグループ化し、枠の中で動線順に並べ、欠品リスクの高い注文とVIP注文をそのティアの中で一段階だけ前倒しする。
ティアにはもう一つ利点がある：フロアが読めることだ。スーパーバイザーはタスクリストを開いて「今後2時間で出るものが全部前にいる」と一目で分かる。だから実際にシステムに従う。そうでなければ紙のリストで並べ替えに戻り、WESは存在しないも同然だ。システムの順序と実際のピック順序がまったく別物だった建物を、私は一つや二つでなく見てきた。
私が見てきた二つの失敗パターン
一つ目の死に方：カットオフ時刻だけでソートすること。2021年、私はMira Lomaの3PLを訪れた。ピークシーズンには1日15,000件の注文をさばいていた。彼らのWES優先度ルールは一行だけだった：カットオフ時刻でソート。プロモーションの日には、何千もの注文が夜通し流れ込んできた——すべて遅くて安い配送サービスで——システムは律儀にその「早い」注文から先にピックした。毎午後、当日集荷に間に合わせなければならない注文が後ろに溜まり、監査ステーションは夜9時過ぎまで残業した。オーナーは、あるピークシーズンに残業代だけで100,000ドル近く燃やしたと言った。ルールを集荷時刻ベースのティアに変えたら、残業はほぼ消えた。それはシステムの問題ではなかった。ルールの問題だった。
二つ目の死に方：欠品リスクを優先度から外すこと。最初から欠品の可能性が高いとフラグが立っている注文がある——棚と合わない手持ち在庫、厳しい有効期限の制約。そういう注文をウェーブの後ろに埋めてしまうと、ピッカーはそこに着くまで問題に気づかない：注文全体が止まり、例外処理、在庫探し、注文分割。プロセスが一つまた一つと続き、ウェーブの尻尾がどんどん伸びる。さらに悪いことに、監査ステーションはその注文を待って出荷を完了させようとしているので、すでにピックされた貨物もそこで待ちぼうけになる。対策は、高リスクの注文を前に引っ張り出し、問題を早期に表面化させることだ。朝10時に欠品を見つければ、在庫を探したり移したりする時間はまだある。午後4時に見つけたら、顧客に謝ることしかできない。
二つの死に方に共通する根本原因は一つ：優先度ルールが「先入れ先出し」という公平性ベースで設計され、結果ベースで設計されていなかったことだ。これが遅れたら何が起きるか、で考えるべきだ。
明日からできることが一つある。WESを開き、今日リリースされたウェーブを三つ引っ張り出し、タスクリストをエクスポートして、キャリア集荷時刻でソートし、システムが実際に割り当てた順序と比較してみる。食い違っていたら、まだ重みをいじったり式を書き換えたりしてはいけない。まず集荷時刻のマスタデータがそもそもメンテナンスされているかを確認しに行く。私の経験では、優先度の失敗のほとんどは、つまらない根本原因に行き着く：誰も集荷時刻を更新していない。キャリアがスケジュールを変更したのに、誰も入力していない。祝日でトレーラーが一台増えたのに、誰も記録していない。まずデータを正しくすれば、ルールは意味を持ち始める。データを間違えれば、どんなルール設定も救ってはくれない。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
