Configure, Price, Quote. Drei Wörter, die klingen, als wäre das Problem damit beschrieben und gelöst. Ist es nicht. Ein CPQ-System automatisiert die Angebotserstellung für konfigurierbare Produkte. Es steuert, welche Optionen kombinierbar sind, berechnet Preise nach definierten Regeln, löst Freigabeprozesse aus und erzeugt ein druckfertiges Angebotsdokument. Das funktioniert, wenn die Grundlagen stimmen. Und es ist teuer, wenn sie es nicht tun. Was in der Praxis immer wieder passiert: Unternehmen wählen eine Plattform, benennen einen Projektverantwortlichen und merken spätestens im dritten Projektmonat, dass niemand vorher sauber definiert hat, wie die eigene Konfigurationslogik funktioniert. Welche Varianten sind zulässig? Wer genehmigt welchen Rabatt? Wo liegen die Stammdaten, und wer ist verantwortlich? Das müssen Unternehmen wissen, möglichst früh. CPQ-Systeme sind Regelmaschinen. CPQ-Software führt aus, was ihr übergeben wird. Die Intelligenz kommt nicht aus dem System, sie muss hineingebracht werden. Folgende sieben Faustregeln haben sich aus den Erfahrungen zahlreicher Projekte verdichtet.
1. Erst Variantenmodell klären
Bevor eine einzige Konfigurationsregel eingepflegt wird, muss das Variantenmodell dokumentiert sein. Nicht als Produktkatalog, sondern als logisches Regelwerk: Welche Merkmalskombinationen sind technisch zulässig, welche nicht? Dieses Wissen steckt in der Praxis oft in Köpfen erfahrener Vertriebsingenieure, in Excel-Tabellen, die niemand mehr vollständig versteht, oder in ERP-Konfigurationen, die historisch gewachsen sind. Ein CPQ-Projekt zwingt dazu, dieses implizite Wissen explizit zu machen. Ein häufiger Fehler: Regelhierarchien werden nicht getrennt. Globale Produktregeln, regionale Compliance-Anforderungen und kundenspezifische Sondervereinbarungen landen im selben Regelwerk. Das macht das System schwer wartbar.
2. Preislogik ohne Tabellen
Viele Unternehmen starten mit der Vorstellung, ihre Preistabellen ins System zu übertragen. Das greift zu kurz. Preislogik in CPQ ist mehrstufig: Listenpreisermittlung, kundenspezifische Konditionen, Rahmenverträge, Mengenrabatte, bis zum kalkulierten Angebotspreis im Freigabeprozess. Dieses Konstrukt nennt sich Preiswasserfall. Wer ihn nicht explizit modelliert, verliert die Kontrolle über Margen. Entscheidend ist die Trennung von Preislogik und Preisdaten. Die Rechenregeln gehören ins CPQ. Die Daten (Einkaufspreise, Konditionssätze, Währungskurse) kommen aus dem ERP und müssen aktuell sein. Systeme ohne direkte ERP-Anbindung arbeiten mit Datenkopien, die veralten und zu Fehlkalkulationen führen. Zwei Vertriebsmitarbeiter, zwei Tabellenversionen, zwei verschiedene Preise für denselben Kunden. Das passiert. CPQ löst dieses Problem, aber nur, wenn die Preislogik vollständig modelliert ist.
3. Freigaben ins System
Wer entscheidet, ab welcher Rabatttiefe ein Angebot freigegeben werden muss? Was passiert, wenn der Vertriebsleiter nicht erreichbar ist? Diese Fragen klingen nach Organisation. Sind sie auch. Aber sie müssen technisch abgebildet sein. Freigabeprozesse in CPQ-Software funktionieren über regelbasierte Workflow-Engines: Jede Genehmigungsanfrage erzeugt eine Prozessinstanz mit definierten Statusübergängen, Eskalationspfaden und Zeitlimits. Das schützt Margen und macht Compliance-Anforderungen erfüllbar. Oft fehlt in der Praxis eine Eskalationslogik. Was passiert, wenn niemand innerhalb von 24 Stunden genehmigt? Diese Szenarien müssen vor der Implementierung durchgespielt sein.
4. Datenhoheit klären
Das ERP-System enthält Stammdaten, CRM-Software die Kundendaten, das PLM-Tools die Produktstruktur – das CPQ-System soll alles zusammenbringen. Wenn diese Systeme nicht sauber integriert sind, entstehen Dateninseln. Aus Dateninseln entstehen inkorrekte Angebote. Die Frage der Datenhoheit ist keine IT-Frage, sie ist eine Governance-Frage. Wer ist verantwortlich für die Korrektheit der Produktdaten? Wer pflegt Preislisten? Ohne klare Antworten entsteht ein Zustand, in dem alle auf andere zeigen, wenn ein Angebot falsch ist. Die Architekturentscheidung, welches System die führende Datenquelle ist, muss vor der Implementierung stehen.
