深夜の火曜日、9時40分にオペレーションマネージャーから電話がかかってきた。計算はすでに済んでいて、その答えが気に入らないときに人が見せる、あの平坦な冷静さが声にあった。「今夜このSKUを300個売りました」と彼は言った。「WMSは在庫ゼロと出ています。OMSはまだ40個あると言っています。」
どのシステムも壊れていなかった。彼の受注管理システムと倉庫管理システムの連携は、設計どおりに正確に動いていた。問題は設計そのものだった。上流に流れ戻る在庫数値にとって「動いている」が実際に何を意味するのか、誰も問わなかったのだ。その40個のギャップが同期遅延であり、誰かが気づいた頃には、過剰販売の注文はすでにシステムに入っていた。
私はこの映画を何度も見すぎて、筋書きを暗記している。OMSからWMSへの方向——注文が下流に流れる方向——は導入時にすべての注目を集める。復路である、上流に流れ戻る在庫は、後付けで作られる。そしてそこでお金が漏れ出す。
OMS画面の数字は履歴であり、ライブ映像ではない
実際のデータの流れを追ってみよう。注文はすべての販売チャネルから入ってきて、ルーティングと割当のためにOMSに着地し、ピッキング・梱包・出荷のためにWMSに落ちる。逆方向では、WMSは受領、棚入れ、ピッキング、棚卸調整をOMSに報告しなければならず、OMSはそれを受けて販売可能数量を各チャネルに押し出す。この復路こそ遅延が潜む場所であり、原因は3つある。
1つ目は同期頻度だ。いまだにスケジュール実行の連携は多い——15分ごと、30分ごと、時には1時間ごとだ。つまりWMSで8時05分にピッキングされた200個は、次のスケジュール実行までOMSに反映されない。夜のピーク帯では、この時間枠こそ過剰販売が起きるタイミングだ。イベント駆動のプッシュ（受領を登録したら、棚卸調整を承認したら、すぐに更新を飛ばす）に変えればギャップは塞がるが、API呼び出しは倍増し、レート制限とインフラコストに真正面からぶつかる。これは技術パズルではなく、ビジネスのトレードオフだ。
2つ目は、誰も気づかない同期失敗だ。バッチジョブがエラーを出し、3回リトライして、静かに死ぬ。あまりに多くの現場で、失敗時のアラートがない——オペレーションは翌朝、在庫更新が6時間前に止まっていたことを知る。WMSでは棚卸調整が正常に登録されたのに、上流への同期ジョブが詰まって、チャネルが2日古い数字で48時間売り続けた倉庫を私は見たことがある。
3つ目は人間の遅延だ。貨物はドックにあるのに、受領がまだシステムで確定していない。棚卸差異がスーパーバイザーの承認待ちキューに座っている。システムの遅延は分単位で測られるが、人間の遅延は時間や日単位で測られる。私が調査した「同期精度」の苦情の半分は、システムの衣装を着たプロセス問題だった。
過剰販売の注文はキャンセル以上のコストがかかる
遅延をITチケットではなく金の問題として扱う理由はここにある。過剰販売は連鎖を引き起こし、その一つひとつがコストになる。
まずキャンセルが来る。出品者起因のキャンセルは、マーケットプレイスに送り得る最悪のシグナルの一つだ。Amazonのポリシーは、出品者起因の出荷前キャンセルを7日ウィンドウで2.5%未満に、注文不良率を60日ウィンドウで1%未満に抑えることを求める——この線を越えれば販売権限の制限が待っている。ピークの夜の数十件の過剰販売だけでキャンセル率が吹き飛ぶこともあり、アカウントの健全性は一夜では回復しない。
次にカスタマーサービスの負荷が来る。返金、謝罪、ネガティブレビュー。過剰販売の注文1件に対応する人件費は、その注文が稼いだはずの利益を上回ることが多い。そして最も静かなコストは応急処置だ——一部の出品者は他の調達先から商品をかき集めて、倍の運賃で遅れて発送する。悪いレビューを稼ぐためにお金を払っているようなものだ。
遅延をゼロにはできない。でも縮められるし、備えることもできる
結論から言う。OMSとWMSの同期遅延は決してゼロにはならない。2つのシステム、ネットワークのホップ、APIのレート制限——常に数秒から数分の遅れは残る。目標は、遅延をビジネスが吸収できる大きさに縮めることであり、その残りにはガードレールを築くことだ。
縮めるには3つの設定判断がカギになる。1つ目、重要なイベントはリアルタイムにすること。棚入れ完了と棚卸調整の承認は、即座にOMSへプッシュすべきだ。下流に流れる注文はバッチのままでいい。上流に流れる在庫は、予算の許す範囲でイベント駆動にすべきだ。2つ目、正しい項目を同期すること。WMSが送るべきは販売可能数量——手持ち在庫から引当済みと品質保留を差し引いたもの——であり、総在庫ではない。総在庫をそのまま渡してOMSに販売可能として扱わせていた連携を、私は監査したことがある。あれは組み込みの水増しだ。3つ目、複数倉庫のマッピングをきれいに保つこと。1つのSKUが3つの建屋にあるとき、OMSの合算から輸送中と凍結在庫を除外しなければ、「利用可能」の数字はフィクションだ。
保険は2つある。1つ目、人気SKUには安全バッファを確保すること。実際の利用可能数量が500なら、OMSには460を掲載して、遅延時間枠への備えとして40を残す。少しの売り切りを犠牲にして保護を買う——バッファの大きさは、そのSKUの過去最悪の時間当たり販売率に同期間隔を掛けた程度にし、少なくとも1回分の遅延サイクルをカバーできるようにする。2つ目、差異アラート付きの日次照合を回すこと。1日1回、夜間の静かな時間帯に、両システムの在庫スナップショット全体を比較し、差異がしきい値を超えたらアラートを上げる。照合は経理劇場ではない——怒った顧客から正午に知るのではなく、朝6時に死んだ同期ジョブに気づくための仕組みだ。
深夜にトラブルが起きたら、この3つを確認する
過剰販売の注文がキューに溜まっている？犯人探しは始めない。この手順で進めれば、たいてい30分以内に根本原因にたどり着く。
まずWMSのトランザクションログを確認する。事故の時間帯の前後で、そのSKUの大きなピッキング、棚卸調整、受領登録を探す。「謎の過剰販売」の驚くほど多くは、逆方向に登録された棚卸調整か、二重に受領された返品が正体だ。
次に同期ジョブのログを確認する。OMSが持つそのSKUの在庫スナップショットの最終タイムスタンプを見る。スナップショットが3時間前のものなのに、注文が1時間前まで流れ続けていたなら、犯人は遅延だ。失敗したリトライには特に注意する——タイムアウトか、レート制限か、データ形式の不一致か？
最後にOMSの割当ロジックを確認する。割当時点で使われた利用可能数量に安全バッファが含まれていたか、引当済みだがまだリリースされていない注文が二重計上されていないかを確認する。割当のバグと同期遅延は一緒に現れるのが大好きで、片方だけ見ても組み合わせはつかめない。
見つけたら、その事故を照合ルールに書き込む——次はカスタマーサービスが動く前にアラートが鳴るべきだ。
明日の最初の仕事：自社のOMSの在庫同期がスケジュール実行か、リアルタイムプッシュかを確認して、間隔を書き留めること。その数字が、過剰販売への反応時間だ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
