In den letzten Jahren ist der Hype um den Wert von Daten kontinuierlich gestiegen. Gleichzeitig sind eine Vielzahl von Konzepten und Methoden aufgekommen, wie man als Unternehmen "datengetrieben" werden kann. Vom strategischen Top-Management bis zum detailorientierten Data-Analysten wird auf allen Ebenen versucht, Daten in den Mittelpunkt der Wertschöpfung zu rücken. Die Initiativen pendeln regelmäßig zwischen holistischer Datenstrategie ("Wir brauchen erstmal gemeinsame Regeln, bevor wir uns konkret mit Daten beschäftigen") und explorativer Datenanalyse ("wir haben so viele Daten, da muss doch etwas Wertvolles drinstecken"). In der Konsequenz gibt es aber nur wenige Initiativen, die wirkliche Fortschritte auf dem Weg zum datengetriebenen Unternehmen produzieren. Applied Data Products unterstützen als integrativer Ansatz für Datenprodukte die konkreten Schritte auf dem Weg der Transformation.
Ein Kernproblem auf dem Weg zum datengetriebenen Unternehmen liegt zumeist darin, zu viel Gewicht auf einen von zwei Polen zu legen: Business oder Technologie. Während Governance, Regulierung und Use-Cases auf der einen Seite verortet ist, steht die Technologie mit ihren APIs, Data Mesh und UML-Diagrammen auf der anderen Seite. Die wenigsten Menschen im Unternehmen schaffen es, beides effektiv miteinander zu verbinden. So wird echtes Alignment zur Herausforderung.
Um die Kräfte im Unternehmen besser zu bündeln, haben wir für unseren Beratungsansatz bewährte und bekannte Frameworks kombiniert und adressieren genau diese Verbindung zwischen beiden Polen. Wir nennen diesen Ansatz Applied Data Products. Hierbei liegt der Fokus darauf, möglichst konkreten Mehrwert zu stiften, um dann ausgehend von erfolgreichen Einzelfällen eine Gesamtstrategie zu erarbeiten. Getreu dem Motto “Learn first, scale second”.
Mit einfachen Datenprodukten Effizienz erhöhen
Machen wir es ganz konkret: Wenn New Yorks Behörden Steuersündern mit einer ganzheitlichen Datenstrategie auf die Schliche kommen möchte, ist das Projekt langwierig, riskant und hat eine hohe Wahrscheinlichkeit an vielen Stellen zu scheitern. Die Kernfrage lautet: Wie kann ich datengestützt Steuerprüfer in die richtigen Unternehmen schicken? Nimmt man erstmal nur die Gastronomie-Branche heran, dann ist der Use Case fast schon offensichtlich: Getreu dem Motto: Viel Müll bedeutet viel Umsatz dürfte es reichen, die Müllcontainer mit den jeweiligen Mengenangaben systemisch zu erfassen und mit den eingereichten Umsätzen abzugleichen. Dort, wo die Abweichungen groß sind, sollte eine genauere Prüfung erfolgen. In der Tat wurde das Verfahren vor einigen Jahren erfolgreich angewandt. Die Erfassung von Müll und eine anschließende Verkreuzung der Umsatzddaten eingereichten Umsätze führte zu einer signifikanten Steigerung der Aufdeckung von Steuersündern.
Bei der Einführung von Applied Data Products ist der erste Schritt die klare Definition von einem oder mehreren konkreten Datenprodukten. Dabei gilt das Prinzip "Klasse statt Masse". Lieber eine Handvoll wohl überlegter Datenprodukte auf dem Weg zum datenzentrierten Unternehmen, als zu viel gleichzeitig zu unternehmen. Neben dem eigentlichen Datenprodukt ist ein Ziel dieses Schrittes, über die eigene Organisation zu lernen, welche Aspekte datengetriebenen Handelns bereits funktionieren - und in welchen konkreten Bereichen es noch Handlungsbedarf gibt. Wichtig ist, in Daten denken zu lernen. Es spielt keine Rolle, ob ein Datenprodukt eine lokale Excel-Liste ist, oder ein Data-Lakehouse mit angeschlossenen Self-Service BI-Dashboard.
Für die Definition von Datenprodukten haben wir einen Data Product Canvas entwickelt, den wir bereits in unterschiedlichen Branchen und für eine Vielzahl von Szenarien anwenden konnten. Angelehnt an den Business Model Canvas dient er dazu, allen Stakeholdern einen schnellen und umfassenden Gesamtüberblick über das jeweilige Datenprodukte zu geben. Er soll kein Ersatz für fachliche oder technische Dokumentationen sein, vielmehr positionieren wir ihn als Conversation Starter. Statt alle Details klar und unmissverständlich zu adressieren dient er in erster Linie als Diskussionsgrundlage, unter anderem für Fragestellungen wie:
- Welche Quellsysteme müssen wir einbinden? Wer verantwortet diese Systeme (und somit die Qualität der gelieferten Daten)?
- Worin besteht der Mehrwert unseres Produkts? Welche Veredelungs- oder Aufbereitungsschritte müssen wir auf den Quelldaten durchführen?
- Welche Handlungen soll unser Datenprodukt ermöglichen - direkt und indirekt?
- Wo entstehen Kosten bei der Erbringung des Produkts?
- Wie lässt sich Erfolg messen?
Der Aufbau des Data Product Canvas
Um alle wesentlichen Informationen hinsichtlich eines Datenprodukts abzubilden, teilt sich unser Data Product Canvas in 5 Bereiche mit insgesamt 11 Feldern auf. Über allem steht eine klar verständliche Management Summary, die (nicht nur) für das Management klar und deutlich beschreibt, was die Kernidee dieses Data Products ist.
Der Hauptteil des Canvas besteht aus den drei Blöcken
- Sources, Storage & Processing
- Value Proposition
- Discoverability, Distribution & Usage
Ergänzt wird der Canvas nach unten mit zusätzlicher Information, die zwar nicht im Kern des Produkts stehen, aber dennoch im Rahmen der Konzeption und Entwicklung eine Rolle spielen. Da die Projektsprache in der IT häufig Englisch ist, nutzen wir für die Bezeichnung der Felder ebenfalls englischsprachige Begriffe. Der Canvas selbst kann natürlich auch in Deutsch befüllt werden.
Die Inhalte des Data Product Canvas
Bisweilen sind Informationen nicht eindeutig einem Feld zuordenbar, im Sinne eines Conversation Starters ist aber auch nicht wichtig, dass Themen im richtigen Feld aufgenommen werden, sondern dass sie aufgenommen und berücksichtigt werden.
Von links nach rechts bzw. oben nach unten umfassen die Felder folgende Inhalte:
Data Providers
Organisatorische wie technische Datenquellen stehen am Anfang der Wertschöpfungskette. Je nach Abstraktionsgrad lassen sich hier Abteilungen oder bereits ganz konkrete Systeme benennen. Die Informationen im Feld Data Providers adressieren Aspekte wie
- Welche Inhalte zieht das Datenprodukt aus welchen Quellsystemen heran?
- Handelt es sich um interne Unternehmensdaten oder externe Daten?
- Welche Abteilungen sind Datenlieferanten und wer ist zuständig für die Definition dieser Daten?
Data Processing
Sobald Daten vorhanden sind, werden mit ihnen Aktionen durchgeführt. Im simpelsten Fall werden sie nur aggregiert, vermutlich fallen hier aber auch Aufbereitung und Verarbeitungsschritte an. Die Dokumentation kann abstrakt nach den Umsetzungsphasen oder auch konkret mit Nennung von Werkzeugen erfolgen. Die Informationen im Feld Data Processing adressieren Aspekte wie
- Welche Arbeitsschritte werden mit den Daten vor der Bereitstellung durchgeführt?
- Welche Schritte zum Data Cleansing erfolgen?
- Wie wird das Thema Datenqualität und Redundanz adressiert?
- Erfolgen Verdichtungsschritte via ETL oder Machine Learning?
Frequency & Storage
Um Daten im Rahmen des Produkts bereitzustellen, müssen diese (persistent) abgelegt sein. Ob und wenn Daten langfristig gespeichert werden oder nur ad hoc berechnet und verteilt werden ist Kerninhalt dieses Themenblocks. Dazu kommt die Frage, in welcher Frequenz sich die (zusammengefassten) Daten ändern und für die Konsumenten verfügbar sind. Ist dies monatlich, täglich, stündlich oder in Echtzeit?
Value proposition(s)
Im Kern des Canvas steht die Value Proposition, also der eigentliche Mehrwert des Datenprodukts. Damit adressiert es die zentrale Frage, welchen Wert die (Nutzung) der Daten für eine Abteilung oder das gesamte Unternehmen bereitstellt. Hier steht der Impact oder auch Outcomes im Vordergrund, nicht die kleinteiligen Outputs, die mit dem Produkt verbunden sind.
Distribution & Access
Die Bereitstellung der Daten und eine angemessene Regelung des Zugriffs ist essentiell für erfolgreiche Datenprodukte. Ob wöchentlich per E-Mail versendet oder via API jederzeit verfügbar muss allen Beteiligten ebenso klar sein, wie die Frage, wer eigentlich den Zugriff regelt. Lassen sich einzelne Datensätze granular freigeben oder bedeutet Zugriff auf das Datenprodukt, dass alle vorhanden Informationen auch eingesehen werden können. Auch hier kommen technische und organisatorische Informationen zusammen.
Discoverability & Semantics
Verwandt mit dem Thema Distribution & Access ist der Aspekt der Discoverability. Woher wissen Abteilungen und Anwender, dass es das Datenprodukt gibt? Existiert ein Datenkatalog oder werden Anwender gezielt eingeladen? Dazu kommt die Frage, wie die vorhandenen Daten zu interpretieren sind - was ist die Definition z.B. von “Umsatz” oder “Kunde”? Wer ist zuständig für die Dokumentation der Semantik, die bereits im Rückgriff auf Datenquellen relevant ist?
Target Users
Im Rahmen von Produkten muss immer bedacht werden, für wen diese umgesetzt werden. Damit sind die Ziel-Anwender diejenigen, für die konzeptionell Wert geschaffen werden soll. Dass auch andere Personen innerhalb oder außerhalb des Unternehmens gegebenenfalls ein Datenprodukt nutzen können, steht hier jedoch nicht im Mittelpunkt. In diesem Feld geht es vor allem darum zu schärfen, für wen das Produkt optimiert wird. Daraus ergeben sich in der Regel auch diejenigen Anwendungsfälle, die noch einmal gesondert aufgeführt werden.
Use Cases
Nachdem definiert ist, wer die Daten nutzen wird, dient das Feld Use Cases zur Dokumentation, was mit den Daten gemacht werden soll. Werden bestehende Anwendungsfälle besser unterstützt oder neue Use Cases erst möglich gemacht? Ist das eigene Produkt eigentlich nur ein Vorprodukt, welches in einer längeren Wertschöpfungskette steht? Ein klares Verständnis, was auf Basis des Produkts an Aktionen passiert, dient sowohl Produzenten als auch Konsumenten für ein gutes Erwartungshaltungsmanagement.
Cost Structure
Unter dem Canvas adressiert das erste flankierende Feld die größten Kostentreiber für das Datenprodukt. Es geht nicht darum, eine detaillierte Kostenplanung vorzunehmen, sondern Klarheit zu erlangen, ob Speicherung, Verarbeitung oder gar Erwerb von externen Daten zu den größten Kostenblöcken gehören.
Success Measurement
Da erfahrungsgemäß zahlreiche Datenprodukte zunächst mit Fokus auf interne Abteilungen erstellt werden, kann einer Cost Structure nicht immer eine Revenue Structure gegenübergestellt werden. Aus diesem Grund umfasst das letzte Feld des Cavas Kriterien, die den Erfolg des Datenprodukts messbar machen sollen. Dies kann in Form von Umsatz oder Profit definiert werden, alternativ auch über API-Aufrufe oder eine Reduktion von Zugriffen auf eine Excel-Liste im Sharepoint. Wesentlich ist, messbare Größen zu etablieren um auf dem Weg zum datengetriebenen Unternehmen auch tatsächlich lernen zu können.
Fazit
Ein bewährter Ansatz, bestehenden Unternehmen und den Mitarbeitenden nachhaltig Fortschritte auf dem Weg zur datengetriebenen Organisation zu ermöglichen, besteht in der konkreten Definition von Datenprodukten. Es braucht auch einen Mentalitätswandel, dass Organisationen in Datenprodukte denken. Dabei spielt es keine Rolle, ob es lokal gepflegte Excel-Tabellen oder hochkomplexe Machine-Learning-Pipelines hinter einem API-Gateway sind. Entscheidend ist, dass alle Beteiligten beginnen, den Wert von Daten für Geschäftsentscheidungen zu verstehen und in Datenprodukte zu übersetzen. Der Data Products Canvas ist nur ein Aspekt auf dem Weg zu Applied Data Products, der von weiteren Werkzeugen - wie einer klaren Stakeholder-Map - ergänzt wird. Durch diese Struktur erlaubt das Vorgehen, maximalen Fokus auf Mehrwerte zu setzen. Aus erfolgreichen Data Products lassen sich dann passende Regeln und Vorgaben ableiten. Zu viel Abstraktion und Vorgaben in den frühen Phasen führen zumeist zu geringeren Lerneffekten und deutlich langsameren Fortschritten auf dem Weg zur Datenzentriertheit.
Weitere Beiträge
von Stephan Hochhaus
Dein Job bei codecentric?
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.