こんばんは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

皆さん、週末をいかがお過ごしでしょうか。

昨日に続き、今日もラグビーリーグワンの試合をJ SPORTSで観戦していました。

クボタスピアーズ船橋・東京ベイ vs 埼玉パナソニックワイルドナイツ。結果は26-24でクボタスピアーズの勝利。最後まで目が離せない、手に汗を握る好ゲームでした。流れるようなパス回し、激しいタックル、そしてボールへの執念。どちらのチームも一歩も引かない、まさに両チームの総力戦でした。

試合を観ながら、ふと気づいたことがあります。強いチームは、攻めと守りのレベルが両方、めちゃくちゃ高い。どれだけ鋭いアタックを仕掛けても、ディフェンスが崩れれば試合は取れない。逆に、どれだけ堅固なディフェンスを誇っていても、点を取る力がなければ勝てない。攻めと守り、どちらが欠けても、チームとして完成しないのです。これは、企業のDXにそのまま当てはまります。

攻めと守りのDX

CRM（営業・マーケティング）は、「攻め」のDX｜ERP（基幹業務）は、「守り」のDX

どれだけ優秀な営業システムで案件を積み上げても、その先の受注・在庫・請求・回収が繋がっていなければ、ビジネスとして完結しません。逆に、ERPで業務を完璧に管理していても、顧客との接点・営業活動・マーケティングが分断されていたら、攻めの一手が打てません。

そして今、AI Agentと共に働く時代が始まっています。Sales Agent、Payables Agent、Expense Agent—ERPにもCRMにも、AIが業務の中に入り込んできている。このAI Agentを本当の意味で活かすためには、リアルタイムのデータと伝票登録の連携が欠かせません。CRMとERPが繋がっていなければ、AIも「片手で戦う」ことになります。

本稿では、CRMとERPの本来の役割、それぞれのデータの持ち方、そして両者を繋ぐ連携の設計について、一緒に考えていきたいと思います。

最後までお付き合いいただけると幸いです。

CRMって、実はこんなに広い

「CRMを導入したい」—そう相談を受けると、多くの場合、頭の中にあるのは、SFA（営業支援システム）のことです。案件管理、商談履歴、売上予測。確かにそれも大切なCRMの一部です。

でも、CRMの本来の意味は Customer Relationship Management、つまり「顧客との関係を管理する」こと。

営業だけではありません。顧客との接点は、実はこんなにも広いのです。

「デジタルマーケティング」「CDP（顧客データプラットフォーム）」「SFA」「フィールドサービス」「プロジェクトオペレーション」「カスタマーサービス/コールセンター」

この一連の流れが、顧客との関係のすべてです。SFAはその中の一区間に過ぎないのです。

多くの企業で起きていること

室長として様々なお客様先を訪問すると、こんな光景をよく目にします。

• デジタルマーケティングはマーケティングツールA
• SFAは営業管理システムB
• フィールドサービスは独自システムC
• プロジェクト管理はパッケージシステムD
• コールセンターはCTIシステムE
• CDPはまた別のツールF
• ERPは基幹システムG

それぞれが単独では機能している。でも、繋がっていない。マーケティングが獲得したリードが、SFAに自動で流れてこない。コールセンターに昨日クレームを言っていた顧客に、今日営業が「新製品いかがですか」と電話する。フィールドエンジニアが訪問した結果が、次のマーケティング施策に活かされない。ERPで管理している購買履歴や与信情報が、営業やマーケティングに見えていない。顧客から見れば、同じ会社のはずなのに、まるで別々の会社と話しているような体験になってしまっています。

CDPとデジタルマーケティングをAIで活かしたいなら、

「AIを使ったパーソナライズマーケティングをやりたい」

「CDPで顧客を一元管理したい」

こうしたご要望を持つお客様が急増しています。

でも、ここで一つ、重要なことをお伝えしたいと思います。CDPは、食わせるデータの質と量で、その力が決まります。顧客データには、大きく2種類あります。

構造化データ—ERPが持つ購買履歴・受注金額・与信残高・支払状況、SFAが持つ商談履歴・案件ステータス、カスタマーサービスが持つ問い合わせ履歴など、テーブル形式で整理されたデータです。

非構造化データ—メール・チャット・通話録音・Webサイトの行動ログ・SNSの反応など、形式が定まっていないデータです。「この顧客は先週、製品ページを3回見ていた」「コールセンターでのトーンが少し怒り気味だった」——こうした情報も、AIにとっては非常に重要なシグナルになります。

CDPは、この構造化・非構造化の両方を統合して、顧客の360度ビューを作ることが本来の役割です。

そして、ここで重要なのが、Microsoft Fabricの存在です。Fabricは、ERPのトランザクションデータ、Dataverseの顧客データ、Webの行動ログ、コールセンターの録音データ—これらのあらゆるデータソースを一つのプラットフォームで統合・分析できる基盤です。構造化・非構造化を問わず、OneLakeという統合ストレージを中心に横断活用できる環境を整えます。だから、AIが見られる世界が広がるのです。

つまり理想的な構造はこうなります。

データがサイロ化したまま、CDPやFabricだけ導入しても、食わせるデータが断片的では、AIも断片的な判断しかできません。逆に、SFA・フィールドサービス・カスタマーサービス・ERP—これらが同一プラットフォーム上でデータを共有している状態であれば、CDPとデジタルマーケティングのAIは、顧客の全文脈を把握した上で動くことができます。

バラバラでも、動く。しかし、同一プラットフォームで統合されていた時、AIは初めて本領を発揮できる。

これが、Dynamics 365というプラットフォームが持つ最大の強みです。

Sales、Field Service、Project Operations, Customer Service、Customer Insightsといった顧客接点側のアプリケーションはDataverseを中核に活用し、Business CentralやFinance & OperationsといったERPはDataverseと連携することで、顧客・業務・データが横断的につながるアーキテクチャを実現できます。

ここにFabricが分析・統合の層として加わることで、AIが扱えるデータの幅はさらに広がります。

顧客データがシステムをまたがって流れる。ラグビーでいえば、フォワードとバックスが同じサインプレーを共有している状態です。

お互いの動きが見えているから、パスがつながり、ノックフォワードが起きにくいのです。

バラバラだとこうなる——現場で起きている「静かな損失」

「うちはちゃんとシステムを入れています」

そうおっしゃるお客様先を訪問すると、確かにシステムはある。でも、繋がっていない。これは特定の企業の話ではありません。室長がこれまで訪問してきた多くの企業で、程度の差はあれ、同じ構造が繰り返されています。

営業現場で起きていること

SFAで案件を管理している営業担当者が、顧客に電話をかける前に何をするか—ERPの別画面を開いて、その顧客の購買履歴を確認する。与信残高を確認する。未払い請求書がないか確認する。これが手作業で、毎回行われています。しかも、ERPを見る権限がない営業担当者は、経理部門に「この会社の与信、どのくらい残ってますか？」とメールや口頭で確認する。経理は経理で、別の仕事の手を止めて確認して返信する。1件の確認に、2人の時間が使われています。これが月に何十件、何百件と積み重なります。

マーケティングと営業の断絶

マーケティング部門がキャンペーンを打つ。メールを送る。ウェブセミナーを開催する。反応した見込み客のリストを作る。そのリストを—Excelに落として、営業部門にメールで送る。営業は受け取ったExcelを、SFAに手入力する。キャンペーンに反応してから、営業がアプローチするまでに数日のタイムラグが生じる。その間に見込み客の熱は冷める。競合他社が先に動く。せっかくマーケティングが育てたリードが、ノックフォワードで途切れています。

コールセンターと営業の壁

顧客がコールセンターに電話をかけてくる。製品の不具合を訴える。オペレーターが対応して、チケットを起票する。その翌日、同じ顧客に営業担当者が電話をかける。「先日はご購入ありがとうございました！追加のご提案があるのですが—」顧客は昨日のクレームがまだ解決していないのに、営業から売り込みの電話がかかってきた、と感じる。
顧客にとっては同じ会社のはずなのに、左手が右手のやっていることを知らない。コールセンターのシステムとSFAが繋がっていないと、こういうことが日常的に起きます。

フィールドサービスの孤立

設備のメンテナンスや修理対応をするフィールドエンジニア。現場で作業を完了させ、報告書を手書きまたは独自システムに入力する。その情報は—営業には届かない。マーケティングにも届かない。ERPへの部品消費の反映は翌日以降。「この顧客の設備は老朽化が進んでいる」「そろそろ買い替えのタイミングだ」—フィールドエンジニアが現場で感じたこの情報が、営業の提案活動にタイムリーに活かされていません。ビジネスチャンスが、現場に埋もれたまま消えていくのです。

プロジェクトサービスの断絶

プロジェクトマネージャーは現場で多くのことを知っている。「追加フェーズに興味がある」「来期の予算を示唆していた」—しかしその情報は、営業のSFAには届かない。工数・原価・請求の実績もERPとは繋がらず、「本当に儲かったのか」は手動の突き合わせでしか把握できない。次の商談のタネが、現場に埋もれたまま消えていく。

ERPとCRMの間のダブルワーク

見積をSFAで作成する。受注が決まったら、同じ内容をERPに手入力する。顧客マスタが、SFAとERPの2箇所に存在する。住所変更があった時は、2箇所を更新しなければならない。片方だけ更新されて、もう片方が古いまま—というケースが頻発する。請求書はERPから発行されるが、営業はSFAしか見ない。「この案件、もう入金されましたか？」という確認が、また別の手間になる。債権の消し込みが完了しても、SFAの案件ステータスは手動で更新しなければならない。同じデータが、2つのシステムを別々に旅している。

CDPを入れても解決しない理由

こうした状況の中で、「AIを活用したい」「CDPを導入したい」というご要望をいただくことがあります。気持ちはよくわかります。でも、正直に申し上げます。データがバラバラなまま、CDPを入れても、AIを入れても、本来の力は発揮できません。

CDPが必要とするのは、顧客との全タッチポイントのデータです。マーケティング・営業・サービス・購買履歴・与信情報・フィールド作業履歴—これらが統合されていてこそ、AIが「この顧客は今、何を求めているか」を正確に、タイムリーに判断できるのです。断片的なデータを食わせたAIは、断片的な答えしか返してくれません。

ラグビーの試合で例えるなら—フォワードとバックスが別々のサインプレーを使っている状態です。いくら個々の選手が優秀でも、連携が取れなければトライは取れない。バラバラな状態は、静かに、じわじわと、ビジネスの機会を蝕んでいるのです。

Lead to Cash—リードから入金まで、データが途切れない世界

先ほどは、バラバラなシステムが生み出す「静かな損失」をお伝えしました。では、繋がった世界はどうなるのか。

Lead to Cashという言葉があります。「リード（見込み客）から、Cash（入金）まで」——営業プロセスの最初から最後までを、一本の流れとして捉える考え方です。ラグビーで言えば、自陣ゴールライン近くのスクラムから始まり、パスを繋ぎ続けて、相手ゴールにトライするまでの一連の攻撃です。途中でノックフォワードを起こさず、ボールを繋ぎ切るイメージです。

この流れがデータの途切れなく走る—それがLead to Cashの理想形です。

繋がった世界で何が変わるか？

営業担当者の朝が変わります。SFAを開くと、担当顧客の全情報が一画面に揃っている。

• 昨日コールセンターに問い合わせがあった（カスタマーサービス連携）
• 先週マーケティングメールを開封し、製品ページを3回訪問した（マーケティング連携）
• ERPの与信残高は300万円、未払い請求書はなし（ERP連携）
• 3ヶ月前にフィールドエンジニアが訪問し「設備の老朽化」を報告していた（フィールドサービス連携）
• 先月プロジェクトが完了し、担当PMが「追加フェーズへの関心あり」とメモしていた（プロジェクトサービス連携）

この情報を持って電話をかける営業と、何も知らずに電話をかける営業とでは、会話の質がまるで違います。
「先日、製品についてお問い合わせいただいていましたね。ちょうど設備の更新についてもご検討のタイミングかと思いまして」顧客は驚きます。「この会社は、自分のことをちゃんと見ている」と感じます。

見積から受注へ—ダブルワークの消滅

繋がった世界では、SFAで作成した見積が、そのままERPの受注に変換されます。顧客マスタは一つ。顧客マスタは統合的に管理され、連携設定に基づいて双方に同期されます。住所変更も、同期の仕組みによって他システムへ反映されます。受注が確定した瞬間に、ERPで在庫確認が走り、出荷スケジュールが組まれる。営業はSFAの画面で納期を確認できる。「納期はいつになりますか？」という顧客からの質問に、その場で即答できます。

与信管理のリアルタイム化

与信限度額のチェックが、受注入力の瞬間に自動で走ります。与信オーバーの場合は、承認フローが自動起動します。営業が経理に「与信どうですか？」と確認する電話は不要になります。ERPの請求・入金状況は、連携設定や同期タイミングに応じてCRMから参照でき、Virtual Tablesを活用することでリアルタイムに近い形での把握も可能になります。「この顧客、そろそろ請求書の支払期限ですね」という情報が営業の手元にある。督促のタイミングを逃さない。

フィールドサービスが営業チャンスになる

フィールドエンジニアが現場で作業を完了させると、その情報がリアルタイムでCRMに反映される。「設備Aの老朽化が進んでいる。交換推奨時期：6ヶ月後」この情報をトリガーに、Sales Agentが自動的に営業担当者にアラートを送る。「担当顧客の設備更新時期が近づいています。提案のタイミングです。」フィールドサービスが、営業のチャンス発掘エンジンになります。

プロジェクトサービスが次の商談になる

プロジェクトが完了した瞬間、その情報がCRMにリアルタイムで反映される。「フェーズ1納品完了。顧客担当者より追加フェーズへの関心あり」—このメモをトリガーに、Sales Agentが自動的に営業担当者にアラートを送る。「フォローアップの最適なタイミングです。」プロジェクトの完了が、次の商談の起点になります。

カスタマーサービスがマーケティングに繋がる

コールセンターへの問い合わせ内容が、マーケティングのセグメント情報に加わります。「この製品について複数回問い合わせしている顧客グループ」—このセグメントに対して、使い方のハウツー動画をメールで自動送信する。顧客満足度が上がる。チャーン（解約）リスクが下がる。問い合わせが「クレーム」から「エンゲージメント向上のきっかけ」に変わります。

AIが本領を発揮する瞬間

そして、ここがこの章の核心です。Lead to Cashの流れが一つのプラットフォームで繋がっている状態では、AIは顧客の全文脈（コンテキスト）を把握した上で動くことができます。

まず、Marketing AgentとCDPが動き出します。CDPには、購買履歴・問い合わせ履歴・Webの行動ログ・フィールドサービスの訪問記録・コールセンターの通話内容——構造化・非構造化を問わず、顧客との全接点のデータが統合されています。Marketing Agentはそのデータを活用して、「この顧客に、今、何を届けるべきか」を判断します。設備の更新時期が近い顧客には更新提案のコンテンツを。複数回問い合わせをしている顧客には使い方のハウツーを。購買から半年が経過した顧客には満足度調査を。パーソナライズされたコミュニケーションが、AIによって自動的に届けられます。そのマーケティング活動に反応した顧客が、次の営業機会として自動的にSFAに流れてきます。ここでノックフォワードは起きません。

次に、Sales Agentが動きます。ERPの在庫・与信残高・未払い請求書・納期をリアルタイムで参照しながら、顧客への最適な提案内容を自律的に生成する。「この顧客の与信残高は十分か」「希望の納期に在庫は間に合うか」—営業担当者が手動で確認していたことを、Sales Agentが瞬時に判断します。

そして、Customer Service Agentが顧客体験を守ります。ERPの購買履歴・請求状況・フィールドサービスの訪問記録・プロジェクトの進捗状況・過去の問い合わせ履歴を参照しながら、顧客の問い合わせに即座に、的確に答える。「昨日クレームがあった顧客に売り込みの電話をかける」という悲劇は二度と起きません。

AIが「目隠しで戦う」状態から、「全局面が見えた状態で戦う」状態へ。CDP→デジタルマーケティング→営業→サービス——この流れが一本のデータの川として繋がっている時、AIは初めて本領を発揮できます。これがLead to Cashの実現がもたらす、AI時代の最大の恩恵です。

Microsoft Fabricが全体を支える

さらに、Lead to CashのデータフローをMicrosoft Fabricが後押しします。ERPのトランザクションデータ（構造化）、CRMの顧客活動データ（構造化）、Webの行動ログ・通話録音・メール（非構造化）——これらすべてをFabricのOneLakeに集約することで、CDPとAIが活用できるデータの幅が劇的に広がります。

リードから入金まで、そして入金からまた次のリードへ。データが途切れず、AIが全局面を把握し、顧客との関係が深まり続ける—これが、CRMとERPが繋がった世界の姿です。ラグビーの試合で、フォワードとバックスが完璧に連携してトライを取る瞬間のように。攻めと守り、全接点が一つに繋がった時、チームは最強になります。

D365 Salesとの連携—BCとFO、それぞれのLead to Cash

先ほど、CRMとERPが繋がった世界の姿を描きました。では実際に、Dynamics 365 SalesはBusiness Central（BC）およびFinance & Operations（FO）とどのように繋がるのか。具体的な仕組みを見ていきましょう。

前回の記事「ノックフォワードしないデータ連携」で、BCとDataverseの4つの連携メカニズムをお伝えしました。D365 Salesとの連携は、まさにそのData Synchronization（データ同期）とVirtual Tablesが中心的な役割を担います。そしてFOの場合は、これに加えてDual-writeという強力な仕組みが登場します。

BCとDynamics 365 Salesの連携

Business CentralとDynamics 365 Salesの連携では、Dataverseを介したデータ同期と、Virtual Tablesによるリアルタイム参照が中心になります。

ここで重要なのは、役割の分離です。

• マスタや一部業務データは、連携設定と同期ジョブに基づいて同期する
• 在庫、与信、納期のように「今この瞬間の値」が重要なものは、Virtual TablesやAPIで参照する

この設計の切り分けが品質を決めます。たとえば、Business Centralの得意先やコンタクト、製品、価格情報などは、Dataverse連携で同期設計を組むことができます。一方で、在庫数量や与信残高のような情報は、Virtual Tablesを用いることで、データをコピーせずにERP側を直接参照する構成が有効です。

「Virtual TablesはDataverse上に「テーブルの定義（窓口）」として登録されています。Power AppsやPower Automateからは通常のDataverseテーブルと同じように見えますが、実際のデータはBC側に存在し、アクセスのたびにBCのAPIを呼び出してリアルタイムで取得します。Dataverseにデータのコピーはつくられず、データはBC側で完全に管理され続けます。ERPがSingle Source of Truth（データの一元管理）のまま、Power AppsやPower AutomateからERP側のデータを操作することができます。」

ここで大切なのは、「全部を同期すればいい」という発想ではないことです。何をDataverseに持たせ、何をBC側に残し、何を参照だけにするか。その設計判断こそが、Lead to Cashの品質を決めます。

※BCとDataverseのデータ同期はジョブキューに基づく同期間隔で実行され、リアルタイム整合性が保証されるものではありません。一方で、Virtual TablesやAPIを活用することでリアルタイム参照を実現できます。

何が同期されるか

BCとD365 Salesの間では、以下のデータが双方向で同期されます。

顧客・取引先マスタ：
BCの得意先（Customer）とD365 SalesのAccount（取引先企業）が同期されます。どちらかで住所・連絡先・与信情報を更新すれば、もう一方に自動反映される。顧客マスタの二重管理が解消されます。

コンタクト（担当者）：
BCのコンタクトとD365 SalesのContactが同期されます。営業担当者がSalesで更新した担当者情報が、BCにも反映される。

通貨・為替レート：
BCで管理している通貨・為替レートがD365 Salesに同期されます。グローバルビジネスにおいて、見積金額の整合性が自動的に保たれます。

品目（製品）：
BCの品目マスタがD365 SalesのProduct（製品カタログ）に同期されます。営業担当者は常に最新の製品情報・価格で見積を作成できます。

在庫情報：
BCの在庫数量は、Virtual Tablesを用いることでD365 Salesからリアルタイムに参照できます。「この製品、今いくつ在庫がありますか？」という質問に、営業がその場で答えられます。データはBCにとどまったまま、Salesの画面から見える。前回の記事で説明したVirtual Tablesの典型的な活用シーンです。

見積（Quote）：
D365 Salesで作成した見積は、連携設定に基づいてBCに同期されます。さらに、受注確定後の処理も設定に応じてBCの販売受注へと引き継がれ、SFAでの見積作成からERPでの受注処理までを一つの流れとして繋ぐことが可能になります。

受注・請求：
BCで処理された受注・請求書の状況が、D365 Salesから確認できます。営業担当者は「あの案件、請求書はもう出ましたか？」という確認を経理に聞かずに済みます。

与信管理のリアルタイム連携

BCで管理している与信限度額・現在の与信使用額・未払い請求書の状況—これらをD365 SalesからVirtual Tablesでリアルタイム参照することで、営業担当者は受注を取る前に与信状況を確認できます。与信オーバーになりそうな場合は、受注入力の段階で自動的に警告が出る。承認フローが起動する。与信オーバーの受注を誰も知らずに処理してしまう、というリスクが排除されます。

Sales AgentがBCのデータを活用する

BCとD365 Salesが繋がっている環境では、Sales Agentの力が最大化されます。「この顧客の過去3年間の購買パターンを分析すると、毎年この時期に追加発注があります。今年もそのタイミングが近づいています。在庫は十分あります。与信残高も問題ありません。提案のドラフトを作成しますか？」BCだけ、あるいはD365 Salesだけでは、こうはなりません。両方が繋がっていて初めて、AIが「全局面が見えた状態」で動けます。

BCとD365 Salesの連携における注意点

BCのVirtual TablesはAPI Pageの設計次第で動きが変わります。在庫参照・与信照会などの読み取りはシンプルに実装できますが、受注作成などのトランザクション処理はAPI Pageの設計に注意が必要です。アーキテクトとして、どのデータをData Syncで同期し、どのデータをVirtual Tablesで参照し、どのデータはERP側に安全に閉じ込めておくか——この判断が、Lead to Cashの品質を決めます。

FOとDynamics 365 Salesの連携

BCとD365 Salesの連携を見てきました。では、Finance & Operations（FO）の場合はどうでしょうか。

FOとDataverseの連携の中心にあるのはDual-writeです。Dual-writeは、FOとDataverseの間でデータ変更に応じて双方向に書き込みが行われる仕組みであり、ほぼリアルタイムでの連携を実現する構成です。BCのData Syncが「同期する」という仕組みであるのに対し、FOのDual-writeは、常時同期に近い状態を前提とした連携構成です。FOで得意先マスタを更新すればD365 SalesのAccountに反映され、D365 SalesでContactを追加すればFO側に連携される。どちらか一方を単純な「マスター」とするのではなく、両システム間で整合性を維持する設計です。

さらに、Prospect to Cashの標準シナリオでは、見積・受注・請求関連のデータをSalesとFOの間で一貫したプロセスとしてつなぐことができます。ただし、ここでも重要なのは「標準で全部が勝手につながる」わけではないということです。価格計算、ステータス管理、データマッピングなど、設計と設定が品質を左右します。

Dual-writeが生み出す密結合

前回のBlogでお伝えしたように、FOとDataverseの連携の中心にあるのはDual-writeです。Dual-writeは、FOとDataverseの間でデータ変更に応じて双方向に書き込みが行われる仕組みであり、ほぼリアルタイムでの連携を実現する構成です。BCのData Syncが「同期する」仕組みであるのに対し、FOのDual-writeは、常時同期に近い状態を前提とした運用設計です。FOで得意先マスタを更新すればD365 SalesのAccountに反映され、D365 SalesでContactを追加すればFO側に連携される、双方向連携の構成です。どちらか一方を「マスター」とするのではなく、両システム間で整合性を維持する設計です。

入金・債権消込までDual-writeでカバーされている点できます。ERPで請求書が発行され、入金が確認された瞬間に、D365 Salesの案件ステータスが自動更新される。Lead to Cashが文字通り、リードから入金まで自動で繋がります。

「Virtual EntitiesはDataverse上に「テーブルの定義（窓口）」として登録されています。Power AppsやPower Automateからは通常のDataverseテーブルと同じように見えますが、実際のデータはFO側に存在し、アクセスのたびにFOのData Entityを経由してリアルタイムで取得します。Dataverseにデータのコピーはつくられず、データはFO側で完全に管理され続けます。ERPがSingle Source of Truth（データの一元管理）のまま、Power AppsやPower AutomateからERP側のデータを操作することができます。」

ビジネスロジックが確実に実行される

前回の記事でお伝えしたFOの特徴—「Virtual Entitiesを経由した操作でも、FOのビジネスロジックを確実に実行できる構成」は、Dual-writeにおいても同様です。D365 Salesから受注を作成した場合でも、FO側のすべての検証ルール・自動計算・在庫引当ロジックが必ず走ります。「Sales側から操作したから、ERPのロジックが動いていない」という事態が起きない設計になっています。これはエンタープライズ用途において、非常に重要な信頼性の担保です。

FOとD365 Salesの連携における注意点

非常に強力なDual-writeですが、前回の記事でお伝えした通り、FOとDataverseの接続は切断・再構成に注意が必要です。一度Dual-writeを有効化すると、データフローが密結合になります。「やっぱり繋ぐのをやめよう」という判断が、後になればなるほど難しくなります。また、Dual-writeの初期設定時に既存データの整合性確保が重要です。FOとD365 Salesにそれぞれ既存のマスタデータがある場合、どちらを正とするかを事前に明確に決めておかなければ、データの衝突が発生します。「繋ぐ前の設計」が、Lead to Cashの成否を分けます。

BCとFO、どちらを選ぶか

どちらが優れているかではありません。企業の規模・業務要件・グローバル展開の有無によって、最適な選択は異なります。中堅・中小企業でスピーディにLead to Cashを実現したいならBC。大企業でグローバルかつエンタープライズグレードの整合性が求められるならFO。そしてどちらの場合も、「繋ぐ前の設計の意図」が品質を決めます。

以前、「BCとFOどちらを選ぶべきか？」というBlogを書いた事があります。こちらも、ご参考までに。

CRM×ERPが繋がることで生まれる実例シーン10選

ここまでに描いた「繋がった世界」は、実際の業務でどんなシーンを生み出すのか。室長がお客様との対話の中でよく出てくる、リアルな10のシーンをお届けします。

01. SalesのQuoteがそのままERPの見積・受注に

営業担当者がD365 Salesで作成した見積が、顧客の承認と同時に自動的にERPの販売受注に変換されます。製品コード・数量・価格・納品先—すべての情報がそのまま引き継がれます。ERPへの手入力はゼロです。転記ミスも、入力漏れも発生しません。営業が受注を取った瞬間、ERPが動き出します。

02. 在庫状況をSalesの画面からリアルタイム確認

「この製品、今すぐ100個出せますか？」顧客からの質問に、営業担当者はD365 Salesの画面を見ながらその場で答えることができます。ERPのVirtual Tables経由で、在庫数量がリアルタイムで表示されています。「在庫は現在142個あります。来週の納品で問題ありません。」在庫確認の電話も、Excelへの転記も不要なのです。

03. 与信限度額をリアルタイムで参照・自動チェック

受注入力の瞬間に、ERPの与信残高が自動チェックされます。与信限度額500万円に対して、今回の受注で480万円を超える場合—自動的に警告が表示され、承認フローが起動します。営業が経理に「与信どうですか？」と確認する電話は不要になります。与信オーバーの受注事故が、構造的に防止されるのです。

04. フィールドサービス・プロジェクトサービスが顧客との接点になる

フィールドエンジニアが顧客先で作業を完了させる。その瞬間、顧客への報告書がCRMから自動送信され、顧客は作業内容・使用部品・次回推奨メンテナンス時期をその場で確認できます。「設備Aの老朽化が進んでいる。交換推奨時期：6ヶ月後」—このデータをトリガーに、Sales Agentが営業担当者にアラートを送ります。顧客にとっては「この会社は現場の状況をちゃんと把握している」という信頼になり、営業にとっては次の提案機会になります。

プロジェクト型ビジネスでも同じ構造が生まれます。プロジェクトの進捗・マイルストーン達成・完了報告—これらが顧客との共有画面としてCRMから届きます。「フェーズ1が完了しました。フェーズ2のご提案をご用意しています。」担当PMが現場で感じた「次のニーズ」がSales Agentに渡り、次の商談が生まれます。工数・原価・請求実績はERPに連携され、収益性もリアルタイムで把握できます。

05. コールセンターの対応履歴が営業・マーケティングに流れる

顧客がコールセンターに問い合わせをしました。その内容と対応結果が、リアルタイムでCRMの顧客プロファイルに追記されます。担当営業はSFAの画面で「昨日、製品Bの操作方法について問い合わせあり。解決済み」という情報を確認してから電話をかけます。「先日、製品Bについてご連絡いただいていましたね。その後いかがでしょうか？」
顧客は「ちゃんと見てもらえている」と感じます。そして、この問い合わせ対応にかかったコスト（対応時間・担当者工数）は、ERPのサービス元帳に自動計上されます。「この顧客のサポートコストは年間いくらかかっているか」が、ERPで正確に把握できます。サポートコストの高い顧客には有償サポート契約の提案ができる。マーケティング部門はこの問い合わせ傾向をセグメント化して、同じ製品を使う顧客グループにハウツー動画を自動配信します。結果、問い合わせ件数が減り、顧客満足度が上がります。CRMのサービス履歴とERPのコスト管理が繋がって初めて、サービスの収益性が見えてくるのです。

06. Marketing AgentがCDPデータを活用してパーソナライズ配信

CDPに統合された購買履歴・行動ログ・問い合わせ履歴・フィールド訪問記録—構造化・非構造化のデータをMarketing Agentが分析します。ここで重要なのは、CDPに食わせるデータにERPの情報が含まれていることです。ERPの購買履歴（いつ、何を、いくらで買ったか）、請求・入金状況（優良顧客か、支払いが遅延しがちか）、在庫・納期情報（今提案できる製品は何か）—これらの構造化データと、Webの行動ログ・通話録音・メールという非構造化データが、Microsoft FabricのOneLakeを通じてCDPに統合されています。「顧客Aは製品Xを購入して8ヶ月が経過。ERPの購買履歴では毎年この時期に追加発注がある。Webサイトで製品Yのページを先週3回閲覧。過去の問い合わせ傾向から製品Yへの関心が高いと判断。ERPの在庫は十分。与信残高も問題なし。」この分析結果を基に、製品Yの提案メールが自動生成・配信されます。ERPのデータがCDPに流れ込んでいるから、Marketing AgentはERPの現実（在庫・与信・購買パターン）を踏まえた上で、マーケティングを動かせる。「なんとなく一斉送信」から、「この顧客に、今、これを届ける。しかも在庫と与信を確認した上で」という非常に効率の良い販促活動ができるのです。

07. 請求書の発行・支払状況が営業にリアルタイムで見える

ERPで請求書が発行された瞬間、D365 Salesの案件に「請求済み」のステータスが自動更新されます。支払期限が近づいている顧客には、自動でアラートが営業担当者に届きます。「〇〇株式会社の請求書、支払期限まであと3日です。」入金が確認されると、案件が「完了」に自動更新されます。「あの案件、入金されましたか？」という確認作業が消えるのです。

08. Sales AgentがLead to Cashを自律的に推進する

顧客からメールで「製品Xを50個、来月15日までに納品してほしい」という引き合いが届いた。

Sales Agentが自動的に動き出す。

• ERPの在庫を確認—「在庫63個。問題なし。」
• 与信残高を確認—「残高220万円。今回の受注額180万円。問題なし。」
• 納期を確認—「生産・物流スケジュール上、来月10日納品可能。」
• 見積ドラフトを自動生成—「単価・数量・納期・支払条件を含む見積書を作成しました。確認してください。」

営業担当者は内容を確認して、承認ボタンを押すだけです。Sales Agentが、ERPとCRMの両方を横断して、Lead to Cashを自律的に推進します。

09. グローバル展開で「Dynamics 365（CRM＋ERP）」連携が真価を発揮する

海外現地法人には、それぞれのERP（FO／BC）があります。現地の営業担当者がD365 Salesで受注を入力すると、現地ERPに販売受注が連携される—これは現地法人単体のLead to Cashです。グローバル展開で真価を発揮するのは、その先です。海外現地法人からの発注が、日本本社の受注として自動的に連携される。現地ERPと本社ERPが繋がることで、グループ内取引の伝票が自動生成されます。本社の経理担当者は、世界各拠点の受注・在庫・売掛金をリアルタイムで把握できます。

さらに、各拠点のD365 SalesのCRMデータ—商談件数・受注確度・パイプライン—も本社に集約されます。「今期の売上予算に対して、現時点の受注実績はいくらか。商談中の案件が全てクローズすれば予算達成できるか」—予算vs実績＋見込みの可視化が、グループ全体で一画面で実現します。どの拠点でボールが落ちているかが、リアルタイムでわかります。

各拠点の需給状況・BOM・製造原価がグループ全体で共有されることで、在庫の最適配置と原価管理がグローバルで一元化されます。製造拠点と販売拠点が同じプラットフォームで繋がることで、SCMの効率化と製造原価の透明性が実現します。「どの拠点で作って、どこから出荷するか」という意思決定が、リアルタイムのデータを基に行えるようになります。

FOとの連携ではDual-writeによりほぼリアルタイムの同期が実現します。BCとの連携ではData Syncによる定期同期が基本となります。どちらのERPを本社・現地に選ぶかは規模・要件次第ですが、D365 Salesを共通の営業基盤、D365ERPを共通のオペレーション基盤として使いながら、グループ全体の財務・在庫・売上見込みを可視化するという構造は同じです。

10. Lead to Cashの全体をPower BIとFabricで可視化する

Lead to Cashの各ステージを、Power BIのダッシュボードでリアルタイムに可視化する。

• リード獲得数・育成状況（マーケティング）
• 商談件数・受注確度・営業パイプライン（SFA）
• 受注金額・出荷状況・納期遵守率（ERP）
• 請求額・入金状況・売掛金残高（ERP）
• 顧客満足度スコア・問い合わせ件数（カスタマーサービス）
• 作業完了数・修理コスト・アップセル／クロスセル創出数（フィールドサービス）
• プロジェクト請求進捗・追加受注額・原価vs収益性（プロジェクトサービス）

CRMとERPが良質な設計により展開できていると、Microsoft FabricのOneLakeに集約された構造化・非構造化データが、Power BIを通じて経営層に一画面で届く。「どのステージでボールが落ちているか」が、リアルタイムで見えます。ノックフォワードが起きている場所が、データで可視化されるのです。

攻めと守り、そして顧客との全接点を一つに

クボタスピアーズ船橋・東京ベイ 対 埼玉パナソニックワイルドナイツ｜結果は26—24

今日の試合を振り返ると、勝敗を分けたのは一つのことでした。どちらのチームも、攻めと守りが高いレベルで繋がっていた。アタックがブレイクダウンでボールを確保する。スクラムハーフが素早く展開する。バックスが走る。フォワードがサポートに入る。そしてトライ。その一連の流れの中で、どこか一箇所でも連携が切れたら—ボールが前に落ちたら—攻撃はそこで終わります。ノックフォワードは、繋ぎ切れなかった瞬間に起きます。

ビジネスの「ノックフォワード」はどこで起きているか

今日、この記事を読んでくださった方の会社では、どこでボールが落ちているでしょうか。

• マーケティングが獲得したリードが、SFAに届くまでの間で落ちていないか。キャンペーンに反応した見込み客の熱が、Excelへの転記と手入力の間に冷めていないか。
• 営業が受注した情報が、ERPに届くまでの間で落ちていないか。同じ内容を2つのシステムに入力する間に、転記ミスと入力漏れが生まれていないか。
• フィールドエンジニアが現場で掴んだ情報が、次の営業提案に届くまでの間で落ちていないか。「設備の老朽化が進んでいる」という現場の気づきが、報告書の中に埋もれたまま提案機会に変わっていないか。
• プロジェクトマネージャーが現場で感じた「次のニーズ」が、営業に届くまでの間で落ちていないか。「フェーズ2への関心あり」というメモが、プロジェクト管理ツールの中で眠ったままになっていないか。
• コールセンターが顧客から聞いた声が、マーケティングに届くまでの間で落ちていないか。「この製品の使い方がわからない」という問い合わせが、同じ製品を使う顧客グループへの改善提案に繋がっていないか。
• ERPの購買履歴・与信情報が、CDPとMarketing Agentに届くまでの間で落ちていないか。「毎年この時期に追加発注がある」という購買パターンが、マーケティングの判断材料になっていないか。
• 営業が商談の中で聞いた顧客の予算感・導入時期・競合情報が、マーケティングのセグメント設計に届くまでの間で落ちていないか。「来期検討」という一言が、適切なタイミングでのナーチャリングに繋がっていないか。
• 請求書が発行されたという情報が、営業に届くまでの間で落ちていないか。「そろそろ支払期限です」という気づきが、ERPの中だけで完結して営業の手元に届いていないか。
• 各拠点の在庫・需給状況が、製造・調達の意思決定に届くまでの間で落ちていないか。「あの拠点に在庫が余っている」という情報が、別の拠点への緊急発注を防げていないか。
• AIが判断に必要なデータが、学習・推論の基盤に届くまでの間で落ちていないか。断片的なデータしか持たないAIは、断片的な提案しかできない。データの川が繋がっていてこそ、AIは本領を発揮できる。

「うちはちゃんとシステムを入れている」—でも、繋がっていない。その「繋がっていない」という状態が、静かに、じわじわと、ビジネスの機会を蝕んでいます。

CRMは、SFAだけではない

この記事を通じてお伝えしたかったことの一つが、これです。CRMとは、顧客との全タッチポイントを管理するプラットフォームです。デジタルマーケティングで顧客を知り、CDPで顧客を理解し、SFAで顧客に提案し、ERPで顧客の注文を履行し、フィールドサービス・プロジェクトサービスで顧客の現場を支え、カスタマーサービスで顧客の声を聞く。そしてその全ての接点から生まれたデータが、一つのプラットフォーム上に流れ込んでくる。それが、Dynamics 365というプラットフォームが持つ、本来の姿です。

バラバラでも、動く。しかし、
同一プラットフォームで統合されていた時、AIは初めて本領を発揮できる。

AI Agentは、データの川の上を泳ぐ

Sales Agent、Marketing Agent、Customer Service Agent、Field Service Agent—AI Agentたちは、データの川の上を泳ぎます。

川が繋がっていれば、Agentは上流から下流まで自由に泳げます。顧客の全文脈を把握して、最適な判断を、自律的に、リアルタイムで下せるのです。

川が途中で干上がっていたら—、データがサイロ化していたら—、Agentはそこで立ち往生します。

どれだけ優秀なAIでも、届いていないデータを使うことはできません。

AIへの投資を最大化するためには、まずデータの川を繋げることが先決です。

CDPを入れる前に。デジタルマーケティングを強化する前に。AI Agentを導入する前に。

「うちのデータの川は、どこかで干上がっていないか？」

この問いを持つことが、DXプロジェクトの出発点になります。

Lead to Cash は、ビジネスの「トライ」である

ラグビーでトライを取るためには、相手のゴールラインまでボールを繋ぎ続けなければなりません。リードを獲得する。育てる。商談に変える。見積を出す。受注する。納品する。請求する。入金を確認する。また次のリードに繋げる。この一本の流れが、Lead to Cashです。どこか一箇所でもノックフォワードが起きたら、トライは取れません。CRMとERPが繋がり、データが途切れずに流れ、AIが全局面を把握して動く—その状態を作ることが、現代のビジネスにおける「トライを取るための戦略」です。

室長纏め｜攻めと守り、そして顧客との全接点を一つに

Microsoft MVP＆Microsoft Regional Directorとして、私がMicrosoft ERPのお客様にMicrosoft CRMを、Microsoft CRMのお客様にMicrosoft ERPを訴求し続けているのは、このためです。

ERPだけでは、攻めのDXができない。

CRMだけでは、守りのDXができない。

両方揃って、初めてDXになる。

そして両方が同一プラットフォーム上で繋がっていた時、AI Agentが初めて本領を発揮し、顧客との関係が深まり続け、ビジネスが加速します。

「攻めと守り、そして顧客との全接点を一つに。」

これが、Dynamics 365というプラットフォームが描く、AI時代のビジネスの姿です。

最後に、１つのシーンを共有させていただきたいと思います。

実は今日の試合は、トップリーグで84試合の笛を吹いてこられた滑川剛人レフリーの引退試合でした。彼の試合終了後の発言をここで引用します。

本日は、協会関係者の皆さま、今日会場に足を運んでくれた皆様、そして最高の試合をしてくれた両チームの皆さま、本当にありがとうございました。5年前に選手から、レフリーにうつって、本当にしんどい思いを正直沢山しました。選手のときには、試合が終われば、勝った。負けた。それで感情が左右されて、モチベーションにもなりましたが、レフリーには、勝ち負けはなく、負けたほうからは、何かしら言われます。それはチームだけではなくて、ここにいる観客の皆さまも同じです。それは、一人の人間だから。どちらかのチームを応援しているから。当たり前の事だと思っています。僕はそれを必死にエネルギーに変えてやってきました。なので、これからはゆっくりします。本当に素晴らしい後輩たちがいっぱいいますので、これから日本のラグビー界の発展に貢献してくれると信じています。いつも通り、厳しく、優しく、レフリーに対して接していただけるとありがたいです。本当に5年間ありがとうございました。

引退するにあたり、このようなメッセージも出されています。

常に求められる基準に向き合い、自分自身に問い続けながら過ごしてきた時間でした。選手としてもレフリーとしても、決して楽な道ではありませんでしたが、その全てが自分を支えてきたと感じています。グラウンドに立つ以上、ひとつひとつの判断に責任を持つ。その重みと向き合い続けた日々に、悔いはありません。

とても実直で、嘘のないメッセージに、無意識のうちに、TVモニターに向かって拍手をしていました。ここに、私が学んだ事を残しておきます。

『グラウンドの規律が、自由なアタックを可能にする』

—CRM・ERP・AIは独立領域ではなく、データ信頼性を中心に統合された意思決定システム—

ラグビーにおいて、観客を魅了するステップや華麗なトライ、すなわち「攻め（CRM）」が生まれる背景には、常に厳格なルールと規律が存在します。もしレフリーがいなければ、試合は成立せず、選手は命の危険に晒され、誰もリスクを取って攻める（チャレンジする）ことはできません。

滑川レフリーの言葉は、まさに企業における「守りのDX（ERP）」の真髄と、それを支えるプロフェッショナル（プロジェクトリーダーやコアメンバー）の覚悟そのものです。

1. 常に求められる基準に向き合う（システムの標準化）
「常に求められる基準に向き合い、自分自身に問い続けながら過ごしてきた時間でした」

ERPの導入や運用は、業務の標準化（Best Practice）という「基準」との戦いです。独自のやり方に逃げる（反則をする）方が楽な場合もあります。しかし、世界基準、あるいは自社が目指すべき厳格な基準に常に自分たちのオペレーションを適合させ（Fit to Standard）、問い続けること。これこそが、企業の強固なインフラ（守りのDX）を創り上げます。

2. 決して楽な道ではないが、全てが自分を支える（ガバナンスの構築）
「決して楽な道ではありませんでしたが、その全てが自分を支えてきたと感じています」

データの統合、プロセスのクレンジング、内部統制の強化。ERPという「守りのDX」は地味で、時に現場からの反発もあり、決して楽な道ではありません。しかし、その強固なガバナンス（規律）という土台があるからこそ、企業は「攻めのDX（CRM）」で新しいビジネスモデルへと果敢に飛び出す（アタックする）ことができるのです。

3. 判断に責任を持つ。その重みと向き合い続ける事（データの信頼性）
「グラウンドに立つ以上、ひとつひとつの判断に責任を持つ。その重みと向き合い続けた日々に、悔いはありません」

レフェリーのジャッジは、その瞬間の感覚ではなく、ルールという共通基盤と、その場で蓄積される記録に支えられています。

そしてその判断は、試合後も検証可能であり、必要であれば説明責任を伴います。

この構造こそが、企業における「データの信頼性」の本質です。

ERPやCRMに蓄積されるデータは、単なる記録ではありません。

それが「なぜその数値になっているのか」を追跡できること。
誰が見ても同じ意味として解釈できること。
そして、後からでも検証できる形で残っていること。

この3つが揃って初めて、データは意思決定の根拠になります。

つまりデータの信頼性とは、“正しいはずの数字”ではなく、「説明可能性」と「再現性」と「追跡可能性」を備えた状態です。

レフェリーがルールという共通基盤に基づいてジャッジを行い、その判断は記録とともに後から検証可能な形で残されます。この「ルール・判断・記録」が一体となっている構造こそが、公平性の本質です。その信頼があるからこそ、選手は安心してリスクを取り、試合は成立します。

ラグビーのレフェリーは、最も近くで試合を見守り、最も公平にルールを適用する存在です。その存在によって、選手は安心して挑戦でき、試合は成立します。私たちが取り組む「守りのDX（ERP）」も同じです。目立つのは「攻めのCRM」かもしれませんが、バックオフィスや基盤を支えるERPの変革が加わることで、企業というグラウンドに「規律と安心」をもたらします。

滑川氏の「悔いはない」という言葉。

私たちも自らの基準に誇りを持ち、一貫した判断（データとプロセス）に向き合い続けたい。

そこにこそ、最強の「守り」と、究極の「攻め」を支える最高のDX365マインドセットがあるのだと思います。

今日の記事が、皆さんのビジネスにおける「次のパス」や「正しい判断」に繋がれば、これ以上嬉しいことはありません。

それでは、また次回。Let’s Enjoy our DX365Life! 🚀