1. IFS Cloud Configure-to-OrderとSales Configurator
IFS Cloudには、Configure-to-Order製造向けの長年の製品構成機能があります。構成可能な部品は、特性とオプションを持つ構成ファミリーに整理されます。ルールが有効な組み合わせをガイドし、構成は販売見積、顧客受注、製造指図、Dynamic Order Processing、その他の製造プロセスで使用できます。
Mercura CPQ + IFS Cloud
複雑な製品を構成し、適正価格を算出し、受注可能な構成を作成しながら、IFS CloudをERPと製造の基幹システムとして維持します。
IFS Cloudには強力なConfigure-to-Order機能があり、IFSは専用のIFS CPQ製品も提供しています。Mercuraは別のアーキテクチャです。ERP、製造、原価計算、受注実行にIFSを使いながら、営業、CRM、販売店、顧客、デジタルチャネル全体で専用の構成体験を提供したい製造業者向けに、IFS Cloudと連携する独立型のCPQ基盤を提供します。
販売見積
IFS CPQとは
IFS CPQを理解するうえで、まず押さえておきたい3つのポイントがあります。「IFS CPQ」という言葉は、複数の関連機能やアーキテクチャを指して使われることがあります。
IFS Cloudには、Configure-to-Order製造向けの長年の製品構成機能があります。構成可能な部品は、特性とオプションを持つ構成ファミリーに整理されます。ルールが有効な組み合わせをガイドし、構成は販売見積、顧客受注、製造指図、Dynamic Order Processing、その他の製造プロセスで使用できます。
IFSはIFS CPQという専用製品も提供しています。IFSは複雑な製造販売向けの組み込みCPQ体験として位置づけ、ガイド付きセリング、動的価格設定、多階層・システムレベル構成、価格ガバナンス、販売店・リセラー体験、顧客向けWeb構成などの機能を追加します。
IFS CloudをERP・製造基盤として維持しつつ、Mercuraなどの別CPQシステムで製品構成、価格設定、可視化、デジタル販売体験を提供することもできます。このアーキテクチャは、IFS外のシステムやチャネル全体で構成が機能する必要がある場合に特に有効です。
確定したIFS CPQ構成は、適切な販売部品、数量、IFS CTO Configuration IDを持つ対応するIFSソース明細を作成できます。
既存のコンフィギュレータ
はい。これは重要です。
信頼できるCPQ評価は、IFSに製品構成がないという前提から始めるべきではありません。IFS Cloudの既存のSales ConfiguratorとConfigure-to-Order機能は、特性とオプションを通じてユーザーをガイドし、構成ルールを適用し、構成依存の価格設定を計算し、結果の構成を下流の製造プロセスに接続できます。
IFSはその後、より広範なCPQ販売体験のために独立したIFS CPQを追加しました。
本質的な問いではない
IFSは製品を構成できるか?
それだけでは十分ではない
IFSにCPQはあるか?
重要なのはこちら
自社の製品、ユーザー、販売チャネル、IFS環境に適した構成アーキテクチャはどれか?
アーキテクチャの選択
正しい答えは解決する課題によって異なります。
IFSに属する製造・運用知識はIFSを使う。実際に製品を構成・購入する人々に最適なCPQアーキテクチャを選ぶ。
三者比較
| 機能 | IFS Cloud CTO / Sales Configurator | IFS CPQ | Mercura + IFS Cloud |
|---|---|---|---|
| IFS ERPと製造 | ネイティブ | ネイティブ連携 | IFSが責任を維持 |
| 構成可能な部品 | あり | IFS CTO連携を使用 | IFS構成部品にマッピング可能 |
| 特性とオプション | あり | あり | あり |
| 構成ルール | あり | あり | あり |
| ガイド付きセリング | あり(構成指向) | あり | あり |
| 構成価格設定 | あり | あり | あり |
| 動的価格ガバナンス | IFS価格機能 | あり | あり |
| 販売見積連携 | ネイティブ | ネイティブ連携 | API連携 |
| 顧客受注連携 | ネイティブ | ネイティブ連携 | API連携 |
| IFS CTO Configuration ID | ネイティブ | 連携経由で作成 | 必要に応じてマッピング可能 |
| BOM / ルーティング評価 | IFSネイティブ責任 | IFS CTOに接続 | IFSが製造マスターを維持可能 |
| 多階層構成 | 製造構造 | あり | あり |
| システムレベル販売 | モデルによる | あり | あり |
| 販売店 / リセラー体験 | IFS B2Bの可能性 | あり | あり |
| 顧客Webコンフィギュレータ | 選択したIFSアーキテクチャが必要 | あり | あり |
| カスタムフロントエンド / SDKアプローチ | コア目的ではない | IFS CPQアーキテクチャ | Mercuraのコアアーキテクチャ |
| CRMファーストワークフロー | 連携が必要 | 環境による | コア連携パターン |
| マルチERP / ERP非依存CPQ | なし | IFS指向 | あり |
| インタラクティブ2D / 3D | 実装による | 対応;3Dアセットは顧客責任 | Mercuraのコア機能 |
| 最適な用途 | 製造中心のCTO | IFS中心のエンドツーエンドCPQ | IFSを中心としたマルチチャネルCPQ |
組み込みCPQアーキテクチャ
この区別はアーキテクチャチームにとって有用です。
IFSは商務面でIFS CPQをIFS Cloud内に組み込まれ、IFS Cloud Manufacturingとネイティブに統合されていると説明しています。
IFS自身の技術ドキュメントが、その仕組みを説明しています。CPQソリューションは外部アプリケーションとしてプロビジョニングされ、以下を使用してIFS Cloudに接続されます:
CPQアプリケーションはERPアプリケーション内で実行されなくても、IFS Cloudと深く統合できます。
Mercuraも同じ関心の分離の原則に従います。IFSはERPと製造実行を引き続き所有し、CPQはサポートされた連携インターフェースを通じてIFSと構造化情報を交換します。
違いは、どのCPQプラットフォームを使うかです。
IFS Cloudが担うべき領域
IFS製造業者にとって、目標はCPQ内でIFSを再構築することではありません。IFSは製造実行において非常に強力です。実装によっては、IFSが以下について権威を維持する場合があります:
Mercuraは、販売構成プロセスが実際に必要とする情報を消費または参照すべきです。
CPQが担うべき領域
CPQレイヤーは主に、要件をIFSが実行できるものに変換することに関心があります。Mercuraは以下を処理できます:
顧客要件を技術的に意味のある選択肢に変換します。
ユーザーが構成する間、依存関係、制約、計算を適用します。
ユーザーが構築しているものを表示します。
構造化構成から商務・技術文書を生成します。
IFSにおけるConfigure-to-Order
IFSのCTO機能は単純なERP品目参照以上の深さがあります。
構成可能な部品は構成ファミリーに接続されます。ファミリーは有効なバリアントを記述する共通の特性とオプションを定義します。IFS Sales Configuratorはユーザーが選択肢を進めるようガイドします。
ルールは以下が可能です:
使用先:
IFSは構成リビジョン管理と同一の既存構成の再利用もサポートしています。
つまり、IFS連携は価値がある場所で既存のCTOモデルを再利用すべきであり、盲目的に置き換えるべきではありません。

ERPと製造
構成 · 価格 · 見積

受注・業務処理
販売チャネル
社内ERPユーザーは可能な対象の1つにすぎません。複雑な製品は、CRMユーザー、フィールドセールス、流通業者、販売店、リセラー、パートナー、エンジニア、顧客、eコマースユーザーによっても販売される場合があります。専用CPQレイヤーにより、一元管理された同じ製品知識を、用途に応じたさまざまな販売チャネルやユーザー体験で活用できます。
商談または販売プロセスから構成を起動します。営業は完全な下流製造構造を理解せずにガイダンスを受けられます。
外部販売チャネルに、関連製品、有効な構成ルール、顧客固有の品揃え、商務ロジック、見積生成への制御されたアクセスを提供し、完全なERPインターフェースを公開しません。IFS CPQ自体も販売店・リセラーポータル機能を提供しているため、組織は外部CPQが自動的に必要であると想定するのではなく、必要な体験を比較すべきです。
Webサイトまたはポータルを通じて顧客が直接製品を構成できるようにします。IFS CPQには顧客向けWebコンフィギュレータ機能が含まれています。Mercuraは、その体験を主にIFS中心のソリューションではなく、より広いヘッドレスまたはカスタムデジタルアーキテクチャの一部にしたい場合に適しています。
多くの製造業者はERPと製造にIFSを使い、CRMには別のプラットフォームを使います。典型的なアーキテクチャはCRM → Mercura CPQ → IFS Cloudです。これにより、製造がそこで実行されているからといって営業担当者をERPに強制する必要がなくなります。
これは、IFS CPQと並んで専門CPQを評価する最も強力な理由の1つです。一部の組織は以下を運用しています:
製品構成はIFS機能として外向きに公開されるべきか、それともIFSと残りのスタックに接続された独立した製品知識レイヤーであるべきか?
普遍的に正しい答えはありません。それはアーキテクチャの決定です。
ビジュアルCPQ
複雑な産業製品は、特性とERPフィールドだけでは販売が困難な場合が多いです。Mercuraは構成ロジックとビジュアルフィードバックを組み合わせられます。
IFS CPQもビジュアル構成シナリオをサポートしています。IFSの製品条件では、IFS CPQに必要な3Dモデルは顧客の責任であることが明記されています。
同じ構造化構成を使ってブランド化された提案書を作成し、承認済み結果をIFS Cloudにマッピングします。
Mercuraが適する場合
Mercuraは、CPQ課題がERP構成を超える場合に特に関連します。
コンフィギュレータはCRMまたは別の営業ワークスペースから起動すべきです。
ERP指向のインターフェースではなく、ブランド体験が必要です。
製品コンフィギュレータ自体がデジタル販売製品です。
1つのCPQモデルが複数のERP、CRM、事業部門に対応する必要があります。
顧客は構成しながら結果を見る必要があります。
販売ロジックはERPマスターデータとは異なるペースで変更されます。
構成はAPIとカスタムアプリケーションを通じて消費される必要があります。
CPQレイヤーはIFS、CRM、PIM、CAD、その他のシステム全体で製品知識を編成する必要があります。
IFS CPQが適する場合
IFS Cloudが明らかに販売・製造アーキテクチャの中心であり、IFSエコシステム内で提供されるCPQソリューションが必要な場合、IFS CPQは真剣に検討に値します。
Mercuraは単に別のアプリケーションを追加するために追加すべきではありません。
Sales Configuratorで十分な場合
すべてのIFS顧客が専用CPQ製品を必要とするわけではありません。
これはしばしば最初に答えるべきアーキテクチャの問いです。
製造への引き渡し
ここがIFSが特に強力な領域です。販売コンフィギュレータは、製造が実行できない見栄えの良い見積を作成すべきではありません。連携は、承認された商務構成が正しいIFS製造入力になる方法を決定すべきです。
Mercuraは顧客要件に対応する既存の販売部品を決定します。結果の部品と数量が関連するIFS販売プロセスに転送されます。
最適な場合: 有効なバリアントの有限カタログを製造または在庫している場合。
Mercuraは必要な選択を取得し、対応するIFS構成特性とオプションにマッピングします。IFSは正式なCTO構成とその下流の製造評価について引き続き責任を負います。
最適な場合: 既存のIFS CTOセットアップに保持したい製造ロジックがすでに含まれている場合。
1つの高レベル構成が複数の販売部品と数量を生む場合があります。IFSは製造構成ルール、製品構造、ルーティング、DOP、その他の下流プロセスを使用して、受注の履行方法を決定できます。
最適な場合: CPQが販売ソリューションを所有し、IFSが製造定義を所有する場合。
IFSは構成ルールを評価して製造構造を作成できます。構成済み製品は製品構造とルーティングロジックに供給でき、IFSは構成評価に基づくDOP構造の作成をサポートしています。
最適な場合: 顧客の選択が部品と製造工程を直接決定する場合。
すべてのETO製品を完全に自動化できるわけではありません。Mercuraは繰り返し可能な部分を標準化し、エンジニアリングが必要とするパラメータを生成できます。エンジニアリングが製品を確定した後、承認されたBOM、プロジェクト構造、または製造定義がIFSに入ります。
最適な場合: すべての受注に本格的なエンジニアリング作業が含まれるが、販売は構成の相当部分を自動化できる場合。
正しいアーキテクチャは製造プロセスによって異なります。すべての製造業者が同じ方法でBOMを生成すべきだとは想定していません。
中間受注
IFSは構成、原価計算、エンジニアリングの間の興味深い橋渡しを提供します。販売見積または顧客受注上の構成済み製品は、中間受注に展開できます。
複雑な製造業者にとって、これは強力なアーキテクチャを形成します:
詳細な製造原価計算をCPQプラットフォームに移すよりも、これが望ましい場合があります。
価格設定の責任
IFSにはすでに相当な価格設定機能があります。不必要に重複させないでください。
構成可能な販売部品について、IFSは未構成販売部品の基本価格、構成特性の経済的価値、オプションの経済的価値を使用して価格を計算できます。
Mercuraは製品を構成し、IFSから関連する価格を要求または消費します。
最適な場合
IFSにすでに商務価格ロジックが含まれ、顧客価格がERPに属し、販売価格ガバナンスがERP管理であり、構成に大幅な追加CPQ価格設定が不要な場合。
例:IFS販売部品価格 + 選択寸法 + 素材係数 + 性能パッケージ + 付属品 + プロジェクト固有の追加 = 構成販売価格。
最適な場合
ERPが標準商務データを所有するが、最終販売価格が構成コンテキストにのみ存在する計算に依存する場合。
Mercuraは完全な構成計算を実行し、結果の商務価値を合意されたIFS取引プロセスに送信します。
最適な場合
価格設定が高度に専門化された構成モデルと不可分な場合。
IFS CPQ自体を選択する場合、IFSは動的価格設定、シナリオモデリング、承認ワークフロー、マージン保護制御をコア機能として訴求しています。そのアーキテクチャでは、別のCPQ価格レイヤーを導入する理由はほとんどありません。
最適な場合
IFSエコシステム内で提供される1つの管理されたCPQ価格レイヤーが必要な場合。
最も重要な価格決定は、どのシステムが最も強力な価格エンジンを持つかではありません。
各価格ルールをどのシステムが所有すべきか?顧客契約、価格表、ERP商務ロジックはIFSに属する場合があります。構成数式はCPQに属する場合があります。製造原価はIFS原価計算と製造に近い場所に属します。承認ロジックは1つの管理された拠点を持つべきです。
優れたIFS CPQアーキテクチャは重複ルールを最小化します。
IFS Cloud連携
RESTとOData
IFS CloudはODataベースのREST APIを通じてビジネス機能を公開しています。IFSはREST APIを推奨連携方法とし、連携に再利用できるIFS Cloud Projectionsを公開しています。APIによってはGET、POST、PUT、PATCH、DELETEなどの標準HTTP操作がサポートされています。
システム間連携について、IFSはOAuth 2.0 client credentialsフローを推奨しています。外部アプリケーションはIFS IAMクライアントを使用してアクセストークンを取得し、関連API呼び出し時にそのトークンを使用します。
外部構成
はい。
IFSドキュメントは、構成が外部アプリケーションによって開始できることを明示しています。IFS自身の最新CPQ連携もこのアーキテクチャパターンを示しています。
Mercura実装では、すべての顧客が同じマッピングを必要とすると想定するのではなく、結果の構成を所有すべきIFSサポートビジネスフローを最初に決定します。
データ交換
典型的な設計には以下が含まれる場合があります:
| データ | 方向 | 目的 |
|---|---|---|
| 販売部品 | IFS → Mercura | ERP製品マスターの再利用 |
| 部品情報 | IFS → Mercura | 技術/製品コンテキスト |
| 顧客 | IFS → Mercura | 顧客固有の見積 |
| 会社 | IFS → Mercura | 組織コンテキスト |
| サイト | IFS → Mercura | 製造/商務コンテキスト |
| 単位 | IFS → Mercura | 一貫した数量 |
| 価格情報 | IFS → Mercura | ERP価格入力 |
| 在庫 / 可用性 | IFS → Mercura | 関連する場合の販売可用性 |
| 構成特性 | IFS → Mercura | 既存CTOモデルの再利用 |
| 構成オプション | IFS → Mercura | 許可されたIFS値の再利用 |
| 原価情報 | IFS → Mercura | 商務上適切な場合 |
| 構成 | Mercura → IFS | 承認済み製品定義 |
| 販売部品 | Mercura → IFS | 構成済み商務明細 |
| 数量 | Mercura → IFS | 受注数量 |
| 構成参照 | Mercura → IFS | CPQへのトレーサビリティ |
| 販売見積データ | Mercura → IFS | 見積フローの継続 |
| 顧客受注データ | Mercura → IFS | 受注プロセスの継続 |
| 技術パラメータ | Mercura → IFS | 下流製造コンテキスト |
| 部品データ | Mercura → IFS | 合意されたアーキテクチャで必要な場合 |
環境の評価
IFS実装は大きく異なります。連携を定義する前に、以下を確認します:
結果は、汎用コネクタ図ではなく、実際のIFS環境に基づく連携設計であるべきです。
意思決定支援
IFS CPQは、複雑な構成可能製品を販売する製造業者向けのIFSのConfigure、Price、Quoteオファリングです。IFSは、ガイド付きセリング、構成、動的価格設定、承認、多階層・システムレベル構成、販売店/リセラーサポート、顧客向けWeb構成を備えた組み込みIFS Cloud体験として位置づけています。
はい。IFS Cloudには、構成可能な部品、構成ファミリー、特性、オプション、構成ルールに基づく長年のConfigure-to-OrderとSales Configurator機能が含まれています。IFS CPQは、これらの製造機能を中心に構築・統合されたより広範なCPQオファリングです。
IFS Sales Configuratorは基盤となるIFS Configure-to-Order機能の一部であり、構成可能部品の有効な構成を作成することに焦点を当てています。IFS CPQはより広範な販売レイヤー製品です。ガイド付きセリング、動的価格ガバナンス、システムレベル構成、外部販売体験などの機能を備えた専用CPQ体験を追加し、結果をIFSビジネスオブジェクトとCTOに統合します。
商務面では、IFSはIFS CPQを組み込まれ、IFS Cloudとネイティブに統合されていると説明しています。技術面では、IFSドキュメントはCPQソリューションをREST呼び出し、IFS Connect、SSO、Webhooks、専用連携ユーザーを使用してIFS Cloudと統合される外部アプリケーションとして説明しています。これにより、別のCPQサービスアーキテクチャを維持しながら、ユーザーには組み込み体験を提供します。
はい。MercuraはIFS CPQの代わりに、IFS Cloudと並んで独立したCPQレイヤーとして使用できます。より良いアーキテクチャは、既存のIFS CTOモデル、販売チャネル、CRM戦略、フロントエンド要件、システム環境、CPQをIFSエコシステムにどれだけ密接に結合したいかによって異なります。
いいえ。IFSはERP、製造、運用プロセスを引き続き所有すべきです。Mercuraは販売構成体験を処理し、承認済み結果を合意されたIFSプロセスに渡します。
はい、連携は既存のIFS CTOアーキテクチャを保持するよう設計できます。例えば、Mercuraが構成選択を決定または収集し、IFSが正式な構成部品、Configuration ID、下流の製造評価について引き続き責任を負う場合があります。正確なモデルは顧客のCTOセットアップによって異なります。
IFSドキュメントは、構成が外部アプリケーションによって開始できることを明示的に許可しています。適切な連携は、サポートされたIFS APIを使用し、顧客のIFSプロセスで必要とされるビジネス検証を保持すべきです。
IFS CloudはODataとProjectionsを使用してREST APIを公開しています。IFSはREST APIが推奨連携アプローチであると述べています。連携は、ビジネスプロセスに応じてPremium APIs、Integration APIs、標準Projections、IFS Connect、その他のサポートされたインターフェースを使用する場合があります。
IFS Cloud REST APIドキュメント →IFSはシステム間連携にOAuth 2.0 client credentialsを推奨しています。最終的な認証セットアップは、インタラクションパターンとIFS環境によって異なります。
IFS OAuthドキュメント →IFS、Mercura、または制御されたハイブリッドアーキテクチャに置くことができます。IFSは基本価格、特性・オプション価格、数式、組み合わせテーブルを使用した高度な構成価格設定をすでにサポートしています。明確な理由がない限り、CPQでそのロジックを再作成しないでください。
IFS CTOは構成を評価して下流の製造構造を決定できます。構成駆動のDOP構造と工程を含みます。Mercuraは販売構成を提供でき、IFSは製造ロジックの評価と実行を引き続き行います。
はい。IFSは販売見積および顧客受注明細行の中間受注をサポートしています。これらは検査と推定原価集計のために展開でき、原価再計算前に軽微なエンジニアリング変更を実施できます。複雑または部分的にエンジニアリングされた製品に特に有用です。
はい。IFS CPQとMercuraの両方が外部販売体験をサポートできます。IFS CPQは販売店/リセラーポータルと顧客向けWebコンフィギュレータ機能を訴求しています。Mercuraは、それらの体験をより広いカスタムまたはマルチシステムアーキテクチャに組み込む必要がある場合に特に関連します。
はい。一般的なアーキテクチャはCRM → Mercura CPQ → IFS Cloudです。CRMが商談を所有し、Mercuraが販売構成体験を所有し、IFSが運用実行を所有します。
このページは主にIFS Cloudに焦点を当てています。旧来のIFS Applications環境は異なる連携技術を使用するため、アーキテクチャを定義する前に個別に評価すべきです。
公式技術リソース
技術コンテンツは2026年8月に最終確認。IFS Cloudのリリース、有効なモジュール、連携環境に照らして前提を検証してください。
IFSが運用を担う。販売に最適なCPQアーキテクチャを選ぶ。
すでにIFSを使用している場合、最初の問いは別のソフトウェアが必要かどうかではありません。構成知識がどこに存在すべきかです。一部の組織には既存のIFS Sales Configuratorで十分です。他の組織には新しいIFS CPQ製品がIFS Cloudの最も自然な拡張です。CRM、ERP、販売店、顧客、カスタムデジタル体験全体に1つの柔軟な構成レイヤーが必要な製造業者には、IFSが製造・運用の基盤として残る中、MercuraがCPQレイヤーを提供できます。構成可能な製品、見積例、現在のIFS CTOセットアップの概要をお持ちください。製品ルール、価格設定、原価計算、製造ロジックがどこに存在すべきか、Mercura、IFS CPQ、既存IFSコンフィギュレータのどれが最適かを整理します。