Vom SAP-Datensilo zum Data Product – Transparenz, Governance & Self Service BI neu gedacht
Unser Gastautor trifft es auf den Nagel auf den Kopf, wenn er sagt, „der kritische Punkt bei Data Products ist nicht nur, ob sie in einer Plattform gut funktionieren. Die eigentliche Frage ist: Wem gehören Daten und Kontext? Wenn fachliche Definitionen, Qualitätsregeln, Lineage und Data Contracts nur noch im Metamodell eines einzelnen Anbieters leben, entsteht kein Data Product, sondern ein Lock-in-Product. Unternehmen sollten deshalb auf Datensouveränität pochen: Data Products müssen in SAP funktionieren können, aber ihre Bedeutung darf nicht in SAP gefangen sein.“
– Timm Grosser, Senior Analyst Data & Analytics bei BARC
Genau darum soll es im folgenden Artikel gehen, der sich an ein kürzlich veranstaltetes Webinar zum Thema anlehnt. Warum braucht es Data Products überhaupt? Welche Probleme lösen sie? Und wie lassen sie sich insbesondere im SAP-Umfeld praktisch umsetzen?
Was hat Amazon mit Data Products zutun?
Wie im Webinar beginnen wir mit einem ungewöhnlichen Vergleich: Amazon.
Früher bedeutete die Suche nach einem Buch, verschiedene Bibliotheken oder Buchhandlungen aufzusuchen, bis man das gewünschte Exemplar gefunden hatte. Heute erwarten wir Informationen sofort: Wir öffnen Amazon, suchen nach einem Produkt und erhalten innerhalb weniger Sekunden alle relevanten Informationen – von Preis und Lieferzeit über Bewertungen bis hin zu Empfehlungen.
Genau diese Erwartungshaltung übertragen wir zunehmend auch auf Unternehmensdaten: Daten sollen einfach auffindbar, verständlich beschrieben und direkt nutzbar sein – genauso wie ein Produkt in einem Online-Shop.
Die Realität: Datenzugriff ist oft komplizierter als nötig
In vielen Unternehmen sieht die Realität jedoch anders aus: Mitarbeiter wissen häufig gar nicht,
- ob die benötigten Daten überhaupt existieren,
- wo sie gespeichert sind,
- wer Zugriff darauf hat,
- wer sie verantwortet oder
- ob man ihnen überhaupt vertrauen kann.
Hinzu kommt, dass Daten oft erst über die IT angefragt werden müssen. Fachbereiche warten auf Berechtigungen oder Auswertungen und verlieren dadurch wertvolle Zeit.
Nicht selten entstehen dadurch Datensilos oder sogar Schatten-IT, weil sich Fachbereiche ihre eigenen Datenbestände aufbauen. Das eigentliche Problem ist also nicht der Mangel an Daten – sondern der schwierige Zugang zu ihnen.
Die Lösung: Data Democratization und Data Products
Um dieses Problem zu lösen, entstand vor einigen Jahren das Konzept der Data Democratization.
Die Idee war einfach: Unternehmen sollten sich vom klassischen Need-to-Know-Prinzip verabschieden. Bis dahin mussten Mitarbeitende begründen, warum sie Daten benötigen. Der Zugriff wurde überwiegend durch die IT gesteuert.
Stattdessen etablierte sich zunehmend das Right-to-Know-Prinzip: Daten sollten grundsätzlich für alle berechtigten Personen zugänglich sein. Ziel war es, Self-Service Analytics zu ermöglichen und Fachbereiche unabhängiger von der IT zu machen.
Damit schien das ursprüngliche Problem zunächst gelöst – doch schon bald zeigte sich eine neue Herausforderung: Je mehr Daten verfügbar wurden, desto schwieriger wurde die Orientierung. Plötzlich stellten sich ganz andere Fragen:
- Welchen Daten kann ich vertrauen?
- Welche Kennzahl ist die richtige?
- Wer verantwortet diese Daten?
- Sind die Informationen aktuell?
- Darf ich diese Daten überhaupt verwenden?
Die Öffnung führte zwar zu mehr Zugänglichkeit, gleichzeitig aber häufig auch zu sinkender Transparenz und geringerem Vertrauen in die Daten.
Genau hier setzen Data Products an und im Webinar lieferte Timm Grosser (BARC) folgende Definition:
“Der Zweck eines Datenprodukts besteht darin, den Zugang zu vertrauenswürdigen, geschäftsreifen Daten zu demokratisieren und gleichzeitig die Komplexität zu verringern sowie die Zeit bis zur Gewinnung von Erkenntnissen für die Datennutzer zu verkürzen.”
Datenprodukte verbinden somit die Offenheit der Data Democratization mit den Regeln einer klaren Data Governance. Ein Data Product besteht dabei nicht nur aus Daten.
Es bündelt zusätzlich
- fachlichen Kontext,
- Metadaten,
- Verantwortlichkeiten,
- Qualitätsinformationen,
- Nutzungsregeln und
- häufig auch sogenannte Data Contracts.
Dadurch werden Daten nicht nur verfügbar, sondern auch verständlich, vertrauenswürdig und wiederverwendbar.
Data Products im SAP-Umfeld
Auch die SAP verfolgt diesen Ansatz konsequent weiter: Mit der SAP Business Data Cloud (BDC) können Daten aus verschiedenen SAP-Systemen zusammengeführt und anschließend als Data Products bereitgestellt werden, primär im BDC Catalog.
SAP unterscheidet dabei zwischen zwei Arten von Data Products:
SAP Managed Data Products werden von SAP standardisiert ausgeliefert und können mit vergleichsweise geringem Aufwand genutzt werden. Voraussetzung ist allerdings eine weitgehend standardisierte SAP-Landschaft ohne umfangreiche Eigenentwicklungen.
In der Praxis sieht das jedoch häufig anders aus: Viele Unternehmen arbeiten mit individuellen Z-Tabellen, eigenem ABAP-Code oder speziell entwickelten Datenmodellen. Für diese Szenarien müssen mit von der SAP bereitgestellten Tools Customer Data Products erstellt werden, bei denen Unternehmen ihre individuellen Daten selbst modellieren und pflegen.
Hinzu kommt, dass viele Unternehmen heute nicht ausschließlich auf SAP setzen. Power BI, Microsoft Fabric, Snowflake oder Databricks gehören inzwischen ebenso zur Analytics-Landschaft wie klassische SAP-Systeme. Zwar lassen sich Daten und Data Products vergleichsweise einfach in die SAP Business Data Cloud integrieren, der Austausch in die entgegengesetzte Richtung stößt jedoch häufig an technologische und teilweise auch vertragliche Grenzen. Dadurch entsteht das Risiko, sich stärker an eine einzelne Plattform zu binden, als ursprünglich geplant.
Gerade in hybriden Landschaften stellt sich daher die Frage, wie sich Data Products möglichst technologieoffen umsetzen lassen. Ein möglicher Ansatz besteht darin, ergänzend auf Lösungen zu setzen, die direkt auf der Quellsystemebene – beispielsweise SAP S/4HANA, SAP ECC oder SAP BW – ansetzen. Statt Daten erst in einer zentralen SAP-Plattform zu katalogisieren, schaffen sie Transparenz über die vorhandenen Daten und Metadaten bereits dort, wo sie entstehen. So erhalten Unternehmen einen vollständigen Überblick über ihre SAP-Daten und schaffen gleichzeitig eine Grundlage für Data Products, die unabhängig von einer bestimmten Zielplattform genutzt werden können.
Das ist richtig für Data Products, die Verwendung nach aussen finden. SAP-intern können auch in Datasphere (+Marketplace) Data Products gebaut werden.
Das Enterprise Glossary von bluetelligence
Wenn Sie zu den Unternehmen gehören, die noch keine Business Data Coud nutzen oder bewusst Technologie-offen bleiben möchten, gestaltet sich die Implementierung von Data Products herausfordernd. Ein sinnvoller erster Schritt ist es dann, Transparenz über die vorhandenen Datenbestände zu schaffen und bestehende Data Products für die Fachbereiche auffindbar und nutzbar zu machen.
Genau dafür haben wir eine Lösung entwickelt: Das Enterprise Glossary. Als zentrale Webanwendung synchronisiert das Enterprise Glossary Metadaten aus SAP- und Power-BI-Systemen, katalogisiert diese zentral und stellt sie Business-Anwendern verständlich zur Verfügung.
Benötigen Fachbereiche bestimmte Daten, können sie vorhandene Data Products einfach im Enterprise Glossary suchen und finden:
Anschließend erhalten Business User einen transparenten Einblick in die technischen Hintergründe – ohne auf Unterstützung der IT angewiesen zu sein:
Gleichzeitig können Sie auf einen Blick die Quellen des Datenprodukts prüfen: entweder in einer Liste oder in einem grafischen Datenfluss:
Neben der technischen Transparenz ermöglicht das Enterprise Glossary auch die fachliche Anreicherung von Datenobjekten. Dadurch entstehen aus rein technischen Metadaten verständliche, fachlich beschriebene Data Products, die gezielt veröffentlicht und genutzt werden können.
Unternehmen schaffen damit die wesentlichen Voraussetzungen für erfolgreiche Data Products:
Transparenz über vorhandene Daten
Auffindbarkeit für Business-Anwender
Fachlicher Kontext und Bedeutung
Klare Verantwortlichkeiten
Zentrale Bereitstellung und Governance
Möchte ein Business User beispielsweise prüfen, ob ein Data Product bereits in Frontend-Anwendungen wie SAP Analytics Cloud, SAP BusinessObjects oder Power BI verwendet wird, lassen sich entsprechende Beziehungen direkt nachvollziehen:
In zukünftigen Versionen wird das Enterprise Glossary zudem ermöglichen, technische Metadaten sowie semantische Anreicherungen über eine REST API in maschinenlesbaren Formaten anderen Plattformen oder AI-Use Cases bereitzustellen.
Damit schafft das Enterprise Glossary eine technologieoffene Grundlage, um Data Products schrittweise aufzubauen, zu dokumentieren und unternehmensweit nutzbar zu machen.
Fazit
Data Products machen Unternehmensdaten verständlich, vertrauenswürdig und nutzbar, indem sie Daten mit fachlichem Kontext, Verantwortlichkeiten und Qualitätsinformationen verbinden.
SAP bietet mit der Business Data Cloud einen Ansatz, um Data Products im SAP-Umfeld bereitzustellen. Für viele Unternehmen bleibt jedoch die Herausforderung, heterogene Systemlandschaften abzubilden und langfristig flexibel zu bleiben.
Das Enterprise Glossary schafft hierfür die semantische Grundlage: Es verbindet technische Metadaten mit fachlichem Kontext über Systemgrenzen hinweg und ermöglicht es Unternehmen, Data Products verständlich, auffindbar und unabhängig von einzelnen Plattformen nutzbar zu machen.
Weitere Infos zur Lösung sowie die Anfrage einer Testversion finden Sie auf unserer Webseite: