スロッティングは倉庫の神話ではなく応用経済学である
倉庫スロッティングは通常、常識に基づいた演習として提示される。速く動く商品は通路の近くに配置し、壊れやすい商品は損傷から守り、補充作業をさらに困難にしてはならない。これらはすべて理にかなっているが、決して十分ではない。前方のピック面は希少な資産であり、その資産の各割り当ては、同じ労働、スペース、在庫の別の用途を排除する。一旦これが明確になると、スロッティングは倉庫内で展開される一連の経済的選択として姿を現す。オーダーピッキングは倉庫業務の中で最もリソースを消費する作業の一つであり、そのため配置のわずかな誤りが労働コストに大きく響くのだ。
この議論のより広範なバージョンは、特に第1章、第5章、第6章、第8章で展開されるサプライチェーン入門に詳述している。サプライチェーンソフトウェアは、記録を取り込み、不確実性の下で推論し、手続きの整然さではなく損益に照らして判断される決定を下すべきである。スロッティングも同様の扱いを受けるべきである。その目的は、移動時間、混雑、脆弱性、補充作業のコストがすべて考慮された上で、期待される経済的リターンに基づいて候補配置をランク付けすることである。
移動時間は、方程式における明白な要素である。オーダーピッキングは労働を吸収し、保管配置はルーティングと密接に関連している。ある人気SKUの歩行距離を短縮する配置は、全体のルートを長くしたり、誤った通路に交差交通を強いたりする可能性がある。移動時間は評価に含まれるが、全体の評価はそれだけでは収まらない。保管配置とピッカールーティングに関する学術研究は、これら二つの問題が深く結びついている理由を示している。
混雑もまた考慮されるべきであり、脆弱性も同様である。平均的な需要下で完璧に見えるスロッティング計画も、急成長する数点の商品が同時に現れたり、補充が遅れて到着したり、2つの通路が同時に飽和状態になったりすると、あっという間に崩壊する。これらの損失は、残業、手動による上書き、急ぎの補充、出発の遅れとして現れる。これらは特筆すべき損失ではなく日常的なものであり、まさにそのために決定論的な計画はこれらを隠蔽しがちである。不測の混雑や脆弱性を単なる二の次や不運とみなすシステムは、単に金銭的機会を逸しているに過ぎない。
補充コストがこの連鎖を締めくくる。すべての前方スロットは、将来の内部作業の約束でもある。ピック面で数秒を節約し、補充作業の回数を倍増させるロケーションは、結果として良い取引とは言えない場合がある。Oracleはこの関連性を明確にしており、そのReslotting Workbenchは、アイテム速度のランキングに基づいてロケーションを再配置し、不一致から補充タスクを生成する。Microsoftは、単位階層、テンプレート、指令、およびスロッティング計画が確立された後の補充作業を通じて類似の連鎖を説明している。両社ともこの結びつきを認識しているが、公開されている記述の中には、不確実性の下でこれらの結合効果を経済的にランク付けするエンジンが示されているものはない。
不確実性こそがすべての問題である。明日の注文は分からず、共同行動、通路内の衝突、補充の中断、作業時間、損傷発生も予測できない。もしスロッティングシステムが、十分であるかのようにポイント予測やABC分類に依存するなら、コストを生むピークを滑らかにしてしまう。平均はあくまで礼儀正しい虚構に過ぎず、倉庫は裾野部分で代償を支払う。同じ欠陥はサプライチェーン全体に見られる。ポイント予測は、未来の形状を消してしまうため、整然とした算術計算と乏しいコミットメントしか生み出さない。
したがって、適切なスロッティングエンジンには、需要量だけでなく、注文の構成、共同行動、補充タイミング、労働摩擦に関する確率的予測が必要である。その上で、これらの分布を実際に取り込み、期待されるリスク調整後のリターンによって移動をランク付けする意思決定ルーチンが求められる。ここで使われる語彙にはあまり我慢ができない。『確率的最適化』という呼称は適切だが、その実質はこのフレーズよりもシンプルである。分布が入力され、経済的にランク付けされた動作が出力される。不確実性が問題定義から除かれると、「最適化」という言葉は単なる飾りとなる。
ソフトウェアが実際に行うこと
この最低基準が採用されると、市場で使われる多くの用語が理解しやすくなる。SAP EWMは、スロッティングを製品マスターに書き戻される保管パラメータの決定として説明し、条件レコードがその結果を導く。SAPの機械学習バリアントは、倉庫設定と製品マスターデータから自動的にスロッティングルールを導出する方法として説明される。これにより設定作業の手間は削減されるかもしれないが、それはあくまでマスターデータシステムのルール生成のように映り、希少なピック面の次善利用を決定する確率的最適化器とは異なる。
Oracleもまた明確である。現在の資料は、アイテム速度ランキング、不一致のランク付け、KPI表示、フィルタリング、ソート、補充タスク生成を中心に展開される。Microsoftは、需要統合、テンプレート行、指令コード、ウェーブ需要数量や最大ロケーション容量などの補充戦略を中心に据えている。これらはスロッティング体制を維持するためのツールであり、競合する配置間の微細な確率的トレードオフを開示するものではない。
より先進的な倉庫ベンダーは、もっと正確な評価に値する。Manhattanは、各潜在的配置に対する相対的な価値や、ユーザー設定の戦略の下で何百万もの移動組み合わせを比較することについて語る。Blue Yonderは、需要シグナル、移動経路、継続的最適化、最高価値の移動、そして補充や労働計画との統合について語る。Lucasは、SKUの速度、相性、ピック経路、予測作業時間、回収重視の動きに基づいた機械学習による推奨を語る。これは目的により近い。少なくとも、単なるデータ入力ではなく、ランク付けを明示している。
それでも、公開されている記述は、難解な部分に入った途端に止まってしまう。私が確認したページでは、どのベンダーも、スロッティング決定を支える確率分布、移動と混雑および補充を仲裁するための経済的目的、または脆弱性に対するペナルティの方法を説明していない。Blue Yonderは、計画スイートの他の部分で確率的予測を広告しており、これは技術的認識の有用なシグナルであるが、スロッティングのページではそれらの分布がエンジン自体に組み込まれているかどうかは示されていない。公開証拠こそが、購買者が販売サイクルが約束に陥る前に検証できるものであり、これを基準としている。
「何百万」や「何十億」という語は、ほとんど敬意を払うに値しない。候補動作の数は、意思決定の質についてほとんど何も示さない。困難なのは可能性を列挙することではなく、不確実性の中で各可能性に健全な経済的価値を割り当てることである。探索空間は安価だが、正しいランク付けは非常に価値が高い。マーケティングが探索空間の大きさや「何十億の意思決定」といったスローガンを前面に出すとき、それは通常、評価の説明が非常に困難であることを意味している。
エンジニアリングからの示唆
今のAI流行よりも古い、もう一つの手がかりがある。製品がフォーム、マスターデータ、ワークフロー、テンプレート行、日々の確認を中心に構成されている場合、それは自らの系譜を示している。まず第一に、それは台帳である。これは在庫の動きを記録するための適切な設計だが、厳密な数値探索の中心としては不適切である。重い最適化は台帳の外にあるべきだと長年主張してきた。なぜなら、記録システムと知能システムは、アーキテクチャを相反する方向に引っ張るからである。この手がかりは、公開されている資料そのもの、すなわち製品マスターの更新、条件レコード、検索可能なワークベンチ、KPIビュー、テンプレート、指令、あらゆる事務的設定オブジェクトに明らかである。
ベンダーがリレーショナルでCRUDに重いコアに、真剣な最適化器を組み込むことは可能だろうか？理論上は可能だが、実際にはほとんどない。データベースが勝利し、フォームが増殖し、最適化器は装飾的な付属物になってしまう。SAP HANAは、取引と分析を同時に実行するために構築されたリレーショナルデータベースである。Manhattan ActiveはCloud SQL for MySQL上で動作する。これら両方の技術は、取引処理の基盤としては立派であり、その存在はエンジニアリングの大部分の努力がまず取引の信頼性に根ざしていることを示している。同じプロダクトファミリーが、後に意思決定ロジックを示さずに自律的な最適化を主張する場合、私が信じる余地は大きく制限される。
公開資料はそのように読める。SAPはスロッティングの結果を製品マスターに書き込む。Oracleは、検索可能なフィールドとKPIビューを備えたワークベンチUIを前面に出す。Microsoftはテンプレート、指令、補充戦略を中心に据えている。Manhattanの公開WMSストーリーはクラウドネイティブなマイクロサービスプラットフォームを強調し、Google Cloudの事例では同じActiveファミリーがCloud SQL for MySQL上で動作していると記されている。これらはいずれもソフトウェアを無用のものにするわけではなく、多くのエンタープライズ製品がデータ入力やプロセスの施行に秀でている理由を説明しているが、希少資源を実際に配分する微細なロジックについてはほとんど触れていない。
より包括的な計画スイートは、通常、ピック面の問題を完全に回避する。RELEXは機械学習による予測、補充のための確率的計画、そしてAI駆動のプラノグラムを公に強調する。Kinaxisはオーケストレーション、シナリオ分析、在庫洞察、ダッシュボードを前面に出す。o9は、AI/MLによる予測と、同期された最適化された意思決定に関するスローガンを伴うエンドツーエンドの計画プラットフォームを強調する。これらの機能はそれぞれの領域で価値があるかもしれないが、私が確認した公開記録において、確率的経済リターンによって個々の配置をランク付けする倉庫スロッティングエンジンに匹敵するものではない。
私を説得するためには何が必要だろうか？ まず、見せかけの演出はほとんど不要だ。ポイント値ではなく分布、KPIの代理ではなく明示的な経済ペナルティ、なぜある動作が他を上回ったのかを示す意思決定ログ、そして事務的な修正をほとんど必要としない動作を出力するエンジンを求める。ソフトウェアは、どの不確実性がモデル化され、どれが評価され、どれが範疇外であるかを明確に示すべきである。それがなければ、「AI搭載スロッティング」は、単により良いブランディングの推奨画面に過ぎない。
スロッティングは、価格設定、購買、在庫配分と同様の厳粛な取り扱いに値する。ピック面は物理的形態の資本である。問題は、その資本を今日誰が取得し、採用することでどのような選択肢が失われるかという点にある。その問いは不確実性下の経済学に属する。他のすべては、その周りの事務的な外殻を飾るに過ぎない。
