DWC INSIGHT 001 · DECISION GUIDE
CPQ-Systeme im Überblick
Welches System passt zu welcher Aufgabe?
CPQ Systems at a Glance – Matching Solutions to Industrial Requirements
CPQ ist kein einheitlicher Softwaremarkt. Hinter dem Begriff verbergen sich sehr unterschiedliche Lösungsansätze – von CRM-naher Angebotserstellung über industrielle Produktkonfiguration bis hin zu ERP-, PLM- und Engineering-orientierten Architekturen. Die entscheidende Frage lautet deshalb nicht: Welcher Anbieter hat die meisten Funktionen? Sondern: Welche Aufgaben soll das System im Zusammenspiel von Kundenbedarf, Produktlogik, Pricing, Angebot, Engineering, PLM und ERP übernehmen?
EXECUTIVE SUMMARY
Eine Marktkarte statt einer Rangliste.
Manche CPQ-Plattformen sind vor allem auf CRM-nahe Angebotsprozesse, Pricing, Freigaben und Dokumente ausgerichtet. Andere kommen aus der industriellen Produktkonfiguration und beherrschen komplexe technische Regeln. ERP-nahe Variantenkonfiguration konzentriert sich dagegen auf Auftrag, Material, Stückliste, Arbeitsplan, Costing und operative Ausführung. Hinzu kommen PLM-nahe Variantenführung, Configuration Lifecycle Management sowie Design- und Engineering-Automation.
Die Auswahl beginnt deshalb nicht mit einer Anbieterliste, sondern mit einer Aufgaben- und Rollenklärung. Portfolio, Produktstruktur, Produkt-Prozess-Klassen, Datenmodell, Anwender, priorisierte End-to-End-Use-Cases und Zielarchitektur sollten vor jeder Longlist definiert werden. Zu prüfen sind Zielgruppen und Kanäle, Produkt- und Regelkomplexität, Guided Selling, Pricing und Costing, Visualisierung, Dokumentengenerierung, benötigte Ergebnisobjekte sowie die Durchgängigkeit zwischen CRM, PIM, PLM, CPQ, CAD und ERP.
Dieser Beitrag ordnet den Markt. Die Auswahlmethodik und die organisatorische Vorbereitung werden in den Folgebeiträgen „CPQ-Systemauswahl ist kein Softwarevergleich“ und „CPQ-Readiness“ vertieft.
1. Warum eine CPQ-Systemübersicht schnell irreführt
Produktkonfiguratoren gibt es viele. Unter ähnlichen Begriffen werden jedoch Lösungen angeboten, deren fachlicher Schwerpunkt, technischer Ansatz und geeigneter Einsatzbereich stark voneinander abweichen. Guided Selling, Angebots- und Produktkonfiguration, Pricing, Dokumentengenerierung, Visualisierung, Stücklisten- und Arbeitsplankonfiguration sowie CAD- und Engineering-Automation sind nicht dieselbe Aufgabe.
Die Marktübersicht „Marktführer CPQ“ aus dem Jahr 2017 hat diese Heterogenität bereits sichtbar gemacht. Ihre Anbieterprofile sind heute jedoch nur noch als historische Fachquelle und nicht als aktueller Marktstatus zu verwenden.
Eine Vergleichstabelle mit Häkchen erzeugt deshalb schnell Scheinsicherheit. Fast jedes etablierte System kann zentrale CPQ-Funktionen grundsätzlich abdecken. Entscheidend sind Tiefe, Modellierungsansatz, Pflegeaufwand, Performance, Systemgrenzen, Integrationslogik und die Frage, welche Ergebnisobjekte zuverlässig erzeugt werden müssen.
Ein System kann hervorragend für globale Vertriebsprozesse und Preisfreigaben geeignet sein – und dennoch bei tiefen technischen Stücklisten oder Engineering-Ergebnissen an Grenzen stoßen.
2. Was CPQ im industriellen Kontext abdecken kann
CPQ steht für Configure, Price und Quote. Im industriellen Umfeld beginnt die relevante Prozesskette häufig früher und endet später: Kunden- oder Anwendungsbedarf erfassen, Produktfamilie auswählen, Lösung führen, technisch konfigurieren, Preise und Kosten ermitteln, Freigaben steuern, Angebot und technische Dokumente erzeugen und die Konfiguration in Auftrag, Stückliste, Arbeitsplan oder Engineering überführen.
Eine moderne CPQ-Landschaft kann Guided Selling, Defaults und Vorzugsausprägungen, Produktselektion, technische Plausibilisierung, Regelwerk und Berechnung umfassen. Hinzu kommen Pricing, Costing, Discounting und Margenprüfung, Visualisierung, Dokumentengenerierung, Angebots- und Projektverwaltung, Workflows sowie Übergaben an CRM, PIM, PLM, CAD und ERP.
MARKTKARTE
3. Die wichtigsten Systemklassen
01
Vertriebszentrierte CPQ-Suiten
Guided Selling, Pricing, Rabatt- und Freigabelogiken, Quote Management, Dokumente sowie CRM- und Revenue-Prozesse.
02
Industrielle CPQ- und Produktkonfiguration
Komplexe technische Regeln, Variantenprodukte, Herstellbarkeit, Ergebnisobjekte sowie häufig Visualisierung und Dokumente.
03
ERP-nahe Variantenkonfiguration
Auftragskonfiguration, Material, BOM, Arbeitsplan, Herstellkosten, Kalkulation und operative Ausführung.
04
Configuration Lifecycle Management
Konsistenz von Konfigurationslogik und gültigen Varianten über Entwicklung, Vertrieb, Fertigung und Service.
05
PLM-nahe Variantenführung
Optionen, Choices, eBOM, Gültigkeiten und Engineering-Änderungen in unmittelbarer Nähe zur Produktdefinition.
06
Design- und Engineering-Automation
Automatisierte CAD-/ECAD-Modelle, Zeichnungen, Berechnungen und wiederkehrende CTO+- oder ETO-Ergebnisse.
07
Visuelle und raumbezogene Konfiguration
In Möbel-, Innenausbau-, Raumplanungs- und Layoutanwendungen kann 2D-/3D-Konfiguration die führende Benutzeroberfläche sein. Entscheidend ist die Durchgängigkeit zu technischen Regeln, Pricing, Dokumenten, Fertigung und ERP.
EINORDNUNG
Was dieser Beitrag bewusst nicht leistet
- keine Rangliste einzelner Anbieter
- keine pauschale Empfehlung eines Marktführers
- kein Featurevergleich mit möglichst vielen Häkchen
- keine Shortlist ohne Bezug zu Produkt, Prozess, Daten und Architektur
Ziel dieses Beitrags ist die fachliche Einordnung unterschiedlicher Lösungsansätze. Eine belastbare Systemauswahl entsteht erst aus dem konkreten Zielbild eines Unternehmens, seinen priorisierten Use Cases sowie seiner Produkt-, Daten- und Systemarchitektur.
4. Nach welchen Kriterien die Marktübersicht gefiltert werden sollte
- Zielgruppen und Kanäle: Web-Self-Service, Partner, Außen- und Innendienst sowie Engineering.
- Produkt-Prozess-Klassen: PTO, ATO, MTO, CTO, CTO+ und ETO.
- Produkt- und Regelkomplexität: Abhängigkeiten, Berechnungen, Variantenraum, Änderungsrate und Wiederverwendung.
- Guided Selling: Kundenbedarf, Anwendungssicht, Defaults, Vorzugsausprägungen und gezielte Empfehlungslogik.
- Pricing und Costing: Preis- und Kostenlogik, Margen, Kalkulationsschemata und Freigaben.
- Visualisierung: 2D, 3D, Rendering, Layout und interaktive Darstellung.
- Dokumentengenerierung: Angebote, Datenblätter, Protokolle, Zeichnungen und technische Beschreibungen.
- Ergebnisobjekte: Konfiguration, Auftrag, 100%-BOM, Arbeitsplan, CAD-Modell oder Berechnung.
- Architektur und Datenhoheit: Rollen von CRM, PIM, PLM, CPQ, CAD und ERP.
- Betrieb und Governance: Modellpflege, Tests, Releases, Versionen, Rollen und interne Kompetenz.
5. Kompakte Anbieter- und Lösungsorientierung
Die folgenden Beispiele dienen der Orientierung und stellen weder ein Ranking noch eine vollständige Marktübersicht dar. Produktnamen und Portfolios verändern sich; vor einer Auswahl ist der aktuelle Stand zu verifizieren.
| Schwerpunkt | Repräsentative Beispiele | Typische Prüffrage |
|---|---|---|
| CRM-/Revenue-nahe CPQ | SAP CPQ, Oracle CPQ, Salesforce Agentforce Revenue Management, Conga CPQ | Reicht die technische Konfiguration – und wie erfolgt die Übergabe an PLM und ERP? |
| Industrielle CPQ / Produktkonfiguration | Tacton, encoway, camos, CAS Merlin, ORISA, SAE | Wie gut passen Regelwerk, Produkt-Prozess-Klassen, Ergebnisobjekte und Modellpflege? |
| ERP-nahe Konfiguration | SAP Advanced Variant Configuration (SAP AVC) in SAP S/4HANA; klassisch SAP LO-VC; Proalpha Produktkonfigurator; IFS Cloud Configure to Order (CTO) mit Sales Configurator; Infor LN Product Configuration (PCF); Product configuration in Microsoft Dynamics 365 Supply Chain Management | Soll ERP die führende Konfigurationslogik tragen, und wie werden Vertriebs-UX, Guided Selling, Pricing sowie die Übergabe in Stückliste, Arbeitsplan und Auftrag ergänzt? |
| CLM / Variantenraum | Configit sowie vergleichbare Plattformansätze | Wird Konsistenz geschaffen oder ein weiteres Produktmodell eingeführt? |
| PLM-nahe Variantenführung | Teamcenter Product Configurator, Windchill Options & Variants, ENOVIA, Aras | Welche technische Wahrheit wird im PLM geführt und welche Verkaufssicht benötigt CPQ? |
| Design Automation | Siemens Rulestream, DriveWorks und CAD-nahe Automation | Welche wiederkehrenden CTO+- und ETO-Ergebnisse lassen sich stabil automatisieren? |
| Visuelle Konfiguration | Configura, EasternGraphics, Combeenation und ähnliche Lösungen | Steht visuelle Planung im Zentrum – und wie werden technische Logik, Preis und Fertigung gekoppelt? |
6. Fünf typische Fehlinterpretationen
- „Alle Systeme können CPQ.“ Funktionsbezeichnungen sind ähnlich, fachliche Tiefe, Modellierungslogik und Pflegeaufwand jedoch nicht.
- „Die meisten Häkchen gewinnen.“ Eine lange Funktionsliste sagt wenig über konkrete Produkte, Rollen, Daten und Systemgrenzen aus.
- „Ein Modell für alle Bereiche ist immer besser.“ Sales, Engineering und Manufacturing benötigen häufig unterschiedliche Sichten und kontrollierte Ableitungen.
- „Der vorhandene ERP- oder CRM-Anbieter ist automatisch die sicherste Wahl.“ Suite-Nähe ersetzt nicht die fachliche Prüfung.
- „Ein Proof of Concept kompensiert fehlende Vorbereitung.“ Ohne priorisierte Use Cases, Testdaten, Grenzfälle und Zielarchitektur demonstriert ein PoC vor allem Präsentationsqualität.
7. Von der Marktkarte zur belastbaren Auswahl
- Ziele, Nutzen und Scope der CPQ-Initiative festlegen.
- Nutzergruppen, Kanäle und priorisierte End-to-End-Use-Cases beschreiben.
- Portfolio und Produkt-Prozess-Klassen segmentieren.
- Produkt-, Daten- und Regelmodell sowie benötigte Ergebnisobjekte definieren.
- Pricing, Costing, Visualisierung und Dokumentengenerierung fachlich klären.
- Systemrollen, Datenhoheit und Integrationen zwischen CRM, PIM, PLM, CPQ, CAD und ERP festlegen.
- Erst danach Longlist und Shortlist bilden, Szenario-Demos durchführen und mit PoC beziehungsweise Pilot validieren.
Fazit
Es gibt nicht das beste CPQ-System. Es gibt Lösungen, deren fachlicher Schwerpunkt, Technologie und Architektur besser oder schlechter zu einer konkreten Unternehmenssituation passen.
Für Industrieunternehmen sollte nicht der Anbietername am Anfang stehen, sondern die Frage: Welche Produkt- und Verkaufslogik soll durch welche Systemrolle geführt, ausgeführt und übergeben werden? Erst wenn Kundenbedarf, Produkt-Prozess-Klasse, Datenmodell, Pricing und Costing, Ergebnisobjekte und Systemarchitektur geklärt sind, wird aus einer heterogenen Anbieterliste eine fundierte Auswahl.
Die eigentliche Herausforderung einer CPQ-Initiative liegt deshalb selten in der Software selbst. Entscheidend sind Zielbild, Produktmodell, Datenmodell und Architektur. Erst auf dieser Grundlage werden Longlist, Shortlist, Proof of Concept und Pilot belastbar.
ENGLISH EXECUTIVE SUMMARY
CPQ Systems at a Glance
The CPQ market cannot be understood as a single linear ranking. Solutions marketed under the CPQ or product configurator label differ substantially in their primary role, modeling approach, technical depth, lifecycle coverage, and integration architecture.
Sales-centric CPQ suites typically focus on guided selling, commercial configuration, pricing, approvals, quote management, proposal documents, and CRM-driven processes. Industrial CPQ and product configuration platforms are often stronger in complex technical rules, manufacturability, and industrial product models. ERP-based variant configuration supports order processing, materials, bills of materials, routings, costing, and manufacturing execution. Other relevant classes include Configuration Lifecycle Management, PLM-based variant management, visual configuration, and design or engineering automation.
A useful market overview therefore starts with system roles rather than vendor names. Companies should clarify users and channels, product-process classes, product and rule complexity, guided selling, defaults and preferred options, pricing and costing, visualization, document generation, required output objects, and the division of responsibilities between CRM, PIM, PLM, CPQ, CAD, and ERP.
The vendor examples in this guide are illustrative and do not constitute a ranking. The right shortlist can only be created after a clear target picture, prioritized end-to-end use cases, and a defined product and data architecture.
Weiterführende Insights
Als Nächstes: CPQ-Systemauswahl ist kein Softwarevergleich – warum Zielbild, Use Cases, Produktmodell und Architektur wichtiger sind als Featurelisten.
Danach: CPQ-Readiness – warum Portfolio, Produktlogik, Daten, Pricing, Visualisierung, Dokumente und Governance vor der Softwareauswahl geklärt werden müssen.
In Vorbereitung: Architektur- und Vendor-Lock-in vermeiden – Methoden, Produktmodelle und Werkzeuge richtig einsetzen.
In Vorbereitung: Das Produktmodell ist wichtiger als das CPQ-System.
Quellen und Einordnung
DWC Knowledge Base: konsolidierte Projekterfahrungen, eigene Marktanalysen sowie fachliche Inhalte aus der früheren CPQ-Select-Wissensbasis. Ergänzend wurden aktuelle öffentliche Herstellerinformationen zu SAP CPQ, SAP Advanced Variant Configuration, Tacton, Configit, Oracle CPQ, Salesforce Agentforce Revenue Management, Conga CPQ, Proalpha Produktkonfigurator, IFS Cloud Configure to Order, Infor LN Product Configuration und Microsoft Dynamics 365 Supply Chain Management herangezogen. Die historische Marktübersicht „Marktführer CPQ 2017“ dient ausschließlich der fachlichen Einordnung. Die genannten Anbieterbeispiele sind neutral, nicht vollständig und vor einer konkreten Auswahlentscheidung auf ihren aktuellen Produktstand zu prüfen.