+150 XP

Aufbau eines Data Governance Council für ein Versorgungsunternehmen

# Aufbau eines Data Governance Council für ein Versorgungsunternehmen

Um 2 Uhr nachts fällt ein Transformator aus. Das Outage Management System zieht das Anlagenalter aus einer Datenbank, die Wartungshistorie aus einer zweiten und die Kundenanzahl aus einer dritten. Die drei Zahlen passen nicht zusammen. Das Metering sagt, die Seriennummer des Transformators sei 2019 stillgelegt worden. Der Netzbetrieb sagt, er sei weiterhin unter Spannung und trage Last. Für den Widerspruch ist niemand zuständig. Das ist kein konstruiertes Beispiel: abweichende Anlagenstammdaten gehören zu den häufigsten Ursachen für verzögerte Audits zur Störungsbehebung bei US-amerikanischen investor-owned utilities, so die Postmortems, die regelmäßig in Zuverlässigkeitsberichten der NERC (North American Electric Reliability Corporation) zitiert werden. Die Lösung ist keine bessere Datenbank. Sie ist ein Governance-Gremium mit der Autorität, eine Entscheidung zu erzwingen.

Warum gerade Versorgungsunternehmen das brauchen

Versorger sitzen auf Daten, die konstruktionsbedingt drei konkurrierende Eigentümer haben:

  • Metering interessiert sich für den Zählpunkt: Verbrauch, Intervalle, Manipulationsflags.
  • Commercial (Abrechnung, Kundenbetrieb) interessiert sich für das Kundenkonto, das an diesem Zählpunkt hängt.
  • Netzbetrieb interessiert sich für die physische Anlage: den Transformator, den Abzweig oder die Umspannstation hinter dem Zähler.

Diese drei Sichten beschreiben dasselbe Objekt der realen Welt, leben aber in verschiedenen Systemen: einem Meter Data Management System (MDMS), einem Customer Information System (CIS) und einem Geografischen Informationssystem (GIS) oder Asset Management System (oft auf Basis von Tools wie IBM Maximo oder SAP PM). Wenn eine Feldmannschaft einen Transformator tauscht, muss jemand alle drei aktualisieren, in der richtigen Reihenfolge, sonst laufen die nachgelagerten Systeme (Abrechnung, Störungskarten, Lastprognose) still auseinander.

Kein einzelnes Team hat die Autorität, die beiden anderen zu zwingen, ihre Seite zu korrigieren. Das ist die Governance-Lücke.

Was ein Data Governance Council tatsächlich ist

Ein Data Governance Council (manchmal auch Data Stewardship Board genannt) ist ein ständiges, cross-funktionales Gremium mit formaler Autorität, um:

1. Zu definieren, welches System das System of Record für jede Datendomäne ist (die eine autoritative Quelle, wenn Kopien voneinander abweichen).

2. Änderungen an gemeinsam genutzten Datenmodellen zu genehmigen oder abzulehnen (zum Beispiel ein neues Feld „Anlagenstatus“, das sowohl GIS als auch CIS respektieren müssen).

3. Streitfälle zu entscheiden, wenn zwei Teams beide Ownership oder beide ein Vetorecht beanspruchen.

4. Datenqualitätsschwellen festzulegen und Remediation-Pläne abzuzeichnen.

Das unterscheidet sich von IT-Governance (die Systeme und Infrastruktur verwaltet) und von einer Compliance-Funktion (die regulatorische Pflichten verwaltet). Das Council besitzt die *fachliche Bedeutung und Autorität* über Daten, nicht die Leitungen, durch die sie fließen.

Charter: die vier Dinge, die sie festlegen muss

Eine Charter, die eines dieser vier Elemente auslässt, scheitert innerhalb eines Jahres.

1. Scope. Benennen Sie die Datendomänen ausdrücklich: Anlagenstammdaten, Zählpunktdaten, Kundendaten, Störungsdaten. Ein vager Scope („alle Daten des Versorgers“) erzeugt ein Council, das nie zusammenkommt, weil niemand weiß, ob sein Thema dazugehört.

2. Entscheidungsrechte. Nutzen Sie eine einfache RACI-Aufteilung (Responsible, Accountable, Consulted, Informed) pro Domäne. Beispiel:

| Domäne | System of Record | Accountable Owner | Consulted |

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

| Physische Anlagenattribute | GIS/Asset Management | Netzbetrieb | Metering, Engineering |

| Zählpunktstatus | MDMS | Metering | Commercial |

| Zuordnung Kunde zu Zähler | CIS | Commercial | Metering, Abrechnung |

3. Eskalationspfad. Legen Sie fest, was passiert, wenn die beiden Accountable Owner nicht übereinstimmen, etwa wenn der Netzbetrieb einen Transformator als stillgelegt führt, das Metering aber weiter aktive Ablesungen zeigt. Der Pfad läuft typischerweise: Data-Steward-Ebene (wöchentliche Arbeitsgruppe) zur Council-Ebene (monatlich) zum Executive Sponsor (CIO, CDO oder COO), falls nach einer festgelegten Anzahl von Tagen ungelöst, in ausgereiften Programmen üblicherweise 10 bis 15 Werktage.

4. Cadence und Quorum. Monatliche Council-Meetings, wöchentliche Steward-Triage, definiertes Quorum (zum Beispiel mindestens ein Accountable Owner aus jeder Domäne plus ein Compliance- oder Datenschutzvertreter).

Rollen: wer am Tisch sitzt

  • Chief Data Officer (CDO) oder Äquivalent, führt den Vorsitz im Council. Eine Gartner-Umfrage von 2023 (ein breit zitierter Branchen-Benchmark, Zahlen näherungsweise) ergab, dass über 80 Prozent der großen Unternehmen einen CDO benannt hatten, wobei Versorger anderen Branchen hinterherhängen, wenn es darum geht, dieser Rolle echte Autorität zu geben.
  • Data Stewards, einer pro Domäne (Metering, Commercial, Netzbetrieb, Anlagen-Engineering). Das sind Leute auf Arbeitsebene, die Datensätze im Tagesgeschäft korrigieren, keine Führungskräfte.
  • Data Owner, Abteilungsleiter, die für die Korrektheit ihrer Domäne verantwortlich sind.
  • Datenschutz-/Compliance-Vertreter, stellt sicher, dass Entscheidungen regulatorische Vorgaben respektieren (siehe nächster Abschnitt).
  • IT-/Architektur-Vertreter, in den meisten Modellen ohne Stimmrecht, berät zur technischen Machbarkeit.
  • Executive Sponsor, entscheidet Patt-Situationen und übernimmt Eskalationen, die das Council nicht lösen kann.

Regulatorische Leitplanken, die das Council respektieren muss

Governance-Entscheidungen in den USA und der EU entstehen nicht im Vakuum; sie sitzen innerhalb verbindlicher Regeln.

  • NERC CIP (Critical Infrastructure Protection) Standards, verpflichtend für Betreiber des US-Bulk-Power-Systems, verlangen dokumentierte Zugriffskontrollen und Change Management für Daten zu netzkritischen Anlagen. Eine Council-Entscheidung, zwei Anlagendatensätze zu „mergen“, muss den von CIP-010 geforderten Audit Trail erhalten.
  • Datenschutzgesetze auf Staatenebene, zum Beispiel der California Consumer Privacy Act (CCPA), regeln Kundenverbrauchsdaten (etwa Intervallablesungen, die Anwesenheitsmuster offenlegen).
  • EU-Datenschutz-Grundverordnung (DSGVO), für europäische Versorger, behandelt granulare Smart-Meter-Daten als personenbezogene Daten, sobald sie einem Haushalt zuordenbar sind, mit dokumentierter Rechtsgrundlage und Datenminimierung.
  • EU Network Code / ENTSO-E-Regeln zum Datenaustausch regeln, wie Übertragungsnetzbetreiber Anlagen- und Netzdaten grenzüberschreitend teilen.

Der Eskalationspfad des Council sollte datenschutzrelevante Streitfälle (enthält dieser Datensatz personenbezogene Daten, darf er teamübergreifend geteilt werden) immer über den Compliance-Vertreter führen, bevor eine fachliche Entscheidung final wird. Eine verständliche Einführung in die für Versorger relevantesten DSGVO-Bestimmungen finden Sie in den Leitlinien des Europäischen Datenschutzausschusses.

Ein durchgerechnetes Beispiel: den Transformator-Streit lösen

Zurück zur Störung um 2 Uhr nachts. So löst der Council-Prozess sie in der Praxis:

1. Der Feldtechniker meldet die Abweichung über ein Datenqualitäts-Ticket.

2. Die Data Stewards aus Metering und Netzbetrieb triagieren wöchentlich: der Netzbetrieb bestätigt per GIS, dass der Transformator 2019 physisch getauscht wurde; das Metering bestätigt, dass sein Datensatz weiter auf die alte Seriennummer zeigt.

3. Ursache: der Stilllegungs-Workflow hat nie eine automatische Aktualisierung im MDMS ausgelöst. Das ist eine Prozesslücke, kein Erfassungsfehler.

4. Council-Entscheidung (gemäß RACI-Tabelle): GIS ist System of Record für den Anlagenstatus, also muss das MDMS entsprechend korrigiert werden. Zusätzlich beauftragt das Council eine Integrationskorrektur: Stilllegungsereignisse im GIS müssen künftig automatisch ein Event an das MDMS publizieren.

5. Der Executive Sponsor genehmigt das Budget für die Integrationskorrektur im nächsten Sprint-Zyklus.

Eine einfache Prüfung, die jeder Analyst vor der Eskalation eines solchen Streitfalls laufen lassen kann, ist eine Abgleichs-Query:

sql
SELECT g.asset_id, g.status AS grid_status, m.asset_id, m.status AS meter_status
FROM gis_assets g
FULL OUTER JOIN mdms_assets m ON g.serial_number = m.serial_number
WHERE g.status != m.status OR g.status IS NULL OR m.status IS NULL;

Solch ein Abgleich, planmäßig ausgeführt (täglich oder wöchentlich), ist das praktische Audit, das die Agenda des Council füttert, statt sie zu ersetzen.

Wissenscheck

1. Warum bleiben im Transformator-Störungsszenario abweichende Anlagendaten über Systeme hinweg ungelöst, selbst nachdem die Diskrepanz entdeckt wurde?

2. Warum haben Versorgungsunternehmen einen besonders akuten Bedarf an formaler Data Governance im Vergleich zu Organisationen mit einfacheren Datenstrukturen?

3. Eine Feldmannschaft tauscht einen Transformator. Zwei Wochen später zeigt das GIS die neue Anlage, das Outage Management System verweist aber noch auf die alte Seriennummer. Was veranschaulicht dieses Szenario am besten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Aussagen über die drei konkurrierenden Dateneigentümer bei einem Versorger, wie in der Lektion beschrieben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Aussagen darüber, was ein Data Governance Council leisten soll.

Wählen Sie alle richtigen Antworten aus.

Praktische Prüfungen und Audits, die das Council vorschreiben sollte

  • Systemübergreifende Abgleichs-Audits, quartalsweise, mit Vergleich von Anlagenzahlen und -status über GIS, MDMS und CIS.
  • Review der Zugriffslogs, an NERC-CIP-Anforderungen gebunden, mit Nachweis, dass nur berechtigte Rollen kritische Anlagendatensätze geändert haben.
  • Dokumentation der Data Lineage, die nachvollzieht, wo ein Feld wie „Zählerstatus“ entsteht und durch welche Systeme es fließt, damit ein Streitfall in Minuten statt Tagen bis zur Quelle zurückverfolgt werden kann.
  • Datenschutz-Folgenabschätzungen (DSFA), unter der DSGVO für Verarbeitungen mit hohem Risiko erforderlich, automatisch ausgelöst, sobald das Council eine neue Nutzung granularer Zählerdaten genehmigt.

What is Data Governance?

Watch on YouTube

Key Takeaways

  • Die Kernaufgabe eines Governance Council ist die Zuweisung von Entscheidungsrechten, nicht der Bau von Dashboards: benennen Sie für jede gemeinsam genutzte Datendomäne (Anlage, Zähler, Kunde) ein System of Record.
  • Die Charter muss Scope, Entscheidungsrechte (RACI), einen Eskalationspfad mit Fristen und die Meeting-Cadence festlegen, sonst übersteht sie den ersten echten Streitfall nicht.
  • Führen Sie jeden Streitfall, der Kundenverbrauchsdaten berührt, zuerst über einen Datenschutz-/Compliance-Vertreter; DSGVO und CCPA behandeln granulare Zählerdaten beide als sensibel.
  • NERC-CIP-Standards verlangen einen auditierbaren Nachweis für Änderungen an netzkritischen Anlagendatensätzen; Council-Entscheidungen müssen diesen Nachweis erhalten, nicht umgehen.
  • Automatisieren Sie Abgleichsprüfungen (systemübergreifende Queries, Reviews der Zugriffslogs), damit das Council seine Zeit mit echten Ownership-Konflikten verbringt und nicht mit Tippfehlern in der Datenerfassung.