MARKTÜBERSICHT
Der CPQ-Markt ist kein einheitlicher Softwaremarkt
Systemrollen verstehen, bevor Produkte verglichen werden.
Diese CPQ-Marktübersicht ordnet Lösungen, die von geführter Produktauswahl und Preisfindung bis zu technischer Auslegung, Stücklistenableitung, CAD-Automation und Lifecycle-Steuerung reichen. Die Unterschiede sind architektonisch, nicht kosmetisch.
Stand: August 2026
EXECUTIVE SUMMARY
Die entscheidende Marktfrage lautet nicht: Welches System kann am meisten? Sie lautet: Welche Logik, Informationen und Ergebnisobjekte müssen in welchem Prozessschritt verlässlich erzeugt, geführt und übergeben werden?
Warum der Markt schwer vergleichbar ist
Je ähnlicher die Funktionslisten erscheinen, desto wichtiger werden Modellierungsansatz, Datenhoheit, Ergebnisobjekte, Pflegefähigkeit und Systemgrenzen.
Die Begriffe CPQ, Produktkonfigurator, Variantenkonfigurator und Angebotskonfigurator werden im Markt nicht einheitlich verwendet. Ein einfaches Auswahlwerkzeug kann ebenso als Konfigurator bezeichnet werden wie eine Plattform, die technische Regeln, Preise, Dokumente, Stücklisten und CAD-Ergebnisse erzeugt. Umgekehrt verfügen ERP-, PLM-, Commerce- oder PIM-nahe Plattformen über Konfigurationsfunktionen, ohne sich als eigenständige CPQ-Lösung zu positionieren.
Auch ähnliche Funktionsnamen sagen wenig über fachliche Tiefe aus. Guided Selling kann aus wenigen Filterfragen bestehen oder einen komplexen Lösungsraum aus Kundenanforderungen, Anwendungen und Produktwissen erschließen. Konfiguration kann eine kommerzielle Auswahl prüfen oder eine vollständige technische Struktur ableiten. Dokumentengenerierung kann ein Angebots-PDF zusammensetzen oder kundenspezifische Spezifikationen, Zeichnungen, BIM-Objekte und Fertigungsunterlagen erzeugen.
Hinzu kommt die unterschiedliche Herkunft der Anbieter. Ein aus CRM und Revenue Management gewachsenes System betrachtet das Angebot anders als eine Regelwerksplattform aus dem Maschinenbau, ein ERP-Konfigurator, eine PLM-Lösung oder eine Engineering-Automation. Diese Herkunft ist kein Qualitätsurteil. Sie erklärt jedoch, warum Benutzerführung, Modellierung, Datenhaltung, Integration und Betriebslogik verschieden ausgeprägt sind.
Sechs Ebenen statt einer CPQ-Box
Für eine belastbare Einordnung betrachtet CPQ-SELECT den Markt entlang von sechs Ebenen. Die Ebenen sind weder lineare Prozessstufen noch ein Reifegradmodell. Sie zeigen, wo eine Lösung ihren fachlichen Schwerpunkt besitzt und welche Objekte dort führend oder verbindlich werden.
In der Praxis kann eine Plattform mehrere Ebenen abdecken. Genau deshalb ist die Objektverantwortung entscheidend: Wer führt Merkmale, Regeln, Produktstrukturen, Preise, Geometrie, Dokumente und Auftragsobjekte? Wer erhält nur eine veröffentlichte, abgeleitete oder transaktionale Sicht? Ohne diese Trennung entsteht Doppelmodellierung, die nicht durch zusätzliche Schnittstellen geheilt wird.
Aufgaben und typische Systeme im Detail
| Ebene | Typische Aufgaben | Typische Systeme |
|---|---|---|
| Markt und Vertrieb | Kundenbedarf, Guided Selling, Opportunity, Angebot, Kanal, Preis, Rabatt und Freigabe. | CRM, Commerce, vertriebszentriertes CPQ, Deal Desk, Pricing Engine. |
| Produktlogik | Merkmale, Regeln, Variantenraum, Produktmodell, Konfigurationsstatus und Berechnungen. | Industrielles CPQ, Produktkonfiguration, Configuration Lifecycle Management. |
| Produkt und Lifecycle | Produktstruktur, Variantenführung, Gültigkeit, Version, Baseline, Freigabe und Änderung. | PLM, CLM, Produktdaten- und Variantenmanagement. |
| Engineering und Visualisierung | Auslegung, Berechnung, CAD/ECAD, eBOM, Geometrie, Visualisierung und technische Dokumente. | CAD/ECAD, Design- und Engineering-Automation, Simulation, Visualisierung. |
| Auftrag und Wertschöpfung | Material, Auftrag, mBOM, Arbeitsplan/BOP, Costing, Beschaffung und Fertigung. | ERP, MES, SCM. |
| Publikation und Nutzung | Kanaldaten, Medien, Kataloge, Portale, Dokumente und Analysen. | PIM, DAM, DMS, BI/Data Platform. |
MARKTORDNUNG
Von den Ebenen zu den CPQ-Systemklassen
Aus diesen Ebenen leitet CPQ-SELECT sieben Systemklassen ab: vertriebszentrierte CPQ-Suiten, industrielle CPQ- und Produktkonfiguration, ERP-nahe Variantenkonfiguration, Configuration Lifecycle Management, PLM-nahe Variantenführung, Design- und Engineering-Automation sowie visuelle und raumbezogene Konfiguration.
Die Klassen beschreiben typische fachliche Schwerpunkte, nicht die gesamte Bandbreite einzelner Produkte. Die dauerhafte Einordnung eines Herstellers in genau eine Klasse wäre häufig zu grob: Portfolios entwickeln sich weiter, Unternehmen werden übernommen und Funktionen überschneiden sich. CPQ-SELECT nutzt die Klassen deshalb als Marktordnung, nicht als Anbieteretikett.
PIM und CPQ: Quelle, Empfänger und kontrollierter Rückfluss
PIM-Systeme führen typischerweise vermarktungs- und kanalspezifische Produktinformationen: Beschreibungen, Klassifikationen, Medien, sprach- und regionsbezogene Inhalte sowie freigegebene Merkmale. Ein CPQ-System kann diese Informationen für Auswahl, Darstellung, Dokumente und digitale Kanäle nutzen. In einer typischen Zielarchitektur ist das PIM jedoch nicht das führende System für technische Konfigurationslogik, Baubarkeitsregeln, Gültigkeiten oder die Ableitung auftragsspezifischer Stücklisten.
Der Rückfluss ist dennoch möglich und sinnvoll, wenn er fachlich klar begrenzt ist. Freigegebene Varianten, abgeleitete Merkmale, Produktbeschreibungen, Vorschaubilder, BIM-Objekte, technische Datenblätter oder katalogfähige Datenpakete können aus Produktmodellierung, PLM, Design Automation oder CPQ in das PIM beziehungsweise DAM übergeben werden. Das PIM übernimmt dann publizierbare Ergebnisse; es ersetzt nicht den technischen Konfigurationskern.
Der Architekturfehler entsteht dort, wo im PIM vorhandene Attribute vorschnell mit einem belastbaren Produktmodell gleichgesetzt werden. PIM-Systeme können Validierungen, Workflows und Attributabhängigkeiten besitzen. Für komplexe technische Constraints, mehrstufige Ableitungen, Variantenstrukturen und reproduzierbare Konfigurationsergebnisse ist jedoch zu prüfen, ob ein spezialisiertes Produktmodell, PLM, CPQ oder ERP die führende Rolle übernehmen muss.
PIM stellt in der Regel produkt- und vertriebsrelevante Informationen für CPQ bereit. Rückschreibungen aus CPQ in das PIM bleiben kontrollierte Ableitungen – nicht die Regelquelle.
Typische Informationsflüsse und Architekturhinweise
| Informationsfluss | Typische Richtung | Architekturhinweis |
|---|---|---|
| Texte, Medien, Klassifikationen, Kanaldaten | PIM/DAM → CPQ/Commerce | PIM führt publizierbare Produktinformation. |
| Merkmale, Regeln, Gültigkeiten, Variantenraum | Produktmodell/PLM/CPQ → Nutzungssysteme | Führendes Modell und Governance explizit festlegen. |
| Angebot, Opportunity, Aktivitäten | CPQ ↔ CRM | Version, Status und Verantwortung nicht doppelt führen. |
| Preis, Auftrag, Material, Stückliste | CPQ ↔ ERP/Pricing | Preisposition, Kostenobjekt und Materialposition getrennt modellieren. |
| CAD/ECAD, eBOM, Zeichnung, Berechnung | CPQ/DA ↔ PLM/CAD | Auslöser, Rückführung, Baseline und Freigabe definieren. |
| Freigegebene Varianten und Publikationspakete | PLM/CPQ/DA → PIM/DAM | Rückfluss als Ableitung und Veröffentlichung, nicht als neue Regelquelle. |
Datenformate: breiter denken, aber sauber trennen
Ein Datenformat löst noch keine Integration. Entscheidend sind zusätzlich Objektidentität, Semantik, Version, Gültigkeit, Änderungslogik, Fehlerbehandlung und fachliche Verantwortung. Dieselbe JSON- oder XML-Struktur kann technisch übertragen werden und fachlich dennoch unbrauchbar sein, wenn Quelle, Zielobjekt oder Versionsstand unklar bleiben.
CPQ-SELECT unterscheidet daher mehrere Format- und Austauschfamilien: Transport- und API-Formate wie REST, OData, GraphQL, JSON und XML; Ereignis- und Messaging-Mechanismen; Katalog- und Klassifikationsstandards wie BMEcat, ECLASS und ETIM; Engineering- und Geometrieformate wie STEP, JT, glTF, DXF/DWG oder native CAD-Formate; BIM-Formate wie IFC; betriebliche Integrationen über IDoc, BAPI, EDI oder dateibasierte Massendaten; sowie Dokumentformate wie PDF, Office, HTML und strukturierte Datenpakete.
Für jede Schnittstelle ist deshalb nicht nur das Format zu dokumentieren, sondern auch der fachliche Vertrag: Welche Objekte werden übertragen? Wer erzeugt die Identität? Welche Version gilt? Wie werden Delta, Rückmeldung, Fehler, Wiederholung, Freigabe und historische Reproduktion behandelt? Ohne diese Antworten bleibt „API-first“ eine technische Eigenschaft ohne architektonische Klarheit. Zentrale Fachbegriffe und Abkürzungen werden im CPQ-Glossar erläutert.
Format- und Austauschfamilien im Überblick
| Familie | Beispiele | Prüffrage |
|---|---|---|
| APIs und Transport | REST, OData, GraphQL, JSON, XML, Webhooks, Events. | Sind Semantik, Versionierung, Fehlerbehandlung und Idempotenz definiert? |
| Katalog und Klassifikation | BMEcat, ECLASS, ETIM, CSV/XLSX für kontrollierte Massenpflege. | Wer führt Klassen, Merkmale, Einheiten, Übersetzungen und Mapping? |
| Engineering und Geometrie | STEP, JT, glTF, DXF/DWG, native CAD/ECAD, AutomationML. | Ist das Ergebnis Visualisierung, Austauschmodell oder freigegebene Engineering-Baseline? |
| BIM und Gebäude | IFC, herstellerspezifische BIM-Objekte, Property Sets. | Welche Geometrie, Eigenschaften, LOD/LOI und Gültigkeit werden bereitgestellt? |
| Operative Integration | IDoc, BAPI, EDI, Queue, Batch, Datei, Datenbank. | Wie werden Transaktion, Rückmeldung und Wiederanlauf gesichert? |
| Dokument und Publikation | PDF, Office, HTML, Bild, 3D-Asset, Datenpaket. | Ist das Dokument nur Darstellung oder ein freigegebenes Ergebnisobjekt? |
Pricing ist eine eigene Architekturdomäne
Pricing ist mehr als das Multiplizieren eines Listenpreises mit einem Rabatt. In variantenreichen Angeboten können Kosten, Optionen, technische Merkmale, Kundennutzen, Region, Kanal, Wettbewerb, Kapazität, Lieferzeit und Vertragslogik gleichzeitig wirken. Deshalb ist zu klären, welche Preislogik im CPQ, ERP, CRM, einer Pricing Engine oder Data Platform geführt wird und wie Freigaben sowie historische Reproduzierbarkeit gesichert werden.
Cost-plus bleibt für viele Industrieunternehmen eine unverzichtbare Untergrenze. Es verbindet Material-, Fertigungs-, Engineering- und Projektkosten mit Mark-up oder Zielmarge. Merkmals- und optionsbasierte Modelle übersetzen technische Ausprägungen in Preispositionen oder Zuschläge. Value-based Pricing orientiert sich stärker am wirtschaftlichen Nutzen für den Kunden, segment- und marktbasiertes Pricing an Region, Kanal, Wettbewerb oder Zahlungsbereitschaft. In der Praxis entstehen meist hybride Modelle.
Mark-up, Marge und Rabatt sind sauber zu unterscheiden. Ein Mark-up wird auf eine Kostenbasis aufgeschlagen; die Marge beschreibt den Anteil am Verkaufspreis. Floor Price, Target Price und Guidance bilden Leitplanken. Discount-Strategien benötigen Gründe, Kompetenzen, Genehmigungen und Rückkopplung. Dynamisches Pricing kann Daten und Nachfrage schneller berücksichtigen, darf aber technische Machbarkeit, Vertragsbindung, Fairness und Governance nicht unterlaufen.
Preisansätze und zentrale Governancefragen
| Preisansatz | Typischer Bezug | Architektur- und Governancefrage |
|---|---|---|
| Cost-plus / Mark-up | Kostenbasis plus Zuschlag oder Zielmarge. | Woher stammen Kosten, zu welchem Zeitpunkt, in welcher Granularität und Version? |
| Merkmals- und optionsbasiert | Ausprägungen, Komponenten, Leistung, Mengen und Pakete. | Sind Preis- und Produktmodell gekoppelt oder bewusst getrennt? |
| Wertbasiert | Kundennutzen, Einsparung, Risiko oder Produktivität. | Wie wird Nutzen segmentiert, begründet und im Vertrieb anwendbar? |
| Markt- und segmentbasiert | Region, Kanal, Kunde, Wettbewerb, Zahlungsbereitschaft. | Welche Daten sind zulässig, aktuell und erklärbar? |
| Hybrid | Kombination aus Kostenuntergrenze, Merkmalen, Wert und Markt. | Welche Regel hat Priorität und wie bleibt das Ergebnis reproduzierbar? |
| Dynamisch | Zeit, Nachfrage, Kapazität, Bestand oder Marktsignal. | Welche Leitplanken, Freigaben und Ausschlussregeln verhindern Fehlsteuerung? |
Dashboards schließen den Regelkreis
Dashboards sind kein dekorativer Zusatz. Sie zeigen, ob Konfiguration, Pricing und Angebotsprozess tatsächlich funktionieren. Relevante Kennzahlen reichen von Nutzung und Durchlaufzeit über Fehler- und Ausnahmequoten bis zu Preisrealisierung, Margenqualität, Rabattleckage, Freigaben, Win/Loss und Modellpflege.
Eine Kennzahl ist nur dann belastbar, wenn Definition, Datenquelle, Granularität, Zeitbezug und Verantwortlichkeit eindeutig sind. „Angebotsdurchlaufzeit“ kann beispielsweise vom ersten Kundenkontakt, vom Start der Konfiguration oder von der letzten Freigabe bis zur Abgabe gemessen werden. Ohne Definition sind Vergleiche wertlos.
Entscheidend ist die Verbindung zur steuerbaren Entscheidung. Ein Discount-Dashboard muss zeigen, wo Korridore und Kompetenzen angepasst werden sollten. Margin Leakage muss Ursachen entlang Preis, Kosten, Sonderoptionen und Rabatten sichtbar machen. Modellqualitätskennzahlen müssen Pflege, Test und Release verbessern. Analytics erhält damit eine Governance-Funktion und wird nicht zum Selbstzweck.
Kennzahlengruppen und gestützte Entscheidungen
| Kennzahlengruppe | Typische Kennzahlen | Gestützte Entscheidung |
|---|---|---|
| Nutzung und Prozess | Nutzerquote, Abbruch, Durchlaufzeit, Nacharbeit, Ausnahmequote. | Benutzerführung, Scope, Schulung und Prozessdesign verbessern. |
| Preis und Rabatt | Price Realization, Discount, Floor-Verletzung, Freigabequote. | Preisleitplanken, Kompetenzen und Guidance anpassen. |
| Marge und Kosten | Deckungsbeitrag, Margin Leakage, Kostenabweichung, Sonderanteil. | Kostenquelle, Zuschläge, Sonderfreigaben und Portfolio steuern. |
| Vertriebsergebnis | Quote Conversion, Win/Loss, Angebotswert, Zyklus nach Segment. | Zielsegmente, Guided Selling und Angebotsqualität fokussieren. |
| Produktmodell | Regelverletzung, Testabdeckung, Änderungsaufwand, Wiederverwendung. | Modularisierung, Modellpflege und Releasequalität verbessern. |
| Datenqualität | Fehlende Merkmale, widersprüchliche Quellen, Synchronisationsfehler. | Datenhoheit, Schnittstellen und Governance korrigieren. |
Ergebnisobjekte entscheiden über den Marktfit
Die Qualität einer Lösung zeigt sich nicht nur in ihrer Oberfläche, sondern an den Ergebnissen, die nach einer Konfiguration belastbar vorliegen. Je nach Prozessklasse können diese Ergebnisse kaufmännisch, technisch, visuell, operativ oder analytisch sein. Ein System, das ein überzeugendes Angebot erzeugt, ist nicht automatisch in der Lage, eine revisionssichere Stückliste, ein CAD-Modell oder eine freigegebene Baseline zu liefern.
Die Auswahl sollte deshalb von den benötigten Ergebnisobjekten rückwärts denken. Für jedes Objekt sind Inhalt, Granularität, Identität, Version, Gültigkeit, Freigabe, Empfänger und Fehlerbehandlung zu definieren. Erst daraus wird sichtbar, welche Systemklasse und welche Integrationsarchitektur tatsächlich erforderlich sind.
Ergebnisdomänen und Qualitätsmaßstäbe
| Ergebnisdomäne | Beispiele | Qualitätsmaßstab |
|---|---|---|
| Kaufmännisch | Angebotsposition, Preis, Rabatt, Marge, Freigabe, Vertrags- und Zahlungslogik. | Vollständig, nachvollziehbar, genehmigt und historisch reproduzierbar. |
| Technisch | Konfigurationsstatus, Berechnung, Zeichnung, CAD/ECAD, eBOM, 100-%-Stückliste, Datenblatt. | Technisch gültig, revisionssicher und eindeutig referenziert. |
| Visuell | 2D/3D-Ansicht, Rendering, AR/VR, BIM-Objekt, Vorschaubild, Medienpaket. | Synchron zur Konfiguration, zweckgerecht und formatstabil. |
| Operativ | Material, Auftrag, mBOM, Arbeitsplan/BOP, Beschaffungs- und Fertigungsinformationen. | Ohne manuelle Übersetzung in ausführbare Objekte überführbar. |
| Analytisch | Ereignisse, Entscheidungsdaten, Preis- und Rabattgründe, Nutzung, Modellqualität. | Definiert, datenschutzkonform und einer Entscheidung zugeordnet. |
Produkt-Prozess-Klassen verändern den Lösungsbedarf
Ein Standardprodukt, eine vordefinierte Auftragsvariante, eine konfigurierte Maschine und ein kundenspezifisch entwickeltes System stellen unterschiedliche Anforderungen. MTS, PTO, ATO, MTO, CTO, CTO+ und ETO unterscheiden sich darin, wann das Produkt feststeht, wo der Kundenkopplungspunkt liegt und welche Ergebnisse im Auftrag noch entstehen müssen.
Für PTO- und einfache MTO-Szenarien können Produktauswahl, Verfügbarkeit, Preis und Angebotsprozess im Vordergrund stehen. CTO verlangt einen vorab definierten und regelbasiert beherrschbaren Lösungsraum. CTO+ benötigt zusätzlich kontrollierte Auslegung oder automatisierte Engineering-Ergebnisse. ETO kann durch CPQ vorbereitet und strukturiert werden, bleibt aber in wesentlichen Teilen ein Engineering- und Projektprozess.
Ein Modell, das für wiederholbare CTO-Aufgaben hervorragend funktioniert, ist nicht automatisch für ETO geeignet. Ebenso ist eine auf ERP-Auftragslogik optimierte Lösung nicht zwangsläufig die beste Oberfläche für anonyme Webnutzer, Partner oder internationale Vertriebsorganisationen.
ARCHITEKTURGRUNDSATZ
Der Markt wird durch Architektur entschieden
In vielen Unternehmen existieren CRM, PIM, PLM, CAD, ERP und spezialisierte Anwendungen bereits. Eine CPQ-Initiative beginnt daher selten auf einer leeren Systemlandschaft. Die eigentliche Entscheidung lautet nicht, welches Produkt möglichst viele Funktionen übernimmt, sondern wie Aufgaben, Objekte und Datenhoheit sinnvoll verteilt werden.
Das kann zu unterschiedlichen Zielbildern führen. In einem Unternehmen liegt die technische Produktlogik nah am PLM und wird für den Vertrieb in eine verkaufsorientierte Sicht überführt. In einem anderen Unternehmen führt ein industrielles CPQ-System die Regeln und erzeugt Ergebnisse für CRM und ERP. In einem dritten Szenario bleibt die Variantenlogik im ERP, während eine vertriebsnahe Schicht Guided Selling, Pricing und Angebote ergänzt.
Nicht ein System muss alles beherrschen. Entscheidend ist, welches System welche Aufgabe und welches Objekt verbindlich führt – und wie die übrigen Systeme daran anschließen.
Keine dieser Architekturen ist allgemein überlegen. Tragfähig ist eine Lösung, wenn Systemrollen, Verantwortlichkeiten, Änderungsprozesse, Ergebnisobjekte und Übergaben zum Produktportfolio, zu den Produkt-Prozess-Klassen und zum Betriebsmodell des Unternehmens passen.
Von der Marktübersicht zur Auswahl
Die Marktübersicht ist kein Ersatz für eine Auswahlmethodik. Sie schafft den Ordnungsrahmen, in dem eine Longlist überhaupt sinnvoll gebildet werden kann. Vor der Betrachtung einzelner Anbieter sind Aufgabe und Scope, Nutzer und Kanäle, Produkt-Prozess-Klassen, Ergebnisobjekte, Datenhoheit, Pricing, Visualisierung, Integrationsanforderungen und Governance zu klären.
Die CPQ-Auswahlkriterien führen diese Prüffelder aus. Die sieben CPQ-Systemklassen beschreiben die Referenzklassen im Detail. Das CPQ-Anbieterregister bleibt bewusst alphabetisch und neutral; es ist Ausgangspunkt für Recherche, nicht Ergebnis einer Auswahl.
English executive summary
The market for CPQ and industrial product configuration is not a homogeneous software category. Solutions may originate from sales and CRM, technical product configuration, ERP, PLM, engineering automation, lifecycle management or visual planning. Similar feature labels often conceal substantial differences in modelling depth, data ownership, maintainability and output objects.
CPQ-SELECT therefore structures the market by tasks, objects and system roles rather than by vendor rankings. A sound assessment starts with product and process classes, required result objects, pricing responsibility, data ownership, lifecycle governance and the target architecture. Only after these questions are clarified should companies compare products and vendors.