Die meisten Organisationen haben Daten. Weniger haben saubere Daten. Und von denen, die mit Datenqualität kämpfen, teilen fast alle ein zentrales Problem: Zu Beginn einigten sich niemand darauf, wie die Daten aussehen sollten, wer sie kontrolliert, oder was geschieht, wenn sie fehlerhaft sind.
Genau das regelt eine Master Data Management Richtlinie.
Sie ist kein Technologiedokument wie eine Datenbeschreibung oder Systemspezifikation. Sie ist eine formale Vereinbarung innerhalb der Organisation, wie Stammdaten erstellt, gepflegt, genutzt und korrigiert werden. Ohne sie wird selbst eine gut konfigurierte MDM-Plattform mit der Zeit in Inkonsistenzen abdriften.
Was Stammdaten wirklich sind
Stammdaten sind die Kerndaten, die die Geschäftsentitäten beschreiben: Produkte, Kunden, Lieferanten, Mitarbeiter, Standorte, Materialien. Sie sind nicht transaktional. Ein Verkaufsauftrag ist keine Stammdata. Der Kunde und das Produkt in diesem Auftrag sind es.
Für einen Hersteller umfassen Stammdaten typischerweise Produktspezifikationen, Materialklassifizierungen, Lieferantendatensätze und Standort- oder Anlagendaten. Für einen Distributor sind es hauptsächlich Produktkataloge sowie Kunden- und Lieferantenhierarchien. Der genaue Umfang variiert je nach Branche, aber das Prinzip ist gleich: Stammdaten werden systemübergreifend und abteilungsübergreifend genutzt, und Inkonsistenzen wirken sich überall aus.
Was eine MDM-Richtlinie abdeckt
Eine gut strukturierte MDM-Richtlinie behandelt fünf Bereiche. Sie muss nicht umfangreich sein. Zwanzig bis dreißig Seiten dichte Verfahren bedeuten normalerweise, dass die Richtlinie mit Betriebshandbüchern verschmolzen ist. Die Richtlinie setzt Prinzipien und Regeln fest. Verfahren zur Umsetzung dieser Regeln liegen separat vor.
Der erste Bereich ist Scope und Domänenabgrenzung. Die Richtlinie benennt die Datendomänen, die sie regelt, und definiert, was als Stammdata innerhalb jeder Domäne gilt. Das klingt offensichtlich, wird aber häufig übersehen. Ohne diese Definition klassifizieren verschiedene Abteilungen dieselben Datensätze unterschiedlich, was zu paralleler Verwaltung und konkurrierenden Versionen führt.
Der zweite Bereich ist Dateneigentum und Datenverwaltung. Für jede Domäne weist die Richtlinie einen Dateneigentümer zu: eine geschäftsseitige Rolle, die für Korrektheit und Vollständigkeit dieser Domäne verantwortlich ist. Unter dem Eigentümer sitzt der Datenverwalter, der tägliche Qualitätsaufgaben übernimmt. Dies ist verschieden vom IT-Eigentum an den Systemen, die die Daten speichern. Die Richtlinie macht diese Trennung explizit.
Der dritte Bereich sind Datenqualitätsstandards. Die Richtlinie definiert, wie „korrekt" aussieht: erforderliche Felder, akzeptierte Formate, gültige Wertebereiche, Eindeutigkeitsregeln und Namenskonventionen. Für Produktdaten könnte dies obligatorische Attribute, standardisierte Maßeinheitscodes oder Regeln für die Verknüpfung von Produktvarianten mit Stammprodukten bedeuten. Diese Standards werden zur Grundlage für automatisierte Validierung im MDM-System.
Der vierte Bereich behandelt Lebenszyklusmanagement-Regeln. Datensätze werden erstellt, geändert, zusammengeführt und letztendlich archiviert oder gelöscht. Die Richtlinie definiert, wer jede Aktion durchführen kann, unter welchen Bedingungen und mit welchen Genehmigungsschritten. Sie gibt beispielsweise vor, ob neue Lieferantendatensätze vor der Aktivierung Freigabe durch Procurement benötigen, oder wie ein Produkt, das zum Auslaufen markiert ist, durch das System fließt, bevor es eingestellt wird.
Der fünfte Bereich sind Compliance- und Audit-Anforderungen. Für Branchen mit behördlicher Aufsicht dokumentiert die Richtlinie, wie Stammdaten Rückverfolgbarkeit, Audit-Trails und Berichtanforderungen unterstützen. In der Chemieherstellung beispielsweise hängt die Korrektheit von Klassifizierungen gefährlicher Stoffe im MDM-System direkt von behördlichen Einreichungen und Produktkennzeichnung ab.
Warum Organisationen ohne Richtlinie im gleichen Problem landen
Ein 2025er Bericht des IBM Institute for Business Value ergab, dass mehr als ein Viertel der Organisationen jährlich über 5 Millionen Dollar durch schlechte Datenqualität verliert. Diese Zahl überrascht viele. Das sollte sie nicht. Ein typisches Beispiel in der Fertigung: Derselbe Lieferant existiert unter drei leicht unterschiedlichen Namen im ERP, in Procurement und in der Kreditorenbuchhaltung. Doppelte Datensätze erzeugen doppelte Bestellungen. Doppelte Bestellungen erzeugen doppelte Zahlungen. Niemand bemerkt es, bis zum Abstimmungsquartal. Das ist kein Systemfehler. Es ist ein Daten-Governance-Fehler.
Der gemeinsame Nenner dieser Probleme ist nicht schlechte Software. Es ist die Abwesenheit vereinbarter und systemweit durchgesetzter Regeln.
In Projekten, die wir mit mittelständischen Industrieunternehmen umgesetzt haben, kam das Problem selten von fehlender MDM-Tooling. Die Daten existierten in mehreren Systemen ohne formale Regeln, welche die autoritative Quelle ist. Finance verwaltete seinen eigenen Lieferantenstamm. Procurement hatte einen anderen. Das ERP hatte einen dritten. Wenn wir fragten, welcher korrekt sei, konnte es niemand sagen. Eine Richtlinie zwingt diese Frage zu beantworten, bevor sich das Datenproblem weiter verschärft.
Eine Master Data Management Richtlinie repariert nicht Ihre Daten. Sie schafft die Voraussetzungen, unter denen Ihre Daten repariert und sauber gehalten werden können.
Wie man eine aufbaut, die auch umgesetzt wird
Die meisten MDM-Richtlinienprojekte scheitern nicht beim Schreiben, sondern bei der Einführung. Ein Dokument, das in einem SharePoint-Ordner sitzt und während Systemänderungen oder Dateneingabe nie referenziert wird, hat keinen praktischen Wert.
Der erste Schritt ist ein Analyse des aktuellen Zustands. Bevor Sie etwas schreiben, kartografieren Sie, was heute tatsächlich geschieht. Wie werden neue Produkte erstellt? Wer genehmigt neue Lieferanten? Was passiert, wenn ein Datensatz falsch ist? Die Analyse offenbart, wo die Verantwortung unklar ist, wo Standards in Konflikt stehen und wo überhaupt kein Prozess existiert. Sie baut auch den internen Business-Case auf, warum ein Daten-Governance-Framework zunächst benötigt wird.
Der Scope sollte am Anfang eng definiert sein. Den Versuch, alle Datendomänen gleichzeitig zu regieren, ist ein häufiger Fehler. Wählen Sie die Domäne, die am meisten operationalen Schmerz verursacht, typischerweise Produktdaten oder Lieferantendaten für Hersteller. Bringen Sie diese Domäne gut zur Geltung, dokumentieren Sie, was funktioniert hat, und expandieren Sie dann zu anderen.
Vor dem Schreiben von Qualitätsstandards müssen Eigentümer zugewiesen werden. Standards haben keinen Wert, wenn niemand für ihre Einhaltung verantwortlich ist. Die Richtlinie benötigt einen benannten Eigentümer für jede Datendomäne. Nicht ein Team. Nicht eine Abteilung. Eine Rolle und eine spezifische Person darin. Ohne diese Rechenschaftspflicht bleibt die Richtlinie aspirativ. Datenverwalter-Verantwortungen sollten mit demselben Detaillierungsgrad wie die Standards selbst beschrieben werden.
Standards müssen auch unter Berücksichtigung der Systeme geschrieben werden. Richtlinien-Level-Regeln müssen in System-Level-Validierungen übersetzbar sein. Eine Regel wie „Produktnamen müssen konsistent sein" ist nicht durchsetzbar. Eine Regel wie „Produktnamen folgen dem Format [Kategorie] [Unterkategorie] [Differentiator], max. 80 Zeichen, keine Sonderzeichen" kann als Feldvalidierung im MDM-System implementiert und bei der Dateneingabe angewendet werden. Je spezifischer der Standard, desto näher kommt er dazu, einen Golden Record automatisch zu erzeugen.
Jedes MDM-Framework benötigt auch einen eingebauten Änderungsprozess, da sich MDM-Standards ändern. Neue Produktlinien erfordern neue Attribute. Regulatorische Updates benötigen neue Klassifizierungsfelder. Die Richtlinie sollte definieren, wie Standards aktualisiert werden: wer schlägt eine Änderung vor, wer überprüft sie, und wie werden vorhandene Datensätze migriert, wenn sich ein Standard ändert. Ohne dies wird die Richtlinie innerhalb von Monaten veraltet.
Der letzte Schritt ist Systemdurchsetzung. Die wirksamsten MDM-Richtlinien sind teilweise selbstdurchsetzend. Die MDM-Plattform validiert Datensätze gegen definierte Regeln bei der Erstellung oder beim Import, lehnt nicht konforme Einträge ab und leitet Ausnahmen durch definierte Genehmigungsworkflows weiter. Richtlinienaussagen und Systemverhalten müssen konsistent sein. Wenn sie auseinanderdriften, folgen Leute dem System, nicht dem Dokument.
Dieser letzte Punkt ist, wo die Plattformwahl wichtig wird. Die MDM-Plattform von AtroCore ist von Grund auf auf Richtliniendurchsetzung ausgerichtet. Sein EAV-basiertes Datenmodell ermöglicht, dass Datenqualitätsregeln pro Domäne und pro Attribut konfiguriert werden, durchgesetzt durch automatisierte Validierung bei der Dateneingabe. Rollenbasierte Zugriffskontrolle entspricht direkt der Eigentumsstruktur, die in der Richtlinie definiert ist. Workflow-Automatisierung verarbeitet Genehmigungsketten für Datensatzerstellung, Änderung und Lebenszyklusübergänge. Die 100%ige REST API-Abdeckung bedeutet, dass dieselben Regeln gelten, ob Daten über die UI, durch eine ERP-Integration oder durch einen Massenimport eingehen. Die Richtlinie und das System bleiben ausgerichtet, anstatt auseinanderzudriften.
Was die Richtlinie nachgelagert ermöglicht
Eine funktionierende MDM-Richtlinie reduziert mehr als nur Datenfehler. Mehrere Funktionen, die sonst fragil sind, werden zuverlässig, sobald Stammdaten geregelt sind.
Systemintegrationen sind die unmittelbarste. Wenn ERP, E-Commerce und Logistiksysteme alle Produkt- und Lieferantendaten aus einem einzigen geordneten Master abrufen, ziehen sie dieselben Daten. Integrationsfehler durch inkonsistente Referenzdaten sinken drastisch. Teams beenden manuelle Abstimmungs-Workarounds zwischen Systemen.
Behördliche Meldungen werden auf eine Weise auditierbar, wie sie es oft ohne Governance nicht sind. Wenn die Richtlinie definiert, wer was und wann geändert hat, und das MDM-System diese Protokollierung durchsetzt, haben Compliance-Teams einen verfolgbaren Audit-Trail. Für Hersteller, die ISO-Zertifizierung, GS1-Compliance oder branchenspezifische Vorschriften unterliegen, ist diese Rückverfolgbarkeit nicht optional und kann nicht nach der Tatsache rekonstruiert werden.
Datenmigration wird auch viel vorhersehbarer. Ein Wechsel zu einem neuen ERP oder PIM ist wesentlich schmerzloser, wenn die Quelldaten geregelt sind. Projekte, die mit ungeregelten Stammdaten starten, verbringen routinemäßig 40 bis 60 Prozent ihrer Zeitlinie nur auf Datenbereinigung. Eine Richtlinie reduziert das, weil die Bereinigungsarbeit bereits inkrementell, bei der Dateneingabe, im Laufe der Zeit durchgeführt wurde.
Der längerfristige Gewinn liegt in Analytics und KI. Nachfrageprognosen, Preismodelle und Optimierung der Lieferkette hängen alle von sauberen, konsistenten Referenzdaten ab. Ein Modell, das auf inkonsistenten Produktklassifizierungen oder unzusammengeführten Lieferantendatensätzen trainiert wurde, erzeugt unzuverlässige Ergebnisse, unabhängig vom verwendeten Algorithmus. Governance ist das, was die zugrunde liegenden Daten für diese Zwecke passend macht.
Organisationen, die frühzeitig eine MDM-Richtlinie umsetzen, bauen auf stabilem Boden auf. Jedes neue System, jede Integration oder Initiative, die sie hinzufügen, verbindet sich mit Daten, die bereits geregelt, bereits konsistent, bereits beherrscht sind. Das ist eine andere Ausgangsposition als nachträgliche Bereinigung.