システムは手持ち500単位と表示している。カスタマーサービスが販売できるのは300単位だけ。そこにキャンペーンが始まり、店舗サイトは「在庫あり」と表示し、倉庫は「そんな在庫はない」と言い、過剰販売のペナルティが降りかかり始める。私が見てきたOMS導入の10件中9件は、壊れた在庫モデルから始まっている。問題はシステムではない——問題は「在庫」が1つの数字として扱われていることで、実際には4本の水位線なのだ。
手持ち在庫は販売可能在庫ではない
1本目の水位線は手持ち在庫：WMS上のSKU総数だ。多くの企業はこの数字をそのまま店舗サイトの販売可能数として押し出す。それが過剰販売の原因ナンバーワンだ。その手持ち総数には、販売できない在庫が何種類も混ざっている：品質検査保留の単位、不良品として処分待ちの単位、棚卸ロック中の単位、再販可否の格付けがまだの顧客返品だ。
対策：OMSが認識すべきは「販売可能手持ち」だけ——凍結・検査保留・不良の単位をすべて差し引いた数だ。このフィルタリングはWMS→OMSインターフェースの中で、在庫ステータスでハードコードすべきであり、日々の手動突合せでやるものではない。化粧品EC企業と仕事したとき、返品の再販率は60%だったが、平均4日間「格付け待ち」に滞留していた。その4日間を販売可能として数えれば、過剰販売は確実だ。
引当：在庫にはもう持ち主がいる
2本目の水位線は引当済み在庫だ。注文が落ちた瞬間、OMSは対応する在庫をかみ取る。まだ棚に置いてあるが、持ち主は決まっている。引当には2種類ある：特定ロット・特定ロケーションに紐づき、誰も触れないハード引当と、正確なピッキング場所が後で決まるまで数量だけ押さえるソフト引当だ。
落とし穴は引当の解除にある。注文キャンセル、一部欠品、支払いタイムアウト——引当は即座に解除されるか？解除が早すぎると、同じSKUの別の注文がそれを奪う。解除が遅すぎると、ゾンビ注文が店舗で売れない在庫に居座る。私のデフォルト：支払いタイムアウトの引当は30分後に自動解除、オペレーターがキャンセルした注文はリアルタイム解除、一部欠品の注文は欠品ラインだけ解除して確定ラインは残す。これらはサービスチームのクリック作業ではなく、OMSのポリシーとしてコード化せよ。
輸送中と検査保留：未来を売る
3本目の水位線は輸送中在庫：発注済み、未入荷だ。優れたOMSは輸送中を到着予定日でセグメントする。3日以内に到着？その一部を先行販売できる。15日先？在庫切れと表示して、その通りにせよ。先行販売比率はサプライヤーの過去の納期遵守率に従うべきだ——95%超なら80%の先行販売は正当化できる。慢性的な遅延常習犯には先行販売ゼロだ。
検査保留は兄弟分の問題だ。商品が到着し、検査ゾーンに置かれ、WMSがまだ格納していない。その間、OMSは販売可能在庫に加算するのではなく「輸送中／検査中」と表示すべきだ。検査サイクルの長いカテゴリー——食品、化粧品、家電——では品質検査に2日から1週間かかることがあり、その在庫状態が見えなければカスタマーサービスと倉庫は毎日ケンカする。
安全在庫：みんなが奪い合う緩衝材
4本目の水位線は安全在庫、不確実性への緩衝材だ：サプライヤーの遅延、需要の急増、棚卸差異。勘ではない——計算は単純だ：SKUの過去90日間の平均日販と変動を取り、補充リードタイムの変動と組み合わせる。両方が荒いほど、緩衝材は厚くなる。ABC分類がここで本領を発揮する：A品目は日単位で安全在庫を計算、C品目はどうせ安いので概算でよい。
安全在庫の最大の敵は「借用」だ。キャンペーンが始まり、オペレーションが緩衝材に積まれた単位を見て売ってしまう。すると日常の注文が欠品する。鉄則を作れ：安全在庫に触るには承認が必要で、触れば補充が発動する。SOPに書け——どんなソフトウェアより効く。
マルチ倉庫：建物ごとに水位線を分ける
ここまで全部、単一倉庫の発想だ。マルチ倉庫の企業は水位線を施設ごとに計算してから集計しなければならない。なぜか？倉庫Aの「在庫あり」は、3日間の輸送を挟んだ倉庫Bの顧客には何の意味もないからだ。
標準パターンは最寄りフルフィルメント＋倉庫別ATPだ。各建物が4本の水位線を自分で計算し、注文ルーティングは販売可能在庫のある最寄りの建物を優先する。全建物の販売可能数がゼロのときだけ、倉庫間転送によるフルフィルメントを許可すべきだ——そして転送の輸送時間は約束納期に入れる。一部の企業はネットワーク在庫を集計してきれいな「在庫あり」バッジを作り、空の建物に注文をルーティングして、社内転送の嵐の中でSLAが崩壊するのを見守る。覚えておけ：集計数は管理ダッシュボード用、フルフィルメントは建物別の数で回す。
転送自体もモデルに入れる。転送オーダーが確定した瞬間、出荷建物の販売可能数は即座に減り、受領建物の輸送中に到着予定日が加わる。転送をグループチャットで回し、システム文書なしで済ませる企業が多すぎる——帳簿は永遠に合わない。転送はシステムトランザクションでなければならない。交渉の余地なし。
すべてをつなぐ1つの式
販売可能数 = 販売可能手持ち − 引当 − 安全在庫 + 確定済み輸送中（時間フェーズ別・割引済み）。
式は簡単、難しいのはデータ品質だ。過剰販売したら、システムを怒鳴るな——このデバッグ手順を辿れ。1：手持ちは正確か？まず数えろ。帳簿と現場が合わなければ、他は全部無意味だ。差異の隠れ家である検査ゾーンと返品ゾーンは特に注意せよ。2：引当は時間通りに解除されているか？死んだ注文が抱えるゾンビ引当のレポートを引け——販売可能在庫の5%を超えたら、ルールを変えろ。3：輸送中の日付は正直か？サプライヤーを6か月の納期遵守で採点せよ。慢性的な楽観主義者には先行販売比率ゼロだ。4：安全在庫は奪われたか？キャンペーン期間の動きをチェック——承認なしに動いていたら、補充の前にプロセスを直せ。
この手順で10回中9回は根本原因が見つかる。残りの1回はたいていインターフェースの遅延だ：WMS→OMS同期が15分バッチで回っていると、繁忙期はその死角の時間帯に売りも受けも大量に発生する。キャンペーン中は同期をリアルタイムか1分間隔に引き上げろ。サーバーコストの上乗せは、過剰販売のペナルティより安い。
最終結論：OMS在庫モデリングに銀の弾丸はない。鉄則は1つだけ——在庫ステートを細かく分けるほど、過剰販売は減る。ステート分割を怠けた企業は、ペナルティという授業料を払うことになる。4本の水位線を正しく引けば、サービスが売っていい数字は、倉庫が実際に持っている数字とついに一致する。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
