Wie schaffen Sie eine einheitliche Datenbasis, wenn jede Abteilung eigene Stammdaten pflegt?

Der Vertrieb kennt einen Kunden unter einer anderen Nummer als die Buchhaltung. Das ERP führt einen Artikel, den die Logistik bereits umbenannt hat. Zwei Umsatzberichte zeigen unterschiedliche Ergebnisse, obwohl beide dieselbe Unternehmensperiode abbilden sollen. Solche Widersprüche entstehen häufig, wenn Abteilungen ihre Stammdaten unabhängig verwalten und verbindliche Regeln für Identitäten, Attribute und Kennzahlen fehlen.

Eine einheitliche Datenbasis entsteht nicht zwangsläufig durch eine zentrale Datenbank. Entscheidend sind gemeinsame Identifikatoren, nachvollziehbare Abgleichregeln, eindeutige fachliche Verantwortlichkeiten und verbindliche KPI-Definitionen. Ein Master-Data-Management-Ansatz (MDM) verbindet diese Elemente und sorgt dafür, dass unterschiedliche Systeme dieselben Geschäftsobjekte zuverlässig wiedererkennen.

Für IT und Controlling bedeutet das: weniger manuelle Abstimmungen, nachvollziehbare Datenkorrekturen und eine belastbarere Grundlage für Entscheidungen. Gerade in Schweizer Unternehmen mit mehreren Gesellschaften, ERP-Instanzen und Geschäftsprozessen in CHF und EUR muss dabei zwischen zentralen Unternehmensstandards und legitimen lokalen Anforderungen unterschieden werden. Der praktikable Einstieg beginnt deshalb bei den Ursachen der Datenkonflikte, nicht bei der Auswahl einer neuen Plattform.

Warum Dubletten trotz Bereinigung zurückkommen, sobald 2 Systeme parallel laufen?

Dubletten kehren zurück, wenn zwei Systeme dieselben Kunden, Artikel oder Lieferanten unabhängig anlegen können und keine gemeinsamen Identitätsregeln besitzen. Eine einmalige Bereinigung entfernt vorhandene Mehrfacheinträge, verhindert jedoch keine neuen. Nachhaltig wird sie erst durch systemübergreifende Match-Regeln, eine geregelte Synchronisation und eindeutige Zuständigkeiten für die führenden Daten.

Der technische Ursprung liegt häufig in den Primärschlüsseln. Das CRM identifiziert einen Kunden beispielsweise mit der Nummer C-1058, während das ERP denselben Geschäftspartner unter D-774 führt. Beide IDs sind innerhalb ihres jeweiligen Systems gültig. Ohne übergreifende Zuordnung bleibt aber unklar, ob sie dieselbe reale Organisation beschreiben.

Ein Golden Record schafft hier eine konsolidierte, fachlich verbindliche Sicht auf das Geschäftsobjekt. Er benötigt nicht zwingend eine vollständig zentralisierte Datenhaltung. Entscheidend ist, dass Identitätsabgleich und Attributregeln für alle beteiligten Systeme gelten. Die Dokumentation Microsoft Purview zur Integration von Master Data Management beschreibt die Bereinigung, Vereinheitlichung und Standardisierung unterschiedlicher Datenquellen zur Erstellung solcher Golden Records.

Ein typischer Ablauf zeigt, warum reine Dublettenbereinigung scheitert:

1. Ein Mitarbeiter legt im CRM einen neuen Kunden an.
2. Das ERP enthält diesen Kunden bereits, hat seinen Datensatz aber noch nicht an das CRM synchronisiert.
3. Beide Systeme akzeptieren die Anlage unter unterschiedlichen lokalen IDs.
4. Beim nächsten Abgleich werden die Einträge ohne ausreichende Identitätsprüfung getrennt weitergeführt.

Das Problem lässt sich nicht allein durch häufigere Synchronisation beheben. Auch Match-Kriterien, Konfliktauflösung und der Zeitpunkt der Datenanlage müssen zusammenpassen. Zu unscharfe Kriterien können umgekehrt unterschiedliche Kunden fälschlicherweise zusammenführen.

Prüfen Sie deshalb drei Fragen: Gibt es eine systemübergreifende Match-Logik? Wer entscheidet über widersprüchliche Attribute? Und wird ein Fehler in seiner fachlich führenden Quelle korrigiert, statt ausschliesslich in einer nachgelagerten Kopie?

Als Qualitätsindikator eignet sich die Wiederholungsquote: Wie viele zuvor zusammengeführte oder bereinigte Geschäftsobjekte erscheinen innerhalb eines definierten Beobachtungszeitraums erneut als Dubletten? Zusammen mit der Gesamtzahl geprüfter Objekte und dokumentierten Fehlzuordnungen macht sie die Wirksamkeit der Regeln sichtbar.

Damit ist zunächst geklärt, welche Datensätze zusammengehören. Für verlässliche Kennzahlen folgt jedoch eine zweite Aufgabe: Auch die Bedeutung der ausgewerteten Geschäftsdaten muss übereinstimmen.

Warum zwei Reports 2 verschiedene Umsätze zeigen und keiner recht hat?

Zwei Umsatzberichte können unterschiedliche Ergebnisse liefern, obwohl beide technisch korrekt berechnet wurden. Häufig verwenden sie unterschiedliche Buchungszeiträume, Währungsumrechnungen, Umsatzabgrenzungen oder Filter. Ohne verbindliche KPI-Definition lässt sich deshalb nicht entscheiden, welcher Wert für das Controlling massgeblich ist. Der eigentliche Konflikt liegt dann in der fachlichen Semantik, nicht zwingend in der Reporting-Software.

Im CRM wird eine Verkaufschance möglicherweise bereits beim Auftragseingang als gewonnen und umsatzrelevant markiert. Das ERP berücksichtigt dagegen fakturierte Beträge oder gebuchte Erlöse. Eine Finanzberichterstattung kann zusätzlich Erlöskorrekturen und periodengerechte Abgrenzungen enthalten. Alle drei Perspektiven beantworten unterschiedliche Fragen.

Für Schweizer Unternehmen mit CHF- und EUR-Geschäften kommen weitere mögliche Abweichungen hinzu: Wurde zum Transaktions-, Buchungs- oder Monatsabschlusskurs umgerechnet? Werden Beträge inklusive oder exklusive Mehrwertsteuer dargestellt? Berücksichtigt der Report Gutschriften, Rabatte und konzerninterne Geschäftsvorfälle?

Eine verbindliche KPI-Definition sollte mindestens die folgenden Punkte dokumentieren:

Diese Definition gehört in einen gemeinsamen Datenkatalog, idealerweise mit Versionierung und nachvollziehbarer Änderungshistorie. Ein Data Catalog allein löst aber keinen fachlichen Konflikt: Die verantwortlichen Personen müssen die Definition verbindlich verabschieden und ihre Verwendung im Reporting kontrollieren.

Stimmen zwei Berichte nicht überein, vergleichen Sie zuerst Definition, Filter, Zeitstempel und Währungsregeln. Erst danach sollten Sie technische Ladefehler oder fehlerhafte Datensätze untersuchen. So wird eine diffuse Diskussion über vermeintlich falsche Zahlen zu einer überprüfbaren Ursachenanalyse.

Sind Identitäten und Kennzahlendefinitionen geklärt, lässt sich fundierter entscheiden, ob die bestehende Systemarchitektur ausreicht oder eine gemeinsame Plattform wirtschaftlich sinnvoll wird.

Wann lohnt sich eine gemeinsame Datenplattform, wenn 3 Abteilungen eigene Daten haben?

Eine gemeinsame Datenplattform lohnt sich besonders dann, wenn mehrere Abteilungen dieselben Geschäftsobjekte unabhängig verwalten, bereichsübergreifende KPIs benötigen und zahlreiche individuelle Schnittstellen hohe Wartungs- und Abstimmungskosten verursachen. Sind die Überschneidungen gering, kann ein föderierter Datenaustausch mit gemeinsamen Identitäts- und Definitionsregeln ausreichend sein. Entscheidend ist der Integrationsbedarf, nicht allein die Anzahl der beteiligten Abteilungen.

Bevor eine Plattform ausgewählt wird, muss zwischen zwei Zielen unterschieden werden: Eine physisch zentrale Datenplattform bündelt Datenhaltung oder Verarbeitung. Eine logisch einheitliche Datenbasis sorgt dagegen dafür, dass verteilte Daten mit gemeinsamen Identifikatoren, Referenzen und Definitionen interpretiert werden können.

Ein Unternehmen kann also eine einheitliche Datensicht besitzen, obwohl CRM, ERP und Warenwirtschaft weiterhin eigenständige Datenbanken verwenden.

Für die Architekturentscheidung hilft folgende Gegenüberstellung:

Keine Architektur ersetzt fachliche Zuständigkeiten. Ohne geklärte Data Ownership werden widersprüchliche Kundenadressen oder Artikelklassifikationen lediglich auf eine neue Infrastruktur übertragen.

Auch die ISO 8000-Reihe setzt bei der Qualität von Stammdaten und deren Austausch an. Die offizielle Beschreibung der Norm ISO 8000-100 zur Stammdatenqualität behandelt unter anderem Qualitätsmetriken sowie Anforderungen an Daten und Organisationen an den Schnittstellen von Stammdatenmanagementsystemen. Daraus folgt keine Verpflichtung zur physischen Zentralisierung.

Statt alle Systeme gleichzeitig abzulösen, empfiehlt sich eine schrittweise Einführung entlang fachlicher Datenbereiche. Ein erster konsolidierter Kundenstamm oder eine vereinheitlichte Artikelklassifikation kann technische Annahmen, Ownership-Regeln und messbare Qualitätsziele unter realistischen Betriebsbedingungen prüfen.

Unabhängig von der Architektur muss anschliessend geklärt werden, welche Geschäftsobjekte überhaupt gemeinsam verwaltet werden und wo ihre fachlichen Verantwortungsgrenzen liegen.

Wie schneiden Sie Daten in 6 Domänen, damit Ownership klar wird?

Teilen Sie Stammdaten nach stabilen Geschäftsobjekten und nicht nach bestehenden Abteilungen auf. Ein pragmatischer Ausgangspunkt sind sechs Domänen: Kunde, Produkt beziehungsweise Artikel, Lieferant, Mitarbeiter, Finanz- und Kostenstellen sowie Asset und Standort. Jede Domäne erhält eine fachlich verantwortliche Stelle. Überschneidende Attribute werden separat zugeordnet, damit nicht zwei Abteilungen dieselbe Änderung unabhängig freigeben müssen.

Der Unterschied ist wesentlich: Vertrieb, Buchhaltung und Kundendienst können denselben Kunden verwenden. Daraus entstehen aber nicht drei fachlich unabhängige Kundendomänen. Stattdessen handelt es sich um ein gemeinsam identifiziertes Geschäftsobjekt mit unterschiedlichen Verantwortlichkeiten für seine Eigenschaften.

Ein möglicher Zuschnitt für ein mittelgrosses Unternehmen lautet:

Die sechs Domänen sind ein Organisationsvorschlag, kein verbindlicher Standard. Je nach Geschäftsmodell können zusätzliche Bereiche erforderlich sein oder mehrere der genannten Objekte sinnvoll zusammengefasst werden.

Besonders wichtig ist die Ownership auf Attributebene. Bei einem Kunden kann die Finanzabteilung für Rechnungsadresse und zahlungsrelevante Angaben zuständig sein, während der Vertrieb Ansprechpartner und Kundenbeziehungen pflegt. Die Identität des Kunden muss dennoch über beide Bereiche hinweg eindeutig bleiben.

Ein einfacher Test prüft die Qualität des Zuschnitts: Lässt sich für jede kritische Attributänderung genau eine fachliche Entscheidungsinstanz benennen? Falls zwei Abteilungen dieselbe Entscheidung beanspruchen, fehlt entweder eine eindeutige Attributregel oder die Domänengrenze muss überarbeitet werden.

Übermässige Segmentierung ist ebenfalls problematisch. Jede zusätzliche Domäne erzeugt potenzielle Übergaben, Zugriffsregeln und Abstimmungspunkte. Die tatsächlichen fachlichen Konflikte sollten den Zuschnitt bestimmen, nicht eine möglichst detaillierte Architekturzeichnung.

Sobald die Geschäftsobjekte sinnvoll geschnitten sind, braucht es kein umfangreiches Governance-Handbuch. Wichtiger ist eine kleine Zahl eindeutig beschriebener Rollen und Entscheidungswege.

Wie organisieren Sie Data Ownership mit 4 Rollen, ohne Bürokratiemonster?

Data Ownership lässt sich mit vier klar unterschiedenen Rollen organisieren: Data Owner entscheiden über fachliche Regeln, Data Stewards überwachen die operative Datenqualität, Data Custodians betreuen die technische Umsetzung und Data Consumers melden Nutzungsprobleme zurück. Für den Einstieg genügt häufig ein kompakter Verantwortlichkeitssteckbrief pro Domäne. Separate Vollzeitstellen oder zusätzliche Entscheidungsgremien sind dafür nicht grundsätzlich erforderlich.

Die Rollen dürfen nicht miteinander verwechselt werden. Der Data Owner entscheidet beispielsweise, welche Kundenattribute verbindlich sind und wann ein Datensatz gesperrt werden muss. Ein Data Steward prüft Auffälligkeiten, bearbeitet Korrekturaufträge und überwacht vereinbarte Qualitätsindikatoren.

Der Data Custodian stellt unter anderem Schnittstellen, Berechtigungen, Verfügbarkeit und technische Protokollierung sicher. Data Consumers verwenden die bereitgestellten Daten und sollten Fehler über einen festgelegten Rückmeldeweg melden können. Diese vierte Rolle ergänzt die drei zentralen Governance-Rollen, die beispielsweise im britischen Government-Digital-Service-Leitfaden beschrieben werden.

Der Leitfaden des Government Digital Service zur Umsetzung eines Datenqualitätsplans unterscheidet Data Owner, Data Steward und Data Custodian und hält ausdrücklich fest, dass in kleineren Organisationen eine Person mehrere Verantwortlichkeiten übernehmen kann. Seine Empfehlungen sind organisatorische Orientierung, keine für Schweizer Unternehmen verbindliche Vorschrift.

Eine schlanke Governance braucht pro Domäne mindestens einen benannten Owner, eine operative Zuständigkeit, eine Definition kritischer Daten und eine Eskalationsregel. Bei einem Konflikt über die Rechnungsadresse sollte beispielsweise die zuvor bestimmte fachliche Verantwortung für dieses Attribut entscheiden, nicht ein spontan einberufenes Komitee.

Dass Governance nicht allein durch formale Zielbilder entsteht, zeigt auch ein Schweizer Befund:

Für mittelgrosse Unternehmen ist vor allem die eindeutige Verantwortung entscheidend. Ein Data Steward kann beispielsweise zwei Domänen betreuen, sofern genügend Kapazität vorhanden ist und die fachlichen Entscheidungsrechte schriftlich feststehen. Die Kombination von Rollen darf allerdings keine unkontrollierten Interessenkonflikte schaffen.

Besonders anspruchsvoll wird diese Zuordnung, wenn nicht nur Abteilungen, sondern rechtlich eigenständige Tochtergesellschaften unterschiedliche Stammdaten und ERP-Systeme verwenden.

Zentrales MDM oder föderiert: Was passt bei 3 Tochtergesellschaften?

Für drei Tochtergesellschaften mit eigenen ERP-Systemen und lokalen Stammdaten ist häufig ein hybrides MDM-Modell sinnvoll. Gemeinsame Identitäten und unternehmensweit relevante Attribute werden zentral gesteuert, während lokale Erweiterungen in den Gesellschaften verbleiben. Vollständig zentrales MDM bietet sich eher an, wenn Geschäftsprozesse und Stammdaten weitgehend harmonisiert sind und ein gemeinsamer Pflegeprozess organisatorisch durchgesetzt werden kann.

Eine eigenständige Gesellschaft kann beispielsweise lokale Lieferantenbeziehungen, landesspezifische Artikelmerkmale oder eigene buchhalterische Zuordnungen benötigen. Diese Unterschiede verschwinden nicht durch ein zentrales MDM-System. Werden alle Attribute ohne fachliche Differenzierung zentralisiert, erhöht sich der Abstimmungsaufwand.

Ein hybrides Modell trennt deshalb zwischen globalen und lokalen Eigenschaften. Für den Kundenstamm könnten die übergreifende Unternehmensidentität, ein konsolidierter Status und gemeinsame Klassifikationen zentral geführt werden. Lokale Kundennummern, geschäftsspezifische Konditionen oder rechtlich begründete Rechnungsinformationen verbleiben dagegen in der zuständigen Gesellschaft.

Die konkreten Grenzen müssen pro Attribut abgestimmt werden. Nicht jede vermeintlich globale Eigenschaft darf zentral überschrieben werden, insbesondere wenn lokale rechtliche oder operative Anforderungen entgegenstehen.

Ein wichtiger Architekturgrundsatz lautet: Gemeinsame Identität bedeutet nicht identische lokale Nummerierung. Wenn Gesellschaft B den Kunden mit der Nummer 4812 und die Zentrale mit C-1058 führt, kann eine Mapping-Tabelle beide lokalen Schlüssel einer gemeinsamen Identität zuordnen. Eine erzwungene Umnummerierung ist dafür nicht erforderlich.

Die eigentlichen Einführungskosten liegen nicht nur in Software, Integration und Betrieb. Jede gemeinsame Attributdefinition verlangt Abstimmung: Welche Gesellschaft bestimmt die Regel? Welche lokalen Ausnahmen sind erlaubt? Wie werden bestehende Datensätze überführt?

Deshalb sollte der Rollout pro Gesellschaft erst nach fachlicher Harmonisierung, einem geprüften Mapping und einem kontrollierten Abgleich erfolgen. Ein allgemeingültiger Zeitrahmen lässt sich daraus nicht ableiten; er hängt insbesondere von Datenqualität, Prozessunterschieden, Ressourcen und Integrationsumfang ab.

Ob zentral oder föderiert: Sobald zahlreiche Systeme Stammdaten austauschen, werden kontrollierte Importprozesse zu einer wesentlichen Voraussetzung für die Datenintegrität.

Der Import-Fehler, der 10.000 Datensätze falsch überschreibt

Ein fehlerhafter Massenimport kann Tausende Stammdatensätze verändern, wenn die Zuordnung zwischen Importdatei und Zielsystem nicht eindeutig geprüft wird. Besonders kritisch sind fehlende oder falsche Unique Keys, zu tolerante Fuzzy-Matches und unkontrollierte Überschreibregeln. Die Zahl von 10.000 Datensätzen beschreibt hier ein mögliches Schadensszenario, keinen dokumentierten Vorfall.

Bei einem gewöhnlichen Import muss das System entscheiden, ob ein Datensatz neu angelegt, aktualisiert oder zurückgewiesen wird. Fehlt ein belastbarer eindeutiger Schlüssel, wird diese Entscheidung unsicher. Ein Name allein reicht beispielsweise selten aus, um zwei Unternehmen zuverlässig zu identifizieren.

Ein zu grosszügiger Ähnlichkeitsabgleich kann unterschiedliche Geschäftspartner zusammenführen. Ein fehlender Treffer kann dagegen fälschlich als Neuanlage interpretiert werden. Entscheidend ist nicht eine bestimmte Match-Toleranz, sondern das tatsächliche Verhältnis aus richtigen Zuordnungen, nicht erkannten Übereinstimmungen und falschen Treffern.

Ein besonders kritischer Fall entsteht, wenn ein Importprogramm mehrere Zielzeilen anhand eines nicht eindeutigen Feldes aktualisiert und dabei neue Werte auf falsche Geschäftsobjekte schreibt.

Für die technische Prävention sind drei Kontrollen besonders wichtig:

• Dry-Run: Import gegen eine geeignete Kopie oder Testumgebung ausführen und erwartete Neuanlagen, Änderungen, Konflikte sowie zurückgewiesene Sätze vergleichen.
• Concurrency-Prüfung: Versionsnummern oder Optimistic Locking verwenden, damit zwischenzeitlich geänderte Datensätze nicht unbemerkt überschrieben werden.
• Audit-Log und Wiederherstellung: Alte und neue Werte, Importkennung, betroffene Schlüssel und einen geprüften Wiederherstellungspunkt nachvollziehbar dokumentieren.

Ein Dry-Run darf dabei nicht als alleinige Garantie gelten: Ändern sich Daten zwischen Simulation und Produktivlauf, muss auch die tatsächliche Ausführung Konflikte erkennen und kontrolliert behandeln können.

Ist der Fehler bereits eingetreten, sollten weitere schreibende Prozesse kontrolliert angehalten oder isoliert werden, soweit dies betrieblich vertretbar ist. Anschliessend müssen betroffene Datensätze über Protokolle, Importkennungen und Versionshistorien identifiziert werden. Je nach System kann eine selektive Wiederherstellung aus Sicherungen oder Änderungsprotokollen möglich sein.

Eine vollständige Rücksicherung des Systems ist nicht automatisch die beste Lösung. Sie könnte zwischenzeitlich korrekt erfasste Änderungen ebenfalls entfernen. Deshalb müssen Wiederherstellungsumfang und Datenkonsistenz vor dem produktiven Eingriff geprüft werden.

Zur Governance gehört ausserdem eine verbindliche Importfreigabe. Der Data Custodian verantwortet die technische Durchführung, während die fachlich zuständige Stelle den Zweck, die Zuordnung und die erwarteten Änderungen genehmigt. Bei risikoreichen Massenimporten sollte eine dokumentierte Vier-Augen-Prüfung vorgesehen sein.

Die Wiederherstellbarkeit hängt unter anderem davon ab, wie schnell ein Fehler erkannt wird und welche unveränderten Sicherungen, Änderungsprotokolle und historischen Datenstände verfügbar sind. Jeder Vorfall sollte deshalb in verbesserte Importregeln und technische Tests münden.

Solche Kontrollen lassen sich zuerst für wenige, geschäftlich besonders relevante Datenbereiche etablieren. Das begrenzt den Einführungsumfang und schafft eine Grundlage für spätere Erweiterungen.

Mit welchen 2 Stammdaten sollten Sie anfangen, damit der Effekt sofort sichtbar ist?

Kundenstammdaten und Produkt- beziehungsweise Artikelstammdaten sind für viele Unternehmen ein sinnvoller Einstieg. Beide Domänen werden von mehreren Abteilungen benötigt und beeinflussen gut sichtbare Prozesse wie Umsatzreporting, Angebotserstellung und Auftragsabwicklung. Entscheidend ist jedoch die tatsächliche Problemlage: Beginnen Sie mit den zwei Domänen, die messbare Qualitätskonflikte verursachen und bereits eine klare fachliche Verantwortung besitzen.

Der Kundenstamm ist häufig besonders geeignet, weil widersprüchliche Identitäten das Zusammenführen von Vertriebs-, Finanz- und Servicedaten erschweren. Eine konsolidierte Kundensicht kann dazu beitragen, dass Umsätze, offene Forderungen und Kundenbeziehungen über mehrere Systeme hinweg nachvollziehbarer werden.

Beim Artikelstamm betreffen Qualitätsprobleme häufig Klassifikationen, Einheiten, Statusangaben und Produktzuordnungen. Stimmen diese Informationen nicht überein, können Angebotsprozesse, Beschaffung, Lagerbewegungen und produktbezogene Auswertungen zusätzlichen Abstimmungsaufwand verursachen.

Die Auswahl sollte trotzdem nicht allein einer Standardempfehlung folgen. Bewerten Sie die Kandidaten anhand von drei Kriterien:

• Qualitätsproblem: In welcher Domäne treten die meisten relevanten Dubletten, widersprüchlichen Attribute oder fehlerhaften Zuordnungen auf?
• Geschäftswirkung: Welche Fehler beeinträchtigen bereits heute eine wichtige KPI, einen Abschlussprozess oder einen operativen Ablauf?
• Umsetzbarkeit: Gibt es einen fachlich verantwortlichen Owner, verfügbare Datenquellen und einen klar begrenzbaren ersten Anwendungsfall?

Ein Unternehmen mit widersprüchlichen Umsatzreports könnte beispielsweise beim Kundenstamm und bei den zugehörigen KPI-Definitionen beginnen. Falls die grössten Probleme in der Beschaffung liegen, könnten Lieferanten- und Artikelstamm geeigneter sein.

Für die erste Phase sollten vor Beginn messbare Ausgangswerte festgelegt werden: Dublettenquote nach definierter Match-Regel, Zahl offener Datenkonflikte, manuelle Abstimmungszeit und Reproduzierbarkeit ausgewählter Reports. Nach Einführung der neuen Regeln werden dieselben Indikatoren erneut gemessen.

Ein fester Zeitraum bis zu sichtbaren Verbesserungen lässt sich nicht seriös garantieren. Datenvolumen, Qualität der vorhandenen Schlüssel, Systemlandschaft und verfügbare Fachressourcen bestimmen, wie schnell belastbare Ergebnisse entstehen.

Auch die Erweiterung auf weitere Domänen sollte an den Ergebnissen der ersten Phase ausgerichtet werden. Erst wenn neue Datensätze nach denselben Regeln angelegt werden, Zuständigkeiten funktionieren und wichtige Qualitätsindikatoren stabil bleiben, ist die erste Harmonisierung nachhaltig.

Wählen Sie jetzt zwei betroffene Domänen, benennen Sie deren fachliche Owner und dokumentieren Sie pro Domäne einen konkreten Datenkonflikt samt Ausgangswert. Daraus lässt sich ein begrenzter MDM-Pilot ableiten, dessen Nutzen IT und Controlling anhand derselben Kennzahlen überprüfen können.