Match-and-Merge-Regeln
Match-and-Merge-Regeln
Match-and-Merge-Regeln sind das algorithmische Herz jeder MDM-Plattform: Sie entscheiden, welche Datensätze derselben realen Entität (Lieferant, Material, Geschäftspartner) zugeordnet werden, wie diese zu einem Datensatz verschmelzen und welcher Attributwert dabei "überlebt". Ohne saubere Regeln entstehen entweder neue Dubletten oder es überschreibt eine Excel-Importzeile aus 2019 die geprüften SAP-Stammdaten von gestern.
Detaillierte Erklärung
Der Mechanismus zerfällt in drei Teilschritte. Erstens das Matching: Deterministische Regeln vergleichen exakte Werte (USt-IdNr., DUNS-Nummer, Handelsregisterauszug-ID) und liefern hohe Präzision bei sauberen Schlüsseln. Probabilistische Verfahren hingegen arbeiten mit Fuzzy-Logik, Tokenisierung und Scoring-Algorithmen — sie erkennen, dass "Müller GmbH, Industriestr. 12" und "Mueller G.m.b.H., Industriestrasse 12a" mit 94 % Wahrscheinlichkeit derselbe Lieferant sind. IBM InfoSphere und Informatica IDMC kombinieren beide Verfahren typischerweise in einem zweistufigen Pipeline-Modell mit Schwellenwerten zwischen 0,80 und 0,95. Zweitens das Merge: Geclusterte Datensätze werden zu einem Master-Container vereint. Drittens die Survivorship — die eigentliche Streitschlichtung auf Attributebene. Die in der MDM-Literatur (Stibo Systems, Profisee, Reltio) etablierten vier Standardstrategien sind "Most Recent" (jüngster Last-Update-Timestamp gewinnt), "Most Trusted" (Quellsystem-Hierarchie, z. B. SAP > CRM > Excel-Import), "Most Complete" (geringste Anzahl Null-Werte) und "Longest" (längster String, sinnvoll bei Adressen, riskant bei abgekürzten Bezeichnungen). Hybride Konfigurationen sind in der Praxis Standard: Für Bankverbindungen gilt "Most Trusted", für Telefonnummern "Most Recent", für Branchenklassifikationen "Most Complete". Die internationale Norm ISO 8000-110 (2021) definiert das semantische Austauschformat, in dem solche Survivorship-Entscheidungen zwischen Systemen dokumentiert werden müssen — ohne diese Dokumentation ist die spätere Audit-Prüfung nach IDW PS 330 nicht möglich.
Praxisbeispiel (konkretes Einkaufsszenario)
Ein Automobilzulieferer aus Niedersachsen mit 1.420 Mitarbeitenden führt 2025 die Konsolidierung dreier ERP-Systeme nach einer Konzernfusion durch. Ausgangslage: 27.380 Lieferantenstammsätze über SAP ECC, Microsoft Dynamics und ein Legacy-System auf Oracle-Basis. Das MDM-Team konfiguriert in Informatica MDM einen zweistufigen Match: deterministischer Vorlauf auf USt-IdNr. und DUNS, probabilistischer Hauptlauf mit 0,87-Schwellwert auf Name + PLZ + Hausnummer. Ergebnis nach Match: 19.140 Cluster, 6.280 als Dubletten markiert (22,9 % Dublettenrate). Survivorship-Konfiguration: Bankverbindung "Most Trusted" mit Hierarchie SAP > Dynamics > Legacy; Klassifikation eCl@ss "Most Complete"; Kontaktadresse "Most Recent" basierend auf Last-Modified-Zeitstempel; Firmenname "Longest" mit manueller Steward-Review oberhalb 30 Zeichen Differenz. Nach drei Monaten Bereinigung umfasst der konsolidierte Stamm 17.910 aktive Datensätze. Konkrete Wirkung: Bei 38 zuvor zersplitterten Konzernlieferanten zeigt sich ein gebündeltes Volumen von 14,7 Mio. Euro — das Verhandlungsteam erzielt im darauffolgenden Jahresgespräch eine Preissenkung von 3,8 %.
Typische Fehler & Verhandlungskontext
Erstens die blinde Übernahme von Standard-Schwellwerten: Ein 0,90-Threshold mag im Customer-MDM passen, im Lieferantenkontext führt er bei chinesischen Namensvarianten oder bei polnischen Diakritika regelmäßig zu False Negatives. Zweitens "Most Recent" als Universalregel: Wenn ein Vertriebsmitarbeiter eine Kreditorenrechnung scannt und dabei eine veraltete Bankverbindung aktualisiert, wird die geprüfte SAP-Bankverbindung überschrieben — ein klassisches Einfallstor für CEO-Fraud. Drittens fehlende Steward-Review-Schwellen: Ohne manuelle Eskalation bei Match-Scores zwischen 0,70 und 0,85 entstehen entweder unzulässige Verschmelzungen oder ein Backlog von 12.000 ungelösten Fällen. Im Verhandlungskontext gilt: Wer Bündelung über fusionierte Datensätze argumentiert, sollte die Survivorship-Logik dokumentiert vorlegen können — Konzern-Einkäufer der Lieferantenseite hinterfragen die Datenbasis, sobald Volumina von mehreren Stammsätzen aggregiert werden, und das Bundesamt für Sicherheit in der Informationstechnik (BSI) verlangt im IT-Grundschutz-Baustein OPS.1.2.6 explizit eine nachvollziehbare Datenherkunft.
Verwandte Begriffe
[[stammdatenmanagement-mdm]], [[datenqualitaet-einkauf]], [[data-governance-einkauf]], [[dublettenerkennung]], [[datenmodell-einkauf]], [[datenkatalog-einkauf]], [[etl-prozess-einkauf]], [[data-steward]], [[klassifizierungsquote]], [[golden-record]], [[datenbereinigung-einkauf]], [[master-data-governance]], [[datenowner]], [[datenqualitaetsbericht]]