DWC Insight 207 · Executive Decision Guide

S/4HANA-Migration und CPQ: Zwei Zielarchitekturen statt einer Standardantwort

Wie Produktlogik, Konfigurationsebenen, Performance und Pricing die künftige CPQ-Rolle bestimmen

Eine S/4HANA-Migration ist der richtige Zeitpunkt, bestehende Konfigurationsmodelle, Laufzeiten und Systemrollen neu zu prüfen. Die Antwort lautet weder pauschal „CPQ behalten“ noch „alles nach SAP“: Sie fällt nach Produktbereich und Aufgabenprofil unterschiedlich aus.

Executive Summary

Nicht das Systemetikett, sondern die dauerhaft benötigte Aufgabe entscheidet.

Die S/4HANA-Migration entscheidet nicht pauschal über CPQ. Das Aufgabenprofil des jeweiligen Produktbereichs bestimmt die künftige Systemrolle; bestehende Modelle sind deshalb nicht automatisch 1:1 zu übernehmen.

Fall A zeigt einen CTO-nahen Bereich mit SAP-geführter Konfiguration, schlankem Web-Frontend, Visualisierung und beherrschbarem Pricing. Ein zusätzliches CPQ war nicht erforderlich.

Fall B zeigt eine differenzierte Lösung: direkter SAP-Ansatz für standardisierte Bereiche, CPQ für komplexere Maschinen mit Lösungsbildung, Ausnahmen und anspruchsvollerer Angebots- und Preislogik.

Gezielte Modellanpassung und die Trennung von Vertriebs- und Ausführungskonfiguration schaffen die Grundlage für klare Laufzeiten, Übergaben und Verantwortungen.

Performance und Pricing sind keine nachgelagerten IT-Details. Sie entscheiden mit darüber, welche Konfigurationsebene wo verarbeitet wird und ob CPQ eine dauerhafte Aufgabe hat.

Ziel ist nicht die geringste Zahl an Systemen, sondern die geringste dauerhaft beherrschbare Komplexität bei vollständiger Aufgabenabdeckung.

Gleicher Transformationsanlass, unterschiedliche Antwort

Eine S/4HANA-Migration ist für variantenreiche Unternehmen mehr als ein technischer Plattformwechsel. Sobald bestehende LO-VC-Modelle überprüft, für AVC vorbereitet oder in neue Laufzeiten überführt werden, stellt sich auch die Architekturfrage neu: Welche Logik bleibt führend, welche Konfigurationsebene wird wo verarbeitet – und braucht der Vertrieb danach noch ein eigenständiges CPQ?

Die pauschale Frage „SAP oder CPQ?“ führt in der Praxis zu kurz. Sie vermischt technische Produktkonfiguration, interaktive Vertriebsführung, Performance, Preisfindung und Angebotsorchestrierung. Dadurch entstehen zwei typische Fehlentscheidungen: Ein vorhandenes CPQ bleibt ohne neu begründete Aufgabe bestehen – oder es wird abgeschafft, obwohl seine Aufgaben in der Zielarchitektur weiterhin benötigt werden.

Zwei anonymisierte Projekte aus dem Maschinen- und Anlagenbau zeigen die sinnvollere Vorgehensweise. Im ersten Fall wurden Konfigurationsmodelle im Zuge der S/4HANA-Transformation gezielt angepasst und auf zwei Konfigurationsebenen geordnet. Ein schlankes Web-Frontend mit Visualisierung genügte; ein weiteres CPQ war nicht erforderlich. Im zweiten Fall führte dieselbe Grundsatzprüfung zu einer geteilten Antwort: direkter SAP-Ansatz für standardisierte Produktbereiche, eigenständige CPQ-Orchestrierung für komplexere Maschinen.

Beide Entscheidungen folgen derselben Logik: Nicht die strategische Systempräferenz, sondern das konkrete Aufgabenprofil des Produktbereichs entscheidet.

Die falsche Alternative: SAP oder CPQ

Advanced Variant Configuration und CPQ sind keine austauschbaren Produktkategorien. AVC verarbeitet technische Produkt- und Regelmodelle im S/4HANA-Kontext. Ein CPQ kann zusätzlich den Vor-Auftragsprozess orchestrieren: Bedarfsklärung, Lösungsbildung, Bündelung, Pricing, Margen- und Freigabelogik, Angebotsversionen, Dokumente und die kontrollierte Übergabe an nachgelagerte Systeme.

Das bedeutet nicht, dass jedes Unternehmen dafür ein eigenständiges CPQ braucht. Es bedeutet nur, dass diese Aufgaben nicht mit der Systemabschaltung verschwinden. Ohne CPQ müssen sie bewusst anderen Systemen, Prozessen und Verantwortlichen zugeordnet werden.

Für eine belastbare Entscheidung sind fünf Ebenen getrennt zu betrachten:

1. Produkt- und Regelmodell: Welche Merkmale, Regeln, Strukturen, Gültigkeiten und Ableitungen tragen den künftigen Lösungsraum?

2. Konfigurationsebenen: Welche kunden- und vertriebsrelevanten Entscheidungen müssen interaktiv erfolgen, welche technische Auflösung gehört in Auftrag, Stückliste und Produktion?

3. Runtime und Performance: Welche Engine verarbeitet welche Ebene, welche Antwortzeiten sind im Vertrieb erforderlich und welche Komplexität darf erst nachgelagert aufgelöst werden?

4. Pricing und Quote: Wo entstehen konfigurationsabhängige Preise, Rabatte, Margen, Freigaben, Angebotsversionen und Dokumente?

Betriebsmodell: Wer verantwortet Modell, Runtime, Frontend, Pricing, Tests, Releases, Schnittstellen und Änderungen über den Lebenszyklus?

Erst wenn diese Ebenen getrennt und anschließend wieder zu einem durchgängigen Prozess verbunden sind, lässt sich entscheiden, ob ein schlankes Selling-Frontend genügt oder ob CPQ eine eigenständige, dauerhaft geschäftskritische Rolle übernimmt.

Migration heißt nicht: Modelle unverändert kopieren

Eine technisch transformierbare Modellwelt ist nicht automatisch zukunftsfähig. Historisch gewachsene LO-VC- und CPQ-Modelle können fachlich überholt, unnötig produktspezifisch, zu tief verschachtelt, schwer testbar oder für interaktive Nutzung zu langsam sein. Werden diese Defizite lediglich in eine neue Laufzeit übertragen, modernisiert das Unternehmen die Technik – nicht die Produktlogik.

In der Praxis sind fünf Prüfentscheidungen erforderlich:

1. Modelle gezielt anpassen

Nicht jedes bestehende Modell muss neu gebaut werden. Aber Merkmale, Regeln, Tabellen, Strukturen und Gültigkeiten sind darauf zu prüfen, ob sie AVC-kompatibel, verständlich, wiederverwendbar und für den künftigen Prozess noch erforderlich sind. Gezielt angepasst wird dort, wo alte Syntax, lokale Sonderlogik oder historisch gewachsene Modellgrenzen die Zielarchitektur behindern.

2. Vertriebs- und Ausführungskonfiguration trennen

Ein kunden- und vertriebsnahes Modell muss schnell führen, verständliche Merkmale anbieten und eine belastbare Auswahl erzeugen. Die technische Ausführung benötigt dagegen vollständige Strukturauflösung, Werk- und Zeitgültigkeit, Stückliste, Arbeitsplan und gegebenenfalls Costing. Eine klare Trennung dieser Konfigurationsebenen reduziert nicht die Durchgängigkeit – sie verhindert, dass jede Vertriebsinteraktion die gesamte technische Modellwelt verarbeiten muss.

3. Performance mit realen Lastfällen prüfen

Performance ist keine abstrakte Systemeigenschaft. Zu testen sind typische und ungünstige Konfigurationswege, mehrstufige Modelle, umfangreiche Tabellen, Preisaufrufe und die Übergabe zwischen Frontend, Runtime und Backend. Entscheidend ist nicht nur der Durchschnitt, sondern ob der Vertriebsprozess auch bei komplexen Fällen stabil und responsiv bleibt.

Performance wird zur Architekturfrage, wenn Modellbausteine, Regelarten oder Preisaufrufe die interaktive Vertriebsnutzung belasten. Dann ist je Element zu entscheiden, ob es übernommen, vereinfacht, neu geordnet oder erst auf der Ausführungsebene aufgelöst wird. Bewertet werden nicht nur Durchschnittswerte, sondern repräsentative und kritische Lastprofile. Nicht jedes technisch transformierbare Konstrukt gehört deshalb unverändert in das Zielmodell.

4. Pricing und Angebotslogik verorten

Beim Pricing ist zwischen konfigurationsabhängiger Preisfindung, standardisierter Konditionslogik und der kommerziellen Orchestrierung von Bündeln, Rabatten, Margen, Freigaben und Angebotsversionen zu unterscheiden. Bleiben Pricing und Quote im betrachteten Bereich überschaubar und SAP-seitig beherrscht, entsteht daraus noch keine eigenständige CPQ-Rolle. Werden dagegen mehrere Produkte, Services und Sonderpositionen zu einer Lösung zusammengeführt, kann Pricing zum tragenden Argument für CPQ werden.

5. Transformation und Regression absichern

Die Überführung klassischer Modelle nach AVC ist kein technischer Einzelschritt. Vorprüfung, Modellanpassung, Ergebnisvergleich und Freigabe bilden einen kontrollierten Übergang; klassische und fortgeschrittene Verarbeitung können dabei für unterschiedliche Modelle nebeneinander bestehen. Das ermöglicht eine gestufte Portfolioentscheidung – ersetzt aber nicht die Prüfung, welche Modelle, Abhängigkeiten und Laufzeiten im konkreten Release tatsächlich unterstützt werden.

Für die Abnahme braucht es deshalb repräsentative Referenzkonfigurationen über beide Konfigurationsebenen hinweg – einschließlich Grenzfällen, Preiswirkungen und Laufzeitverhalten. Ergebnisgleichheit allein reicht nicht, wenn die interaktive Nutzung anschließend nicht performant oder der Modellstand nicht eindeutig rückverfolgbar ist.

Die Managementfolgerung ist pragmatisch: Nicht alle Modelle gleich behandeln. Für jede Produktfamilie wird ein begründeter Migrationspfad festgelegt – fortführen, selektiv anpassen, in Ebenen neu ordnen oder fachlich neu modellieren.

Ein führendes Modell – aber nicht zwingend eine einzige Laufzeit

Das häufig als „Model Once, Configure Anywhere“ beschriebene Prinzip weist in die richtige Richtung: Produktlogik soll nicht für jeden Kanal neu modelliert werden. Es bedeutet jedoch weder ein monolithisches Modell für alle Aufgaben noch zwingend dieselbe Engine für jede Anfrage. Vertriebs- und Ausführungskonfiguration können unterschiedlich zugeschnitten sein, solange Führung, Übergabe und Gültigkeit eindeutig bleiben.

SAP Variant Configuration and Pricing kann Konfigurations- und Pricing-Funktionen für Web-, Commerce- oder CPQ-Anwendungen bereitstellen. Je nach Szenario werden Knowledge-Base-Laufzeitversionen verarbeitet oder Anfragen an die AVC-Engine im Backend weitergeleitet. Die beiden Wege verlagern Verantwortung unterschiedlich: Replikation schafft einen kontrolliert zu versorgenden Laufzeitstand außerhalb des führenden Systems; Weiterleitung bindet die Frontend-Nutzung stärker an Verfügbarkeit und Last des Backends. Keine der beiden Abhängigkeiten ist grundsätzlich falsch – sie muss aber bewusst gewählt und betrieben werden.

Präziser als ein bloßes „ein Modell überall“ lautet das Ziel:

Zwei Zielbilder · eine Entscheidungslogik

Die Systemrolle folgt dem Aufgabenprofil des Produktbereichs.

A

SAP-geführte Konfiguration ohne zusätzliches CPQ

Web-Frontend
Führung & Visualisierung→ SAP-nahe Runtime
Konfiguration & Pricing→ S/4HANA
Auftrag & Ausführung

Passt, wenn Produktmodell, Performance, Pricing und Quote mit einem bewusst schmalen Frontend beherrscht bleiben.

Gegenprobe: Wächst das Frontend zum Schatten-CPQ?

B

Geteiltes Zielbild nach Produktbereich

Standardisierter Bereichschlankes Frontend → SAP

Komplexe MaschinenCPQ-Orchestrierung → SAP

Passt, wenn Lösungsbildung, MTO-/ETO-Anteile, Varianten der Quote sowie anspruchsvolleres Pricing und Freigaben nur in einzelnen Bereichen eine eigenständige CPQ-Rolle begründen.

Gegenprobe: Dupliziert CPQ technische Produktlogik?

Fall A: SAP-geführte Konfiguration ohne zusätzliches CPQ

Die folgenden Fälle beschreiben anonymisierte und verdichtete Zielbildentscheidungen. Sie belegen keine quantifizierten Wirkungen aus einem späteren Produktivbetrieb.

Ausgangslage im CTO-nahen Produktbereich

Im ersten Projekt wurde die S/4HANA-Transformation genutzt, um bestehende Konfigurationsmodelle vor der Überführung nach AVC fachlich und technisch neu zu ordnen. Eine reine 1:1-Übernahme war nicht das Ziel. Einzelne Abhängigkeiten und Strukturen mussten angepasst, vertriebsnahe Merkmale von der technischen Auflösung klarer getrennt und repräsentative Konfigurationsfälle neu getestet werden.

Der betrachtete Produktbereich war weitgehend modular und CTO-nah. Der Vertrieb benötigte eine moderne Web-Bedienung, geführte Auswahl und Visualisierung. Pricing und Angebotsprozess waren im vorgesehenen Scope dagegen standardisiert genug, um keine eigenständige kommerzielle Orchestrierung zu begründen. Die Frage lautete daher: Welches kleinste Zielbild deckt diese Aufgaben zuverlässig ab?

Das pragmatische Zielbild

Das Zielbild verteilte die Aufgaben bewusst auf vier klar begrenzte Bausteine:

• Vertriebsnahe Konfiguration: kundenrelevante Merkmale, geführte Auswahl und eine verständliche Sicht auf den zulässigen Lösungsraum.

• Technische Auflösung: SAP-geführte Regeln und Strukturen für Auftrag, Stückliste, Arbeitsplan und Folgeprozesse.

• Web-Frontend und Visualisierung: bedienen, erklären und Ergebnisse darstellen – ohne eigene technische Produktlogik.

• Pricing: standardisierte SAP-nahe Preisfindung ohne parallele Preis- und Freigabelogik im Frontend.

Dieses Zielbild war bewusst schmal. Das Frontend sollte führen, visualisieren und kontrolliert übergeben. Produktregeln, technische Gültigkeit und die maßgebliche Preisfindung blieben außerhalb der Oberfläche. Damit entstand kein Ersatz-CPQ, sondern eine klar begrenzte Nutzung der SAP-geführten Konfiguration.

Was praktisch geprüft wurde

Die Entscheidung beruhte auf fünf belastbaren Prüfungen:

• Modellanpassung: Nur die für AVC, Verständlichkeit und Wiederverwendung erforderlichen Teile wurden angepasst; Altlogik wurde nicht pauschal kopiert.

• Konfigurationsebenen: Vertriebsführung und technische Strukturauflösung wurden getrennt, aber über eindeutige Merkmale und Ergebnisse verbunden.

• Performance: Interaktive Antwortzeiten wurden mit repräsentativen und ungünstigen Fällen geprüft; die vollständige technische Auflösung musste nicht bei jeder Nutzereingabe erfolgen.

• Pricing: Konfigurationsabhängige Preiswirkungen und Konditionen blieben im SAP-nahen Zielbild beherrschbar; eine parallele Preislogik im Frontend wurde vermieden.

• Betrieb: Der zusätzliche Nutzen eines CPQ hätte Plattform-, Integrations-, Test- und Pflegeaufwand nicht eindeutig gerechtfertigt.

Damit wurde kein CPQ „ersetzt“. Im betrachteten Aufgabenprofil blieb nach der Neuordnung keine eigenständige dauerhafte CPQ-Rolle übrig.

Grenze der Übertragbarkeit

Die Entscheidung wäre anders ausgefallen, wenn mehrere Produkte und Services zu Lösungen gebündelt, stark differenzierte Preise und Margen kalkuliert, mehrstufige Freigaben gesteuert oder zahlreiche Angebotsvarianten und Partnerkanäle beherrscht werden müssten. Dann würde das schlanke Frontend entweder überlastet oder schleichend selbst zum CPQ.

Fall B: Unterschiedliche Zielbilder für unterschiedliche Produktbereiche

Ausgangslage im heterogenen Produktportfolio

Im zweiten Projekt wurde eine bestehende CPQ-Landschaft im Zuge der S/4HANA-Migration grundsätzlich überprüft. Das Unternehmen vereinte einen stärker standardisierten, CTO-nahen Produktbereich und komplexere Maschinen mit relevanten MTO-/ETO-Anteilen, Ausnahmen und höherem Abstimmungsbedarf vor dem Auftrag.

Eine unternehmensweit einheitliche Architektur hätte auf den ersten Blick strategisch sauber gewirkt. In der Praxis hätte sie jedoch den standardisierten Bereich überversorgt oder die komplexen Maschinen unterversorgt. Deshalb wurde nicht nach einem einzigen Systemziel, sondern nach der dauerhaft erforderlichen Rolle je Produktbereich entschieden.

Die differenzierte Entscheidung

Für den stärker standardisierten Bereich wurde der direkte SAP-geführte Ansatz gewählt. Die Modelle wurden auf das künftige Zielbild angepasst, Vertriebs- und Ausführungskonfiguration klar getrennt und ein schlankes Frontend vorgesehen. Die Preis- und Angebotslogik blieb in diesem Bereich ausreichend standardisiert.

Für die komplexeren Maschinen blieb dagegen eine eigenständige CPQ-Rolle erforderlich. Dort reichte die Ausführung eines vollständig vorgedachten Produktmodells nicht aus. Lösungsbildung über mehrere Komponenten, MTO-/ETO-Anteile, Ausnahmebehandlung, Angebotsvarianten sowie anspruchsvollere Preis-, Margen- und Freigabeentscheidungen mussten vor dem Auftrag zusammengeführt werden.

Das Zielbild lautete deshalb weder „CPQ überall“ noch „CPQ vollständig ablösen“. SAP führte die technische Produktlogik; CPQ orchestrierte sie nur dort, wo der Vor-Auftragsprozess eine eigenständige Anwendung rechtfertigte.

Warum Differenzierung nicht Fragmentierung bedeutet

Unterschiedliche Zielbilder bleiben nur dann beherrschbar, wenn gemeinsame Architekturregeln gelten. Führende Produktobjekte, zulässige Ableitungen, Konfigurationsebenen, Preisverantwortung, Übergabepunkte und Tests müssen unabhängig vom Produktbereich eindeutig sein. CPQ darf technische Produktlogik nicht unkontrolliert duplizieren; das schlanke Frontend darf nicht schleichend eine eigene Angebots- und Preiswelt aufbauen.

Die Differenzierung lag damit in der Orchestrierung und im erforderlichen Prozessumfang – nicht in beliebigen Produktwahrheiten.

Grenze der Differenzierung

Wären die komplexeren Produkte stärker modularisiert, Ausnahmen seltener und Preis-, Freigabe- und Dokumentprozesse einfacher, hätte sich der CPQ-Scope reduzieren können. Umgekehrt müsste der CTO-nahe Bereich neu bewertet werden, sobald Lösungsbildung, Kanalvielfalt oder kommerzielle Komplexität deutlich wachsen.

Die beiden Fälle im direkten Vergleich

Die Tabelle zeigt den eigentlichen Unterschied: Nicht die Systempräferenz, sondern die dauerhafte Aufgabe bestimmt die Architektur.

Wann ein schlankes Selling-Frontend genügt

Ein schlankes Frontend ist ein belastbares Zielbild, wenn es tatsächlich schlank bleiben kann. Dafür sollten drei Bedingungen weitgehend erfüllt sein:

• Modell und Ebenen beherrscht: Der Lösungsraum ist ausreichend strukturiert; vertriebsnahe Merkmale und technische Auflösung sind sauber getrennt und eindeutig verbunden.

• Performance beherrscht: Die interaktive Konfiguration bleibt auch bei realen Grenzfällen responsiv; aufwendige technische Ableitungen werden dort ausgeführt, wo sie hingehören.

• Pricing und Quote beherrscht: Preisfindung, Rabatte, Freigaben und Dokumente sind überschaubar oder eindeutig in bestehenden Systemen verankert.

Sobald diese Bedingungen nicht mehr gelten, muss neu entschieden werden. Ein zunächst kleiner Web-Client kann über Jahre Merkmale, Sonderregeln, Preise, Rabatte, Freigaben und Dokumentbausteine aufnehmen. Formal bleibt er ein Frontend; faktisch entsteht ein individuell entwickeltes CPQ ohne die dafür notwendige Produkt- und Betriebsdisziplin.

Wann CPQ eine eigenständige Aufgabe hat

Ein CPQ ist nicht durch möglichst viele Funktionen gerechtfertigt, sondern durch eine klar abgrenzbare Verantwortung. Diese kann insbesondere entstehen, wenn drei Aufgabenbündel dauerhaft zusammenkommen:

• Lösungsbildung: Bedarf, Produkte, Services und Ausnahmen müssen iterativ zu einer technisch eindeutigen Lösung zusammengeführt werden.

• Pricing und Quote: Preis, Kosten, Marge, Risiko, Freigaben, Versionen und Dokumente müssen gemeinsam gesteuert werden.

• Kanäle und Übergabe: Interne, Partner- und digitale Kanäle benötigen kontrollierte Sichten; MTO-/ETO-Anteile und Ausnahmen müssen nachvollziehbar in den Auftrag überführt werden.

Auch dann bleibt die Abgrenzung zentral: CPQ orchestriert den Vor-Auftragsprozess, muss aber nicht automatisch die alleinige Quelle aller technischen Produktregeln sein. Die beste Architektur verteilt nicht Funktionen nach Herstellergrenzen, sondern Verantwortung nach Objekten und Entscheidungen.

Die kritische Grenze: zweite Produktwahrheit oder Schatten-CPQ

Zwei Fehlentwicklungen sehen auf den ersten Blick gegensätzlich aus, haben aber dieselbe Ursache.

Die zweite Produktwahrheit entsteht, wenn Produktmerkmale, Regeln oder Gültigkeiten parallel in SAP, CPQ und weiteren Anwendungen gepflegt werden, ohne führende Quelle und kontrollierte Ableitung. Schnittstellen synchronisieren dann Daten, aber nicht automatisch Bedeutung und Verantwortung.

Das Schatten-CPQ entsteht, wenn ein als schlank geplantes Frontend zunehmend Angebotslogik übernimmt. Jede einzelne Ergänzung wirkt pragmatisch. In Summe entsteht jedoch eine geschäftskritische Anwendung mit eigener Logik, Testlast und Releaseabhängigkeit – nur ohne klare Produktentscheidung und Governance.

Beide Risiken lassen sich nicht allein durch Technologie vermeiden. Erforderlich sind für jedes zentrale Objekt drei klare Prinzipien:

5. Führung: Wo wird das Objekt fachlich geführt und wer darf es ableiten oder anreichern?

6. Gültigkeit: Welcher Stand ist verbindlich und welches Ergebnis wird persistiert und übergeben?

7. Verantwortung: Wer verantwortet Änderungen, Tests und Freigaben?

Diese drei Prinzipien sind häufig wertvoller als eine lange Funktionsmatrix.

Die richtige Entscheidungsreihenfolge

Die Architekturentscheidung lässt sich in sieben Managementschritte verdichten:

1. Produktbereiche und Prozessprofile trennen. PTO, ATO, MTO, CTO, CTO+ und ETO geben wichtige Randbedingungen, entscheiden aber nicht allein über das System.

2. Migrationspfad je Modell festlegen. Fortführen, selektiv anpassen, in Ebenen neu ordnen oder fachlich neu modellieren – nicht pauschal konvertieren.

3. Konfigurationsebenen und Objektübergaben festlegen. Vertriebsführung, technische Auflösung, Stückliste und Persistenz brauchen eindeutige Grenzen.

4. Performance unter realistischen Bedingungen testen. Typische Fälle, Grenzfälle, mehrstufige Modelle, Preisaufrufe und Übergaben gehören in den Nachweis.

5. Pricing und Vor-Auftragsaufgaben zuordnen. Preis, Marge, Freigabe, Version, Dokument und Kollaboration brauchen klare Systemverantwortung.

6. CPQ-Rolle je Produktbereich entscheiden. Nicht „CPQ ja oder nein“ für das gesamte Unternehmen, sondern Aufgabe, Scope und Umkehrbedingung je Bereich festlegen.

7. Das kleinste tragfähige Betriebsmodell wählen. Ziel ist nicht die niedrigste Zahl an Anwendungen, sondern die geringste dauerhaft beherrschbare Komplexität bei vollständiger Aufgabenabdeckung.

Diese Reihenfolge verhindert, dass eine Softwareentscheidung die fachliche Architektur vorwegnimmt. Sie erlaubt zugleich unterschiedliche Zielbilder für unterschiedliche Produktbereiche – bei gemeinsamer Objektführung, Governance und Testlogik.

iTechnische Einordnung und offizielle SAP-Hinweise

Funktionsumfang und Verfügbarkeit der genannten Komponenten sind im konkreten Vorhaben nach Edition, Release und Deployment zu validieren.

• SAP Help: Variant Configuration Service

• SAP Help: Weiterleitung von Konfigurationsanfragen an AVC

Hinweis zu den Fällen: Die beiden Projektsituationen sind anonymisiert und für die Veröffentlichung verdichtet. Identifizierende Angaben zu Unternehmen, Produkten, Releases und Implementierungsdetails wurden bewusst generalisiert. Die Darstellung beschreibt Zielbildentscheidungen, keinen quantifizierten Nachweis aus dem Produktivbetrieb. Der Beitrag leitet daraus keine universelle Produktempfehlung ab.

Fazit für Entscheider

Die Migration schafft den Anlass – nicht die Antwort.

Die S/4HANA-Migration entscheidet nicht über CPQ.

Sie schafft den Anlass, Modelle, Konfigurationsebenen und Systemrollen neu zu ordnen.

Wo vorhandene Modelle gezielt angepasst, Vertriebs- und Ausführungskonfiguration sauber getrennt, Performance nachgewiesen und Pricing im SAP-nahen Prozess beherrscht werden können, kann ein schlankes Selling-Frontend genügen.

Wo dagegen Lösungsbildung, MTO-/ETO-Anteile, Ausnahmen sowie anspruchsvolle Preis-, Margen-, Freigabe- und Angebotsprozesse zusammenkommen, bleibt CPQ eine eigenständige Systemrolle.

Diese Entscheidung kann innerhalb eines Unternehmens für verschiedene Produktbereiche unterschiedlich ausfallen.

Einheitlich bleiben müssen der führende Modellkern, Gültigkeit, Übergabe, Regressionstest und Verantwortung.

Die beste Architektur ist nicht die mit den wenigsten Systemen, sondern die mit der geringsten dauerhaft beherrschbaren Komplexität – ohne zweite Produktwahrheit und ohne Schatten-CPQ.

English Executive Summary

S/4HANA Migration and CPQ: Two Target Architectures Instead of One Default Answer

An S/4HANA migration is an opportunity to reassess configuration models, execution layers and system responsibilities. It does not automatically determine whether a separate CPQ solution is required. The appropriate architecture depends on the product and process profile of each business area.

In one anonymised case, legacy configuration models were selectively adapted for the future AVC environment and separated into a sales-oriented layer and a technical execution layer. A focused web frontend with guided selling and visualisation was sufficient. Product logic and standardised pricing remained SAP-led; an additional CPQ role could not be justified.

In a second case, the result differed by product segment. A direct SAP-led approach was suitable for the more standardised CTO-oriented range. Complex machines with relevant MTO and ETO content, iterative solution building, quotation variants and more demanding pricing, margin and approval processes still required independent CPQ orchestration.

The management principle is therefore to choose the smallest sustainable operating model for each product area. Model adaptation, configuration layers, runtime performance, pricing and ownership must be tested together. CPQ should remain only where it has a clearly defined, durable responsibility; a thin frontend must not gradually become an unmanaged shadow CPQ.