Zum Inhalt springen
governance.binom.net
Search the hub
Vom Data Catalog zum Governance Operating Model

Vom Data Catalog zum Governance Operating Model

Ein fokussierter Pilot verbindet Katalog, Rollen, Entscheidungsroutinen, technische Kontrollen und Evidenz zu einem belastbaren Operating Model.

Category
Data Governance
Author
Reading time
5 min
Published
Tags
data-catalog data-governance operating-model governance-pilot evidence
1 Views
Download PDF

Begriffe vor dem Lesen

  • Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien; nicht automatisch Governance.
  • Capability — Konkrete Fähigkeit wie Suche, Workflow, Nachweis, Lineage oder Richtlinie-Verknüpfung.
  • verantwortliche Person — Rolle, die Bedeutung, Nutzung, Risiko oder Freigabe im definierten Umfang verantwortet.
  • Workflow — Wiederholbarer Ablauf für Vorschlag, Prüfung, Entscheidung und Nachweis.
  • Nachweis — Prüfbarer Nachweis, dass eine Entscheidung oder Kontrolle stattgefunden hat.

Ausgangslage

Connectoren für sales_otc laufen; Beschreibungen veralten, Owner antworten nicht, Zertifizierung ohne Review-Datum. Das Werkzeug ist live — das Governance-Betriebsmodell (Cadence, Eskalation, Evidence) noch nicht.

Typische Symptome ohne Betriebsmodell:

  • Connectoren laufen, aber Beschreibungen veralten.
  • Owner-Felder sind gefüllt, aber Entscheidungen bleiben offen.
  • Richtlinien sind verlinkt, aber nicht in Kontrollen übersetzt.
  • Qualitätswerte sind sichtbar, aber niemand priorisiert Vorfälle.
  • Zertifizierungen haben kein Review-Datum.
  • Audit-Evidenz wird kurz vor einer Prüfung manuell zusammengesucht.

Leitentscheidung

Mit einem begrenzten Governance-Pilot ein Operating Model beweisen.

Der Pilot verbindet:

  1. einen geschäftlich relevanten Scope;
  2. klare Decision Rights;
  3. wenige wiederholbare Routinen;
  4. technische und organisatorische Kontrollpunkte;
  5. automatisch oder kontrolliert erzeugte Evidenz;
  6. messbare Ergebnisse.

Einen geeigneten Pilot wählen

Ein guter Pilot ist klein genug für acht bis zwölf Wochen und wichtig genug für echte Aufmerksamkeit.

Geeignete Kandidaten sind:

  • ein regulatorisch relevanter Report;
  • ein häufig genutzter Unternehmens-KPI;
  • ein sensibles Datenprodukt;
  • eine Domain mit wiederkehrenden Qualitätsproblemen;
  • eine bevorstehende Plattformmigration;
  • ein Datenprodukt mit vielen manuellen Zugriffsanfragen.

Ein schwacher Pilot besteht nur aus leicht dokumentierbaren Assets ohne reale Entscheidung.

Scope begrenzen

Für den Start genügen:

  • eine Domain;
  • ein bis drei Datenprodukte;
  • fünf bis zwanzig kritische Assets;
  • ein fachlicher Entscheidungsfall;
  • ein technischer Kontrollpunkt;
  • ein Nachweis-Paket.

Rollen und Decision Rights

Rolle Mandat im Pilot
Executive Sponsor Geschäftszweck bestätigen und Blockaden entfernen
Data Owner Zweck, Nutzung, Risiko und Priorität entscheiden
Data Steward Kontext pflegen, Reviews moderieren, Aufgaben verfolgen
Data Custodian Pipeline, Plattformobjekt, Qualität und Änderungen verantworten
Control Owner Kontrollausführung und Nachweis sicherstellen
Catalog Product Team Plattform, Integrationen und Informationsmodell betreiben
Consumer Discovery, Zugang und Nutzbarkeit validieren

Vier Kernroutinen

1. Onboarding

Ein neues Datenprodukt erhält:

  • klaren Zweck und Zielgruppe;
  • Owner und Steward;
  • kritische Assets;
  • Klassifikation;
  • Qualitätsanforderungen;
  • Zugangspfad;
  • Lifecycle-Status.

Das Onboarding endet mit einer überprüfbaren Freigabe.

2. Change Review

Eine relevante Änderung startet Impact Analysis und Review.

Geprüft werden:

  • Downstream-Nutzer;
  • Definitionen und Verträge;
  • Qualitätsregeln;
  • Richtlinien und Berechtigungen;
  • Migrations- und Kommunikationsbedarf.

3. Issue Management

Ein Qualitäts- oder Governance-Signal wird priorisiert, zugewiesen und geschlossen.

Kritikalität folgt dem Geschäftskontext, nicht nur dem technischen Fehler.

4. Periodische Attestierung

Owner bestätigen in festem Rhythmus:

  • Verantwortung;
  • zulässige Nutzung;
  • Klassifikation;
  • Qualitätsstatus;
  • fortbestehenden Bedarf;
  • offene Ausnahmen.

Nicht bestätigte Assets verlieren Zertifizierung oder werden eskaliert.

Evidence by Design

Evidenz darf kein Nebenprodukt kurz vor dem Audit sein.

Für jede Kontrolle werden vorab festgelegt:

Element Leitfrage
Kontrollziel Welches Risiko wird reduziert?
Auslöser Wann muss die Kontrolle laufen?
Ausführung Menschlich, technisch oder kombiniert?
Ergebnis Was gilt als bestanden?
Evidenz Welcher Nachweis entsteht?
Aufbewahrung Wie lange und wo bleibt er erhalten?
Ausnahme Wer darf abweichen und bis wann?

Gute Evidenz enthält mindestens:

  • eindeutige Kontroll- und Asset-Referenz;
  • ausführende Identität;
  • Zeitpunkt;
  • Eingaben oder geprüften Zustand;
  • Ergebnis;
  • Begründung bei Abweichung;
  • unveränderbare oder versionierte Ablage.

Pilotplan

Woche 1 bis 2: Baseline

Scope, Geschäftsergebnis, heutige Durchlaufzeiten, Rollen und zwei konkrete Risiken bestätigen.

Woche 3 bis 4: Modell

Mindestmetadaten, Workflows, Durchsetzung Points, Evidence und Erfolgskriterien festlegen.

Woche 5 bis 8: Umsetzung

Integrationen konfigurieren, reale Assets onboarden und einen Zugriffs- oder Freigabefall ausführen.

Woche 9 bis 10: Belastungstest

Owner-Abwesenheit, Schemaänderung, Qualitätsfehler, Ausnahme und Audit-Export testen.

Woche 11 bis 12: Entscheidung

Ergebnisse und Betriebsaufwand bewerten, Lücken dokumentieren und über Skalierung entscheiden.

Messung

Adoption bleibt wichtig, ist aber nicht das Endergebnis.

Leading Indicators

  • Anteil kritischer Assets mit bestätigtem verantwortliche Person;
  • Anteil vollständiger Mindestmetadaten;
  • fristgerecht bearbeitete Reviews;
  • aktuelle Qualitäts- und Kontrollsignale;
  • aktive Nutzer im Pilot.

Outcome Indicators

  • Zeit bis zur richtigen Datenauswahl;
  • Zeit bis zur Governance-Entscheidung;
  • Anteil fristgerecht behobener kritischer Fälle;
  • Anteil erfolgreicher Kontrollausführungen;
  • Vollständigkeit des Nachweis-Pakets;
  • weniger Fehlverwendungen oder doppelte Produkte.

Skalierung

Nicht einfach weitere Assets harvesten.

Skaliert in dieser Reihenfolge:

  1. bewährten Use Case standardisieren;
  2. Rollenpaket und Mindestmetadaten wiederverwendbar machen;
  3. Workflows als Templates bereitstellen;
  4. Integrationen und Evidenz automatisieren;
  5. nächste Domain mit lokalem Owner onboarden;
  6. zentrale Standards anhand realer Abweichungen verbessern.

Föderation bedeutet gemeinsame Mindeststandards mit lokaler Entscheidung.

Sie bedeutet weder vollständige Zentralisierung noch freie Beliebigkeit.

Abschluss-Checkliste

  • Ist der Umfang geschäftlich relevant und begrenzt?
  • Sind Mandate und Eskalationen bestätigt?
  • Gibt es mindestens einen echten Ende-zu-Ende-Fall?
  • Sind Durchsetzung Points technisch benannt?
  • Entsteht Nachweis im normalen Ablauf?
  • Wird Outcome statt nur Metadatenmenge gemessen?
  • Hat jede Zertifizierung ein Review-Datum?
  • Ist der Betriebsaufwand transparent?
  • Gibt es eine explizite Skalierungsentscheidung?

Artefakt

Das Ergebnis des Piloten ist ein wiederverwendbares Governance-Paket:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Scope und Ziele
RACI und Decision Rights
Mindestmetadaten
Workflow-Templates
Kontroll- und Evidence-Matrix
Integrationskarte
Messmodell
Runbook und Eskalation

Damit wird der Katalog vom installierten Produkt zur betriebenen Governance-Fähigkeit.

Weiterlesen

Catalog Deep Dive

Part 6 of 6

View series
Part 1: Why a Data Catalog Can Create the Illusion of Governance Part 2: The Map of Catalog Types Part 3: What Governance Really Needs from a Data Catalog Part 4: When Each Data Catalog Is Sufficient Part 5: Select a Data Catalog by Capability Part 6: From Data Catalog to Governance Operating Model

Knowledge check

Tour