マルチ倉庫ソーシング:OMSがどの倉庫から出荷するかをどう決めるか
結論から: 受注が入ると、OMSは正確に4つの関門をこの順序で通す——在庫の有無、輸送リードタイムとコスト、倉庫の処理能力、そして特殊ルール。どの関門も倉庫を却下できる。在庫の関門がノーと言えば、その倉庫は脱落し、距離の審査にすら進まない。この順序を守ればソーシングはほぼ自動で回る。逆にすれば運賃請求と過剰販売が交互に月を台無しにする。
「一番近い倉庫から出す」とソーシングを扱った顧客を3社見てきた。3社とも授業料を払った。
2024年11月の話。カリフォルニアの小型家電販売店、倉庫は3拠点:ロサンゼルス、ダラス、ニュージャージー。同社のOMSのソーシングルールは1つだけだった:配送先住所に最も近い倉庫を選ぶ。実に合理的に聞こえる——距離が短い、運賃が安い、配送が速い、そうだろう?
ブラックフライデーの朝がそれを覆した。LA倉庫は買い手の大半に最も近かったが、売れ筋SKUはダラスにあり、LAには数十個しかなかった。OMSは忠実に受注の約80%をLAに振った。午後半ばにはLAは崩壊していた:6時間のピッキング滞留、ヤードにはUPSのトレーラーが積み込み待ちで並び、荷揃えは一向に終わらない。一方ダラスは20,000個を誰も触らず抱えていた。2日目はさらに悪かった——LAは在庫ゼロになったが、OMSは前日の在庫スナップショットで引当てを続けていた。受注は入り続け、倉庫は「在庫なし」と言い続け、カスタマーサービスは遅延の謝罪で溺れた。
12月上旬に後始末に呼ばれた。ログを見れば話は一目瞭然だった:OMSの問題ではなく、ソーシングルールの問題だ。処置はシンプルだった:在庫の有無を第1関門に引き上げ、処理能力のブレーカーを追加し、在庫同期を1日1回からリアルタイム引当てに変える。導入は2週間で、クリスマス商戦は持ちこたえた。
だから私は言い続けるのだ:「一番近い」はソーシングの4番目の考慮事項で、その前に3つの関門がある。順に見ていこう。
ソーシングの4関門
| 関門 | 次元 | 決めること | 誤設定で壊れるもの |
|---|---|---|---|
| 1 | 在庫の有無 | この倉庫に本当に販売可能な在庫があるか | 過剰販売、出荷遅延 |
| 2 | リードタイムとコスト | 在庫のある倉庫のうち、どこが最も速く安く出せるか | 運賃の爆発、納期約束の不履行 |
| 3 | 倉庫の処理能力 | この倉庫は今日の量を捌けるか | 滞留、運送会社の締切逸失 |
| 4 | 特殊ルール | VIP引当て、危険物制限、保税倉庫要件 | コンプライアンス露出、重要顧客のクレーム |
順序は交渉不可だ。在庫の有無は常に第1関門:在庫のない倉庫は即失格で、第2ラウンドに進むことすらない。「一番近い」を先に置くのは、まさにあのカリフォルニアの販売店が犯した間違いだ。
第2関門はリードタイムとコストが争う場で、ここに逆説がある:一番近い倉庫が必ずしも最も安く出せるわけではない。 UPS Groundでのダラス→シカゴは2日ルートだが、地理的により近いニュージャージーはゾーンとサーチャージの組み合わせで割高になることもある。あるいはLA拠点が1件ごとの取扱手数料を取る3PLで、ダラスが自社倉庫で手数料ゼロ、ということもある。本物のソーシングエンジンは第2関門を直線距離ではなく総フルフィルメントコストで順位付けする。ある案件では、距離のみのソーシングで月約$180Kの運賃がかかっていたが、総コスト順位付けに切り替えて$130Kを下回った。この$50Kの差は純粋な「一番近い倉庫」税だった。
ソーシングルールの設定:Go-Live前夜のチェックリスト
マルチ倉庫のGo-Live前夜に必ず回すチェックリストだ。順番通り、省略なしで。
1. まず在庫の定義を固める。 OMSが見る在庫は利用可能在庫でなければならない——手持ちから割当済み、引当て済み、QA保留を差し引いたものだ。仮想在庫(入荷予定PO、輸送中在庫)はソーシングプールに絶対に入れてはならない。入れるなら販売可能在庫と決して混ざらない別の先行販売プールに入れる。まったく同じ失敗を3回見た:仮想在庫を利用可能として計上し、OMSが引当て、倉庫が「そんなものはない」と言い、CSが謝罪を食らった。3回ともだ。
2. ルールエンジンを関門順に書く。 OMS管理画面でルール群を組む:(1) 在庫フィルター——在庫ゼロの倉庫を落とす、(2) コストとリードタイムの順位付け——残りを総フルフィルメントコストの安い順に並べる、(3) 処理能力チェック——日次スループット上限を超えた倉庫を重み下げか除外、(4) 特殊ルールの上書き——VIP顧客は特定拠点に固定、危険物は認定拠点からのみ、越境受注は保税倉庫から。各ルールに明確な「もしこうなら、こうせよ」をつける。「できれば」「可能な範囲で」は禁句だ。
3. 分割出荷ルールは別に設定する。 1受注3明細:倉庫Aに2明細、倉庫Bに1明細。分割するか、受注全体を保留するか。分割は速いが送料は倍、保留はコストを守るが納期約束が破れる。私のデフォルト:高額・納期厳守の受注は分割可(上限を設ける——最大2個口)、低額受注は最も多く持つ倉庫から完全出荷し、欠品明細はバックオーダーにする。Go-Live前に決めていなければ、繁忙期のCSは「なぜ私の注文が2箱で来たのか」に1日千回答えることになる。
4. ブレーカーとフォールバックを入れる。 倉庫ごとに日次処理上限を設定する(過去ピークの1.2倍)。上限に達したら新規受注は自動的に次点の倉庫へ。さらにセーフティネット:4関門をすべて通っても倉庫が割り当たらなかった受注は、SLA 15分の手動レビューキューに落とす。フォールバックのないOMSでは各倉庫が単一障害点になる。
5. 立ち上げ前に負荷テストをする。 前年の繁忙期の受注量3日分をテスト環境のソーシングに流す。見る数字は3つ:過剰販売率(ゼロでなければならない)、1受注あたりの平均フルフィルメントコスト、最も忙しい倉庫のピーク負荷(85%以下に抑える)。3つとも通って初めて承認する。

もう1つの話:ソーシングが正しければ、節約は本物のお金になる
2025年3月。テキサスのペット用品小売店、倉庫は4拠点:ダラス、アトランタ、シカゴ、ロサンゼルス。同社のソーシングは手作業だった——CSのリーダーが毎朝在庫スプレッドシートを目視し、手で受注を割り振っていた。繁忙期は1日4,000受注で、「ソーシングの夢を見る」と言っていた。
導入した設定は派手なものではない:在庫の有無が先、コストが次、処理能力ブレーカーが3番目、あと特殊ルール1つ——フロリダ向け受注はアトランタ優先(ハリケーンシーズンの物流経験の知恵だ)。稼働1か月目、1受注あたりの平均フルフィルメントコストは$1.10下がった。1日4,000受注なら月約$130Kだ。オーナーの言葉そのままに:「このルールセットでCS担当3人分が浮いた」。
ただし正直な注意書き:ソーシングロジックは設定して終わりではない。運送料金は毎年変わり、処理能力は季節で動き、新倉庫が増えるたびに関門の順位付けをやり直す。私は顧客に四半期ごとのソーシングルール見直しを伝えている。棚卸のサイクルカウントと同じ頻度だ。交渉不可だ。
よくある失敗点:Go-Live前にもう一度読む
失敗1:在庫を無視して距離だけでソーシング。 これが最初の話だ。距離はコストの入力項目であって、資格ではない。在庫ゼロの倉庫は、距離ゼロでも無価値だ。
失敗2:仮想在庫がソーシングプールに漏れ込む。 輸送中在庫、未入荷PO、QA保留——どれも引当てできない。この落とし穴を3回見た。毎回過剰販売だ。
失敗3:処理能力ブレーカーなし。 ピーク時、全受注が「最適」倉庫に殺到し、その倉庫が一番悲惨な倉庫になる。日次スループット上限はソーシング盤のヒューズだ。省くな。
失敗4:分割出荷ルールなし。 分割禁止なら納期約束が崩壊し、分割自由なら運賃が倍になる。分割には明示的なコスト閾値が必要だ。
失敗5:ルールを設定したきり見直さない。 ソーシングルールは生きている——料金も処理能力もネットワークも動く。設定して忘れれば、半年後には間違っている。
ソーシングは4関門と5項目のチェックリストに尽きる。結論は冒頭に、手順は上に全部、落とし穴には印をつけた。残るはGo-Liveの夜にチェックリストを1項目ずつ回すことだけだ。近道はない。
Lin Xiao(WMS導入コンサルタント)著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。







