CPQ + SAP S/4HANA im Maschinenbau: Implementierungserfahrung, Architektur und Projektergebnisse

Projektkontext

Im Maschinenbau entstehen Angebote oft als Gemeinschaftsleistung zwischen Vertrieb, Konstruktion und Kalkulation. Ohne CPQ durchläuft eine Anfrage mehrere Abteilungen, bevor ein Angebotsdokument entsteht — mit Excel-Kalkulationen, Rückfragen an Engineering und manueller Preisfindung. Die Fehleranfälligkeit ist hoch, die Durchlaufzeit liegt typischerweise zwischen zwei und fünf Werktagen.

SAP S/4HANA ist in diesen Unternehmen das System of Record: Materialstamm, Konditionstechnik, Stücklisten (PP/MM) und Kundenpreisfindung (SD) liegen dort. Der kritische Schritt bei der CPQ-Einführung ist, diese Daten strukturiert ins Konfigurationssystem zu übernehmen — und fertige Konfigurationen als verwertbare Datensätze zurückzuschreiben.

Integrationsarchitektur

SAP S/4HANA bietet standardisierte OData-APIs für die wichtigsten Stammdaten: Materialstamm (MM), Vertriebspreise und Konditionen (SD), Stücklisten (PP) und Kundenstamm. Diese APIs ermöglichen eine direkte Integration ohne Middleware-Zwischenschicht — in den meisten Maschinenbau-Projekten ein klarer Vorteil gegenüber älteren SAP-Installationen, wo RFC-Aufrufe und BAPI-Schnittstellen individuell entwickelt werden mussten.

Ein wichtiger Architekturentscheid betrifft das Verhältnis zu SAP VC (Variantenkonfiguration): Unternehmen, die SAP VC bereits aktiv nutzen, haben gut strukturierte Konfigurationsregeln — die Frage ist, ob diese ins CPQ migriert oder parallel gehalten werden. In den beobachteten Projekten wurde SAP VC häufig als Datenquelle für Variantenstruktur genutzt, während die eigentliche Konfigurationslogik im CPQ abgebildet wurde.

Der Datenfluss nach der Konfiguration geht in der Regel zurück nach SAP: als Kundenauftrag (SD), als Stücklistenposition (PP) oder als strukturiertes Angebot. Dieser Rückschrieb ist technisch über die SAP-Sales-Order-API realisierbar, erfordert aber ein sauberes Feldmapping auf SAP-Seite.

Implementierungsverlauf

Die entscheidende Variable in SAP-Projekten ist die Stammdatenqualität. In Projekten, in denen Materialstammdaten gepflegt, Konditionen aktuell und Stücklisten vollständig sind, erreicht man einen funktionsfähigen Prototypen in 6–8 Wochen. Wo Stammdaten bereinigt werden müssen, verlängert sich die Phase um 4–8 Wochen — unabhängig von der CPQ-seitigen Implementierung.

Die typische Projektstruktur sieht vor: Datenaudit in Woche 1–3, Schnittstellenentwicklung in Woche 4–8, Key-User-Testing in Woche 9–12, Roll-out und Training in Woche 12–16. Bei klarer Projektsteuerung sind 2–4 Monate realistisch. SolidWorks-Anbindung (für CAD-Dokumente im Angebot) wurde in mehreren Projekten als zweite Phase umgesetzt — nach stabilem Go-live des Kernprozesses.

Die Sales Adoption ist im Maschinenbau erfahrungsgemäß hoch, wenn das CPQ technisch präzise konfiguriert ist. Vertriebsmitarbeiter akzeptieren das System schnell, sobald sie sehen, dass die Konfigurationsregeln korrekt sind und keine Fehler produzieren.

Fachliche Einschätzung

SAP S/4HANA + CPQ ist für den deutschen Maschinenbau die ausgereifteste Kombination. Die API-Infrastruktur ist vorhanden, die Datenmodelle sind kompatibel, und es gibt ausreichend Referenzprojekte, um Architekturentscheidungen auf Erfahrungswerten zu basieren.

Die wichtigste Voraussetzung für ein erfolgreiches Projekt ist keine technische: Es ist die interne Bereitschaft, Stammdaten zu bereinigen und Preislogiken zu dokumentieren, bevor das CPQ-System konfiguriert wird. Teams, die das vorbereiten, erreichen den Go-live schneller und mit weniger Nacharbeit.

Hinweis: Als Gründer von Mercura bin ich an der Implementierung der Mercura CPQ Plattform beteiligt. Die Inhalte stellen persönliche fachliche Beobachtungen aus Implementierungsprojekten dar.