Mercura CPQ + Microsoft Dynamics 365 Sales
Dynamics 365 Salesのプロセスに製品構成とCPQを追加
アカウント、取引先担当者、商談はDynamics 365 Salesに置き、ガイド付きの製品構成、商流ルール、価格設定、構成に応じた見積はMercuraで扱います。
Dynamics 365 Salesは引き続きアカウント、取引先担当者、商談、営業活動を管理します。Mercuraは、カタログからの選択を超えて、ルール、依存関係、計算、価格、ドキュメントが必要になる製品販売向けの専用構成レイヤーを追加します。
Microsoftパートナーですか
製造業のお客様がスプレッドシート中心の構成やERPカスタマイズの限界に達したとき、Mercuraは既に導入しているシステムを置き換えずに、商流構成レイヤーを追加できます。
Dynamics 365 Sales向けCPQとは
Dynamics 365は顧客関係を、Mercuraは製品の複雑性を担います
Dynamics 365 Sales
- • アカウント
- • 取引先担当者
- • 商談
- • 活動
- • 営業パイプライン
- • 予測
- • 顧客コンテキスト
Mercura CPQ
- • ガイド付きセリング
- • 製品選択
- • ルールと制約
- • 依存関係
- • 計算
- • 構成価格
- • ビジュアライゼーション
- • ドキュメント
- • 構成の技術データ
承認済みの成果
- 構成済み明細
- 商流説明
- 価格
- 構成参照
- 見積ドキュメント
- 連携契約で定義したその他の項目
正確なマッピングは、各Dynamics 365環境のデータモデルと営業プロセスに依存します。
CRMは顧客を知っているが、製品をどう構成するかは決められないとき
Dynamics 365 Salesは、顧客は誰か、どの商談が開いているか、どの営業活動があったか、パイプライン上のどの段階かを管理するのに向いています。 複雑な製造では別の知識層が必要になります。要件に合う製品、互換性のあるオプション、有効な寸法、必須アクセサリ、構成変更による価格変化、提案に載せる仕様、ERPや生産が次に必要とする情報です。 Mercuraはこれらの反復的な判断を構成ロジックに変換し、営業がエンジニアリングに毎回見積を回さずに自律的に動けるようにします。
Dynamics 365 Salesでよくあるアーキテクチャパターン
正しいCRM + CPQ設計は一つではありません。見積、価格、下流の受注実行をどのシステムが担うかで、適切なパターンが変わります。
A
パターンA — CRM主導で商談に戻す
Dynamics 365 Sales → Mercura CPQ → Dynamics 365 Sales
Dynamics 365 Salesの商談が商流の中心である場合に一般的です。Mercuraが構成と見積出力を担当し、合意した明細、参照、ドキュメント、価格をプロジェクトで定義した商談や関連CRMレコードにマッピングします。
B
パターンB — Dynamics 365 SalesとBusiness Central
Dynamics 365 Sales → Mercura CPQ → Business Central
CRMがDynamics 365 Salesで、実務の見積や受注がMicrosoft Dynamics 365 Business Centralで続く構成でよく見られます。Mercuraは顧客向け構成と、既に使っているERPの販売オブジェクトの間に位置します。
C
パターンC — Dynamics 365 SalesとFinance & Supply Chain Management
Dynamics 365 Sales → Mercura CPQ → Finance & Supply Chain Management
商談がSalesにあり、実行がMicrosoft Dynamics 365 Finance & Supply Chain Managementに移るエンタープライズ製造で一般的です。MercuraがERPの生産・財務に入る前に、販売可能な構成を定義します。
これらは一般的な選択肢であり、すべての顧客が三つすべてを使うという意味ではありません。各データの所有は連携設計時に合意します。
ロジックが複数システムにあっても、営業体験は一つに
商談コンテキストから構成
CPQプロセスはDynamics 365にある商流コンテキストから始められるため、基本的な顧客・商談情報を探したり再入力したりする必要が減ります。
技術的に無効な構成を防ぐ
Mercuraのルールと制約が許可された組み合わせを案内し、営業が製品ロジック全体を暗記する必要を減らします。
構成価格を計算
価格は外部ソースと構成固有の計算を組み合わせられます。価格の各要素の正（ソース・オブ・トゥルース）は実装時に定義します。
同じデータから提案を生成
構造化された構成から、製品、オプション、数量、仕様、画像、価格を含む商流ドキュメントを作成できます。
見積を作り直さずプロセスを継続
承認後、合意した項目と明細を次の商流ステップに渡し、手入力を減らせます。
MercuraはDynamics 365 Salesとどう接続できるか
Dynamics 365 SalesはMicrosoft Dataverseをデータ基盤として使います。連携は各環境のテーブル、項目、カスタマイズ、営業プロセスに合わせて設計します。 典型的なアーキテクチャでは、次のような情報を利用できます。具体的なオブジェクト、同期方向、所有は連携分析で定義します。
Mercuraへ
- アカウント
- 取引先担当者
- 商談
- 通貨
- 商流コンテキスト
- 該当する場合の製品または価格
Mercuraが計算
- 製品選択
- オプション
- ルール
- 属性
- 数量
- 計算値
- 構成後価格
- ドキュメント
CRMプロセスへ戻る
- 構成参照
- 説明
- 商流明細
- 価格
- ドキュメント
- 合意した項目
Dynamics 365 Sales + Mercura + ERP
多くのメーカーでは、CRMがプロセスの最終段階ではありません。 商談はDynamics 365 Salesで始まり、商流構成はMercuraで行い、承認結果はBusiness Central、Dynamics 365 Finance & Supply Chain Management、または別のERPへ進むことがあります。 各段階をどのアプリケーションが担うか、アーキテクチャで明確にします。
Dynamics 365 Sales
- アカウント
- 商談
- 営業活動
Mercura CPQ
- 要件
- 構成
- ルール
- 価格
- 見積
ERP
- 受注
- 品目
- 部品
- 製造
- 請求
MicrosoftパートナーはいつMercuraを案件に持ち込むべきか
- 標準見積の妥当性確認にエンジニアリングが必要になっている。
- 製品構成ロジックがスプレッドシートに残っている。
- ERPカスタマイズの保守が難しくなっている。
- Dynamics 365 Salesでガイド付きセリングが必要。
- 販売店または顧客向けのセルフサービス構成が必要。
- 価格がリスト価格だけでなく構成ルールに依存している。
- 見積に構成固有のドキュメントが必要。
- 製品の複雑性がERP取引の前に決まる。
よくある質問
Dynamics 365 Sales向けCPQとは
Dynamics 365 Salesのプロセスに接続する構成、価格、見積のレイヤーです。CRMは顧客関係と商談を保持し、Mercuraは要件を有効で見積可能な構成に変えるロジックを担います。
MercuraはDynamics 365 Salesを置き換えるのか
いいえ。Dynamics 365 SalesはCRMとして残ります。製品販売にルール、依存関係、計算、構成固有のドキュメントが必要な場合にMercuraが補完します。
MercuraはDynamics 365の商談データを使えるか
はい。連携でアカウントと商談のコンテキストを利用できます。具体的な項目はDataverseモデルと環境のカスタマイズに依存します。
構成結果はDynamics 365 Salesに戻せるか
はい。Mercuraの出力は合意した商流プロセスにマッピングできます。構成参照、明細、価格、ドキュメントなど、構造はプロジェクトで定義します。
価格はどこで計算すべきか
アーキテクチャ次第です。価格はERPまたはCRMから来たり、Mercuraの構成ロジックと組み合わせたり、主にCPQで計算したりできます。価格の各部分について明確な正を定義してください。
MercuraはDynamics 365 SalesとERPの両方で使えるか
はい。CRM、CPQ、ERPをつなぐ一般的なパターンで、商談、構成、受注を手作業で二重管理せずに一つの流れにできます。
御社のDynamics 365環境ではどう機能するか
実際の構成可能製品、典型的な商談、現在の見積の作り方を教えてください。そのプロセスをもとに、Mercuraの位置づけとDynamics 365とのデータ交換をご一緒に整理できます。
CPQデモのリクエスト