Stammdaten-Synchronisation: Master Data Management 2026
Kundennummern, die in drei Systemen unterschiedlich lauten. Ein Artikel, der im Shop anders heißt als im ERP. Eine Preisliste, die im CRM noch von letztem Jahr stammt. Solche Inkonsistenzen sind kein Schönheitsfehler, sondern teuer: Schlechte Datenqualität kostet Unternehmen im Schnitt 12,9 Millionen US-Dollar pro Jahr (Gartner, 2021). In Deutschland kämpfen 76 Prozent der Unternehmen mit unzureichender Datenqualität und Datensilos, und nur 6 Prozent schöpfen das Potenzial ihrer Daten wirklich aus (Bitkom Data Economy, 2025). Master Data Management (MDM) setzt genau hier an: Es etabliert für jede Entität einen führenden Datensatz -- den Golden Record -- und synchronisiert ihn konsistent zwischen ERP, Shop und CRM. Dieser Artikel zeigt, wie eine belastbare Stammdaten-Synchronisation technisch funktioniert: von der Single Source of Truth über die regelbasierte Konfliktlösung bis zum messbaren Datenqualitäts-Score.
Das Wichtigste in Kürze
- Master Data Management etabliert für jede Entität einen führenden, bereinigten Datensatz -- den Golden Record -- statt mehrere widersprüchliche Versionen in ERP, Shop und CRM.
- Konflikte zwischen Systemen werden nicht erzwungen, sondern über dokumentierte Survivorship-Regeln pro Attribut gelöst; uneindeutige Fälle landen in einer Prüfliste.
- Datenqualität wird über einen messbaren Score aus Dimensionen wie Vollständigkeit, Eindeutigkeit und Konsistenz sichtbar und gezielt verbesserbar.
- Data Governance regelt, wer welche Daten ändern darf -- ohne diesen organisatorischen Rahmen bleibt jede technische Synchronisation Stückwerk.
- Die einmalige Erstbereinigung vor dem Go-Live entscheidet darüber, ob der laufende Abgleich verlässliche Ergebnisse liefert.
Was Stammdaten sind und warum sie auseinanderlaufen
Stammdaten sind die langlebigen Kerndaten eines Unternehmens: Kunden, Lieferanten, Produkte, Preise, Konten. Im Gegensatz zu Bewegungsdaten wie Bestellungen oder Buchungen ändern sie sich selten, werden aber von nahezu jedem Prozess gelesen. Genau deshalb ist ihre Konsistenz so entscheidend -- und genau deshalb laufen sie in gewachsenen Systemlandschaften regelmäßig auseinander.
Der Grund ist strukturell. Jedes System pflegt seine eigene Sicht auf dieselbe Entität: Das ERP kennt den Kunden als Debitor mit Zahlungsbedingungen, das CRM als Kontakt mit Ansprechpartnern, der Shop als Konto mit Lieferadresse. Wird ein Attribut in einem System geändert, bleibt es in den anderen oft veraltet. Mit jeder weiteren Schnittstelle steigt die Zahl möglicher Abweichungen -- in Deutschland kämpfen bereits 76 Prozent der Unternehmen mit Datensilos und unzureichender Qualität (Bitkom Data Economy, 2025). Studien beziffern den Anteil von Dubletten in Kontaktdatenbanken auf 15 bis 30 Prozent (Experian), bei automatisierten Integrationen kann er noch deutlich höher liegen (Plauti, 2024). KPMG und Forrester berichten zudem, dass nur rund ein Drittel der Entscheider den aus ihren Daten gewonnenen Analysen wirklich vertraut und nur 10 Prozent ihr Datenqualitätsmanagement als hervorragend einstufen (KPMG, 2018).
Stammdaten sind die Voraussetzung jeder Integration
Single Source of Truth: der Golden Record
Das Kernprinzip von MDM ist die Single Source of Truth: Für jede Entität existiert genau ein verbindlicher, bereinigter Datensatz -- der Golden Record. Er entsteht nicht dadurch, dass man ein System zum alleinigen Master erklärt, sondern dadurch, dass die besten verfügbaren Werte aus allen Quellen zu einem konsolidierten Datensatz zusammengeführt werden. Welches System für welches Attribut die Hoheit hat, regelt die Data Governance.
In der Praxis haben sich drei Architekturmuster etabliert. Beim Registry-Stil bleibt jedes System Eigentümer seiner Daten, der MDM-Hub hält nur die Verknüpfungen und eine Kreuzreferenztabelle. Beim konsolidierenden Stil werden Daten in einen zentralen Hub repliziert und dort bereinigt, ohne sie zurückzuschreiben. Beim zentralen Stil ist der Hub das führende System, das Änderungen aktiv an alle angebundenen Systeme verteilt. Welches Muster passt, hängt von der Systemlandschaft ab -- eine Middleware bildet in allen Fällen die Drehscheibe.
Registry-Stil
Quellsysteme bleiben Eigentümer, der Hub hält nur Verknüpfungen und Kreuzreferenzen. Geringer Eingriff, aber kein bereinigter Golden Record im Hub.
Konsolidierend
Daten werden zentral zusammengeführt und bereinigt, ohne Rückschreiben. Ideal für Reporting und Analyse, weniger für operative Verteilung.
Zentral verteilend
Der Hub ist führend und verteilt geprüfte Änderungen aktiv an ERP, Shop und CRM. Höchste Konsistenz, höchster Abstimmungsbedarf.
Die drei Domänen: Kunden, Produkte, Preise
Eine Stammdaten-Synchronisation betrifft selten nur eine Datenart. In der Praxis sind es vor allem drei Domänen, die zwischen ERP, Shop und CRM konsistent gehalten werden müssen -- und jede hat ihre eigene Logik.
Kundenstammdaten verbinden Debitor, Kontakt und Shop-Konto. Hier geht es um eindeutige Identifikation, Dublettenvermeidung und die Frage, welches System bei Adresse, Zahlungsbedingungen oder Einwilligungen die Hoheit hat. Produktstammdaten verknüpfen Artikelnummer, Bezeichnung, Attribute und Medien -- oft im Zusammenspiel mit einem PIM-System als führender Quelle für beschreibende Daten. Preisdaten schließlich sind besonders heikel, weil Staffeln, Kundengruppen und Währungen ins Spiel kommen und Fehler hier unmittelbar Umsatz kosten -- vor dem Hintergrund, dass schlechte Datenqualität ein Unternehmen im Schnitt 12,9 Millionen US-Dollar jährlich kostet (Gartner, 2021).
| Domäne | Typischer Master | Kritisches Attribut |
|---|---|---|
| Kunden | ERP (Debitor) bzw. CRM | Adresse, Zahlungsbedingungen, Einwilligung |
| Produkte | PIM bzw. ERP | Artikelnummer, Bezeichnung, Klassifikation |
| Preise | ERP | Staffelpreis, Kundengruppe, Währung |
| Konten | ERP bzw. DATEV | Kontonummer, Steuerschlüssel |
Die Festlegung des führenden Systems pro Attribut ist keine technische, sondern eine fachliche Entscheidung. Sie wird einmal sauber getroffen und im Mapping hinterlegt. Ein robustes Daten-Mapping zwischen ERP und Shop ist dabei die handwerkliche Grundlage jeder Synchronisation und wird zentral in der Integrationsschicht gepflegt.
Konfliktlösung: Wenn zwei Systeme widersprechen
Der schwierigste Teil jeder Stammdaten-Synchronisation ist der Moment, in dem zwei Systeme für dasselbe Attribut unterschiedliche Werte melden. Wird die Adresse im CRM und parallel im ERP geändert -- welcher Wert gewinnt? Ohne klare Regel entsteht entweder ein endloses Hin- und Herschreiben oder ein stiller Datenverlust. Beides ist gefährlich.
Die Lösung sind sogenannte Survivorship-Regeln: pro Attribut definierte Vorrangregeln, die festlegen, welcher Wert überlebt. Üblich sind vier Strategien: Source-Priorität (ein bestimmtes System gewinnt stets für dieses Attribut), Recency (der jüngste Zeitstempel gewinnt), Vollständigkeit (der gefülltere Wert gewinnt) und Vertrauensscore (das System mit der höchsten Datenqualität für dieses Feld gewinnt). Entscheidend ist, dass diese Regeln nachvollziehbar dokumentiert und versioniert sind.
customer:
address:
strategy: source_priority
order: [erp, crm, shop]
email:
strategy: recency # juengster Zeitstempel gewinnt
payment_terms:
strategy: source_priority
order: [erp]
consent_marketing:
strategy: source_priority
order: [crm]
conflict_fallback: review_queue # bei Gleichstand: nichts ueberschreibenIm Zweifel nicht überschreiben
Datenqualität messbar machen
Datenqualität ist kein Bauchgefühl, sondern messbar. Ein belastbares MDM-Setup berechnet einen Datenqualitäts-Score aus klar definierten Dimensionen und macht damit sichtbar, wo die Stammdaten stehen und wo sie sich verbessern. Das ist nicht nur eine Kennzahl fürs Management, sondern die Grundlage, um Survivorship-Regeln gezielt nachzuschärfen.
Vollständigkeit
Sind alle Pflichtfelder gefüllt? Fehlende Steuernummern oder Lieferadressen blockieren später ganze Prozesse.
Eindeutigkeit
Existiert jede Entität genau einmal? Dubletten machen je nach Quelle 15 bis 30 Prozent der Kontaktdaten aus (Experian).
Validität
Entsprechen Werte ihrem Format? Eine ungültige USt-IdNr. oder PLZ fällt sonst erst beim Versand oder bei der Rechnung auf.
Konsistenz
Stimmen Werte über Systeme hinweg überein? Genau diese Dimension hebt eine Stammdaten-Synchronisation gezielt an.
Aktualität
Wie alt ist der Wert? Veraltete Preise oder Adressen sind formal valide, aber inhaltlich falsch.
Referenzielle Integrität
Verweisen Fremdschlüssel auf existierende Datensätze? Verwaiste Referenzen brechen Auswertungen und Buchungen.
In Projekten setzen wir auf einen gewichteten Score je Domäne, der nach jedem Synchronisationslauf neu berechnet wird. Schon das bloße Sichtbarmachen verändert das Verhalten: Sobald die Pflege messbar wird, sinkt der Dublettenanteil spürbar. Der wirtschaftliche Hebel ist erheblich, denn schlechte Datenqualität bindet schätzungsweise 15 bis 25 Prozent des Umsatzes (MIT Sloan Management Review). Realistisch lassen sich nach einer Bereinigung Score-Werte im hohen Neunzigerbereich halten (Projekterfahrung) -- nicht durch einmalige Aktionen, sondern durch laufende Validierung im Datenfluss.
Eine Synchronisation kann nur so gut sein wie die Daten, die sie verteilt. Wer schlechte Stammdaten schneller verteilt, hat am Ende nur schneller schlechte Daten überall.
Data Governance: Wer darf was ändern?
Technik allein löst kein Stammdatenproblem. Genauso wichtig ist die Data Governance -- der organisatorische Rahmen, der festlegt, wer für welche Daten verantwortlich ist, wer sie ändern darf und nach welchen Regeln. Genau an dieser Stelle scheitern viele Initiativen: Der Bitkom nennt fehlende Data Governance und mangelnde Datenstrategie als Hauptgründe, warum das Potenzial der Daten ungenutzt bleibt -- nur 6 Prozent der deutschen Unternehmen schöpfen es heute aus (Bitkom Data Economy, 2025).
- Data Ownership: Pro Domäne und idealerweise pro Attribut ist eine verantwortliche Rolle benannt -- der Data Owner entscheidet über Regeln und Hoheit.
- Pflegeprozesse: Klare Abläufe, wo ein Datensatz angelegt und geändert wird, verhindern, dass dieselbe Entität an drei Stellen parallel entsteht.
- Validierungsregeln: Format- und Plausibilitätsprüfungen greifen möglichst früh, idealerweise schon bei der Eingabe im führenden System.
- Audit-Trail: Jede Änderung am Golden Record wird mit Quelle, Zeitstempel und auslösender Regel protokolliert -- nachvollziehbar und revisionssicher.
- DSGVO-Bezug: Gerade bei Kundendaten gehören Einwilligungen, Löschfristen und Auskunftsrechte in das Governance-Modell.
Der Audit-Trail ist nicht nur Pflichtprogramm, sondern praktischer Helfer: Bei einer unerwarteten Änderung lässt sich lückenlos nachvollziehen, welches System welchen Wert wann geliefert hat und welche Survivorship-Regel gegriffen hat. Das macht die Fehlersuche erheblich kürzer und ist eng mit einer sauberen Fehlerbehandlung in den Schnittstellen verzahnt.
Technische Umsetzung der Synchronisation
Auf der technischen Ebene wird die Synchronisation über APIs und ein klar definiertes Mapping realisiert. Der MDM-Hub kommuniziert mit jedem System über dessen Schnittstelle -- per REST- oder GraphQL-API für moderne Systeme, per Dateiimport oder spezialisiertem Konnektor für ältere ERP-Systeme. Änderungen werden idealerweise ereignisgesteuert verteilt: Ein Webhook oder eine Event-Nachricht meldet die Änderung, der Hub konsolidiert und schreibt nur das geänderte Attribut zurück.
Zwei Eigenschaften sind dabei nicht verhandelbar. Erstens Idempotenz: Wird dieselbe Änderung versehentlich zweimal verteilt, darf kein inkonsistenter Zustand entstehen. Zweitens ein delta-basiertes Vorgehen: Statt bei jedem Lauf alle Datensätze zu übertragen, werden nur tatsächliche Änderungen synchronisiert. Das hält die Last gering und macht Konflikte überhaupt erst erkennbar. Bei großen Datenmengen ergänzt ein periodischer Vollabgleich das Delta-Verfahren, um schleichende Abweichungen zu fangen. Der Aufwand lohnt sich, denn die Dublettenquote in Kontaktdaten liegt ohne aktive Bereinigung häufig bei 15 bis 30 Prozent (Experian).
Klein anfangen, sauber wachsen
Projektablauf eines MDM-Vorhabens
Ein MDM-Projekt ist zu gleichen Teilen ein Daten-, ein Technik- und ein Organisationsprojekt. Der bewährte Ablauf folgt fünf Phasen, wobei die fachliche Abstimmung mindestens so viel Zeit braucht wie die technische Umsetzung.
Die fünf Phasen eines MDM-Vorhabens
- 1
Daten-Audit
Erhebung der Quellsysteme, Datenmodelle und des aktuellen Datenqualitäts-Scores. Wo entstehen Dubletten, wo widersprechen sich Werte?
- 2
Governance festlegen
Bestimmung der Data Owner, der führenden Systeme je Attribut und der Survivorship-Regeln gemeinsam mit den Fachbereichen.
- 3
Erstbereinigung
Deduplizierung, Normalisierung und Validierung des Bestands, bevor die laufende Synchronisation startet.
- 4
Anbindung und Mapping
Verbindung der Systeme über APIs oder Konnektoren, Umsetzung des Mappings und der Konfliktregeln in der Middleware.
- 5
Go-Live und Monitoring
Produktivbetrieb mit laufender Überwachung des Datenqualitäts-Scores und einer Prüfliste für die nicht eindeutig lösbaren Fälle.
- Daten-Audit: Erhebung der Quellsysteme, Datenmodelle und des aktuellen Datenqualitäts-Scores. Wo entstehen Dubletten, wo widersprechen sich Werte?
- Governance festlegen: Bestimmung der Data Owner, der führenden Systeme je Attribut und der Survivorship-Regeln gemeinsam mit den Fachbereichen.
- Erstbereinigung: Deduplizierung, Normalisierung und Validierung des Bestands, bevor die laufende Synchronisation startet.
- Anbindung und Mapping: Verbindung der Systeme über APIs oder Konnektoren, Umsetzung des Mappings und der Konfliktregeln in der Middleware.
- Go-Live und Monitoring: Produktivbetrieb mit laufender Überwachung des Datenqualitäts-Scores und einer Prüfliste für die nicht eindeutig lösbaren Fälle.
Der Hebel liegt in der Erstbereinigung
Der wirtschaftliche Nutzen ist greifbar: Weniger Dubletten bedeuten weniger Fehlversände, korrekte Preise verhindern Margenverluste, und ein konsistenter Kundenstamm beschleunigt Vertrieb und Service. Vor dem Hintergrund eines MDM-Marktes, der für 2026 je nach Quelle auf rund 21 bis 30 Milliarden US-Dollar geschätzt wird (Mordor Intelligence, 2026; Persistence Market Research, 2026) und in dem cloudbasierte Bereitstellungen den größeren Anteil ausmachen (Fortune Business Insights, 2026), ist der Trend zur konsolidierten Datenbasis kein kurzfristiger Effekt, sondern eine strukturelle Entwicklung. In über 50 Integrationsprojekten (Projekterfahrung) hat sich gezeigt, dass die saubere Stammdatenbasis sehr häufig der unterschätzte, aber entscheidende Erfolgsfaktor ist.