Konzeptkarte

SAP Data Products — Der Katalog mit 300+

Stand 27. September 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP Data Products?

SAP Data Products sind kuratierte, versionierte, geregelte Datenassets, die für den nachgelagerten Konsum geformt sind — die Bausteine von BDC.

Worum es geht

SAP Data Products sind kuratierte, versionierte, geregelte Datenassets, die für den nachgelagerten Konsum geformt sind — die Bausteine von BDC. Die Sapphire 2026 bestätigte über 300 live und kündigte ein Ziel von 500+ für Q2 2026 an; dieser Meilenstein wurde nicht als erreicht bestätigt, also die auf dem Tenant überprüfbare Katalogzahl zitieren.

Die Domänenabdeckung, sichtbar auf der Keynote-Folie. Finance: Billing & Payments · Cash Flow · Compensation. Supply Chain: Deliveries · Inventory · Manufacturing Material · Purchase Orders. Human Resources: Headcount. Service & Sales: Cases & Tickets. Plus Erweiterungen über Spend Management und branchenspezifische Produkte.

Was ein Data Product tatsächlich enthält. Jedes Data Product besteht aus einem typisierten Schema + geschäftlich aussagekräftigen KPIs + Lineage zum SAP-Quellsystem + Governance-Metadaten (Owner, Aktualisierungsrhythmus, Klassifizierung) + den Daten selbst. Ein Konsument (Joule-Agent, SAC-Dashboard, Datasphere-Modell) fragt ein Data Product als erstklassiges Objekt ab — ohne Joins gegen rohe S/4HANA-Tabellen schreiben zu müssen.

Warum 300 → 500 wichtig ist. Jedes neu hinzugekommene Data Product ist ein Feature, das SAP bestehenden BDC-Kunden kostenlos liefert. Das Tempo (200 hinzugefügte Produkte in 2 Quartalen) ist der Beleg dafür, dass SAP in die inhaltliche Tiefe von BDC investiert, nicht nur in die Plattform. Ein Berater sollte die vierteljährlichen Data-Product-Release-Notes so verfolgen, wie ein SAP-BW-Berater früher die Business-Content-Auslieferungen verfolgt hat.

Wann ein gepacktes SAP Data Product konsumiert werden sollte gegenüber dem Bau eines eigenen Datasphere-Views — die Trade-off-Entscheidung. Das gepackte Data Product ist der richtige Ausgangspunkt, wann immer eine Standard-SAP-Domäne im Scope liegt und die Reporting-Anforderungen des Kunden sauber auf den gelieferten KPI-Satz passen. Ein Standardprodukt zu konsumieren bedeutet, dass SAP die Wartungslast übernimmt: Schema-Updates, Lineage-Korrekturen und Zertifizierung liegen in der Verantwortung von SAP, nicht des Projektteams. Der Implementierungsgeschwindigkeitsvorteil ist real — ein Finance-Team kann innerhalb von Tagen nach der BDC-Bereitstellung beginnen, ein standardisiertes Cash-Flow-Data-Product abzufragen, gegenüber Wochen für den Bau und die Validierung eines gleichwertigen individuellen Datasphere Analytic Model.

Wählen Sie einen individuellen Datasphere-View, wenn die Geschäftslogik vom Standardprodukt abweicht: proprietäre Berechnungsmethoden, nicht standardmäßige Kostenverteilungsstrukturen, systemübergreifende Vermischung von SAP- und Nicht-SAP-Quellen oder branchenspezifische KPI-Definitionen, die SAP noch nicht als gepacktes Produkt geliefert hat. Der Trade-off ist die vollständige Eigenverantwortung für die Wartung. Wenn S/4HANA-Upgrades die zugrunde liegende Tabellenstruktur ändern, bricht ein individueller Datasphere-View stillschweigend, bis jemand eine Berichtsabweichung untersucht; ein gepacktes Data Product tut das nicht. Diese Wartungsasymmetrie ist das stärkste Argument dafür, mit dem Standardprodukt zu beginnen und nur dort anzupassen, wo die Lücke dokumentiert und begründet ist.

Im Vergleich zur direkten Replikation roher S/4HANA-Tabellen nach Datasphere: Die Rohreplikation bietet maximale Flexibilität, aber keine semantische Schicht — jedes Konsumententeam implementiert dieselbe Join-Logik, Währungsumrechnung und KPI-Definition unabhängig neu. Die Data-Product-Schicht ist der Governance-Vertrag, der diese Fragmentierung verhindert. Die Replikation roher Tabellen ist nur während der ersten Erkundung angemessen oder für operative Reporting-Anforderungen, die kein gepacktes Produkt abdeckt und für die eine individuelle Modellierung bereits begonnen hat.

Die BW-Verbindung. Der SAP BW Data Product Generator (verfügbar) wandelt bestehende BW-InfoProvider in Data Products um — der kanonische Pfad zur BW-Modernisierung. Bauen Sie BW-Logik nicht von Grund auf neu in BDC — generieren Sie sie.

Einen weiter wachsenden Katalog steuern. Ein Katalog von 300 bis 500 Produkten ist keine statische Liste, die ein Berater einmal auswendig lernt; es ist ein bewegliches Ziel mit eigener Versionierungsdisziplin. Jedes Data Product veröffentlicht neben seinem Schema einen Datenvertrag — einen benannten Owner, einen erklärten Aktualisierungstakt, eine Sensibilitätsklassifizierung und eine explizite Konsumentenliste — und genau dieser Vertrag unterscheidet ein Data Product tatsächlich von einer geteilten Tabelle mit hübscherem Etikett. Wenn SAP eine Schemaänderung an einem bestehenden Data Product ausliefert (ein neues Feld, ein umbenannter KPI, eine verschärfte Klassifizierung), sagt der Vertrag einem konsumierenden Joule-Agenten oder SAC-Dashboard, ob die Änderung additiv und gefahrlos zu ignorieren ist, oder ob sie etwas bricht und vor dem nächsten Refresh eine Prüfung braucht.

Angewandtes Beispiel: Ein Finance-Team, das das gepackte Cash-Flow-Data-Product für ein Working-Capital-Dashboard konsumiert, bemerkt zu Beginn eines neuen Quartals, dass SAPs Release Notes ein Schema-Update mit einem neuen Währungsabsicherungsfeld für dieses Produkt auflisten. Weil das Team das Data Product als erstklassiges Objekt konsumierte statt rohe Tabellen zu joinen, kommt das Update als additive Spalte an, ohne dass am bestehenden Dashboard irgendetwas nachgearbeitet werden muss — genau das Szenario, das die Data-Product-Schicht garantieren soll. Im Gegensatz dazu bricht bei einem Team, das eine entsprechende individuelle Datasphere-Ansicht auf denselben rohen S/4HANA-Tabellen gebaut hat, ein unabhängiges S/4-Upgrade, das die Struktur einer zugrunde liegenden Tabelle ändert, diese Ansicht lautlos — und niemand bemerkt es, bis Wochen später eine Zahl im Dashboard falsch aussieht.

Der Grenzfall, den man einem Kunden explizit nennen sollte: eine Domäne, die mitten im Projekt von „noch kein gepacktes Data Product vorhanden“ zu „jetzt von einem Data Product abgedeckt“ wechselt. Tritt das ein, braucht jede in der Zwischenzeit gebaute individuelle Ansicht eine explizite Entscheidung — sie zugunsten des neuen gepackten Produkts stilllegen, oder genau dokumentieren, warum sie weiterhin abweicht (etwa eine proprietäre Berechnung, die das Standardprodukt nicht unterstützt). Beide stillschweigend am Leben zu lassen ist der häufigste Weg, wie zwei Finance-Dashboards am Ende zwei unterschiedliche Working-Capital-Zahlen zu denselben zugrunde liegenden Transaktionen melden, und es ist die häufigste Datenqualitätsbeschwerde, die tatsächlich auf das Wachstum des Data-Product-Katalogs zurückgeht statt auf einen echten Datenfehler.

Die Joule-Perspektive, September 2026. Der SAP Knowledge Graph liest Data-Product-Metadaten — Owner, Lineage, Aktualisierungstakt, Sensibilitätsklassifizierung — als sein Grounding-Substrat, was bedeutet, dass das Rennen des Katalogs von 300 auf 500 nicht nur eine Inhaltsgeschichte ist, sondern auch eine Geschichte der Joule-Fähigkeit. Jedes neue Data Product, das SAP ausliefert, ist eine zusätzliche Entität, auf der Joule-Agenten und der Orchestrierungsdienst des Generative AI Hub eine Antwort ankern können, ohne dass ein Berater vorher von Hand ein Semantikmodell verdrahten muss. Praktisch bedeutet das: Vor dem Scoping eines Joule-Agenten für einen Finance- oder SCM-Anwendungsfall prüfen, ob die Domäne bereits ein gepacktes Data Product hat, denn eine abgedeckte Domäne wird innerhalb weniger Tage zu einem ankerbaren Agenten, während eine nur durch eine rohe Tabelle oder eine undokumentierte individuelle Ansicht abgedeckte Domäne das Projekt zwingt, die Grounding-Schicht von Hand zu bauen — dieselbe Katalogzahl von über 300, die eine Bauen-oder-Kaufen-Entscheidung für das Reporting trifft, entscheidet auch eine Bauen-oder-Kaufen-Entscheidung für das KI-Grounding.

Die im Mai 2026 hinzugefügte Batch-Inferenz aus SAP AI Core, direkt eingebettet in geschäftsfertige Data Products (sodass eine Vorhersage eines tabellarischen Modells — SAP-RPT-1.6 zum Stand September 2026, die aktuelle Generation auf dem Generative AI Hub — als Feld neben den governten Daten landet, die Joule bereits liest), ist der konkrete Mechanismus, den es einem Kunden zu nennen lohnt: Ein Data Product ist damit nicht mehr nur ein Abfrageziel, es kann eine von SAPs eigenem tabellarischem Foundation-Modell befüllte Vorhersagespalte tragen, ohne eine separate MLOps-Pipeline. Für einen Berater ist die explizit aufzuwerfende Entscheidung, ob das Data Product einer gegebenen Domäne jetzt um eine AI-Core-Batch-Inferenz-Spalte angereichert werden soll, oder deskriptiv bleibt, bis der Business Case für die Vorhersage bewiesen ist — zu frühes Anreichern fügt AI-Units-Kosten und eine Modell-Refresh-Pflicht hinzu, die niemand budgetiert hat.

Die BDC Modernization Option für SAP BW NetWeaver, seit September 2026 zur Buchung offen, ändert die Sequenzierungsfrage für BW-lastige Kunden: Sie nimmt den Druck, jeden InfoProvider in ein Data Product umzuwandeln, bevor KI-Grounding beginnen kann, denn die Option selbst ist eine Brücke, kein Zwang. Eine pragmatische Scoping-Regel für 2026: dort zuerst in Data Products umwandeln, wo ein Joule-Anwendungsfall bereits finanziert ist, und den Rest auf der Brücke der Modernization Option belassen, bis ein Anwendungsfall sie benennt.

Warum es zählt

Das Konsummuster ist konkret: Ein Konsument fragt ein Data Product als erstklassiges Objekt ab und überspringt handgeschriebene Joins gegen rohe S/4HANA-Tabellen.
Das Tempo von 300 auf 500 (200 netto neu in zwei Quartalen) ist der genannte Beleg dafür, dass SAP in inhaltliche Tiefe investiert, nicht nur in die Plattform — es lohnt sich, das so zu verfolgen, wie BW-Berater Business-Content-Releases verfolgt haben.
Die Build-vs-Buy-Regel ist explizit: Verwenden Sie ein gepacktes Data Product, wenn Standarddomäne und KPI-Satz der Anforderung entsprechen — bauen Sie nur dann individuelles Datasphere, wenn die Geschäftslogik tatsächlich abweicht.

Kernpunkte

Über 300 Data Products auf der Sapphire 2026 bestätigt; der für Q2 2026 angekündigte Meilenstein 500+ wurde nicht als erreicht bestätigt — die Katalogzahl vor dem Zitieren prüfen.
Domänen: Finance (Billing, Cash Flow, Comp) · SCM (Deliveries, Inventory, Mfg Mat, POs) · HR (Headcount) · Service (Cases & Tickets) · Spend · Industry.
Jedes Produkt: typisiertes Schema + KPIs + Lineage + Governance-Metadaten + Daten.
Konsumenten (Joule, SAC, Datasphere) fragen Data Products als erstklassige Objekte ab — keine rohen S/4HANA-Joins nötig.
Der SAP BW Data Product Generator wandelt BW-InfoProvider in Data Products um — der kanonische Pfad zur BW-Modernisierung.
Jedes Data Product veröffentlicht neben seinem Schema einen Datenvertrag (Owner, Aktualisierungstakt, Sensibilitätsklassifizierung, Konsumentenliste) — dieser Vertrag, nicht das Schema allein, unterscheidet es von einer geteilten Tabelle.
SAP Knowledge Graph und Joule ankern Antworten direkt auf Data-Product-Metadaten — eine Katalog-Lücke in einer Domäne ist damit auch eine KI-Grounding-Lücke, nicht nur eine Reporting-Lücke.

Quellen

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.