ソーターを「調子のいい日」のために買う人はいない。カタログの数字——1時間12,000個、読取率99.9%——は、すべてのシュートが空いたままで、すべてのラベルがスキャンできることを前提にしている。現実の倉庫はそんなふうには動かない。私は2023年のサンクスギビング翌週の火曜日の午前2時、カリフォルニア州オンタリオの120,000平方フィートの3PLに立ち、クロスベルトソーターが自分の成功に窒息していくのを見てそれを学んだ。シュート3が満杯になり、フォトアイはしばらく前からアラームを出していたが、シフトスーパーバイザーは「このウェーブが終わってから」片付けようと考えていた。WCSはシュート3へのダイバートを続けた。荷物はシュートから滑り落ちて床に山積みになり、やがてスキャントンネルの読取ゾーンを塞いだ。ノーリードが急増し、例外シュートも満杯になり、ライン全体が再循環モードに入った——UPSのカットオフが過ぎ去る中、トレイが1時間近く空でぐるぐる回り続けた。
原因分析は気まずかった。機器は正常だったからだ。WCSの例外ルーティング設定が間違っていたのだ。シュート満杯、読み取れないバーコード、特大荷物——これはすべての仕分けシステムで毎日起こる。正常な例外だ。設定を間違えると、数十万ドルする機械がほんの一握りの設定に負ける。私が長年しくじってきたことと、最終的にたどり着いた結論を書く。
シュートが満杯のとき、WCSは誰の言うことを聞くのか
よくある間違いは、満杯シュートを「人手の問題」として扱うこと——誰かを送って片付ければいい、という考えだ。しかし満杯シュートは本質的にはルーティングの判断だ。フォトアイが「満杯」を出した瞬間、システムはソーターが約1周する間に3つのことをしなければならない：そのシュートへのダイバートを止め、対象の荷物をバックアップシュートに再ルーティングし、片付けに来るよう人に知らせる。
私が最もよく見る失敗モードは「ダイバート停止」と「再ルーティング」の間のタイムラグだ。次のウェーブが落ちてくるまでルーティングテーブルを更新しないシステムがあり、30〜60秒間、ソーターは満杯のシュートに荷物を送り続ける。かつて訪れた現場では「シュート満杯」信号がシュート入口ではなく底部のフォトアイから来ていた。センサーが反応した頃には、荷物はすでにシュートの縁を越えて床に溢れていた。
私の設定ルールは3つ。第一に、シュート満杯検出は入口のフォトアイ＋充填率計算で行う：設計容量の85%でWCSが警告を送り、新規荷物をバックアップシュートにダイバートし始める。100%でダイバートを完全に停止する。第二に、各シュートにルーティングテーブルで「オーバーフローバディ」をハードコードする——隣のシュートか集中例外シュートだ。午前2時に現場スタッフがこの判断を即興する必要はなくなる。第三に、シュートが片付いたらWCSは通常ルーティングを自動復帰させる。人がボタンをクリックして再開するのに頼ってはならない——午前3時にそのクリックが忘れられる確率は10回中9回だ。
戒めの反例をひとつ。2021年に訪れたアパレル倉庫のWCSは、シュートが一つでも満杯になるとソーター全体を止め、手動片付けを待つ設定になっていた。保守的に聞こえるだろう？ピークシーズンには約40分ごとにシュートが満杯になった。ソーターは1日に20回以上停止と起動を繰り返し、実効スループットは3割近く落ちた——モーターとブレーキへの負担は言うまでもない。満杯時の自動再ルーティングに切り替えたら、スループットはその日に回復した。ラインを止めるのが最もコストの高い例外処理だ。最後の手段にとっておけ。
ノーリード問題は失敗ではなく「迷い」が問題だ
スキャントンネルのベンダーは読取率99.9%をうたう。現場では、しわの寄ったラベル、テープで半分貼られた出荷ラベル、横倒しの箱が、ノーリードを毎日の出来事にする。読取率が問題なのではない——読み取れなかった荷物をWCSがどう扱うかが問題だ。
私が見てきたアプローチは3つ。第一：ノーリードのたびにラインを止めてアラームを出す。これは最悪の選択肢だ。ピーク時に1時間1万個近く回すラインでは、停止のたびに再起動時間と上流の渋滞が発生し、課金は分単位で積み上がる。第二——私が推奨するもの——はノーリードを例外シュートにダイバートする。リワークステーションのオペレーターが荷物をスキャンし、宛先を入力するかラベルを再発行し、WCSは修正をその荷物の例外IDに紐づけて通常フローに再投入する。第三は「次はカメラが捉えてくれるかも」とノーリードを何周も再循環させるやり方だ。そう、本当にこう設定している現場がある——完全な無駄容量の再循環ループを5周も。
第二のアプローチが機能するかどうかを決めるディテールが一つある：例外シュートの位置だ。スキャントンネルの下流にあり、人が手の届く場所にあり、通常シュートと滑り面を奪い合わない独自のコンベア区間にあること。あるプロジェクトでは例外シュートがソーターの反対側にできてしまい、オペレーターは修正済み荷物を再投入するためにカートを80メートル押していかなければならなかった。ピーク中はノーリードが人が歩いて戻せる速度より速く溜まり、例外シュートが新たなボトルネックになった。
例外シュートと手動ステーションをケチるな
例外シュートと手動リワークステーションは、予算査定で最初に削られる項目だ——「通常フローは動いている、例外がどれだけあるというのか？」このセリフは入札会議では理にかなって聞こえ、ブラックフライデーの午前2時には馬鹿げて聞こえる。
私の最低構成：ライン上に少なくとも2つの例外シュート（ノーリード用1つ、特大・非搬送可能物用1つ）＋手動投入ステーション1つ。特大荷物には独自の段落が必要だ：WCSは投入時点で寸法と重量の制限を強制し、制限超えはソーターに触れる前に手動ステーションへ却下されなければならない。6フィートのロール状カーペットがクロスベルトに投入されたのを一度見た。カーブで詰まってラインが25分止まった——投入時に特大却下がなかったせいだ。
手動ステーションには、ほとんどの人が忘れる機能がもう一つ必要だ：オペレーター指定ダイバート。一部の荷物はラベルが破損したノーリードだ。オペレーターがWMSで宛先を調べ、作業ステーションでシュートを指定し、WCSが荷物をそこにダイバートする。この機能は多くのWCSパッケージで出荷時無効になっている。有効にせよ。
そして手動ステーションのラベルプリンターを削るな。ノーリードの約3分の1は単にラベルが損傷しているだけだ——再発行すれば荷物は通常フローに戻る。プリンターがなければ、オペレーターはシフト中ずっと追跡番号を手入力し、エラー率は目に見えて上がる。プリンター1台と1年分のリボンは数百ドル。ライン上で最高の金の使い方だ。
アラーム閾値：静かよりうるさいほうがいい
私の最も高くついたアラームの失敗は、気を遣いすぎたことだった——現場に迷惑をかけないよう、シュート満杯アラームを「満杯」が5分続いてから鳴るように設定した。鳴った頃には、荷物が胸の高さまで積まれていた。
私の現在の閾値：シュート充填率85%でシフトスーパーバイザーのハンディに警告、サイレンなし。100%でダイバート停止とサイレン。例外シュートに20個を超える荷物でアラーム、15分の片付けSLA。ノーリード率が2%超えが10分続いたらアラーム——これはほぼ確実にスキャントンネルの清掃が必要か、上流から不良ラベルのロットが来た合図で、誰かが確認に行くべきだ。アラームは階層化しなければならない：警告はハンディへ、障害はライト＋サイレン＋テキストメッセージ。階層化なしでは「オオカミ少年」問題になる：全部がアラームし、現場はやがてサイレンを抜く。そういうのも見たことがある。
もう一つルール：WCSは例外ルーティングのすべての動作をログに残さなければならない。どの荷物を、いつ、なぜ再ルーティングし、どのシュートに行って、誰が対応し、いつ片付いたか。そのログはピーク後のレビューで金になる——例外労働のコストを正確に算出でき、翌年の予算に実数が裏付けられる。
仕分けベンダーは通常フローを私よりよく知っている。だが例外ルーティングでは、ベンダーのデフォルトは理想の倉庫向けに書かれており、理想の倉庫など存在しない。シュートは満杯になる。バーコードは読めない。特大荷物は紛れ込む。WCSは好調な日にどれだけ速く回るかで評価されるのではない——悪い日にどれだけ慌てないかで評価される。次のWCS受入テストでは、通常のダイバートケースだけでなく走らせるな。例外ドリルを仕掛けろ：シュートを2つ塞ぎ、無ラベル荷物を10個流し、特大荷物を1つ投入して、システムが5分以内に自己安定するか見ろ。できなければ今すぐ設定を直せ——ブラックフライデーの午前2時の授業料よりずっと安い。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
