Data Products

Dieser Leitfaden ist für dich, wenn in deinem Unternehmen gerade jemand „wir brauchen Data Products" gesagt hat — und du jetzt herausfinden musst, was das operativ bedeutet: Was ist ein Data Product überhaupt, wie baut man es, und wie muss die Organisation drumherum aussehen? Ich komprimiere hier, was ich aus meiner eigenen CDO-Praxis und aus den Gesprächen mit Datenverantwortlichen von ZEISS, Siemens Energy, PowerCo, FIEGE, MOIA und Metro gelernt habe.

Was sind Data Products? Die Definition

Ein Data Product ist ein Datenangebot, das wie ein Produkt behandelt wird: Es hat einen Owner, einen klaren Geschäftszweck, dokumentierte Qualität und einen Lebenszyklus — und es ist so aufbereitet, dass der Konsument es selbstständig nutzen kann.

Meine eigene Arbeitsdefinition aus dem Podcast (Folge mit Tim Wiegels): Ein Datenprodukt ist ein Service, den du innerhalb oder außerhalb des Unternehmens so zur Verfügung stellst, dass er für den Konsumenten direkt konsumierbar ist — ohne dass jedes Mal jemand Hand anlegen muss, außer zur Weiterentwicklung. Die Gegenprobe ist genauso wichtig: Ganz viele Analysen sind kein Datenprodukt. Wenn du eine Auswertung so händisch baust, dass du sie nicht reproduzieren kannst, hast du ein Ergebnis geliefert, aber kein Produkt gebaut.

Sarah S. hat es in ihrer Folge um den Lebenszyklus ergänzt: Ein Datenprodukt wird von Endanwendern selbstständig verwendet und durchläuft wie jedes Produkt Entwicklungsphase, Launch, Wartung und irgendwann die Marktentnahme. Und Tatjana S., Product Owner des Logistics Data Product Teams bei FIEGE, bringt die Produkt-Denke auf den Punkt: „ein Produkt muss ein Ziel haben, ein Problem lösen und ein Produkt muss auch wettbewerbsfähig bleiben" (Folge zu FIEGE). Wichtig dabei: Es muss kein Dashboard sein — eine Daten-API ist genauso ein Data Product, sobald sie skalierbar Mehrwert liefert.

Die Bestandteile eines Data Products

Ales Zeman, der seit über 25 Jahren Datenprodukte baut und heute bei Quest an Trusted Data Products arbeitet, zerlegt ein Data Product in vier Bausteine — wir haben es im Gespräch die Lego-Analogie genannt (Folge zu Business-Intent):

1. Daten — der Rohstoff selbst
2. Modell — das Datenmodell, das die Daten konsumierbar strukturiert
3. Kontext — die Metadaten: Was bedeutet das, woher kommt es, wie aktuell ist es?
4. Vermarktung — Visibilität: Ein Data Product, das keiner findet, existiert praktisch nicht

Das mit Abstand häufigste Data Product da draußen ist übrigens wenig glamourös: „die meisten Datenprodukte, die heißen wirklich Kunde 360" — Sichtbarkeit darauf, was Kunden kaufen und wie sie sich verhalten.

Data Product vs. Datensatz vs. Report

Bei ZEISS Digital Partners ist genau das der Anspruch im Betrieb: „Alle Daten, die unsere Data Landings verlassen, werden wie Produkte behandelt" — mit Operations-Modus, Maintenance-Plan, geregelter Access-Freigabe und Bugfix-Fristen (Folge mit Vanessa G.).

Wie implementiert man Data Products in einer Organisation?

Die kurze Antwort: mit dem Geschäftszweck zuerst, nicht mit der Technik. Ales Zeman formuliert es im Podcast drastisch: Wenn man den Geschäftszweck nicht vorher bestimmt hat, scheitern die Projekte — „Die kriegen keine Unterstützung, die kriegen keine Ergebnisse, keinen ROI." Jedes Data-Product-Vorhaben beginnt deshalb mit der Frage: Was wollen wir erreichen?

Die vier Implementierungs-Schritte, die sich durch die Praxis-Cases ziehen:

1. Business-Intent definieren. Wer konsumiert das Produkt, welches Problem löst es, was ist der messbare Mehrwert? Erst wenn das steht, lohnt sich die erste Pipeline.
2. Gemeinsames Datenmodell schaffen. Ohne ein geteiltes konzeptionelles Modell — schon die Frage „was ist ein Kunde?" — ist ein abteilungsübergreifendes Data Product nicht baubar: „Da arbeiten immer noch alle in den Silos."
3. Auffindbarkeit herstellen. Datenkatalog, Dokumentation, Metadaten. Das ist auch der häufigste Blocker im Mittelstand: KI-Initiativen brauchen vertrauenswürdige Daten, „und der Weg dahin ist über Datenprodukte" — aber vielen fehlt schlicht der Katalog.
4. Betrieb organisieren. Maintenance-Plan, SLAs, Feedback-Kanal, Weiterentwicklung — sonst verfällt das Produkt zum Datensatz.

Warum der Zweck-zuerst-Ansatz so viel Geld spart, zeigt eine Geschichte aus Folge 335 mit Ales Zeman: Eine Versicherung definierte ein Betrugs-Erkennungs-Datenprodukt — sechs Monate Abstimmung, Teams von 5–10 Leuten aus verschiedenen Abteilungen, und als Ergebnis der Anforderungsdefinition 350 Excel-Sheets. Interne Kosten: rund 400.000 Euro für ein einzelnes Datenprodukt. Seine Rechnung dazu: Wenn das Produkt zwei Millionen mehr Umsatz bringt, kann man das vertreten — aber beim nächsten Use Case fing das Unternehmen wieder bei null an. Die Lehre: wiederverwendbare Modelle und Automatisierung statt Einzelanfertigung.

Und die zweite große Lehre kommt von Siemens Energy (Folge mit Jonas K.): Adoption schlägt Architektur. „Ich baue schöne Data Products, aber niemand konsumiert die. Dann liegen sie trotzdem immer noch irgendwo rum." Ein Data Product ohne Nutzer ist kein Asset, sondern laufende Kosten.

Die Schritt-für-Schritt-Anleitung mit allen Praxisbeispielen findest du im Cluster Wie implementiert man Data Products?.

Wie baut man eine Data Product Organisation auf?

Das Muster, das sich über fast alle Folgen zieht, hat Dr. Sven Willrich von PowerCo in einem Satz zusammengefasst: „Wir zentralisieren Technik, wir dezentralisieren die Data Ownership." (Folge zur Daten-Demokratisierung)

Konkret heißt das:

• Zentral: Plattform, Infrastruktur, Standards, Governance-Rahmen. Bei Siemens Energy gibt es dafür Ingestion-as-a-Service und Data-Products-as-a-Service — die zentrale Einheit nimmt den Fabriken die Extraktionsarbeit ab und gibt bereinigte Daten als Produkte zurück.
• Dezentral: Die Verantwortung für die Inhalte. Die Domäne, die die Daten am besten versteht, verantwortet das Data Product.

Warum nicht einfach alles zentral? Weil das zentrale Team sonst zwangsläufig zum Engpass wird. MOIA hat diesen Weg bewusst hinter sich: „Wir hatten so ein Setup früher auch, als wir noch kleiner waren" — und hat die Ownership dann gezielt zu den produzierenden Teams verlagert, „weil das sonst früher oder später natürlich zum Bottleneck wird" (Folge mit Rieke D.). Die BVG kam zum selben Schluss: „damit wir skalieren, müssen wir die anderen befähigen. Wir müssen dezentrale Datenteams aufbauen." (Folge mit Sebastian H.)

Und warum nicht alles dezentral? Auch dafür gibt es eine klare Warnung aus der Praxis: „Jeder Fachbereich baut seine Data Engineers auf. Wo landen wir denn da?" Dezentralisierung der Ownership heißt nicht, dass jede Abteilung ihre eigene Dateninfrastruktur betreibt.

ZEISS zeigt, dass es dazwischen Abstufungen gibt: zentrale, hybride und dezentrale Datendomänen — je nachdem, wie viel Verantwortung der Fachbereich tragen kann und will (Data-Mesh-Journey der ZEISS Group). Die Organisation muss atmen können: Was heute zentral startet, kann morgen in die Domäne wandern.

Wie die Rollen im Detail aussehen — Data Owner, Data Product Owner, Plattform-Team, Domänen-Team — steht im Cluster Organisation & Rollen.

Welche Rollen gibt es in Data Platform Teams?

Die wichtigste Abgrenzung, die in der Praxis ständig verwechselt wird, kommt aus der PowerCo-Folge:

• Data Owner — trägt die Datenverantwortung für ein Quellsystem bzw. eine Domäne. Sitzt im Fachbereich.
• Data Product Owner — „jemand, der wie ein Use-Case-Owner agiert": verantwortet ein konkretes Data Product als agil entwickeltes Artefakt, inklusive Roadmap und Konsumenten-Feedback.

Dazu kommen die Plattform- und Umsetzungsrollen: Data Engineers, Analytics Engineers / BI und Data Scientists. Als Größenordnung aus der Tim-x-Jonas-Diskussion über Team-Strukturen: rund 25 Prozent Analytics und Data Science — der Rest ist Data Engineering, BI und Plattform (Folge zu Data-Team-Strukturen). Datenarbeit ist zum größten Teil Engineering-Arbeit.

Wie groß ist so ein Team? ZEISS Digital Partners betreibt eine Marketing-Data-Domäne mit fünf Personen; bei FIEGE verantworten sieben Leute das Logistik-Kern-Datenprodukt, das 140 Standorte mit Wareneingangs-, Warenausgangs- und Bestandsdaten versorgt. Man braucht also keine 50-Personen-Organisation, um professionell Data Products zu betreiben — man braucht klare Verantwortung.

Source-Aligned vs. Consumer-Aligned Data Products

Die Kurzfassung: Source-Aligned Data Products sitzen nah am Quellsystem und stellen dessen Daten stabil und sauber bereit; Consumer-Aligned Data Products sind für einen konkreten Use Case eines Konsumenten gebaut. ZEISS Digital Partners arbeitet in der Praxis sogar mit drei Zonen-Typen — Source-Aligned, hybrid und Consumer-Aligned.

Warum die Unterscheidung praktisch wichtig ist (und wo ihre Grenzen liegen — inklusive der Frage, wo die Verantwortung eines Source-Aligned-Teams endet), habe ich im Cluster Source-Aligned vs. Consumer-Aligned ausführlich aufgeschrieben.

Data Products und Data Mesh: Wie hängt das zusammen?

Data Products sind das zentrale Artefakt im Data Mesh — das Prinzip „Data as a Product" ist eines der vier Mesh-Prinzipien. Aber die Abhängigkeit ist einseitig: Du brauchst kein Data Mesh, um Data Products zu bauen. Ein Mittelständler mit einem guten zentralen Team kann Daten produktförmig behandeln, ohne Domänen-Ownership und federierte Governance einzuführen. Umgekehrt gilt: Ein Data Mesh ohne Data-Product-Disziplin ist nur ein dezentralisiertes Data Warehouse mit schönen Worten.

Wenn deine eigentliche Frage die Organisationsform ist (Mesh ja/nein, ab welcher Größe), starte beim Data-Mesh-Leitfaden. Wenn deine Frage lautet „wie machen wir aus unseren Daten nutzbare Produkte?", bist du hier richtig.

Data Product Portfolio: den Überblick behalten

Sobald mehr als eine Handvoll Data Products existiert, brauchst du einen Portfolio-Blick: Welche Produkte gibt es, wer konsumiert sie, welche rechnen sich? PowerCo macht die Effizienz des Data Managements an einer einzigen Kennzahl fest: der Wiederverwendbarkeit von Datenprodukten. Ein Datenprodukt soll so oft wie möglich wiederverwendet werden — auch von anderen Datenprodukten, denn „ein Dataprodukt kann ein anderes Dataprodukt konsumieren".

Das Portfolio beantwortet auch die unangenehme Frage: Welche Produkte haben keine Konsumenten? Die Siemens-Energy-Lehre gilt hier doppelt — ein unbenutztes Data Product im Portfolio ist ein Kostenblock, kein Asset. Und die Metro-Beispiele zeigen die andere Seite: Cross-Sell- und Alternativ-Recommender sind Data Products, deren Wertbeitrag direkt im Umsatz messbar ist (Folge mit Anna H.).

Praxisbeispiele: Welche Data Products bauen Unternehmen wirklich?

Damit das Konzept nicht abstrakt bleibt — die Datenprodukte, die mir in den Podcast-Gesprächen am häufigsten begegnen, sortiert nach Typ:

Der Klassiker: Kunde 360. Ales Zeman sagt es trocken: „Die meisten Datenprodukte, die heißen wirklich Kunde 360" — die konsolidierte Sicht darauf, was Kunden kaufen und wie sie sich verhalten, über Systeme hinweg. Unspektakulär, aber das Fundament für fast alles Weitere: Personalisierung, Churn-Modelle, Service-Steuerung. Wenn du nicht weißt, womit du anfangen sollst, fang hier an — vorausgesetzt, die Frage „was ist ein Kunde?" ist abteilungsübergreifend beantwortet.

Umsatzwirksame Modelle im Handel. Metro Digital betreibt Cross-Sell-Recommender („er schaut nach Kaffee — Zucker und Milch — ich inspiriere meinen Kunden, mehr zu kaufen") und Alternativ-Recommender als Datenprodukte, deren Wertbeitrag direkt an der Kasse messbar ist (Folge mit Anna H.). Solche Produkte sind ideale Leuchttürme, weil niemand über ihren Nutzen diskutieren muss.

Standardisierte Kern-Daten als Produkt. Das FIEGE-Muster: Ein Team, ein Produkt, 140 Standorte — statt 140 lokaler Excel-Wahrheiten. Der Wert liegt nicht in einem cleveren Modell, sondern in Verlässlichkeit und Standardisierung. Nebeneffekt aus der Folge: Das Datenteam wuchs mit dem Erfolg des Produkts auf 19 Personen — Datenprodukte schaffen ihre eigene Nachfrage.

Prozess-Datenprodukte mit Preisschild. Bei Siemens Energy wurde aus einer kompletten Prozessketten-Analyse das Procurement Cockpit — nach eigener Aussage „das stärkste skalierte Datenprodukt" der Geschäftseinheit: Ein manueller Prozess, der einen Kollegen 20 Stunden pro Woche kostete, läuft heute in zwei Minuten (Folge mit Max J.). Das Entscheidende ist die Denkweise dahinter: „Mit diesen Kennzahlen können wir ein gewisses Preisschild an unsere Use Cases bringen."

Interne Daten-Services als Produkt. Die Meta-Ebene von Siemens Energy: Ingestion-as-a-Service und Data-Products-as-a-Service sind selbst Datenprodukte — mit den Fabriken als Kunden. Wer Plattform-Teams führt, sollte sie genauso behandeln: mit Nutzern, Feedback und Roadmap.

Auffällig quer durch alle Fälle: Kein einziges dieser Produkte ist ein Dashboard. Dashboards sind Konsum-Oberflächen — die Datenprodukte dahinter sind Datensets, Modelle, APIs und Services.

Wie misst man den Erfolg von Data Products?

Die unbequeme Wahrheit zuerst: Deployment ist keine Erfolgsmetrik. Ein Data Product, das live ist, aber nicht genutzt wird, „liegt trotzdem immer noch irgendwo rum" (Siemens Energy). Die vier Messgrößen, die sich in den Gesprächen als tragfähig erwiesen haben:

1. Aktive Konsumenten. Wer nutzt das Produkt regelmäßig — Teams, Systeme, andere Datenprodukte? Die Metrik hinter der Siemens-Energy-Lehre „Adoption schlägt Architektur".
2. Wiederverwendungsrate. Die PowerCo-Kennzahl: „Wie messen wir die Effizienz im Data Management durch die Wiederverwendbarkeit von Datenprodukten?" Ein Produkt, das in fünf Use Cases steckt, hat seine Baukosten fünfmal verteilt.
3. Wertbeitrag des Use Case. Zemans einfache Kaufmannsrechnung: 400.000 Euro Produktkosten gegen zwei Millionen Mehrumsatz — „dann kann ich das vielleicht machen." Nicht jedes Produkt braucht eine Euro-Zahl, aber jedes braucht eine Antwort auf die Frage, was ohne es schlechter wäre.
4. Zeit bis zum nächsten Produkt. Die Systemfrage: Wird das zweite, dritte, vierte Produkt schneller und billiger als das erste? Wenn nicht, baust du Einzelanfertigungen — genau das Muster, das die Versicherung aus der 400.000-Euro-Story bei jedem Use Case von vorn beginnen ließ.

Wo diese Messbarkeit organisatorisch aufgehängt ist, entscheidet der Reifegrad: Ab Data-Maturity-Stufe 4 werden Datenprodukte selbst mit Metriken und SLAs geführt — vorher ist schon die ehrliche Nutzungs-Messung ein großer Schritt.

Häufige Fehler beim Aufbau von Data Products

1. Technik vor Zweck. Plattform gekauft, Pipelines gebaut, Use Case unklar — der teuerste Klassiker.
2. Analysen als Produkte verkaufen. Nicht reproduzierbare Einmal-Auswertungen ins „Portfolio" zählen.
3. Ownership zentralisieren. Das zentrale Team wird Bottleneck; die Fachbereiche fühlen sich nicht verantwortlich.
4. Alles dezentralisieren. Jede Abteilung baut eigene Engineers und eigene Infrastruktur auf — Wildwuchs statt Mesh.
5. Visibilität vergessen. Ohne Katalog und interne „Vermarktung" wird selbst das beste Produkt nicht gefunden.
6. Silos im Datenmodell lassen. Ohne gemeinsame Definition der Kernentitäten scheitert jedes abteilungsübergreifende Produkt.
7. Betrieb nicht einplanen. Ohne Maintenance-Plan und Bugfix-Fristen degeneriert das Produkt nach dem Launch.

Weiterlesen im Cluster

• Wie implementiert man Data Products in einer Organisation? — Schritt für Schritt, mit den Cases von Quest, Siemens Energy und FIEGE
• Data Product Organisation & Team aufbauen — Rollen, Strukturen, Teamgrößen aus der Praxis
• Source-Aligned vs. Consumer-Aligned Data Products — die Zonen-Logik am ZEISS-Beispiel
• Data Mesh — wenn deine Frage die Organisationsform ist
• Datengetriebene Transformation — der größere Rahmen: Kultur, Change, Rollen