Master Data Management: Definition & Praxis

Was ist Master Data Management?

Master Data Management (MDM), auch Stammdatenmanagement genannt, ist die unternehmensweite Disziplin, mit der die zentralen Geschäftsobjekte einer Organisation – Kunden, Lieferanten, Produkte, Materialien, Standorte, Mitarbeitende und rechtliche Einheiten – systemübergreifend definiert, konsolidiert, qualitätsgesichert und verantwortlich verwaltet werden.

Das Ergebnis ist ein Golden Record: eine einzige, autoritative Darstellung je Entität, auf die alle nachgelagerten Prozesse und Systeme zugreifen.

Gartner formuliert es präzise: MDM ist eine „technologiegestützte Geschäftsdisziplin, in der Business und IT zusammenarbeiten, um Einheitlichkeit, Genauigkeit, Stewardship, Governance, semantische Konsistenz und Verantwortlichkeit der offiziellen, gemeinsam genutzten Stammdaten eines Unternehmens sicherzustellen."

Das Wort „Disziplin" trägt hier das Gewicht. Es ist kein rhetorischer Zusatz.

IBM beschreibt MDM als umfassenden Ansatz zur Verwaltung der kritischen Daten eines Unternehmens, der Technologie, Werkzeuge und Prozesse nutzt, um einen einheitlichen Stammdatendienst zu schaffen. Im internationalen Standardwerk der Disziplin, dem DAMA-DMBOK von DAMA International, ist Stammdatenmanagement gemeinsam mit dem Referenzdatenmanagement als eigenständiges Wissensgebiet verankert.

Was sind Stammdaten – und was nicht?

Der häufigste Definitionsfehler in Enterprise-Projekten: Stammdaten werden mit „allen wichtigen Daten" gleichgesetzt. Das führt zu einem Scope, der nicht beherrschbar ist.

Gartner definiert Stammdaten als „die kleinstmögliche Menge konsistenter und einheitlicher Identifikatoren und erweiterter Attribute, die die Kernentitäten eines Unternehmens eindeutig beschreiben und über mehrere Geschäftsprozesse hinweg genutzt werden". Zwei Kriterien sind entscheidend: kleinstmögliche Menge und prozessübergreifende Nutzung.

IBM unterscheidet sechs Datenarten, die in jedem Unternehmen vorkommen. Die Abgrenzung ist die Grundlage jeder sauberen MDM-Scope-Definition:

Die praktische Konsequenz: Eine Rechnung ist kein Stammdatum. Der Kunde auf der Rechnung ist eines. Wer diese Grenze im Projekt nicht früh und hart zieht, verhandelt zwei Jahre später noch über den Scope.

Die Stammdaten-Domänen

IBM gliedert Stammdaten in Domänen mit zugehörigen Subdomänen – Kunde (inkl. Mitarbeitende und Vertriebspartner), Produkt (inkl. Teile, Assets), Lieferant (inkl. Kontakte, Lieferpläne, Vertragskonditionen), Standort (inkl. geografische Gliederungen) sowie weitere Objekte wie Verträge, Garantien und Lizenzen.

In der europäischen Enterprise-Praxis kommen zwei Domänen hinzu, die in angloamerikanischen Modellen oft unterschätzt werden:

Legal Entities

Rechtliche Einheiten, Beteiligungsstrukturen, Gesellschafterverhältnisse. Relevant für Konzernkonsolidierung, regulatorisches Reporting und Compliance-Nachweise.

Organisationsdaten

Aufbau- und Ablauforganisation, Kostenstellen, Funktionen, Berichtslinien. Relevant für Berechtigungen, Steuerung und Personalprozesse.

Beide Domänen sind bei Goldright als eigenständige Produkte abgebildet – im Legal Entity Manager und im Organizational Data Manager. Der Grund ist nicht Produktlogik, sondern Datenlogik: Diese Objekte haben eigene Lebenszyklen, eigene Historisierungsanforderungen und eigene Ownership-Strukturen.

Der Golden Record

Der Golden Record ist das operative Ergebnis von MDM. IBM beschreibt ihn als Single Source of Truth, die Daten aus verschiedenen Quellen integriert und bestätigt, sodass alle im Unternehmen mit denselben Informationen arbeiten.

Wichtig ist die Abgrenzung: Ein Golden Record ist kein bereinigter Export. Er ist ein dauerhaft gepflegter, versionierter, verantworteter Datensatz mit definierten Survivorship-Regeln – also expliziten Festlegungen, welches Quellsystem für welches Attribut autoritativ ist. Wie diese Regeln in der Praxis entstehen, behandeln wir vertieft im Beitrag Golden Record Stammdaten: So bauen und pflegen Sie ihn richtig.

Warum ist Master Data Management 2026 relevant?

Die Antwort lautet nicht „wegen KI". KI verschärft den Druck, aber sie erzeugt ihn nicht. Der Druck entsteht aus fünf belegbaren Entwicklungen, die unabhängig voneinander wirken.

Der Reifegrad stagniert – flächendeckend

Gartner beschreibt fünf Reifegrade für MDM-Programme: initial, developing, defined, managed, optimizing. Aus tausenden Gesprächen mit Klienten leitet Gartner ab, dass sich die meisten großen Organisationen auf Stufe 2 („Developing“) befinden und auf Stufe 3 („Defined”) hinarbeiten. Stärker regulierte Branchen wie Finanzdienstleistungen und Gesundheitswesen liegen tendenziell weiter vorn – weil dort verbindliche Kontrollanforderungen gelten.

Das ist die zentrale Zahl dieses Artikels. Nicht weil sie dramatisch klingt, sondern weil sie erklärt, warum Budgets fließen und Ergebnisse ausbleiben. Gartner formuliert unmissverständlich: Die reine Implementierung von MDM-Software schließt die MDM-Lücke nicht.

Schlechte Datenqualität kostet 12,9 Mio. USD pro Jahr

Gartner beziffert die durchschnittlichen jährlichen Kosten schlechter Datenqualität auf 12,9 Mio. USD pro Organisation. Der Wert wird seit Jahren als branchenübergreifende Referenzgröße herangezogen und ist damit die belastbarste verfügbare Grundlage für eine Business-Case-Rechnung.

Für die Argumentation im Board ist entscheidend, was diese Zahl nicht ist: eine Schätzung der Kosten eines MDM-Programms. Sie ist die Schätzung der Kosten seines Fehlens.

Der gemessene Ausgangszustand liegt unter der Selbsteinschätzung

Die belastbarste Untersuchung zur realen Stammdatenqualität stammt aus dem Harvard Business Review. Tadhg Nagle, Thomas C. Redman und David Sammon ließen 75 Führungskräfte jeweils 100 kürzlich in ihrer Abteilung angelegte Datensätze auf offensichtliche Fehler prüfen.

Das Ergebnis: Durchschnittlich 47 % der neu erzeugten Datensätze enthielten mindestens einen kritischen Fehler. Nur 3 % der ermittelten Datenqualitäts-Scores konnten selbst bei großzügigster Auslegung als akzeptabel eingestuft werden.

Die Methodik ist bewusst einfach und in jedem Unternehmen in wenigen Stunden reproduzierbar. Genau das macht sie für die Standortbestimmung so nützlich: Sie liefert eine Baseline, bevor irgendein Tool ausgewählt wird.

Deutsche Unternehmen nutzen ihre Daten kaum

Bitkom hat in einer repräsentativen Befragung von 603 Unternehmen ab 20 Beschäftigten erhoben, wie weit die Datennutzung tatsächlich reicht. Nur 6 % gehen davon aus, das Potenzial der verfügbaren Daten vollständig auszuschöpfen. 31 % schöpfen es eher stark aus, 42 % eher wenig, 18 % überhaupt nicht.

Nur 7 % der Unternehmen sehen sich als Vorreiter bei datengetriebenen Geschäftsmodellen. Und bei den Unternehmen, die keine Daten mit Partnern teilen, nennt ein Drittel (33 %) fehlende Kompatibilität der Daten als Grund.

Fehlende Kompatibilität ist keine Frage der Leitungen. Sie ist eine Frage gemeinsamer Definitionen – also exakt der Gegenstand von Master Data Management.

Regulatorik macht Datenstrukturen prüfbar

Der EU Data Act ist laut Europäischer Kommission am 11. Januar 2024 in Kraft getreten und seit dem 12. September 2025 anwendbar. Er schafft harmonisierte Regeln für den Zugang zu Daten vernetzter Produkte, für den Wechsel zwischen Datenverarbeitungsdiensten und für Interoperabilität.

Der Bitkom-Befund dazu ist bemerkenswert: 44 % der befragten Unternehmen mussten demnach bereits häufig oder mehrfach Innovationsvorhaben rund um Datennutzung wegen rechtlicher Vorgaben oder Unsicherheiten stoppen.

Wer Daten auf Anforderung herausgeben, portieren oder interoperabel bereitstellen muss, braucht eindeutige Entitäten, dokumentierte Herkunft und nachvollziehbare Änderungshistorien. Das sind MDM-Fähigkeiten, keine juristischen.

Der Markt bestätigt die Neubewertung

Grand View Research beziffert den globalen MDM-Markt für 2023 auf 19,9 Mrd. USD und prognostiziert 60,7 Mrd. USD bis 2030, entsprechend einer jährlichen Wachstumsrate von 17,4 % im Zeitraum 2024 bis 2030. Nordamerika hielt 2023 einen Umsatzanteil von 38,9 %.

Wachstumstreiber sind laut Bericht unter anderem hybride IT-Landschaften, Omnichannel-Modelle und regulatorische Anforderungen – nicht primär KI.

Die vier Wurzelursachen: Warum MDM-Initiativen stecken bleiben

Die Beobachtung aus zwei Jahrzehnten Enterprise-Architektur ist unspektakulär: MDM-Programme scheitern selten am Werkzeug. Sie scheitern an vier strukturellen Mustern, die sich branchenübergreifend wiederholen.

MDM wird als Projekt geführt, nicht als Betriebsdisziplin

Ein Projekt hat einen Anfang, ein Ende und ein Budget. Stammdaten haben keines davon. Sie entstehen täglich neu, verändern sich, veralten.

Wird MDM als Projekt aufgesetzt, endet es mit einem bereinigten Datenbestand und einer Abschlusspräsentation. Sechs bis zwölf Monate später ist die Duplikatenquote zurück auf dem Ausgangsniveau, weil die Entstehungsprozesse unverändert geblieben sind. Bereinigt wurde das Symptom, nicht der Mechanismus.

Gartner adressiert genau diesen Punkt in seinem MDM Operating Model, das sieben funktionale Komponenten unterscheidet: Data-&-Analytics-Strategie, Scope, Metriken, Governance, Organisation und Rollen, Prozess sowie Technologie. Sechs dieser sieben Komponenten sind dauerhafte Betriebsfähigkeiten. Nur eine davon lässt sich sinnvoll als Projekt liefern.

Die Konsequenz: Wer MDM budgetiert, muss Betriebskosten budgetieren – nicht nur Implementierungskosten.

Ownership existiert auf dem Papier, nicht in der Entscheidung

Die zweite Ursache ist die häufigste und die unbequemste. McKinsey beschreibt den heutigen Zustand in vielen Organisationen wörtlich so: Daten hätten oft keinen echten „Owner", der sicherstellt, dass sie aktuell und nutzbar sind; Datenbestände lägen zudem – teils dupliziert – in ausufernden, isolierten und kostspieligen Umgebungen.

In der Praxis sieht das so aus: Es gibt eine Data-Governance-Richtlinie. Es gibt eine RACI-Matrix. Es gibt benannte Data Owner. Und es gibt keine Instanz, die entscheidet, ob im Konfliktfall die Kundenklassifikation aus dem CRM oder aus dem ERP gilt.

Ownership ohne Entscheidungsrecht ist Dokumentation, keine Governance. Die Frage „Wer entscheidet, wenn zwei Fachbereiche unterschiedliche Wahrheiten haben?" ist der Lackmustest jedes MDM-Programms. Wird sie nicht beantwortet, eskaliert jede Survivorship-Regel zur Grundsatzdiskussion.

Die Architektur folgt der Unternehmenshistorie, nicht dem Datenmodell

Gewachsene Systemlandschaften sind kein Versäumnis, sondern das Ergebnis rationaler Einzelentscheidungen über zwei Jahrzehnte: Akquisitionen mit eigenen ERP-Instanzen, dezentrale Länderorganisationen mit eigenen CRM-Systemen, Fachbereichslösungen, die schneller verfügbar waren als der Konzernstandard.

Jede dieser Entscheidungen war für sich vertretbar. In Summe entsteht eine Landschaft, in der dieselbe Entität in fünf Systemen unter fünf Bezeichnungen existiert – ohne dass ein Schlüssel sie verbindet.

IBM benennt Mergers & Acquisitions ausdrücklich als einen der zentralen MDM-Anwendungsfälle: MDM erleichtert die Integration unterschiedlicher Datensysteme und verhindert das Chaos unkoordinierter Datenabgleichsprozesse.

Die architektonische Antwort ist nicht die Ablösung der Landschaft. Sie ist ein Stammdaten-Hub, der über den Systemen liegt, Entitäten eindeutig identifiziert und die Quellsysteme bidirektional versorgt – ohne sie zu ersetzen.

Es gibt keine Baseline, also auch keinen Nachweis

Die vierte Ursache ist die stillste. MDM-Programme starten häufig ohne gemessenen Ausgangszustand. Es gibt eine gefühlte Problemlage („unsere Lieferantendaten sind schlecht"), aber keine Zahl.

Ohne Baseline ist kein Fortschritt nachweisbar. Ohne Nachweis versiegt das Budget nach dem zweiten Jahr – nicht weil das Programm scheitert, sondern weil sein Erfolg unsichtbar bleibt.

Gartner führt Metriken in seinem MDM Operating Model als eigenständige funktionale Komponente und beschreibt die Reifeentwicklung von „keine Metriken" bis zu „Metriken als Grundlage von Steuerung und Investitionsentscheidungen".

Die gute Nachricht: Die Baseline ist billig. Die von Nagle, Redman und Sammon beschriebene Methode – 100 kürzlich angelegte Datensätze, Fehler markieren, fehlerfreie Datensätze zählen – liefert in wenigen Stunden einen belastbaren Startwert je Domäne.

Kein Datenqualitätsproblem, sondern ein Betriebsmodell-Problem

Die meisten Organisationen diagnostizieren richtig, dass ihre Daten schlecht sind. Und leiten daraus die falsche Maßnahme ab: eine Bereinigung.

Eine Bereinigung ist eine Zustandsänderung. Schlechte Datenqualität ist aber kein Zustand, sondern ein Fluss. Sie wird täglich neu produziert – von Prozessen ohne Pflichtfelder, von Schnittstellen ohne Validierung, von Rollen ohne Entscheidungsrecht.

Wer den Fluss nicht ändert, bereinigt in Zyklen. Und zahlt in Zyklen.

Dieser Perspektivwechsel klingt akademisch. Er ist es nicht. Er entscheidet darüber, ob Sie ein Budget für 18 Monate beantragen oder eine Fähigkeit aufbauen, die trägt.

Der Lösungsansatz: Ein MDM-Betriebsmodell in sechs Phasen

Das folgende Modell ist entlang der funktionalen Komponenten des Gartner MDM Operating Model aufgebaut und um die Erfahrung aus europäischen Enterprise-Implementierungen ergänzt. Es ist bewusst sequenziell: Jede Phase erzeugt die Voraussetzung der nächsten.

Phase 1: Reifegrad und Baseline bestimmen

Ziel: Eine Zahl, kein Gefühl.

Bestimmen Sie zwei Dinge parallel. Erstens den organisatorischen Reifegrad entlang der fünf Gartner-Stufen – initial, developing, defined, managed, optimizing. Zweitens die faktische Datenqualität je Domäne über eine einfache, wiederholbare Messung.

Konkret zu erheben:

• Domänen-Inventar: Welche Stammdaten-Domänen existieren, in welchen Systemen, in welchem Umfang?

• Duplikatenquote je Domäne: Wie viele Datensätze beschreiben dieselbe reale Entität?

• Vollständigkeitsrate je Domäne: Welcher Anteil der geschäftskritischen Attribute ist befüllt?

• Fehlerquote bei Neuanlagen: Nach der HBR-Methode: 100 aktuelle Datensätze, kritische Fehler markieren, fehlerfreie zählen.

• Ownership-Karte: Für welche Domäne existiert eine benannte, entscheidungsbefugte Instanz?

Ergebnis: Ein Reifegrad-Score und eine Baseline je Domäne. Beides brauchen Sie für die Budgetgenehmigung und für den späteren Wirkungsnachweis.

Phase 2: Scope und Domänenpriorisierung

Ziel: Eine Domäne. Nicht fünf.

Die Priorisierung folgt zwei Kriterien, nicht einem: Business-Impact (welche Domäne blockiert die meisten wertschöpfenden Prozesse?) und Ownership-Bereitschaft (wo existiert eine Führungskraft, die die Verantwortung annehmen will?).

Die zweite Frage wird regelmäßig unterschätzt und entscheidet häufiger über den Erfolg als die erste. Eine technisch einfache Domäne ohne Owner scheitert. Eine komplexe Domäne mit engagiertem Owner gelingt.

Definieren Sie in dieser Phase außerdem die Abgrenzung: Welche Attribute sind Stammdaten, welche nicht? Die Gartner-Definition – kleinstmögliche Menge, prozessübergreifend genutzt – ist hier der Maßstab, nicht der Wunschzettel der Fachbereiche.

Phase 3: Governance und Rollenmodell

Ziel: Entscheidungswege, nicht Dokumente.

Drei Rollen sind zu besetzen, und zwar namentlich:

• Data Owner: Verantwortet eine Domäne fachlich. Entscheidet über Definitionen, Qualitätsstandards und Zugriff. Sitzt im Business, nicht in der IT.

• Data Steward: Verantwortet die operative Umsetzung: Pflege, Qualitätssicherung, Eskalation. Im DAMA-DMBOK zählt Data Stewardship zu den Kernkomponenten des Wissensgebiets Reference & Master Data Management – neben Golden-Record-Erzeugung, Matching und Hierarchiemanagement.

• Entscheidungsinstanz: Ein benanntes Gremium mit Mandat, Konflikte zwischen Domänen zu entscheiden. Ohne diese Rolle bleibt Governance folgenlos.

Formalisieren Sie parallel die Qualitätsregeln: Pflichtfelder, Validierungslogiken, Freigabe-Workflows. Und definieren Sie messbare Ziele je Domäne – etwa Vollständigkeit über 95 %, Duplikatenquote unter 1 %, definierte Aktualisierungsfristen.

McKinsey beschreibt als Zielbild ein Operating Model, in dem Datenbestände wie Produkte geführt werden – mit dediziertem Team, definiertem Owner und kontinuierlicher Weiterentwicklung. Für Stammdaten ist das keine Zukunftsvision, sondern die Mindestanforderung an einen tragfähigen Betrieb.

Phase 4: Datenmodell und Implementierungsstil festlegen

Ziel: Eine bewusste Architekturentscheidung statt einer Defaulteinstellung.

Erst in dieser Phase fällt die Architekturentscheidung – nach Governance, nicht davor. Die vier etablierten Implementierungsstile unterscheiden sich fundamental in Aufwand, Wirkung und Eingriffstiefe. Der ausführliche Vergleich folgt im nächsten Abschnitt.

Parallel entsteht das kanonische Datenmodell: die verbindliche Definition der Entität und ihrer Attribute, unabhängig von der Repräsentation in einzelnen Quellsystemen. Dieses Modell ist das eigentliche Asset. Systeme werden ersetzt, das Modell bleibt.

Phase 5: Golden Record und Integration

Ziel: Ein autoritativer Datensatz, der in den operativen Fluss zurückwirkt.

Die technische Umsetzung umfasst vier Bausteine:

• Matching und Deduplizierung: Regelbasierte und probabilistische Verfahren identifizieren Datensätze, die dieselbe Entität beschreiben – über Systemgrenzen und Schreibweisen hinweg.

• Survivorship-Regeln: Explizite Festlegung, welches Quellsystem für welches Attribut autoritativ ist. Diese Regeln sind fachliche Entscheidungen, keine technischen Konfigurationen.

• Historisierung: Point-in-Time-Nachvollziehbarkeit jeder Änderung. Grundlage für Audits, Due Diligence und regulatorische Nachweise.

• Bidirektionale Integration: Der Golden Record versorgt ERP, CRM, BI und nachgelagerte Plattformen über konfigurierbare Schnittstellen – und nimmt Änderungen aus ihnen kontrolliert entgegen.

Der letzte Punkt entscheidet über Wirkung. Ein Golden Record ohne Rückfluss in die operativen Systeme ist ein Bericht.

Phase 6: Betrieb, Messung, Skalierung

Ziel: Die Fähigkeit stabilisieren und ausrollen.

Der Betrieb umfasst automatisierte Validierung an der Dateneingabe, Workflow-gesteuerte Freigaben, kontinuierliches Monitoring der definierten KPIs und regelmäßige Berichterstattung an die Data Owner.

Erst wenn eine Domäne über mindestens zwei Quartale stabil gemessene Zielwerte erreicht, beginnt der Rollout auf die nächste. Diese Reihenfolge ist unbequem, weil sie langsam wirkt. Sie ist die einzige, die skaliert.

Best Practices: Was in der Enterprise-Praxis trägt

Die folgenden sieben Prinzipien stammen aus MDM-Implementierungen im europäischen Mittelstand und in Konzernstrukturen. Sie sind bewusst als Verhaltensregeln formuliert, nicht als Funktionsliste.

Business Sponsorship vor Toolauswahl.
Gartner formuliert es deutlich: Die Implementierung von MDM-Software allein schließt die MDM-Lücke nicht. Ein Programm ohne benannten C-Level-Sponsor aus dem Business scheitert an fehlender Adoption – unabhängig von der Qualität der Plattform.

Eine Domäne, ein messbarer Erfolg, dann die nächste.
Der parallele Angriff auf alle Domänen erzeugt Stakeholder-Komplexität, die kein Programm trägt. Die sequenzielle Vorgehensweise liefert früher sichtbare Ergebnisse und sichert damit das Folgebudget.

Qualitätsregeln gemeinsam mit dem Fachbereich definieren.
Jede Validierungsregel braucht eine fachliche Begründung. Die Prüffrage lautet: „Was passiert operativ, wenn dieses Feld fehlt oder falsch ist?" Regeln ohne diese Antwort blockieren Prozesse und werden umgangen.

Messen, bevor gebaut wird.
Die Baseline ist Voraussetzung, nicht Nachbereitung. Eine Duplikatenquote, die vor Projektstart nicht erhoben wurde, lässt sich nachträglich nicht rekonstruieren – und damit auch keine Verbesserung belegen.

Historisierung von Anfang an mitdenken.
Point-in-Time-Nachvollziehbarkeit nachträglich einzuführen ist aufwendig bis unmöglich. Sie ist Voraussetzung für regulatorische Nachweise, Audit-Fähigkeit und die Rekonstruktion vergangener Zustände.

API-first integrieren.
Der Golden Record entfaltet Wirkung nur dort, wo er konsumiert wird. Konfigurierbare, bidirektionale Schnittstellen zu ERP, CRM, BI und Analyseplattformen sind kein Ausbaustadium, sondern Teil der Grundarchitektur.

Das Datenmodell vom System trennen.
Systeme werden abgelöst, migriert, konsolidiert. Ein kanonisches Datenmodell, das unabhängig von der aktuellen Landschaft definiert ist, überlebt diese Zyklen und macht Migrationen beherrschbar.

Vergleich: Die vier MDM-Implementierungsstile

Die Architekturentscheidung ist die folgenreichste im gesamten Programm. Sie bestimmt Aufwand, Eingriffstiefe in die Quellsysteme und die erreichbare Konsistenz. Vier Stile haben sich etabliert.

In europäischen Konzernstrukturen ist das Coexistence-Modell in den meisten Fällen die tragfähige Wahl. Es erreicht operative Konsistenz, ohne die Ablösung gewachsener Systeme vorauszusetzen – ein Anspruch, der in Landschaften mit mehreren ERP-Instanzen realistisch bleiben muss.

MDM im Verhältnis zu benachbarten Disziplinen

Die zweite häufige Abgrenzungsfrage betrifft die Nachbardisziplinen. Die folgende Übersicht ordnet ein.

Die Kernaussage: Diese Konzepte konkurrieren nicht. Data Governance definiert die Spielregeln, MDM setzt sie für Stammdaten operativ durch, PIM und CRM sind spezialisierte Konsumenten und Quellen, das Data Warehouse wertet aus. Wer MDM durch eines der anderen zu ersetzen versucht, verlagert das Problem, statt es zu lösen.

Praxis-Muster: Der Weg von Reifegrad 2 zu Reifegrad 3

Das folgende Muster ist aus mehreren realen Projekten abstrahiert und bewusst ohne Nennung konkreter Unternehmen dargestellt. Es beschreibt einen typischen Verlauf, keine Einzelfallstudie.

Ausgangslage

Ein produzierender Konzern mit mehreren Landesgesellschaften, historisch gewachsen durch Akquisitionen. Mehrere ERP-Instanzen, zwei CRM-Systeme, ein eigenständiges Beschaffungssystem. Lieferanten existieren mehrfach unter abweichenden Schreibweisen und Klassifikationen. Der Monatsabschluss enthält mehrere Tage manuellen Abgleichs. Auf die Frage nach der Duplikatenquote gibt es keine Zahl – nur Schätzungen einzelner Fachbereiche.

Nach dem Gartner-Reifegradmodell entspricht das Stufe 2: Es existieren Initiativen, aber keine unternehmensweit definierten Prozesse, Rollen und Metriken.

Vorgehen

Das Programm beginnt nicht mit einer Toolauswahl, sondern mit einer Messung. Nach der HBR-Methode werden je Domäne 100 kürzlich angelegte Datensätze auf kritische Fehler geprüft. Das Ergebnis liegt regelmäßig deutlich unter der Selbsteinschätzung der Organisation – und erzeugt genau dadurch die Bereitschaft, Ownership verbindlich zu klären.

Anschließend wird eine Domäne priorisiert. In diesem Muster: Lieferanten. Nicht weil sie technisch am einfachsten wäre, sondern weil der Einkaufsleiter die Verantwortung übernimmt und der Business-Impact über Beschaffung, Compliance und Konzernreporting hinweg unmittelbar sichtbar ist.

Es folgen Governance und Rollenmodell mit benannter Entscheidungsinstanz, dann das kanonische Datenmodell, dann die Architekturentscheidung – im Regelfall Coexistence –, dann Matching, Survivorship-Regeln und bidirektionale Integration.

Wirkungsmechanismus

Der messbare Effekt entsteht an drei Stellen. Erstens sinkt der manuelle Abgleichsaufwand, weil Systeme nicht mehr gegeneinander abgeglichen werden müssen. Zweitens verkürzen sich Prozesse, die auf Lieferantenidentität aufsetzen – Freigaben, Risikoprüfungen, Rahmenvertragszuordnungen. Drittens wird regulatorisches Reporting reproduzierbar, weil Historisierung und Herkunft dokumentiert sind.

Der eigentliche Übergang

Der Sprung von Reifegrad 2 auf 3 findet nicht statt, wenn die Plattform produktiv geht. Er findet statt, wenn die Organisation zum ersten Mal eine Stammdatenentscheidung trifft, ohne dass das Programmteam sie moderieren muss. Ab diesem Punkt trägt die Disziplin sich selbst.

Fallstricke: Was ein MDM-Programm zuverlässig zum Scheitern bringt

Der Scope wächst mit den Wünschen der Fachbereiche.
Jeder Bereich meldet Attribute nach, die „auch wichtig" sind. Ohne die Gartner-Abgrenzung – kleinstmögliche Menge, prozessübergreifend genutzt – wächst das Datenmodell, bis es nicht mehr pflegbar ist. Der Scope ist eine Entscheidung, kein Konsens.

Governance wird dokumentiert statt entschieden.
Eine RACI-Matrix ohne Entscheidungsinstanz beschreibt Zuständigkeit, nicht Autorität. Der Test: Wer entscheidet innerhalb von zwei Wochen, wenn zwei Fachbereiche widersprechende Definitionen vertreten?

Die Bereinigung ersetzt die Prozessänderung.
Ein einmalig bereinigter Bestand verliert innerhalb von sechs bis zwölf Monaten seine Qualität, wenn die Entstehungsprozesse unverändert bleiben. Bereinigung ohne Governance ist eine wiederkehrende Ausgabe.

Die Integration wird nachgelagert geplant.
Ein Golden Record ohne Rückfluss in die operativen Systeme verbessert keine Prozesse. Er erzeugt eine weitere Datenquelle – und damit exakt das Problem, das gelöst werden sollte.

Alle Domänen starten gleichzeitig.
Zu viele Stakeholder, zu viele parallele Zielkonflikte, zu wenig Fokus. Der sequenzielle Ansatz wirkt langsamer und liefert früher.

Es wird kein Betriebsbudget eingeplant.
Nach dem Go-live endet die Programmfinanzierung, der Betrieb bleibt ungeklärt. Data Stewards werden nebenbei besetzt, Monitoring läuft ins Leere, die Kennzahlen verfallen still.

Der Nutzen wird behauptet statt belegt.
„Die Daten sind jetzt besser" ist im Steering Committee kein Argument. Ohne Baseline, definierte KPIs und regelmäßiges Reporting ist der Wertbeitrag nicht darstellbar – und das Folgebudget nicht begründbar.

Fazit: Master Data Management ist eine Fähigkeit, kein Projekt

Die zentrale Erkenntnis dieses Artikels lässt sich in einem Satz zusammenfassen: Der Engpass im Master Data Management liegt fast nie in der Technologie.

Gartner verortet die Mehrheit großer Organisationen auf Reifegrad 2 von 5 – und stellt zugleich klar, dass die Implementierung von MDM-Software die MDM-Lücke nicht schließt. Der Sprung auf Reifegrad 3 entsteht dort, wo Scope entschieden, Ownership mit Entscheidungsrecht ausgestattet und Fortschritt gemessen wird.

Die Kosten der Untätigkeit sind dabei besser belegt als die Kosten des Handelns. Gartner beziffert die Folgen schlechter Datenqualität auf durchschnittlich 12,9 Mio. USD jährlich. Der Harvard Business Review zeigt, dass der reale Ausgangszustand regelmäßig weit unter der Selbsteinschätzung liegt. Und Bitkom belegt, dass nur 6 % der deutschen Unternehmen das Potenzial ihrer Daten ausschöpfen.

Der Weg dorthin ist unspektakulär und funktioniert: messen, eine Domäne priorisieren, Ownership verbindlich klären, den passenden Implementierungsstil wählen, den Golden Record in die operativen Prozesse zurückspielen – und den Betrieb finanzieren, nicht nur die Einführung.

Beginnen Sie mit der Messung. Alles andere folgt daraus.

Quellen-Verzeichnis

Gartner: "Master Data Management: Build a Strong Process, Framework and Solution" - https://www.gartner.com/en/data-analytics/topics/master-data-management

Gartner: "Data Quality: Best Practices for Accurate Insights" - https://www.gartner.com/en/data-analytics/topics/data-quality

Harvard Business Review: "Only 3% of Companies’ Data Meets Basic Quality Standards" - https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards

Bitkom e. V.: "Presseinformation: Deutsche Unternehmen nutzen ihre Daten kaum" - https://www.bitkom.org/Presse/Presseinformation/Deutsche-Unternehmen-nutzen-ihre-Daten-kaum

Grand View Research: "Master Data Management Market Report" - https://www.grandviewresearch.com/industry-analysis/master-data-management-market-report

McKinsey & Company: "The data-driven enterprise of 2025" - https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-data-driven-enterprise-of-2025

Europäische Kommission: "Data Act" - https://digital-strategy.ec.europa.eu/en/policies/data-act

IBM: "Was ist Master Data Management (MDM)?" - https://www.ibm.com/de-de/think/topics/master-data-management

DAMA International: "DAMA Data Management Body of Knowledge (DAMA-DMBOK)" - https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/

DAMA-MN (Chapter von DAMA International): "Reference & Master Data Management (MDM)" - https://www.dama-mn.org/Reference-MDM