BDC und Datasphere: Was sich ändert, was bleibt

Als SAP Datasphere in die Business Data Cloud überführte, war die erste Frage jedes Kunden mit laufendem Datasphere-Tenant dieselbe: Was passiert mit dem, was wir gebaut haben? Die kurze Antwort ist beruhigend; der interessante Teil ist, was Sie nicht mehr bauen sollten.

Die Kernaussage in einem Satz: Ihre Datasphere-Investition überlebt — aber selbst gebaute Replikationsflüsse sind ab jetzt technische Schulden mit Ablaufdatum.

Was bleibt

Datasphere verschwindet nicht. Es läuft als Modellierungs- und Integrationsschicht innerhalb von BDC weiter:

• Spaces und Modelle bleiben erhalten. Ihre semantischen Modelle, Views und Datenflüsse funktionieren weiter — BDC konsumiert sie, statt sie zu ersetzen.
• SAP Analytics Cloud bleibt als Visualisierungsschicht, jetzt im Bundle statt separat kontrahiert.
• Skills bleiben wertvoll. Wer in Datasphere modellieren kann, ist genau die Person, die in BDC Datenprodukte mit Geschäftsfragen verdrahten wird.

Wenn Sie in den letzten Jahren in Datasphere investiert haben, war nichts davon umsonst. Das ist der Unterschied zwischen einer Evolution und den Plattform-Beerdigungen, denen SAP-Kunden schon beigewohnt haben (dasselbe haben wir über Sales Cloud V1 zu V2 gesagt: Neubauten sind ehrlich, Umbenennungen nicht — BDC ist eher ein Neubau der Verpackung um einen überlebenden Kern).

Was sich ändert

Drei Dinge sind wirklich anders:

1. Paketierung und Lizenzierung. Ein BDC-Vertrag in Capacity Units deckt Datasphere, SAP Analytics Cloud und die eingebettete Databricks-Engine ab. Die Ära, drei SAP-Datenprodukte separat zu verhandeln, endet mit Ihrer nächsten Verlängerung.
2. Datenprodukte ersetzen selbst gebaute Extraktion. Wo SAP ein Datenprodukt liefert — S/4HANA Finanzen, Pipeline aus Sales Cloud V2, SuccessFactors — wird der Replikationsfluss, den Ihr Team für dieselben Daten gebaut hat, zum Altbestand. SAP pflegt das Datenprodukt durch die Releases; Ihren Custom-Flow pflegt niemand ausser Ihnen.
3. Machine Learning zieht hinter den Zaun. Workloads, für die man SAP-Daten bisher auf eine separate ML-Plattform herauskopieren musste, laufen jetzt in eingebettetem Databricks, unter derselben Governance. Wer je einen Datenschutz-Review einer Schatten-Analytics-Plattform durchgesessen hat, erkennt hier die leise Schlagzeile. Unter Schweizer nDSG und DSGVO ist “die Daten haben die SAP-Governance nie verlassen” ein Satz, den Ihr Datenschutzbeauftragter gerne sagen wird.

Was Sie nicht mehr bauen sollten

Konkret, ab diesem Jahr:

• Bauen Sie keine neuen Replikationsflüsse für Daten, die SAP als Datenprodukt liefert. Prüfen Sie zuerst den Katalog; bauen Sie nur für die Lücken.
• Modellieren Sie generische Entitäten nicht mehr von Grund auf. “Kunde”, “Kundenauftrag”, “Rechnung” kommen semantisch modelliert an. Ihr Modellierungsaufwand gehört in die letzte Meile — Ihre Branchenlogik und KPIs — nicht in die erste.
• Behandeln Sie S/4HANA- und CX-Analytics nicht mehr als getrennte Projekte. Auf dem integrierten Stack bedient ein Fundament beide. Sie zu trennen, reproduziert genau das Problem der widersprüchlichen Zahlen, das BDC beenden soll.

Das Verlängerungsgespräch

Timen Sie Ihren Schritt kommerziell. Wenn Ihr Datasphere- oder SAC-Vertrag in den nächsten 12 Monaten zur Verlängerung ansteht, verhandeln Sie die BDC-Konversion bei der Verlängerung — dann ist SAP flexibel. Bringen Sie Ihre Verbrauchshistorie mit: Die Capacity-Unit-Dimensionierung belohnt Kunden, die ihre tatsächliche Nutzung kennen, statt die Standard-T-Shirt-Grösse zu akzeptieren.

Und halten Sie den Scope ehrlich. Der richtige erste BDC-Schritt nach der Konversion ist kein Plattform-Migrationsprojekt — es ist eine Domäne, ein Satz Datenprodukte, eine Insight App, die eine Frage beantwortet, die Ihr Management bereits stellt. Die Plattformarbeit folgt der Nachfrage, nie umgekehrt.