去年のブラックフライデー、ある家庭用品セラーから救済の依頼が来た。彼らのOMSは5行の注文をカリフォルニア、テキサス、ニュージャージーの3つの倉庫から出荷する3つの荷物に分割していた。顧客が支払ったのは1回の送料。会社が支払ったのは3回分——そして星1つのレビューが付いた。「5点の商品が3日間に分けて届いた。ふざけた店だ」。オーナーは聞いた。「システムが自動で最適な倉庫を選ぶんじゃなかったのか?」確かにルール通りではあった。ただそのルールは3年前に適当に設定され、それ以来一度も触られていなかったのだ。

OMSにおけるマルチ倉庫引当ルールは、設定を誤れば毎日金を垂れ流し、正しく設定しても誰にも褒められない、そんなモジュールだ。ルールが実際に持つべき軸、優先順位の付け方、そして現場で私が最もよく見る3つの典型的な設定ミスを解説する。

ルール1:まず距離——ただし「距離」は直線距離ではない

ほぼすべてのOMSは「顧客に最も近い倉庫」をルール1として搭載している。一見正しいが、魔物は「近い」の計算方法に潜む。直線距離で計算すると、LAの注文はサンバーナーディーノからの引当になるかもしれない——机上では60マイルだ。しかし運送会社の料金はZIP-to-ZIPのゾーンで決まり、実際の請求額はフェニックスからの引当より高くなることがある。

対策は、運送会社のゾーン表から逆算することだ。主要運送会社のゾーンマトリクスをOMSに取り込み、マイル数ではなく推定運賃でソートする。1日3,000件の注文を処理するあるクライアントは、この1つの変更だけで月間運賃を9%削減した。実数だ。ソートロジックを1箇所変えただけである。

eコマース倉庫の梱包ステーションで待つ複数の荷物

ルール2:在庫の深さ——最後の1個を売り切るな

在庫を無視した距離優先は、2番目に大きな落とし穴だ。倉庫Aが最も近い。だがそのSKUの残りは2個で、そのうち1個は既に別の引当待ち注文に確保済みだ。引当可能在庫(available-to-promise)を無視するOMSは、それでも注文をそこに振る。ピッキングで不足が出て、注文は再び分割され、出荷日は吹き飛ぶ。

引当ルールには在庫のウォーターラインが必要だ。安全在庫を下回る倉庫(例えば7日分の販売量)は、どれだけ近くても自動的に後回しにする。ウォーターラインはABCクラスごとに設定する——A品は高めに、C品は低めに。多くのOMSプラットフォームはクラス別ウォーターラインに対応しているのに、導入時に手抜きで全品一律の数値を設定する。それは設定しないのと同じだ。

ルール3:コストは運賃だけではない

成熟した引当ルールはトータルで計算する。運賃+倉庫のハンドリング費+梱包差異だ。例:東海岸向け注文は西海岸の拠点からだと運賃が$2高い——しかし西海岸の拠点は自社運営で、東海岸の3PLよりハンドリング費が$3安い。差し引き$1の節約だ。運賃だけのルールは間違った選択をする。

さらに厄介なのが3PLの料金体系だ。マルチピース注文のサーチャージ、特大品のハンドリング料金。これらを引当コストモデルに組み込まないと、システムはかさばる注文をすべて「運賃は安いがハンドリングは高い」拠点に振り分け、損失は月末の照合で初めて表面化する。

ルール4:納期の約束は専用レーンで

納期コミットのある注文——プレミアム配送やTikTok Shopの定時出荷スコア——は別の引当ロジックが必要だ。最安の倉庫ではなく、期限通り出荷できる倉庫を選ぶ。遅延ペナルティやアカウントへのペナルティは、数ドルの運賃よりはるかに高くつく。

2つのルールテンプレートを推奨する。通常注文用はコスト最適、コミット注文用は納期優先で、注文タグに応じてOMSが切り替える。両方を1つのブレンドルールで賄おうとすると、必ず両方で失敗する。

実践のチューニング:優先順位付けは職人芸だ

この4つのルールはOMS内で優先順位に従って実行される。私の推奨順序は:納期コミットタグ → 在庫ウォーターライン → トータルコスト → タイブレーカーとしての距離。理由:約束はレッドラインだ。在庫の薄い倉庫への引当はインシデントを生む。コストは日々の最適化の主戦場だ。距離が効くのは、それより上がすべて同点のときだけだ。

一度に1つのルールを調整し、1週間回して、データを読む。分割率、平均運賃、遅延率。この3つをセットで読む。分割率は下がったが運賃が上がったなら、ウォーターラインが厳しすぎる。運賃は下がったが遅延が増えたなら、コストルールが納期ルールを押しのけている。2〜3ラウンド回せば収束する。

最後にもう1つ——フォールバックだ。「引当できる倉庫がない」場合の経路が必ず必要だ。全拠点が在庫不足か、システムが詰まったとき、注文が宙に消えてはいけない。例外プールに回して手動対応し、補充アラートを上げる。フォールバックのない設定を見たことがある。注文が4日間システムに滞留し、倉庫が気づく前に顧客には既に返金されていた。完璧なルールもフォールバックがなければゼロに等しい。

あなたのOMSの引当ルールを確認してほしい——最後に調整したのはいつか?答えが「稼働開始時」なら、この記事はあなたのために書いた。

英語版からの翻訳。内容に相違がある場合は英語版を優先します。