Vom Data Catalog zum Governance Operating Model

Begriffe vor dem Lesen

• Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien; nicht automatisch Governance.
• Fähigkeit — Wiederholbar nutzbare Funktion, etwa Suche, Freigabeprozess, Datenherkunft oder Nachweisführung.
• Verantwortliche Rolle — Person oder Rolle mit dem Mandat, über Bedeutung, Nutzung, Risiko oder Freigabe in einem klaren Bereich zu entscheiden.
• Arbeitsablauf — Festgelegter Weg von Antrag und Prüfung bis zu Entscheidung, Umsetzung und Nachweis.
• Nachweis — Prüfbarer Nachweis, dass eine Entscheidung oder Kontrolle stattgefunden hat.

Ausgangslage

Die technischen Verbindungen für den unternehmensweiten Vertriebsbericht laufen. Trotzdem veralten Beschreibungen, verantwortliche Rollen reagieren nicht und Freigaben besitzen kein Datum für die nächste Prüfung. Das Werkzeug ist in Betrieb, das Governance-Betriebsmodell mit festen Prüfrhythmen, Eskalationswegen und Nachweisen jedoch 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-Nachweis 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 Umfang;
2. klare Entscheidungsrechte;
3. wenige wiederholbare Routinen;
4. technische und organisatorische Kontrollpunkte;
5. automatisch oder kontrolliert erzeugte Nachweise;
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.

Umfang 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 Entscheidungsrechte

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. Änderungen prüfen

Eine relevante Änderung startet eine Prüfung der Auswirkungen und der notwendigen Freigaben.

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.

Nachweise von Anfang an einplanen

Nachweis darf kein Nebenprodukt kurz vor dem Audit sein.

Für jede Kontrolle werden vorab festgelegt:

Gute Nachweis 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

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

Woche 3 bis 4: Modell

Mindestmetadaten, Workflows, Durchsetzungspunkte, Nachweise 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.

Frühe Fortschrittskennzahlen

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

Ergebniskennzahlen

• 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 Datenobjekte automatisch erfassen.

Skaliert in dieser Reihenfolge:

1. bewährten Anwendungsfall standardisieren;
2. Rollenpaket und Mindestmetadaten wiederverwendbar machen;
3. Workflows als Templates bereitstellen;
4. Integrationen und Nachweis 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 Durchsetzungspunkte 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 mit erfundenen Daten. Für die Anwendung im Unternehmen brauchst du passende Daten aus den eigenen Systemen und Prozessen.

Umfang und Ziele
RACI und Entscheidungsrechte
Mindestmetadaten
Workflow-Templates
Kontroll- und Nachweismatrix
Integrationskarte
Messmodell
Runbook und Eskalation

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

Weiterlesen

• Teil 1: Warum ein Datenkatalog Governance vortäuschen kann
• Teil 5: Datenkatalog nach Fähigkeiten auswählen
• Metadata Deep Dive
• Metadaten als Produkt betreiben

Den Arbeitsfall in diesem Kapitel prüfen

Übernimm einen tatsächlich gepflegten Datenpfad in den Betrieb. Vereinbare, wer bei einer Definitionsänderung den Eintrag aktualisiert, wer Verbraucher informiert und wer veraltete Zusagen zurücknimmt. Prüfe dies an einer realistisch nachgestellten Änderung.

Gegenprobe und Abnahme: Die Übergabe endet mit benannten Aufgaben und Kapazität. Ein importierter Katalog ohne Pflegeweg bleibt ein Pilotbefund.

Halte erwartetes Ergebnis, tatsächlich beobachteten Stand, Abweichung und zuständige Entscheidung in der Arbeitsakte fest. Ein noch nicht ausgeführter Test bleibt offen.

Arbeitsakte für diese Serie herunterladen · Beispieldaten und Sollwerte

Vom Beispiel in den eigenen Betrieb

Die gesuchte Aussage ist mit Definition, gültigem Stand, Fachverantwortung und bekannten Grenzen auffindbar. Der Zugriff wird im zuständigen System geprüft und umgesetzt.

Miss Such- und Rückfragezeit für denselben Anwendungsfall und die Arbeit zur Pflege verlässlicher Einträge. Importmenge und gefüllte Pflichtfelder sind keine eigenständigen Wirtschaftlichkeitsnachweise.

Benanntes Team, Pflegekapazität und Reviewtermin gehören zur Übernahme. Vereinbare, welche bisherige Doppelpflege oder Rückfrage der neue Ablauf ersetzt. Erforderliche Schutzmaßnahmen bleiben bestehen, auch wenn die wirtschaftliche Wirkung noch nicht belegt ist.