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.
5. Dokumente richtig mitdenken
Das Angebotsdokument ist das Einzige, was der Kunde sieht. Wenn Konfiguration und Preis stimmen, aber das erzeugte PDF unvollständig oder in der falschen Sprache ist, hat das System sein Ziel verfehlt. Dokumentlogik ist in vielen CPQ-Projekten ein nachrangiges Thema. Das rächt sich. Was vorab definiert sein muss: Welche Informationen erscheinen in welchem Dokumenttyp? Welche Sprachen? Welche rechtlichen Pflichtangaben? Diese Anforderungen gehören in die Konzeptphase.
6. Verantwortlichkeit absichern
Ein CPQ-System ist kein Projekt, das irgendwann abgeschlossen ist. Es ist ein lebendes System, das dauerhaft gepflegt werden muss, mit klaren Rollen. Bewährt hat sich eine Struktur mit drei Perspektiven: fachliche Key User für Konfigurationsregeln und Preislogik, Administratoren für Systemänderungen und eine Governance-Instanz, die entscheidet, welche Regeländerungen wann ins System kommen. Ohne Struktur entsteht Regelwildwuchs. Inkonsistenzen häufen sich, und irgendwann traut niemand mehr dem System.
7. Prozess für Änderungen
Produktvarianten ändern sich. Preise ändern sich. Märkte ändern sich. Ein CPQ-System, das diese Veränderungen nicht strukturiert verarbeiten kann, wird zur Bremse. Regeländerungen sind technisch komplexer, als sie aussehen. Eine einzelne Preisregel besteht aus mehreren verknüpften Datenobjekten. Wer ändert, ohne Abhängigkeiten zu kennen, riskiert Folgefehler, oft ohne sofort sichtbare Fehlermeldung. Der Fehler taucht dann im nächsten Kundenangebot auf. Best Practice ist eine strukturierte Deployment-Pipeline: Änderungen werden in einer Sandbox entwickelt, automatisierte Regressionstests prüfen bestehende Szenarien, dann geht die Änderung in Produktion. Keine Änderung ohne Test, kein Go-live ohne Monitoring.
Ein dauerhafter Prozess
Die Einhaltung dieser sieben Regeln scheitert meist nicht an der Technologie, sondern an der Organisation. CPQ-Projekte, die funktionieren, haben eines gemeinsam: Die beteiligten Unternehmen haben verstanden, dass sie keinen Software-Rollout steuern, sondern ihre eigene Angebotslogik gestalten. Das System ist das Ergebnis dieser Arbeit. Nicht ihr Ersatz.
