Die Frage „wie baut man eine Data Product Organisation auf?" hat in den über 320 Podcast-Folgen eine erstaunlich konsistente Antwort bekommen — egal ob Konzern (ZEISS, Siemens Energy, PowerCo), Scale-up (MOIA) oder Mittelstand (FIEGE): Technik zentralisieren, Ownership dezentralisieren. Der Rest ist Ausgestaltung.
Das Grundmuster: Hybrid statt Entweder-oder
Dr. Sven Willrich von PowerCo bringt die Formel in seiner Folge auf den Punkt: „Wir haben Dezentralisierung auf der einen Seite und Zentralisierung auf der anderen Seite. Und das eine schließt das andere nicht aus. Weil wir zentralisieren Technik, wir dezentralisieren aber die Data Ownership."
Beide Extreme scheitern vorhersagbar:
Rein zentral → Bottleneck. MOIA hat das selbst erlebt: „Wir hatten so ein Setup früher auch, als wir noch kleiner waren und haben uns ganz bewusst in eine andere, eher dezentralisierende Richtung von Data Ownership bewegt" — weil ein übergreifendes zentrales Team „früher oder später natürlich zum Bottleneck wird" (Folge mit Rieke D.). Auch die BVG kam beim Aufbau ihres zentralen Datenteams schnell an den Punkt: „damit wir skalieren, müssen wir die anderen befähigen. Wir müssen dezentrale Datenteams aufbauen." (BVG-Folge)
Rein dezentral → Wildwuchs. Die Gegenwarnung kommt aus derselben PowerCo-Folge: „Wir bauen jetzt auch Data Engineers überall auf. Also jeder Fachbereich baut seine Data Engineers auf. Wo landen wir denn da?" Dezentrale Ownership heißt nicht dezentrale Infrastruktur.
Und ein Grundsatz für jede Struktur-Entscheidung, aus der Tim-x-Jonas-Folge über Team-Strukturen: „Du kannst nicht sagen, du startest es in der IT und auf Teufel komm raus bleibt es in der IT. […] Die Organisation muss atmen können." (Folge zu Data-Team-Strukturen) Die richtige Struktur ist eine Phase, kein Endzustand.
Die Rollen im Detail
Data Owner vs. Data Product Owner
Die am häufigsten verwechselten Rollen — sauber getrennt in der PowerCo-Folge:
| Data Owner | Data Product Owner | |
|---|---|---|
| Verantwortet | Daten einer Domäne / eines Quellsystems | ein konkretes Data Product |
| Sitzt | im Fachbereich | im Produkt-/Datenteam |
| Denkt in | Datenqualität, Zugriff, Governance | Use Case, Roadmap, Konsumenten |
| Analogie | Eigentümer | Produktmanager |
Willrich formuliert es so: Ein Data Product Owner ist „jemand, der sozusagen wie ein Use-Case-Owner agiert, also der im Prinzip dieses Artefakt, was da agil entwickelt wird, betreut als Owner" — während der Data Owner die Datenverantwortung am Quellsystem trägt.
Bei ZEISS ist der Data Owner explizit eine Fachbereichs-Rolle: „wir haben Rollen, die erfüllt sein müssen in den Domänen. Und eine ist zum Beispiel die des Data Owners" — die technische Umsetzung übernimmt das zentrale Team, aber „immer in Abstimmung, in Alignment mit dem Fachbereich" (ZEISS-Journey-Folge).
Wie ernst man die Rolle nehmen kann, zeigt BSH Hausgeräte: Dort gibt es einen eigenen Data-Owner/Data-Steward-Lernpfad, für den eine Nominierung durch den Bereichs-Vorgesetzten nötig ist — „weil das ist eigentlich, was den Data Access ermöglicht". Diese Vorarbeit, sagt Bartosch P., „hilft uns jetzt auch in Themen wie Data Mesh, Data Products" (BSH-Folge).
Product Ownership auf Daten übertragen
Bei FIEGE ist der Data Product Owner kein Datenmensch mit Zusatztitel, sondern eine echte Produktrolle: „als Product Owner entwickelt man auch unter anderem Datenprodukte. Man ist wirklich dafür zuständig, die Datenprodukte von Anfang an zu designen" (FIEGE-Folge). Ihr Produktverständnis kommt aus der klassischen Produktwelt: Ziel, Problem, Wettbewerbsfähigkeit.
Die Plattform- und Umsetzungsrollen
Rund um Owner und Product Owner braucht es die Umsetzung — das ist die Antwort auf die Frage „welche Rollen gibt es in Data Platform Teams?":
- Data Engineers — Pipelines, Ingestion, Datenmodelle im Betrieb
- Analytics Engineers / BI — Transformation, Metriken, Reporting-Schicht
- Data Scientists — statistische Modelle, ML, Prognosen
- Plattform-Engineering — Self-Service-Infrastruktur, Standards, Tooling
Als Größenordnung aus der Tim-x-Jonas-Diskussion einer Team-Benchmark: etwa 25 Prozent Analytics und Data Science, der Rest Data Engineering, BI und Plattform. Wer sein Datenteam mehrheitlich mit Data Scientists besetzt, hat meist ein Engineering-Problem in sechs Monaten.
Strukturen aus der Praxis
MOIA: drei Ebenen
MOIA organisiert Datenarbeit in drei Schichten (Folge mit Rieke D.): Datenproduzenten-Teams, „die ihre Daten auch durchaus als Datenprodukte begreifen und als Datasets zur Verfügung stellen", darüber plattformorientierte Datenteams pro Business-Domäne — plus dedizierte Data-Plattform- und Analytics-Plattform-Teams. Die Ownership liegt bewusst bei den produzierenden Teams und Domain-Analytics-Teams.
ZEISS: drei Domänen-Typen
ZEISS unterscheidet „zentrale, hybride und dezentrale Datendomänen": Zentral verantwortet die zentrale Einheit alles; hybrid übernimmt der Fachbereich die Data-Ownership bei cross-funktionaler Umsetzung; dezentral stellt das Plattform-Team „eigentlich nur Infrastruktur bereit und dezentral können die Teams ganz autark Datenprodukte implementieren". Das erlaubt, jede Domäne nach ihrer Reife einzustufen, statt der ganzen Organisation ein Modell überzustülpen.
Siemens Energy: Services statt Kontrolle
Die zentrale Dateninitiative bei Siemens Energy positioniert sich als Dienstleister — Ingestion-as-a-Service, Data-Products-as-a-Service — statt als Kontrollinstanz (Folge mit Jonas K.). Der Effekt: Die 30+ Fabriken hören auf, redundant dieselben Datenprodukte zu bauen, weil der zentrale Weg der bequemere ist.
Wie groß muss das Team sein?
Kleiner als gedacht — Verantwortung schlägt Headcount:
- ZEISS Digital Partners: Das Marketing-Data-Domänenteam arbeitet zu fünft und bildet zusammen mit der Sales-and-Service-Data-Landing-Zone das Team Customer Intelligence (ZEISS-Praxisfolge).
- FIEGE: Sieben Personen verantworten das Kern-Datenprodukt, „um zu gewährleisten, dass für 140 Standorte die Daten zur Verfügung stehen".
Der Startpunkt ist also keine Reorganisation, sondern ein Team mit klarem Produkt, klarem Owner und klaren Konsumenten. Wie das erste Produkt entsteht, steht im Cluster Wie implementiert man Data Products?; die architektonische Zonen-Logik im Cluster Source-Aligned vs. Consumer-Aligned. Den Überblick gibt die Data-Products-Pillar.