CRM・MA・ERP・DWH連携の設計――EAで責任分界とデータフローを整理する

CRM、MA、ERP、DWHを個別案件ごとに直接つなぐと、顧客名、案件金額、商品、担当組織が複数方向に更新され、どの値が正しいか分からなくなります。ある連携の改修が別のレポートを止め、再送で商談や受注が重複し、障害時にはCRM担当とERP担当が互いのシステムを疑う。問題の本質はAPI方式そのものではなく、業務責任、データ責任、連携責任が設計されていないことです。

連携設計では、まず実現したい顧客対応・営業の業務能力を定め、データ項目ごとの正となるシステム、更新権限、流通方向、鮮度、失敗時の処置を決めます。そのうえで同期API、非同期イベント、バッチ、参照型などの方式を選びます。本記事では、EAとDMBOKを共通言語にした特定製品に依存しない設計手順を解説します。

システム一覧ではなく顧客・営業の業務能力から始める

「CRMとERPをリアルタイム連携する」という要求だけでは、何を、なぜ、どの鮮度で届けるか判断できません。顧客獲得、商談、見積、受注、請求、サービス、経営分析という一連のバリューストリームを描き、各場面の意思決定とデータ利用者を確認します。営業組織改革の全体像と営業プロセス標準化を先に整理すると、不要な連携を減らせます。

鮮度は「リアルタイム」という言葉で済ませず、許容遅延、処理量、ピーク、順序、整合性、停止時の代替を定量化します。リアルタイム化は価値がある一方、結合度、監視、再処理、コストも増やします。営業画面への即時応答と、分析用履歴の翌朝更新を同じ方式にしないことが重要です。

データ項目ごとに正本と更新責任を決める

システム全体を「顧客マスタの正」と決めても、属性ごとに責任が違う場合があります。企業の法的名称はマスタ、商談ステージはCRM、請求残高はERP、配信同意は同意管理機能が正というように、エンティティと属性の粒度でシステム・オブ・レコードを定めます。DWHは履歴と分析の正であっても、原則として業務トランザクションの更新元にはしません。

顧客360度ビューとマスタデータでは、単一システムに全データを集めることより、顧客IDと属性の責任を統一することが重要です。更新競合が起きたとき、優先順位、手動確認、上書き禁止、履歴保持のルールを決めます。

データフロー図に「読み取り・作成・更新・通知」を書き分ける

箱と矢印だけの構成図では責任が読み取れません。データフローごとに、送信元、受信先、業務イベント、方向、作成・更新・参照、トリガー、頻度、データ量、認証、変換、品質ルール、エラー処置、責任者を記載します。同じ顧客データでも、CRMがERPの請求先を参照する流れと、CRMで更新した担当者情報をマスタへ申請する流れは別インターフェースです。

最低限のインターフェース契約

• 業務目的、送受信チーム、サービスレベル
• スキーマ、必須・任意、コード、NULL、タイムゾーン、文字コード
• 業務キー、相関ID、重複判定、冪等性
• 作成・更新・削除・取消の意味と順序
• バージョン、互換期間、変更通知、廃止手続き
• 認証・認可、暗号化、機密区分、同意・目的制限
• タイムアウト、再試行、隔離、手動復旧、照合
• 監視指標、アラート、一次対応、エスカレーション

連携方式はユースケースごとに選ぶ

Salesforceの公式Integration Decision Guidesは、タイミング、方向、利用者体験、データ量、実装・保守性、プラットフォーム制約などを考慮して連携方式を選ぶ枠組みを示しています。特定製品の機能名ではなく、次のような一般的パターンとして評価すると比較しやすくなります。

一つの顧客体験に複数方式を組み合わせることもあります。たとえば見積画面では同期APIで最新価格を照会し、見積作成後はイベントで下流へ通知し、履歴は夜間にDWHへ取り込む設計です。Microsoft Azure Architecture Centerも、直接API、非同期メッセージ、イベント、バッチなどを要件に応じて使い分ける考え方を示しています。

責任分界はRACIと運用フローで具体化する

「インターフェースは連携基盤チームの責任」とだけ定めるのは危険です。送信された内容の正しさ、配送、受信後の業務反映はそれぞれ責任が異なります。相関IDで一件をエンドツーエンドに追跡し、送信・配送・受信・業務反映の件数と状態を照合します。

信頼性・セキュリティ・変更に備える

非同期連携では、少なくとも1回は配信される方式（at-least-once delivery）により同じイベントが再送される可能性を前提に、受信処理を冪等にします。同期連携では、タイムアウト後に実処理が完了している可能性を考え、照会や再送の設計を用意します。顧客データでは、認証・暗号化だけでなく、利用目的、同意、最小化、保持、削除をデータフロー全体で確認します。

• 業務ユースケース、許容遅延、停止影響から連携要件を定めた
• 属性ごとの正となるシステムと更新主体が明確である
• 作成・更新・削除・取消の流れを別々に設計した
• 業務キー、相関ID、冪等性、重複処理を定義した
• 同期・非同期・バッチ・参照を用途別に選んだ
• スキーマ版と後方互換期間、変更通知を契約化した
• 再試行、隔離、手動復旧、再処理の手順がある
• 送信・配送・受信・業務反映をエンドツーエンドで監視する
• 件数・統制合計・重要項目を定期照合する
• 同意、権限、保持、削除を複製先まで適用する

EAとDMBOKで部分最適を防ぐ

EAでは、業務アーキテクチャで能力と責任、データアーキテクチャで情報の正本と流通、アプリケーションアーキテクチャで機能配置、テクノロジーアーキテクチャでAPI・メッセージ・運用基盤を整合させます。The Open GroupのTOGAF Standardは、特定製品へ固定されない一貫した方法とコミュニケーションを支える枠組みとして利用できます。

DAMA-DMBOKの観点では、連携はデータ統合だけでなく、ガバナンス、メタデータ、マスタ、品質、セキュリティを横断します。インターフェース契約をデータカタログと結び、責任者、リネージュ、品質ルール、問題履歴を維持してください。営業KPIとパイプライン・売上予測の定義も、CRMとDWHで同じ意味を参照する必要があります。

まとめ

CRM・MA・ERP・DWH連携の成否は、接続本数ではなく、各システムが責任を持つ業務とデータが明確で、障害や変更後も説明可能かで決まります。業務ユースケースからデータフローを設計し、方式選定、データ契約、責任分界、監視・照合を一つのアーキテクチャとして管理してください。

参考資料

• Salesforce Architects「Integration Decision Guides」
• Microsoft Learn「Get started with integration architecture design」
• Microsoft Learn「Asynchronous messaging options」
• The Open Group「TOGAF Standards」
• DAMA International「What is Data Management?」

営業改革・SFA・CRMテーマクラスター：営業組織改革の全体像 ／ SFA・CRM要件定義 ／ 営業プロセス標準化 ／ 営業KPI設計 ／ パイプライン・売上予測 ／ 顧客360・マスタデータ ／ SFA定着 ／ CRMデータ移行 ／ CRM・MA・ERP・DWH連携 ／ SFA・CRM刷新

関連するBI／DWHナレッジ：意思決定から逆算するBI要件定義 ／ セマンティックレイヤー ／ データ不一致とリネージュ