Governance-Rollen nach Unternehmensgröße — sechs Hüte ohne Rollen-Wildwuchs

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• Owner — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• Custodian — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Evidence — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

zt.

Sechs Rollen bedeuten nicht sechs neue Stellen. Sie beschreiben sechs Verantwortungsarten:

• Data Owner entscheidet fachliche Bedeutung, Zweck, zulässige Nutzung und Risiko.
• Data Steward hält Definitionen, Qualitätsregeln, Katalogkontext und Eskalationen arbeitsfähig.
• Data Product Owner priorisiert Nutzen, Roadmap, Serviceversprechen und Lebenszyklus eines Datenprodukts.
• Data Architect schützt Modellgrenzen, Schnittstellen, Zählebene und kontrollierte Änderungen.
• Data Custodian betreibt Plattform, Speicher, Rechte, Monitoring, Backup und Recovery.
• Data Consumer nutzt Daten verantwortungsvoll und meldet Lücken über einen sichtbaren Anfrageweg.

In kleinen Organisationen können drei Personen alle sechs Hüte tragen. In Konzernen können viele Menschen Teilaufgaben übernehmen. Entscheidend ist nicht die Anzahl der Titel. Entscheidend ist, ob bei einer konkreten Entscheidung klar ist, welcher Hut gerade spricht.

Rollen dürfen zusammenfallen. Entscheidungsrechte dürfen nicht verschwimmen.

Was diese Serie klärt

• wie Rollen nach Unternehmensgröße sinnvoll gebündelt oder getrennt werden
• warum IT nicht automatisch fachliche Datenverantwortung besitzt
• wie funktionsübergreifende Grenzen, gemeinsame KPIs und Eskalationen funktionieren
• welches Minimum kleine Organisationen wirklich brauchen

Begriffe vor dem Lesen

• Hut — Verantwortungsart, die eine Person tragen kann, ohne dass daraus automatisch eine eigene Stelle wird.
• Data Owner — fachlich verantwortliche Rolle für Bedeutung, Zweck, Zugriff, Risiko und Freigabe.
• Data Steward — Rolle, die Definitionen, Qualität, Katalogpflege, Issues und Eskalation vorbereitet und nachhält.
• Data Product Owner — Rolle für Nutzen, Roadmap, Backlog, Serviceversprechen und Lebenszyklus eines Datenprodukts.
• Data Architect — Rolle für Modellgrenzen, Schnittstellen, Identitäten, Zählebene und Änderungsauswirkungen.
• Data Custodian — technische Rolle für Plattform, Zugriff, Betrieb, Backup, Recovery und technische Nachweise.
• Data Consumer — Person oder Team, das Daten nutzt, Anforderungen formuliert und Fehler meldet.
• Nachweis — prüfbarer Beleg, dass eine Entscheidung, Umsetzung, Kontrolle oder Ausnahme stattgefunden hat.

Einfaches Schaubild

Produkte und Entscheidungen

Governance beginnt nicht beim Organigramm, sondern bei Produkten und Entscheidungen. Ein typisches Portfolio enthält Kundendaten, Finance-Produkte, Workforce-Daten, Supply-Chain-Produkte, Referenzdaten, Kennzahlenprodukte, semantische Modelle und Plattformservices.

Für jedes wichtige Produkt sollten wiederkehrende Entscheidungen sichtbar sein:

• Welche Bedeutung ist verbindlich?
• Welche Quelle ist maßgeblich?
• Welche Nutzung ist erlaubt?
• Welche Qualitätsabweichung ist akzeptabel?
• Wer darf Zugriff erhalten?
• Wann wird ein Produkt freigegeben, eingeschränkt oder abgelöst?

Wo Governance wirklich hängt

Governance scheitert selten daran, dass ein Rollentitel fehlt. Sie scheitert an Übergaben:

• Der Steward dokumentiert eine Unklarheit, aber niemand entscheidet.
• Eine fachlich verantwortliche Rolle genehmigt eine Regel, aber niemand setzt sie technisch um.
• Ein Product Owner priorisiert Auslieferung, ohne fachliche Risiken sichtbar zu machen.
• Ein Architect beschreibt eine Schnittstelle, aber Nutzer erfahren Änderungen zu spät.
• Ein Custodian betreibt eine Tabelle und wird deshalb fälschlich als fachlicher Owner eingetragen.
• Consumer bauen lokale Wahrheiten, weil der Anfrageweg nicht funktioniert.

Der praktische Entscheidungsfluss ist einfach:

Nicht jeder Fall braucht alle sechs Rollen. Eine Definition ohne technische Änderung braucht vielleicht Steward und Owner. Ein Backup-Test braucht vor allem Custodian und Service-Verantwortung. Ein neues domänenübergreifendes Produkt braucht meist alle Perspektiven.

Rollen-Mapping

Data Steward

Der Steward hält die tägliche Governance arbeitsfähig. Er pflegt nicht blind alle Metadaten, sondern sorgt dafür, dass kritische Begriffe, Qualitätsregeln, offene Fragen und Reviews entscheidungsfähig bleiben. Gute Steward-Ergebnisse sind entschiedene Begriffe, nachvollziehbare Qualitätsregeln, priorisierte Issues und eskalierte statt versteckte Blockaden.

Data Owner

Der Data Owner trägt fachliche Verantwortung. Er entscheidet Zweck, Nutzung, verbindliche Definitionen, Zugriffspolitik, Risikoakzeptanz, Zertifizierung und fachliche Ausnahmen. Er muss nicht jedes Ticket bearbeiten, aber erreichbar sein, wenn eine Entscheidung fällig ist.

Data Product Owner

Der Data Product Owner führt das Datenprodukt als Service. Er priorisiert Nutzerwert, Umfang, Backlog, Roadmap, Service-Level, Go-live und Ablösung. Er darf Zweck- oder Zugriffsentscheidungen nicht stillschweigend übernehmen.

Data Architect

Der Architect schützt stabile Modell- und Schnittstellengrenzen. Dazu gehören Zählebene, Entitäten, Verträge, Versionierung, Impact Analysis und Breaking Changes. Er soll Standards und Review-Pfade schaffen, nicht jedes Ticket persönlich blockieren.

Data Custodian

Der Custodian hält die technische Realität verlässlich: Betrieb, Speicher, Zugriff, Maskierung, Monitoring, Backup, Recovery und technische Incident Response. Technische Obhut ist keine fachliche Verantwortung.

Data Consumer

Consumer nutzen freigegebene Produkte und melden Lücken sichtbar. Sie verantworten korrekte Nutzung, melden Qualitätsprobleme, fehlende Dimensionen, unklare Aktualität und Schattenlogik über Intake statt über private Workarounds.

SMB: Hüte explizit bündeln

Kleine Organisationen brauchen minimale Entscheidungsfähigkeit, kein Enterprise-Organigramm. Ein praktikables Modell:

• Fachbereichsleitung trägt den Data-Owner-Hut.
• Analyst oder Prozessexpertin übernimmt Stewardship und Consumer-Perspektive.
• Analytics Lead übernimmt Product-Owner- und Architect-Hut.
• Engineer, IT-Admin oder Dienstleister übernimmt Custodianship.

Mehrfachhüte sind erlaubt. Wichtig ist, dass Konflikte sichtbar bleiben: Wer priorisiert Nutzen? Wer prüft Modellgrenzen? Wer entscheidet Risiko? Wer betreibt technisch?

Mid-Market: Domänen und Services trennen

Im Mid-Market wachsen Systeme, Nutzer und Übergaben. Informelle Erreichbarkeit reicht nicht mehr. Sinnvoll sind Owner je kritischer Domäne, geschützte Stewardship-Kapazität, Product Owner für wiederverwendete Datenprodukte, ein zentraler oder föderierter Architekturservice, Plattformteams als Custodians und benannte Consumer-Vertretung.

Rollen werden nach Nachfrage, Risiko und Änderungsrate skaliert, nicht nach Tabellenzahl.

Enterprise: föderieren, ohne Verantwortung zu verwässern

Enterprise-Governance braucht lokale Entscheidungen dort, wo Kontext liegt, und gemeinsame Leitplanken dort, wo Wiederverwendung, Risiko oder Auditbarkeit betroffen sind. Föderation bedeutet nicht, dass jede Einheit eigene Definitionen ohne Schnittstellenvertrag pflegt.

Typisch sind Domain Owner, Lead Stewards, Steward-Netzwerke, Product Owner für strategische Datenprodukte, Enterprise- und Domain-Architects, Plattform-Custodians und benannte Consumer Councils. Zusätzlich braucht es Vertretung, Delegationsgrenzen, Onboarding, Lernpfade, Kapazitätsplanung und Eskalationsfristen.

Mini-Scorecard

Bewerte jede Aussage mit 0, 1 oder 2 Punkten.

• 0 = nicht vorhanden.
• 1 = teilweise oder informell.
• 2 = verlässlich und nachweisbar.

Entscheidungsfähigkeit

• Kritische Produkte und wiederkehrende Entscheidungen sind benannt.
• Pro fachlicher Entscheidung existiert genau eine fachlich verantwortliche Rolle.
• Frist und Eskalation sind sichtbar.

Rollenklarheit

• Alle sechs Hüte sind erklärt.
• Mehrfachhüte sind transparent dokumentiert.
• Custodian und fachliche Verantwortung werden nicht verwechselt.

Ausführung

• Stewards besitzen geschützte Kapazität.
• Product Backlogs enthalten Governance-Arbeit.
• Architects prüfen risikobasiert.
• Custodians liefern Betriebsnachweise.
• Consumer-Lücken erreichen den Anfrageweg.

Größen-Fit

• Kleine Einheiten vermeiden unnötige Stellen.
• Wachsende Domänen erhalten Kapazität nach Nachfrage.
• Enterprise-Föderation hat verbindliche Eskalationswege.

Erster Umsetzungsschnitt

Nimm einen echten Fall, zum Beispiel eine strittige Kennzahl oder ein kritisches Datenprodukt.

1. Zehn wiederkehrende Entscheidungen sammeln.
2. Produkte und Domänen zuordnen.
3. Die sechs Hüte auf vorhandene Personen mappen.
4. Mehrfachhüte und Konflikte dokumentieren.
5. Für drei reale Fälle prüfen, ob Entscheidung, Umsetzung und Nachweis funktionieren.

Das Ergebnis ist kein perfektes Organigramm. Es ist ein getesteter Entscheidungsmechanismus.

Weiterlesen

• Rollen-Hub: die sechs Governance-Rollen
• RACI für Data Governance
• Stewardship staffen und Kapazität schützen
• IT-Familie — welche Kindkarte