
ERPおよび運用コンテキスト
Dynamics 365 Finance & Supply Chain Management
- リリース済み製品
- 製品マスタ
- 顧客
- 単位と通貨
- 在庫
- サイトと倉庫
- 原価データ
- 関連する価格入力
- 製造構造
- 生産実行
Mercura + Microsoft Dynamics 365 Finance & Supply Chain Management
複雑な製品を構成し、構成に応じた価格を算出し、顧客向け見積を作成し、承認済みの結果をDynamics 365へ連携します。
Mercuraは、Microsoft Dynamics 365 Finance and Supply Chain Management(通称 Dynamics 365 F&O または FSCM)の周辺に、営業向けのCPQおよび製品コンフィギュレーション層を追加します。ERPは従来どおり、運用プロセスの中核として機能し続けます。
販売見積
30秒でわかる答え
Dynamics 365 F&O向けCPQは、Configure(構成)・Price(価格)・Quote(見積)を、Microsoft Dynamics 365 Finance and Supply Chain Managementで管理する製品・顧客・運用データと結びつけます。営業担当者が顧客要件を品目番号、寸法、オプション、BOM部品、価格へ手作業で変換するのではなく、Mercuraがユーザーに構成をガイドし、Dynamics 365で実行可能な構造化された商談結果を生成します。
顧客要件 → 製品構成 → 価格算出 → 見積 → 承認 → Dynamics 365見積/受注 → 製造
Dynamics 365は引き続きERPおよびサプライチェーン基盤です。Mercuraは、正しい受注を作成する前に必要となる、知識集約型の営業判断を担います。
重要な区別
Microsoft Dynamics 365 Supply Chain Managementには、ネイティブの製品構成技術が含まれています。制約ベースの製品構成モデルには属性、制約、計算、部品、BOM明細、工程オペレーションを含めることができ、構成可能な製品は販売見積および販売受注で利用できます。多くの製造業にとって、このネイティブ機能は価値があります。
問いの本質は次ではありません:
Dynamics 365で製品を構成できるか?
できます。
重要な問いは次のとおりです:
製品構成はどこで終わり、営業体験はどこから始まるべきか?
Dynamics 365のネイティブ製品構成は、製品・製造・ERP構造と密接に結びついています。Mercura CPQは次に重点を置きます:
必ずしもどちらか一方のコンフィギュレーターを選ぶ必要はありません。多くの企業にとって最強のアーキテクチャは、Dynamics 365の運用向け製品ロジックとMercuraの営業向け構成の組み合わせです。
システムの責務
クリーンなアーキテクチャはERPを重複させません。各システムに明確な責務を与えます。

ERPおよび運用コンテキスト
Configure · Price · Quote

実行
アーキテクチャはお客様のDynamics 365実装に従います。Mercuraは、あらかじめ定義されたCPQデータモデルに製品、BOM、販売プロセスを再構築することを、すべての製造業に要求するものではありません。
ネイティブ構成 vs. CPQ
Dynamics 365の製品構成は、運用向けの製品および製造構造と密接に結びついています。Mercura CPQは、顧客要件を販売可能で理解しやすく、商談上正しいソリューションへ変換するために必要なすべてに焦点を当てます。
| 要件 | Dynamics 365 SCM 製品構成 | Mercura CPQ |
|---|---|---|
| 製品マスタとリリース済み製品 | 中核的な責務 | 関連データを参照またはマッピング |
| 製品寸法 | 中核的な責務 | 営業向けフローで寸法を提示可能 |
| 制約ベースの構成 | 対応 | 対応 |
| BOM構成 | 中核的な製造機能 | 商談/部品出力を計算またはマッピング可能 |
| 工程オペレーション | 中核的な製造機能 | 通常はSCM/エンジニアリングへ引き渡し |
| 販売受注からの構成 | 中核機能 | 上流の営業体験を構築可能 |
| 顧客要件からのガイド付きセリング | ERP志向 | CPQの中核機能 |
| 非技術者向けの営業UX | 主目的ではない | 中核機能 |
| 販売店向けコンフィギュレーター | 周辺ソリューションが必要 | 中核ユースケース |
| 顧客セルフサービス | 周辺ソリューションが必要 | 中核ユースケース |
| 2D / 3Dビジュアル構成 | 主目的ではない | 中核機能 |
| 構成固有の提案ドキュメント | ERPドキュメントプロセス | 中核機能 |
| 複雑な商談計算 | ERPモデルに依存 | 中核機能 |
| ヘッドレス/カスタムフロントエンド | カスタムアーキテクチャが必要 | Mercuraのネイティブアプローチ |
| CRM主導の構成 | 連携が必要 | 接続された営業プロセス向けに設計 |
Dynamics 365単体が適する場合
構成の主目的が有効なERP製品バリアント、BOM、工程の決定であり、ユーザーがDynamics 365プロセス内で製品を構成することに慣れている場合。
Mercuraを追加する場合
顧客要件を、ERPトランザクションを作成する前に、技術的な選択、商談オプション、計算、ビジュアライゼーション、または顧客向け提案へ変換する必要がある場合。
両方を組み合わせる場合
Dynamics 365に価値ある製造構成ロジックがすでに存在し、それを権威ある情報源として維持しつつ、営業にはよりシンプルで強力な体験が必要な場合。
F&O CPQに唯一正しいアーキテクチャはありません。適切なモデルは、製品知識がすでにどこに存在するかによって決まります。
お客様はすでに成熟したDynamics 365製品構成モデルをお持ちです。Mercuraは営業ジャーニーを提供し、必要な入力を取得します。合意した連携は、技術的に適切な場合、それらの入力をDynamics 365の構成プロセスへ変換します。
最適な場合:
Mercuraには販売可能な構成を決定するためのルールが含まれ、Dynamics 365に必要な品目、数量、パラメータ、商談値を生成します。
最適な場合:
Mercuraは反復可能な商談構成を自動化し、構造化されたパラメータをエンジニアリング、CAD、PLM、または別の技術システムへ渡します。検証済みのエンジニアリング結果がその後Dynamics 365へ進みます。
最適な場合:
Mercuraは、すべての製品ロジックを1つのアプリケーションに押し込むのではなく、Dynamics 365周辺のシステムと連携できます。
営業体験
顧客は通常、製品マスタ、構成寸法、品目番号、BOMバリアント、部品コード、工程、倉庫、エンジニアリング属性を把握した状態で来訪しません。顧客は要件を持って来ます。
"時速3,000本の充填システムが必要です。このボトルサイズで、自動キャッピングとこれらの衛生要件を満たす構成にしてください。"
能力、環境、寸法、設置要件、顧客の嗜好を取得します。
ルールを用いて、どの製品ファミリー、機械、またはシステムが適切かを判断します。
互換性のあるオプション、部品、アクセサリのみを提示します。
寸法、数量、エンジニアリング値、原価、追加料金、商談価格を算出します。
構成が変わるたびに画像、図面、またはインタラクティブ3Dを更新します。
顧客が何を購入するのかを説明する提案書を生成します。
承認済み構成を、合意した見積、受注、製造ワークフローへ連携します。
構成から見積へ
ERPデータと顧客向け情報は異なる目的を果たします。Mercuraは構造化された構成を用いて、顧客が実際に必要とする情報を含む営業ドキュメントを生成します。同じ構成は同時に、Dynamics 365向けのより技術的な出力も生成できます。これにより、顧客が見積を承認した後に、販売したソリューションを手作業で再作成する必要がなくなります。
多くのエンタープライズDynamics環境では、複数のDynamicsアプリケーションを使用しています。
顧客、見積、製品情報の正確な記録システムは、Microsoftアーキテクチャによって異なります。Mercuraは商談プロセスがERP内で始まることを要求しません。
F&Oインスタンスにプラグインを差し込めばすべてが動く、という信頼できる約束はありません。適切なCPQ連携は、Dynamics環境が実際にどのように機能しているかを理解することから始まります。
技術連携
Dynamics 365の財務・運用アプリは複数の連携パターンを公開しています。適切なインターフェースは、ボリューム、レイテンシ要件、既存の拡張、プロセスが同期か非同期かによって異なります。最終的な契約は実装時にフィールドレベルで合意します。
| データ | 方向 | 一般的なアプローチ | 目的 |
|---|---|---|---|
| リリース済み製品 | Dynamics 365 → Mercura | パブリックデータエンティティ / OData / 連携レイヤー | ERP製品マスタの再利用 |
| 製品属性 | Dynamics 365 → Mercura | データエンティティ / マッピング連携 | 構成コンテキスト |
| 顧客 | Dynamics 365 → Mercura | パブリックデータエンティティ / OData | 顧客固有のセリング |
| 単位と通貨 | Dynamics 365 → Mercura | データエンティティ | 一貫した商談計算 |
| 価格入力 | Dynamics 365 → Mercura | OData、サービス、またはマッピング連携 | ERP商談データの再利用 |
| 在庫コンテキスト | Dynamics 365 → Mercura | 必要に応じてOData/サービス | 在庫を考慮したセリング |
| 構成 | Mercura → Dynamics 365 | データエンティティ、マッピングエンドポイント、またはカスタムサービス | 販売内容の保持 |
| 販売見積 | Mercura → Dynamics 365 | データエンティティ / サービス | ERP見積フローの継続 |
| 販売受注 | Mercura → Dynamics 365 | データエンティティ / サービス | 実行可能な受注の作成 |
| 部品 / BOM入力 | Mercura → Dynamics 365 | 実装固有の連携 | 受注生産型の引き渡し |
| エンジニアリングパラメータ | Mercura → Dynamics 365 / CAD / PLM | APIマッピング | 技術的な下流自動化 |
| Mercura参照 | Mercura → Dynamics 365 | マッピングフィールド | エンドツーエンドのトレーサビリティ |
Dynamics 365は複数の連携パターンをサポートしており、それらを互換性のあるものとして扱うべきではありません。
財務・運用アプリは、OData RESTエンドポイントを通じてパブリックデータエンティティを公開します。
Data Management Frameworkは、インポート、エクスポート、連携のためのデータエンティティとデータパッケージをサポートします。
定期連携は、財務・運用アプリと外部アプリケーション間でドキュメントまたはファイルを交換できます。
すべての企業のDynamics 365実装が標準のパブリックエンティティで表現できるわけではありません。プロセスがカスタムテーブル、フィールド、ビジネスロジック、特殊な価格設定、製品構成ロジック、企業固有の受注作成、または製造プロセスに依存する場合、カスタムサービスまたは拡張が適切なアプローチとなることがあります。
Mercuraの連携設計はビジネスプロセスから始まり、適切なDynamics 365インターフェースを選択します。すべての実装がワンクリックのOData接続であると約束するものではありません。
Dynamics 365財務・運用連携では、OAuth 2.0とMicrosoft EntraアプリケーションIDを用いた、認証済みシステム間通信が利用できます。正確なセキュリティアーキテクチャは、連携パターンとDynamics 365環境によって異なります。
導入時に定義する項目の例:
万能の答えはありません。すべてのDynamics 365価格ルールをCPQ内に重複させることも、すべての構成固有の計算をERPに押し込むことも、通常は望ましくありません。
Mercuraが構成を決定し、関連する商談価格はDynamics 365から取得します。
最適な場合: ERPがすでに営業プロセスに必要な最終価格を生成している。
Dynamics 365が品目価格、顧客情報、またはその他の商談入力を提供します。Mercuraが構成固有の部分を計算します。
基本機械 + 幅追加料金 + ステンレス係数 + 高容量モーター + 制御パッケージ + 設置 − 顧客値引き = 構成済み販売価格
最適な場合: ERP価格設定は標準製品に有効だが、構成済みソリューションが数式とオプション依存の価格設定を導入する。
Mercuraが完全なCPQ価格モデルを担い、承認済み販売価格を受注構造とともにDynamics 365へ送信します。
最適な場合: 価格が構成パラメータ、計算、顧客要件、または製品関係に大きく依存する。
価格の所有権はアーキテクチャ上の判断であり、CPQ機能のチェックリストではありません。
製造業にとって、見積の作成は問題の半分にすぎません。運用部門も知る必要があります。具体的に何を販売し、何を製造すべきか。
Mercuraが既存の販売可能/製造可能な製品またはバリアントを特定します。
出力: 製品 + 構成参照 + 数量 + 価格
Dynamics 365製品構成が運用向け製品構造の生成を引き続き担います。Mercuraは合意したプロセスに必要な営業向け構成コンテキストを提供します。
出力: 構成パラメータ → Dynamics 365構成
Mercuraが販売された構成に属する部品と数量を決定します。結果は合意したDynamics 365製造プロセスへマッピングされます。
出力: 親製品 + 部品 + 数量 + 構成値
Mercuraが商談構成を作成し、構造化されたパラメータをCAD、PLM、またはエンジニアリングへ送信します。得られたエンジニアリング構造が下流で使用される製造定義となります。
出力: CPQパラメータ → エンジニアリング → 最終生産構造 → Dynamics 365
実装
連携は1つのワークストリームです。より大きな成果は、製品、価格、営業知識を自動化に十分なほど明確にすることから生まれます。
アーキテクチャを実証するのに十分な複雑さを持つ製品を選びます。顧客要件、オプション、依存関係、計算、価格、部品、期待されるDynamics出力を取得します。
成果物: 検証済みCPQパイロットモデル
必要なデータエンティティ、製品、顧客、価格入力、見積/受注オブジェクト、製造出力、拡張を特定します。
成果物: フィールドレベルの連携仕様
利用者(社内営業、エンジニア、販売店、顧客)を中心に体験を設計します。ルール、ビジュアライゼーション、ドキュメント、承認を追加します。
成果物: テスト可能なエンドツーエンド営業ワークフロー
Mercuraの結果を、期待されるDynamics 365トランザクションおよび製造構造と照合します。
成果物: 照合済み見積to受注プロセス
製品ファミリーごとに拡張し、製品と連携のガバナンスを明確に維持します。
成果物: 保守可能なCPQ展開
効果が出る場面
能力、寸法、材質、モーター、制御パッケージ、アクセサリを構成します。
購入シグナル: 営業が見積を検証するために定期的にエンジニアリングの支援を必要とする。
要件を機械、モジュール構造、オプション、生産入力へ変換します。
購入シグナル: 品目を選択する前に、受注ごとに複数の技術的判断が必要。
サイズ、材質、取付要件、仕上げ、設置オプションを計算します。
購入シグナル: 最終製品が単純なSKU選択ではなく、寸法と数式に依存する。
複数の製品を1つのエンジニアリング済み商談ソリューションへ構成します。
購入シグナル: 営業が個別品目ではなく、システム全体を販売している。
販売代理店に、製品知識、構成、価格設定への制御されたアクセスを提供します。
購入シグナル: 販売店の拡大により、社内エンジニアリングと営業チームへのサポート負荷が増加している。
エンジニアリングが最終的な技術作業を完了する前に、製品選択の反復可能な80%を自動化します。
購入シグナル: エンジニアが営業から同じ構成に関する質問に多大な時間を費やしている。
意思決定サポート
Dynamics 365 F&O CPQは、Microsoft Dynamics 365の財務・運用アプリと接続されたConfigure、Price、Quoteソリューションです。営業チームが顧客要件を有効な構成、価格、見積へ変換し、承認済みの結果をDynamics 365の受注および運用実行へ送信するのを支援します。
用語は時代とともに変化してきました。Dynamics 365 F&Oは、Dynamics 365の財務・運用プラットフォームおよびエコシステムを指す呼称として、いまも広く使われています。Microsoftは現在、Dynamics 365 FinanceとDynamics 365 Supply Chain Managementを別アプリケーションとして提供しています。一部の実装パートナーや顧客は、Finance + Supply Chain Managementの略称としてFSCMまたはF&SCMを使用します。CPQ購入者にとって、これらの用語はしばしば同じ連携ランドスケープを指します。
Dynamics 365 Supply Chain Managementにはあります。Microsoftは、事前定義バリアント、寸法ベースの構成、制約ベースの製品構成をサポートしています。制約ベースの製品構成モデルには属性、制約、計算、部品、BOM明細、工程オペレーションを含めることができ、販売見積および受注からの製品構成で利用できます。つまり、外部CPQがネイティブコンフィギュレーターを自動的に置き換えるべきではありません。ガイド付きセリング、顧客向け構成、ビジュアライゼーション、高度な商談ロジック、またはより充実した見積自動化も必要な場合、Mercuraは特に有効です。
Microsoft: 製品構成モデルの概要 →Dynamics 365コンフィギュレーターは、主にSupply Chain Management内で有効な製品および運用構造を定義するのを支援します。CPQはより広い営業課題をカバーします。顧客は何を必要としているか、何を販売できるか、いくらにすべきか、どのように提示すべきか、ERPは何を実行すべきか。企業はどちらか一方を単独で使うことも、両方を組み合わせることもできます。
場合によっては可能です。正しいアーキテクチャは、それらのモデルの構造と、営業プロセスへの参加方法によって異なります。まず、ネイティブDynamics構成を権威ある情報源として維持するのが最善か、Mercuraで営業構成をモデル化して出力をDynamicsへマッピングするか、両者の責務を分割するかを判断します。ビジネス上の理由なく、成熟したERP構成ロジックを再構築することは推奨しません。
はい、合意した連携に含まれる場合。Mercuraは承認済み構成を、参照、製品、数量、商談値、構成情報を含む関連するDynamics 365見積または受注プロセスへマッピングできます。正確なインターフェースは、利用可能なデータエンティティ、拡張、受注構造によって異なります。
はい。ただし、BOMを送信するということは、Dynamics 365では複数の意味を持ちます。実装では、販売された構成が既存バリアントの選択、既存製品構成モデルの起動、既存BOMの参照、構成固有の部品データの作成、または最終BOMが存在する前のエンジニアリングへの供給のいずれを行うべきかを確立する必要があります。すべての構成可能製品が新しいBOMを作成すべきであると仮定するのではなく、製造プロセスを中心に連携を設計します。
Dynamics 365に残すことも、Dynamics 365とMercuraで分割することも、Mercuraで計算することもできます。正しい選択は、価格が主にERP/顧客ベースか、構成ベースかによって異なります。
いいえ。Mercuraは社内営業アプリケーション、Dynamics連携ワークフロー、販売店ポータル、顧客ポータル、Webサイトコンフィギュレーター、カスタムアプリケーションを動かすことができます。同じ構成エンジンが異なるチャネルに対応し、Dynamics 365は運用バックエンドとして維持されます。
一般的なMicrosoft連携技術には、ODataとパブリックデータエンティティ、Data Management Framework、REST API、定期連携、カスタムサービスと拡張、Microsoft Entra ID認証が含まれます。正確なアーキテクチャは、データ量、レイテンシ要件、拡張、ビジネスプロセスによって異なります。
はい。より広いMicrosoftアーキテクチャでは、Dynamics 365 SalesがCRM活動と商談を担い、Mercuraが構成と見積を管理し、Finance & Supply Chain Managementが下流の受注、製造、財務プロセスを処理できます。
公式技術リソース
技術コンテンツ最終確認日: 2026年8月30日。お客様のDynamics 365エディション、リリース、拡張に照らして前提を検証してください。
お客様のプロセスで確認する
Dynamics 365 CPQを評価する最速の方法は、汎用的な機能チェックリストではありません。代表的な製品1つと実際の見積プロセスをお持ちください。顧客要件 → 構成 → 価格 → 見積 → Dynamics 365 → 製造をマッピングし、Finance & Supply Chain Managementに残すべき責務とMercuraが自動化できる責務をお示しします。
CPQデモのリクエスト