SAP S/4HANA Public Cloud + SAP Sales Cloud V2: Der integrierte CX- und ERP-Stack

S/4HANA Public Cloud und Sales Cloud V2 sind darauf ausgelegt, denselben Kunden zu teilen: denselben Business Partner, dieselben Produkte und Preise, einen Auftragsfluss. Die meisten DACH-Unternehmen mit SAP haben bereits ein CRM und ein ERP; das Problem ist, dass sich die beiden nicht einig sind, wer der Kunde ist.

Kurzfassung: Beide Produkte bauen auf dem Business-Partner-Modell von SAP auf, und SAP veröffentlicht Standard-Integrationsinhalte für Sales Cloud V2 und S/4HANA Cloud Public Edition, die auf SAP Integration Suite laufen. Stammdaten, Preise und Auftragsabwicklung bleiben im ERP; Pipeline, Aktivitäten und Servicefälle leben in Sales und Service Cloud V2; Integration und Erweiterungen liegen auf BTP. Was in Ihrem Projekt noch zu entscheiden ist, ist der Umfang: welche Felder repliziert werden, in welche Richtung jeder Fluss läuft, wie Fehler überwacht werden und wer die Integration nach dem Go-live verantwortet.

Dieser Beitrag erklärt, wie diese Integration funktioniert, wo die Logik liegt und wie Sie eine Einführung so staffeln, dass die alten Datenqualitätsprobleme nicht ins neue System wandern.

Warum S/4HANA Public Cloud mit Sales Cloud V2 kombinieren?

Weil eine Verkäuferin, die ein Angebot erstellt, und ein Buchhalter, der eine Rechnung verbucht, auf denselben Kunden schauen sollten.

In vielen SAP-Landschaften, die wir antreffen, ist das nicht so. Das CRM führt einen Kundendatensatz mit anderem Namensformat, anderen Adressfeldern und anderem Kreditstatus als der ERP-Datensatz. Der Vertrieb weiss nichts von der überfälligen Rechnung, die Finanzabteilung nichts vom neuen Vertrag.

Die klassische Lösung ist eine Schnittstelle, die Felder zwischen zwei unterschiedlichen Datenmodellen abgleicht. Das funktioniert, ist aber fragil: Jede Schemaänderung auf einer Seite bricht etwas, und irgendwann pflegt eine einzige Person eine Schnittstelle, die sonst niemand versteht.

Die Kombination aus S/4HANA Public Cloud und Sales Cloud V2 entschärft dieses Problem, weil beide das Business-Partner-Konzept verwenden. S/4HANA ist das führende System, Sales Cloud V2 erhält den replizierten Datensatz, und das Mapping ist im Content-Paket von SAP weitgehend vordefiniert, statt pro Projekt erfunden zu werden. Schlägt ein Verkäufer einen Kunden nach, sieht er den Account, den die Finanzabteilung im ERP pflegt. Eine Integration muss trotzdem betrieben und überwacht werden, aber sie verbindet zwei kompatible Modelle, statt zwischen inkompatiblen zu übersetzen.

Für DACH-Unternehmen, die von SAP S/4HANA On-Premise oder ECC wegziehen, ist das eines der echten Argumente für den Public-Cloud-Weg: ein CRM und ein ERP auf demselben Fundament.

Welches CRM passt am besten zu SAP S/4HANA Public Cloud?

Das beste CRM für SAP S/4HANA Public Cloud ist SAP Sales Cloud V2, weil es das Datenmodell des ERP teilt: Kundendatensätze folgen auf beiden Seiten dem Business-Partner-Konzept, Produkte und Preise kommen aus S/4HANA ins Angebot, und SAP liefert Standard-Integrationscontent für die Auftragsübergabe. Jedes CRM braucht eine Integrationsschicht zum ERP; mit Sales Cloud V2 ist der grösste Teil davon vorgefertigt und folgt dem Releasezyklus eines einzigen Herstellers, mit Salesforce oder Dynamics entwerfen, mappen und pflegen Sie sie selbst, und zwar dauerhaft.

Wann ein Dritt-CRM trotzdem sinnvoll ist

Zu einer guten Beratung gehören auch die Fälle, in denen die Antwort anders ausfällt. Läuft Salesforce bereits in mehreren Divisionen, mit ausgereiften Konfigurationen, aktiven AppExchange-Integrationen und eigenem Admin-Team, ist ein Wechsel für eine S/4HANA-Einführung wahrscheinlich die falsche Entscheidung. Dasselbe gilt, wenn umfangreiche Analytics-Arbeit auf dem CRM-Datenmodell beruht (eigene Objekte, Einstein-Modelle, Datenflüsse in ein Data Warehouse) oder wenn Ihre Anforderungen weit über den B2B-Vertrieb hinaus in Partnermanagement oder Branchenfunktionen reichen, bei denen dieses Ökosystem einen Vorsprung hat. Der Vergleich ist nie rein technisch: Er hängt davon ab, woher Sie kommen und wie viel Veränderung Ihre Teams wollen.

Ein Kundendatenmodell, nicht zwei

Das Business-Partner-Modell ist das Rückgrat beider Systeme. In S/4HANA Public Cloud wird jeder Kunde als Business Partner angelegt. Sales Cloud V2 erhält diesen Datensatz über SAP Integration Suite, sodass die Accountdaten in Sales Cloud widerspiegeln, was S/4HANA führt: Firmenname, Adressen, Zahlungsbedingungen und, wenn Sie es in den Umfang aufnehmen, Kredit- und Mahninformationen.

Für den Vertrieb verändert das das Kundengespräch. Wer einen Account in SAP Sales Cloud V2 öffnet, sieht das finanzielle Bild: offene Posten, Kreditrahmen, Auftragshistorie. Niemand muss die Buchhaltung anrufen, um zu erfahren, ob ein Geschäft gefährdet ist.

Für den Service bedeutet dasselbe Modell, dass Fälle in SAP Service Cloud V2 an dieselbe Kundenentität gebunden sind, die im ERP lebt. Keine separate Suche, kein «welchem System glaube ich?».

Die Synchronisierung ist eine Designentscheidung, kein Automatismus. Business-Partner-Datensätze werden in S/4HANA als führendem System gepflegt, Änderungen fliessen über Integrationsereignisse nach Sales Cloud V2. Neue Kunden, die in Sales Cloud V2 bei der Akquise angelegt werden, können zur ERP-Anlage zurück nach S/4HANA fliessen. Die Richtung jedes Flusses und das Feldmapping werden bei der Einführung entschieden, nicht nach dem Go-live entdeckt.

Vom Angebot über den Auftrag zur Rechnung

Hier zahlt sich die Integration für den Vertrieb am sichtbarsten aus.

Eine Verkäuferin erstellt ein Angebot in Sales Cloud V2. Produkte und Preise kommen aus S/4HANA; wer SAP CPQ einsetzt, lässt Konfiguration und Preislogik dort laufen. Der Kunde erhält ein Angebot auf Basis echter Preisdaten, nicht aus einer separat gepflegten Tabelle. Unser Beitrag zu Quote-to-Cash zwischen Sales Cloud V2 und S/4HANA Public Cloud geht diesen Fluss Schritt für Schritt durch.

Nimmt der Kunde an, geht der Auftrag zur Abwicklung an S/4HANA, statt per E-Mail an ein internes Team zur manuellen Erfassung. Das Lager kommissioniert, die Logistik versendet, die Finanzabteilung fakturiert.

Liefer- und Rechnungsstatus (gebucht, bezahlt, überfällig) fliessen zurück in die Accountsicht von Sales Cloud. Die Verkäuferin sieht, ob der Auftrag vom letzten Monat bezahlt ist, ohne ein Finanzportal zu öffnen, und der Service sieht den Lieferstatus, ohne das Lager anzurufen.

Dieser Kreislauf vom Angebot über den Auftrag zur Rechnung, sichtbar in Sales Cloud, ist das, was «integriertes CRM und ERP» in der Praxis bedeutet: ein Fluss, in dem Daten ohne manuelle Doppelerfassung wandern.

Clean Core: Wo die Integrationslogik liegt

Das Clean-Core-Prinzip von SAP ist hier entscheidend. Ziel ist, Anpassungen aus dem Kern von S/4HANA herauszuhalten und Integrations- und Erweiterungslogik auf die SAP Business Technology Platform zu legen.

Für eine Integration von Sales Cloud und S/4HANA heisst das:

• Freigegebene Standard-APIs auf beiden Seiten (OData, SOAP, Events), dokumentiert im SAP Business Accelerator Hub
• Integrationsflüsse in SAP Integration Suite auf BTP
• Die vorgefertigten Content-Pakete von SAP als Ausgangspunkt für die Standardszenarien
• Eigene Logik (Preisregeln, Genehmigungsworkflows, Spezialmappings) in BTP-Erweiterungen oder SAP Build, nicht in Modifikationen von S/4HANA

Der Nutzen ist handfest. SAP aktualisiert S/4HANA Public Cloud für alle Kunden nach einem festen Release-Kalender, und eine Integration auf freigegebenen APIs und Side-by-Side-Erweiterungen ist darauf ausgelegt, diese Upgrades zu überstehen. Logik, die an nicht freigegebenen Objekten hängt, macht aus jedem Upgrade eine Regressionstest-Kampagne.

Was in S/4HANA, Sales Cloud V2 und BTP liegt

Verantwortung	Wo sie liegt
Kundenstammdaten (Business Partner)	S/4HANA Public Cloud
Produktkatalog, Preiskonditionen	S/4HANA Public Cloud
Auftragsmanagement, Abwicklung, Fakturierung	S/4HANA Public Cloud
Opportunity-Management, Pipeline, Forecasting	Sales Cloud V2
Kundeninteraktionen, Aktivitäten, Besuchsberichte	Sales Cloud V2
Servicefälle, SLA-Tracking, Eskalationen	Service Cloud V2
Integrationsflüsse, Eventverarbeitung, Fehlerbehandlung	BTP Integration Suite
Erweiterungen, eigene Apps, KI-Funktionen	BTP (Side-by-Side)

Es gibt Grenzfälle, aber als Ausgangsmodell ist das sauberer als die meisten Landschaften, die wir übernehmen. Der Leitfaden zur Integrationsarchitektur behandelt die Muster technisch tiefer.

So sieht das in Spadoom-Projekten aus

Das Bild vor einem Projekt ist immer ähnlich: Der Vertrieb pflegt Kundendaten in einem CRM, das nur lose mit SAP abgeglichen ist, die Finanzabteilung hat den massgeblichen Kundendatensatz, den der Vertrieb nicht sieht, die Auftragserfassung ist manuell, und von einer Kreditsperre erfährt der Vertrieb, wenn der Kunde sich beschwert.

Nach dem Projekt zeigt die Accountsicht in Sales Cloud offene Posten und Auftragshistorie aus dem ERP, Angebote beruhen auf echten Preisen, und Aufträge fliessen ohne Doppelerfassung ein.

Drei veröffentlichte Projekte zeigen unterschiedliche Teile davon:

• Bei intelligentfood hat Spadoom Sales Cloud V2, die Integration mit Cloud ERP und Arbeiten in Teilen von MM und SD umgesetzt. Die Sales-&-Service-Plattform war in drei Monaten live (die Angabe bezieht sich auf diese Plattform, nicht auf die gesamte ERP-Einführung).
• Bei Nussbaum Matzingen, einem Verpackungshersteller, hat Sales Cloud V2 Excel-Listen und Outlook-Ordner in fünf Monaten durch eine Vertriebsplattform ersetzt und dem Management volle Pipeline-Transparenz gegeben, mit SAP ECC als Backend.
• Bei Miltenyi Biotec haben wir Commerce Cloud, Marketing, Customer Data Cloud, S/4HANA und Service Cloud V2 über SAP Integration Suite verbunden, sodass der Service mit denselben Kundendaten arbeitet wie der Rest der Landschaft.

Nichts davon ist spektakulär. Es ist das, was eine Integration von CRM und ERP leisten soll, und es funktioniert, wenn das Datenmodell von Anfang an geteilt wird.

In welcher Reihenfolge Sie die zwei Projekte angehen

Der häufigste Fehler: CRM und ERP als parallele, unabhängige Projekte führen, die sich «später verbinden» sollen. Das tun sie selten, oder nur oberflächlich, und die Integrationsschulden wachsen.

Die bessere Reihenfolge:

1. Zuerst das gemeinsame Datenmodell entwerfen. Vor jeder Systemkonfiguration festlegen, wie ein Business Partner aussieht, wie Accounts und Kontakte strukturiert sind und wo Stammdaten gepflegt werden. Das ist eine fachliche Entscheidung, keine technische.
2. S/4HANA zuerst oder parallel zu Sales Cloud aufsetzen, nicht danach. Geht Sales Cloud mit einer Übergangsintegration zum alten ERP live, bauen Sie diese Integration beim S/4HANA-Go-live neu.
3. Die Integrationsszenarien vor dem Go-live definieren. Angebot zu Auftrag, Rechnungssicht und Kundenstamm-Abgleich werden in einer eigenen Integrationsumgebung konfiguriert und getestet; sie lassen sich nicht am Ende anschrauben.
4. Die Integration vor dem Go-live in echten Systemen testen. Die S/4HANA-Seite darf anfangs simuliert werden, aber die Flüsse müssen Ende-zu-Ende getestet sein, bevor der erste echte Auftrag durchläuft.

Die Varianten der Reihenfolge und ihre Abwägungen beschreibt unser Leitfaden zur gemeinsamen Einführung von S/4HANA Public Cloud und Sales Cloud V2. Wenn Sie noch wählen, wer es umsetzt, erklärt unser Leitfaden zum besten SAP Partner für Cloud ERP und CRM in der Schweiz, warum ein Team für beide Hälften zählt.

---

Die meisten Unternehmen stehen irgendwo dazwischen: eines oder beide Systeme im Einsatz, aber nicht vollständig verbunden. Das fünftägige S/4HANA-Readiness-Assessment liefert Umfang, Reihenfolge und Kostenbandbreite für beide Hälften, bevor Sie sich festlegen, als erster Schritt einer ERP- und CX-Transformation. Oder sprechen Sie mit uns über Ihr konkretes Setup.

Weiterführende Lektüre:

• Was S/4HANA Public Cloud nativ abdeckt und wofür es Sales/Service Cloud V2 braucht
• S/4HANA Public Cloud + Sales Cloud V2 vs. Salesforce
• SAP S/4HANA Public Cloud: Lösungsübersicht