S/4HANA Public Cloud und Sales Cloud V2 gemeinsam einführen: Sequenzierung, Zeitplan, Fallstricke

Sollten Sie S/4HANA Public Cloud und SAP Sales Cloud V2 gleichzeitig einführen?

Das ist eine der häufigsten Fragen, die wir von DACH-Unternehmen hören, die ihre SAP-Landschaft modernisieren. Die ehrliche Antwort: Es hängt davon ab, welches Problem dringlicher ist — und ob Ihre Organisation die Programmmanagement-Kapazität hat, beides gleichzeitig zu stemmen.

Gut gemacht, bietet ein gemeinsamer Rollout von Anfang an ein sauberes, gemeinsames Datenmodell: ein Business-Partner-Datensatz, ein Produktkatalog, ein Auftragsfluss. Schlecht gemacht, konkurrieren zwei Parallelprojekte um dieselbe IT-Kapazität, dieselben Key User und dieselbe Change-Management-Aufmerksamkeit. Dann kommt etwas zu Schaden — oder beides landet zu spät.

Dieser Beitrag legt die drei Sequenzierungsoptionen dar, zeigt, wie ein realistischer kombinierter Zeitplan aussieht, erklärt, wo die beiden Projektteams synchron bleiben müssen — und nennt die Fallstricke, die wir schon mehr als einmal erlebt haben.

Sollten Sie S/4HANA Public Cloud und Sales Cloud V2 gleichzeitig einführen?

Der Ausgangspunkt ist eine ehrliche Bestandsaufnahme Ihrer Rahmenbedingungen.

Zwei grosse SAP-Implementierungen parallel zu führen ist ambitioniert. Beide Systeme berühren Ihre Kerngeschäftsprozesse. Beide erfordern Key-User-Zeit für Workshops, Tests und Schulungen. Beide benötigen Integrationsarbeit auf BTP. Wenn Ihr IT-Team oder Ihr Beratungsbudget begrenzt ist, ist Sequenzierung sicherer.

Aber es gibt ein echtes Argument für parallele Durchführung. Das Business-Partner-Modell ist zwischen S/4HANA Public Cloud und SAP Sales Cloud V2 geteilt. Wenn Sie CRM zuerst ohne ERP einführen, bauen Sie eine temporäre Integration zu Ihrem bestehenden ERP — und müssen Teile davon wiederholen, wenn S/4HANA kommt. Das ist Nacharbeit, die Sie durch bessere Sequenzierung vermeiden können.

Die richtige Antwort hängt von drei Dingen ab: welches System Ihr Unternehmen dringlicher braucht, wie es um Ihre Change-Management-Kapazität steht und ob Sie einen Partner haben, der die Integrationsschicht über beide Workstreams hinweg verantwortet.

Drei Sequenzierungsoptionen

ERP zuerst, dann CRM

Das ist der sicherere Standard. S/4HANA Public Cloud geht zuerst live und etabliert das Business-Partner-Stammdatenmodell, den Produktkatalog und die Finanzprozesse. Sobald das ERP stabil ist — typischerweise 3 bis 6 Monate nach dem Go-Live — startet das Sales Cloud V2-Projekt mit sauberen Quelldaten für die Integration.

Der Kompromiss: Ihr Vertriebsteam wartet. Wenn die CRM-Situation kritisch ist — manuelle Prozesse, Daten in Tabellen, keine Pipeline-Transparenz — sind 9 bis 12 Monate Wartezeit auf ein besseres Vertriebstool schmerzhaft.

Was diese Option bringt: Sales Cloud V2 geht live mit echten ERP-Daten von Tag eins. Keine temporären Konnektoren, die später abzulösen sind. Keine Datenmigration aus einem Zwischen-CRM-Zustand. Die Integrationsarbeit wird einmal — und korrekt — durchgeführt.

CX zuerst, dann ERP

Weniger üblich, macht aber Sinn, wenn der Vertriebsprozess der primäre Schmerzpunkt ist und das ERP vorerst stabil genug ist.

SAP Sales Cloud V2 geht gegen das bestehende ERP live — ob ECC, S/4HANA on-premise oder ein anderes System. Die Integration wird für dieses ERP gebaut. Wenn S/4HANA Public Cloud später kommt, wird die Integration gegen die neuen ERP-Endpunkte neu gebaut.

Der Kompromiss: Sie akzeptieren doppelte Integrationsarbeit. Die erste Integration wird aufgegeben, wenn das ERP wechselt. Das ist echter Aufwand und Nacharbeit — aber wenn die Priorität darin besteht, dem Vertriebsteam im nächsten Quartal ein modernes CRM bereitzustellen, kann es die richtige Entscheidung sein.

Ein Risiko, das benannt werden muss: Wenn Ihr bestehendes ERP unordentliche Stammdaten hat — inkonsistente Business-Partner-Datensätze, doppelte Accounts, veraltete Preise — importieren Sie dieses Chaos in Sales Cloud. Und bereinigen es dann erneut vor der S/4HANA-Migration. Besser einmal bereinigen, in der ERP-Migration, und Sales Cloud sauber starten.

Parallele Durchführung

Beide Projekte laufen gleichzeitig mit einem gemeinsamen Integrations-Workstream. Das verkürzt den Gesamtzeitplan, erhöht aber den Koordinationsaufwand erheblich.

Damit das funktioniert, brauchen Sie: einen dedizierten Programmmanager, der die stream-übergreifenden Abhängigkeiten verantwortet, einen klaren Integrationsverantwortlichen auf BTP und ein gemeinsames Steuerungsgremium, das Prioritätskonflikte lösen kann, wenn beide Projekte gleichzeitig dieselben Key User beanspruchen.

Wir haben parallele Durchführung funktionieren sehen, wenn die beiden Workstreams in Bezug auf Team und Umfang wirklich getrennt sind — ERP-Team verantwortet Finanzen und Logistik, CX-Team verantwortet den Vertriebsprozess — und nur auf der Integrationsschicht und der Stammdaten-Governance zusammenkommen müssen. Wo es scheitert: wenn dieselben drei Personen als Key User in beiden Projekten gleichzeitig erwartet werden.

Ein realistischer kombinierter Zeitplan

Das sind separate Schätzwerte, keine einzige kombinierte Zahl.

S/4HANA Public Cloud Greenfield-Implementierungen für KMU mit sauberem Prozessumfang — keine umfangreichen Anpassungen, Standardprozesse — dauern typischerweise 6 bis 9 Monate vom Kickoff bis zum Go-Live. Das ist der dokumentierte Bereich für Standard-Greenfield-Rollouts. Komplexer Umfang, mehrere Länder oder erhebliche Datenmigration verlängern das.

SAP Sales Cloud V2 Implementierungen für den Mittelstand — typischerweise 50 bis 200 User, ein Land, Standard-CRM-Prozesse — dauern 10 bis 16 Wochen. Unser Median über abgeschlossene Sales Cloud V2-Projekte liegt bei 14 Wochen vom Kickoff bis zum Go-Live. Kleinere Teams mit straffem Umfang schaffen es schneller. Enterprise-Implementierungen mit komplexen ERP-Integrationen dauern länger.

Für ein kombiniertes ERP-zuerst-Programm: Das ERP ist in Monat 6 bis 9 live, CX startet 1 bis 2 Monate vor dem ERP-Go-Live (mit frühem Beginn der Integrationsplanung), und Sales Cloud V2 geht in Monat 10 bis 15 live. Das ist der realistische End-to-End-Bereich für einen sequenziellen Rollout.

Parallele Durchführung verkürzt das Gesamtprogramm — beide Systeme können dasselbe Quartal ansteuern — aber nicht so stark, wie die meisten erwarten. Die Integrationsschicht muss unabhängig davon gebaut, getestet und stabilisiert werden, ob die zwei Projekte sequenziell oder parallel laufen.

Für detaillierte Guidance zur CX-Seite deckt unser SAP Sales Cloud V2 Implementierungsleitfaden die vollständigen Projektphasen, Teamstruktur und Kostenaufschlüsselung ab.

Wo die zwei Projektteams synchron bleiben müssen

Auch bei einem sequenziellen Rollout können die zwei Teams nicht vollständig isoliert agieren. Es gibt vier Bereiche, in denen sie koordinieren müssen.

Business-Partner-Modell und Stammdaten-Governance. Das S/4HANA-Projekt definiert die Struktur des Business-Partner-Datensatzes — Felder, Segmente, Rollen. Sales Cloud V2 konsumiert diese Struktur. Wenn das CX-Team nicht bei den ERP-Stammdaten-Workshops dabei ist, stellt es bei der Integration fest, dass die benötigten Felder nicht existieren oder anders heissen. Lösung: In jeden ERP-Stammdaten-Workshop einen CX-Vertreter einbeziehen.

Produktkatalog und Preisfindung. Sales Cloud V2 zieht Preise aus S/4HANA. Das ERP-Projektteam muss die Konditionsarten und Katalogstruktur finalisieren, bevor die CX-Integration gebaut werden kann. Ein häufiger Fehler: Das ERP-Team sperrt das Preismodell zwei Monate, nachdem die CX-Integration bereits für eine andere Struktur konzipiert wurde.

Benutzerverwaltung und Berechtigungen. Beide Systeme nutzen denselben Identity Provider, typischerweise SAP Identity Authentication Service. User-Provisionierung, Rollenzuweisung und SSO müssen einmal konzipiert werden und für beide Systeme funktionieren. Lassen Sie nicht zu, dass jedes Projekt das unabhängig löst.

Change-Management-Timing. Key User können nicht im Monat 7 S/4HANA-Schulungen und im Monat 8 Sales Cloud V2-Schulungen absolvieren, ohne auszubrennen. Sequenzieren Sie die Schulungsprogramme bewusst, mit ausreichend Abstand zwischen den Go-Lives, damit sich die User auf dem ersten System stabilisieren können, bevor sie das zweite lernen.

Fallstricke, die wir gesehen haben — und wie man sie vermeidet

Zwei Steuerungskreise ohne gemeinsamen Eskalationsweg. Das ERP-Projekt hat seinen eigenen Steuerungskreis. Das CX-Projekt hat seinen eigenen. Wenn eine stream-übergreifende Entscheidung getroffen werden muss — wer verantwortet den BTP-Integrations-Tenant? wer finanziert die gemeinsame Middleware? — gibt es kein Forum dafür. Die Entscheidung hängt wochenlang in der Luft. Lösung: Von Tag eins ein gemeinsames Programm-Steering einrichten, auch wenn es nur monatlich tagt.

Integrationsumfang zu spät definiert. Beide Projekte gehen davon aus, dass das andere Team die Integration übernimmt. Sechs Wochen vor dem Go-Live hat niemand damit angefangen, den Auftragsfluss von Sales Cloud nach S/4HANA zu bauen. Lösung: Integrationsumfang, Verantwortung und Budget müssen vereinbart sein, bevor eines der beiden Projekte in die Realize-Phase geht.

Schmutzige ERP-Daten in Sales Cloud importiert. Die ERP-Datenmigration bereinigt Kundendatensätze. Aber die CRM-Integration ist aus den alten ERP-Daten gebaut, nicht aus den bereinigten — weil die Zeitpläne nicht aufeinander abgestimmt sind. Sales Cloud geht mit 14.000 doppelten Accounts live. Lösung: Die CRM-Datenmigration muss aus dem bereinigten ERP-Zustand nach der Migration schöpfen — das bedeutet, Datenbereinigung vor dem CRM-Go-Live zu sequenzieren, nicht parallel dazu.

Change Fatigue. Finanz-User absorbieren ein neues ERP. Zwei Monate später wird dieselbe Organisation gebeten, ein neues CRM zu adoptieren. Die Akzeptanz leidet auf beiden Seiten. Lösung: Vor der Genehmigung des Programmzeitplans einen realistischen Change-Management-Kapazitätsplan erstellen. Der integrierte S/4HANA Public Cloud und Sales Cloud V2-Stack ist nichts wert, wenn die User auf Tabellen zurückgreifen.

BTP-Footprint unterschätzt. Beide Projekte werden BTP nutzen — Integration Suite, Identity Authentication, möglicherweise Build. Wenn jedes Projekt seine eigenen BTP-Instanzen beschafft, entstehen duplizierte Tenants, doppelte Kosten und eine Integrationsarchitektur, die keine Komponenten teilen kann. Lösung: BTP-Strategie als Programm-Entscheidung definieren, nicht als Projekt-Entscheidung.

Die technische Integration zwischen SAP S/4HANA Public Cloud und Sales Cloud V2 ist gut dokumentiert und umsetzbar. Das Schwierige ist nicht die Technologie. Es ist das Führen von zwei grossen Veränderungsprogrammen in derselben Organisation, mit denselben Menschen, ohne dass eines das andere untergräbt.

Richtige Sequenzierung, klare Verantwortlichkeit auf der Integrationsschicht und genug Zeit, damit Ihre Organisation jedes System absorbieren kann, bevor das nächste kommt — das ist es, was einen sauberen kombinierten Rollout von einem langen, teuren Recovery-Projekt unterscheidet.

Möchten Sie die Sequenzierung für Ihre spezifische Situation besprechen? Schreiben Sie uns — kein Pitch Deck, einfach ein Gespräch.