+150 XP

Governance von Produkt-, Standort- und Kundenstammdaten

# Governance von Produkt-, Standort- und Kundenstammdaten

Zwei Lebensmittelketten fusionieren. Achtzehn Monate später kann Finance eine einfache Frage noch immer nicht beantworten: Wie viele Filialen betreibt das fusionierte Unternehmen eigentlich? Filiale 0412 existiert doppelt, einmal in der Nummerierung des Käufers und einmal im Altsystem, beide buchen weiterhin Umsatz. Niemand hat das Duplikat stillgelegt. Jeder Regionalvertriebsbericht seit der Fusion zählt den Umsatz dieses Standorts um einige Prozentpunkte doppelt, und niemandem ist es aufgefallen, weil die Zahl „plausibel aussah“.

Das ist kein hypothetischer Sonderfall. Das ist das Standardergebnis, wenn Stammdaten-Governance als IT-Nachgedanke behandelt wird statt als betriebswirtschaftliche Disziplin. Diese Lektion behandelt die zentralen Stammdatendomänen im Handel, die Qualitätsmetriken, die Probleme wie das oben beschriebene aufdecken, und die Governance-Mechanismen, die sie verhindern.

Was „Stammdaten“ im Handel bedeuten

Stammdaten sind die zentralen, relativ stabilen Referenzdaten, von denen jede Transaktion abhängt. Sie unterscheiden sich von Transaktionsdaten (ein Verkauf, eine Lieferung, eine Rückgabe), die laufend entstehen und auf Stammdatensätze verweisen.

Die drei Domänen, die im Handel und in der Distribution am wichtigsten sind:

Produktstammdaten: SKU-Attribute (Stock Keeping Unit, ein eindeutiger Code für einen verkaufsfähigen Artikel) wie Beschreibung, Kategoriehierarchie, Größe, UPC/EAN-Barcode (Universal Product Code / European Article Number), Mengeneinheit und Lieferantenverknüpfung.

Standortstammdaten: Filial-IDs, Codes der Distributionszentren, Banner-/Format-Flags, geografische Attribute, Verkaufsfläche, Eröffnungs- und Schließungsdaten.

Kundenstammdaten: Loyalty-Programm-IDs, Haushaltszuordnung, Kontakt- und Consent-Daten, Schlüssel zur Kaufhistorie.

Eine vierte, oft unterschätzte Domäne sind Lieferantenstammdaten: die Einheiten, bei denen Sie einkaufen, verknüpft mit Kosten-, Lead-Time- und Compliance-Daten.

Jede Domäne liegt typischerweise in einem „System of Record“, der maßgeblichen Quelle, wird aber in ein Dutzend nachgelagerte Systeme kopiert: Point-of-Sale (POS), Data Warehouse, E-Commerce-Plattform, Planungstool, Loyalty-Engine. Jede Kopie ist eine Gelegenheit für Drift.

Warum Fusionen das Problem so brutal offenlegen

Ein Einzelketten-Händler kann jahrelang mit schlampigen Stammdaten überleben, weil alle unbewusst die Workarounds lernen. Eine Fusion entfernt dieses tribal knowledge von einem Tag auf den anderen.

Häufige Fehlermuster:

  • Doppelte Standort-IDs: zwei Nummerierungssysteme kollidieren, wie im Eingangsbeispiel. Behoben durch eine kanonische Standorttabelle mit einem Crosswalk (Mapping-Tabelle) von Legacy-IDs auf die neue Master-ID.
  • Inkompatible Produkthierarchien: Banner A ordnet „Sprudelwasser“ unter Getränke > Wasser ein; Banner B hängt es unter Getränke > Softdrinks > Wasser. Umsatzvergleiche auf Kategorieebene werden bedeutungslos, bis Hierarchien gemappt oder vereinheitlicht sind.
  • Fragmentierte Kundenidentität: derselbe Käufer hat eine Loyalty-ID im Programm jedes Banners. Ohne einen „Golden Record“ (die einzige vertrauenswürdige, dedupliziertе Version einer Entität) brechen Lifetime Value und Personalisierung zusammen.
  • Abweichende Mengeneinheiten: ein System führt ein Gebinde mit 12, das andere ein Gebinde mit 24, für den nominell gleichen Produktcode.

Das sind stille Fehler. Berichte laufen weiter. Dashboards füllen sich weiter. Die Zahlen driften nur leise von der Wahrheit weg, oft über Monate, weil nichts abstürzt.

Zentrale Dimensionen der Datenqualität zur Prüfung

Datenqualität wird üblicherweise anhand eines Standardsets von Dimensionen bewertet, übernommen aus dem breiteren Data-Management-Feld und kodifiziert in Frameworks wie dem Data Management Body of Knowledge (DMBOK) von DAMA International:

  • Eindeutigkeit: keine doppelten Datensätze für dieselbe real existierende Entität (das Problem mit Filiale 0412).
  • Genauigkeit: spiegelt der Datensatz die Realität wider (korrekte Verkaufsfläche, korrekter Barcode).
  • Vollständigkeit: sind Pflichtfelder gefüllt (jede SKU hat eine Kategorie zugewiesen).
  • Konsistenz: stimmt dasselbe Attribut über Systeme hinweg überein (Produkthierarchie identisch in POS und Warehouse).
  • Aktualität: wird der Datensatz aktualisiert, wenn sich die Realität ändert (eine geschlossene Filiale wird innerhalb von Tagen als geschlossen markiert, nicht in Quartalen).
  • Validität: entspricht der Wert dem erwarteten Format oder Wertebereich (ein UPC hat 12 Stellen, ein Bundesstaatscode ist ein echter Bundesstaat).

Governance-Metriken, die sich zu verfolgen lohnen

Retail-Datenteams überwachen typischerweise ein kleines Set konkreter, prüfbarer Metriken statt abstrakter Qualitätsscores.

Duplikatrate: Anteil der Datensätze in einer Stammdatentabelle, die Duplikate eines anderen Datensatzes sind.

*Rechenbeispiel*: Eine Standort-Stammtabelle hat nach einer Fusion 3.200 Zeilen. Ein Matching-Durchlauf (Vergleich von Adresse, Steuernummer und Geocode) identifiziert 140 Duplikatpaare.

Duplikatrate = 140 / 3.200 = 4,4 %

Das bedeutet, dass etwa 1 von 23 „Filialen“ im System ein Phantom ist, was die Standortanzahl aufbläht und den Umsatz in jedem nach Standort summierten Bericht doppelt zählt.

Attribut-Vollständigkeitsrate: Anteil der gefüllten Pflichtfelder.

Beispiel: Verlangt eine Produkttabelle Kategorie, Unterkategorie, UPC und Mengeneinheit, und bei 92.000 von 100.000 SKUs sind alle vier gefüllt, liegt die Vollständigkeit bei 92 %.

Cross-System-Konsistenzrate: Anteil der Datensätze, bei denen ein gegebenes Attribut über zwei Systeme hinweg übereinstimmt (z. B. POS-Kategorie vs. Kategorie im Warehouse-Management-System). Händler mit Harmonisierungsprojekten nach einer Fusion starten oft unter 70 % und zielen auf über 98 %, bevor sie Legacy-Systeme abschalten.

Golden-Record-Abdeckung: Anteil der Kundentransaktionen, die erfolgreich mit einem einzigen deduplizierten Kundenprofil verknüpft sind, statt verwaist oder über mehrere IDs verteilt zu sein.

Time-to-Correct: durchschnittliche Zeit zwischen der Meldung eines Datenqualitätsproblems und seiner Behebung. Eine gereifte Governance-Funktion verfolgt das wie ein Incident-SLA (Service Level Agreement).

Dies sind Schätzungen typischer Zielbereiche, wie sie in der Retail-Datenmanagement-Praxis Mitte der 2020er genannt werden, keine universellen Standards; tatsächliche Schwellenwerte sollten pro Unternehmen anhand des Geschäftsrisikos festgelegt werden.

Die Governance-Mechanismen, die den Fehler verhindern

Metriken sagen Ihnen, dass es brennt. Governance-Mechanismen verhindern, dass es überhaupt anfängt.

1. Ein System of Record pro Domäne. Entscheiden Sie explizit, welches System die Wahrheit für Standort, Produkt und Kunde besitzt. Alles andere bezieht sie von dort und pflegt keine eigene Version.

2. Master-Data-Management-Tooling (MDM). Plattformen (Beispiele: Informatica MDM, SAP Master Data Governance und Reltio), die Matching, Deduplizierung und Verteilung von Golden Records an nachgelagerte Systeme zentralisieren. In einer Fusion liegen die Crosswalk-Tabellen zwischen Legacy- und neuen IDs im MDM-Tooling.

3. Data-Stewardship-Rollen. Ein namentlich benannter Business Owner (nicht nur IT), der für die Qualität jeder Domäne verantwortlich ist: ein Merchandising-Lead verantwortet die Regeln der Produkthierarchie, ein Real-Estate-/Operations-Lead die Standortdaten.

4. Change Control für Hierarchien. Kategorie- und Standortstrukturen sollten sich nicht ohne geregelten Genehmigungsprozess ändern, denn jeder historische Bericht hängt implizit davon ab, dass die Hierarchie stabil bleibt (oder versioniert wird).

5. Automatisierte Validierungsregeln bei der Erfassung. Weisen Sie einen neuen SKU-Datensatz ohne UPC ab. Markieren Sie einen neuen Filialdatensatz, dessen Adresse das Geocoding nicht besteht. Fehler bei der Erstellung abzufangen ist weitaus günstiger, als sie 18 Monate später zu bereinigen.

Eine einfache Validierungsregel, in Pseudocode ausgedrückt, veranschaulicht die Prüfung am Eingang:

IF new_location.store_id EXISTS in location_master
   AND new_location.address MATCHES existing.address
THEN flag_as_potential_duplicate()
ELSE IF new_location.upc_length != 12
THEN reject("invalid UPC format")
ELSE approve_and_publish()

Wissenscheck

1. Was unterscheidet Stammdaten im Handelskontext am besten von Transaktionsdaten?

2. Im Fusionsszenario war Filiale 0412 unter zwei verschiedenen Nummerierungssystemen doppelt angelegt und beide Datensätze buchten weiter. Welche Grundursache veranschaulicht das?

3. Ein Unternehmen will eine einzige maßgebliche Quelle für die Attribute jedes Produkts, obwohl die Daten in ein Dutzend nachgelagerte Systeme kopiert werden. Welches Konzept beschreibt diese maßgebliche Quelle?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten: Welche der folgenden sind Beispiele für Attribute von Standortstammdaten, im Unterschied zu Produkt- oder Kundenstammdaten?

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten: Warum blieb das Duplikat-Problem der Filiale in der Fusion achtzehn Monate lang unbemerkt?

Wählen Sie alle richtigen Antworten aus.

Messbenchmarks und wo man nachschaut

Es gibt keinen einzigen globalen „Datenqualitätsindex“ für den Handel, wie es etwa einen Inflationsindex gibt. Was existiert, sind interne Reifegrad-Assessments und von Anbietern veröffentlichte Umfrageschätzungen (behandeln Sie diese als richtungsweisend, nicht als präzise): Branchenumfragen zur Datenqualität (von Firmen wie Gartner und verschiedenen MDM-Anbietern) schätzen seit Jahren, dass Organisationen glauben, schlechte Datenqualität koste sie jährlich erhebliche Summen, wobei die genauen Dollarbeträge je nach Methodik stark variieren und nicht als feste Fakten zitiert werden sollten.

Der umsetzbarere Ansatz für ein Retail-Datenteam: eine interne Qualitäts-Scorecard pro Domäne (Produkt, Standort, Kunde, Lieferant) aufbauen, die oben genannten Metriken monatlich verfolgen und eigene Verbesserungsziele setzen, die an konkrete Geschäftsfolgen gekoppelt sind, wie im Fusions-Reporting-Beispiel, statt einer externen Benchmark-Zahl nachzujagen.

Für eine breitere Grundlage zu Prinzipien des Datenqualitätsmanagements ist die DMBOK-Übersicht von DAMA International ein solider, frei zugänglicher Referenzpunkt.

Wichtigste Erkenntnisse

  • Stammdaten (Produkt, Standort, Kunde, Lieferant) sind die stabile Referenzschicht, von der jede Transaktion abhängt; wenn sie kaputt sind, sind die Fehler still, kein Crash mit Knall.
  • Fusionen sind der klassische Stresstest: doppelte Standort-IDs, nicht zueinander passende Produkthierarchien und fragmentierte Kundenidentitäten können das Reporting monatelang verzerren, bevor es auffällt.
  • Verfolgen Sie konkrete, prüfbare Metriken: Duplikatrate, Attribut-Vollständigkeitsrate, Cross-System-Konsistenzrate, Golden-Record-Abdeckung und Time-to-Correct.
  • Governance-Mechanismen (ein System of Record, MDM-Tooling, benannte Data Stewards, Change Control für Hierarchien, Validierung am Eingang) verhindern die Probleme, die Metriken erst im Nachhinein aufdecken.
  • Es gibt keine universelle externe Benchmark für Datenqualität; bauen Sie eine interne Scorecard pro Domäne, gekoppelt an reale Geschäftsfolgen.