Der Anruf vom Händler läuft jedes Mal gleich ab: eine vage Opportunity und vier Produktfamilien, die sich überlappen und alle passen, bis sie es dann doch nicht tun. Die Masken im Guided Selling sind starr, der Rückstau bei der Modellpflege ist länger als das Quartal. Jemand sagt: „Die Daten sind im PLM“, und alle nicken, als würde das irgendetwas beschleunigen.
Spätestens im zweiten Meeting beginnt die Debatte: Holen wir für drei bis sechs Monate einen Berater, der das Projekt durchzieht? Oder investieren wir langfristig, bauen Know-how auf und schaffen die Kompetenz, die wir angeblich wollen?
Währenddessen läuft das Angebotsgeschäft weiter. Das System funktioniert – nur eben langsam.
Engpass ist nicht das Regelwerk
Den meisten CPQ-Teams fehlt es nicht am richtigen Tool, sondern an der Fähigkeit, Produktwissen effektiv zu nutzen. Die Symptome sind Verzögerungen in der Modellierung, unlogische Fragebögen und inkonsistente Empfehlungen je nach Region. Die Ursache ist simpel: Das entscheidende Produktwissen ist im Unternehmen verstreut – nur nicht dort, wo es für den Verkauf gebraucht wird.
Es steckt in Zeichnungen und Katalogen, die nie für Abfragen gedacht waren. Es steckt in historisch gewachsenen PLM-Ansichten, die 2005 für Ingenieure gebaut wurden und 2026 immer noch unentbehrlich sind. Es steckt in den Angeboten der letzten vier Jahre, die genau verraten, was warum verkauft wurde – wenn sich nur jemand die Mühe machte, hinzuschauen.
Wir behandeln CPQ wie ein IT-Projekt, nicht wie ein Wissenssystem, das gepflegt werden muss. Deshalb wird jede „Optimierung“ des Guided Selling zu einem aufwendigen Übersetzungsprojekt – und ist schnell überholt, sobald sich das Portfolio ändert.
Wer in sechs Monaten ein Ergebnis will, holt sich einen Berater. Wer in drei Jahren die Kompetenz im Haus haben will, muss jetzt in die eigene Analyse investieren.
Was sich in CPQ-Teams wirklich ändert
Die erfolgreichen Teams warten nicht auf das nächste Release ihres Softwareanbieters oder einen perfekten Data Lake. Sie ändern die Art und Weise, wie sie Produktwissen aufbauen und pflegen.
Sie nutzen Large Language Models (LLMs) als Beschleuniger, nicht als Orakel. Der Kern – harte Constraints, Kompatibilität, Sicherheitsregeln – bleibt symbolisch im Regelwerk. Die weiche Ebene – das Klären von Mehrdeutigkeiten, Erklärungen, das Vorschlagen von Prioritäten – wird von Sprachmodellen übernommen. Das Ergebnis ist ein Guided-Selling-Prozess, der in natürlicher Sprache argumentieren kann, aber die harten Geschäftsregeln des Produktmodells respektiert.
Sie versuchen nicht mehr, jede Nuance in Regeln zu pressen. Nicht jedes Detail ist kritisch. Das Team konzentriert sich darauf zu entscheiden, was eine Regel *verdient*.
Sie generieren Modelle direkt aus vorhandenen Unterlagen. Technische Broschüren liefern Kandidaten für Attribute. Historische Angebote zeigen Muster für Kompromisse bei der Konfiguration. E-Mails von Händlern signalisieren, wo der Fragebogen verwirrt. Zeichnungen sind keine Anhänge mehr, sondern Input.
Und sie behandeln Guided Selling als ein lernendes System. Fragen erscheinen in der richtigen Reihenfolge, weil das System lernt, was am schnellsten zu einer gültigen Konfiguration führt. Das Ergebnis ist unauffällig, aber wirksam: Die Zeit bis zum ersten gültigen Angebot verkürzt sich spürbar.
Wie das Hybridmodell praktisch funktioniert
Dahinter steckt keine Magie. Ein pragmatischer Ansatz sieht so aus:
- Die Kernlogik bleibt symbolisch. Kompatibilitäts-, Sicherheits- und Kostenregeln bleiben dort, wo sie hingehören: in einer Rules Engine oder einem Konfigurator, der für ihre Durchsetzung gebaut wurde.
- Sprache interpretiert die Absicht. Eine schlanke Schicht aus Sprachverarbeitung interpretiert Freitext, Broschüren oder Zeichnungen und schlägt daraus Attributwerte und Optionen vor – klar, kontextbezogen und nachvollziehbar wie ein erfahrener Vertriebsingenieur.
- Ein Mapping sorgt für Konsistenz. Die Vorschläge des Sprachmodells werden auf die offiziellen Attribute und Werte des Produktmodells abgebildet. Jeder Verstoß gegen die Kernlogik wird blockiert und erklärt, nicht versteckt.
Der eigentliche Wandel ist organisatorisch: Das Team wird vom reinen Regel-Pfleger zum Orchestrator des Produktwissens. Anstatt das System auszutauschen, reduziert man die Hürden, um Produktwissen schnell in den Angebotsprozess zu bringen – in Wochen statt in Quartalen.
Warum dieser Moment entscheidend ist
Zwei Dinge haben sich gleichzeitig geändert. Erstens sind die Kosten für Experimente drastisch gesunken. Einen geführten Prozess, der auf einem Sprachmodell basiert und im symbolischen Regelwerk verankert ist, kann man heute innerhalb eines Sprints testen. Man braucht dafür keine perfekte PLM-Migration, sondern einen klaren Anwendungsfall und den Mut, den Erfolg zu messen.
Zweitens hat die Menge an „gefangenem“ Wissen in Altsystemen einen kritischen Punkt erreicht. PLM-Ansichten, die vor 20 Jahren sinnvoll waren, enthalten heute die einzig verlässliche Definition bestimmter Module. Angebotsarchive umfassen Tausende Konfigurationen. Sprachmodelle machen diese Inhalte erstmals systematisch auswertbar.
Das ist der Hebel: Orchestrierung statt Komplettaustausch. Man lässt die bestehenden Systeme tun, was sie gut können, und legt eine flexible Schicht darüber, die übersetzt, vorschlägt und lernt.
In Kompetenz investieren, nicht nur in Ergebnisse
Kompetenz entsteht nicht durch den Kauf eines Tools. Sie wächst, weil Mitarbeiter im Kontext der realen Arbeit lernen, ausprobieren und nachsteuern können. Erfolgreiche Programme setzen daher auf interne Prototyping-Gruppen oder F&E-Kooperationen.
Berater liefern schnell Ergebnisse. Interne Analyse hingegen verbessert, wozu Ihre Mitarbeiter morgen in der Lage sind. Die besten Teams kombinieren beides: Prototyp bauen, lernen, verfeinern – und dann die Implementierungspartner für die Skalierung holen. Dann weiß man aber, was sich zu skalieren lohnt, und gibt kein sechsstelliges Budget für Regeln aus, die niemand braucht.
Ein Jahr Reibungsverluste durch ein fehlgeleitetes Guided-Selling-Projekt kann so viel kosten wie drei Jahre interner Kompetenzaufbau. Der Unterschied ist, was man am Ende besitzt: eine dauerhafte Fähigkeit, nicht nur ein Projektergebnis.
Der Zinseszinseffekt der Kompetenz
Der Erfolg zeigt sich nicht in einem großen Launch, sondern in der stillen Summe kleiner Vorteile:
- Schnellere Modellerstellung, weil der erste Entwurf aus Broschüren und alten Angeboten entsteht und Experten nur noch korrigieren, anstatt bei null anzufangen.
- Besseres Guided Selling, weil das System den kürzesten Weg zur gültigen Konfiguration lernt und Kompromisse in normaler Sprache erklärt.
- Klarheit im Portfolio, weil Überlappungen im Verkaufsprozess sichtbar werden, nicht erst im Lenkungsausschuss. Redundanzen werden mit Daten statt Meinungen beseitigt.
- Vertrauen der Vertriebspartner, weil das Werkzeug ihnen hilft, sichere Entscheidungen zu treffen, statt nur ein Formular auszufüllen.
Die Alternative ist leiser, aber härter: Es werden immer mehr Regeln hinzugefügt, um Sonderfälle zu beheben. Fragebögen werden länger. Regionale Teams bauen eigene Excel-Lösungen. Preisfreigaben nehmen zu, weil das Risiko wächst, wo die Klarheit fehlt.
Wie anfangen – ohne auf eine neue Plattform zu warten
Nehmen Sie sich eine Produktfamilie vor, bei der es bekanntermaßen die meisten Unklarheiten gibt. Analysieren Sie die Angebote der letzten zwei Jahre und einige E-Mails von Händlern. Definieren Sie die drei Entscheidungen, die Kosten und Kompatibilität am stärksten beeinflussen. Bauen Sie einen Prototyp, der diese Entscheidungen vorschlägt, sie den offiziellen Attributen zuordnet und zur Validierung an den bestehenden Konfigurator übergibt. Messen Sie die Zeit bis zum gültigen Angebot, die Anzahl der Rückfrageschleifen und die Abschlussquote.
Parallel dazu beauftragen Sie jemanden, Attribute und Regeln direkt aus bestehenden Unterlagen zu extrahieren. Behandeln Sie diesen ersten Entwurf als Korrekturvorlage, nicht als endgültige Wahrheit. Sie werden lernen, wo Ihr Wissen wirklich steckt – und auch, was keine Regel braucht.
Wenn dafür die internen Ressourcen fehlen, ist das das Signal, eine Kooperation für den Kompetenzaufbau zu starten. Ziel ist kein Whitepaper, sondern eine Fähigkeit: schnellere Modelle, bessere Produktführung, klarere Portfolios.
Früher oder später werden Sie trotzdem einen Berater engagieren. Aber dann aus einer besseren Position, mit einem klareren Auftrag und einem Team, das bereit ist, das Ergebnis zu übernehmen.
Die Frage ist nicht, ob Sprachmodelle CPQ verändern werden. Sie tun es bereits. Die Frage ist nur, ob Sie Geschwindigkeit weiterhin nur einkaufen oder anfangen, sie selbst aufzubauen. Welche Strategie wird in drei Jahren die offensichtlich richtige sein?
Kommentare
Kommentar veröffentlichen