午前 2:30 に電話が鳴った。カスタマーサービスからで、担当者は泣き出しそうな声だった。「お客様が注文されました。OMS は在庫 40 単位ありと表示しているのに、ピッカーがロケーションに行ったら——何もなかったんです。棚に段ボール箱の角すらありませんでした」
私はこの電話を何度も受けてきた。どのインシデントも展開は同じだ。IT は「インターフェースのログはクリーンだ」と言い、オペレーションは「帳簿はクリーンだ」と言い、両者は会議の間ずっと互いを責め合う。倉庫チームがとばっちりを受ける。過剰販売はその 1 件の注文だけでは済まない——マーケットプレイスのペナルティ、セラー評価の低下、悪いレビュー。フルコンボのコストは、その 40 単位の価値を遥かに上回る。
十分な件数を経験して、私は学んだ。OMS と WMS の在庫差異は、毎回同じ 5 つの根本原因に集約される。そして、どれに該当するかを突き止めるための固定の手順がある。順番通りに進めれば、ほとんどのインシデントは 30 分以内に特定できる。
数字が食い違うとき、原因はこの 5 つのうちどれか
誰かが言い争いを始める前に、責任の所在を正しく割り当てよう。先に言い争うのは、インシデント対応で最もコストの高い過ごし方だ。
1 つ目、同期遅延。ほとんどの OMS–WMS 連携はリアルタイムではなく、スケジュールに従って同期する。同期ウィンドウの内側では、2 つのシステムは食い違って当然——仕様であり、バグではない。「差異」の驚くほど多くは、5 分前の OMS の数字と今この瞬間の WMS の数字を誰かが比較しているだけだ。数量を比較する前に、タイムスタンプを比較しよう。
2 つ目、輸送中在庫の未控除。引当済み、ピッキング中、出荷ステージング済み——WMS は既にそれらの単位を「引当可能」から外しているのに、OMS はまだ手持ち在庫として表示している。ピークシーズンには 1 日に数千件の注文があり、輸送中在庫のボリュームだけで、2 つのシステム間に数百単位の差が生じることもある。
3 つ目、返品の受領済み・未計上。WMS は返品を受け入れて格納した。現物は戻っている。だが、その返品を OMS に計上するメッセージが失われたか失敗した。OMS はそれらの単位が販売済みだと思い続けているため、引当可能在庫は恒常的に低く表示され、差は広がり続ける。
4 つ目、循環棚卸の調整の未同期。WMS は棚卸を実施し、増減を計上したが、その調整が OMS に届いていない。時間とともに両者はどんどん乖離し、その乖離はランダムに見えるため、調査が悲惨になる。
5 つ目、壊れた複数倉庫マッピング。OMS の「Los Angeles DC」が WMS の 2 つの物理建物にマッピングされていたり、OMS で新しいフルフィルメント拠点が作られたのに WMS のマッピングテーブルに追加されていなかったりする。これが一番ずるい。各システムは内部的には整合しており、比較したときだけすべてが間違って見える。
私が使う経験則はこうだ。各システムが単体では正しく見え、比較したときだけ間違って見える場合は、マッピングか同期定義を疑え。差が時間とともに広がり続ける場合は、返品や棚卸調整のフローが止まったことを疑え。
実例を紹介しよう。昨年、家庭用品の EC 倉庫で、毎週月曜の朝に 200 から 300 単位の差が出て、週の残りはクリーンだった。手順通りに進めた——タイムスタンプ、輸送中、返品、棚卸はすべて問題なし。原因はこうだった。週末の夜勤シフトが、古い建物コードを使って WMS でロケーション移動をしていた。マッピングテーブルにそのコードのエントリがなく、調整のバッチ全体が OMS への途中で静かに破棄されていた。月曜朝に差が最大になり、平日の通常出荷で徐々に「希釈」されて、完璧な週間サイクルが生まれていた。差異にリズムがあるときは、数字だけでなくパターンを見よう。
壊れたら、責める前に手順を回せ
根本原因のタイプが特定できるまで、会議を招集するな、責任を割り当てるな。1 人、ノート PC 1 台、この順番で。
まずタイムスタンプを揃える。比較する前に両方の数字を同じ時点に持っていき、同期ウィンドウのノイズを除外する。このステップだけで、誤報の少なくとも 3 分の 1 がふるい落とされる。これを飛ばす人は多い。2 時間かけて調査し、最後に異なる時点を比較していたと気づく。
タイムスタンプを揃えても差が残るなら、輸送中を調べる。WMS で「引当済み・未ピッキング」「ピッキング中」「出荷ステージング済み」を合計し、その差と突き合わせる。一致したら、それは定義の問題だ。OMS の引当可能の計算式から輸送中を控除する必要があるか、オペレーションが「手持ち在庫」と「販売可能在庫」は別物だと理解する必要があるか、どちらかだ。
輸送中で説明できなければ、返品を調べる。WMS の直近 1 週間の返品受領を抜き出し、OMS の返品計上と 1 行ずつ突き合わせる。失敗リトライのキューには特に注意しよう。連携の多くはファイア・アンド・フォーゲットだ——失われたメッセージは、誰も監視していないキューに眠ったままになる。
返品がクリーンなら、循環棚卸を調べる。WMS の直近の棚卸調整をエクスポートし、それぞれに対応する OMS への同期レコードがあるか確認する。棚卸調整は低頻度だがインパクトが大きい。1 回のプッシュ漏れが、数ヶ月間差異を残し続けることがある。
最後に、マッピングを調べる。OMS の倉庫リストと WMS の物理建物リストを並べ、マッピングのエントリを 1 つずつ辿る。新規建物、ピークシーズンの一時的な前方在庫配置拠点、サードパーティの直送サイト——マッピングが抜け落ちるのはこういうところだ。マッピングが間違っていたら、最初の 4 ステップは無駄骨だった。土台そのものが歪んでいる。
この 5 ステップで、10 件中 9 件は故障箇所が特定できる。それから初めて責任分担の話をしよう。同期遅延はアーキテクチャの判断だから IT の持ち分。返品計上の失敗は連携の問題で、これも IT。棚卸の未プッシュはプロセスの問題で、オペレーションの持ち分。マッピングの破損は、たいてい建物オープン時に両者がすり合わせていなかったのが原因だから、これは折半だ。私の推奨は、役割分担を文書化して保管することだ。日次突合はオペレーション、インターフェースとジョブは IT がオーナー。何か壊れたら、手順を順番に回す。そうすれば、誰も先に文句は言えない。
次の午前2時の電話を待つのはやめよう
トラブルシューティングは消火活動だ。防火は 3 つの仕組み。どれも高くない。
1 つ目、日次の突合ジョブを回す。SKU ごとに OMS の引当可能と WMS の引当可能を比較し、しきい値を超えたら自動でアラートする。しきい値をきつくしすぎないこと——私はたいてい、5 単位超、または SKU の販売可能数量の 2% 超といった値を勧める。そうでないと、アラート疲れで 1 週間で全部死ぬ。アラートはメールだけでなく、作業用のグループチャットに送る。あのメールは誰も読まない。
2 つ目、棚卸調整を OMS にリアルタイムでプッシュする。月末にバッチ処理している会社はまだ多いが、それでは毎月数日間、2 つのシステムが互いに間違った状態になる。調整時プッシュに変えよう。技術的には API コールが 1 回増えるだけだ。
3 つ目、輸送中を OMS で可視化する。カスタマーサービスとオペレーションが、手持ち在庫の横に輸送中とステージング済みの数量を見られるようにする。孤独な手持ち在庫の数字 1 つではなく。過剰販売の電話が来たら、担当者は本当に在庫切れなのか、どこかのカートの上なのかを伝えられる——午前2時半に誰も起こす必要がなくなる。
この 3 つをやれば、差異はゼロにはならないが、午前 2:30 の電話は半分になるはずだ。
最後に 1 つ質問だ。今のあなたの OMS–WMS 在庫精度はどれくらいか？ 答える前に考えてほしい。その数字をどこで調べるか、誰がどれくらいの頻度でチェックしているか、どれくらいの差でアクションを起こすか。この 3 つに答えられなければ、午前2時半のあの電話はまた鳴る。問題は「いつか」だけだ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
