SAP Data Products bauen: Der Weg vom Quellsystem zum wiederverwendbaren Datenprodukt

Ihr Konzern hat S/4HANA in der Cloud, daneben laufen noch zwei ECC-Systeme, ein BW und eine Handvoll Drittsysteme, die niemand ablösen will. In SAP Business Data Cloud sehen Sie sauber aufbereitete Data Products – aber nur für die Systeme, die SAP direkt angebunden hat. Alles andere bleibt außen vor. Die Frage, die dann kommt, lautet nicht "Was ist ein Data Product?", sondern: Wie bekomme ich meine eigenen Daten in dieselbe Struktur?

Genau darum geht es hier.

Stand dieser Anleitung: 28. Juli 2026

Das SAP Data Product Studio ist zum Redaktionsschluss nicht allgemein verfügbar. Die hier beschriebenen Abläufe beruhen im Kern auf einer öffentlichen SAP-Expertensession vom März 2026, in der eine Vorabversion aus einem Entwicklungssystem gezeigt wurde. SAP hat dort ausdrücklich darauf hingewiesen, dass Funktionsumfang, Bezeichnungen und Termine sich ändern können.

Widersprüchliche Terminangaben: Auf der SAP TechEd 2025 wurde als Verfügbarkeitsfenster die erste Jahreshälfte 2026 kommuniziert; in der Session im März 2026 nannte SAP das dritte Quartal 2026. Der Termin ist also bereits einmal verschoben worden. Prüfen Sie vor jeder Planung den SAP Road Map Explorer – nicht diesen Artikel.

Was Sie heute schon umsetzen können, steht in Abschnitt 4 und in der Roadmap-Tabelle am Ende.

Das Ziel in einem Satz

Sie nehmen Daten aus einem System, das SAP Business Data Cloud nicht von Haus aus kennt – ECC, BW, ein Drittsystem – und stellen sie als versioniertes, katalogisiertes, über Delta Sharing konsumierbares Data Product bereit, das sich für nachgelagerte Anwendungen nicht mehr von einem SAP-eigenen Data Product unterscheidet.

1. Was ein Data Product ausmacht – und was nicht

Der häufigste Fehler passiert vor dem ersten Klick: Eine Tabelle wird exponiert und "Data Product" genannt. Das ist keins. SAP definiert fünf Eigenschaften, und alle fünf sind Arbeit:

Es ist ein semantisch zusammenhängender Datensatz. Nicht eine Tabelle, sondern eine Menge von Objekten, die fachlich zusammengehören – Stammdaten mit Texten und Hierarchien in einem, Bewegungsdaten in einem anderen. Der Zuschnitt ist eine Design-Entscheidung, keine technische.

Es ist wiederverwendbar. Klein genug, dass man es in mehreren Kontexten einsetzen kann. Groß genug, dass es für sich allein Sinn ergibt. Diese beiden Anforderungen ziehen in entgegengesetzte Richtungen – das auszubalancieren ist die eigentliche Modellierungsarbeit.

Es ist gut beschrieben. Und zwar zweifach: eine fachliche Beschreibung, an der eine Fachanwenderin im Katalog erkennt, ob dies der richtige Datensatz für ihre Auswertung ist. Und saubere Semantik – Feldtypen, Währungskennzeichen, Aggregationsverhalten, Assoziationen zwischen den Entitäten. Der Beschreibungstext allein reicht nicht.

Es ist einfach konsumierbar. Über einen definierten Endpunkt, in SAPs Fall Delta Sharing. Damit verbunden ist eine Zusage, die viele unterschätzen: Sie verpflichten sich zu einer stabilen Schnittstelle. Wer ein Data Product veröffentlicht, kann es nicht mehr beliebig ändern – dazu unten mehr beim Thema Versionierung.

Es ist auffindbar. Über den Katalog in SAP Business Data Cloud. Was dort nicht gefunden wird, existiert für die Organisation nicht.

Delta Sharing ist dabei ein offenes Protokoll für Datenaustausch ohne Kopie: Der Konsument greift auf die Daten zu, statt sie zu replizieren.

2. Brauchen Sie überhaupt ein eigenes Data Product?

Fünf Kriterien. Wenn Sie weniger als drei mit Ja beantworten, bauen Sie besser einen View in SAP Datasphere und sparen sich den Governance-Aufwand.

Mehr als ein Konsument. Ein Data Product zahlt sich erst aus, wenn mindestens zwei unabhängige Verbraucher darauf zugreifen – sonst ist es eine aufwendig verpackte Einzellieferung.
Konsumenten außerhalb Ihres Modellierungswerkzeugs. Databricks, eine BTP-Anwendung, ein KI-Szenario, ein anderer Fachbereich. Wenn alles in Datasphere bleibt, reicht Datasphere.
Zusage über Stabilität ist gewünscht. Sie wollen sich auf eine Struktur festlegen und Änderungen kontrolliert über Versionen fahren.
Auffindbarkeit ist ein Problem. Es gibt genug Datentöpfe, dass Menschen suchen müssen.
Klare fachliche Verantwortung existiert. Es gibt jemanden, der das Ding besitzt. Ohne benennbaren Owner wird aus einem Data Product zuverlässig eine verwaiste Tabelle mit Zertifikat.

3. Voraussetzungen

Sie haben eine SAP Business Data Cloud Subscription. Data Products aus BDC über den regulären Weg zu konsumieren, setzt diese voraus – auch dann, wenn Ihre HANA Cloud in BTP statt in BDC läuft; in dem Fall kommt eine Destination-Verknüpfung dazu.
Sie haben einen SAP Datasphere Tenant, der Teil einer BDC Formation ist. Der Datasphere Object Store ist der Ablageort für kundeneigene Data Products – der Object Store der Foundation Services ist SAP-verwaltet und für Ihre eigenen Produkte nicht vorgesehen.
Sie haben in Datasphere einen Space mit Object-Store-Fähigkeit und dort das Recht, lokale Tabellen auf Dateiebene anzulegen.
Ihre Quellsysteme sind über Datasphere erreichbar – als Connection, per Replication Flow, über SQL. Diese Verbindungen bauen Sie nicht neu; Sie benutzen die vorhandenen.
Es gibt eine benannte fachliche Verantwortung für den Datensatz. Person oder Verteilerliste, kein Team-Postfach ohne Adressaten.
Für den Weg durch die Systemlandschaft: mehrere Formations oder zumindest getrennte Tenants für Entwicklung, Test und Produktion.

4. Die Landkarte: vier Wege, drei davon führen woanders hin

Es kursieren mehrere SAP-Werkzeuge mit "Data Product" im Namen oder in der Funktionsbeschreibung. Die Verwechslungsgefahr ist real und kostet Projekte Wochen.

Werkzeug	Was es tut	Wofür es nicht taugt
Data Product Generator (in BW)	Nimmt einen InfoProvider, schiebt die Daten in den Datasphere Object Store, legt die lokalen Tabellen auf Dateiebene an, richtet die Subscription für die Replikation ein und gruppiert die Objekte	Erzeugt trotz des Namens kein fertiges Data Product – es fehlt die Hülle. Und es ist eine BW-Funktion, also ausschließlich für BW-Quellen
Data Sharing Cockpit (in Datasphere)	Ursprünglich für SQL-basiertes Teilen zwischen Datasphere-Tenants gebaut; inzwischen um die Erzeugung von Data Products auf Delta-Sharing-Basis erweitert	Ist die Übergangslösung, bis das Data Product Studio da ist. Versionsverwaltung und Transport gehen bestenfalls über Behelfe; abgeleitete Data Products mit Herkunftsnachweis sind nicht vorgesehen
Data Composer	Führt Datensätze aus mehreren Systemen auf Datenebene zusammen – Richtung "Golden Record", also eine Vereinigung, kein Join. Kommt aus dem Customer-Data-Platform-Umfeld	Ist kein Nachfolger und keine Umbenennung des Data Product Studios. Erzeugt am Ende zwar auch ein Data Product, ist aber an ein Fachbereichsprodukt gekoppelt und nicht Teil des BDC-Grundumfangs
Data Product Studio	Das kommende Werkzeug: Data-Product-first, im BDC Cockpit angesiedelt, laufzeitunabhängig gedacht, mit Versionsverwaltung und Transport über die Landschaft	Noch nicht allgemein verfügbar (Stand Juli 2026)

Was das praktisch heißt: Wenn Sie heute liefern müssen, bauen Sie über Data Sharing Cockpit – und zwar so, dass der Wechsel später wenig kostet. Konkret: den Zuschnitt und die Semantik jetzt schon so festlegen, wie Sie sie im Studio hätten, und Versionierung fachlich dokumentieren, auch wenn das Werkzeug sie noch nicht abbildet.

Ein zweiter Weg existiert für Ergebnisse aus SAP Databricks: Dort legen Sie das Ergebnis als Delta Table ab, erzeugen im Catalog Explorer einen Delta Share mit SAP Business Data Cloud als Empfänger und liefern zwei Metadatendateien mit – eine ORD-Datei, die Ressourcen und Fähigkeiten beschreibt, und eine CSN-Datei für die Struktur. Erst damit wird aus dem geteilten Datensatz ein Data Product.

5. Schritt für Schritt

Der Ablauf beschreibt den Weg über das Data Product Studio, weil er die Zielarchitektur zeigt. Die Schritte 1 bis 4 gelten unverändert auch für den heutigen Weg über das Data Sharing Cockpit – dort entfallen lediglich die Schritte 8 und 9.

Schritt 1: Quelle an Datasphere anbinden und Daten landen lassen

Was Sie tun: Sie verbinden Ihr Quellsystem – ECC, BW, Drittsystem – mit SAP Datasphere und replizieren die benötigten Tabellen in den Object Store. Aus BW heraus übernimmt das der Data Product Generator; für alle anderen Quellen nutzen Sie die vorhandenen Connections und Replication Flows.

Erfolgskriterium: In Ihrem Object-Store-Space liegen lokale Tabellen auf Dateiebene mit erwarteter Satzanzahl, und die Replikation läuft ohne Fehler durch.

Häufigste Fehlerursache: Es wird versucht, die Verbindung im Data Product Studio zu suchen. Die gibt es dort nicht. Das Studio baut keine Quellanbindungen – es benutzt, was in Datasphere schon da ist. Die gesamte Integrationsarbeit passiert davor.

Schritt 2: Space-Struktur als Herkunftsnachweis anlegen

Was Sie tun: Sie legen pro Quellsystem einen eigenen Object-Store-Space an – nicht einen Sammelspace für alles. SAP plant dedizierte Spaces für die Data-Product-Erstellung; unabhängig davon ist die Trennung nach Quellsystem heute schon die richtige Entscheidung.

Erfolgskriterium: Man kann an einem Space ablesen, aus welchem System seine Daten stammen.

Häufigste Fehlerursache: Ein gemeinsamer Space für zwei ECC-Mandanten. Danach ist am Data Product nicht mehr erkennbar, welche Zahl aus welchem System kommt – und der Herkunftsnachweis, der für Governance und spätere abgeleitete Produkte gebraucht wird, ist zerstört. Das nachträglich aufzutrennen bedeutet, alle nachgelagerten Objekte anzufassen.

Schritt 3: Zuschnitt festlegen

Was Sie tun: Sie entscheiden, welche Entitäten in ein Data Product gehören. Faustregel: Stammdaten mit ihren Texten und Hierarchien bilden eine Einheit, Bewegungsdaten eine zweite. Die Verknüpfung passiert beim Konsumenten, nicht im Produkt.

Erfolgskriterium: Sie können in einem Satz sagen, wofür das Data Product da ist, ohne "und" zu benutzen.

Häufigste Fehlerursache: Der Zuschnitt folgt der Quellstruktur statt der fachlichen Frage. Ein Data Product, das entsteht, weil diese fünf Tabellen im selben Schema lagen, wird von niemandem wiederverwendet.

Das ist der Point of no Return. Ab hier zieht jede Änderung am Zuschnitt eine neue Hauptversion nach sich – mit allem, was daran hängt.

Schritt 4: Semantik und Beschreibung anreichern

Was Sie tun: Feldtypen prüfen, Währungs- und Mengenkennzeichen setzen, Aggregationsverhalten festlegen, Kennzahlen von Dimensionen trennen, Assoziationen zwischen den Entitäten definieren. Dazu die fachliche Beschreibung: Was steckt drin, für welche Fragestellung ist es gedacht, was ist es ausdrücklich nicht.

Erfolgskriterium: Jemand, der das Quellsystem nicht kennt, kann anhand der Katalogeinträge entscheiden, ob dies der richtige Datensatz ist.

Häufigste Fehlerursache: Die Beschreibung wird als Pflichtfeld behandelt und mit dem Tabellennamen gefüllt. Damit ist die Auffindbarkeit erledigt – und Auffindbarkeit ist eine der fünf konstituierenden Eigenschaften, nicht ein nettes Extra.

Schritt 5: Quellobjekte im Studio auswählen

Was Sie tun: Im BDC Cockpit über den App-Switcher ins Data Product Studio wechseln, ein neues Data Product anlegen, den Datasphere-Tenant wählen, darin den Space, darin die Tabellen.

Erfolgskriterium: Die ausgewählten Entitäten erscheinen mit ihrer Semantik – Dimensions- und Faktentabellen sind als solche erkennbar, Kennzahlen und Aggregationen sind übernommen.

Häufigste Fehlerursache: Es wird erwartet, dass das Studio den Datenbestand durchsucht. Das tut es nicht – es fragt den Katalog nach den verfügbaren Objekten. Was im Katalog nicht registriert ist, taucht in der Auswahl nicht auf, auch wenn die Tabelle existiert.

Schritt 6: Ausgabestruktur festlegen

Was Sie tun: In der ersten Ausbaustufe: nichts. Es gibt eine Eins-zu-eins-Abbildung von Quelle auf Ziel. Filter und Projektionen sind vorgesehen, echte Transformationen zunächst nicht.

Erfolgskriterium: Die Ausgabestruktur entspricht der Eingabestruktur.

Häufigste Fehlerursache: Die Erwartung, im Studio modellieren zu können. Das Data Product Studio ersetzt SAP Datasphere nicht. Jede Transformation – Joins, Berechnungen, Bereinigung – passiert vorher in Datasphere über Transformation Flows und Replication Flows. Das Studio legt die Hülle um das Ergebnis. Wer das umdreht, baut an der falschen Stelle.

Schritt 7: Metadaten und Veröffentlichungsangaben

Was Sie tun: Fachlicher Name, Beschreibung, Protokoll (zunächst Delta Sharing), Domäne, Verantwortliche Person oder Verteilerliste, Kategorie – zur Auswahl stehen unter anderem Business Objects, Analytical und Other – sowie die Fachbereichszuordnung.

Erfolgskriterium: Die Filter, die Sie im Katalog später zum Suchen brauchen, sind gefüllt.

Häufigste Fehlerursache: Die Kategorien und Fachbereichsangaben werden als SAP-interne Klassifikation abgetan und leer gelassen. Sie sind die Filterdimensionen im Katalog – dieselben, die Sie vom Business Accelerator Hub kennen. Ihre eigenen Data Products erscheinen dort nicht, aber die Filterlogik im internen Katalog ist dieselbe.

Schritt 8: Laufzeitsysteme zuordnen

Was Sie tun: Für jede Umgebung – Entwicklung, Test, Produktion – festlegen, aus welchem Datasphere-Space die lokalen Tabellen dort bezogen werden.

Erfolgskriterium: Für jede Zielumgebung existiert eine Zuordnung.

Häufigste Fehlerursache: Die Annahme, die Auswahl aus Schritt 5 gelte für alle Umgebungen. Sie gilt für die Entwicklungsumgebung. Wer das übersieht, hat ein Data Product, das sich nicht transportieren lässt – und merkt es zum spätestmöglichen Zeitpunkt.

Schritt 9: Version festlegen und veröffentlichen

Was Sie tun: Version vergeben und Status setzen. Vorgesehen sind Haupt-, Neben- und Patchversionen sowie Zustände von "gespeichert" über eine Test-Bereitstellung bis "aktiv" und "veraltet".

Die Regel dahinter ist die wichtigste des ganzen Verfahrens:

Neben- und Patchversion = verträgliche Änderung. Eine zusätzliche Spalte, eine präzisierte Beschreibung. Bestehende Konsumenten bekommen die Änderung bei der Bereitstellung, ohne etwas zu tun.
Hauptversion = brechende Änderung. Eine gelöschte Spalte, ein geänderter Schlüssel. Beide Hauptversionen laufen dann parallel – für die nachgelagerten Dienste sind es zwei verschiedene Data Products. Konsumenten wechseln aktiv und bewusst.

Erfolgskriterium: Ein Konsument kann sich auf die Struktur verlassen, ohne Ihren Änderungsprozess zu kennen.

Häufigste Fehlerursache: Eine brechende Änderung wird als Nebenversion ausgeliefert, weil sie technisch durchgeht. Damit ist die Zusage gebrochen, die ein Data Product überhaupt erst zu einem macht – und der Schaden trifft Systeme, von denen Sie nichts wissen.

Schritt 10: Zugriff über den Katalog freigeben

Was Sie tun: Konsumenten finden das Data Product im BDC-Katalog, fordern Zugriff an, installieren es in ihrer Umgebung und binden den Delta-Sharing-Endpunkt an – Datasphere, Databricks, eine BTP-Anwendung.

Erfolgskriterium: Ein Konsument, mit dem Sie nicht gesprochen haben, findet das Produkt und kann Zugriff beantragen.

Häufigste Fehlerursache: Bereitstellung und Installation werden verwechselt. Bereitstellung heißt: Das Data Product existiert in einer Formation. Installation heißt: Ein Konsument hat es über den Katalog bezogen. Die Frage "wo ist es bereitgestellt" beantwortet nicht die Frage "wer benutzt es".

6. Interface Data Products – der interessanteste Teil

Diese Funktion wird unterschätzt, weil sie technisch unspektakulär klingt. Ein Interface Data Product ist ein Data Product ohne Quelle und ohne Transformation – es definiert ausschließlich die Ausgabestruktur. Es ist eine Schnittstellenzusage, kein Datensatz.

Der Nutzen entsteht beim Implementieren. SAP liefert für bestimmte Anwendungen ein Interface Data Product aus. Sie erstellen ein eigenes Data Product gegen dieses Interface: Die Ausgabestruktur ist gesperrt – Felder, Spalten, Datentypen liegen fest – und Sie sorgen dafür, dass Ihre Daten in diese Form kommen. Erfüllen Sie das Interface, funktioniert die SAP-Anwendung mit Ihren Daten.

Das Szenario, das den Unterschied macht: Sie sind auf dem Weg zu S/4HANA, aber noch nicht dort. Eine SAP-Anwendung, die Sie einsetzen wollen, erwartet S/4HANA-Data-Products. Über ein Interface Data Product bringen Sie Ihre ECC-Daten in genau diese Struktur – die Anwendung läuft, obwohl das Quellsystem ein anderes ist. Und alles, was Sie darauf aufbauen, bleibt bestehen: Wenn die Migration abgeschlossen ist, tauschen Sie das Data Product gegen das echte S/4HANA-Produkt aus. Die Schicht darüber merkt davon nichts.

Wer eine mehrjährige Transformation vor sich hat, sollte diese Mechanik kennen, bevor er die Analytik-Landschaft neu aufsetzt. Sie entscheidet darüber, ob die Arbeit der nächsten zwei Jahre den Systemwechsel übersteht.

SAP beschreibt drei Ausbaustufen: zunächst die Implementierung von SAP-gelieferten Interfaces; später beliebige bestehende Data Products als Interface-Vorlage; schließlich selbst definierte Interfaces. Die dritte Stufe zielt auf Konzernstrukturen – die Zentrale gibt eine Struktur vor, die Regionen oder Tochtergesellschaften liefern konform dagegen, und der Datenaustausch braucht keine bilaterale Abstimmung mehr. Nur die erste Stufe ist für die erste Produktversion angekündigt.

7. Stolperfallen

Modellierung wandert ins falsche Werkzeug. Symptom: Im Studio wird nach Join-, Berechnungs- oder Bereinigungsfunktionen gesucht. Ursache: Das Studio ist ein Verpackungs-, kein Modellierungswerkzeug – zumindest zum Start. Vermeidung: Alle Transformationen in Datasphere abschließen, bevor Sie das Studio öffnen.

Views statt lokaler Tabellen als Quelle. Symptom: Ein Datasphere-View soll direkt Basis eines Data Products werden. Ursache: Der kundeneigene Weg setzt auf dem Object Store auf, also auf lokalen Tabellen auf Dateiebene. Vermeidung: Das View-Ergebnis über einen Transformation Flow im Object Store materialisieren. Andernfalls verschieben Sie Rechenlast in jeden einzelnen Konsumentenzugriff.

Sammelspace zerstört den Herkunftsnachweis. Symptom: Zwei Quellsysteme liegen im selben Object-Store-Space. Ursache: Der Space übernimmt die Rolle des Quellsystem-Kennzeichens. Vermeidung: Ein Space je Quellsystem, von Anfang an.

Brechende Änderung als Nebenversion. Symptom: Eine Spalte verschwindet, die Version steigt von 1.2 auf 1.3. Ursache: Es wird technisch geprüft statt vertraglich gedacht. Vermeidung: Feste Regel – jede Löschung und jede Schlüsseländerung ist eine Hauptversion, ohne Ermessensspielraum.

Bereitstellung mit Installation verwechselt. Symptom: Die Nutzungsauswertung zeigt Aktivität, aber niemand im Fachbereich kennt das Produkt. Ursache: Bereitstellung in einer Formation ist nicht dasselbe wie Bezug über den Katalog. Vermeidung: Beide Kennzahlen getrennt führen.

Metadaten fehlen im Katalog. Symptom: Eine Tabelle ist im Object Store vorhanden, erscheint im Studio aber nicht zur Auswahl. Ursache: Das Studio arbeitet gegen den Katalog, nicht gegen den Datenbestand. Vermeidung: Katalogregistrierung als Vorbedingung prüfen, nicht als Nebenwirkung erwarten.

Kein benannter Verantwortlicher. Symptom: Nach einem halben Jahr weiß niemand, ob die Daten noch stimmen. Ursache: Das Owner-Feld wurde mit einem Team-Postfach ohne Adressaten gefüllt. Vermeidung: Person oder gepflegte Verteilerliste – und die Verantwortung im Fachbereich verankern, nicht in der IT.

Fehlende Laufzeitzuordnung blockiert den Transport. Symptom: Das Data Product lässt sich nicht in die Testumgebung bringen. Ursache: Für Test und Produktion wurde kein Quell-Space zugeordnet. Vermeidung: Die Zuordnung für alle Umgebungen bei der Erstanlage vornehmen.

Erwartung falscher Werkzeugzuständigkeit. Symptom: Wochen gehen für die Frage drauf, ob der Data Composer das Data Product Studio ablöst. Ursache: Namensähnlichkeit bei völlig unterschiedlichem Zweck. Vermeidung: Die Tabelle in Abschnitt 4 als Entscheidungshilfe im Projekt hinterlegen.

8. Heute verfügbar und was angekündigt ist

Fähigkeit	Stand Juli 2026	Anmerkung
Daten aus Fremdsystemen in den Datasphere Object Store bringen	Verfügbar	Über bestehende Connections und Replication Flows
BW-Daten in den Object Store überführen	Verfügbar	Data Product Generator; erzeugt die Vorstufe, nicht das Data Product
Data Product auf Delta-Sharing-Basis erzeugen	Verfügbar	Über Data Sharing Cockpit in Datasphere, als Übergangslösung
Ergebnisse aus SAP Databricks zurückspielen	Verfügbar	Delta Table, Delta Share an BDC, plus ORD- und CSN-Datei
Data Product Studio im BDC Cockpit	Angekündigt	Terminangaben widersprüchlich (siehe Stand-Kasten)
Versionsverwaltung mit Haupt-, Neben- und Patchversion	Angekündigt	Zustandsmodell laut SAP zum Sessionzeitpunkt noch in Überarbeitung
Transport über Entwicklungs-, Test- und Produktionsumgebung	Angekündigt	Setzt Ansiedlung im BDC Cockpit voraus
Implementierung SAP-gelieferter Interface Data Products	Angekündigt, erste Produktversion
Eigene Interface Data Products definieren	Angekündigt, spätere Ausbaustufe
Abgeleitete Data Products aus bestehenden Data Products	Angekündigt, spätere Ausbaustufe	Liegen ebenfalls im Object Store
Mischung aus SAP-verwalteten und eigenen Data Products	Angekündigt, ohne Termin
Transformationen im Studio	Über die erste Version hinaus	Zunächst Eins-zu-eins-Abbildung, Filter und Projektionen vorgesehen
Domänenkonzept für Verantwortlichkeiten	Angekündigt, Abhängigkeit von der Governance-Roadmap

9. Checkliste

Vor dem Bauen

☐ Mindestens zwei unabhängige Konsumenten identifiziert
☐ Fachlicher Verantwortlicher namentlich benannt und einverstanden
☐ BDC Subscription und Datasphere-Tenant in einer Formation vorhanden
☐ Object-Store-Space je Quellsystem angelegt
☐ Zuschnitt in einem Satz ohne "und" formulierbar

Beim Bauen

☐ Alle Transformationen in Datasphere abgeschlossen, Ergebnis materialisiert
☐ Semantik gesetzt: Feldtypen, Währung, Aggregation, Assoziationen
☐ Fachliche Beschreibung geschrieben – inklusive dessen, wofür das Produkt nicht gedacht ist
☐ Kategorie und Fachbereich gefüllt
☐ Laufzeitzuordnung für alle Umgebungen hinterlegt

Vor der Veröffentlichung

☐ Versionsregel schriftlich festgehalten und im Team bekannt
☐ Katalogeintrag von jemandem gegengelesen, der das Quellsystem nicht kennt
☐ Bereitstellungs- und Installationskennzahlen getrennt definiert
☐ Bei laufender S/4HANA-Migration: geprüft, ob ein Interface Data Product der bessere Schnitt ist

10. Häufige Fragen

Ersetzt das Data Product Studio die Modellierung in SAP Datasphere? Nein. Datasphere bleibt das Modellierungswerkzeug – Views, analytische Modelle, Ausnahmeaggregationen, Eingabeparameter, Planungsfunktionen. Das Studio setzt auf Tabellenebene im Object Store auf. Selbst wenn dort später Modellierungsfunktionen dazukommen, bewegen sie sich auf dieser Ebene.

Liegen abgeleitete Data Products auch im Object Store? Ja.

Brauche ich eine BDC-Subscription, wenn ich meine agentischen Szenarien in BTP mit HANA Cloud baue? Für den Bezug von SAP-verwalteten Data Products aus BDC: ja. Läuft die HANA Cloud in BTP statt in BDC, kommt eine Destination-Verknüpfung dazu, über die das Data Product aktiv geteilt wird.

Muss ich für KI-Agenten zusätzlich eine Ontologie oder einen Knowledge Graph modellieren? Nach SAPs Darstellung entsteht die benötigte Metadatenstruktur im Hintergrund und wird von den Agenten genutzt. Ob Kunden darauf zugreifen oder eigene Strukturen anlegen können, ist eine separate Frage, die zum Sessionzeitpunkt offen war.

Wurde das Studio in "Data Composer" umbenannt? Nein. Der Data Composer führt Daten auf Datensatzebene zu einem Golden Record zusammen, stammt aus einem anderen Produktumfeld und ist an ein Fachbereichsprodukt gekoppelt. Er erzeugt am Ende auch ein Data Product – das macht ihn nicht zum selben Werkzeug.

Kann ich Data Products zwischen Formations bewegen? Sie stellen sie in der Zielformation bereit. Innerhalb einer Formation kommt die Quelle aus Datasphere, die Bereitstellung erfolgt über den Foundation Service.

Kann ich Data Products als Datei weitergeben? Data Product Definition Files sind vorgesehen, inklusive Herunterladen und Hochladen, und das Studio ist API-first angelegt. Für Partner, die Produkte als Vorlage bereitstellen wollen, ist das der einfachste Weg; weitergehende Verteilmechanismen sind separat in Arbeit.

Quellen

SAP Live Expert Session zum Data Product Studio in SAP Business Data Cloud, März 2026 – https://www.youtube.com/watch?v=g00Zw5UV7Tw (Transkript ausgewertet am 28.07.2026)
SAP Learning: Sharing data back to SAP Business Data Cloud – https://learning.sap.com/courses/introducing-the-open-data-ecosystem-for-sap-business-data-cloud/sharing-data-back-to-sap-business-data-cloud (abgerufen 28.07.2026)
SAP News Center: Accelerate the Autonomous Enterprise with SAP Business Data Cloud, Mai 2026 – https://news.sap.com/2026/05/sap-bdc-accelerate-autonomous-enterprise/ (abgerufen 28.07.2026)
SAP Architecture Center: Data Products in SAP Business Data Cloud – https://architecture.learning.sap.com/docs/ref-arch/f5b6b597a6/1 (Seite lieferte beim Abruf am 28.07.2026 keinen auswertbaren Inhalt; als weiterführende Referenz gelistet, nicht als Beleg verwendet)

Sicherheit der tragenden Aussagen

Aussage	Quelle	Sicherheit
Fünf konstituierende Eigenschaften eines Data Products	1	Hoch
Kundeneigene Data Products setzen auf dem Datasphere Object Store auf	1	Hoch
Data Product Generator erzeugt kein fertiges Data Product	1	Hoch
Data Sharing Cockpit als Übergangslösung mit Delta-Sharing-Erzeugung	1	Hoch
Versionsregel: Hauptversion bei brechenden Änderungen, Parallelbetrieb	1	Hoch
Interface Data Products und die drei Ausbaustufen	1	Hoch
Erste Produktversion mit Eins-zu-eins-Abbildung ohne Transformationen	1	Mittel – ausdrücklich als Planungsstand gekennzeichnet
Databricks-Rückweg über Delta Share plus ORD- und CSN-Datei	2	Hoch
Verfügbarkeitsfenster Data Product Studio	1, plus abweichende Angabe aus der TechEd-2025-Kommunikation	Niedrig – Angaben widersprechen sich, keine der Terminangaben ließ sich in einer direkt abrufbaren Primärquelle bestätigen
Kategorien Business Objects, Analytical, Other	1	Mittel – in der Session mit Einschränkung genannt
Zustandsmodell der Versionen	1	Niedrig – laut SAP zum Sessionzeitpunkt in Überarbeitung

Sascha Theismann begleitet Unternehmen bei messbarer digitaler Transformation – von KI- und Automatisierungs-Governance bis zur Enterprise-Architektur im SAP-Umfeld.