„Wie implementiert man Data Products in einer Organisation?" ist die falsche erste Frage — die richtige lautet: Warum? Alles, was ich in den Podcast-Gesprächen über erfolgreiche und gescheiterte Datenprodukt-Initiativen gelernt habe, läuft auf diesen Punkt zu: Der Business-Intent entscheidet, die Technik folgt.
Schritt 1: Business-Intent definieren
Ales Zeman baut seit über 25 Jahren Datenprodukte, heute bei Quest. Seine Erfahrung aus unserem Gespräch: „Wenn man den Geschäftszweck nicht vorher bestimmt hat, was will man erreichen, dann scheitern die Projekte. Die kriegen keine Unterstützung, die kriegen keine Ergebnisse, keinen ROI."
Konkret heißt das, vor der ersten Pipeline drei Fragen schriftlich zu beantworten:
- Welches Geschäftsproblem löst das Produkt? („Betrugsfälle früher erkennen", „Cross-Sell-Quote erhöhen")
- Wer konsumiert es? Eine Fachabteilung, ein anderes Data Product, ein externer Partner?
- Was ist der messbare Mehrwert? Zemans einfache Rechnung: „wenn ich 400.000 Euro für so ein Datenprodukt bezahle […] und mir zwei Millionen mehr Umsatz oder Gewinn — dann kann ich das vielleicht machen."
Ohne diese Antworten ist jedes Data-Product-Vorhaben ein Technikprojekt auf der Suche nach einer Rechtfertigung.
Schritt 2: Gemeinsames Datenmodell schaffen
Der unsichtbare Blocker bei abteilungsübergreifenden Data Products ist selten die Technologie — es sind die Begriffe. Zeman: „Wenn die ein Konzept nicht gemeinsam haben, da wird ein Datenprodukt abteilungsübergreifend nicht möglich sein aufzubauen. Da arbeiten immer noch alle in den Silos."
Die Nagelprobe ist banal: Definieren Vertrieb, Marketing und Service „Kunde" gleich? Wenn nicht, braucht das Produkt zuerst ein gemeinsames konzeptionelles bzw. logisches Datenmodell der Kernentitäten. Das ist Abstimmungsarbeit, keine Engineering-Arbeit — und genau deshalb wird sie gern übersprungen.
Wie teuer das Überspringen wird, zeigt der Versicherungs-Fall aus derselben Folge: Für ein Betrugs-Erkennungs-Datenprodukt brauchte die Abstimmung zwischen Fachabteilung, Datenabteilung und Analysten sechs Monate, mit Teams von 5–10 Leuten — und das Ergebnis der Anforderungsdefinition waren 350 Excel-Sheets. Interne Kosten: rund 400.000 Euro für ein einzelnes Datenprodukt. Das eigentliche Drama: Beim nächsten Use Case begann die Organisation wieder bei null, weil nichts davon wiederverwendbar angelegt war.
Schritt 3: Auffindbarkeit und Vertrauen herstellen
Ein Data Product, das niemand findet, existiert praktisch nicht. Zemans Bausteine-Logik (Daten, Modell, Kontext, Vermarktung) macht Metadaten und Visibilität zu Pflichtbestandteilen — nicht zu Nice-to-haves. Praktisch heißt das: Datenkatalog, dokumentiertes Schema, benannter Owner, Kontaktweg.
Das ist auch der Punkt, an dem aktuell viele Mittelständler hängen. Der Treiber für Data Products ist 2026 fast immer KI: „KI braucht gute Daten, vertrauensvolle Daten. Und der Weg dahin ist über Datenprodukte." Aber viele Unternehmen scheitern schon einen Schritt davor — „weil die überhaupt noch nicht einen Datenkatalog haben."
Schritt 4: Betrieb und Wiederverwendung organisieren
Nach dem Launch beginnt die eigentliche Produktarbeit. Bei ZEISS Digital Partners gilt: „Alle Daten, die unsere Data Landings verlassen, werden wie Produkte behandelt" — mit Operations-Modus, Maintenance-Plan, geregelter Access-Freigabe und Bugfix-Fristen (ZEISS-Praxisfolge).
Und: Baue jedes Produkt so, dass es wiederverwendet werden kann. Bei PowerCo ist die Wiederverwendungsrate die zentrale Effizienz-Kennzahl des Data Managements — „ein Datenprodukt soll so oft wie möglich Wiederverwendung finden", auch als Baustein in anderen Datenprodukten (PowerCo-Folge).
Der Skalierungs-Case: Siemens Energy
Wie sich diese Schritte in einem Konzern zusammensetzen, zeigt die Folge mit Jonas K. von Siemens Energy. Ausgangslage: In über 30 Fabriken bauten ausgebildete Data Citizens parallel — und ohne voneinander zu wissen — „eigentlich dasselbe Datenprodukt". Fleißig, engagiert, komplett redundant.
Die Antwort war keine Verbotskultur, sondern ein Service-Angebot: eine zentrale Dateninitiative mit Ingestion-as-a-Service und Data-Products-as-a-Service. Die zentrale Einheit übernimmt die Datenextraktion für die Fabriken komplett und gibt bereinigte Daten als Datenprodukte zurück; die Data Citizens vor Ort konzentrieren sich auf ihre Use Cases. Ein Pilot-Werk teilt heute Datenprodukte über alle Domänen der Factory Data Cloud.
Die dazugehörige Warnung aus derselben Folge gilt für jede Implementierung: „Ich baue schöne Data Products, aber niemand konsumiert die. Dann liegen sie trotzdem immer noch irgendwo rum." Adoption schlägt Architektur — miss Nutzung, nicht Deployment.
Der Standardisierungs-Case: FIEGE
Den Mittelstands-Blick liefert FIEGE: Statt dass jeder Logistik-Standort eigene Excel-Lösungen pflegt, verantwortet ein Logistics Data Product Team mit sieben Leuten das zentrale Datenprodukt — standardisierte Wareneingangs-, Warenausgangs- und Bestandsdaten für 140 Standorte. Product Ownership auf Daten übertragen heißt hier wörtlich: „Man ist wirklich dafür zuständig, die Datenprodukte von Anfang an zu designen."
Checkliste für den Start
- [ ] Geschäftszweck, Konsument und Mehrwert schriftlich definiert?
- [ ] Kernentitäten abteilungsübergreifend gleich definiert?
- [ ] Owner benannt, Katalog-Eintrag mit Metadaten vorhanden?
- [ ] Maintenance-Plan, SLAs und Feedback-Kanal geregelt?
- [ ] Wiederverwendung mitgedacht (Modell, Bausteine, Standards)?
- [ ] Nutzungs-Messung aufgesetzt (Konsumenten, Wiederverwendungsrate)?
Wie du die Organisation und die Rollen dafür aufstellst, steht im Cluster Organisation & Rollen; die Zonen-Logik für die Architektur im Cluster Source-Aligned vs. Consumer-Aligned. Den Gesamtüberblick gibt die Data-Products-Pillar.