Brauchen Sie wirklich SAP CPQ? Eine ehrliche Entscheidungshilfe neben S/4HANA Public Cloud

Kaum ein SAP-Produkt landet so schnell auf der Shortlist wie CPQ. Der Vertrieb wünscht sich schnellere Angebote, der Lizenzberater nickt, und plötzlich steht ein zusätzliches Produkt im Zielbild, bevor jemand gefragt hat, welches Problem es lösen soll. Dabei ist die Frage selten, ob SAP CPQ gut ist. Es ist gut. Die Frage ist, ob Ihr Angebotsprozess die Maschine braucht, die Sie damit einkaufen. Aus unseren Projekten rund um S/4HANA Public Cloud und Sales Cloud V2 wissen wir: In etwa der Hälfte der Fälle lautet die ehrliche Antwort nein. Dieser Beitrag ist die Entscheidungshilfe, die wir uns zu Beginn mancher Evaluation gewünscht hätten.

Was SAP CPQ wirklich ist

CPQ steht für Configure, Price, Quote. Das Produkt liefert diese drei Buchstaben in industrieller Ausbaustufe:

• Guided Selling: Der Verkäufer wird per Fragenkatalog zum passenden Produkt geführt, statt sich durch Kataloge zu klicken. Wertvoll, wenn das Sortiment so breit ist, dass auch erfahrene Vertriebler nicht jede Kombination kennen.
• Komplexe Regelwerke: Kompatibilitätsregeln und Constraints über Komponenten hinweg. Wenn Motor X, dann nie Getriebe Y; wenn Spannungsvariante A, dann Pflichtzubehör B. Das Regelwerk verhindert, dass technisch unmögliche Angebote das Haus verlassen.
• Mehrstufige Freigabematrizen: Rabattschwellen mit sauberem Workflow. Bis 5 Prozent entscheidet der Verkäufer, bis 12 der Vertriebsleiter, darüber die Geschäftsleitung, alles protokolliert.
• Angebotsdokumente: Gebrandete Proposals mit Textbausteinen, Bildern und Konditionsübersichten, generiert statt in Word zusammengebastelt.
• Channel- und Partnervertrieb: Portale, in denen Händler und Partner selber konfigurieren und offerieren, mit eigenen Preislisten und Sichtbarkeiten.

Das ist viel Maschine. Sie kostet Lizenz, Implementierung und laufende Pflege. Genau darum lohnt sich der nüchterne Blick, bevor die Unterschrift trocknet.

Der Entscheidungsbaum aus unseren Projekten

Über die Jahre hat sich bei uns ein einfacher Entscheidungsbaum herausgeschält. Er ist keine Wissenschaft, aber er hat sich in Projekten bewährt.

Kein CPQ, wenn alle drei Punkte zutreffen: weniger als etwa zehn Merkmale pro Produktfamilie, reiner Direktvertrieb ohne Händlerkanal, und Preise, die der Verkäufer manuell oder aus einer einfachen Richtpreislogik setzt. In dieser Konstellation ist ein schlankes Angebot im CRM plus Advanced Variant Configuration im ERP schneller live, günstiger im Betrieb und für den Aussendienst leichter zu lernen. Wie diese Architektur konkret aussieht, beschreibt unser Beitrag zur Variantenkonfiguration.

CPQ zahlt sich aus, sobald eines der folgenden Muster dominiert: Kompatibilitätsregeln, die sich nicht mehr in ein paar Merkmalen abbilden lassen. Ein Partner- oder Händlerkanal, der selbständig offerieren soll. Formale Rabattfreigaben, die heute per E-Mail und Zuruf laufen und regelmässig schiefgehen. Oder Angebotsdokumente, die ein Aushängeschild sein müssen, weil der Mitbewerber mit polierten Proposals antritt.

Die Grauzone dazwischen gibt es natürlich. Unser Rat dort: erst den schlanken Weg bauen, den Prozess sechs Monate messen, dann entscheiden. Ein CPQ lässt sich nachrüsten. Eine überdimensionierte Plattform wieder auszubauen ist ungleich schmerzhafter.

Das Integrationsbild, wenn CPQ gesetzt ist

Fällt die Entscheidung für CPQ, gehört es an eine klar definierte Stelle: zwischen Sales Cloud V2 und S/4HANA Public Cloud. Die Opportunity lebt im CRM. Aus ihr heraus entsteht das Angebot in CPQ, dort wird konfiguriert, bepreist und freigegeben. Der gewonnene Auftrag geht nach S/4HANA, wo Stückliste, Arbeitsplan und Fertigung übernehmen.

Zwei Punkte entscheiden über Erfolg oder Dauerbaustelle. Erstens die Variantenpreis-Synchronisation: Preise und preisrelevante Merkmalswerte müssen zwischen den AVC-Modellen in S/4HANA und CPQ abgeglichen werden, sonst offeriert der Vertrieb Preise, die die Kalkulation nie bestätigt. Zweitens, und wichtiger: Modellieren Sie dieselben Regeln niemals zweimal. Wer das komplette AVC-Regelwerk in CPQ dupliziert, pflegt ab Tag eins zwei Wahrheiten, die auseinanderlaufen. Entscheiden Sie pro Regeltyp, wo die Konfigurationswahrheit lebt: Verkaufslogik in CPQ, Fertigungslogik in AVC, und die Schnittstelle dazwischen so schmal wie möglich.

Drei Lektionen, die in keinem Datenblatt stehen

Aus Projekten, anonymisiert, aber real:

1. Rulebook-Governance ist der versteckte Kostenblock. Die Regeln zu bauen ist das kleinere Problem. Sie zu pflegen, wenn Produkte ändern, ist das grössere. Benennen Sie einen Owner, eine Person mit Namen, nicht ein Gremium, und setzen Sie einen quartalsweisen Review an. Ohne diesen Rhythmus veraltet das Regelwerk still, und der Vertrieb baut Umgehungen.
2. Freigabematrizen sollen die echte Unterschriftenregelung abbilden, nicht eine neue erfinden. Die Versuchung ist gross, mit dem Tool gleich die Kompetenzordnung zu reformieren. Widerstehen Sie ihr. Ein Workflow, der nicht der gelebten Praxis entspricht, wird umgangen, und dann haben Sie Lizenzkosten plus Schatten-Prozess.
3. Messen Sie die Angebotsdurchlaufzeit vorher und nachher. Von der Anfrage bis zum versandten Angebot, in Stunden. Ohne Vorher-Wert gibt es keinen Business Case, nur ein Bauchgefühl. Mit ihm sehen Sie nach sechs Monaten schwarz auf weiss, ob sich die Investition trägt.

Häufige Fragen

Kann CPQ gegen die Konditionen aus S/4HANA bepreisen?

Ja. CPQ kann Preisfindungslogik aus S/4HANA anbinden und Konditionen als Basis nutzen; alternativ hält es eigene Preislisten, die per Synchronisation aktuell bleiben. Wichtig ist die Grundsatzentscheidung, welches System preisführend ist. Zwei parallel gepflegte Preislogiken sind derselbe Fehler wie zwei Regelwerke.

Ersetzt CPQ die Advanced Variant Configuration?

Nein, die beiden ergänzen sich. CPQ verkauft: Guided Selling, Verkaufsregeln, Angebotsdokument. AVC fertigt: Super-Stückliste, Arbeitsplan, Kalkulation. Wer AVC abschalten will, weil CPQ da ist, verwechselt die Verkaufssicht mit der Fertigungssicht und holt sich das Problem in die Produktion.

Was ist ein realistischer Zeitplan für eine CPQ-Einführung?

Für eine erste Produktlinie mit sauberem Regelwerk und Anbindung an Sales Cloud V2 und S/4HANA Public Cloud rechnen wir mit vier bis sechs Monaten. Danach wächst das Modell Linie für Linie. Wer alle Produktfamilien im ersten Wurf modellieren will, plant de facto ein Mehrjahresprojekt und merkt es erst im zweiten Jahr.

Und wenn wir nur schnellere Angebote wollen, ohne den ganzen Apparat?

Dann ist der schlanke Weg meist der richtige: Angebot in Sales Cloud V2, Merkmale als Felder, Konfiguration erst im S/4HANA-Auftrag. Genau dieses Muster haben wir im erwähnten Beitrag zur Variantenkonfiguration beschrieben. CPQ können Sie immer noch nachrüsten, wenn der Händlerkanal oder das Regelwerk tatsächlich kommt.

Sie stehen vor genau dieser Entscheidung? Wir schauen uns Ihren Angebotsprozess an und sagen Ihnen ehrlich, ob CPQ die Lizenz wert ist, auch wenn die Antwort nein lautet. Sprechen Sie mit uns.