CPQ Software: Was sie leistet, wo ihre Grenzen liegen und wie Sie auswählen

CPQ Software verbindet drei Schritte, die in variantenreichen Vertriebsprozessen sonst auseinanderfallen: die technisch gültige Konfiguration, die belastbare Preisfindung und das versandfertige Angebot. Für Hersteller mit konfigurierbaren Maschinen, Anlagen oder Fahrzeugkomponenten ist das der Unterschied zwischen einem Angebot in Stunden und einem Angebot in Tagen. Interessant ist allerdings weniger die Frage, was CPQ kann. Interessant ist, wo die Kategorie aufhört, was sie an Datenqualität voraussetzt und warum der Markt gerade jetzt ein Auswahlrisiko darstellt, das vor zwei Jahren noch keines war.

Was ist CPQ Software?

CPQ steht für Configure, Price, Quote. Eine CPQ Software führt Vertrieb, Partner oder Endkunden regelbasiert durch die Zusammenstellung eines konfigurierbaren Produkts, berechnet daraus einen gültigen Preis und erzeugt ein Angebot samt technischer Spezifikation. Gartner beschreibt CPQ Application Suites als integriertes Set von Anwendungen, das Konfiguration, Preisfindung und Angebotserstellung im lösungsorientierten und verhandelten Vertrieb unterstützt, typischerweise mit Pricing Engine, Proposal Generator, Quoting-System und einer Regel- beziehungsweise Constraint-Engine (Gartner IT-Glossar). Der eigentliche Kern ist die Regel-Engine. Sie entscheidet, welche Kombination aus Merkmalen technisch überhaupt zulässig ist. Alles andere setzt darauf auf.

Configure, Price, Quote: die drei Schritte im Detail

Schritt	Was passiert	Woran es in der Praxis scheitert
Configure	Regelwerk prüft Merkmalskombinationen, schließt unzulässige Optionen aus, ergänzt Zwangsbauteile und erzeugt eine eindeutige Spezifikation samt Stücklistenbezug.	Das Regelwerk ist historisch gewachsen, niemand kann es vollständig erklären, und Änderungen brauchen Entwicklerhilfe.
Price	Ermittelt Listenpreis, Zu- und Abschläge, Rabattstufen, Währungs- und Länderlogik, Rahmenvertragskonditionen und Freigabegrenzen.	Preislogik liegt verstreut in ERP, Excel und Köpfen. Der Rabatt ist verhandelbar, die Herstellkosten dahinter sind unbekannt.
Quote	Erzeugt das Angebotsdokument mit Texten, Bildern, technischen Daten und Nachweisen, dokumentiert Varianten und übergibt an CRM und ERP.	Die Produktinhalte im Angebot sind veraltet, weil sie nicht aus einer geführten Quelle kommen, sondern aus einer Kopie.

Für welche Unternehmen lohnt sich CPQ Software?

Ein brauchbares Auswahlraster liefert die Produkt-Prozess-Klasse, also die Frage, wie viel eines Auftrags bereits vor dem Auftrag festliegt. Sie sagt mehr über die CPQ-Eignung aus als Umsatz oder Mitarbeiterzahl. Die folgende Einteilung folgt der in der Auftragsabwicklung verbreiteten Systematik, wie sie unter anderem Dr. Wüpping Consulting für die CPQ-Systemauswahl heranzieht.

Produkt-Prozess-Klasse	Charakteristik	CPQ-Eignung
MTS (Make to Stock)	Lagerfertigung, feste Artikel, Preis aus Preisliste	Gering. Shop oder CRM genügt.
PTO (Pick to Order)	Zusammenstellung aus Lagerartikeln, keine Fertigung je Auftrag	Gering bis mittel. Sinnvoll, sobald Bündel und Zubehörregeln komplex werden.
ATO (Assemble to Order)	Montage aus vordefinierten Modulen, endlicher Variantenraum	Hoch. Klassischer CPQ-Fall mit klarem ROI.
MTO (Make to Order)	Auftragsbezogene Fertigung auf Basis definierter Produkt- und Prozessstrukturen, ohne Neukonstruktion	Hoch. Der Variantenraum ist festgelegt, die Fertigung startet erst mit dem Auftrag.
CTO (Configure to Order)	Regelbasierte Konfiguration, sehr großer Variantenraum, keine Neukonstruktion	Sehr hoch. Kernfall für CPQ Software.
CTO+	Konfiguration mit begrenztem Anpassungsanteil, gelegentliche Sonderlösungen außerhalb des Regelwerks	Hoch, wenn der Standardanteil dominiert und Sonderfälle bewusst als Ausnahme geführt werden.
ETO (Engineer to Order)	Auftragsbezogene Konstruktion, das Angebot selbst ist ein Engineering-Vorgang	Eingeschränkt. CPQ deckt hier den standardisierbaren Teil ab, ersetzt aber keine Angebotskalkulation durch Konstruktion.

Der häufigste Auswahlfehler in dieser Tabelle betrifft die Erwartungshaltung. Ein Unternehmen mit hohem ETO-Anteil kauft eine CPQ Software in der Annahme, damit nahezu den gesamten Angebotsausgang zu automatisieren, und erreicht am Ende nur den standardisierbaren Bruchteil. Das Projekt gilt dann als gescheitert, obwohl das Ergebnis dem Produktprogramm entspricht. Prüfen Sie deshalb vorab, welcher Anteil Ihres Auftragseingangs überhaupt regelbasiert abbildbar ist, und leiten Sie das Projektziel daraus ab.

CPQ Software auswählen: sieben Schritte

Die Reihenfolge ist entscheidend, weil die ersten drei Schritte über den Erfolg entscheiden und die letzten vier nur noch über den Anbieter.

1. Produkt-Prozess-Klassen bestimmen. Welcher Anteil Ihres Auftragseingangs ist ATO, CTO, CTO+ oder ETO? Das definiert den realistischen Automatisierungsgrad.
2. Datenmodell prüfen. Existieren standardisierte Merkmalsleisten und Wertelisten? Wenn nein, ist das Ihr erstes Projekt, nicht das CPQ.
3. Datenhoheit festlegen. Pro Datenobjekt genau ein führendes System und eine verantwortliche Rolle, schriftlich fixiert. Wie sich das über PLM, ERP, PIM und MDM verteilt, behandelt der Artikel zum Variantenmanagement.
4. Systemrollen abgrenzen. Wer erzeugt welche Stücklistensicht (Vertrieb, Konstruktion, Fertigung), wo liegt die Preislogik, wo die Kostenbewertung, wo das Regelwerk.
5. Integrationstiefe klären. Bidirektional zu ERP und CRM, und zwar mit konkreten Objekten und Auslösern, nicht als Konnektor-Logo auf einer Folie.
6. Anbieterstabilität bewerten. Produktroadmap, Portfolio-Überschneidungen nach Übernahmen, Exportierbarkeit des Konfigurationsmodells.
7. Betriebsmodell definieren. Rollen, Aufwände und Freigabewege für die Pflege nach dem Go-live, mit Namen und Kapazität.

CPQ Software, Produktkonfigurator, Guided Selling und ERP-Variantenkonfiguration: wo liegen die Grenzen?

Diese vier Begriffe werden im Markt weitgehend synonym verwendet, und genau daraus entstehen Fehlinvestitionen. Die Abgrenzungen im Einzelnen:

Was unterscheidet CPQ Software von einem Produktkonfigurator?

Ein Produktkonfigurator endet bei der gültigen Spezifikation, oft ergänzt um einen Listenpreis. CPQ Software führt darüber hinaus den kaufmännischen Prozess: Rabattlogik, Genehmigungsworkflows, Angebotsversionierung, Gültigkeitsfristen, Übergabe in CRM und ERP. Die Trennlinie liegt also nicht im C, sondern in P und Q. CPQ-Lösungen für variantenreiche Industrieprodukte enthalten typischerweise eine Konfigurationsfunktion. Ein vollständiger technischer Produktkonfigurator ist damit aber nicht gesetzt, und umgekehrt ist längst nicht jeder Konfigurator CPQ. Wie ein Konfigurator technisch arbeitet und was hinter dem Begriff High-Level Configuration Approach steckt, erklärt unser Artikel zum Produktkonfigurator. Praktische Konsequenz: Wenn Angebote in Excel kalkuliert und Rabattfreigaben per E-Mail gesteuert werden, ist CPQ ein ernsthafter Kandidat. Ob es ein vollständiges CPQ-System braucht, hängt aber von Produktkomplexität, Preislogik, Freigabetiefe und Integrationsbedarf ab. In einfacheren Fällen reichen Angebotsautomatisierung, CRM-Workflows oder eine Pricing-Lösung. Sind Ihre Preise fix, Ihre Rabatte regelbasiert und Ihre Angebote einseitig, genügt ein Konfigurator, und Sie sparen sich ein mehrjähriges Projekt.

Ist Guided Selling dasselbe wie CPQ?

Nein. Guided Selling ist ein Interaktionsmuster, keine Systemkategorie. Es beschreibt, dass ein Nutzer über Bedarfsfragen zur passenden Lösung geführt wird, statt sich durch eine technische Merkmalsliste zu arbeiten. Das kann innerhalb einer CPQ Software passieren, ebenso im Webshop, in einer Produktsuche oder in einem Beratungstool ohne jede Konfigurationslogik. Anbieter listen Guided Selling gern als CPQ-Feature. Der wichtigere Punkt ist die Frage dahinter: Welche Fragen kann ein Kunde selbst beantworten, was muss der Vertrieb ergänzen, und wo ist technische Expertise unverzichtbar? Bleibt diese Dreiteilung ungeklärt, entsteht ein Fragebogen, den niemand ausfüllt.

Wo endet der Onlineshop und wo beginnt CPQ?

Ein Shop verkauft, was preislich und logistisch eindeutig ist. CPQ erzeugt, was erst durch Regelauswertung eindeutig wird. Sobald Rabattfreigaben, Rahmenverträge, Lieferzeitzusagen oder technische Rückfragen ins Spiel kommen, ist der Checkout der falsche Ort. Für die Architektur folgt daraus eine einzige relevante Frage: Teilen Shop und CPQ dasselbe Regelmodell, oder pflegen Sie zwei Modelle? Die Antwort bestimmt Ihre Betriebskosten für die nächsten Jahre. Wo Käufer schon vor der Konfiguration Orientierung brauchen, ist das die Aufgabe von Guided Selling im Vertrieb.

Zwei Einsatzmodelle, zwei sehr unterschiedliche Projekte

CPQ Software wird in der Praxis auf zwei Arten betrieben, und die Wahl entscheidet über Aufwand und Risiko mehr als die Produktauswahl.

	Angebotssystem für den Vertrieb	Self-Service-Konfiguration
Wer bedient	Innendienst, Außendienst, Handelspartner	Endkunde ohne Schulung
Preissicht	Konditionen, Rabattstufen, Marge	Listenpreis oder Preis auf Anfrage
Datenanspruch	hoch, aber Lücken sind kompensierbar	sehr hoch, Lücken werden sofort sichtbar
Umgang mit Sonderfällen	Freigabeweg und manueller Eingriff möglich	muss im Regelwerk abgebildet sein oder in eine Anfrage münden
Typischer Nutzen	kürzere Angebotsdurchlaufzeit, weniger Fehlkonfigurationen	Erreichbarkeit rund um die Uhr, Vorqualifizierung von Anfragen
Übliches Risiko	Akzeptanz im Vertrieb, wenn das Regelwerk lückenhaft ist	öffentlich sichtbare Datenlücken und falsche Preise

Die Reihenfolge ist selten eine Geschmacksfrage. Wer intern anfängt, testet Regelwerk und Preislogik in einem Umfeld, in dem ein Fehler nichts kostet außer einer Rückfrage. Wer außen anfängt, prüft dieselben Dinge vor Kunden. Zwei Modelle bedeuten übrigens nicht zwei Systeme: sinnvoll ist ein Regelwerk mit zwei Rollen und zwei Oberflächen.

Was die einzelnen Beteiligten davon haben

• Der Vertrieb gewinnt vor allem Sicherheit. Ein Angebot, das aus einem geprüften Regelwerk entsteht, muss nicht in der Konstruktion gegengelesen werden, und der Rabatt bewegt sich in einem freigegebenen Rahmen.
• Der Innendienst gewinnt Zeit, weil Rückfragen und Nachbesserungen entfallen. Das ist die Kennzahl, die sich am leichtesten belegen lässt, und deshalb die beste Grundlage für einen Business Case.
• Der Kunde gewinnt Verlässlichkeit. Ein konfiguriertes Angebot mit Stückliste, Zeichnung und Nachweisen ist prüfbar. Ohne begleitende Inhalte aus einem PIM-System bleibt es eine Preisangabe.
• Die Konstruktion gewinnt Ruhe, aber erst nach der Regelaufnahme. Vorher kostet das Projekt dort Zeit, und das gehört in die Planung.

Wo CPQ-Projekte an der Übergabe scheitern

Eine Stückliste (BOM, Bill of Materials) ist die strukturierte Aufstellung aller Baugruppen, Komponenten und Mengen, aus denen ein Produkt besteht. Bei konfigurierbaren Produkten erzeugt jede Konfiguration ihre eigene Stückliste, und Vertrieb, Konstruktion und Fertigung brauchen sie jeweils in anderer Form. Eine Konfiguration erzeugt deshalb nicht ein Ergebnis, sondern drei Sichten auf dasselbe Produkt. Wer diese Unterscheidung überspringt, merkt es spätestens beim ersten Auftrag, der zwischen Vertrieb und Fertigung hängen bleibt.

• Die Sales BOM beschreibt, was der Kunde bestellt hat, in seiner Sprache und Struktur. Sie ist die Grundlage des Angebots.
• Die Engineering BOM beschreibt, wie das Produkt technisch aufgebaut ist, mit Konstruktionslogik und Baugruppenstruktur.
• Die Manufacturing BOM beschreibt, in welcher Reihenfolge und an welchem Ort gefertigt und montiert wird.

Zwischen diesen Sichten liegt Übersetzungsarbeit, und sie ist der Grund, warum ein CPQ-Projekt an der Schnittstelle scheitert und nicht am Konfigurator. Für die Auswahl ist deshalb genau eine Frage wichtig: Welche dieser drei Sichten erzeugt Ihr CPQ, welche bekommt es geliefert, und wer verantwortet die Übersetzung dazwischen? Wie die Stücklistenlogik dahinter aufgebaut ist und woran man ein fehlendes Regelwerk erkennt, behandelt der Artikel zum Variantenmanagement.

Fünf Muster hinter gescheiterten CPQ-Projekten

In den gesichteten Fallbeschreibungen und Beratungsanalysen wiederholen sich fünf Muster:

• Fehlende Modularisierung. Ein unstrukturiertes Produktprogramm konfigurierbar zu machen bedeutet, das Chaos nachzumodellieren. Modularisierung ist Voraussetzung, nicht Projektergebnis.
• Ungeklärte Datenhoheit. Vier Abteilungen pflegen dasselbe Merkmal, niemand entscheidet. Nach dem Go-live driften die Systeme innerhalb weniger Monate auseinander.
• Customizing statt Konfiguration. Jede Sonderanforderung wird programmiert. Beim nächsten Release ist das Projekt releaseunfähig und damit teuer.
• Fehlende Nutzerakzeptanz. Der Außendienst rechnet weiter in Excel, weil das Werkzeug langsamer ist als seine Erfahrung. Antwortzeiten im Konfigurator sind kein Komfortthema, sie entscheiden über die Nutzung.
• Kein Betriebsmodell. Nach dem Projekt fragt niemand mehr, wer Regeln, Merkmale und Preise pflegt. Genau das ist der Punkt, an dem gute Systeme schlecht werden.

Der letzte Punkt lässt sich organisatorisch lösen. Die Rolle, die dauerhaft für Struktur, Regeln und Freigaben zuständig ist, heißt in vielen Unternehmen Data Steward. Ohne sie wird das Regelwerk zum Museum.

Warum CPQ Software ohne saubere Produktdaten scheitert

Eine CPQ Software rechnet mit Merkmalen, Werten und Beziehungen. Sie erzeugt sie nicht. Wenn dasselbe technische Merkmal in drei Systemen unterschiedlich heißt, wenn Einheiten gemischt sind oder wenn Merkmalswerte als Freitext vorliegen, ist kein Regelwerk modellierbar, das länger als ein Release hält. Das ist der Grund, warum CPQ-Projekte überraschend oft nicht am Konfigurator scheitern, sondern an der Datenqualität der Produktdaten. Praktisch heißt das: Vor dem Regelwerk steht das Datenmodell. Welches System dabei welche Daten führt, hängt von der Zielarchitektur ab. Häufig stellt ein PIM-System die vertriebs- und kanalspezifischen Produktdaten bereit, also Merkmalsleisten, Wertelisten, Übersetzungen, Medien und Freigabestände, aus denen Angebotsdokument und Konfigurationsoberfläche gespeist werden. Technische Konfigurationsmerkmale und Regelmodelle können dagegen aus PLM, ERP oder dem Master Data Management stammen. Erst danach ist die Frage sinnvoll, welches Regelwerk darauf aufsetzt. Wer Datenbereinigung und Modellierung in die Einführungsphase verschiebt, verlagert damit nicht das Risiko, sondern nur den Zeitpunkt, an dem es sichtbar wird. Bei Viamedici liegen Konfigurationslogik und Produktdatenmodell deshalb auf einer Plattform: unsere CPQ-Lösung arbeitet direkt auf demselben Datenmodell wie unser PIM-System, wodurch die sonst übliche Doppelpflege von Merkmalen und Wertelisten entfällt. Wie das in der Praxis aussieht, zeigt unser Deep Dive zur Smart Product Configuration.

Pricing ist nicht Costing

Praktisch alle Marktbeiträge behandeln das P in CPQ als Rabattlogik. Im Maschinen- und Anlagenbau ist die schwierigere Aufgabe eine andere: Was kostet diese konkrete Konfiguration uns? Preisfindung ist eine kaufmännische Entscheidung mit Verhandlungsspielraum. Kostenbewertung ist eine Rechnung über Material, Fertigungszeit, Zukaufteile und Zuschläge, und sie hängt an Daten, die im ERP liegen und sich laufend ändern. Eine CPQ Software, die nur Preise kann, produziert Angebote mit unbekannter Marge. Klären Sie in der Auswahl deshalb explizit, ob und wie eine Deckungsbeitragsbetrachtung pro Konfiguration möglich ist, und woher die Kostensätze kommen.

Kennzahlen: Woran messen Sie den Erfolg?

Fast alle Anbieter versprechen schnellere und fehlerfreie Angebote. Prüfbar wird das erst mit Zahlen, die Sie vor dem Projekt erheben. Ein brauchbares Set:

Kennzahl	Warum sie zählt
Angebotsdurchlaufzeit	Zeit von der Anfrage bis zum versandten Angebot. Der offensichtliche Wert, aber nur aussagekräftig getrennt nach Standard- und Sonderfall.
Anteil Angebote ohne Engineering-Rückfrage	Der ehrlichste Indikator für die Qualität des Regelwerks.
Angebotsgenauigkeit	Anteil der Angebote, die ohne technische Korrektur in den Auftrag übergehen.
Quote-to-Order-Rate	Ob die schnelleren Angebote auch bessere Angebote sind.
Rabattdisziplin	Streuung der gewährten Nachlässe je Produktgruppe. Zeigt, ob die Preislogik greift.
Pflegeaufwand je Produktänderung	Personentage, um eine neue Option ins Regelwerk zu bringen. Entscheidet darüber, ob das System nach dem Projekt gepflegt wird oder veraltet.

Der CPQ-Markt 2025 und 2026: Konsolidierung als Auswahlrisiko

Wer aktuell eine Longlist baut, sollte wissen, dass sich der Anbietermarkt in den letzten anderthalb Jahren deutlich bewegt hat. Drei Vorgänge sind für die Auswahl relevant:

• Salesforce CPQ ist End of Sale, nach übereinstimmenden Marktberichten seit dem 19. März 2025. Salesforce selbst bestätigt auf der Produktseite den Status End of Sale und ausdrücklich nicht End of Life: Neukunden können nicht mehr lizenzieren, Bestandskunden erhalten weiter Support, neue Funktionen entstehen auf Revenue Cloud Advanced. Ein End-of-Life-Datum nennt Salesforce nicht (Salesforce).
• Conga hat am 2. Februar 2026 die Übernahme des B2B-Geschäfts von PROS abgeschlossen. Conga selbst gibt seine Kundenbasis mit über 10.000 an, auf die das PROS-Geschäft nun aufsetzt (Conga).
• ServiceNow hat im April 2025 die Übernahme des KI-CPQ-Anbieters Logik.ai angekündigt, mit dem erklärten Ziel, Konfiguration und Angebotsprozess in die eigenen Workflows einzubetten. Für Unternehmen mit ServiceNow-Landschaft verändert das die Optionen, für alle anderen zeigt es die Richtung: CPQ wird zunehmend Bestandteil größerer Suiten statt eigenständiges Produkt.

Für die Praxis folgt daraus eine unbequeme, aber sinnvolle Zusatzfrage an jeden Anbieter in der Shortlist: Welches Produkt aus Ihrem Portfolio verkaufen Sie in drei Jahren noch, und was passiert mit meinem Konfigurationsmodell, wenn Sie es nicht mehr verkaufen? Zur Marktgröße kursieren stark abweichende Prognosen. Aussagekräftiger für eine Investitionsentscheidung als jede absolute Zahl: Mordor Intelligence weist die Fertigung mit etwa 32 Prozent Umsatzanteil 2025 als größtes Anwenderfeld aus (Mordor Intelligence).

Fazit

CPQ Software ist kein Werkzeug, das einen unstrukturierten Vertriebsprozess sortiert. Sie ist der kaufmännische Aufbau auf einem geordneten Produktprogramm und einem belastbaren Datenmodell. In dieser Reihenfolge verkürzen sich Angebotszeiten deutlich, und es entsteht zusätzlich Transparenz über das, was tatsächlich verkauft wird. Umgekehrt automatisiert man die eigenen Datenprobleme. Die drei Fragen, die am Anfang stehen sollten, haben mit Software nichts zu tun: Wie modular ist unser Produktprogramm, wer besitzt welches Datenobjekt, und wer pflegt das Regelwerk in fünf Jahren? Wie sich die dahinterliegende Variantenvielfalt strukturell in den Griff bekommen lässt, behandelt unser Artikel zum Variantenmanagement.