CPQ ist kein Konfigurator – sondern die fehlende Mitte zwischen CRM und ERP

Wenn Unternehmen variantenreiche Produkte verkaufen, entscheidet eine technische Wahrheit: CRM und ERP allein reichen nicht.

CRM versteht Kunden und Anforderungen, ERP versteht Stücklisten und Fertigung – aber keiner der beiden Bereiche entscheidet, was konfigurierbar, zulässig und produzierbar ist. Genau hier fehlt in vielen Architekturen die Mitte. CPQ füllt diese Lücke – nicht als Konfigurator, sondern als regelbasierte Entscheidungsschicht.

CRM weiß viel, aber nicht genug

Richtig läuft es, wenn CRM das liefert, wofür es gebaut wurde: Kundenkontext, Historien, Anforderungen, Chancen. Sobald CRM jedoch technische Validierung übernehmen soll, verliert der Prozess Stabilität. Variantenregeln, Produktabhängigkeiten und Freigaben benötigen Versionierung und Systematik, die CRM-Plattformen konzeptionell nicht leisten.

Ein stabiler Prozess entsteht erst, wenn CRM strukturiert übergibt, und CPQ ab diesem Übergabepunkt entscheidet, welche Variante technisch und kaufmännisch zulässig ist. 

ERP liefert Realität, aber kein Vertriebsmodell

ERP-Systeme funktionieren dann am besten, wenn sie ausschließlich geprüfte Daten erhalten: Artikel, Preise, Stücklisten, Fertigungsparameter.
Richtig läuft es, wenn CPQ das ERP vor unvollständigen oder unverifizierten Konfigurationen schützt und nur konsistente, vertriebsfähige Stücklisten übergibt.

Praxisbeispiele zeigen, wie wichtig die Systemtrennung ist: Siemens Energy und Bosch Rexroth arbeiten mit CPQ‑ERP‑PLM‑Integrationen, die durchgängige Variantendaten ermöglichen. Sobald hingegen versucht wird, CPQ‑Logik direkt ins ERP zu verlagern, verliert der Prozess spürbar an Beweglichkeit.

Was CPQ tatsächlich ist

Configure‑Price‑Quote, kurz CPQ, bezeichnet eine Systemklasse, die Produktvarianten prüft, Preise berechnet und vertriebsfertige Angebote erzeugt. Während Wikipedia CPQ als Software beschreibt, die Konfiguration, Preislogik und Angebotsdokumente zusammenführt, zeigt die Praxis im industriellen Umfeld: CPQ ist weniger ein Tool und mehr eine Entscheidungsschicht. Es validiert Regeln, wendet Abhängigkeiten an und sorgt dafür, dass Vertriebsentscheidungen technisch und kaufmännisch konsistent bleiben.

Der wahre Engpass: implizites Wissen

Stabile CPQ-Prozesse basieren auf klaren, dokumentierten Regeln. In der Praxis steckt jedoch ein großer Teil der Produktlogik in Köpfen, Tabellen oder historischen E-Mails. Richtig läuft es, wenn dieses Wissen systemfähig gemacht wird, bevor Modellierung beginnt. Viele Praxisbeispiele zeigen klar: Datenqualität und Schnittstellen sind die größten Bremsfaktoren, nicht die Software.

Zur Einordnung:
Viele CPQ-Hersteller berichten, dass 80 Prozent des Modellierungsaufwands in den seltensten 20 Prozent der Konfigurationen stecken (Herstellerangabe, z. B. Tacton). Für die gängigen Varianten dagegen entsteht vergleichsweise wenig Aufwand. Das deckt sich mit der Praxis, ohne dass es eine harte wissenschaftliche Quelle dafür gäbe.

CPQ ist kein IT-Projekt, sondern ein Architekturprojekt der Fachbereiche

Erfolgreiche Unternehmen führen CPQ nicht als Software ein, sondern als fachliche Infrastruktur. Richtig läuft es, wenn:

• Vertrieb, Produktmanagement, Konstruktion und Kalkulation gemeinsam definieren, was erlaubt ist. 
• Price Governance festlegt, welche Rabatte und Freigaben gelten. 
• PLM und ERP die technischen und produktionsseitigen Wahrheiten liefern. 
• IT die Plattform stellt, aber nicht die Regeln.

Viele ausgewertete Beispiele zeichnen ein klares Bild: Die größten Hürden liegen in Datenqualität, Versionierung und Integrationslogik, also in fachlicher Verantwortung, nicht in der Implementierung. Aussagen wie „CPQ-Projekte scheitern selten an Software“ sind deshalb als Praxisbeobachtung zu verstehen, nicht als statistische Wahrheit.

Die typischen Fehlannahmen bei CPQ‑Projekten

1. „Die Regeln kennen wir.“
   In vielen Unternehmen existieren Regeln nur als Erfahrungswissen Einzelner, oft widersprüchlich und selten dokumentiert. Sobald CPQ dieses Wissen in testbare Logiken überführt, zeigt sich, dass „wir wissen das schon“ häufig nur für die Standardfälle stimmt. Für Grenzfälle, Ausnahmen und kundenspezifische Varianten fehlen meist klare Definitionen. Genau hier entstehen die meisten Verzögerungen.
   
2. „ERP‑Variantenlogik reicht aus.“
   Die Variantenlogik im ERP ist für die Fertigung gebaut: stabil, präzise, versioniert. In der Angebotsphase braucht der Vertrieb jedoch Beweglichkeit. Er muss Szenarien durchspielen können, ohne direkt neue Materialnummern oder Stücklisten zu erzeugen. Wer versucht, den Vertriebsprozess komplett ins ERP zu verlagern, blockiert sowohl Vertrieb als auch Technik.
   
3. „CPQ ist ein Konfigurator mit schönerer Oberfläche.“
   In der Oberfläche mögen sich CPQ und Konfigurator ähneln. Der Unterschied liegt darunter: Ein Konfigurator blendet Auswahlmöglichkeiten ein oder aus. CPQ prüft technische Abhängigkeiten, kalkuliert Preise, löst Freigaben aus und generiert vollständige Vertriebsstücklisten. Viele Projekte scheitern genau deshalb: Man kauft „UI“ – gebraucht wird aber eine Entscheidungsmaschine.

Was erfolgreiche CPQ-Projekte gemeinsam haben

Unternehmen, die CPQ nachhaltig nutzen, berichten übereinstimmend – basierend auf Fallstudien, nicht auf repräsentativen Erhebungen:

• Kürzere Angebotszeiten:
  • Handtmann: –50 % Angebotszeit (Herstellerangabe, Elfsquad). 
  • camos-Kunden: ca. –30 % Angebotszeit (Herstellerangabe). 
  • Hive CPQ: „bis zu –70 %“ (Herstellerangabe).
• Höhere Trefferquoten:
  +30 % Hit-Rate laut camos (Herstellerangabe).
• Stabilere Abläufe durch klare Systemrollen.

Diese Zahlen zeigen ein konsistentes Muster: Geschwindigkeit entsteht, wenn CPQ nicht als UI-Projekt verstanden wird, sondern als verbindliche Entscheidungsschicht.

Warum CPQ heute unverzichtbar geworden ist

Unternehmen mit variantenreichen Produkten brauchen ein System, das Vertrieb schnell macht – und das Unternehmen vor falschen Entscheidungen schützt.
Richtig läuft es, wenn CPQ diese Mitte bildet: zwischen CRM und ERP, zwischen Anforderungen und Machbarkeit, zwischen Vertrieb und Produktion.

Ein Konfigurator unterstützt Auswahl.
CPQ steuert Entscheidungslogik. 

Genau deshalb ist CPQ kein Konfigurator, sondern der Angebotsmotor, der Komplexität systemfähig macht und Variabilität in kontrollierbare Bahnen bringt.

Fazit

CPQ schließt genau die Lücke, die zwischen CRM und ERP entsteht. CRM versteht den Kunden, ERP versteht die Produktion, aber keiner der beiden Bereiche entscheidet, was technisch zulässig, kaufmännisch sinnvoll und organisationsweit konsistent ist.

Ein Konfigurator kann diese Aufgabe nicht übernehmen, weil er nur Optionen darstellt. CPQ dagegen operationalisiert Regeln, sorgt für Verbindlichkeit und überführt Anforderungen in belastbare Konfigurationen und Stücklisten.

Damit wird CPQ zur fehlenden Mitte zwischen Vertrieb und Fertigung, und zum System, das variantenreiche Angebotsprozesse erst stabil und skalierbar macht.