ERP・CRM・ECサイト統合アーキテクチャ：フローごとの設計

このガイドは、ECサイト・ERP・CRMがすでに稼働しており、それらを一つのシステムとして連携させる必要があるCTO、ITマネージャー、Eコマース担当者を対象としています。エンタープライズシステム統合ガイドでは、レコードオーナーシップ、統合パターン、障害設計の一般原則を解説しています。本ページでは、それらをコマーストライアングルに適用し、フローごとに説明した後、トポロジーの選択とロールアウトプランで締めくくります。

ガイドの内容

• 3つのシステムと5つのフロー
• リファレンスアーキテクチャ
• 5つのフローの設計
• 設計を変えるB2Bのルール
• トポロジー：選択肢と選定基準
• 統合レイヤーにおけるAI
• ロールアウトプラン
• Netbase JSCの納品実績
• 納品実績として存在するもの、存在しないもの
• このガイドの限界
• よくある質問
• 次のステップ

3つのシステムと5つのフロー

多くのコマース環境では、中心に同じ3つのシステムが配置されています。ECサイトが販売と決済を担い、ERPが商品・在庫・価格・受注処理・帳票を管理し、CRMがアカウント・コンタクト・見積・サービス履歴を保持します。その周囲には決済プロバイダー、倉庫またはキャリア、そして多くの場合、商品情報システムが位置しています。

このトライアングル内のほぼすべての統合作業は、次の5つのフローに分類されます。

ツールを選定する前に、自社の環境に合わせてこの表を整理してください。2つのシステムが同じ行を主張する場合、オーナーを決めるのはインテグレーターではなくビジネス側です。オーナーを1レコードにつき1つに限定すべき理由はピラーガイドで解説しています。本ページの残りでは、オーナーが確定した後に各フローに必要な事項を説明します。

リファレンスアーキテクチャ

堅牢な設計は、どの製品で実装しても同じレイヤー構成を持ちます。

• システムごとのアダプター。各ECサイト、ERP、CRMは、そのシステムのAPIとデータモデルに対応する専用アダプターを持ちます。MicrosoftのArchitecture Centerはこれをアンチコラプションレイヤーと定義しており、あるシステムのセマンティクスが別のシステムへ漏れ出るのを防ぐ翻訳レイヤーです。ERPが入れ替わっても、変更が必要なのはそのアダプターだけです。
• 共通データモデル。アダプターはお互いに変換するのではなく、商品・顧客・受注・請求書の正規モデルへ変換します。Enterprise Integration Patternsが解説しているように、共通フォーマットを持つことで、新しいシステムを追加する際に必要な変換ペアはパートナーごとではなく1つで済みます。
• 識別子クロスリファレンス。小さなストアが各レコードのキーをすべてのシステムでマッピングします（ECサイトの注文番号、ERPの販売オーダー番号、CRMの商談ID）。名前やメールアドレスでマッチングすることはありません。
• 耐久性のあるイベント。変更は、それを発生させたのと同じデータベーストランザクション内に記録されてから公開されます（トランザクショナルアウトボックスパターン）。これにより、クラッシュが発生してもERPだけ更新されてECサイトに通知されない、という状況を防げます。
• マルチステップフローのオーケストレーション。受注から入金までのフローは4つのシステムに関わります。シーケンスとその補償処理を1つのコンポーネントが管理することで、ステップがWebhook全体に散在するのを防ぎます。
• 監視と照合。すべてのフローにダッシュボード、アラート、そしてオーナーとコピー間の件数・合計値の日次比較を設けます。

各レイヤーの障害対応ルール（冪等書き込み、バックオフ付きリトライ、デッドレターキュー）はピラーガイドに記載されており、変更なく適用されます。

5つのフローの設計

カタログと価格。オーナーからイベントとして変更をプッシュし、夜間にフル比較を実施します。価格の見逃しは遅延よりも深刻な問題となるためです。価格には有効期間を付与し、ERPが請求しない価格がECサイトに表示されることを防ぎます。

在庫。生の在庫数ではなく、在庫状況（手持ち在庫マイナス引当マイナス安全在庫）をチャネルごとに送信します。受注作成時に在庫を引き当て、キャンセル時に解放することで、2つのチャネルが最後の1点を二重販売するのを防ぎます。

顧客とアカウント。B2Bでは、CRMが通常アカウントとそのコンタクトを所有し、ERPが与信条件を所有します。ECサイトはその両方を受け取ります。新しいWebの顧客は最初にオーナーシステムで作成されてからコピーされるため、1人の人物が3つのレコードになることはありません。

受注とステータス。ECサイトは決済が承認されるまで受注を所有します。その後はERPが出荷を管理し、ステータス・出荷情報・追跡番号が返送されます。RFC 9110はPOSTを冪等でないと定義しているため、再試行されたcreateが2つ目の販売オーダーにならないよう、受注にはECサイトからの冪等キーを付与します。

決済・請求書・返金。決済プロバイダーがトランザクションを所有し、ERPが請求書とクレジットノートを所有し、CRMがアカウントチームに両方を表示します。入金済み決済と請求書を毎日照合し、返金はERPから、またはそのAPIを通じてのみ開始できるようにします。

設計を変えるB2Bのルール

企業間取引は、コンシューマー向けECサイトでは不要なルールを追加します。それぞれのルールがロジックの配置場所を決定します。

• 顧客別価格リストと契約価格はERPまたはCRMに保持し、アカウントごとに取得します。何千もの商品バリエーションとしてコピーすることはありません。
• 与信限度額と支払条件はチェックアウト時にERPに対して確認します。限度額を超えた受注は失敗するのではなく、承認待ちとなります。
• 見積はCRMで作成され、再入力なしに受注に変換されます。見積番号はERPの受注に引き継がれます。
• 発注書と承認は買い手側から受注と共に保存されます。これにより、請求書が買い手の財務チームの期待に合致します。

トポロジー：選択肢と選定基準

4つの判断基準があります。データとルールがどれほど標準的か、2年後に想定するシステムとフローの数、ロジックを所有・変更する必要があるのは誰か、そして夜間に運用するのは誰かです。多くの環境ではコネクターから始め、エラー処理と可視性が限界に達した時点でハブへ移行します。統合ハブはそのステップの自社所有版です。マルチベンダーストアでは出品者への支払いとベンダーカタログが加わります。詳細はマーケットプレイスプラットフォームアーキテクチャで解説しています。ECサイト自体の変更が予定されている場合は、先にカスタムEコマースプラットフォームガイドで方向性を定めてください。

Netbase JSCの納品実績

• リワードショッププラットフォーム（クライアント名非公開）。ドバイを拠点とするロイヤルティ企業向けに、Netbase JSCはヘッドレスMagento 2マルチストアプラットフォームをクライアントのポイントミドルウェア、受注サービス、商品カタログと接続しました。ポイントと受注はクライアントのシステムが所有し、変更はWebhookで伝達され、スケジュール同期がフェイルオーバーとして機能します。詳細はリワードショップの実績をご覧ください。
• 米国クライアント向けクラウドERP（クライアント名非公開）。2020年よりオフショア開発・マネージングパートナーとして、Netbase JSCはマルチテナントクラウドERPを構築しています。第1フェーズにはCRMおよびテナントが既存で利用するシステムへのAPI統合が含まれます。詳細はクラウドERPの実績をご覧ください。
• Cloodo Workspace。Netbase JSCのビジネス部門製品であり、CRM・HRM・クラウドERP・AIモジュールを1つのプロダクトに統合することで、レコードを同期するのではなく1つのシステムに集約します。詳細はCloodoの実績をご覧ください。

Netbase JSCはまた、カタログ・在庫・受注・顧客のAPI同期を通じてクライアントのECサイトとERPを接続した実績があります。これらのクライアントは非公開です。

納品実績として存在するもの、存在しないもの

• 存在するもの。上記の実績は、どのシステムが接続されたか、どのシステムがどのデータを所有するか、変更がどのように伝達されるかというスコープと設計を説明しています。Netbase JSCのプロダクト化済みモジュールにはCRM・B2B営業エンジン、ワークフロー自動化ツールキット、Smart ERP Lightが含まれ、納品済みプラットフォームにはWooCommerce、Magento 2、Laravel、ヘッドレスコマースが含まれます。
• 存在しないもの。これらの実績のいずれも、統合の期間、メッセージボリューム、エラー率、ビジネス成果を公開しておらず、また数値の根拠として提示するものでもありません。ERP統合のクライアントは非公開です。

このガイドの限界

• フロー表はB2CおよびB2Bコマースのデフォルトです。マーケットプレイス、サブスクリプション、製造業では独自のフローが追加されます。
• パターンは公開されている説明から引用しています。実際のデータに対するテストなしにパターンを適用しても、統合の正確性は保証されません。
• 最小権限キー、転送時TLS暗号化、保存時AES暗号化、管理者アクセスへのMFAなどのセキュリティ施策はリスクを低減しますが、保証ではありません。

よくある質問

ERPとECサイト、どちらが受注を所有すべきですか？通常、ECサイトは決済が承認されるまで受注を所有し、その後ERPに引き渡します。ERPは出荷と請求を管理し、ステータスはECサイトとCRMに返送されます。

ERPとECサイトを接続するためにミドルウェアは必要ですか？必ずしも必要ではありません。標準製品が2つで、ボリュームが少なければコネクターで対応できます。B2BルールやCRM、第3のシステムが加わると、コネクターの網よりもハブまたはプラットフォームの方が通常は運用コストが低くなります。

受注の重複を防ぐにはどうすればよいですか？すべての受注にECサイトからの冪等キーを付与し、識別子クロスリファレンスを管理し、ECサイトの受注とERPの受注を毎日照合してください。

ERPを入れ替えずに統合できますか？通常は可能です。アダプターがERPのモデルを分離するため、ビジネスが入れ替えを決断するまで現状のERPを維持でき、変更が必要なのはアダプターだけです。入れ替えが検討されている場合は、カスタムERP vs 既製ERPで選択肢を比較してください。

次のステップ

ECサイト・ERP・CRMの情報、最も頻繁に問題が発生するフロー、および期限をお知らせいただければ、オーナー・フロー・トポロジーをマッピングするためのソリューションレビューをご予約します。システム・API統合、ERP・CRM開発、またはNetbase JSCのインサイトもご覧ください。

関連サービスとソリューション