„An der Regel können wir heute nichts ändern – nur Johan weiß, wie die funktioniert.“ Diesen Satz habe ich in zu vielen Lenkungsausschüssen gehört. Ein einzelner Experte wird zum Flaschenhals, der Backlog wächst und die Vertriebsteams arbeiten still und leise am System vorbei.
Wenn der CPQ-Prozess von einer Handvoll technischer Modellierer abhängt, verlangsamt sich alles. Nicht weil die Menschen langsam wären, sondern weil die Arbeit von Fähigkeiten abhängt, die Product Owner nicht haben und auch nicht brauchen sollten. Diejenigen, die das Produkt am besten kennen, können ihr Wissen nicht direkt im System abbilden.
Wenn Ihr CPQ-System auf einzelne Helden angewiesen ist, haben Sie kein System – Sie haben einen Engpass.
Der versteckte Flaschenhals, den Sie vermutlich tolerieren
Die meisten Teams schieben langsame Angebotsprozesse auf Daten, die Benutzeroberfläche oder mangelndes Training. Das ist nur die halbe Wahrheit. Die wahre Bremse ist, dass sich die Modellierung immer noch wie Programmieren anfühlt. Sie wollen eine einfache Abhängigkeit abbilden, und daraus wird ein Ticket, dann eine Übergabe und schließlich ein kleines Projekt. Währenddessen öffnet der Vertrieb wieder alte Excel-Tabellen, denn die funktionieren wenigstens sofort.
CPQ sollte schon immer für eine präzise Preisgestaltung über alle Optionen und Abhängigkeiten hinweg sorgen. Das Ziel war richtig. Das Problem liegt darin, wie wir die Regeln erfassen, die diese Genauigkeit erst ermöglichen.
Nicht Regeln sind das Problem, sondern starre Regeln.
Warum die Situation heute eine andere ist
Wir haben heute eine praxistaugliche Methode, um Produktwissen von der Implementierung zu entkoppeln. Ein Produktmanager kann schreiben: „Die Schlafkabine funktioniert nur mit dem Hochleistungsmotor.“ Das System übersetzt diesen Satz in die zugrunde liegende Abhängigkeitsregel und validiert sie sofort. Keine Syntax, kein Solver-Voodoo, keine Wartezeit.
Das verändert alles. Die Modellierung wird zu einem Gespräch in klarer Sprache. Produktexperten können selbstständig Regeln hinzufügen und testen und diese Änderungen über die etablierten Freigabeprozesse produktiv setzen. Das ist nicht nur schneller, sondern auch sicherer – weil die Validierung deterministisch und testbar ist.
Der Wert von CPQ bleibt oft auf der Strecke, weil das Wissen in den Köpfen von Spezialisten gefangen ist, anstatt in einem lebendigen, nachvollziehbaren Regelwerk zu stecken, das vom Fachbereich selbst gepflegt werden kann.
Klartext als Input, deterministische Logik als Output
So funktioniert das in der Praxis:
- Ein Product Owner schreibt eine Regel in natürlicher Sprache: „Die Schlafkabine funktioniert nur mit dem Hochleistungsmotor.“
- Das System interpretiert den Satz, erzeugt die Abhängigkeit im Konfigurationsmodell und führt sofort eine Validierung gegen die aktuelle Produktstruktur durch.
- Wenn die Regel einen Konflikt erzeugt, wird dieser sofort angezeigt – nicht erst drei Sprints später.
Es geht nicht darum, explizite Logik abzuschaffen. Es geht darum, dem Fachbereich zu ermöglichen, diese Logik in seinen Worten auszudrücken, und sie dann in saubere, testbare Regeln zu übersetzen. Die Leitplanken bleiben erhalten: Versionierung, Freigaben und eine kompakte Testsuite, die nach jeder Änderung sicherstellt, dass die Kernkonfigurationen noch funktionieren.
Es geht nicht darum, Urteilsvermögen zu automatisieren. Es geht darum, den Weg von der Produktidee zur umsetzbaren Regel zu verkürzen. Der Solver bleibt die letzte Instanz – das Sicherheitsnetz, das gewährleistet, dass alles, was das Haus verlässt, baubar, bepreisbar und lieferbar ist.
Nachvollziehbarkeit schafft Vertrauen. Wenn das System seine Entscheidungen nicht erklären kann, wird der Vertrieb dem Ergebnis nicht trauen.
Fünf Prinzipien für diesen Ansatz
1) Eine Regel, ein Satz. Halten Sie jede Regel atomar und lesbar. „Wenn Kundensegment = Kommunal, dann standardmäßig Edelstahl.“ Wenn ein Satz zu lang wird, teilen Sie ihn in zwei Regeln auf. Kleine Regeln lassen sich besser kombinieren und testen.
2) Kontext als feste Eingangsgröße. Listen Sie nicht nur Merkmale auf, sondern beschreiben Sie, wann und warum eine Variante die richtige Wahl ist. Eine kurze Begründung wie „Schlafkabine empfohlen für Fernverkehr mit Übernachtungen“ verbessert die Systemlogik und die Nachvollziehbarkeit. Außerdem erleichtert es das Onboarding neuer Vertriebsmitarbeiter.
3) Validierung beim Schreiben, nicht erst im Test. Sobald jemand eine Regel hinzufügt, sollte sie deterministisch gegen ein Set von Kerntests geprüft werden: die Top-20-Konfigurationen, die zehn wichtigsten Preisstaffeln und bekannte Grenzfälle. Finden Sie Fehler an der Tastatur, nicht Wochen später in einem Testzyklus.
4) Eine lebende Testsuite parallel zu den Regeln pflegen. Jeder gefundene Fehler wird zu einem neuen Test. Jede kritische, verkaufbare Kombination wird zu einem Test. Mit der Zeit wird diese Suite zu Ihrer Leitplanke und zur Grundlage für stabile Releases.
5) Schluss mit dem „Helden-Modellierer“-Antimuster. Übertragen Sie die Verantwortung an Produktmanagement und Sales Operations. Technische Experten werden zu Unterstützern und Prüfern, nicht zu Blockierern. Wenn eine Regel Produktwissen statt Programmierkenntnisse erfordert, sollte das Produktteam sie schreiben.
Von Lean-Gerede zu gelebter Praxis
Lean ist kein Poster, sondern die Beseitigung von Verschwendung. Verschwendung im CPQ-Prozess sind Übergaben, Warteschlangen und Nacharbeit. Wenn Product Owner Regeln direkt formulieren können, entfallen zwei der schlimmsten Übeltäter: die Ticket-Warteschlange und die Übersetzung zwischen Fachbereich und IT.
Zuverlässigkeit ist die Basis, aber ohne Geschwindigkeit gewinnt man keine Aufträge. Wir brauchen beides: ein stabiles Fundament und schnelle Anpassungsfähigkeit.
Konkrete Beispiele für die Praxis
Präferenzregel mit Begründung: „Für Fernverkehr Schlafkabine bevorzugen; Begründung: ‚Nachtruhe, Lärmschutz, Fahrerkomfort‘.“ Das System wendet nicht nur die Präferenz an, sondern macht die Erklärung in der Oberfläche und im Angebot sichtbar.
Kompatibilitätsregel: „Die Schlafkabine ist nur mit dem Hochleistungsmotor kombinierbar.“ Die Abhängigkeit wird erzwungen. Versucht ein Vertriebler den Kleinmotor, erhält er eine klare, verständliche Meldung statt einer kryptischen Fehlermeldung.
Kommerzielle Leitplanke: „Wenn Rabatt auf Premium-Service > 15 %, Freigabe durch Vorgesetzten erforderlich.“ Der Fachbereich schreibt die Richtlinie, das System setzt sie um und steuert den Freigabeprozess.
Blockieren Sie Fehler frühzeitig – anstatt sie später aufzuräumen.
Was sich ändert, wenn Product Owner modellieren können
Weniger Workarounds. Wenn Änderungen wöchentlich statt quartalsweise live gehen, hört der Vertrieb auf, Excel-Listen zu horten. Das System wird zum schnellsten Weg für ein korrektes Angebot.
Sauberere Governance. Change Control bleibt, aber der Zyklus dauert Tage statt Monate. Die Klartext-Regel prüfen, die betroffenen Tests einsehen, freigeben. Fertig.
Besseres Onboarding. Neue Vertriebsmitarbeiter lernen die Produktoptionen mit integrierten „Warum“-Erklärungen. Es ist, als hätten Sie Ihren besten Produktexperten in jedem Gespräch dabei – ohne ihn einplanen zu müssen.
Höheres Vertrauen. Wenn ein System seine Entscheidungen erklären kann, folgt die Akzeptanz. Und Akzeptanz ist die einzige Kennzahl, die am Ende zählt.
Was Sie in diesem Quartal tun können
1) Starten Sie ein Zwei-Wochen-Pilotprojekt für eine Produktlinie. Wählen Sie ein Produkt mit 15-30 Modulen. Bitten Sie die Product Owner, 50 Regeln in einfacher Sprache zu formulieren, jede in einem Satz. Bauen Sie eine minimale Testsuite auf und messen Sie zwei Dinge: die Dauer bis zur Umsetzung einer Änderung und die Nutzung durch den Vertrieb.
2) Etablieren Sie eine „Regel-Hygiene“. Definieren Sie kurze Stilrichtlinien: ein Satz pro Regel, aktive Sprache, „Warum“-Notizen unter 20 Wörtern, obligatorische Sofortvalidierung. Jeder Fehler wird innerhalb von 24 Stunden zu einem neuen Test.3) Definieren Sie die Verantwortlichkeiten neu. Das Produktmanagement ist Autor, Sales Operations ist Publisher und technische Experten sind Prüfer. Wenn eine Änderung länger als zwei Tage bei einer Person liegt, ist das ein Prozessproblem, das behoben werden muss – kein Eskalationsfall.
Dies ist kein Big-Bang-Projekt. Es ist eine Verhaltensänderung. Die Technologie beseitigt nur die Hürden, damit sich das richtige Verhalten durchsetzen kann.
Ein letzter Punkt: Natürliche Sprache ist der Einstieg, nicht das Ziel. Der Solver und die Tests bleiben die Leitplanken. Diese Kombination funktioniert: schnelle Abbildung der Absicht und die Sicherheit, dass das Ergebnis korrekt ist.
Wenn Ihre Produktexperten die Regel formulieren können, sollten sie auch für die Regel verantwortlich sein. Ihr System sollte die Übersetzung, die Validierung und die Erklärung übernehmen – jedes Mal.
Wer jetzt umsteigt, wird es an kürzeren Durchlaufzeiten und größerem Vertrauen spüren. Wer wartet, wird weiter Tickets an einen schrumpfenden Pool von Spezialisten verteilen und sich wundern, warum das CPQ-System auf dem Papier gut aussieht, aber im Vertrieb nie richtig ankommt.
Solange die Modellierung auf Spezialisten angewiesen ist, bleibt die Geschwindigkeit Ihres Vertriebs begrenzt.
Kommentare
Kommentar veröffentlichen