SAP Sales Cloud V2 mit Business Data Cloud verbinden: Integrationsmuster, die funktionieren

Wir implementieren SAP Sales Cloud V2 und SAP S/4HANA Public Cloud mit einem Team, und lange endete das Analytics-Gespräch rund um das CRM an einem von zwei Orten: Export in ein Data Warehouse, das jemand pflegt, oder mit den eingebetteten Dashboards leben. SAP Business Data Cloud (BDC) öffnet einen dritten Weg. Dieser Beitrag sammelt die Designmuster, die wir anwenden, wenn Sales-Cloud-V2-Daten in BDC auf ERP-Daten treffen, und die Fehler, von denen wir Kunden abraten.

Kurzfassung: Nutzen Sie SAP-Datenprodukte überall, wo es sie gibt, und prüfen Sie den Katalog für Ihr Release, bevor Sie etwas bauen. Wo Sales-Cloud-V2-Daten noch nicht als Datenprodukt verfügbar sind, laden Sie sie einmal in Datasphere und führen sie als eigenes Datenprodukt. Machen Sie Pipeline-to-Cash zum ersten Modell, stimmen Sie drei Join-Schlüssel früh ab, lassen Sie Echtzeitbedarf in der Anwendungsintegration und lassen Sie alle Konsumenten dasselbe semantische Modell lesen.

Womit BDC arbeitet

SAP hat Business Data Cloud im Februar 2025 angekündigt. Das Angebot vereint SAP Datasphere, SAP Analytics Cloud, SAP Business Warehouse und SAP Databricks in einem verwalteten Angebot (SAP Learning: Introducing SAP Business Data Cloud). Der zentrale Baustein ist das Datenprodukt, das SAP als verfeinerten Datensatz mit beschreibenden Metadaten und einem Zugangsport oder einer API beschreibt (SAP News, Oktober 2025). Auf den Datenprodukten baut SAP intelligente Anwendungen (früher Insight Apps genannt) auf; eine Anwendung für Revenue Intelligence war im Oktober 2025 in einer eingeschränkten Vorschau.

Für CRM-Architekten heisst das zweierlei. Erstens kommt ein Teil der benötigten Daten von SAP modelliert und gepflegt an. Zweitens muss der Rest weiterhin eingebracht und modelliert werden, und die Qualität dieser Arbeit entscheidet, ob sich die Plattform auszahlt. Wie SAP-verwaltete Datenprodukte aktiviert und konsumiert werden, dokumentiert SAP Help.

Die Muster im Überblick

Muster	Einsetzen für	Vermeiden für
1. Datenprodukte zuerst	Standardentitäten, die SAP für Ihr Release liefert	Nachbau von Daten, die SAP für Sie pflegt
2. Pipeline-to-Cash als erstes Modell	Vertrieb und Finanzen mit unterschiedlichen Zahlen	Start mit fünf Domänen gleichzeitig
3. Echtzeit bleibt in der Anwendungsschicht	Angebote, Verfügbarkeit, Preise am Verkaufspunkt	Dashboards, die «sicherheitshalber» Live-Daten wollen
4. Ein semantisches Modell, viele Konsumenten	SAC-Stories, Databricks-Notebooks, Joule	Teameigene Kopien von «Umsatz»

Muster 1: Datenprodukte zuerst, eigenes Datenprodukt als Zweites

Der Reflex aus zehn Jahren CRM-Analytics ist eine Extraktionspipeline. Beginnen Sie einen Schritt früher: Öffnen Sie den Datenprodukt-Katalog für Ihr Release und prüfen Sie, welche Entitäten SAP liefert. Die Beispiele, die SAP beim Start nannte, waren Daten aus S/4HANA, SAP Ariba und SuccessFactors; gehen Sie also nicht davon aus, dass jedes Sales-Cloud-V2-Objekt bereits vorhanden ist. Jeder Extraktor, den Sie neben ein bestehendes Datenprodukt bauen, ist eine Altlast mit Ihrem Namen darauf: Er bricht, wenn sich eine API ändert, und er bringt die Frage «welcher Opportunity-Betrag ist das?» zurück.

Wo es für die benötigten CRM-Entitäten (Accounts, Opportunities, Aktivitäten) kein SAP-Datenprodukt gibt, bringen Sie sie einmal und bewusst ein:

• Ladeweg: die Sales-Cloud-V2-APIs oder ein Replikationsfluss nach SAP Datasphere, ein Space für CRM-Daten, keine Nebenkopien.
• Als Produkt führen: ein Verantwortlicher, eine dokumentierte Definition pro Kennzahl, ein mit dem Fachbereich vereinbarter Aktualisierungsrhythmus.
• Den Ausstieg planen: Sobald SAP ein gleichwertiges Datenprodukt liefert, stellen Sie die Konsumenten darauf um und legen Ihren Fluss still. Benennen Sie die Flüsse so, dass dieser Wechsel später eine Checkliste ist und keine Untersuchung.

Erweiterungsfelder brauchen einen eigenen Schritt. Trägt Ihre Sales Cloud V2 eigene Felder, etwa Maschinentyp, Projektphase oder AVC-Konfigurationsdaten, planen Sie, wie jedes davon in die semantische Schicht gelangt und wem es gehört. Auf einem sauberen Tenant sind das Stunden Modellierung pro Feldgruppe, nicht Wochen.

Muster 2: Pipeline-to-Cash als erstes Modell

Jeder Kunde fragt danach; wenige haben es. Opportunities liegen im CRM, Aufträge und Rechnungen im ERP, und die Verbindung dazwischen ist eine vierteljährliche Excel-Übung. Mit CRM- und S/4HANA-Daten in einem BDC-Tenant wird Pipeline-to-Cash zur Modellierungsaufgabe statt zum Integrationsprojekt.

Die Join-Schlüssel entscheiden, ob es funktioniert:

• Account zu Geschäftspartner. Im integrierten Stack werden Sales-Cloud-V2-Accounts von oder zu S/4HANA-Geschäftspartnern repliziert, der Schlüssel existiert also meist. Prüfen Sie vor der Modellierung Dubletten und Accounts, die nur im CRM angelegt wurden.
• Opportunity zu Kundenauftrag. Die Verbindung existiert nur, wenn der Prozess sie erzeugt: Ein aus der Opportunity erstelltes Angebot oder ein Auftrag trägt die Referenz. Direkt im ERP erfasste Aufträge brauchen eine Zuordnungsregel, sonst bleiben sie ausserhalb des Trichters.
• Produkt zu Material. Produktstammdaten sollten aus S/4HANA kommen. Freitextprodukte in Opportunities lassen sich später nicht verbinden.

Das Modell selbst bleibt einfach: gewonnene Opportunities gegen Auftragseingang und fakturierten Umsatz, nach Verkaufsorganisation, Produktgruppe und Periode. Der Ertrag ist Forecast-Genauigkeit, gemessen an dem, was tatsächlich ausgeliefert wurde, die Zahl, die CRM-Disziplin vom Managementwunsch zur Kennzahl macht. Die Integrationsarchitektur zwischen Sales Cloud V2 und S/4HANA Public Cloud beschreibt, wo diese Schlüssel auf der Transaktionsseite entstehen.

Muster 3: Echtzeit gehört nicht in die Analytics-Schicht

Der häufigste Designfehler, dem wir begegnen, ist operativer Echtzeitbedarf, der über die Analytics-Plattform geleitet wird. Wer vor einem Angebot Live-Bestand und Preise braucht, bekommt sie aus der Anwendungsintegration zwischen Sales Cloud V2 und S/4HANA, nicht aus BDC. Analytics verträgt Aktualisierungszyklen; Angebote nicht.

Ziehen Sie die Linie ausdrücklich im Architekturdokument: Transaktionen über Anwendungs-APIs, Analyse über Datenprodukte. Architekturen, die das vermischen, erben die Schwächen beider Seiten, langsame Angebote und fragile Dashboards.

Muster 4: Ein semantisches Modell, viele Konsumenten

Steht das Fundament, widerstehen Sie Varianten pro Team. Die SAC-Story für das Management, das Databricks-Notebook der Analystin und ein Joule-Agent, der «Wie steht die Q4-Pipeline gegenüber dem Vorjahr?» beantwortet, sollten dasselbe gepflegte Modell lesen. Sobald jemand seine eigene Version von Umsatz abzweigt, bauen Sie das Problem wieder auf, für dessen Beseitigung Sie bezahlt haben. Governance ist hier das Produkt selbst: eine Definition pro Kennzahl, ein Verantwortlicher pro Domäne, Änderungswünsche über diesen Verantwortlichen.

Hier beginnt Datenqualität mehr zu zählen als Werkzeuge. Doppelte Accounts und verwaiste Opportunities fliessen direkt in jeden Konsumenten. Die Reihenfolge der Korrektur beschreiben wir in Warum Ihre CRM-Daten nur so gut sind wie Ihr Datenfundament.

Wo das hineinpasst

Diese Serie begann mit was BDC ist und was mit Datasphere geschieht. Die Muster oben sind der praktische Mittelteil. Der strategische Grund dahinter ist KI: Agenten sind nur so gut wie das Modell, das sie lesen, und ein gepflegtes Pipeline-to-Cash-Modell ist das, was ein Joule-Agent braucht, um Umsatzfragen mit derselben Herkunft wie ein Bericht zu beantworten.

CRM- und ERP-Analytics auf einem Fundament gelingen am einfachsten, wenn ein Team beide Seiten der Nahtstelle kennt. So arbeiten wir, siehe warum ERP und CRM aus einer Hand zählen. Wenn Sie Sales Cloud V2 betreiben und Ihre Analysen noch in Exporten leben, beginnt unsere BDC-Praxis genau mit diesem ersten Modell.

Häufige Fragen

Gibt es native Datenprodukte für Sales Cloud V2 in BDC?

Prüfen Sie den Datenprodukt-Katalog für Ihr Release, bevor Sie etwas entwerfen. Wo SAP ein Datenprodukt für die benötigten Entitäten liefert, nutzen Sie es. Wo nicht, laden Sie die Sales-Cloud-V2-Daten einmal über die APIs oder einen Replikationsfluss in Datasphere, modellieren sie als eigenes, gepflegtes Datenprodukt und ersetzen es, sobald SAP ein gleichwertiges liefert.

Kann ich Sales-Cloud-V2- und S/4HANA-Daten in einem BDC-Modell kombinieren?

Ja, und genau darum geht es. Gewonnene Opportunities aus Sales Cloud V2 werden in einem semantischen Modell mit Kundenaufträgen, Fakturen und Margen aus S/4HANA verbunden. Das ergibt Pipeline-to-Cash-Reporting ohne eigene Middleware. Die Join-Schlüssel (Account zu Geschäftspartner, Opportunity zu Kundenauftrag, Produkt zu Material) brauchen einen Abstimmungsworkshop, danach halten sie.

Was ist mit Echtzeitanforderungen?

Halten Sie sie aus der Analytics-Schicht heraus. Pipeline- und Umsatzanalysen funktionieren mit Aktualisierungszyklen. Wer vor einem Angebot Live-Bestand oder Preise braucht, erhält sie aus der Anwendungsintegration zwischen Sales Cloud V2 und S/4HANA, nicht aus BDC. Beides in einer Architektur zu vermischen, ist der häufigste Designfehler, den wir sehen.

Wie gelangen eigene Erweiterungsfelder aus Sales Cloud V2 in BDC?

Planen Sie sie ausdrücklich ein. Erweiterungsfelder wie Maschinentyp oder Projektphase gehören zu keinem Standardmodell, deshalb braucht jedes ein Mapping in die semantische Schicht und einen benannten Verantwortlichen. Auf einem sauberen Tenant ist das eine Modellierungsaufgabe von Stunden pro Feldgruppe, kein eigenes Projekt.