まず結論を言います。ERP と WMS を統合するなら、マスタデータが先です。常に。私は 30 件以上の本番稼働を回してきましたが、「まず受注系のインターフェースを立ち上げて、マスタデータの整備は後で」やったプロジェクトは、例外なく本番稼働の夜に爆発しました。うまくいった例外は一つありますが、運が良かったのではなく、マスタデータの仕事を誰かがちゃんと終わらせるまで、単に開始が遅れただけでした。
道路と交通にたとえてみましょう。統合は、ERP と WMS の間で購買発注と販売受注を動かす — これが道路です。マスタデータは道路標識です。品目コード、ロケーションコード、顧客マスタ。ERP の標識が「SKU-48213」で、WMS が「SKU48213」と読めば、交通は衝突します。インターフェースが動いていることは、本番稼働の準備ができたことではありません。この脚本どおりの展開を、私は三度見てきました。
マスタデータを後回しにすると必ず爆発する理由
2024 年夏。カリフォルニア州リバーサイドに自社倉庫を持つビューティーブランド — 50,000平方フィート、約4,000オーダー/日。顧客の IT 責任者はこう決めました。「マスタデータの整理は時間がかかりすぎる。まず PO と SO のインターフェースを立てて、マスタデータは本番後に埋め合わせよう。」
本番稼働の三日前、ERP が購買発注を WMS に送りました。エラー：品目が見つかりません。ERP の品目番号は「SKU-48213」、WMS は「SKU48213」として取り込んでいた — ハイフンが一つ足りない。どちらも引かない。インターフェース仕様には「品目番号をそのまま渡す」としか書かれていなかったからです。ゴミを入れれば、ゴミが出てくる。
さらに悪化しました。ERP には 6,000 件以上の有効 SKU があり、そのうち 400 件以上はゾンビ品目 — 廃番になり、復活し、また廃番になり、それでも価格テーブルに残っていた。本番稼働の朝、最初の入荷波が、ドックで「品目が未保守」エラーの山にぶつかりました。トラックが積み上がる。午後4時にようやく稼働開始、ドアには 12 台のトレーラーが渋滞。その夜の対応：ERP 側の品目新規作成を凍結し、WMS を品目マスタに宣言して、ERP に逆方向で同期。本番稼働は二週間ずれ込み、コンサル三週間分が余分に燃えました。
対照的に、翌年のオハイオ州のホームグッズ 3PL。初日に三つのコード体系 — 品目、顧客、ロケーション — を、本番稼働の八週間前にロックしました。倉庫に入ってくる新しい SKU は、まずマスタデータの審査を通さなければならない。受注系インターフェースの統合は最後、残りの二週間でやりました。本番稼働の夜に起きた問題は、ちょうど二つだけ。一つはフィールド長の不一致 — ERP で 20 文字、WMS で 30 文字 — 切捨てルールを入れて半時間で修正しました。私が回した中で一番スムーズな本番稼働の一つでした。
並べてみれば答えは明らかです。マスタデータ先行は慎重な選択肢ではなく、現実に触れても生き残れる唯一の選択肢です。マスタデータは二つのシステムの共通言語です。言語が統一されていなければ、会話が速くなるほど誤解は大きくなるだけです。
私の ERP-WMS 統合の回し方：七つのステップの手順
毎回同じプレイブックです。これに従えば大丈夫です。
-
何よりも先にコード体系をロックする。本番稼働の八〜十週間前に、品目コード体系、ロケーションコード体系、顧客/仕入先コード体系を確定 — 三者で署名。署名した者が、その後の変更に責任を持つ。署名後は凍結：特例は変更申請を通す。廊下での立ち話では済ませない。
-
マスタデータの各ドメインに、オーナーを一人ずつ決める。ERP も WMS も品目データを必要とするが、真実の源は一つだけ。私のいつもの分担：品目は ERP（財務と購買がそこにいる）、ロケーションは WMS（倉庫は自分の棚を知っている）、顧客は ERP、仕入先は ERP。オーナーが作って保守する。下流システムは読むだけ。
-
マスタデータの全件突合を一度やる。近道なし：ERP の有効品目を、WMS の実在庫と一本ずつ突き合わせる。狩るのは三つ — コードの不一致、名称/仕様の不一致、そして、業務実態はないのに帳票に出てくるゾンビ品目。あるプロジェクトでは整理でゾンビが 7% 見つかった。生かしたまま本番に入れば、時限爆弾です。
-
フィールドマッピング文書に、一つひとつ署名する。「だいたい動いてる」はなし — ヘッダ、明細、品目コード、数量単位、ロット番号、有効期限のすべてに、送り元、送り先、変換ルールを書く。特に数量単位：ERP がケース、WMS がピースだったプロジェクトを、私は四つ経験している。変換係数を一度でも間違えれば、一つのドキュメントバッチが丸ごとゴミになる。
-
マスタデータ系のインターフェースを、トランザクション系より先に立ち上げる。順序は譲れない：品目マスタ同期を稼働・突合完了 → ロケーション/顧客/仕入先を稼働 → 業務文書（PO、ASN、SO、返品）は最後。この順序を逆にすると、偽陽性に対してテストすることになる。
-
本物の汚いデータでテストする。テストシナリオにはいつもの容疑者を入れる：桁が一つ多い品目コード、末尾に空白のある顧客名、長すぎるロット番号。きれいなデータでしかテストしていない統合は、テストしていないのと同じ。
-
本番稼働前夜のチェックリスト（毎回使っています）:
- 三つのコード体系は凍結され、未処理の変更申請はゼロか？
- ERP→WMS の品目全件突合は完了し、差異ゼロか？
- ロケーションマスタは WMS と同期され、空ロケーションは検証済みか？
- ゾンビ品目は無効化され、新規文書が参照できなくなっているか？
- 数量変換係数は品目ごとにレビュー済みか？
- 業務一日のフルリハーサル（PO → 入荷 → 格納 → 波動 → 出荷 → コールバック）は、エンドツーエンドでグリーンか？
- 本番当日にインターフェースが大量障害を起こした場合のロールバック計画は？
マスタデータの同期頻度も、決めておく価値があります。品目・顧客・仕入先はほぼリアルタイムで動かすべきです。ERP で作られた品目は、夜間バッチではなく数分で WMS に届かなければならない。ロケーションマスタは WMS の中にあり、即時反映される。あるプロジェクトは品目同期を深夜に回していた。10 AM に、倉庫が新商品を出荷する必要ができたのに、その品目がまだ届いていなかった。ピック作業が作れませんでした。ほぼリアルタイムが最低ライン：遅延が 15 分を超えたら、インターフェースはアラートを上げるべきです。
トランザクション先行が許されるとき：ハイブリッド戦略
例外はあります。条件がこうなら：新設倉庫、レガシー在庫ゼロ、品目 500 件未満、文書タイプは二つだけ — ならハイブリッドで行きます。マスタデータのルールとトランザクション系インターフェースを並行で進めるが、マスタデータ系のインターフェースはやはり先に稼働させる。これは実質、マスタデータ先行の圧縮版です。
私が見た唯一の本物の例外：ERP は誰も触れないレガシーシステム、WMS は新築で、古い ERP にはマスタデータのガバナンスがまったくない。この場合の私の手は、すべてのマスタデータ権限を WMS に渡すことです — 品目・ロケーション・顧客は WMS が作る。ERP は文書を送り、コールバックを受けるだけ。「マスタデータは新しいシステムに従う」も、会話を始める前に言語を統一するという同じことです。
爆発注意：本番稼働の夜に爆発する罠
罠その一：フィールド長の不一致。ERP は顧客略称に 50 文字を許可、WMS は 30 文字しか受け付けない。本番前に誰も確認しなかった。顧客名は転送中に切断され、同じ顧客が二つのシステムで別名になる — 突合不能。対策：すべてのフィールドについて長さをマッピング表に書き、オーバーフロー方針（切捨てかエラー）を決める — どちらかにする。
罠その二：コードに埋め込まれた変換係数。一部のインテグレーターは「1 ケース = 24 ピース」をハードコーディングする。顧客が包装仕様を変える。インターフェースはエラーにならない。データは静かに三か月間おかしくなる。対策：係数は品目マスタのフィールドにし、品目と一緒に旅させる — ハードコーディングは絶対にしない。
罠その三：死んだ品目を参照する返品文書。品目は ERP で無効化されたのに、WMS の返品がまだそれを参照している。文書が届き、インターフェースは「品目が見つかりません」を投げ、返品処理が止まる。対策：品目を無効化する前に、WMS 側でそれを参照する未処理文書がないか確認する — 事前検証ゲート。
罠その四：組織次元の不一致。ERP の組織構造は WMS の倉庫コードと一対一にならない。インターフェースが組織コードを渡し、WMS はそれを間違った建物に解決する。対策：組織マッピングは専用のテーブルを持つ。品目マッピングに混ぜない。
次の ERP-WMS 統合プロジェクトでは、キックオフのホワイトボードの一行目を「マスタデータが先」にしてください — そして三者に署名させてください。感謝されるでしょう。この順序で回したプロジェクトは、どれも本番稼働の夜が静かでした。逆の順序で回したプロジェクトは、どれも深夜にパニックの電話をかけてきました。
Lin Xiao（WMS 実装コンサルタント）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
