CPQ (Configure, Price, Quote): Was es leistet, wo seine Grenzen liegen und wie Sie auswählen

CPQ verbindet drei Schritte, die beim Vertrieb variantenreicher Produkte sonst auseinanderfallen: die technisch gültige Konfiguration, die belastbare Preisfindung und das versandfertige Angebot. Für Hersteller variantenreicher Maschinen, Anlagen oder Fahrzeugkomponenten heißt das: Ein gültiges Angebot liegt in Minuten vor, wo manuelle Abläufe oft Tage brauchen. 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?

CPQ steht für Configure, Price, Quote, also Konfigurieren, Preis berechnen und Angebot erstellen. Das sind die drei Schritte zwischen einer Kundenanfrage und einem verbindlichen Angebot. Wer variantenreiche Produkte verkauft, stellt zuerst die passende Variante zusammen, berechnet dann den Preis genau dieser Variante und schickt am Ende ein Angebot mit allen technischen Details raus. CPQ bildet das regelbasiert in einem Durchgang ab, für den eigenen Vertrieb, für Partner oder direkt für Endkunden.

Gartner zählt in seiner Marktdefinition für CPQ-Anwendungen unter anderem die automatische Preisfindung, die Auswahl von Produktoptionen und Merkmalen, die Angebotserstellung samt Konditionsverhandlung und die Auftragserfassung zu den Pflichtfunktionen (Gartner Peer Insights). Das Herzstück ist das Regelwerk: Es legt fest, welche Merkmale überhaupt zusammenpassen. Alles andere baut darauf auf.

Configure, Price, Quote: die drei Schritte im Detail

Warum gerade das Regelwerk so oft zum Engpass wird, hat einen technischen Grund. Viele Konfiguratoren bilden ihre Regeln imperativ ab, also als fest programmierte Abfolge von Prüfungen. Das Wissen über die Zusammenhänge steckt dann im Code. Haben die ursprünglichen Entwickler oder Produktingenieure das Unternehmen verlassen, lässt es sich nur mühsam rekonstruieren. Ein deklaratives Regelwerk beschreibt dagegen nur die Einschränkungen selbst, in einer definierten Form und ohne Programmlogik. Es bleibt übersichtlich, Fachleute pflegen und erweitern es ohne Programmierer, und es hängt nicht davon ab, ob die Konfiguration später im Web, auf dem Desktop oder mobil läuft.

Für welche Unternehmen lohnt sich CPQ?

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.

Der häufigste Auswahlfehler in dieser Tabelle betrifft die Erwartungshaltung. Ein Unternehmen mit hohem ETO-Anteil führt CPQ in der Annahme ein, 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 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. Bei neuen Konfigurationsprojekten steht in aller Regel zuerst eine Stammdatenkonsolidierung an. Eine CPQ-Lösung kann Informationen aus mehreren Excel-Tabellen oder aus SAP zusammenführen, ersetzt diese Konsolidierung aber nicht.
3. Datenhoheit festlegen. Pro Datenklasse 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, 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 von einem Produktkonfigurator?

In der Praxis verschwimmen die Grenzen, im engeren Sinne lässt sich aber klar trennen. Ein Produktkonfigurator bietet eine Oberfläche, auf der Nutzer Merkmalswerte auswählen und so zu einer gültigen Produktvariante kommen. Am Ende steht meist ein Konfigurationscode, den der Kunde an den Vertrieb weitergibt, oder eine Zusammenfassung als PDF. Damit endet seine Aufgabe. Alles Weitere läuft manuell oder über eine eigens gebaute Anschlusslösung, und genau dort liegt seine Schwäche.

CPQ führt den Prozess weiter. Im Mittelpunkt stehen die Preisberechnung auf Basis der individuellen Konfiguration und die anschließende Angebotserstellung. Dazu kommen Funktionen, die bei der Auswahl leicht übersehen werden: Rabattlogik, Genehmigungsworkflows, Angebotsversionierung, Gültigkeitsfristen, die Verwaltung von Angeboten und Opportunities sowie die Übergabe in CRM und ERP. Die Trennlinie liegt also nicht im C, sondern in P und Q.

Gerade die Opportunity wird in vielen Vergleichen unterschätzt. Häufig beginnt ein CPQ-Vorgang damit, dass ein Vertriebsmitarbeiter auf Basis der CRM-Daten eine Opportunity für einen bestimmten Kunden anlegt. Konfiguration und Angebot hängen dann an dieser Opportunity, und es entsteht eine Übersicht über alle Anfragen dieses Kunden. Im industriellen Umfeld mit häufigen Nachbestellungen ist das besonders wertvoll, weil frühere Konfigurationen direkt auffindbar bleiben.

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. Viele Lösungen am Markt lassen sich nur als Gesamtsystem nutzen. Modular aufgebaute Lösungen erlauben dagegen, gezielt einzelne Funktionen zu integrieren, etwa Konfiguration und Preisberechnung in einen bestehenden Webshop, der Bestellung und Kundenkonto ohnehin selbst abwickelt. 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 von CPQ 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.

Ein Gegensatz ist das trotzdem nicht, denn beide lassen sich gut kombinieren. Der interne Vertrieb arbeitet mit der vollständigen CPQ-Lösung, bei Bedarf mit erweiterten Regeln für Experten. Im Onlineshop läuft ein auf Endkunden zugeschnittener Ausschnitt. Zwei getrennte Regelwerke entstehen dadurch nicht zwangsläufig: Meist teilen beide einen großen gemeinsamen Regelbestand und unterscheiden sich nur in wenigen Punkten. Für die Architektur bleibt deshalb eine relevante Frage: Teilen Shop und CPQ dasselbe Regelmodell, oder pflegen Sie zwei? Die Antwort bestimmt Ihre Betriebskosten für die nächsten Jahre. Ein Produktkonfigurator, der headless betrieben wird, kann beide Oberflächen aus einem Regelwerk bedienen.

Orientierung braucht dabei nicht zwingend einen vorgeschalteten Dialog. Schon im Konfigurator lässt sich viel davon bieten, etwa über sinnvolle Vorbelegungen. Wie weit das reicht und wann ein eigener Bedarfsdialog sinnvoll wird, beschreibt der Beitrag zu Guided Selling im Vertrieb.

Zwei Einsatzmodelle, zwei sehr unterschiedliche Projekte

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

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. Häufig gibt es einen internen und einen externen Konfigurator, die den Großteil des Regelwerks gemeinsam nutzen. Im Idealfall genügt dann der Austausch der Oberfläche, meist kommen aber einige eigene Regeln je Rolle hinzu.

Was die einzelnen Beteiligten davon haben

• Der Vertrieb gewinnt vor allem Geschwindigkeit. Bei einem hochkomplexen Produkt mit einem Datenblatt von über 600 Seiten braucht eine gültige Konfiguration viel Fachwissen, und selbst erfahrene Experten schlagen immer wieder nach. Fehler passieren trotzdem, also folgen Abstimmungsrunden mit Konstruktion oder Fertigung. Aus einem geprüften Regelwerk entsteht das gültige Angebot dagegen in Minuten. Diese Zeitersparnis lässt sich am leichtesten belegen und ist deshalb die beste Grundlage für einen Business Case.
• Dazu kommt 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.
• Das Unternehmen kann mehr verkaufen. Bei einem Viamedici-Kunden wurden bestimmte Produktfunktionen bis dahin gar nicht angeboten, weil ihre Konfiguration von Hand zu aufwendig und zu fehleranfällig war. Mit dem Regelwerk ließen sie sich sicher konfigurieren, der Vertrieb verkaufte höherpreisige Geräte, und der Umsatz stieg merklich.
• 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 variantenreichen 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:

• Nicht konsolidierte Stammdaten. Liegen dieselben Produktinformationen in mehreren Quellen mit unterschiedlichem Stand, modelliert das Projekt den Widerspruch nach statt das Produkt. Die Konsolidierung der Stammdaten ist Voraussetzung, nicht Projektergebnis.
• Ungeklärte Datenhoheit. Vier Abteilungen pflegen dasselbe Merkmal, oft unabhängig voneinander in eigenen Systemen, etwa in mehreren Excel-Tabellen mit unterschiedlichem Stand und Umfang. Niemand entscheidet, welcher Wert gilt. Nach dem Go-live driften die Systeme innerhalb weniger Monate auseinander.
• Produktregeln im Programmcode. Eine individuell gestaltete Konfigurationsanwendung ist kein Problem. Ein Konfigurator darf so individuell sein wie das Produkt, das er abbildet, von der Corporate Identity bis zur Nutzerführung. Kritisch wird es, wenn Produktregeln direkt in die Anwendung programmiert werden. Oberfläche und Regelwerk gehören strikt getrennt, sonst wird jede Erweiterung zum Entwicklungsprojekt und jedes Release 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. Genauso zählt die Nutzerführung: Wer von Excel mit all seiner Freiheit auf eine Anwendung mit festen Abläufen wechselt, nimmt sie nur an, wenn diese Abläufe zu seiner Arbeitsweise passen.
• 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 ohne saubere Produktdaten scheitert

CPQ rechnet mit Merkmalen, Werten und Beziehungen. Es 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. Auch Viamedici hat mehrfach erlebt, dass Projekte daran scheiterten, weil Stammdaten nicht ausreichend konsolidiert werden konnten. Abhilfe schafft eine Projektleitung, die alle Beteiligten zusammenbringt, die Bedeutung der Produktdatenqualität vermittelt und die nächsten Schritte verbindlich klärt.

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.

In Viamedici-Projekten liefert häufig unser PIM-System die Datenbasis, weil dort viele der benötigten Informationen bereits vorliegen. Zwingende Voraussetzung ist es nicht. Unsere CPQ Software setzt auf der vorhandenen Datenbasis auf, und fehlende Informationen lassen sich im PIM oder direkt in der CPQ-Plattform ergänzen. Das Regelwerk selbst liegt selten im PIM. Dort sind aber häufig schon Produktbeziehungen hinterlegt, die automatisch importiert und als Grundlage des Regelwerks genutzt werden. In der CPQ-Lösung kommen dann etwa technische Regeln aus der Konstruktion hinzu. 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. Ein CPQ, das 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:

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 ist kein Werkzeug, das einen unstrukturierten Vertriebsprozess sortiert. Es ist der kaufmännische Aufbau auf konsolidierten Stammdaten 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 konsolidiert sind unsere Stammdaten, wer besitzt welche Datenklasse, 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.