MDM- und Referenzdaten-Governance

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.

Warum Master Data Management ein Betriebsmodell braucht

Master Data Management (MDM) verwaltet gemeinsam genutzte Kerndaten wie Kunden, Lieferanten oder Produkte. Die Software kann Datensätze vergleichen und verteilen. Sie kann jedoch nicht entscheiden, welche fachliche Bedeutung gilt, welches Fehlerrisiko akzeptabel ist oder wer einen strittigen Datensatz freigibt.

Ein tragfähiges Betriebsmodell verteilt deshalb Entscheidungen: Der Fachbereich verantwortet Bedeutung und Nutzung, Data Stewards bearbeiten Konflikte, technische Teams betreiben Regeln und Schnittstellen. Datenschutz, Informationssicherheit oder Recht werden dort beteiligt, wo ihr Mandat berührt ist.

Die vier Steuerungsfelder

1. Verantwortung: Für jedes Stammdatenobjekt ist festgelegt, wer Regeln freigibt und wer Konflikte bearbeitet.
2. Zusammenführung: Vergleichs-, Zusammenführungs- und Trennregeln sind versioniert und testbar.
3. Verteilung: Nutzende Systeme wissen, welche Version sie erhalten und wie Änderungen angekündigt werden.
4. Betrieb: Fehler, Ausnahmen und Regeländerungen landen in einer nachvollziehbaren Warteschlange.

Entscheidungen und Rollen

Der technische Betrieb darf Regeln nicht still verändern. Umgekehrt darf der Fachbereich keine Regel freigeben, deren technische Wirkung und Rückabwicklung ungeklärt sind.

Ein sinnvoller Einstieg

Wählt ein wichtiges Objekt, etwa den Geschäftskunden. Nehmt zwei Quellsysteme und ein nutzendes System in den Umfang. Dokumentiert Identifikatoren, Vergleichsregeln, Prioritäten, Konfliktweg und Verteilung. Testet einen eindeutigen Treffer, einen Grenzfall, eine falsche Zusammenführung und die anschließende Trennung.

Der Einstieg ist gelungen, wenn ein Außenstehender erklären kann, warum ein Datensatz zusammengeführt wurde, welche Quellwerte erhalten blieben und wer die Entscheidung ändern darf.

Messung

• Anteil automatisch zusammengeführter Fälle, getrennt nach sicherer Regel und Grenzfall
• falsch zusammengeführte und übersehene Dubletten aus geprüften Stichproben
• Zeit bis zur Entscheidung bei strittigen Fällen
• Zahl der nutzenden Systeme mit bekannter Regel- und Datenversion
• offene Ausnahmen ohne verantwortliche Person oder Ablaufdatum

Checkliste

• Fachliche und technische Verantwortung sind getrennt und benannt.
• Vergleich, Zusammenführung und Trennung sind als eigene Entscheidungen dokumentiert.
• Quellwerte und Herkunft bleiben nach einer Zusammenführung nachvollziehbar.
• Änderungen werden vor der Verteilung mit realistischen Fällen getestet.
• Nutzende Systeme erhalten Hinweise auf relevante Regeländerungen.

Artefakt

Das Ergebnis ist eine MDM-Betriebskarte: Objekt, beteiligte Quellen, nutzende Systeme, Entscheidungsrechte, Regeln, Konfliktweg, Tests und Ablageorte der Nachweise auf einer Seite.

Was ein Golden Record wirklich ist

Ein Golden Record ist kein von selbst entstehender „wahrer“ Datensatz. Er ist eine für einen festgelegten Zweck freigegebene Sicht auf mehrere Quellen. Für Rechnungsanschriften kann das ERP-System maßgeblich sein, für die bevorzugte Kontaktadresse dagegen ein Kundenportal. Deshalb braucht jeder ausgegebene Wert Herkunft, Regelversion und Gültigkeitszeitpunkt.

Drei Entscheidungen getrennt halten

1. Match: Gehören zwei Datensätze wahrscheinlich zur selben Person, Organisation oder Sache?
2. Merge: Dürfen sie zu einer gemeinsamen Identität verbunden werden?
3. Survivorship: Welcher Quellwert wird für einen bestimmten Zweck ausgegeben?

Ein hoher Ähnlichkeitswert beantwortet nur die erste Frage. Er ist keine automatische Erlaubnis zur Zusammenführung. Grenzfälle gehören in eine fachliche Prüfung, besonders wenn eine falsche Verbindung Zahlungen, Zugriffe oder Kommunikation beeinflusst.

Regeln, die Menschen prüfen können

Eine Regel nennt verwendete Merkmale, Mindestqualität, Schwelle, Ausschlüsse und erwartete Fehler. Ein Beispiel: Handelsregisternummer plus Land kann für Unternehmen ein starker Schlüssel sein. Ein ähnlicher Name allein reicht nicht, weil verschiedene Unternehmen gleich heißen können.

Beim Zusammenführen bleiben ursprüngliche Kennungen und Werte erhalten. Eine Trennung muss möglich sein, ohne die Historie zu verlieren. Nutzende Systeme erhalten eine stabile Kennung und werden informiert, wenn sich eine Verbindung oder Prioritätsregel ändert.

Tests vor der Freigabe

• eindeutiger Treffer mit starken Schlüsseln
• ähnliche Namen, die nicht zusammengehören
• umgezogene oder umbenannte Entität
• zwei Personen mit gemeinsamer Adresse
• fehlerhafte Zusammenführung und vollständige Trennung

Bewertet nicht nur die Trefferrate. Messt in einer geprüften Stichprobe sowohl falsche Zusammenführungen als auch übersehene Dubletten. Welche Fehlerart schwerer wiegt, entscheidet der Geschäftszweck.

Verantwortlichkeiten

Der fachliche Data Owner genehmigt Zweck und Fehlertoleranz. Der Data Steward prüft Grenzfälle und dokumentiert Gründe. Das technische Team implementiert Regeln, Protokollierung und Rückabwicklung. Nutzende Systeme bestätigen, dass sie Kennungsänderungen verarbeiten können.

Checkliste

• Match, Merge und Auswahl des Ausgabewerts sind getrennt beschrieben.
• Der Golden Record ist an einen Zweck gebunden.
• Quellwerte, Regelversion und Entscheidungsgrund bleiben erhalten.
• Grenzfälle werden nicht allein anhand eines Modellwerts verbunden.
• Eine fehlerhafte Zusammenführung lässt sich kontrolliert rückgängig machen.

Artefakt

Das Ergebnis ist ein Match- und Merge-Vertrag mit Zweck, Schlüsseln, Schwellen, Ausschlüssen, Prüfweg, Prioritätsregeln, Testfällen und Verfahren zur Trennung.

Referenzdaten sind kleine Listen mit großer Wirkung

Länder, Währungen, Produktstatus oder Schadenarten wirken unscheinbar. Werden ihre Codes unterschiedlich verstanden, scheitern jedoch Schnittstellen, Kennzahlen und regulatorische Meldungen. Referenzdaten brauchen deshalb dieselbe Sorgfalt wie große Datenprodukte.

Was jede Liste erklären muss

Jeder Eintrag besitzt einen stabilen Code, eine verständliche Bedeutung, Gültig-von und gegebenenfalls Gültig-bis. Zusätzlich braucht die Liste eine fachlich verantwortliche Person, eine Version und einen beschriebenen Änderungsweg. Anzeigenamen dürfen übersetzt oder verbessert werden; der stabile Code wird nicht still wiederverwendet.

Interne Listen werden von externen Standards unterschieden. Bei ISO-Ländercodes oder branchenspezifischen Codes dokumentiert das Unternehmen, welche Ausgabe gilt und wie Aktualisierungen übernommen werden. Eigene Erweiterungen müssen klar als solche erkennbar sein.

Änderungen ohne Überraschungen verteilen

Neue Codes können häufig abwärtskompatibel ergänzt werden. Umbenennungen, Zusammenlegungen oder Stilllegungen können dagegen Berichte und Schnittstellen verändern. Eine Änderung enthält daher Wirkung, Gültigkeitsdatum, Zuordnung vom alten zum neuen Code und betroffene Systeme.

Unbekannte Codes werden nicht still auf „Sonstiges“ abgebildet. Sie landen in einer sichtbaren Fehlerbehandlung, damit fachliche Unterschiede nicht verschwinden.

Beispiel

Der Status CLOSED reicht nicht, wenn Fachbereiche darunter „Vertrag beendet“, „Kunde inaktiv“ oder „technisch archiviert“ verstehen. Besser sind getrennte Codes mit Definition, erlaubten Übergängen und Gültigkeit. Ein Bericht kann dann bewusst entscheiden, welche Zustände in seine Kennzahl gehören.

Messung

• nutzende Systeme pro Version und deren Umstellungsstand
• unbekannte oder ungültige Codes je Schnittstelle
• Änderungen ohne Zuordnung oder Vorankündigung
• Zeit zwischen Freigabe und vollständiger Verteilung
• veraltete Codes, die nach ihrem Enddatum weiter genutzt werden

Checkliste

• Codes sind stabil, eindeutig und nicht an einen Anzeigenamen gebunden.
• Bedeutung, Gültigkeit und zulässige Übergänge sind erklärt.
• Externer Standard und interne Erweiterung sind unterscheidbar.
• Änderungen enthalten Zuordnung und Auswirkungsanalyse.
• Unbekannte Werte werden sichtbar behandelt.

Artefakt

Das Ergebnis ist ein Referenzdatenvertrag mit Liste, Version, Codes, Bedeutung, Gültigkeit, verantwortlicher Person, Änderungsweg und Zuordnungen zwischen Versionen.

Warum Quellen widersprechen

Mehrere Systeme können für dasselbe Objekt unterschiedliche Werte liefern, ohne dass eines vollständig „falsch“ ist. Ein Lieferantenportal kennt vielleicht die aktuelle Bankverbindung, das ERP-System den rechtlich geprüften Namen und das Einkaufssystem die zuständige Kategorie. Eine einzige globale Quellenrangfolge würde diese Unterschiede verdecken.

Survivorship zweckbezogen entscheiden

Survivorship bezeichnet die Regel, die aus mehreren Quellwerten den ausgegebenen Wert auswählt. Die Regel gilt pro Attribut und Zweck. Sie kann auf fachlicher Autorität, Aktualität, bestätigter Qualität oder einem manuellen Entscheid beruhen.

Eine gute Regel beantwortet:

• Welche Quellen dürfen diesen Wert liefern?
• Welche Quelle ist für welchen Zweck maßgeblich?
• Wie werden Aktualität und Freigabestatus verglichen?
• Wann wird statt einer automatischen Auswahl ein Konflikt eröffnet?
• Wie lange gilt eine manuelle Ausnahme?

„Neuester Wert gewinnt“ ist selten ausreichend. Ein frisch importierter, ungeprüfter Firmenname darf einen rechtlich bestätigten Namen nicht überschreiben.

Konflikte sichtbar bearbeiten

Ein Konfliktfall enthält Objekt, Attribut, Quellwerte, Zeitpunkte, Regelversion, Auswirkung und zuständige Person. Die Entscheidung dokumentiert nicht nur den gewählten Wert, sondern auch den Grund. Wiederkehrende Fälle zeigen, dass eine Regel oder ein Quellprozess verbessert werden muss.

Korrekturen sollten möglichst im verantwortlichen Quellsystem erfolgen. Wird nur im MDM-System bereinigt, bleibt der Fehler in der Quelle bestehen und kann später erneut in Analysen oder KI-Anwendungen gelangen. Eine lokale Übersteuerung braucht deshalb einen sichtbaren Grund und ein Ablauf- oder Prüfdatum.

Tests und Messung

Testet gleich alte Werte, fehlende Zeitstempel, gesperrte Quellen, manuelle Übersteuerungen und verspätete Ereignisse. Messt Konflikte nach Attribut und Ursache, Bearbeitungszeit, wiederkehrende Fehler sowie den Anteil der Korrekturen, die bis zur Quelle zurückgeführt wurden.

Checkliste

• Auswahlregeln gelten pro Attribut und Zweck, nicht pauschal pro System.
• Fachliche Freigabe schlägt bloße Aktualität, wenn der Zweck es verlangt.
• Entscheidungen bleiben mit Grund und Regelversion nachvollziehbar.
• Manuelle Übersteuerungen haben Prüfdatum und verantwortliche Person.
• Wiederkehrende Fehler werden im Quellsystem bearbeitet.

Artefakt

Das Ergebnis ist eine Konflikt- und Auswahlmatrix: Attribut, Zweck, zulässige Quellen, Priorität, Konfliktschwelle, Prüfrolle, Ausnahmeweg und Rückmeldung an die Quelle.

MDM ist laufender Betrieb, kein einmaliges Bereinigungsprojekt

Nach dem ersten Import ändern sich Quellen, Regeln und Geschäftsobjekte weiter. Ohne festen Arbeitsrhythmus wachsen Konfliktlisten, Ausnahmen bleiben liegen und nutzende Systeme erfahren Änderungen zu spät. Eine Betriebskadenz ordnet diese Arbeit nach Dringlichkeit und Wirkung, nicht nach beliebigen Kalenderversprechen.

Vier wiederkehrende Arbeitsarten

Laufende Fallbearbeitung

Data Stewards prüfen Grenzfälle, fehlende Pflichtwerte und Rückmeldungen aus nutzenden Systemen. Kritische Fälle erhalten eine Reaktionsfrist; harmlose Dubletten dürfen gebündelt werden.

Regelpflege

Wiederkehrende Konflikte werden nicht endlos manuell gelöst. Das Team prüft, ob Vergleichs-, Prioritäts- oder Validierungsregeln verbessert werden müssen. Jede Änderung wird mit einer repräsentativen Stichprobe getestet.

Wirkungsprüfung

Fachliche und technische Verantwortliche betrachten falsche Zusammenführungen, übersehene Dubletten, veraltete Referenzdaten und Fehler in der Verteilung. Die Kennzahlen werden nach Objekt, Quelle und Regelversion aufgeschlüsselt.

Änderungsplanung

Neue Quellen, Felder oder nutzende Systeme werden nur aufgenommen, wenn Bedeutung, Kennungen, Qualität, Verantwortungen und Rückabwicklung geklärt sind. Betroffene Teams erhalten die Änderung vor ihrer Aktivierung.

Prioritäten verständlich festlegen

Priorität entsteht aus Geschäftsauswirkung, Zahl betroffener Datensätze, regulatorischem Risiko und Möglichkeit der Rückabwicklung. Eine falsche Bankverbindung benötigt typischerweise schnellere Behandlung als eine abweichende Schreibweise ohne Folgewirkung.

Eine sinnvolle Arbeitsübersicht

Messung

• Bestand und Alter offener Fälle nach Auswirkung
• wiederkehrende Konflikte trotz früherer Entscheidung
• Anteil der Regeländerungen mit Positiv- und Negativtest
• Fehler, die bis zum Quellsystem zurückgeführt wurden
• Änderungen, die nutzende Systeme ungeplant treffen

Checkliste

• Kritische Fälle sind von normaler Pflege unterscheidbar.
• Wiederkehrende Fehler führen zu Regel- oder Quellverbesserungen.
• Regeländerungen besitzen Version, Tests und Freigabe.
• Ausnahmen haben Ablaufdatum und Maßnahme.
• Nutzende Systeme werden vor relevanten Änderungen beteiligt.

Artefakt

Das Ergebnis ist ein MDM-Betriebsboard mit Fallart, Auswirkung, verantwortlicher Person, Regelversion, nächster Entscheidung und Abschlussnachweis.