ERPとAdobe Commerceの連携：出荷と在庫を正しく回す

ERPとAdobe Commerceを結ぶプロジェクトの多くは、接続の問題として要件定義され、実際には合意の問題であることが判明します。受注をERPへ流す技術は何年も前に解決済みです。解決されていないのは、あなたの会社において、どのシステムが正しくあってよいのかという点です。

本稿では、判断が必要になる順に整理します。この連携は何のためにあるのか、どの方式の上に作るのか、受注処理と在庫についてデータはどう流れるべきか、そして稼働し続けるために後から何が必要になるのか。これらの連携が本番でどう壊れるか——在庫のずれ、価格の往復、受注伝票の重複——については、対になる記事MagentoとSAPの連携で、実際に壊れるのはどこかをご覧ください。

オブジェクトの一覧ではなく、成果から始める

最初に作られがちな成果物は、同期する対象の一覧です。商品、顧客、受注、在庫、請求書。これは出発点として間違っています。すべてを動かすのに、特に何も改善しない連携ができあがるからです。

そうではなく、お金を払って取り除こうとしている業務上の問題から始めてください。実務上、それはほぼ必ず次のいずれかです。

• 受注をERPに手入力しており、人件費がかかり、入力ミスも生じている。
• サイトが倉庫にない在庫を約束してしまい、キャンセルと返金が発生している。
• 顧客が問い合わせなしには注文状況を確認できない。
• 財務が月末に2つのシステムを手作業で突き合わせている。
• 価格変更が店舗に届くのが遅い、あるいは二重に届く。

それぞれが、特定のデータフロー、特定の方向、特定の遅延要件に対応します。構築前に、それぞれの現在のコストを書き出してください。週あたりの作業時間、キャンセル率、問い合わせ件数。この基準値こそが、後になって連携が効いたかどうかを教えてくれるものであり、そして誰も記録しないものの筆頭でもあります。

そのうえで、受け入れ基準を同じ言葉で合意します。「受注が5分以内に手入力なしでERPに現れること」は検証できます。「システムが連携されていること」は検証できません。

連携方式を選ぶ

大きく3つの方式があり、正直に言えばどれも機能します。失敗するのは、適合性ではなく好みで選んだときです。

どんな機能比較より確実に方式を決められる問いが2つあります。

ERPはどれだけカスタマイズされているか。 10年にわたり拡張されてきたシステムが、コネクタの前提に合致することはめったにありません。その時点でどのみち変換ロジックを書くことになり、判断は「書くかどうか」ではなく「そのロジックをどこに置くか」に変わります。

3年後、システムはいくつあるか。 答えが「ERPと店舗」なら、直接連携が身の丈に合っています。「ERP、POS、倉庫システム、マーケットプレイス3社」なら、ハブはコストに見合います。1対1の接続は、システムそのものより速く増えていくからです。

後者はマレーシアの多チャネル小売でよく見られる状況であり、当社がBridziaのマーケットプレイス同期技術WOW Syncを開発した理由でもあります。Thunder Match Technologyでは、ERP／SAP、自社EC、実店舗、主要マーケットプレイスを接続し、商品・価格・在庫・受注の更新をチャネルごとではなく一度で済ませられるようにしました。賢い受注振り分けと、倉庫と店舗をまたいだ在庫の共有プールも備えています。TMTからは、マルチチャネル受注管理の人件費を最大3×削減できたとの報告を受けています。

データフローを設計する

連携頻度は、連携全体に対する1つの決定ではありません。オブジェクトごとの決定であり、どちらの方向に誤っても高くつきます。一括処理をイベント駆動にすればERPが溢れ、受注をバッチにすれば顧客が待たされます。

この表のうち3行が、リスクの大半を抱えています。

販売可能在庫は数字ではなく計算式です。 ERPが非制限在庫として持っている数量は、店舗が約束してよい数量ではありません。未出荷の受注に対する引当、保留在庫や品質検査中の在庫、輸送中の在庫、安全在庫が、両者の間に挟まっています。サプライチェーン部門と明示的に計算式を定義し、ERP側で算出し、店舗側は1つの数字を受け取るだけで独自の計算はしないようにします。

受注は冪等でなければなりません。 危険な失敗はきれいなエラーではなく、ERPが伝票を作成したのに店舗側がそれを知らないまま終わる、判然としないタイムアウトです。すべての受注に安定した参照番号を付けて送り、ERP側は何かを作成する前に既存伝票の有無を確認します。これが再送を安全にし、安全な再送だからこそ積極的に再送できます。

コンテンツの所有権は、前提ではなく強制です。 夜間のERP連携が手書きの商品説明とメタディスクリプションを黙って上書きすると、実際の作業成果が静かに壊され、たいていは流入の変化に気づいた誰かが数週間後に見つけます。項目ごとに所有権を決め、所有していない項目には連携が書き込めないようにしてください。

もう1つ、全体に効く設計ルールがあります。ERPをリクエストの経路から外すこと。 カート投入、購入手続き、注文確定のいずれにも、自社で制御していないシステムの応答を待つ処理があってはいけません。注文を確定するのと同じトランザクションでアウトボックスに書き込み、送信はワーカーに任せます。これで購入手続きはERPの稼働状況に依存しなくなり、すべての注文が問い合わせ可能な状態を持ちます。

起きがちなことと、設計上の対応

失敗のパターンはSAP編の記事で詳しく扱っています。ここでは要点と、それぞれに対応する構造的な対策を並べます。

• 店舗と倉庫の間で在庫がずれる。 差分配信に加えて低頻度の全件スナップショット、メッセージへのタイムスタンプ付与、順序が逆転したメッセージは適用せず破棄。
• 価格が2つの値の間を行き来する。 1つの項目に書き込むのは1つだけ。基本価格はERPが持ち、店舗側のルールエンジンがその上に販促を計算して書き戻さない。
• 再送の後に受注伝票が重複する。 安定した参照番号をキーとする冪等性を、伝票作成前にERP側で確認。
• 再送の嵐が障害を悪化させる。 失敗を再送可能なものと最終的なものに分類。前者はジッター付き指数バックオフと試行上限、後者はデッドレターキューと通知。
• マスタデータの不一致。 販売組織に拡張されていない品目、単位の違い、得意先マスタのない顧客。片側にしか存在しないレコードを読み飛ばすのか、報告するのか、販売停止にするのかを決め、SKUの文字列一致ではなく安定した識別子をキーとする明示的なマッピングテーブルを持つ。
• 合計金額が1セント違う。 小数精度、丸め方向、課税基準——明細単位か伝票単位か——をアーキテクチャ設計の段階で確定させ、税率の異なる商品にまたがるパーセント割引と割引済み送料明細で検証する。

マレーシアで事業を行う場合は、最後の項目にSSTの扱いを明示的に加えてください。どの時点で課税し、両システムでどう表現するのかが一致していないと、丸めの不具合にしか見えない理由で財務が伝票を却下します。

稼働開始後の運用

連携は成果物ではなく、サービスです。動き続けさせるために必要なものを挙げます。

初日からの突合。 稼働中のカタログ全体について、販売可能在庫と基本価格を毎晩比較し、合意した許容差の内側なら自動補正、外側なら通知する。加えて、ERP伝票のない店舗側の注文とその逆を一覧にする日次の受注チェック。出力は、担当者が名指しで決まっている短いレポートであるべきです。普段は空のレポートだからこそ、空でないときに気づかれます。

業務上の問いに答える監視。 キューの滞留量、メッセージの経過時間、種類別の失敗件数、デッドレターの件数を、開発用のダッシュボードだけでなく、サポートと運用が見える場所に出すこと。

双方に名前のついた責任者。 長引く連携障害の多くは組織の問題です。コマース側とERP側が、互いに相手が調査中だと思っています。

変更管理の規律。 ERPのバージョンアップ、新しい販売組織、新しい商品タイプ、新しいマーケットプレイスは、いずれも連携に触れます。後から発見するのではなく、ERP側の変更管理プロセスに載せてください。

繁忙期前の負荷テスト。 これらの連携は、ワーカーが処理する速さよりキューが積み上がる速さが上回ると挙動が変わります。処理能力が足りなくなったときに何を落とすのかを事前に決めてください。多くの場合、在庫更新の頻度が受注送信に譲ります。

下流のシステムは、連携が生み出したものをそのまま受け継ぎます。EC Intelligenceで構築するセグメンテーションやライフサイクル施策は、そこに届く受注データと顧客データの品質を超えられません。中途半端に同期された注文は連携の問題にとどまらず、的外れな施策になって表に出てきます。

よくある質問

ミドルウェアを使うべきか、ERPと直接連携すべきか。

システムが2つで、マッピングが安定していて、コードを持ち続けるチームがいるなら、直接連携が身の丈に合っています。ミドルウェアは、複数のシステムが関わるか、マッピングの変更が多い場合にライセンス費用に見合います。決め手となる問いは、ERPがどれだけカスタマイズされているかと、3年後にいくつのシステムを見込んでいるかです。

Adobe CommerceとのERP連携にはどれくらいかかるのか。

多くの場合、構築全体の中の1タスクではなく、クリティカルパスそのものになります。ばらつきの原因は開発速度ではなく、ERPのカスタマイズの深さと、項目ごとの所有権の判断がどれだけ早く下りるかです。細くても端から端まで通る1本を早い段階で通してみるのが、状況を把握する最も確実な方法です。

リアルタイムか、バッチか。

オブジェクトごとに選んで、両方です。受注、キャンセル、出荷情報の更新、回転の速い商品の在庫移動はイベント駆動。商品マスタの全件、在庫スナップショット、価格のロード、請求書、クレジットメモはスケジュール実行。一括処理をイベントとして扱うと、ERPがまったく想定していない量のメッセージが発生します。

商品コンテンツはERPとAdobe Commerceのどちらが持つべきか。

ERPが識別子、基本価格、在庫、単位、顧客の与信情報を持ちます。Adobe Commerceが商品説明、画像、カテゴリ、SEO情報、売り場づくりを持ちます。慣習に頼らず、連携の実装として強制してください。

同時にマーケットプレイスの在庫精度をどう保つのか。

マーケットプレイスは在庫と受注について独自の状態を持つので、最初の連携の延長ではなく、2つめの同期層です。販売可能在庫の情報源を1つにして、そこからすべてのチャネルへ供給する。この中央集約が、Shopee、Lazada、TikTok Shopがそれぞれ勝手にずれていくのを止めます。

効果を判断するには何を測ればよいか。

構築前に記録した基準値です。手入力の作業時間、売り越しによるキャンセル率、注文状況に関する問い合わせ件数、月末の突合作業の時間。この4つが動くことが、この連携を導入した目的です。

要点

オブジェクトの一覧より先に成果を定義する。方式は好みではなく、ERPのカスタマイズの深さとこれから増えるシステムの数で選ぶ。所有権を項目ごとに決め、販売可能在庫を明示的な計算式にし、受注を冪等にし、ERPをリクエストの経路から外す。そして初日から突合を作る。どんな連携も必ずずれるのであり、問題は顧客より先に気づけるかどうかだけだからです。

Bridziaは14年にわたりAdobe Commerce（Magento）に取り組み、アジア各地の小売・FMCGブランド向けに、財務・在庫・倉庫の各モジュールをまたぐERP連携を構築してきました。連携を計画中の方、あるいは既存の連携がずれ続ける理由を突き止めたい方は、プロジェクトについてお聞かせください。