In einem Großhandel, der seit fünfzehn Jahren läuft, sind die Produktstammdaten nie sauber. Niemand hat sie absichtlich zerlegt — es war einfach so, dass jeder Vertriebler einen neuen Artikel anlegte, wenn der alte in der Suche nicht auftauchte. Nach einem Jahrzehnt hat das Unternehmen dreimal so viele „Produkte" wie es tatsächlich einkauft.
Dubletten, Varianten desselben Artikels unter verschiedenen Codes, tote SKUs aus fünf Jahren zuvor, Einträge wie „Test 01", „Kabelchen", „Vorübergehendes Produkt", und Mengeneinheiten, an die sich niemand erinnert („Pkg." — ist das ein Karton oder eine Schrumpfeinheit?). Alles lebt im selben Wörterbuch und vergiftet jede nachgelagerte Entscheidung: Lagerbestand, Margenbericht, Allegro-Integration, das Angebot an den Kunden.
Dieser Text handelt davon, wie man in einem 15- bis 50-Personen-Handels- oder Produktionsunternehmen die Produktstammdaten aufräumt — ohne den Vertrieb einen Monat lang stillzulegen und ohne für ein volles MDM-Projekt (Master Data Management) zu viel zu bezahlen.
Woher das Chaos kommt
Drei häufigste Quellen, in dieser Reihenfolge.
Erstens: Jeder Vertriebler legt einen SKU „für sofort" an. Ein Lieferant schickt ein neues Produkt, ein Kunde will heute ein Angebot, also legt der Vertriebler um 15:47 Uhr „KAB-M-2M-BIA" an. Dass dasselbe Kabel bereits als „KABEL-2M-M-BIALY" in der Datenbank existiert — dazu hatte niemand Lust. Das ERP erzwingt keine EAN-Eindeutigkeit, weil das EAN-Feld optional ist, und der Lieferantenname unterscheidet sich durch einen Tippfehler.
Zweitens: ERP-zu-ERP-Migrationen. Das Unternehmen wechselt von Subiekt auf Comarch Optima, der gesamte Katalog wird „wie er ist" importiert, ohne Bereinigung. Zwei Jahre später weiß niemand mehr, welche SKUs aus der Migration stammen und welche aus dem Tagesgeschäft. Dazu kommen Testeinträge aus der Migration, die jemand angelegt hat, um zu prüfen „ob sich das überhaupt einpflegen lässt" — und sie sind geblieben.
Drittens: Lieferantenwechsel. Das Unternehmen wechselt den Kabellieferanten von „Elektrocentrum" zu „HurtElektryk", und der neue Lieferant vergibt andere Codes. Statt den Lieferantencode am bestehenden SKU anzupassen — entsteht ein zweiter SKU. Drei Jahre später hast du zwei parallele Wörterbücher für dieselbe Warengruppe.
12 800 SKUs, davon 5 400 Dubletten oder tot
Bei einem unserer Kunden — einem 22-köpfigen Elektro-Großhandel aus Südostpolen, der seit 9 Jahren Comarch Optima nutzt — wollte die Geschäftsführung nach dem ersten sauberen Buchprüfungsaudit eine „echte Inventur" durchführen. Ausgangslage: 12 807 aktive Produktdatensätze im Wörterbuch, während das Lager (ca. 3 800 m²) physisch schätzungsweise 4 000 bis 5 000 verschiedene Artikel enthielt.
Nach drei Wochen Analyse des Optima-Exports zeigte sich:
- 3 190 SKUs hatten in den letzten 24 Monaten keinerlei Lagerbewegung und Bestand null.
- 1 480 SKUs waren Dubletten (dieselben Produkte unter verschiedenen Codes — meist unterschieden sie sich durch ein Leerzeichen, Groß-/Kleinschreibung oder einen alten Lieferantencode).
- 220 SKUs waren Arbeitseinträge wie „Test", „Neues Produkt", „Kabel — prüfen", „VORÜBERGEHEND".
- 510 SKUs hatten eine leere EAN, obwohl die Produkte physisch mit Barcodes bedruckt waren.
- 340 SKUs hatten die Einheit „Stk.", obwohl sie in Wahrheit nach Metern oder in Sammelpackungen verkauft wurden.
Die tatsächliche Zahl aktiv verkaufter SKUs lag bei 7 417. Also 42% weniger als im ERP. Folgen: Die Jahresinventur dauerte 4 Tage, weil die Zählliste 12 800 Positionen hatte. Ein Vertriebler, der „YDY 3×1,5 Kabel" eintippte, bekam vier verschiedene SKUs zurück und wählte den, der gerade Bestand hatte (nicht immer den „Haupt"-Datensatz), wodurch der Top-Verkaufsbericht künstliche Zersplitterung zeigte.
Die Bereinigung dauerte 8 Wochen. Vorgehen: 2 Wochen Audit und Zusammenführungsregeln, 5 Wochen Merges mit 100 bis 200 Datensätzen pro Tag (jeder Merge abgenickt vom Vertriebler, der für die Warengruppe verantwortlich war), eine Woche Feinschliff. Kosten: 24 Tsd. PLN, inklusive einer GS1-Integration zur EAN-Validierung. Ergebnis: Die nächste Inventur dauerte 1,5 statt 4 Tage, die Suche lieferte endlich einen Datensatz pro Anfrage, und der Top-100-Verkaufsbericht zeigte zum ersten Mal seit Jahren das, was die Geschäftsführung intuitiv immer wusste, dass die Firma verkauft.
Nichts Zauberhaftes. Vier Personen, eine gemeinsame Regel, acht Wochen.
Was löschen, was in Ruhe lassen
Das ist die heikelste Frage, denn jeder Vertriebler wird „seine" SKUs wie souveränes Territorium verteidigen.
Ohne zu zögern löschen: Testeinträge („Test", „ABC Produkt", „NEU"), Datensätze mit leeren Identifikationsfeldern (keine EAN, kein Lieferantencode, kein Bild, keine Verkäufe), und Einmal-Datensätze, die vor 6+ Jahren für eine einzige Bestellung angelegt und danach nie wieder benutzt wurden.
Zusammenführen (nicht löschen): Dubletten. Der entscheidende Unterschied: Ein Datensatz mit Verkaufshistorie zu löschen zerstört deine historischen Berichte. Zusammenführen heißt, dass ein Code zum „Master" wird und die Dubletten inaktiv gesetzt werden, mit ihrer Historie umgeleitet auf den Master. Comarch Optima und enova365 haben dedizierte Funktionen dafür. In Subiekt macht man das mit einem SQL-Skript — vorsichtig, und erst nachdem die Datenbank in eine Testumgebung wiederhergestellt wurde.
Archivieren, nicht löschen: tote SKUs (keine Verkäufe seit 24+ Monaten, aber historische Verkäufe existieren). Setze sie auf „inaktiv", nimm sie aus den Standardansichten der Vertriebler, aber behalte sie in der Datenbank. In drei Jahren, bei der Steuerprüfung, wirst du dir selbst danken.
Nicht anfassen: Datensätze, bei denen du dir nicht sicher bist. Eine falsche Entscheidung, Produkte zusammenzuführen, die tatsächlich verschieden sind (zum Beispiel eine 10A- und eine 16A-Sicherung, die in der Bezeichnung ähnlich aussehen), zerlegt deine Bestandsberichte. Regel: Im Zweifel — stehen lassen und in einer zweiten Runde zurückkommen.
Wie du die Bereinigung ohne Vertriebsstillstand durchziehst
Vier Regeln, die in jedem Projekt funktionieren.
Immer zuerst ein Datenbank-Backup. Bevor jemand einen Datensatz berührt, machst du ein vollständiges ERP-Backup und stellst es in einer Testumgebung wieder her. In der ersten Woche arbeitest du ausschließlich auf der Kopie — erst wenn die Merge-Regel klar und geprüft ist, überträgst du Änderungen in die Produktion.
Batches von 100 bis 200 Datensätzen pro Tag, nicht alles auf einmal. Es ist verlockend, ein Skript zu schreiben, das „alles am Wochenende aufräumt". In der Praxis führen solche Skripte immer etwas zusammen, was sie nicht sollten. Manuelle Arbeit mit 100 bis 200 SKUs pro Tag, abgenickt vom verantwortlichen Vertriebler, ist langsamer — aber sie legt keine Brände.
Weise pro Warengruppe eine verantwortliche Person zu. In jedem Großhandel gibt es jemanden, der Kabel am besten kennt, jemanden, der Beleuchtung am besten kennt, und jemanden, der Zubehör am besten kennt. Sie zeichnen die Merges ab — nicht die IT, nicht ein Vertriebler aus der Nachbarregion, nicht die Geschäftsführung. Ohne das kippt die Regel „wir führen KABEL-2M-BIA mit KAB-M-2M-BIALY zusammen" in der ersten Woche, weil sich herausstellt, dass eines weißes PVC ist und das andere weißes LSOH.
Jede Entscheidung protokollieren. Ein einfaches Google-Sheet: Master-Code, zusammengeführte Codes, Datum, wer abgezeichnet hat, Begründung. Ein halbes Jahr später wird jemand fragen „was ist mit SKU X passiert" — und du musst die Antwort in 30 Sekunden haben, nicht nach zwei Tagen ERP-Wühlerei.
Die Stammdaten nach der Bereinigung sauber halten
Die Bereinigung ist ein einmaliges Ereignis. Die Stammdaten sauber zu halten — ist ein Prozess. Drei Dinge, ohne die du in zwei Jahren wieder am selben Punkt stehst.
Weise eine einzige Person zu, die für das Anlegen neuer SKUs verantwortlich ist. Nicht „jeder Vertriebler bei sich" — eine Person im Unternehmen, mit Regeln. Es kann die Assistenz der Geschäftsführung sein, es kann der Lagerleiter sein, es kann der Inhaber sein — Hauptsache eine.
Sperre im ERP das Anlegen von Datensätzen ohne Pflichtfelder. Comarch Optima, enova365 und Subiekt erlauben, EAN, Lieferantencode, Mengeneinheit und Kategorie als Pflicht zu erzwingen. Das sind 10 Minuten Arbeit für den ERP-Administrator, und die Hälfte des Problems verschwindet an der Wurzel.
Erzeuge jedes Quartal einen Bericht „neu angelegte SKUs der letzten 90 Tage" und geh ihn durch. 15 Minuten pro Quartal ersparen dir in drei Jahren Wochen an Bereinigung.
Wenn deine Produktstammdaten aufgebläht sind und du selbst nicht weißt, wie viele Produkte du wirklich hast — brauchst du kein MDM-Projekt für eine halbe Million. Ein halbstündiges Gespräch mit jemandem, der das in Optima, enova und Subiekt seit Jahren macht, reicht meist, um den Aufwand einzuschätzen.
Stammdaten aufzuräumen ist kein IT-Projekt — es ist ein Management-Projekt. Ohne die Entscheidung, wer die Daten besitzt, hält kein ERP sie von allein sauber.