Die Datenorganisation und ihre Rollen gestalten

# Die Datenorganisation und ihre Rollen gestalten

Als Cynthia Stoddard bei einem großen Unternehmenssoftware-Anbieter die Rolle des CDO übernahm, erbte sie 340 Personen aus Analytics, Engineering und Governance, die an sechs verschiedene VPs berichteten, von denen keiner ihr unterstand. Ihr Strategie-Deck sagte „data as a product“. Ihr Organigramm sagte „Daten als Service-Ticket“. In der Lücke zwischen diesen beiden Sätzen scheitern die meisten CDO-Amtszeiten, still und leise.

Das Problem des Organisationsdesigns lässt sich trügerisch einfach formulieren und ist brutal in der Umsetzung: Ihre Struktur ist die physische Ausprägung Ihrer Strategie, und wenn beide sich widersprechen, gewinnt immer die Struktur. Menschen tun, was ihre Berichtslinie, ihre Incentives und ihr Umfeld ihnen vorgeben, nicht was Ihr Strategie-PDF verlangt. In dieser Lektion geht es darum, diese Lücke bewusst zu schließen.

Struktur folgt Strategie, wörtlich, nicht als Absichtserklärung

Die erste Disziplin besteht darin, keine KKThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ästchen zu zeichnen, solange Sie das *Operating Model* nicht benennen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen, das Ihre Strategie verlangt. Es gibt drei Archetypen, und die meisten Organisationen sind eine bewusste Mischung statt einer Reinform.

Zentralisiert. Alle Datentalente berichten an den CDO. Sie bekommen Konsistenz, Hebel auf knappe Spezialisten und eine einzige Adresse für Governance. Sie verlieren Domänenkontext und Geschwindigkeit; die Geschäftsbereiche ärgern sich über die Warteschlange. Das funktioniert, wenn die strategische Priorität darin liegt, *Kontrolle herzustellen*: regulatorische Nachbesserung, ein zerstörtes Vertrauensproblem oder eine erstmalige Enterprise-Datenplattform.

Dezentral (föderiert). Datenteams sitzen in den Geschäftsbereichen, mit gestrichelter Linie zu Ihnen. Sie bekommen Domänenkompetenz und Business Ownership. Sie verlieren Standards, duplizieren Tooling und stellen fest, dass „Umsatz“ auf elf verschiedene Arten definiert ist. Das funktioniert, wenn die Einheiten wirklich unterschiedliche Geschäfte sind und die Priorität *Geschwindigkeit nahe am P&L* ist.

Hub-and-Spoke. Ein zentraler Hub besitzt Plattform, Standards und knappe Fähigkeiten; eingebettete Spokes sitzen im Business und verantworten Delivery. Hier landen die meisten reifen Datenorganisationen, nicht weil es en vogue ist, sondern weil es die Kernspannung löst: Hebel im Zentrum, Kontext am Rand.

Die Ermessensfrage ist, *was in den Hub gehört und was in den Spoke*, und genau hier machen CDOs es falsch. Die richtige Sortierregel ist nicht „Wichtiges ins Zentrum“. Sie lautet:

> Zentralisieren Sie, was von Skalierung, Konsistenz oder Knappheit profitiert. Föderieren Sie, was von Kontext und Geschwindigkeit profitiert.

Lassen Sie jede Funktion durch diesen Filter laufen. Data Platform Engineering profitiert von Skalierung → Hub. Business AnalyticsBusiness AnalyticsTechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Vollständige Definition ansehen → profitiert von Kontext → Spoke. Data-Governance-Policy profitiert von Konsistenz → Hub, aber die *Ausführung* von Governance profitiert von Kontext → Spoke. Diese eine Unterscheidung, Policy zentral, Ausführung lokal, ist die wichtigste strukturelle Entscheidung, die Sie treffen werden, und wir kommen darauf zurück.

Schauen Sie sich an, wie Netflix und JPMorgan hier aus guten Gründen auseinandergehen. Netflix gibt eingebetteten Analysten enorme Autonomie, weil der strategische Engpass die Experimentiergeschwindigkeit ist. JPMorgan zentralisiert deutlich stärker, weil der Engpass die regulatorische Belastbarkeit ist und die Kosten eines Datenfehlers in Consent Orders gemessen werden. Keines von beiden ist „Best Practice“. Jede Struktur ist eine Wette darauf, wo die Friktion sitzt, die am meisten zählt.

Die Trennung von Governance und Delivery

Das häufigste strukturelle Versagen, das ich sehe, ist Governance und Delivery in einem Team unter einer Führungskraft zusammenzulegen. Es wirkt effizient. Es ist Gift.

Delivery-Teams werden am Ausliefern gemessen: Pipelines live, Dashboards gelauncht, Modelle in Produktion. Governance wird an Kontrolle gemessen: Qualität, Lineage, Zugriff, Compliance. Wenn dieselbe Führungskraft beides verantwortet, gewinnt Delivery *immer* den täglichen Trade-off, weil Delivery eine Deadline hat und Governance ein Prinzip. Qualität erodiert stillschweigend, bis ein Incident die Abrechnung erzwingt.

Die Lösung: die beiden Berichtslinien trennen und sie zugleich zwingen, einen gemeinsamen Workflow zu teilen. Governance setzt Policy und besitzt die Definition von „gut gemacht“. Delivery besitzt „schnell gemacht“. Sie treffen sich am Punkt der Produktion, dem Gate, durch das Datenprodukte ausgeliefert werden.

Hier das Betriebsmuster, das das ohne bürokratischen Krieg funktionieren lässt:

• Governance definiert die Controls als Code, nicht als Word-Dokument. Data Contracts, Qualitätsschwellen, Zugriffsrichtlinien und Klassifizierungsregeln leben in der PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen →, nicht in einem Review-Meeting.
• Delivery-Teams dürfen sich innerhalb dieser Guardrails schnell bewegen und eskalieren nur Ausnahmen.
• Der CDO verantwortet die Schlichtung, wenn beide kollidieren, und das werden sie.

Ein Data Contract ist das konkrete Artefakt, in dem diese Trennung real wird. ErErThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → ist die Schnittstelle zwischen einem Datenproduzenten und seinen Konsumenten und erlaubt, Governance automatisch durchzusetzen statt über Meetings:

dataset: customer_transactions
owner: payments-domain-team
sla:
  freshness: 15m
  availability: 99.9%
schema:
  - name: customer_id
    type: string
    classification: PII      # löst Zugriffs- + Maskierungsrichtlinie aus
    nullable: false
  - name: amount_usd
    type: decimal
    quality_check: "amount_usd >= 0"
consumers: [risk-analytics, finance-reporting]
breaking_change_policy: 30d_notice

Achten Sie darauf, was dieses Artefakt organisatorisch leistet. Das Feld owner erzwingt Accountability in der Domäne, eine Person, keine Warteschlange. Das Feld classification lässt zentrale Governance den Umgang mit PII durchsetzen, ohne jede PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → zu inspizieren. Die breaking_change_policy verhindert, dass ein Delivery-Team stillschweigend nachgelagerte Konsumenten kaputt macht. Der Contract kodiert Ihr Organisationsdesign in den Workflow, und das ist der einzige Ort, an dem Organisationsdesign den Kontakt mit der Realität übersteht.

Das ist der Mechanismus hinter Data MeshData MeshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.Vollständige Definition ansehen →, aber Sie brauchen das Buzzword nicht. Sie brauchen das Prinzip: Domänen besitzen ihre Datenprodukte Ende zu Ende, das Plattformteam gibt ihnen befestigte Wege, und Governance ist *computational* föderiert, durchgesetzt von der Plattform, nicht von einem Komitee.

Rollen: wer tatsächlich was verantwortet

Titel wuchern und bedeuten von Unternehmen zu Unternehmen nichts. Gestalten Sie Ihre Organisation um *Accountabilities* und hängen Sie dann Titel daran. Hier sind die Rollen, die zählen, und die Grenzentscheidungen, die sie funktionsfähig machen.

Der Data Product Manager ist die Rolle, in die die meisten CDOs zu wenig investieren und deren Auslassen sie am meisten bereuen. Wenn data-as-a-productdata-as-a-productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.Vollständige Definition ansehen → von der Folie in die Realität wandert, muss jemand ein Datenasset so verantworten, wie ein PM Software verantwortet: Roadmap, Konsumenten, SLAs und Lifecycle. Ohne diese Rolle sind „Produkte“ nur Tabellen mit besserem Marketing. Der DPM sitzt im Spoke, nah an der Domäne, und ist das menschliche Gegenstück zum obigen Data Contract.

Der Data Platform / Data Engineering Lead verantwortet den befestigten Weg: Ingestion, Transformation, Storage und Self-Serve-Tooling, auf dem die Spokes aufbauen. Diese Rolle gehört eindeutig in den Hub. Der Fehlermodus besteht darin, jede Domäne ihre eigene Plattform bauen zu lassen; am Ende finanzieren Sie fünf halbe Plattformen und haben keinen Hebel.

Der Analytics Engineer / Domain Analyst sitzt im Spoke und verwandelt rohe Domänendaten in entscheidungsreife Modelle. Das ist Ihre Kontextschicht. Sie zu zentralisieren nimmt dem Business die Geschwindigkeit.

Der Data Governance Lead verantwortet Policy, Standards, den Datenkatalog und die Definition von Qualität. Hub. Aber, entscheidend: ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → verantwortet *Policy und Tooling*, nicht die tägliche Durchsetzung in jeder Domäne. Seine Aufgabe ist, das Richtige zum Einfachen zu machen, eingebettet in die Plattform.

Data Stewards sind die föderierte Ausführung von Governance. Hier die Entscheidung, über die CDOs stolpern: *Stewards sollten nicht an Sie berichten.* Sie sollten respektierte Domänenexperten sein, die Datenqualität und Definitionen innerhalb ihres Geschäftsbereichs verantworten, mit gestrichelter Linie zur zentralen Governance. Ein Steward, der an zentrale Governance berichtet, ist ein Außenstehender, der die Domäne kontrolliert; ein Steward, der zur Domäne gehört, ist ein Insider, der sie verbessert. Gleiche Tätigkeit, gegenteiliges Ergebnis.

Ordnen Sie diese Rollen explizit der Hub/Spoke-Trennung zu:

| Rolle | Zuhause | Verantwortlich für |

|------|------|-----------------|

| Data Platform Eng | Hub | Befestigte Wege, Hebel, Tooling |

| Governance Lead | Hub | Policy, Katalog, Standards-as-Code |

| Data ProductData ProductA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.Vollständige Definition ansehen → Manager | Spoke | Produkt-Roadmap, SLAs, Konsumenten |

| Analytics Engineer | Spoke | Domänenmodelle, Entscheidungsunterstützung |

| Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → | Spoke (gestrichelt zum Hub) | Qualität & Definitionen in der Domäne |

Die Berichtslinien in dieser Tabelle *sind* Ihre Trennung von Governance und Delivery, konkret gemacht. Wenn Sie die Spalte „Zuhause“ für eine Rolle nicht ausfüllen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen, verstehen Sie noch nicht, wozu diese Rolle da ist.

Eine weitere Ermessensfrage: die Spanne zwischen Ihrem Plattformteam und Ihren eingebetteten Teams bestimmt Ihre Skalierungsobergrenze. Wenn jeder Spoke drei zentrale Engineers braucht, um irgendetwas auszuliefern, ist Ihre Plattform nicht Self-Serve, und bei einem Dutzend Domänen laufen Sie gegen eine Wand. Der Test ist unbarmherzig: *Kann ein Domänenteam ein neues Datenprodukt ausliefern, ohne ein Ticket beim Hub einzureichen?* Wenn nicht, haben Sie eine Serviceorganisation in den Kleidern einer Produktorganisation.

Sequenzierung, Berichtslinien und die Reorg, die Sie noch nicht machen sollten

Die meisten CDOs versuchen, im ersten Monat das perfekte Ziel-Organigramm zu zeichnen und es in einer Big-Bang-Reorg auszurollen. Das scheitert doppelt: das Design ist falsch, weil Sie noch nicht verstehen, wo die echte Friktion sitzt, und das politische Kapital verbrennt, bevor Sie Wert gezeigt haben.

Sequenzieren Sie die Struktur passend zu Ihrer strategischen Phase. In einer Phase des Kontrollaufbaus tendieren Sie zentral, bündeln knappe Talente, etablieren Standards, gewinnen die Vertrauensschlacht. Mit steigendem Vertrauen und wachsender Plattformreife *föderieren* Sie bewusst nach außen und schieben Product Ownership und Stewardship in die Domänen. Das Organigramm sollte ein Film sein, kein Foto. KKThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ündigen Sie diesen Weg offen an: „Wir zentralisieren jetzt, um die Plattform zu bauen, und wir werden die Ownership innerhalb von achtzehn Monaten zu Ihnen verlagern.“ Das verwandelt eine bedrohliche Reorg in ein Versprechen.

Wohin sollten Sie als CDO berichten? Das ist ein Strategie-Indikator, keine Eitelkeitsfrage. Berichten Sie an CEO oder COO, wenn Daten ein Hebel für Growth und Monetarisierung sind, Sie brauchen P&L-Nähe und Peer-Status mit den Leitern der Geschäftsbereiche. Berichten Sie an den CIO, wenn die Priorität Plattform- und Infrastrukturkonsolidierung ist. Berichten Sie an CFO oder CROCROConversion Rate Optimization (CRO) is the systematic practice of increasing the percentage of users who complete a desired action, using data, testing, and user research.Vollständige Definition ansehen →, wenn das Mandat defensiv ist: Risiko, Compliance, Kosten. Die falsche Linie ist fatal: ein CDO mit Monetarisierungsmandat, der an einen risikoversessenen CROCROConversion Rate Optimization (CRO) is the systematic practice of increasing the percentage of users who complete a desired action, using data, testing, and user research.Vollständige Definition ansehen → berichtet, wird strukturell vom Mandat abgeschnitten, offensive Wetten einzugehen.

Das Problem der gestrichelten Linie ist der Kern föderierten Designs, und gestrichelte Linien funktionieren für sich allein meist nicht. Eine gestrichelte Linie ohne Hebel ist eine Empfehlung. Geben Sie ihr Zähne über drei Mechanismen:

1. Geteilte Ziele. Der Bonus des eingebetteten Analytics-Leads wird teils von Ihnen, teils vom BU-Leiter festgelegt. Geteilter Incentive, geteilte Loyalität, bewusst so.

2. Kontrolle über den Karriereweg. Wenn Sie Beförderungen und Leveling für die Datenprofession im gesamten Unternehmen verantworten, haben Ihre gestrichelten Linien Schwerkraft, auch wenn die durchgezogene Linie im Business liegt.

3. Kontrolle über die Plattform. Wenn die Domänen von den befestigten Wegen abhängen, die Ihr Hub baut, ist Ihr Einfluss strukturell, nicht politisch.

Dieser dritte Punkt ist das stille Geheimnis mächtiger CDOs. Diejenigen mit echter Autorität haben selten alle unter sich. Sie besitzen die Plattform, die Standards und die Profession, sodass die ganze Organisation auf Schienen läuft, die sie gelegt haben, unabhängig von den KKThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ästchen im Organigramm.

Ein Wort zu Conway's Law, denn es regiert alles Obige: Ihre Systeme werden Ihre Kommunikationsstruktur spiegeln. Wenn Sie Ingestion und Analytics in zwei Teams aufteilen, die nicht miteinander sprechen, bauen Sie eine PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → mit einer Nahtstelle genau an dieser Grenze, und Datenqualität stirbt in der Lücke. Legen Sie Ihre Teamgrenzen dorthin, wo Sie die Systemschnittstellen *haben wollen*, dann arbeitet Conway's Law für Sie statt gegen Sie.

Wichtigste Erkenntnisse

• Sortieren Sie jede Funktion über eine Regel: zentralisieren, was von Skalierung, Konsistenz oder Knappheit profitiert; föderieren, was von Kontext und Geschwindigkeit profitiert. Hub-and-Spoke ist für die meisten reifen Organisationen die Antwort, aber nur, wenn Sie diese Sortierung bewusst vornehmen.
• Trennen Sie Governance und Delivery in unterschiedliche Berichtslinien und führen Sie sie am Punkt der Produktion über Data Contracts wieder zusammen, die Controls als Code kodieren. Lassen Sie niemals eine Führungskraft beides verantworten, Delivery gewinnt den täglichen Trade-off immer.
• Stewards gehören zur Domäne, nicht zur zentralen Governance. Policy ist zentral; Ausführung ist lokal. Ein Außenstehender, der eine Domäne kontrolliert, scheitert; ein Insider, der sie verbessert, gelingt.
• Bauen Sie Autorität über die Plattform, die Standards und die Profession auf, nicht über die Kästchen im Organigramm. Die mächtigsten CDOs besitzen die Schienen, auf denen alle fahren, und dadurch verhalten sich gestrichelte Linien wie durchgezogene.
• Behandeln Sie das Organigramm als Film, nicht als Foto. Sequenzieren Sie die Struktur zu Ihrer strategischen Phase, zentralisieren Sie, um Kontrolle herzustellen, dann föderieren Sie, um zu skalieren, und kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ündigen Sie den Weg an, damit eine Reorg als Versprechen gelesen wird, nicht als Bedrohung.