DWC INSIGHT 201 · DECISION GUIDE
CPQ-Systeme im Überblick
Welches System passt zu welcher Aufgabe?
CPQ ist kein einheitlicher Softwaremarkt. Sieben Systemklassen lösen unterschiedliche Aufgaben zwischen Vertrieb, Produktlogik, Auftrag, Lifecycle, Produktdefinition, Engineering und Visualisierung. Eine belastbare Orientierung beginnt deshalb bei Systemrolle und Kernobjekt – nicht beim Anbieterlogo.
EXECUTIVE SUMMARY
Eine Marktkarte statt einer Rangliste.
Unter dem Label CPQ werden Lösungen mit sehr unterschiedlicher Herkunft angeboten. Vertriebszentrierte Suiten führen Angebote, Pricing und Freigaben. Industrielle Produktkonfiguratoren beherrschen Regeln und valide Lösungen. ERP-nahe Variantenkonfiguration führt Material, Auftrag und operative Ableitung. Configuration Lifecycle Management und PLM-nahe Variantenführung sichern Konsistenz und Produktdefinition. Design- und Engineering-Automation erzeugt technische Ergebnisse; visuelle und raumbezogene Konfiguration macht Planung und Auswahl zum führenden Bedienkonzept.
Configuration Lifecycle Management und PLM-nahe Variantenführung bleiben als angrenzende Systemwelten gekennzeichnet. Sie werden dennoch als Systemklassen 04 und 05 mitgeführt, weil sie dieselben End-to-End-Prozesse und die Zielarchitektur wesentlich prägen.
Die Auswahl beginnt deshalb mit Aufgabe, Kernobjekt, benötigtem Ergebnis und führender Systemrolle. Erst wenn Portfolio, Produkt-Prozess-Klassen, Datenmodell, Anwender, priorisierte Use Cases und Zielarchitektur geklärt sind, werden Produktnamen vergleichbar.
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.
Interaktive Entscheidungshilfe
Erst die führende Aufgabe. Dann die Systemklasse.
Wählen Sie die Systemrolle, die im Zielbild führen soll. Die Einordnung zeigt Kernobjekt, typische Stärke, benötigtes Ergebnis und die Grenze, an der weitere Systeme übernehmen müssen.
Sieben Systemklassen im industriellen Lösungsraum
Angebot, Pricing, Freigabe und kommerzieller Workflow.
Quote, Deal, Preisbestandteile, Konditionen und Vertragsübergabe.
CRM-nahe Nutzerführung, Kanäle, Governance und Quote-to-Cash.
Technische Produktlogik und belastbare Engineering-Ergebnisse müssen häufig angebunden werden.
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.
Marktübersichten können diese Heterogenität sichtbar machen. Für eine belastbare Auswahl reichen Anbieterprofile jedoch nicht aus: Entscheidend sind Systemrolle, Kernobjekt, Wissensmodell, Pflegekonzept und die benötigten Ergebnisobjekte.
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. Sieben Systemklassen im industriellen Lösungsraum
Für die fachliche Einordnung werden sieben Systemklassen unterschieden. Fünf stammen unmittelbar aus CPQ-, Konfigurations- oder Automatisierungsaufgaben. Configuration Lifecycle Management und PLM-nahe Variantenführung sind angrenzende Systemwelten, prägen jedoch dieselben End-to-End-Prozesse und werden deshalb als eigenständige Klassen 04 und 05 mitgeführt. Insight 206 vertieft die sieben Klassen nach Herkunft, Kernobjekt und Eignung.
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
Angrenzende Systemwelt: Konsistenz von Konfigurationslogik und gültigen Varianten über Entwicklung, Vertrieb, Fertigung und Service.
05
PLM-nahe Variantenführung
Angrenzende Systemwelt: 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
2D-/3D-Konfiguration, Layout, Geometrie und digitale Kundenschnittstellen. Entscheidend ist die Durchgängigkeit zu technischer Logik, Preis und Fertigung.
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: MTS, 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.
| Systemklasse | Repräsentative Beispiele | Typische Prüffrage |
|---|---|---|
| 01 Vertriebszentrierte CPQ-Suiten | SAP CPQ, Oracle CPQ, Salesforce Agentforce Revenue Management, Conga Advantage CPQ | Reicht die technische Konfiguration – und wie erfolgt die Übergabe an PLM und ERP? |
| 02 Industrielle CPQ- und Produktkonfiguration | Tacton, Conga Smart CPQ, encoway, camos, CAS Merlin, ORISA, SAE | Wie gut passen Regelwerk, Produkt-Prozess-Klassen, Ergebnisobjekte und Modellpflege? |
| 03 ERP-nahe Variantenkonfiguration | 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? |
| 04 Configuration Lifecycle Management (angrenzend) | Configit sowie vergleichbare Plattformansätze | Wird Konsistenz geschaffen oder ein weiteres Produktmodell eingeführt? |
| 05 PLM-nahe Variantenführung (angrenzend) | Teamcenter Product Configurator, Windchill Options & Variants, ENOVIA, Aras | Welche technische Wahrheit wird im PLM geführt und welche Verkaufssicht benötigt CPQ? |
| 06 Design- und Engineering-Automation | Siemens Rulestream, DriveWorks und CAD-nahe Automation | Welche wiederkehrenden CTO+- und ETO-Ergebnisse lassen sich stabil automatisieren? |
| 07 Visuelle und raumbezogene 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 für Entscheider
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.
Seven system classes are distinguished across the industrial solution landscape. Five originate directly from CPQ, configuration or automation tasks. Configuration Lifecycle Management and PLM-based variant management remain identified as adjacent system domains, but are included as classes 04 and 05 because they materially shape the same end-to-end processes and target architecture. Insight 206 examines all seven classes by origin, core object and suitability.
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 model, prioritized end-to-end use cases, and a defined product and data architecture.
Weiterführende Insights
Position: Säule 2 · CPQ und Produktkonfiguration · Beitrag 1 von 6
Vorheriger Beitrag: — Auftakt der Säule
Nächster Beitrag: Insight 202 – CPQ-Systemauswahl ist kein Softwarevergleich
Einordnung und Aktualität: Die Marktbetrachtung basiert auf langjähriger Projekt- und Markterfahrung von Dr. Wüpping Consulting. Produktbezeichnungen und Leistungsumfänge verändern sich; Stand: August 2026. Die genannten Beispiele sind weder vollständig noch als Ranking oder Empfehlung zu verstehen.