+150 XP

Master Data und Reference Data bei Versorgern: Assets, Zähler und Kunden

# Master Data und Reference Data bei Versorgern: Assets, Zähler und Kunden

Im Feld wird ein Transformator ausgetauscht. Die Kolonne erfasst ihn in der Mobile-Work-Order-App unter der Asset-ID TX-4471. Im Büro zeigt das Geographic Information System (GIS, die Kartendatenbank, die festhält, wo jeder Mast, jede Leitung und jeder Transformator physisch steht) weiterhin das alte Gerät unter der ID TX-4471-A. Das Abrechnungssystem, das die Zähler-zu-Transformator-Beziehungen zur Berechnung der Netzverluste zieht, kann die beiden nicht zusammenführen. Sechs Monate später weist ein Zuverlässigkeitsbericht „Phantom“-Ausfälle an einem Transformator aus, der nicht mehr existiert, während der echte, für das Outage Management System unsichtbar, weiter auslöst. Niemand merkt es, bis eine Kundenbeschwerde die Sache zurückverfolgt.

So sieht es aus, wenn Master Data bricht. Diese Lektion behandelt, was diese Daten tatsächlich sind, wie Versorger sie sauber halten, und welche Metriken zeigen, ob das funktioniert.

Was Master Data bei Versorgern bedeutet

Master Data sind die zentralen, relativ stabilen Daten, die die Entitäten beschreiben, auf denen ein Geschäft läuft: keine Transaktionen, sondern die Dinge, an denen Transaktionen passieren.

Bei Versorgern sind drei Master-Data-Domänen am wichtigsten:

  • Asset Data: Masten, Transformatoren, Umspannwerke, Rohrleitungen, Zähler, Erzeugungseinheiten. Liegt vor allem in GIS und CMMS (Computerized Maintenance Management System, das Inspektionen und Reparaturen plant und protokolliert).
  • Meter Data: Gerätekennungen, Einbaudaten, Zähler-zu-Liegenschaft-Verknüpfungen und zunehmend Intervalldaten aus AMI (Advanced Metering Infrastructure, das Smart-Meter-Netz, das den Verbrauch alle 15 bis 60 Minuten meldet).
  • Customer Data: Kontoinhaber, Serviceadressen, Tarifklassen, Kontakt- und Abrechnungsdaten, typischerweise im CIS (Customer Information System) gehalten.

Reference Data ist etwas anderes: die standardisierten Code-Sets, die diese Systeme gemeinsam nutzen, etwa Spannungsklassen-Codes, Ausfallursachen-Codes oder Tarifkennungen. Reference Data ist das, was dafür sorgt, dass Asset Data aus dem GIS dasselbe bedeutet wie Asset Data im CMMS.

Das Problem im Einstieg ist ein Master-Data-Key-Mismatch: derselbe reale Transformator existiert unter zwei verschiedenen Kennungen in zwei Systemen, die nie korrekt verknüpft wurden.

Wo diese Daten liegen und warum sie fragmentieren

Versorger betreiben typischerweise 5 bis 15 Systeme, die alle einen Teil derselben physischen oder kundenbezogenen Realität für sich beanspruchen:

| System | Besitzt | Typische Anbieterbeispiele |

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

| GIS | Asset-Standort, Netztopologie | Esri, Schneider Electric |

| CMMS/EAM | Wartungshistorie, Asset-Zustand | IBM Maximo, SAP EAM |

| AMI Head-End | Zählerstände, Gerätestatus | Itron, Landis+Gyr |

| CIS/Billing | Kundenkonten, Tarifmodelle | Oracle Utilities, SAP IS-U |

| OMS | Ausfallereignisse, Wiederherstellung | Verschiedene, oft mit GIS integriert |

Jedes System wurde separat beschafft, oft Jahrzehnte auseinander, von unterschiedlichen Abteilungen. GIS-Teams modellieren das Netz so, wie Ingenieure es sehen. CIS-Teams modellieren es so, wie die Abrechnung es braucht. Die Übersetzungsschicht hat standardmäßig niemand im Besitz, und genau deshalb existiert Master Data Management (MDM) als Disziplin: um pro Entität einen autoritativen „Golden Record“ zu benennen und zu steuern, wie jedes andere System darauf referenziert.

Die Governance-Metriken, die das Problem aufdecken

Was man nicht messt, kann man nicht managen. Vier Metriken dominieren MDM-Programme bei Versorgern:

1. Match Rate: der Prozentsatz der Datensätze über zwei Systeme hinweg, die per Matching-Regeln automatisch derselben realen Entität zugeordnet werden können (exakte ID oder „fuzzy“ Matching über Name plus Adresse plus Geolokation).

*Rechenbeispiel*: Ein Versorger hat 2,1 Millionen Zähler im AMI und 2,05 Millionen Liegenschaftsdatensätze im CIS. Eine automatisierte Matching-Routine verknüpft 1,968 Millionen Paare mit hoher Konfidenz.

Match Rate = 1.968.000 / 2.050.000 = 96,0 %

Die restlichen 4 % (rund 82.000 Datensätze) brauchen manuelle Prüfung oder Verifikation im Feld. Das ist kein Rundungsfehler; jeder nicht gematchte Datensatz ist ein potenzieller Abrechnungsstreit oder ein verpasster Anschluss.

2. Duplicate Rate: der Anteil der Datensätze in einem einzelnen System, die dieselbe Entität mehr als einmal repräsentieren. Häufige Ursache: ein Kunde zieht innerhalb des Versorgungsgebiets um und erhält ein neues Konto anstelle eines aktualisierten, oder eine Feldkolonne legt nach einem Asset-Tausch in der Mitte der Lebensdauer einen neuen Asset-Datensatz an, statt den bestehenden zu aktualisieren.

Industrie-MDM-Benchmarks über große Unternehmen hinweg nennen für Kundendatenbanken üblicherweise Duplicate Rates von 5 % bis 15 % vor der Bereinigung, die nach Einführung eines ausgereiften MDM-Programms auf unter 2 % sinken. Das sind allgemeine Datenqualitätsschätzungen für Unternehmen, keine publizierten versorgerspezifischen Zahlen, also als Richtungsgrößen behandeln.

3. Golden Record Coverage: der Prozentsatz der Entitäten (Assets, Zähler, Kunden), für die ein einzelner, benannter, vertrauenswürdiger Master-Datensatz existiert, auf den alle nachgelagerten Systeme referenzieren, im Gegensatz zu widersprüchlichen Versionen über Systeme hinweg.

4. Datenqualitätsdimensionen, pro Attribut bewertet, typischerweise:

  • *Completeness*: ist das Feld gefüllt (z. B. hat jeder Transformator ein Baujahr)?
  • *Accuracy*: entspricht der Wert der Realität (korrekte GPS-Koordinaten)?
  • *Timeliness*: wie veraltet ist er (wurde das Einbaudatum des Zählers innerhalb von 24 Stunden aktualisiert)?
  • *Consistency*: hat dasselbe Asset dieselbe Spannungsangabe in GIS und CMMS?

Eine nützliche Referenz dafür, wie diese Dimensionen formal definiert sind, ist das DAMA-DMBOK Data Quality Framework, das breit als Basisvokabular für Enterprise Data Governance genutzt wird, auch bei Versorgern.

Warum das in Geld und Sicherheit durchschlägt

Zurück zum Transformator-Mismatch. Konkret verursacht er:

  • Abrechnungsfehler: Netzverlustberechnungen weisen Kosten Kunden am falschen Transformator zu und verzerren Cost-of-Service-Studien, die in Tarifverfahren vor den State Public Utility Commissions (PUCs) in den USA oder den National Regulatory Authorities (NRAs) in Europa verwendet werden.
  • Blinde Flecken bei der Zuverlässigkeit: SAIDI und SAIFI (System Average Interruption Duration/Frequency Index, die Standard-Zuverlässigkeitsmetriken in den USA, die an Regulierer berichtet werden) werden gegen das falsche Asset berechnet und untertreiben die tatsächliche Ausfallexposition am echten Transformator.
  • Sicherheitsrisiko: eine Kolonne, die zur Wartung beauftragt wird, „TX-4471 freizuschalten“, isoliert möglicherweise die falsche physische Einheit, wenn GIS und Schaltauftragssystem auseinanderlaufen.
  • Gescheiterte AMI-Integration: Smart-Meter-Daten lassen sich nicht korrekt auf Abgang- oder Transformatorebene aggregieren, weder für Lastprognosen noch für Investitionsentscheidungen zur Netzmodernisierung, was den Business Case für Grid-Edge-Analytics untergräbt.

Ein minimales Beispiel für Matching-Logik

Versorger starten Deduplizierung oft mit deterministischen Regeln, bevor probabilistisches Matching darübergelegt wird. Eine vereinfachte Regel in Pseudocode:

python
def match_asset(gis_record, cmms_record):
    if gis_record.asset_id == cmms_record.asset_id:
        return "exact_match"
    if (gis_record.gps_lat, gis_record.gps_lon) == (cmms_record.gps_lat, cmms_record.gps_lon) \
        and gis_record.asset_type == cmms_record.asset_type:
        return "probable_match_geo"
    if fuzzy_ratio(gis_record.description, cmms_record.description) > 0.85:
        return "probable_match_text"
    return "no_match"

Datensätze, die in no_match oder probable_match landen, gehen in eine manuelle Stewardship-Queue, den von Menschen geprüften Backlog, den jedes ausgereifte MDM-Programm als eigene Workload-Metrik verfolgt.

Wissenscheck

1. Im Transformator-Szenario war das Kernproblem, dass GIS und die Mobile-Work-Order-App bei der Asset-ID für dieselbe physische Einheit auseinanderliefen. Welche Kategorie von Datenproblem illustriert das?

2. Was unterscheidet Reference Data im Versorgerkontext am besten von Master Data?

3. Ein Versorger will Netzverluste korrekt berechnen, indem er Zähler den Transformatoren zuordnet, von denen sie versorgt werden. Welche zugrunde liegende Bedingung ist für das Funktionieren dieser Berechnung am kritischsten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Antworten zu den drei beschriebenen Master-Data-Domänen bei Versorgern.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Antworten dazu, warum die abweichenden Transformator-IDs die im Szenario beschriebenen Folgeprobleme verursachten.

Wählen Sie alle richtigen Antworten aus.

Benchmarks, an denen man sich orientieren kann

Publizierte, versorgerspezifische MDM-Benchmarks sind rar (Anbieter legen selten kundenbezogene Zahlen offen), nutzen Sie diese also als branchengeschätzte Bandbreiten, nicht als verifizierte Sektordurchschnitte:

  • Match Rates über 95 % zwischen GIS und CMMS gelten als ausgereiftes Programm; viele Versorger, die MDM-Initiativen starten, berichten anfängliche Match Rates im Bereich von 70 % bis 85 % vor der Bereinigung, wie in Utility-IT-Fallstudien und MDM-Anbieter-Whitepapers üblicherweise diskutiert (Schätzung).
  • Ziele für Golden Record Coverage von 90 %+ bei Kunden-Master-Data sind typische Programmziele in Enterprise-MDM-Rollouts (Schätzung, allgemeiner Enterprise-Benchmark, nicht versorgerspezifisch).
  • Projekte zur Behebung von Datenqualitätsproblemen in assetintensiven Branchen brauchen laut allgemeiner MDM-Implementierungsliteratur typischerweise 12 bis 36 Monate, um von fragmentierten Multi-System-Datensätzen zu einer governierten Single Source of Truth zu kommen.

Fragen Sie immer, wenn Sie einen MDM-Benchmark zitiert sehen: was ist die Quelle, welche Branche, welches Jahr?

Key Takeaways

  • Master Data (Assets, Zähler, Kunden) sind die stabilen Kerndaten, auf denen Versorger laufen; Reference Data sind die gemeinsamen Code-Sets (Spannungsklassen, Ausfallursachen), die dafür sorgen, dass Systeme sich über Bedeutung einig sind.
  • Eine einzige abweichende Kennung zwischen GIS und CMMS kann in Abrechnungsfehler, verzerrte SAIDI/SAIFI-Zuverlässigkeitsmetriken und Sicherheitsrisiken beim Schalten im Feld durchschlagen.
  • Vier zentrale Governance-Metriken zum Tracken: Match Rate (systemübergreifend korrekt verknüpfte Datensätze), Duplicate Rate (redundante Datensätze innerhalb eines Systems), Golden Record Coverage (Entitäten mit einem vertrauenswürdigen Master) und die vier Datenqualitätsdimensionen (Completeness, Accuracy, Timeliness, Consistency).
  • Rechenbeispiel: 1.968.000 gematchte Paare von 2.050.000 CIS-Liegenschaftsdatensätzen ergeben eine Match Rate von 96 %, das Niveau, das allgemein mit einem ausgereiften MDM-Programm verbunden wird.
  • Behandeln Sie alle MDM-Benchmark-Prozentwerte als Schätzungen aus allgemeinen Enterprise- oder Anbieterquellen, solange kein Versorger oder Regulierer eigene Zahlen publiziert hat; prüfen Sie immer Quelle und Aktualität, bevor Sie sie zitieren.

Zurück

Analytics-Maturity benchmarken: von Spreadsheets zu Predictive Pipelines

Weiter

Datenwert und ROI messen: KPIs für Entscheidungen über Dateninvestitionen