Master Data Management und Datengovernanace werden häufig als austauschbar behandelt oder unter dem vagen Begriff „Datenstrategie" zusammengefasst. Beide sind Säulen des Enterprise-Datenmanagements, doch sie erfüllen unterschiedliche Funktionen, operieren auf verschiedenen Organisationsebenen und scheitern auf unterschiedliche Weise, wenn sie nicht aufeinander abgestimmt sind. In Projekten, die wir implementiert haben, fehlte es den Organisationen, die am meisten mit Datenbeschaffenheitsproblemen kämpften, selten an Tools. Ihnen fehlte die Verbindung zwischen Policy und Umsetzung.
Was Datengovernanace leistet
Datengovernanace ist ein Rahmenwerk zur Entscheidung darüber, wer was mit Daten tun darf und unter welchen Bedingungen. Ein Datengovernanace-Rahmenwerk definiert Verantwortung, Rechenschaftspflicht und Regeln, nach denen Daten erstellt, modifiziert, genutzt und stillgelegt werden. Ein Datengovernanace-Programm beantwortet Fragen wie: Wer trägt Verantwortung für die Genauigkeit von Kundendatensätzen? Was gilt als gültige Produktklassifizierung? Wie lange behalten wir Finanzmasterdaten nach Vertragsende?
Das Ergebnis eines Governance-Programms ist Policy. Richtlinien umfassen Datenbeschaffenheitsschwellwerte, Namenskonventionen, Zugriffsrechte, Stewardship-Zuweisungen, Klassifizierungsschemata und Compliance-Verpflichtungen. Ohne Governance werden diese Entscheidungen trotzdem getroffen – nur inkonsistent und unsichtbar, von wem auch immer gerade eine Tabellenkalkulation bearbeitet.
Governance erstreckt sich auf alle Daten einer Organisation, nicht nur auf Stammdaten. Sie deckt Transaktionsdaten, Metadaten, Betriebsdaten und deren Beziehungen ab. Primäre Stakeholder sind Geschäftsführer, Dateneigentümer, Compliance-Teams und Rechtsabteilungen. In größeren Organisationen koordiniert ein Datengovernanace-Rat typischerweise Richtlinien abteilungsübergreifend. Die IT ist beteiligt, aber Governance ist grundsätzlich eine Geschäftsfunktion.
Was MDM leistet
Master Data Management ist die Gesamtheit der Prozesse und Systeme, mit denen eine Organisation ihre zentralen, gemeinsamen Datenbereiche in einer einzigen, verbindlichen Version erstellt und verwaltet: Kunden, Produkte, Lieferanten, Standorte, Mitarbeiter und ähnliche Referenzobjekte, die sich über mehrere Systeme erstrecken.
MDM ist in erster Linie eine technische und operative Funktion. Sie verwaltet die Datenintegration aus mehreren Quellsystemen, Deduplizierung und Matching, Datenbereichung, Qualitätsvalidierung, Hierarchie-Management und Verteilung an verbrauchende Systeme. Das Ergebnis eines MDM-Programms ist ein Masterdatensatz, auch Golden Record genannt: eine bereinigten, konsolidierten und zuverlässigen Repräsentation eines Geschäftsobjekts, auf die sich nachgelagerte Systeme verlassen können. Die MDM-Plattform arbeitet typischerweise als zentraler Hub und fungiert als Datenspeicher für Kundendaten, Produktdaten, Lieferantendaten und andere gemeinsame Bereiche, um konsistente Versionen an jede angebundene Anwendung zu verteilen.
Während Governance die Regeln definiert, führt MDM sie aus. Wenn Governance vorschreibt „ein Produktdatensatz muss eine gültige GTIN enthalten, bevor er veröffentlicht werden kann", ist MDM das System, das auf diese GTIN prüft, fehlende Datensätze kennzeichnet und sie über einen Stewardship-Workflow zur Behebung leitet. Das Ergebnis ist, wenn beide Programme aufeinander abgestimmt sind, eine einzige verlässliche Datenquelle, der jede Abteilung vertrauen kann.
MDM ist spezifisch auf Stammdaten beschränkt. Es verwaltet nicht alle organisatorischen Daten. Primäre Stakeholder sind Datentechniker, Integrations-Architekten, Datenverwalter und die Geschäftsverantwortlichen der verwalteten Bereiche.
Wo sie sich überschneiden
Die Beziehung zwischen Master Data Management und Datengovernanace ist keine Hierarchie. Keine sitzt über der anderen. Sie sind voneinander abhängig: Governance liefert die Autorität und Policy, die MDM benötigt, um Entscheidungen zu treffen, und MDM bietet die Ausführungsumgebung, die Governance benötigt, um praktische Wirkung zu haben.
Die sichtbarste Schnittstelle ist Datenstewardship. Datenverwalter werden normalerweise vom Governance-Programm definiert, mit klaren Domänenzuweisungen, Genehmigungsbefugnissen und Eskalationspfaden. Aber sie verrichten ihre tatsächliche Arbeit in MDM-Tools: Überprüfung gekennzeichneter Datensätze, Auflösung von Duplikaten, Genehmigung von Änderungen und Bestätigung von Bereicherung. Wenn ein Verwalter einen Datensatz ablehnt, leitet das MDM-System ihn mit einem Ursachencode durch den Workflow zurück; wenn dieser ihn genehmigt, wird der Datensatz zum Golden Record heraufgestuft und an Nachlagersysteme verteilt. Dieser Workflow funktioniert nur, wenn Governance bereits zwei Dinge getan hat: ein Geschäftsglossar erstellt, das definiert, was jede Datenbereiche abteilungsübergreifend bedeutet, und Dateneigentümerschaft so klar zugewiesen, dass jede Entscheidung jemanden zur Verantwortung hat. Wenn das Governance-Programm diese Arbeit nicht geleistet hat, stagnieren MDM-Workflows, weil niemand die Autorität hat, Konflikte zu lösen.
Datenbeschaffenheit ist der zweite große Bereich, in dem die beiden Programme aufeinandertreffen. Governance setzt Beschaffenheitsstandards fest, beispielsweise Mindest-Vollständigkeitsschwellen, obligatorische Attribute oder Formatspezifikationen für Datengenauigkeit und Datenkonsistenz. MDM misst gegen diese Standards und setzt sie beim Dateneintrag oder der Integration durch. Die Kosten dieser Lücke sind nicht abstrakt: Nach einem Bericht des IBM Institute for Business Value von 2025 schätzen mehr als ein Viertel der Organisationen jährliche Verluste von über 5 Millionen USD aufgrund schlechter Datenbeschaffenheit, und Gartner beziffert die durchschnittlichen Kosten schlechter Datenbeschaffenheit auf 12,9 Millionen USD pro Jahr.
Eine Governance-Policy, die nur in einem gemeinsamen Dokument existiert, hat keine operative Wirkung. Ein MDM-System, das Beschaffenheitsprüfungen ohne Governance-definierte Standards durchführt, führt nur willkürliche Regeln aus, denen niemand formell zugestimmt hat.
Regulatorische Compliance ist wo Fehlabstimmung am teuersten wird. Verordnungen wie GDPR, CCPA und die EU-Verordnung zur allgemeinen Produktsicherheit erlegen spezifische Verpflichtungen auf, wie bestimmte Daten aufgezeichnet, aufbewahrt und zugänglich gemacht werden müssen. Governance definiert, was diese Verpflichtungen für jede Datenbereiche bedeuten, einschließlich Datenspeicherzeiträumen und Zugriffskontrolle. MDM operationalisiert sie durch Feld-ebenen-Kontrollen, Zugriffsbeschränkungen, Audit Trails und automatisierte Datenspeicher-Zeitpläne. Datenursprung, d.h. die Fähigkeit zu verfolgen, woher ein Datensatz kam, wie er geändert wurde und von wem, ist oft ebenso eine Compliance-Anforderung wie ein technisches Feature, und es funktioniert nur, wenn Governance definiert hat, was der Ursprung zeigen muss. Ein Hersteller, der Produktsicherheitsdaten unter GPSR verwaltet, benötigt beispielsweise sowohl eine Governance-Policy, die angibt, welche Produktattribute rechtlich erforderlich sind, als auch ein MDM-System, das Vollständigkeitsprüfungen vor der Genehmigung zur Verteilung erzwingt.
Die Frage der Abfolge
Eine häufig gestellte Frage in Organisationen, die beide Programme gleichzeitig starten, ist, ob Governance zuerst definiert werden soll oder das MDM-System zuerst gebaut werden soll. Keines kann vollständig vor dem anderen abgeschlossen werden, aber der richtige Startpunkt hängt davon ab, wo die Probleme liegen.
Wenn das primäre Problem politischer Natur ist, d.h. niemand einigt sich darauf, wer welche Daten besitzt oder welche Regeln gelten sollen, muss Governance zuerst kommen. Das Erstellen eines MDM-Systems vor Klärung des Dateneigentums führt zu einer technisch funktionsfähigen Plattform, die niemand nutzt, weil jede Entscheidung einen territorialen Konflikt auslöst.
Wenn das primäre Problem technischer Natur ist, ist es sinnvoll, mit der MDM-Infrastruktur zu beginnen. In Projekten, die wir für mittelständische Hersteller und Distributoren implementiert haben, führte das Erstellen einer funktionierenden MDM-Pipeline oft zu konkreten Belegen, dass Governance-Gespräche vorankommen mussten. Menschen sind bereit, sich auf Eigentümerschaftsregeln zu einigen, sobald sie in einem echten System sehen können, wie die Daten aussehen und was schiefgeht, wenn die Regeln unklar sind.
Die meisten Organisationen wählen am Ende einen parallelen Ansatz: Etablieren Sie Governance zuerst für die prioritärste Datenbereiche, wie Produkt oder Kunde, bauen Sie dann MDM-Prozesse und Tools für dieselbe Domäne, bevor Sie auf andere ausweiten. Der Anfang mit einer einzelnen Domäne hält beide Programme in echten Datenproblemen verwurzelt, statt in abstrakter Policy-Ausgestaltung.
Häufige Fehlermuster
Governance ohne MDM
führt zu Richtlinien, die in Dokumentation existieren, aber nie durchgesetzt werden. Datenbeschaffenheitsziele werden gesetzt und nie gemessen. Verwalter werden ernannt, haben aber kein System, in dem sie arbeiten. Compliance-Verpflichtungen werden anerkannt, aber nicht operationalisiert. Das Governance-Programm verliert schließlich Glaubwürdigkeit, weil sich nichts sichtbar verbessert.
MDM ohne Governance
führt zu einer technisch leistungsfähigen Datenplattform, die auf undokumentierten Annahmen läuft. Die Matching- und Deduplizierungsregeln im MDM-System spiegeln die Vorlieben von wem auch immer sie konfiguriert hat, nicht eine bewusste Organisationsentscheidung. Wenn zwischen Geschäftseinheiten ein Konflikt über die Klassifizierung eines Kunden entsteht, gibt es keine Autorität, um ihn zu lösen. Das MDM-System wird zum Engpass statt zum Beschleuniger.
Fehlabgestimmte Abfolge
führt zu einem MDM-System, das nicht mit später geschriebenen Governance-Richtlinien konform ist. Dies ist häufig in Organisationen, die MDM-Infrastruktur schnell erstellen und dann später eine Governance-Funktion hinzufügen. Das Nachrüsten von Governance in ein bereits laufendes MDM-Programm erfordert Neuverhandlung von Regeln, die bereits in die Systemlogik eingebaut sind, was teuer und disruptiv ist.
Plattformauswahl
Bei der Bewertung von Master Data Management-Software sollten Datengovernanace-Fähigkeiten von Anfang an Teil der Bewertungskriterien sein. Die Plattform muss konfigurierbare Stewardship-Workflows unterstützen, Datenbeschaffenheits- und Datenrichtlinien durchsetzen, die vom Geschäft definiert statt von der IT hart codiert werden, und Audit Trails bieten, die für Regulatory Reporting ausreichend sind. Sie sollte auch Governance-Metadaten für externe Tools wie Datenkataloge oder Lineage-Tracker verfügbar machen. Zunehmend müssen Organisationen ihre MDM-Plattform mit sauberen, verwalteten Masterdaten in KI-Workflows einspeisen. KI-Systeme erben Datenbeschaffenheitsprobleme direkt, und ungelöste Duplikate oder fehlende Attribute in Stammdaten führen zu unzuverlässigen Modellausgaben.
Eine Plattform, die Governance als separates Modul behandelt, schafft das gleiche Organisationsproblem in technischer Form: zwei Programme, die manuell synchronisiert werden müssen. Plattformen, die Governance-Kontrollen direkt in das Datenmodell einbetten, reduzieren diesen Overhead.
Eine MDM-Plattform für Produktbereiche muss Regulatory Data-Verpflichtungen nativ handhaben, nicht durch Workarounds.
Für Hersteller, die Produktdaten verwalten, ist die zusätzliche Überlegung, ob das MDM-System Regulatory Data-Verpflichtungen neben operativer Governance verwalten kann. Der EU Digital Product Passport erfordert beispielsweise, dass bestimmte Datenattribute strukturiert, versioniert und in einem definierten Format für Dritte zugänglich sind. Das ist gleichzeitig eine Governance-Policy-Frage und eine MDM-Implementierungsfrage.
AtroCore ist eine Open-Source Master Data Management- und Integrationsplattform mit einem 100% konfigurierbaren Datenmodell, was bedeutet, dass Governance-Kontrollen um die tatsächlichen Datenbereiche einer Organisation herum gebaut werden, nicht um eine vordefinierte Vendorstruktur. Sie läuft On-Premise oder in der Cloud unter einer GPLv3-Lizenz ohne Pro-Benutzer-Gebühren. Rollenbasierte Zugriffskontrolle, konfigurierbare Stewardship-Workflows und Datenbeschaffenheitsregeln auf Attributebene sind alle native Bestandteile der Plattform, ebenso wie bidirektionale REST API-Synchronisation mit ERP-, CRM- und E-Commerce-Systemen. In der Praxis nutzen unsere Kunden im Bereich Industrieausrüstung und Baustoffe sie, um Produktdaten-Vollständigkeitsregeln über Dutzende angebundene Systeme durchzusetzen, sodass Datensätze, die Governance-Prüfungen nicht bestehen, niemals Downstream-Kanäle erreichen.
Fazit
Die oben beschriebenen Fehlermuster haben eine gemeinsame Wurzel: Ein Programm wurde als Abhängigkeit des anderen statt als sein Partner behandelt. Governance, die MDM voraus läuft, führt zu Policy ohne Durchsetzungspfad. MDM, das Governance voraus läuft, führt zu Durchsetzung ohne legitime Autorität. Keines funktioniert allein.
Organisationen, die MDM als Technologieprojekt und Datengovernanace als separate Organisationsinitiative behandeln, enden in der Regel mit sowohl einem System, das die vereinbarte Policy nicht widerspiegelt, als auch mit einer Policy, bei der kein System sie durchzusetzen hat. Mit einer gemeinsamen Definition der höchstpriorität-Datenbereiche beginnen, Stewardship vor Workflow-Konstruktion zuweisen und eine Plattform auswählen, die Governance als native Funktion statt als Add-on behandelt, wird mehr tun, um diese Lücke zu schließen, als jede nachfolgende Datenbeschaffenheits-Bereinigung.