BDC und Datasphere: was sich ändert, was bleibt

Als SAP Datasphere in die Business Data Cloud integriert hat, stellten Kunden mit einem laufenden Datasphere-Tenant immer dieselbe erste Frage: Was geschieht mit dem, was wir gebaut haben? Die kurze Antwort beruhigt. Nützlicher ist der zweite Teil der Antwort: was Sie nicht mehr bauen sollten.

Kurzfassung: Ihre Datasphere-Investition bleibt erhalten: Spaces, Modelle, Flows und Know-how bleiben, und SAP Analytics Cloud sowie SAP BW werden Komponenten derselben Plattform. Neu sind die Verpackung (ein BDC-Vertrag in Capacity Units), von SAP gepflegte Datenprodukte, die selbst gebaute Replikation für Standard-SAP-Daten ersetzen, SAP Databricks für Machine Learning innerhalb der SAP-Governance und ein Stammdatenmanagement, das in BDC wandert. Bauen Sie keine Flows mehr für Daten, die SAP bereits liefert, und legen Sie die Lizenzumstellung auf die nächste Verlängerung.

Was bleibt

Datasphere verschwindet nicht. Es bleibt die Integrations- und semantische Modellierungsschicht innerhalb von BDC; SAPs Einführung in die Business Data Cloud führt es unter den Kernkomponenten auf:

• Spaces und Modelle bleiben erhalten. Semantische Modelle, Views und Datenflüsse funktionieren weiter. BDC nutzt sie, statt sie zu ersetzen. Die Dokumentation zu SAP Datasphere bleibt die Referenz für die Modellierungsschicht.
• SAP Analytics Cloud bleibt als Visualisierungs- und Planungsschicht, jetzt Teil des Bundles statt eines separaten Vertrags.
• SAP BW bleibt erreichbar. BW und die BW Private Cloud Edition sind Komponenten von BDC; bestehende Warehouse-Modelle müssen also nicht am ersten Tag neu gebaut werden.
• Das Know-how bleibt wertvoll. Wer in Datasphere modellieren kann, verbindet in BDC die Datenprodukte mit den Geschäftsfragen.

Wer in den vergangenen Jahren in Datasphere investiert hat, hat nichts verschwendet. Es handelt sich um eine Weiterentwicklung der Verpackung rund um einen bleibenden Kern, nicht um einen Plattformwechsel, wie ihn SAP-Kunden schon erlebt haben (der Wechsel von Sales Cloud V1 zu V2 war ein echter Neubau; dieser Schritt ist es nicht).

Was sich ändert

Vier Dinge sind tatsächlich anders.

1. Verpackung und Lizenzierung. Ein BDC-Vertrag umfasst Datasphere, SAP Analytics Cloud, SAP BW und SAP Databricks. SAP lizenziert BDC auf Basis von Capacity Units; wie ein eigenständiger Datasphere- oder SAC-Vertrag überführt wird, hängt von Ihrem Vertrag ab.
2. Datenprodukte ersetzen selbst gebaute Extraktion. Ein Datenprodukt ist «ein aufbereiteter Datensatz, Metadaten, die ihn beschreiben, und ein Zugangspunkt oder eine API» (SAP News). Wo SAP eines liefert (die erste Welle konzentrierte sich auf S/4HANA, SAP Ariba und SAP SuccessFactors), wird der Replikationsflow, den Ihr Team für dieselben Daten gebaut hat, zur Altlast. SAP pflegt das Datenprodukt durch alle Releases; Ihren eigenen Flow pflegt niemand ausser Ihnen. Für CX-Daten wie Sales Cloud V2 prüfen Sie den Katalog für Ihr Release und behalten die Datasphere-Replikation dort, wo es noch kein Datenprodukt gibt.
3. Machine Learning zieht hinter den Zaun. Workloads, für die man SAP-Daten früher auf eine separate ML-Plattform kopieren musste, laufen in SAP Databricks unter derselben Governance, und BDC Connect teilt Datenprodukte ohne Kopie mit einer bestehenden Databricks-, Snowflake- oder anderen Partnerplattform. Unter dem Schweizer nDSG und der DSGVO ist «die Daten haben die SAP-Governance nie verlassen» ein Satz, den Ihre Datenschutzverantwortlichen schätzen werden.
4. Stammdatenmanagement wandert in BDC. Im Mai 2026 hat SAP SAP Master Data Governance und SAP HANA Cloud zu Kernkomponenten von BDC gemacht und die Übernahme von Reltio abgeschlossen, dessen Multi-Domain-Stammdatenmanagement SAP in BDC bringt (SAP News). Die Qualität der Kunden- und Materialstammdaten, lange ein eigenes Projekt, wird Teil derselben Plattform.

Was Sie nicht mehr bauen sollten

Konkret, ab heute:

• Keine neuen Replikationsflows für Daten, die SAP als Datenprodukt liefert. Zuerst den Katalog prüfen, nur für die Lücken bauen.
• Keine generischen Entitäten mehr von Grund auf modellieren. Kunde, Kundenauftrag und Rechnung kommen semantisch modelliert, wo ein Datenprodukt existiert. Ihr Modellierungsaufwand gehört auf die letzte Meile: Ihre Branchenlogik, Ihre KPI, Ihre Erweiterungsfelder.
• SAP-Daten nicht mehr für Machine Learning herauskopieren, wenn SAP Databricks oder eine Freigabe ohne Kopie die Aufgabe innerhalb der Governance-Grenze erledigen.
• S/4HANA- und CX-Analytics nicht mehr als getrennte Projekte führen. Im integrierten Stack dient ein Fundament beiden. Wer sie trennt, erzeugt wieder das Problem widersprüchlicher Zahlen, das BDC beenden soll. Wie die CRM-Seite dazukommt, zeigen die Integrationsmuster zwischen Sales Cloud V2 und BDC.

Eine kurze Migrations-Checkliste

Schritt	Was prüfen	Ergebnis
1. Bestandsaufnahme	Genutzte Spaces, Modelle, Replikationsflows, BW-Queries	Liste der Objekte mit Verantwortlichen und Nutzung
2. Katalogabgleich	Welche Flows ein SAP-Datenprodukt Ihres Releases doppeln	Flows zum Abbau, Flows zum Behalten
3. Vertrag	Verlängerungsdaten für Datasphere und SAC, tatsächlicher Verbrauch	Zeitpunkt der Konversion und Grundlage der Dimensionierung
4. BW-Pfad	Welche BW-Modelle bleiben, welche auf Datenprodukte wechseln	Gestaffelter Plan statt Big-Bang-Migration
5. Stammdaten	Verantwortung für Kunden- und Materialattribute	Eine benannte Person pro Domäne
6. Erster Anwendungsfall	Eine Frage, die das Management bereits stellt	Umfang des ersten BDC-Release

Das Gespräch zur Vertragsverlängerung

Planen Sie den Wechsel kommerziell. Wird Ihr Datasphere- oder SAC-Vertrag in den nächsten zwölf Monaten verlängert, verhandeln Sie die BDC-Konversion bei der Verlängerung. Bringen Sie Ihre Verbrauchshistorie mit: Die Dimensionierung der Kapazität begünstigt Kunden, die ihre tatsächliche Nutzung kennen, gegenüber jenen, die eine Standardgrösse akzeptieren.

Halten Sie den Umfang bescheiden. Der richtige erste Schritt nach der Konversion ist kein Plattform-Migrationsprojekt, sondern eine Domäne, die dazugehörigen Datenprodukte und eine Analyse, die eine Frage beantwortet, die Ihr Management bereits stellt. Die Verantwortung für Stammdaten kommt zuerst; warum CRM-Daten vom Datenfundament abhängen beschreibt die Reihenfolge. Die Plattformarbeit folgt der Nachfrage, nicht umgekehrt.

Wenn Sie für die Bestandsaufnahme ein zweites Paar Augen wünschen, sprechen Sie mit uns. Spadoom liefert den ERP-Kern und den CX-Stack mit einem Team; deshalb betrachten wir beide Seiten des Datenmodells gleichzeitig.

Häufige Fragen

Verschwindet SAP Datasphere mit Business Data Cloud?

Nein. Datasphere bleibt die Integrations- und Modellierungskomponente innerhalb von BDC; Spaces, Modelle und Datenflüsse werden übernommen. Was sich ändert, ist die Verpackung: Neue Funktionen, Datenprodukte und die Lizenzierung kommen jetzt unter dem BDC-Dach.

Werden bestehende Datasphere-Lizenzen in BDC überführt?

SAP lizenziert BDC auf Basis von Capacity Units; wie ein eigenständiger Datasphere- oder SAP-Analytics-Cloud-Vertrag überführt wird, hängt von Ihrem Vertrag ab. Der praktische Rat: die Konversion auf die nächste Verlängerung legen, echte Verbrauchszahlen mitbringen und das Bundle verhandeln, nicht die Einzelkomponenten.

Sollte ich 2026 noch ein neues Datasphere-Projekt starten?

Starten Sie es als BDC-Projekt. Die Arbeit ist weitgehend dieselbe (Spaces, Modelle, Flows), aber Vertrag und Architektur sollten von der BDC-Paketierung ausgehen, von Datenprodukten überall dort, wo SAP sie liefert, und von selbst gebauter Replikation nur dort, wo es noch kein Datenprodukt gibt.

Was geschieht mit SAP BW in BDC?

SAP BW, auch die BW Private Cloud Edition, ist eine der BDC-Komponenten. Bestehende BW-Modelle können weiterlaufen, während neue Analysen auf Datenprodukten und Datasphere entstehen; der Wechsel lässt sich also staffeln statt in einem einzigen Migrationsprojekt zu erledigen.