SH

Sascha Hess

xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

NOTFALL-KIT – SQL SERVER 2026

SQL Server

Master Data Management

Ein Datensatz, eine Wahrheit, eine Quelle — für das gesamte Unternehmen

1

MDM-Grundkonzepte

Stammdaten-Domänen, Golden Record, Hub-Architektur

2

Dubletten-Management

Erkennen, zusammenführen, dauerhaft verhindern

3

MDM-Architekturmuster

Registry, Consolidation, Coexistence, Centralized

4

Governance-Framework

Rollen, Prozesse, Regeln für dauerhaft saubere Stammdaten

5

30-Tage-MDM-Kickoff

Erste MDM-Strukturen in einem Monat produktiv

WAS SIE IN DIESEM KIT ERWARTEN DÜRFEN

■  MDM-Architektur — Vier Muster erklärt mit Entscheidungsrahmen für den Mittelstand.

■  Dubletten-Management — Erkennung, probabilistisches Matching, Zusammenführung mit SQL.

■  Survivorship-Regeln — Welche Attribute aus welcher Quelle den Golden Record bilden.

■  Governance-Framework — Rollen, Prozesse und Review-Zyklen die wirklich funktionieren.

■  30-Tage-Kickoff — Erste MDM-Strukturen für die wichtigste Domäne in einem Monat.

ZIEL DIESES KITS

Nach dem Lesen und Umsetzen dieses Kits haben Sie ein klares MDM-Konzept für Ihre wichtigste Stammdaten-Domäne, einen produktiven Dubletten-Erkennungsprozess, definierte Survivorship-Regeln, eine Governance-Struktur und messbare MDM-KPIs — ohne Enterprise-MDM-Software.

STAMMDATEN (Master Data):

  Geschäftsobjekte die mehrfach genutzt werden und relativ stabil sind.

  Abgrenzung: NICHT Transaktionsdaten (Bestellungen, Buchungen)

              NICHT Referenzdaten (Währungen, Länder, Einheiten)

  Typische Domänen: Kunden, Lieferanten, Artikel, Mitarbeiter,

                    Kostenstellen, Standorte

STAMMDATEN-DOMÄNE:

  Eine Gruppe fachlich zusammengehöriger Stammdaten.

  Je Domäne: eigene Regeln, eigene Owner, eigener Prozess.

  Beispiel: "Kundenstamm" umfasst Firmen UND Ansprechpartner UND Adressen.

GOLDEN RECORD:

  Der eine, maßgebliche Datensatz eines Objekts — die "eine Wahrheit".

  Wird aus mehreren Quellen synthetisiert nach definierten Regeln.

  Alle Systeme sollen den Golden Record konsumieren — nicht eigene Kopien.

MASTER HUB:

  Das führende System für eine Stammdaten-Domäne.

  Alle Änderungen gehen durch den Hub — nie direkt in Downstream-Systeme.

  Beispiel: ERP = Master Hub für Kundenstamm →

            CRM und Webshop erhalten Repliken.

CROSS-REFERENCE (XREF):

  Tabelle die lokale IDs verschiedener Systeme für dasselbe Objekt verbindet.

  ERP-KundenNr 10045 = CRM-AccountID A-8823 = Webshop-CustomerID C99012.

  Ohne XREF ist keine systemübergreifende Konsolidierung möglich.

Stammdaten

Wiederverwendet, relativ stabil

Kunden, Artikel, Lieferanten

Hoch — Kernthema MDM

Transaktionsdaten

Einmalig, zeitlich gebunden

Bestellungen, Rechnungen, Buchungen

Niedrig — nutzen Stammdaten

Referenzdaten

Systemweit, sehr stabil

Länder, Währungen, Einheiten

Mittel — oft vergessen

Metadaten

Daten über Daten

Felddefinitionen, Regeln

Mittel — → Datenkatalog-Kit

DIMENSION 1 — VOLLSTÄNDIGKEIT:

  Sind alle Pflichtattribute für jedes Objekt befüllt?

  KPI: Vollständigkeitsquote je Domäne (Ziel: 100 % Pflichtfelder)

DIMENSION 2 — EINDEUTIGKEIT:

  Existiert jedes Objekt nur einmal im System?

  KPI: Dublettenquote (Ziel: < 1 % bestätigte Dubletten)

DIMENSION 3 — KONSISTENZ:

  Sind dieselben Objekte in allen Systemen gleich beschrieben?

  KPI: Systemübergreifende Übereinstimmungsrate (Ziel: > 98 %)

DIMENSION 4 — AKTUALITÄT:

  Entsprechen die Daten dem aktuellen Stand der Realität?

  KPI: Anteil Datensätze mit Bestätigungsdatum < 24 Monate (Ziel: > 90 %)

MUSTER 1 — REGISTRY STYLE (Verzeichnis)

  Prinzip:  Jedes System behält seine eigenen Daten.

            Ein zentrales Verzeichnis speichert nur IDs und verweist auf Quellen.

  Vorteil:  Minimaler Eingriff in bestehende Systeme.

  Nachteil: Kein echtes Golden Record — nur Verlinkung.

  Einsatz:  Viele heterogene Systeme die nicht vereinheitlicht werden können.

            Erster Schritt bei niedrigem MDM-Reifegrad.

  Beispiel: XREF-Tabelle: ERP-KundenNr ↔ CRM-ID ↔ Webshop-ID

MUSTER 2 — CONSOLIDATION STYLE (Konsolidierung)

  Prinzip:  Daten aus allen Quellen fließen in einen zentralen Hub.

            Hub berechnet Golden Record. Quellen bleiben unverändert.

  Vorteil:  Gute Analytics-Basis. Keine Eingriffe in Quellsysteme.

  Nachteil: Kein Write-Back — Quellen werden nicht verbessert.

  Einsatz:  Analytics und BI als primärer Use Case.

            Mehrere Quellen die nicht vereinheitlicht werden können/sollen.

MUSTER 3 — COEXISTENCE STYLE (Koexistenz)

  Prinzip:  Zentraler Hub + lokale Kopien. Hub sendet Verbesserungen zurück.

            Jedes System kann bestimmte Attribute weiter selbst pflegen.

  Vorteil:  Echter Golden Record UND lokale Autonomie.

  Nachteil: Konfliktlösung bei konkurrierenden Updates komplex.

  Einsatz:  Mittelstand mit ERP + CRM + Webshop ohne vollständige Zentralisierung.

            EMPFEHLUNG für die meisten KMU-Szenarien.

MUSTER 4 — CENTRALIZED STYLE (Zentralisierung)

  Prinzip:  Ein zentrales System ist die einzige Quelle. Alle anderen lesen.

            Änderungen NUR im zentralen System. Vollständiges Single Source of Truth.

  Vorteil:  Maximale Konsistenz und Kontrolle.

  Nachteil: Hoher Implementierungsaufwand. Alle Systeme müssen angepasst werden.

            Kultureller Widerstand: Abteilungen verlieren Datenkontrolle.

  Einsatz:  Neue ERP-Einführungen. Große Konzerne. Wenn IT-Governance stark.

ENTSCHEIDUNGSBAUM:

Frage 1: Wie viele Systeme enthalten Stammdaten einer Domäne?

  1 System → Kein MDM nötig: ERP ist de facto Master Hub → Standardprozesse

Frage 2: Werden Stammdaten in mehreren Systemen GEÄNDERT?

  Nein (nur ERP schreibt, Rest liest) → Centralized Style (ERP als Hub)

  Ja (mehrere Systeme schreiben) → weiter zu Frage 3

Frage 3: Können Quellsysteme für Write-Back angepasst werden?

  Nein → Consolidation Style (Hub nur für Analytik)

  Ja, mit Aufwand → Coexistence Style (empfohlen für KMU)

Frage 4: Ist ein dediziertes MDM-System budget-fähig?

  Nein → Coexistence mit SQL Server Hub (dieses Kit)

  Ja → Kommerzielle MDM-Tools prüfen (Kapitel 9)

COEXISTENCE-ARCHITEKTUR FÜR DEN MITTELSTAND:

QUELLSYSTEME          MDM-HUB              DOWNSTREAM

  ┌─────────┐          ┌─────────────┐      ┌──────────┐

  │  ERP    │──────→   │  Golden     │─────→│   CRM    │

  │(Master) │          │  Record     │      └──────────┘

  └─────────┘          │  Database   │      ┌──────────┐

  ┌─────────┐          │             │─────→│  Webshop │

  │  CRM    │──────→   │  + XREF     │      └──────────┘

  │(Ergänz.)│          │  + History  │      ┌──────────┐

  └─────────┘          │  + Lineage  │─────→│  BI / DWH│

  ┌─────────┐          └─────────────┘      └──────────┘

  │ Webshop │──────→         ↑

  │(Erfassg)│          DQ-Checks

  └─────────┘          Dedup-Engine

                       Survivorship-Rules

WRITE-BACK: Hub sendet verbesserte/bereinigte Daten zurück an ERP.

            ERP bleibt Master — Hub verbessert, nicht ersetzt.

KUNDENSTAMM — CHARAKTERISTIKA:

TYPISCHE OBJEKTE:

  Firma (juristische Person) + Ansprechpartner + Adresse(n) + Kontakte

  → Hierarchie beachten: Konzern → Tochtergesellschaft → Standort → Kontakt

TYPISCHE QUALITÄTSPROBLEME:

  → Dubletten: "Müller GmbH" und "Müller GmbH & Co. KG" (oft dieselbe Firma)

  → Adress-Verfall: Umzüge werden nicht ins ERP übertragen

  → Ansprechpartner-Veraltung: Person gewechselt, Datensatz bleibt

  → Rechtsform-Inkonsistenz: GmbH vs. GmbH & Co. KG vs. ohne Rechtsform

  → Fremdsprachige Schreibweisen: Ü/ue, ß/ss

PFLICHTATTRIBUTE (Golden Record Minimum):

  Firmenname (normalisiert), Rechtsform, Straße, PLZ, Ort, Land,

  Kundennummer, Steuernummer/USt-ID, Zahlungsbedingung,

  Data Owner, Letzte Bestätigung

DSGVO-RELEVANZ: Hoch

  Ansprechpartner sind personenbezogene Daten.

  Auskunftsrecht nach Art. 15 DSGVO muss systemübergreifend erfüllbar sein.

ARTIKELSTAMM — CHARAKTERISTIKA:

TYPISCHE OBJEKTE:

  Artikel + Varianten (Farbe, Größe) + Einheiten + Preise + Klassifikation

TYPISCHE QUALITÄTSPROBLEME:

  → Doppelte Artikel mit unterschiedlichen Nummern aber gleichem Produkt

  → Fehlende Klassifikation (Warengruppe, Produktgruppe)

  → Inkonsistente Einheiten: "Stück" vs. "St." vs. "pc"

  → Fehlende oder veraltete Einstandspreise

  → Stücklisten-Inkonsistenz: Komponente ohne Einstandspreis

PFLICHTATTRIBUTE (Golden Record Minimum):

  Artikelnummer, Bezeichnung (DE/EN), Warengruppe, Einheit,

  Einstandspreis, Verkaufspreis, GTIN/EAN (falls vorhanden),

  Hersteller-Artikelnummer, Aktiv-Status, Data Owner

BESONDERHEIT:

  Varianten-Handling: Elternartikel vs. Variantenartikel klar trennen.

  Keine Variante als eigenen Artikel anlegen — sonst explodiert der Stamm.

LIEFERANTENSTAMM — CHARAKTERISTIKA:

TYPISCHE QUALITÄTSPROBLEME:

  → Veraltete Bankverbindungen (Zahlungsrisiko!)

  → Fehlende USt-IDs (steuerrechtliches Risiko)

  → Inaktive Lieferanten nicht gesperrt (Bestellungen gehen weiter)

  → Ansprechpartner nicht aktuell (Reklamationen versanden)

PFLICHTATTRIBUTE (Golden Record Minimum):

  Lieferantenname, Rechtsform, Adresse, IBAN/BIC (aktuell bestätigt),

  USt-ID, Zahlungsbedingung, Lieferzeit, Data Owner,

  Letzte Bankdaten-Bestätigung (Datum!)

BESONDERHEIT — IBAN-FRAUD-PRÄVENTION:

  Bankverbindungsänderungen sind ein häufiges Angriffsszenario.

  Protokoll: Jede IBAN-Änderung → Bestätigung per Telefon mit bekannter Nummer.

  4-Augen-Prinzip: Erfassung ≠ Freigabe der neuen Bankverbindung.

-- MDM-Hierarchie: Konzern → Tochter → Standort → Ansprechpartner

CREATE TABLE dbo.MDM_Kunden_Hierarchie (

    KnotenID        INT IDENTITY PRIMARY KEY,

    Eltern_KnotenID INT REFERENCES dbo.MDM_Kunden_Hierarchie(KnotenID),

    Ebene           INT,             -- 1=Konzern, 2=Tochter, 3=Standort, 4=Kontakt

    Ebenen_Typ      NVARCHAR(30),

    ERP_KundenNr    NVARCHAR(50),    -- Referenz ins ERP

    CRM_AccountID   NVARCHAR(50),    -- Referenz ins CRM

    Golden_Record_ID INT,            -- Verweis auf Golden Record

    Ist_Aktiv       BIT DEFAULT 1

);

-- XREF-Tabelle: systemübergreifende ID-Verknüpfung

CREATE TABLE dbo.MDM_XREF (

    XREF_ID         INT IDENTITY PRIMARY KEY,

    Domäne          NVARCHAR(30),    -- 'Kunde', 'Artikel', 'Lieferant'

    Golden_ID       INT NOT NULL,    -- ID im MDM-Hub

    Quell_System    NVARCHAR(50),    -- 'ERP', 'CRM', 'Webshop'

    Quell_ID        NVARCHAR(100),   -- Lokale ID im Quellsystem

    Ist_Master      BIT DEFAULT 0,   -- Welches System ist führend?

    Angelegt_Am     DATETIME2 DEFAULT GETDATE(),

    CONSTRAINT UQ_XREF UNIQUE (Domäne, Quell_System, Quell_ID)

);

-- Golden Record Tabelle (Kundenstamm)

CREATE TABLE dbo.MDM_Golden_Kunden (

    Golden_ID       INT IDENTITY PRIMARY KEY,

    -- Kern-Attribute (aus bester Quelle)

    Firmenname      NVARCHAR(200) NOT NULL,

    Firmenname_Norm NVARCHAR(200),   -- Normalisiert für Matching

    Rechtsform      NVARCHAR(50),

    Strasse         NVARCHAR(200),

    PLZ             NVARCHAR(10),

    Ort             NVARCHAR(100),

    Land            NVARCHAR(3),     -- ISO-Code

    USt_ID          NVARCHAR(20),

    -- MDM-Metadaten

    Quell_System    NVARCHAR(50),    -- Führendes System

    DQ_Score        DECIMAL(5,2),

    Dubletten_Geprueft_Am DATE,

    Letzte_Bestaetigung DATE,

    Data_Owner      NVARCHAR(100),

    Erstellt_Am     DATETIME2 DEFAULT GETDATE(),

    Geaendert_Am    DATETIME2 DEFAULT GETDATE()

);

STRATEGIE 1 — EXAKTES MATCHING:

  Zwei Datensätze mit identischem Feldwert → sofortige Dublette.

  Schnell, kein Fehler, aber geringe Trefferquote.

  Beispiel: Gleiche USt-ID, gleiche IBAN, gleiche EAN

STRATEGIE 2 — NORMALISIERTES MATCHING:

  Feldwerte werden vor dem Vergleich normalisiert.

  Normalisierung: Groß-/Kleinschreibung, Sonderzeichen, Abkürzungen.

  "GmbH & Co. KG" = "GmbH u. Co. KG" = "GmbH&CoKG" nach Normalisierung.

STRATEGIE 3 — PHONETISCHES MATCHING:

  Klingt ähnlich → gleich? Kölner Phonetik / Soundex / Metaphone.

  "Müller" und "Mueller" werden auf denselben Code abgebildet.

  Hohe Trefferquote, aber auch mehr False Positives.

STRATEGIE 4 — PROBABILISTISCHES MATCHING:

  Score aus gewichteten Teil-Vergleichen verschiedener Felder.

  Kein Feld allein entscheidet — kombinierter Wahrscheinlichkeitswert.

  Goldstandard für professionelles MDM.

  Score > 90 % → Auto-Merge; 70-90 % → manuelle Prüfung; < 70 % → keine Dublette.

-- Normalisierungs-Funktion für Firmennamen

CREATE OR ALTER FUNCTION dbo.fn_NormalisiereFirma (@Firma NVARCHAR(500))

RETURNS NVARCHAR(500)

AS BEGIN

    DECLARE @result NVARCHAR(500) = UPPER(LTRIM(RTRIM(@Firma)));

    -- Rechtsformen normalisieren

    SET @result = REPLACE(@result, 'GMBH & CO. KG',   'GMBHCOKG');

    SET @result = REPLACE(@result, 'GMBH & CO KG',    'GMBHCOKG');

    SET @result = REPLACE(@result, 'GMBH U. CO. KG',  'GMBHCOKG');

    SET @result = REPLACE(@result, 'GMBH',            'GMBH');

    SET @result = REPLACE(@result, ' AG',             'AG');

    SET @result = REPLACE(@result, ' E.V.',           'EV');

    -- Umlaute normalisieren

    SET @result = REPLACE(@result, 'Ü', 'UE');

    SET @result = REPLACE(@result, 'Ö', 'OE');

    SET @result = REPLACE(@result, 'Ä', 'AE');

    SET @result = REPLACE(@result, 'ß', 'SS');

    -- Sonderzeichen entfernen

    SET @result = REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(

        @result, '.',''), ',',''), '-',''), '&',''), ' ','');

    RETURN @result;

END;

-- Dubletten-Kandidaten über normalisiertes Matching finden

SELECT

    a.KundenNr AS KundenNr_A,

    a.Firmenname AS Firma_A,

    a.PLZ AS PLZ_A,

    b.KundenNr AS KundenNr_B,

    b.Firmenname AS Firma_B,

    b.PLZ AS PLZ_B,

    -- Normalisierte Namen zum Vergleich

    dbo.fn_NormalisiereFirma(a.Firmenname) AS Norm_A,

    dbo.fn_NormalisiereFirma(b.Firmenname) AS Norm_B,

    -- Match-Score (einfaches Beispiel)

    CASE

        WHEN dbo.fn_NormalisiereFirma(a.Firmenname) =

             dbo.fn_NormalisiereFirma(b.Firmenname)

         AND a.PLZ = b.PLZ THEN 95

        WHEN dbo.fn_NormalisiereFirma(a.Firmenname) =

             dbo.fn_NormalisiereFirma(b.Firmenname) THEN 80

        WHEN a.PLZ = b.PLZ AND LEFT(dbo.fn_NormalisiereFirma(a.Firmenname),6) =

             LEFT(dbo.fn_NormalisiereFirma(b.Firmenname),6) THEN 70

        ELSE 0

    END AS Match_Score

FROM dbo.Kunden a

JOIN dbo.Kunden b ON a.KundenNr < b.KundenNr  -- Jedes Paar nur einmal

    AND a.Aktiv = 1 AND b.Aktiv = 1

WHERE (

    -- Mindestens ein gemeinsames Merkmal als Filter vor dem teuren Vergleich

    a.PLZ = b.PLZ

    OR LEFT(dbo.fn_NormalisiereFirma(a.Firmenname), 6) =

       LEFT(dbo.fn_NormalisiereFirma(b.Firmenname), 6)

)

HAVING CASE

    WHEN dbo.fn_NormalisiereFirma(a.Firmenname) =

         dbo.fn_NormalisiereFirma(b.Firmenname) AND a.PLZ = b.PLZ THEN 95

    WHEN dbo.fn_NormalisiereFirma(a.Firmenname) =

         dbo.fn_NormalisiereFirma(b.Firmenname) THEN 80

    WHEN a.PLZ = b.PLZ AND LEFT(dbo.fn_NormalisiereFirma(a.Firmenname),6) =

         LEFT(dbo.fn_NormalisiereFirma(b.Firmenname),6) THEN 70

    ELSE 0 END >= 70

ORDER BY Match_Score DESC, Firma_A;

-- Dubletten-Kandidaten für manuelle Prüfung speichern

CREATE TABLE dbo.MDM_Dubletten_Kandidaten (

    KandidatID      INT IDENTITY PRIMARY KEY,

    Domäne          NVARCHAR(30),

    ID_A            NVARCHAR(100),    -- Datensatz A

    ID_B            NVARCHAR(100),    -- Datensatz B

    Match_Score     DECIMAL(5,1),

    Match_Methode   NVARCHAR(50),     -- Normalisiert / Phonetisch / Manuell

    Status          NVARCHAR(20) DEFAULT 'Offen',

    -- Offen / Bestätigt / Abgelehnt / Zusammengeführt

    Geprueft_Von    NVARCHAR(100),

    Geprueft_Am     DATETIME2,

    Master_ID       NVARCHAR(100),    -- Welcher Datensatz bleibt?

    Zusammengef_Am  DATETIME2,

    Bemerkung       NVARCHAR(500)

);

-- Offene Dubletten je Data Steward anzeigen

SELECT

    dk.KandidatID,

    dk.Match_Score,

    dk.Match_Methode,

    -- Datensatz A

    ka.Firmenname AS Firma_A,

    ka.PLZ + ' ' + ka.Ort AS Ort_A,

    ka.USt_ID AS UStID_A,

    -- Datensatz B

    kb.Firmenname AS Firma_B,

    kb.PLZ + ' ' + kb.Ort AS Ort_B,

    kb.USt_ID AS UStID_B,

    -- Transaktionshistorie

    (SELECT COUNT(*) FROM dbo.Verkaufsbelege

     WHERE KundenNr = dk.ID_A) AS Belege_A,

    (SELECT COUNT(*) FROM dbo.Verkaufsbelege

     WHERE KundenNr = dk.ID_B) AS Belege_B

FROM dbo.MDM_Dubletten_Kandidaten dk

JOIN dbo.Kunden ka ON dk.ID_A = ka.KundenNr

JOIN dbo.Kunden kb ON dk.ID_B = kb.KundenNr

WHERE dk.Status = 'Offen' AND dk.Domäne = 'Kunde'

ORDER BY dk.Match_Score DESC;

-- Trigger: Neuen Kundensatz auf Dubletten prüfen vor dem Insert

CREATE OR ALTER TRIGGER trg_Kunden_DupCheck

ON dbo.Kunden AFTER INSERT

AS BEGIN

    SET NOCOUNT ON;

    INSERT INTO dbo.MDM_Dubletten_Kandidaten

        (Domäne, ID_A, ID_B, Match_Score, Match_Methode)

    SELECT

        'Kunde',

        i.KundenNr,

        k.KundenNr,

        95,

        'Automatisch bei Anlage'

    FROM inserted i

    JOIN dbo.Kunden k

        ON k.KundenNr != i.KundenNr

        AND k.Aktiv = 1

        AND dbo.fn_NormalisiereFirma(k.Firmenname) =

            dbo.fn_NormalisiereFirma(i.Firmenname)

        AND k.PLZ = i.PLZ;

END;

STRATEGIE 1 — QUELLEN-PRIORITÄT:

  System A hat immer Vorrang vor System B.

  Einfach, vorhersehbar, aber unflexibel.

  Beispiel: ERP-Adresse > CRM-Adresse > Webshop-Adresse

STRATEGIE 2 — AKTUALITÄTSPRIORITAET:

  Das System das zuletzt geändert hat, gewinnt.

  Gut für schnell ändernde Attribute (Telefon, E-Mail).

  Risiko: Qualitätsarme Systeme können gute Daten überschreiben.

STRATEGIE 3 — VOLLSTÄNDIGKEITSPRIORITÄT:

  Der vollständigere Datensatz gewinnt.

  Gut für Adress-Ergänzungen (CRM hat Abteilung, ERP nicht).

  Algorithmus: Attribut mit mehr ausgefüllten Feldern gewinnt.

STRATEGIE 4 — VERTRAUENS-SCORING:

  Jede Quelle erhält pro Attribut-Typ einen Vertrauensscore.

  Golden Record = Attribut aus der Quelle mit höchstem Score.

  Flexibelste Methode — aber höchster Konfigurationsaufwand.

  Beispiel: ERP-Vertrauen für Bankdaten: 95 | CRM: 40 | Webshop: 20

STRATEGIE 5 — ATTRIBUTE SPLITTING:

  Verschiedene Attribute kommen aus verschiedenen Quellen.

  ERP liefert: Kundennummer, Zahlungsbedingung, Steuerdaten.

  CRM liefert: Ansprechpartner, letzte Kontakt, Segmentierung.

  Webshop liefert: Liefer-Präferenzen, Bewertungen.

-- Survivorship Rules: je Domäne und Attribut die bevorzugte Quelle

CREATE TABLE dbo.MDM_Survivorship_Regeln (

    RegelID         INT IDENTITY PRIMARY KEY,

    Domäne          NVARCHAR(30),

    Attribut        NVARCHAR(100),

    Priorität_1     NVARCHAR(50),    -- Bevorzugtes System

    Priorität_2     NVARCHAR(50),    -- Fallback 1

    Priorität_3     NVARCHAR(50),    -- Fallback 2

    Strategie       NVARCHAR(30),    -- Quelle / Aktualität / Vollständigkeit

    Mindest_Wert    NVARCHAR(200),   -- Validierungsregel

    Kommentar       NVARCHAR(500)

);

-- Beispiel-Konfiguration für Kundenstamm

INSERT INTO dbo.MDM_Survivorship_Regeln

    (Domäne, Attribut, Priorität_1, Priorität_2, Priorität_3,

     Strategie, Mindest_Wert, Kommentar)

VALUES

('Kunde','Firmenname',      'ERP','CRM',NULL,    'Quelle','NOT NULL','ERP führt für Rechnungsstellung'),

('Kunde','Rechtsform',      'ERP','CRM',NULL,    'Quelle','NOT NULL','Steuerrechtlich bindend'),

('Kunde','Strasse',         'ERP','CRM','WEB',   'Aktualität','NOT NULL','Lieferadresse: aktuellste Version'),

('Kunde','PLZ',             'ERP','CRM','WEB',   'Aktualität','[0-9]{5}','Nur gültige DE-PLZ'),

('Kunde','Telefon',         'CRM','ERP',NULL,    'Aktualität','NOT NULL','CRM pflegt Kontaktdaten'),

('Kunde','Email',           'CRM','WEB','ERP',   'Aktualität','LIKE %@%.%','CRM hat aktuellste E-Mail'),

('Kunde','Zahlungsbedingung','ERP',NULL,NULL,    'Quelle','NOT NULL','Nur ERP ist verbindlich'),

('Kunde','Kundensegment',   'CRM',NULL,NULL,     'Quelle',NULL,'Nur CRM pflegt Segmentierung');

-- Golden Record aus Quellen nach Survivorship-Regeln berechnen

CREATE OR ALTER PROCEDURE dbo.sp_Berechne_Golden_Record

    @KundenNr_ERP NVARCHAR(50),

    @KundenNr_CRM NVARCHAR(50) = NULL,

    @KundenNr_WEB NVARCHAR(50) = NULL

AS BEGIN

    SET NOCOUNT ON;

    -- Quelldaten zusammenführen

    DECLARE

        @Firma_ERP   NVARCHAR(200), @Firma_CRM   NVARCHAR(200),

        @Strasse_ERP NVARCHAR(200), @Strasse_CRM NVARCHAR(200),

        @PLZ_ERP     NVARCHAR(10),  @Email_CRM   NVARCHAR(200),

        @Tel_CRM     NVARCHAR(50),  @Seg_CRM     NVARCHAR(50);

    -- ERP-Daten holen

    SELECT @Firma_ERP = Firmenname, @Strasse_ERP = Strasse, @PLZ_ERP = PLZ

    FROM dbo.Kunden WHERE KundenNr = @KundenNr_ERP;

    -- CRM-Daten holen (falls vorhanden)

    IF @KundenNr_CRM IS NOT NULL

        SELECT @Firma_CRM = Firmenname, @Strasse_CRM = Strasse,

               @Email_CRM = Email, @Tel_CRM = Telefon,

               @Seg_CRM = Kundensegment

        FROM dbo.CRM_Accounts WHERE AccountID = @KundenNr_CRM;

    -- Golden Record nach Survivorship-Regeln zusammenstellen

    -- Firmenname: ERP hat Priorität

    -- Strasse: aktuellste Version (hier vereinfacht: CRM wenn vorhanden)

    -- Email: CRM hat Priorität

    MERGE dbo.MDM_Golden_Kunden AS target

    USING (SELECT

        COALESCE(@Firma_ERP, @Firma_CRM) AS Firmenname,

        COALESCE(@Strasse_CRM, @Strasse_ERP) AS Strasse,

        @PLZ_ERP AS PLZ,

        @Email_CRM AS Email,

        @Seg_CRM AS Kundensegment

    ) AS source ON (1=0)  -- Immer INSERT (vereinfacht)

    WHEN NOT MATCHED THEN

        INSERT (Firmenname, Strasse, PLZ, Quell_System)

        VALUES (source.Firmenname, source.Strasse, source.PLZ, 'MDM-HUB');

END;

MDM STEERING COMMITTEE (Strategisch, Quartalsweise)

  Mitglieder: GF, IT-Leiter, CFO, Vertriebsleiter

  Aufgaben:   MDM-Strategie, Budget, domänenübergreifende Konflikte

  Entscheide: Neue Domänen, Architekturänderungen, Eskalationen

DATA DOMAIN OWNER (Je Domäne, Fachbereich)

  Wer:    Bereichsleiter der "besitzenden" Abteilung

  Aufgaben:

    ✓ Qualitätsstandards für die Domäne definieren

    ✓ Business-Regeln genehmigen

    ✓ Konfliktlösung bei Attribut-Disputes zwischen Systemen

    ✓ Jährliches Quality Review der Domäne

  Beispiel: Vertriebsleiter = Domain Owner Kundenstamm

            Einkaufsleiter = Domain Owner Lieferantenstamm

DATA STEWARD (Operativer Pfleger, je Domäne)

  Wer:    Erfahrener Sachbearbeiter / Key User

  Aufgaben:

    ✓ Täglich: Dubletten-Arbeitsliste bearbeiten

    ✓ Wöchentlich: Neue undokumentierte Objekte qualifizieren

    ✓ Monatlich: DQ-Score-Bericht erstellen

    ✓ Jährlich: Datensätze zur Bestätigung an Besitzer schicken

  Zeit: 20-30 % Aufbauphase, 10 % laufender Betrieb

MDM-ARCHITEKT (Technisch, IT)

  Wer:    DBA / IT-Spezialist

  Aufgaben: Hub-Betrieb, XREF-Pflege, Matching-Engine, Schnittstellen

LEBENSZYKLUS EINES STAMMDATENSATZES:

ANLAGE → AKTIV → INAKTIV → ARCHIVIERT

ANLAGE (Status: "Neu"):

  Trigger: Manuelle Anlage oder automatischer Import

  Prüfung: Pflichtfelder vollständig? Dubletten vorhanden?

  Aktion:  DQ-Score berechnen, Dubletten-Check starten

  Freigabe: Durch Data Steward oder automatisch bei Score > 90 %

AKTIV (Status: "Freigegeben"):

  Laufende Überwachung: DQ-Score täglich, Dubletten wöchentlich

  Jährliche Bestätigung: Data Owner bestätigt Korrektheit

  Änderungen: Nur durch autorisierte Personen, protokolliert

INAKTIV (Status: "Inaktiv"):

  Trigger: Kein Umsatz/Keine Bestellung > 24 Monate

  Wirkung: Ausgeblendet in Auswahlfeldern, kein neuer Geschäftsverkehr

  Reaktivierung: Durch Data Steward jederzeit möglich

ARCHIVIERT (Status: "Archiviert"):

  Trigger: Keine Bewegung > 5 Jahre, kein offener Posten

  Wirkung: Nur noch für Historiensuche sichtbar

  Löschung: Prüfung durch Datenschutzbeauftragten (DSGVO-Fristen!)

RICHTLINIE: Anlage eines neuen Kunden

GELTUNGSBEREICH: Alle Mitarbeiter die Kundenstammdaten anlegen

REGEL 1 — VOR DER ANLAGE:

  Pflicht-Suche vor jeder Neuanlage: Name + PLZ im ERP und CRM prüfen.

  Bei Treffern: bestehenden Datensatz nutzen oder Duplikat melden.

  Kein Kundensatz ohne vorherige Suche!

REGEL 2 — PFLICHTFELDER:

  Firmenname (vollständig mit Rechtsform), Straße, PLZ, Ort, Land.

  Für Rechnungsstellung zusätzlich: USt-ID oder Steuernummer.

  Keine Anlage mit Platzhaltern ("XXX", "Test", "unbekannt").

REGEL 3 — NAMENSKONVENTION:

  Offizielle Schreibweise laut Handelsregister oder Briefkopf.

  Keine Abkürzungen im Firmennamen (GmbH ausschreiben).

  Umlaute immer als Umlaut (Müller — nicht Mueller).

REGEL 4 — VERANTWORTLICHKEIT:

  Data Steward muss innerhalb von 24h Datensatz prüfen.

  Bei Unklarheiten: Rückfrage beim Anleger — nicht eigenmächtig ändern.

KONSEQUENZEN bei Nichtbeachten:

  Erstverstoß: Hinweis und Korrektur.

  Wiederholung: Schulung und Führungskraft-Gespräch.

SYNCHRONISATIONS-STRATEGIEN:

PUSH (Master → Downstream):

  MDM-Hub sendet Änderungen aktiv an alle Systeme.

  Zeitgesteuert (täglich 02:00) oder ereignisgesteuert (bei Änderung).

  Vorteil: Zentrale Kontrolle, einheitlicher Zeitpunkt.

  Risiko: Downstream-Systeme können nicht "nein sagen".

PULL (Downstream holt sich Updates):

  Systeme holen regelmäßig Änderungen aus dem Hub ab.

  API oder Delta-Tabelle im Hub.

  Vorteil: System entscheidet wann es aktualisiert.

  Risiko: Systeme können vergessen zu holen.

EVENT-DRIVEN (Änderungsereignis triggert Sync):

  Jede Änderung im Hub erzeugt ein Event → alle Subscriber werden benachrichtigt.

  Modernste Methode, minimale Latenz.

  Technologie: SQL Server Service Broker / Webhooks / Message Queue.

EMPFEHLUNG FÜR KMU:

  Einfachste Methode: Delta-Tabelle im Hub + täglicher Pull per SQL Agent.

  Kein Message Broker, keine komplexe Event-Architektur.

-- Delta-Tabelle: alle Änderungen seit letzter Synchronisation

CREATE TABLE dbo.MDM_Sync_Delta (

    DeltaID         INT IDENTITY PRIMARY KEY,

    Domäne          NVARCHAR(30),

    Golden_ID       INT,

    Aktion          NVARCHAR(10),   -- INSERT / UPDATE / DELETE

    Geaendert_Am    DATETIME2 DEFAULT GETDATE(),

    Verarbeitet_Von NVARCHAR(50),   -- Welches System hat abgeholt?

    Verarbeitet_Am  DATETIME2

);

-- Trigger auf Golden Record: Änderungen in Delta schreiben

CREATE OR ALTER TRIGGER trg_MDM_Golden_Kunden_Delta

ON dbo.MDM_Golden_Kunden AFTER INSERT, UPDATE, DELETE

AS BEGIN

    SET NOCOUNT ON;

    INSERT INTO dbo.MDM_Sync_Delta (Domäne, Golden_ID, Aktion)

    SELECT 'Kunde', Golden_ID, 'INSERT' FROM inserted

    WHERE NOT EXISTS (SELECT 1 FROM deleted WHERE Golden_ID = inserted.Golden_ID)

    UNION ALL

    SELECT 'Kunde', Golden_ID, 'UPDATE' FROM inserted

    WHERE EXISTS (SELECT 1 FROM deleted WHERE Golden_ID = inserted.Golden_ID)

    UNION ALL

    SELECT 'Kunde', Golden_ID, 'DELETE' FROM deleted

    WHERE NOT EXISTS (SELECT 1 FROM inserted WHERE Golden_ID = deleted.Golden_ID);

END;

-- Downstream-System holt Delta ab (täglich per SQL Agent Job)

SELECT

    d.DeltaID,

    d.Aktion,

    d.Geaendert_Am,

    g.Firmenname, g.Strasse, g.PLZ, g.Ort, g.Land,

    x.Quell_ID AS CRM_AccountID

FROM dbo.MDM_Sync_Delta d

JOIN dbo.MDM_Golden_Kunden g ON d.Golden_ID = g.Golden_ID

LEFT JOIN dbo.MDM_XREF x ON d.Golden_ID = x.Golden_ID

    AND x.Domäne = 'Kunde' AND x.Quell_System = 'CRM'

WHERE d.Domäne = 'Kunde'

  AND d.Verarbeitet_Von IS NULL  -- Noch nicht vom CRM abgeholt

ORDER BY d.Geaendert_Am;

-- Nach erfolgreichem Sync als verarbeitet markieren

UPDATE dbo.MDM_Sync_Delta

SET Verarbeitet_Von = 'CRM', Verarbeitet_Am = GETDATE()

WHERE Domäne = 'Kunde' AND Verarbeitet_Von IS NULL;

-- Konflikt-Protokoll: wenn zwei Systeme dasselbe Attribut gleichzeitig ändern

CREATE TABLE dbo.MDM_Konflikte (

    KonfliktID      INT IDENTITY PRIMARY KEY,

    Golden_ID       INT,

    Domäne          NVARCHAR(30),

    Attribut        NVARCHAR(100),

    Wert_System_A   NVARCHAR(500),

    System_A        NVARCHAR(50),

    Zeitstempel_A   DATETIME2,

    Wert_System_B   NVARCHAR(500),

    System_B        NVARCHAR(50),

    Zeitstempel_B   DATETIME2,

    Status          NVARCHAR(20) DEFAULT 'Offen',

    Aufgelöst_Durch NVARCHAR(100),

    Aufgelöst_Am    DATETIME2,

    Gewinner_Wert   NVARCHAR(500)

);

-- Wöchentlicher Konflikt-Report an Data Stewards

SELECT

    k.KonfliktID,

    k.Domäne,

    g.Firmenname AS Betroffener_Datensatz,

    k.Attribut,

    k.Wert_System_A, k.System_A, k.Zeitstempel_A,

    k.Wert_System_B, k.System_B, k.Zeitstempel_B,

    DATEDIFF(DAY, k.Zeitstempel_A, GETDATE()) AS Tage_Offen

FROM dbo.MDM_Konflikte k

JOIN dbo.MDM_Golden_Kunden g ON k.Golden_ID = g.Golden_ID

WHERE k.Status = 'Offen'

ORDER BY Tage_Offen DESC;

-- Täglicher MDM-Score je Domäne

CREATE TABLE dbo.MDM_KPI_Tagesdaten (

    KPI_ID          INT IDENTITY PRIMARY KEY,

    Erfasst_Am      DATE DEFAULT CAST(GETDATE() AS DATE),

    Domäne          NVARCHAR(30),

    -- Volumen

    Gesamt_Datensaetze     INT,

    Aktive_Datensaetze     INT,

    -- Vollständigkeit

    Vollstaendigkeit_Pct   DECIMAL(5,1),

    -- Eindeutigkeit

    Offene_Dubletten       INT,

    Dublettenquote_Pct     DECIMAL(5,1),

    -- Aktualität

    Bestaetigt_12Monate    INT,

    Aktualitaetsquote_Pct  DECIMAL(5,1),

    -- Konsistenz

    Sync_Fehler            INT,

    Offene_Konflikte       INT,

    -- Gesamt-Score

    MDM_Score_Pct          DECIMAL(5,1)

);

-- Tägliche Berechnung (SQL Agent Job 06:00)

INSERT INTO dbo.MDM_KPI_Tagesdaten (

    Domäne, Gesamt_Datensaetze, Aktive_Datensaetze,

    Vollstaendigkeit_Pct, Offene_Dubletten, Dublettenquote_Pct,

    Bestaetigt_12Monate, Aktualitaetsquote_Pct,

    Offene_Konflikte, MDM_Score_Pct)

SELECT

    'Kunde',

    COUNT(*) AS Gesamt,

    SUM(CASE WHEN Ist_Aktiv = 1 THEN 1 ELSE 0 END) AS Aktiv,

    -- Vollständigkeit: Pflichtfelder befüllt?

    ROUND(100.0 * SUM(

        CASE WHEN Firmenname IS NOT NULL AND PLZ IS NOT NULL

                  AND Ort IS NOT NULL AND Strasse IS NOT NULL THEN 1 ELSE 0 END

    ) / NULLIF(COUNT(*), 0), 1),

    -- Offene Dubletten

    (SELECT COUNT(*) FROM dbo.MDM_Dubletten_Kandidaten

     WHERE Status = 'Offen' AND Domäne = 'Kunde'),

    -- Dublettenquote

    ROUND(100.0 * (SELECT COUNT(*) FROM dbo.MDM_Dubletten_Kandidaten

        WHERE Status IN ('Offen','Bestätigt') AND Domäne = 'Kunde') /

        NULLIF(COUNT(*), 0), 1),

    -- Aktualität: Bestätigung < 12 Monate

    SUM(CASE WHEN Letzte_Bestaetigung >= DATEADD(MONTH,-12,GETDATE())

             THEN 1 ELSE 0 END),

    ROUND(100.0 * SUM(

        CASE WHEN Letzte_Bestaetigung >= DATEADD(MONTH,-12,GETDATE())

             THEN 1 ELSE 0 END) / NULLIF(COUNT(*),0), 1),

    -- Konflikte

    (SELECT COUNT(*) FROM dbo.MDM_Konflikte

     WHERE Status = 'Offen' AND Domäne = 'Kunde'),

    -- Gesamt-Score (gewichtetes Mittel)

    ROUND(

        0.30 * ROUND(100.0 * SUM(CASE WHEN Firmenname IS NOT NULL

            AND PLZ IS NOT NULL THEN 1 ELSE 0 END) / NULLIF(COUNT(*),0), 1)

      + 0.30 * (100.0 - ROUND(100.0 * (SELECT COUNT(*) FROM dbo.MDM_Dubletten_Kandidaten

            WHERE Status IN ('Offen','Bestätigt') AND Domäne = 'Kunde')

            / NULLIF(COUNT(*), 0), 1))

      + 0.25 * ROUND(100.0 * SUM(CASE WHEN Letzte_Bestaetigung >=

            DATEADD(MONTH,-12,GETDATE()) THEN 1 ELSE 0 END)

            / NULLIF(COUNT(*),0), 1)

      + 0.15 * (100.0 - LEAST(100, (SELECT COUNT(*) FROM dbo.MDM_Konflikte

            WHERE Status = 'Offen' AND Domäne = 'Kunde') * 5.0))

    , 1)

FROM dbo.MDM_Golden_Kunden;

POWER BI MDM-DASHBOARD (4 Seiten):

SEITE 1 — EXECUTIVE OVERVIEW:

  MDM-Score je Domäne (Ampelkarten: Grün ≥95 / Gelb 85-95 / Rot <85)

  Trend MDM-Score 12 Monate je Domäne

  Offene Dubletten und Konflikte (Zähler)

  Letzte Bereinigung: Datum und Anzahl zusammengeführter Datensätze

SEITE 2 — KUNDENSTAMM DETAIL:

  Vollständigkeit je Pflichtfeld (Balken)

  Dublettenquote Trend (Linie)

  Aktualitätsverteilung (< 6 / 6-12 / 12-24 / > 24 Monate)

  Neue Kandidaten diese Woche (Karte)

SEITE 3 — DUPLIKATE & KONFLIKTE:

  Offene Dubletten nach Score-Klasse (> 90 / 70-90)

  Älteste offene Duplikate (Tabelle)

  Offene Konflikte nach System-Paar

  Bearbeitungszeit: Ø Tage von Erkennung bis Auflösung

SEITE 4 — SYSTEME & SYNCHRONISATION:

  Sync-Fehler je System-Verbindung

  Delta-Queue-Größe (unverarbeitete Änderungen)

  XREF-Abdeckung: Wie viele GR haben Verknüpfungen in allen Systemen?

  Letzte erfolgreiche Synchronisation je Downstream-System

VOR DEM START

Scope festlegen: welche Domäne zuerst? Empfehlung: Kundenstamm (höchste Geschäftswirkung). Domain Owner und Data Steward benennen und committen lassen. Datenbankzugriff auf alle relevanten Quellsysteme einrichten (Read-Only für Analyse). Budget für Data-Steward-Zeit sicherstellen: 20-30 % in Aufbauphase.

ERGEBNIS NACH 30 TAGEN

Nach 30 Tagen haben Sie eine vollständige MDM-Infrastruktur für den Kundenstamm: Golden Record Berechnung, automatische Dubletten-Erkennung, gepflegte Survivorship-Regeln, ein laufendes Governance-Framework und einen MDM-Score der täglich gemessen wird. Die wichtigsten Dubletten sind identifiziert — viele schon zusammengeführt.

MDM-Assessment & Konzept

Analyse der Stammdaten-Situation, Architekturempfehlung und Roadmap für den Aufbau eines MDM-Systems — pragmatisch, ohne Enterprise-Lizenzkosten.

MDM-Implementierung

Aufbau eines Golden Record Hubs mit Dubletten-Erkennung, Survivorship-Regeln, XREF und Synchronisation für ERP, CRM und BI.

Datenqualitäts-Assessment

Vollständige Analyse der Stammdatenqualität — DQ-Score je Domäne, Dublettenquote, Bereinigungsplan.

Data Governance Beratung

Aufbau eines schlanken Governance-Rahmens mit MDM-Rollen, Richtlinien und Review-Prozessen für den Mittelstand.

Interim IT-Management

Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, Daten-Strategie.