Konzeptkarte

SAP Business Data Cloud Use Cases — Die sechs Aufgaben, für die es gekauft wird

Stand 2026-08-07T00:00:00Z

Redaktion: Cédric-Olivier Mâry, 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 Business Data Cloud Use Cases — Die sechs Aufgaben, für die es gekauft wird?

Sechs wiederkehrende Aufgaben erklären nahezu jede BDC-Einführung: domänenübergreifendes Reporting, das Grounding von KI-Agenten, die Veröffentlichung von Daten als Contracts, ML auf SAP-Semantik, die fristgebundene Ablösung von BW und transaktionsnahe operative Workloads. Keine davon ist ohne BDC unmöglich — jede ist eine Entscheidung darüber, wer die Verdrahtung verantwortet.

SAP Business Data Cloud wird für eine kleine Zahl wiederkehrender Aufgaben gekauft, und diese klar zu benennen, ist nützlicher als eine weitere Tour durch die Architektur. Sechs Formen decken nahezu jede im Markt heute diskutierte Einführung ab, und jede davon ist eine Aufgabe, die ein Kunde schon vor BDC zu erledigen versuchte — meist, indem er drei Produkte und eine Governance-Tabelle zusammensetzte.

Domänenübergreifendes Reporting, das kein einzelnes SAP-Modul besitzt

Die häufigste Aufgabe ist eine Frage, deren Antwort in mehr als einem System liegt: Marge nach Kunde, wobei die Kosten in S/4HANA und die Pipeline in einem CRM liegen, oder eine kopfzahlbereinigte Produktivität, bei der Workday eine Hälfte hält. Vor BDC bedeutete das entweder, SAP-Daten in ein externes Warehouse zu extrahieren und deren Semantik neu aufzubauen, oder von Datasphere aus zu föderieren und hinzunehmen, dass die Nicht-SAP-Seite zweite Klasse bleibt. BDCs Antwort ist, dass die semantische Schicht und das Lakehouse in einem Katalog und einer Autorisierungsebene liegen, sodass ein domänenübergreifender Join eine Modellierungsübung statt eines Integrationsprojekts wird.

Einen KI-Agenten in Geschäftsdaten grounden, die er sehen darf

Die zweite Aufgabe ist neuer und ist der Grund, warum viele Kunden sich BDC überhaupt ansehen. Ein Joule-Agent, der die Frage „welcher meiner Lieferanten ist dieses Quartal gefährdet“ beantwortet, braucht drei Dinge, die eine Chat-Oberfläche allein nicht liefern kann: konsistent aufgelöste Entitäten, pro Nutzer durchgesetzte Berechtigungen und verfügbare Herkunftsnachweise, wenn jemand die Antwort anzweifelt. Das ist eine Aufgabe der Datenplattform, keine Modellaufgabe, und genau dafür existieren der Knowledge Graph und der Catalog.

Warum es zählt

Eine Anwendungsfall-Frage ist der häufigste Weg, wie ein BDC-Gespräch beginnt, und der am schlechtesten beantwortete: Der Markt antwortet mit einer Architekturtour. Die sechs Aufgaben zu benennen, lässt einen Berater einen Interessenten in einem Meeting statt in dreien qualifizieren.

Kernpunkte

Sechs Formen decken nahezu jede Einführung ab: domänenübergreifendes Reporting, KI-Grounding, Data Products, Lakehouse-ML, BW-Ausstieg, operative/prädiktive Workloads.
Keine der sechs ist ohne BDC unmöglich — das Angebot betrifft, wer die Verdrahtung verantwortet, nicht exklusive Fähigkeiten.
Domänenübergreifendes Reporting ist der häufigste Einstiegspunkt, weil die Frage Systeme umspannt, die kein einzelnes SAP-Modul besitzt.
KI-Grounding ist eine Aufgabe der Datenplattform, keine Modellaufgabe: Entitätsauflösung, nutzerbezogene Berechtigungen und Herkunftsnachweise sind die Anforderungen.
Data Products bekämpfen ein organisatorisches Versagen — konkurrierende Definitionen von Customer — kein technisches.
Die Databricks-Ebene existiert, damit ML geschieht, ohne SAP-Semantik neu abzuleiten, den Fehlermodus offener Stack-Migrationen.
Der BW-Ausstieg ist ein Migrationspfad mit terminierter Uhr, keine neue Fähigkeit; BW Bridge hält die Modellierungsinvestition erreichbar.
Operative und prädiktive Workloads sind der engste Fall und der latenzempfindlichste.
Eine Anwendungsfall-Frage wird meist zu einer Build-versus-Buy-Frage — früh an die Entscheidungsrahmen-Karten weiterleiten.
Qualifizieren, welche der sechs ein Interessent tatsächlich finanziert; Einführungen, die mit allen sechs auf einmal begründet werden, geraten meist ins Stocken.

Begriffe auf dieser Seite

Data Product: Ein veröffentlichter Datensatz mit versioniertem Schema, festgelegtem Ziel für Aktualität und Vollständigkeit, benanntem Governance-Eigentümer und expliziter Konsumentenliste — ein Vertrag statt einer Tabelle.
BDC Catalog: Die einheitliche Metadatenschicht, die semantische Typen, Herkunft, Data Products und DAC-Regeln über die Datasphere- und die Databricks-Seite hinweg trägt.
BW Bridge: Der Pfad, der bestehende BW-Modellierung von innerhalb von SAP Datasphere erreichbar hält, sodass ein BW-Ausstieg kein Neuschreiben der Modelle verlangt.
Joule agent: Die KI-Konsumoberfläche über BDC; verlässliche Antworten hängen von aufgelösten Entitäten, nutzerbezogenen Berechtigungen und abrufbarer Herkunft ab.
SAP Knowledge Graph: Das semantische KI-Fundament, das Geschäftsentitäten über den Bestand hinweg verbindet und Agentenantworten in echten Beziehungen verankert.
Cross-domain join: Eine Abfrage, deren Antwort SAP- und Nicht-SAP-Quellen umspannt; innerhalb von BDC ist das eine Modellierungsübung statt eines Integrationsprojekts.
Lakehouse tier: Die von Databricks verwaltete, offen formatierte Speicherebene innerhalb der Abrechnungs- und Governance-Grenze von BDC.
Build-versus-buy: Die Abwägung, in die sich eine Anwendungsfall-Frage auflöst: Datasphere, ein Lakehouse und Governance selbst zusammensetzen, gegenüber BDC vorverdrahtet.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →