結論から先に言います。注文番号がシステム間で一致しないとき、連携そのものが壊れていることはほぼありません。壊れているのは、誰も管理していないマッピングテーブルです。
2023年秋、カリフォルニア州オンタリオ郊外の60,000平方フィート超のアパレル系3PL。カスタマーサービスの責任者から相談を受けました。彼女のチームは「注文はどこ」問い合わせのチケットに埋もれていたのです。オンラインストア上ではすべての注文が「出荷済み」になっているのに、追跡番号をクリックすると「そのような出荷はありません」と出る。ひどい場合は他人の荷物が表示される。IT部門は1週間ログを調べましたが、すべてのインターフェースはグリーン——OMS、WMS、キャリアAPI、エラーはゼロでした。
その3か月前、WMSのアップグレードで分割後の子注文番号の生成ルールが変わっていました。OMS側には誰も伝えず、OMSは従来の方法でIDを組み立て続けます。キャリアから追跡番号が戻ってくると、ライトバックのロジックはID文字列への推測で注文に紐づけていました——推測を外せば、追跡番号は違う注文に着地する。パイプは正常だった。壊れていたのは「あるシステムのIDが、別のシステムでも同じ意味を持つ」という前提でした。
この展開は20年で少なくとも10回見てきましたが、オンタリオでの発見の瞬間こそ、グリーンなログが嘘をつく理由を示しています。ITリーダーが問題の注文を1件取り出し、画面を1つずつ一緒に辿りました。OMSでは注文88412、出荷済み、追跡番号付き。WMSでは注文88412が2件の子ピッキングに分割されている——しかし子番号は新方式の88412-Aと88412-Bで、OMSのライトバックは旧パターンの88412-01と88412-02にマッチし続けていた。追跡番号は無事に戻ってきたのに、紐づけ先はどこにも存在しない注文番号だった。すべてのAPIは仕事をしていた。IDの形に関する取り決めが片方で書き換えられ、もう片方では再合意されていなかったのです。
チェーンは3つの予測可能な箇所で切れる
注文の旅には4つの停留点があります——OMSの親注文、WMSのピッキングと荷物、TMSとキャリアのラベルと追跡、OMSへのステータスのライトバック——そして3つの予測可能な継ぎ目があります。
まず分割出荷。OMSでは注文は1つの番号です。WMSの中では、在庫の場所に応じて2つのウェーブと3つの荷物に分割され——その子番号はWMSの中にしか存在しません。OMSは子が存在することさえ知りません。追跡番号は親宛てで戻ってくるため、子番号で検索しても何もヒットしない。さらに厄介な変種が部分出荷です。3つの荷物、2つのキャリア、3つ目は在庫不足。OMSは親全体を「完了」とマーク——顧客には2箱が届き、3つ目の追跡番号は孤児になります。
2つ目の継ぎ目は追跡のライトバック。キャリアが追跡番号を発行し、TMSがそれを取り込む——そしてライトバックが違う注文を指してしまう。典型例はこうです。ラベルがずれて印刷され、誰かが再印刷する。古い追跡番号が無効化されず——1つの荷物に2つの有効な番号がぶら下がる。顧客とカスタマーサービス担当がそれぞれ別の番号を追跡する。全員が正しく、全員が間違っている。
3つ目の継ぎ目はバッチとパレットで、これはB2B向けの話です。小売業者は856事前出荷通知を要求し、実物のパレットのSSCC-18シリアル番号は、ASNのパックレベル番号と1文字1文字一致しなければなりません——1桁違えばパレット全体が却下されます。かつてWMSでパレットIDを自動生成しながら、945出荷通知を手入力している倉庫を見たことがあります。その2つの番号はそもそも同じものではありませんでした。3か月後の突合で爆発し、チャージバックの総額はまともなフォークリフトが買えるほどでした。
連携はデータを動かし、マッピングテーブルはデータを一致させる——そして後者の仕事に、すべての問題が埋まっています。
返品フローにも罠があります。荷物がRMA番号に紐づいて倉庫で受け取られるのに、OMSの返金は元の注文番号にぶら下がる。RMAから注文へのマッピングがなければ、経理には孤児の返金が残ります。私が見た最悪のケースは、1か月で数百件の未突合の返金。オペレーションは1週間かけて手作業で突き合わせました。
マッピングテーブルは地味に徹する
私の追跡手法は1つの動きだけです。チェーンを辿る、スキップなし。まずそのIDが親か子か、どのシステムで生まれたかを突き止める。下流へ1ホップずつ進む。IDが繋がらなくなるホップが断絶点です。10回中9回は2ホップ目までに見つかります。
データを直す前に3つの質問を。マッピングを書いたのはシステムか、人が手で打ったのか。最近ルール変更はあったか。同じ壊れ方をしているのは他に何件あるか。1レコードを直すのは火消し。バッチで直すのがトラブルシューティングです。オンタリオのケースでは、過去3か月分の誤マッピング追跡番号をすべて正しい場所に紐づけ直すスクリプトを書きました——1回の処理で4千件超の注文。1件ずつクリックしていたら、カスタマーサービスは来年までかかっていたでしょう。
次に堅牢化。5つのルール、どれも授業料を払って学んだものです。
1つの正準テーブル。注文→子、子→荷物、荷物→ラベル、ラベル→追跡番号、そしてバッチとパレットへ——すべてを1つのマッピングテーブルに集約し、システムの中に置き、名指しの管理者と変更ログを付ける。腐敗したマッピングテーブルには共通の組織的問題がありました。OMSチームはWMSチームが管理していると思い、WMSチームは3PLのEDIアナリストが管理していると思い、アナリストは「ただの参照資料」だと思っていた。1人の名前を付ける——毎月変更ログをレビューし、すべてのアップグレード、キャリアのオンボーディング、小売仕様の変更に同席する人。オンタリオの事故は、WMSのアップグレードにOMS側の誰も読まなかったリリースノートが付いていたために起きた。管理者がいれば、5分の差分レビューで見つけていたはずです。
IDに名前空間を付ける。すべてのIDに生まれたシステムのプレフィックスを付け、WMS生まれの番号がOMS生まれの番号と衝突しないようにする。荒っぽく聞こえるかもしれませんが、私は3回救われました。2つのシステムはどちらも素朴な連番整数が大好きで、プレフィックスがなければ必ず衝突します——かつて2社の3PL顧客の注文が1つのWMSに流れ込み、両方とも10001から始まっていて、システムが顧客Aの荷物を顧客Bの注文に紐づけてしまったことがあります。パレット1台分が間違った顧客に出荷されました。
荷物IDをエコーバックする。追跡番号が戻ってくるときは、出ていったときの荷物IDを一緒に運ばせなければなりません。素の追跡文字列だけでは逆向きに辿れません——ラベルを2回再印刷したら、その追跡番号がどのOMS注文に属するのか当てられません。856にはこのための構造がすでに入っています——船荷証券参照として追跡番号を運ぶREFセグメントを、キャリア独自の番号と一緒に。使いましょう。
毎日突合する。定期ジョブを回す。WMSでは出荷済み、OMSでは更新待ち、キャリアの追跡イベントあり。この3つの集合を差分する——落ちた分が、明日カスタマーサービスが怒られる種になります。3つのバケット。WMSでは出荷済みなのにOMSが一度も更新されていない——ライトバックの紛失。OMSは更新されたのにキャリアのイベントがない——ラベルは印刷されたが貨物は動いていない。どちらにも記録がないキャリアのイベント——大抵はテストラベルか、再印刷の古い番号。まず分類、それから対処。
分割ロジックをバージョン管理する。分割ルールの変更はすべて、まずテスト環境でマッピングに対して検証する。2分のチェックが、3か月遅れました。
最初に決めておくべきトレードオフが1つあります。追跡のライトバックにおける、キャリアのリアルタイムコールバックとバッチ突合のどちらを選ぶか。リアルタイムは速いが、コストが高く、コールバックは取りこぼす。バッチは半日遅れだが岩のように堅い。小規模オペレーションは恥ずかしがらずにバッチで回し、ピークシーズンの2週間前にリアルタイムに切り替えればいい。節約分では、午前2時の火消しの残業代はまかないきれません。
もう1つの「不一致」がありますが、これはIDの問題ではありません。時刻です。WMSは太平洋時間で出荷を記録し、OMSはUTCで解釈する。同じ注文が、システムごとに1日ずれて着地する。担当者は「今日の出荷」を検索して何も見つからず、IDが消えたと思い込む。タイムゾーンをまたぐ倉庫はこの罠に常にはまります。IDを疑う前に時計を疑いましょう。
では、あなたへの質問です。ITチームに聞いてみてください。IDマッピングテーブルを最後に開いたのはいつかと。答えが「何かが壊れたとき」なら、次の断絶はすでに進行中です。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
