CRMとERPの連携設計：同期するデータ、管理権限、テスト方法

CRMとERPの連携は、顧客対応の業務を受注、在庫、請求などを記録する業務システムにつなぎます。難しいのは、どのレコードを移すか、どちらのシステムに変更を許すか、転送の失敗をどう把握するかを決めることです。

業務の引き継ぎを一つ選びます。営業担当者には確定した受注番号が必要です。財務には信頼できる請求先情報が必要です。サービス担当者には現在の配送状況が必要です。それぞれの用途に合うデータ契約を定めます。

本ガイドは、その契約を記述し、対象を広げる前に一つの流れを検証する方法を紹介します。権限表と受注の例は仮想のもので、顧客事例やQonnexの既製コネクタを示すものではありません。使えるインターフェースは製品によって異なります。

CRMとERPの連携に測定できる役割を一つ与える

開始条件と終了点が明確な引き継ぎを選びます。たとえばCRMで承認済みの受注依頼をERPで確定受注とし、その受注IDをCRMに返す流れです。「二つのシステムを一致させる」より、初回の範囲を具体的にできます。

業務上の結果に責任を持つ人を決めます。営業企画が依頼の品質、業務部門が受注の可否、財務が請求統制を担当することが考えられます。ITは実装の技術運用を担いますが、業務上の役割分担は各部門と決めます。

改善したい点と測定方法を記録します。再入力にかかる時間、拒否された依頼、未解決転送の滞留時間、照合で見つかった差異などが候補です。連携を構築する前に、各指標のデータソースを定めます。

Qonnexの手作業コストの記事では、繰り返し入力と引き継ぎのコストを説明しています。診断後は、業務を一つ特定し、責任者を一人定め、確認可能な結果を一つ設定します。

リアルタイム更新を約束する前に、業務上の必要性を確認します。夜間に更新される口座残高の表示と、受注確定前の在庫確認では求められる鮮度が異なります。値ごとに許容する最長の経過時間と、古い情報の表示方法を明記します。

引き継ぎに必要なレコードを整理する

CRMとERPは顧客、商品、受注、財務データを共有できますが、両者の概念は必ずしも一致しません。見込み客が請求可能な顧客になるには条件があります。商談と確定受注、案件見込額と認識済み収益も区別します。

IBMの連携概要は顧客、商品、価格、販売など共有される代表的なデータを挙げています。これを候補一覧として使い、必要な項目を選びます。

最初の業務で扱うレコードごとに、次を確認します。

• 送信元と送信先で変わらない識別子。
• 作成に必須の項目と、その後変更できる項目。
• 先に存在する必要のある関連レコード。
• 作成・更新を許可する業務イベント。
• 受理を確認する送信先の応答。

依存関係と処理の順序を決めます。受注依頼には承認済みの顧客情報と有効な商品IDが必要な場合があります。どちらかが欠けた場合の処理を定めます。転送を続けるために仮レコードを作ると、請求やレポートにも不確かな情報が広がりかねません。

業務キーと表示名は分けます。名前が似た企業もあれば、名称変更後も同じ取引先である企業もあります。二つのシステムの識別子をどう対応付けるか、その修正を誰が承認できるかを文書化します。

項目ごとに変更権限を割り当てる

「CRMが顧客を管理する」では範囲が広すぎることがあります。営業企画が取引関係や希望する連絡方法を管理し、財務が請求条件と正式な請求先法人を管理する場合があります。引き継ぎで重要な項目ごとに権限を指定します。

以下は仮想企業の設計例です。役割分担は自社の業務に合わせて決めます。

競合時の扱いを事前に決めます。ERPが管理する請求項目をCRMで編集しようとしたら、編集を禁止するのか、警告を出して変更を破棄するのか、財務に変更依頼を出すのかを明確にします。通知なしの上書きは両システムへの信頼を損ねます。

「最後の更新を優先する」だけでは、管理権限を表せません。タイムスタンプが新しくても、編集者の権限や値の正しさは保証されません。同時編集を許す場合は、バージョンの扱いと、自動で安全に解決できない場合に必要な人の判断を定めます。

業務担当者が読める言葉でデータ契約を書く

データ契約は転送が何を意味するかについての合意です。業務責任者が読んで理解でき、実装担当者がテストできる精度が必要です。

受注依頼には、送信元のID、承認済みの顧客対応付け、明細、数量、単位、通貨、必要な日付、検証ルールを含めます。実際の業務に合わせて、値引き、税、配送情報、任意項目の扱いを決めます。空欄とゼロの意味も区別します。

精度、タイムゾーン、日付のルールを定めます。一方のシステムがケース単位、もう一方が個数で数量を扱う場合があります。希望納品日とイベント発生時刻は別です。合計金額には通貨が必要です。

企画会議で使える架空の受注依頼を示します。

識別子は架空で、実システムの画面やデータを示すものではありません。金額や所要時間の実測結果も含みません。

送信依頼と同じ精度で応答経路を文書化します。営業担当者が、送信済み、受理済み、拒否、確認待ちを区別できるようにします。送信成功の表示だけで、ERPが受注を確定したと見なさないようにします。

同期の方向と頻度を用途に合わせて決める

受け手が確定値を表示するだけなら、一方向連携が適します。ワークフローの異なる部分をそれぞれのシステムが管理するなら、双方向のやり取りが適する場合があります。どちらでも共有項目の編集権限は個別に決めます。

Microsoftのデュアルライトの概要は、Dynamicsの財務・運用アプリケーションとDataverseの間の連携を、双方向の動作や運用統制とともに説明しています。この製品の例を他製品にも適用できると考えたり、全項目で双方向更新を採用したりする必要はありません。

アーキテクチャの判断は業務上の契約と分けます。APIで直接つなぐ場合、連携プラットフォームを使う場合、標準連携を使う場合では制約が異なります。まずデータ、頻度、管理権限、復旧の要件を決め、許容できる運用費で満たせる方法を評価します。

対象業務に関係する制約を確認します。対応オブジェクト、更新方法、レート制限、バッチサイズ、処理順、利用できるイベント通知、エラー情報などです。実際に使うシステムの最新ドキュメントで確認します。カタログにコネクタが載っていても、必要な取引を処理できるとは限りません。

計画保守中の動作を定義します。ERP停止中に依頼を安全にキューに置けるか、在庫の確定を止めるべきか、誰が連携の再開を決めるかを最初の停止前に運用設計に盛り込みます。

更新が失敗しても復旧できるようにする

必要な顧客レコードがないために依頼が拒否されるケースは結果が明確です。一方、ERPが受注を確定しても応答が連携処理に届かないことがあります。すでに受注が存在するのにCRMでは保留のままです。

架空の依頼DEMO-ORD-104を使い、後者の復旧を確認します。元の依頼IDを維持し、送信先が実際に受理した内容を照会します。インターフェースが検索に対応していれば、返却されるはずだった受注IDを回収します。安全に確認できなければ、新たな受注を作る前に調査に回します。

どの仕組みで再実行が安全になるかを、実装チームに説明してもらいます。冪等な操作とは、同じ依頼を繰り返しても業務上の効果が重複しないようにした操作です。採用するインターフェースでその挙動が得られるか、保護がどのくらい続くかを確認します。

依頼の再実行や値の復元ですべての失敗を直せるわけではありません。確定受注がすでに後続作業を起動していることもあります。Microsoftの補償トランザクションのガイドでは、復旧に業務固有の処理や人の介入が必要な理由を説明しています。この業務では、誰が確定済み取引を取り消し、修正し、または別の方法で解決できるかを決めます。

調査に必要な証跡を残します。依頼ID、イベント時刻、送信元・送信先ID、処理状態、再試行履歴、エラーの分類です。運用ログには顧客の全データや秘密情報を残さないようにします。業務利用者には技術エラーの原文に代えて、次の対応が分かる状態を表示します。

ジョブの成功とは別に業務レコードを照合する

ダッシュボードが成功を示していても、顧客の対応付けや単位換算が誤っていたり、明細が抜けたりすることがあります。転送の技術的な状態と業務上の結果は別々に検証します。

パイロット対象について、保存した識別子で送信元の依頼と送信先で受理したレコードを比較します。重要項目と明細数を確認します。一致しないものは拒否、保留、対象外、要調査のどれかに分類し、未解決分の担当者と確認頻度を決めます。

CRMで何を「最新」と見なすか定義します。更新時刻が古い値を、新しい値と区別できる表示にします。データが古いという警告を出す条件と、その情報で利用者が判断してよいかを決めます。

照合工数も測定します。再入力がなくなっても手動照合が増えれば、比較に含めます。Qonnexの自動化の投資対効果を測るガイドでは、運用費全体を含める理由を解説しています。

対象を広げる前にデータ契約をテストする

管理されたテスト環境で、合成レコードまたは使用許可のあるレコードを使います。認証情報が有効でAPIが成功することを確認した上で、業務契約に沿ってテストします。

実際の結果、証跡、レビュー担当者の承認を記録します。リリースを止める失敗と修正後の再テスト方法を合意します。開発者が後から手動修正できるという理由だけで合格にしません。

引き継ぎを実際に運用する担当者も参加させます。営業担当者が保留中の受注を説明できるか、業務担当者が拒否の理由を調査できるか、財務担当者が管理項目を検証できるかを確認します。例外を扱えることも受入条件です。

連携の運用を担う人を決める

技術責任者と業務責任者を置きます。失敗の監視、対応付けの維持、項目変更の承認、不在時の代理を誰が担うかを記録します。アプリケーションの更新やインターフェースの変更を確認する手順を定めます。

アクセスは連携に必要なレコードと操作に限定します。テスト用と本番用の認証情報を分け、更新方法を定めます。連携用アカウントは個々の従業員のアクセス権に依存させません。実際の統制は組織のセキュリティ責任者が確認します。

展開前に一時停止と復旧の手順を決めます。キュー内の作業を保持し、すでに受理された項目を特定できるようにします。再開時は停止以降のイベントを無条件に再実行しません。

初回の運用レビューでは、未解決レコード、古いデータ、修復工数、予定した改善の証跡を確認します。他のレコード種別に広げるのは依存関係と統制を定義してからです。請求書状態の表示と新規請求レコードの書き込みでは権限もリスクも異なります。

導入の相談にはデータ契約を持ち込む

Qonnexの業務効率化サービスには、既存のCRM、会計、業務ツールの連携が含まれます。適切な範囲は現在使えるインターフェースと業務ルールで決まります。既存システムの置き換えは前提ではなく、特定のQonnexコネクタの提供可否は別途確認が必要です。

実装方法を選ぶ前に、レコードの権限表、データ契約、障害対応・照合手順、受入テスト表の四つを用意します。連携の相談で確認すべき判断を具体化できます。

契約上の条件と技術テストは分けます。Qonnexの成果連動型コンサルティングの解説では、成果に基づく考え方を紹介しています。動作する連携についても、受入条件を満たす証拠と業務成果を測る合意が必要です。

特定の引き継ぎを評価するには、開始条件、対象システム、責任者、現在の例外をビジネス分析で説明してください。繰り返し入力しているレコードと、その入力を待っている判断から始めます。