Stammdaten: Die stille Fehlerquelle, die wie ein Systemproblem aussieht
Automatisierung & IntegrationDatenqualität

Stammdaten: Die stille Fehlerquelle, die wie ein Systemproblem aussieht

T. Krause

T. Krause

Das Symptom

Die Sätze klingen in jedem Betrieb ähnlich. „Auf die Bestandsdaten kann man sich nicht verlassen." „Der Materialbedarf stimmt nie." „Wir haben das System, aber wir rechnen trotzdem in Excel nach."

Daraus wird meist eine Systemdiskussion. Das ERP sei zu alt, zu starr, schlecht eingeführt worden; ein Wechsel wird geprüft, Angebote werden eingeholt. Was in dieser Phase selten jemand macht: eine Stichprobe von fünfzig Artikeln nehmen und die hinterlegten Stammdaten gegen die Realität prüfen.

Wer es macht, findet in der Regel dasselbe. Das System rechnet einwandfrei. Es rechnet nur mit Wiederbeschaffungszeiten, Mindestbeständen, Stücklisten und Arbeitsplänen, die zu einem Betrieb gehören, den es so seit fünf Jahren nicht mehr gibt.

Der Mechanismus

Stammdaten haben eine unangenehme Eigenschaft: Sie werden einmal angelegt und danach nur noch dann angefasst, wenn etwas schiefgeht. Es gibt keinen Anlass, sie zu pflegen, weil ein veralteter Wert nichts meldet — er produziert nur leise ein etwas falsches Ergebnis.

Vier Feldtypen laufen dabei besonders zuverlässig aus dem Ruder.

Wiederbeschaffungszeiten. Beim Anlegen des Artikels wurde eingetragen, was der Lieferant damals genannt hat. Seitdem hat sich der Lieferant geändert, die Menge, die Lieferkette. Der Wert steht unverändert im System und bestimmt jede Bestellvorschlagsrechnung.

Mindest- und Meldebestände. Meist einmal aus dem Bauch gesetzt, oft in ruhigeren Jahren. Sie bestimmen, wann Kapital gebunden wird, und werden praktisch nie überprüft.

Stücklisten. Konstruktionsänderungen kommen in der Fertigung an, bevor sie im System ankommen. Die Halle arbeitet mit der aktuellen Version, das System kalkuliert mit der alten. Beide sind überzeugt, recht zu haben.

Arbeitspläne und Vorgabezeiten. Dieselbe Geschichte wie bei den Rüstzeiten: einmal ermittelt, danach fortgeschrieben.

Der eigentliche Schaden entsteht durch eine Rückkopplung. Weil die Ergebnisse nicht stimmen, prüft jemand nach — in einer eigenen Tabelle. Diese Tabelle wird zur Arbeitsgrundlage. Damit sinkt der Anlass, die Stammdaten zu korrigieren, weiter, denn man arbeitet ja ohnehin nicht mehr mit ihnen. Nach zwei Jahren gibt es zwei parallele Wahrheiten, und die gepflegte ist die inoffizielle.

Die Kosten

Ein anonymisiertes Beispiel, in Details verändert, im Muster echt. Ein technischer Großhändler mit rund 9.000 aktiven Artikeln stand vor einem ERP-Wechsel. Begründung: unzuverlässige Dispositionsvorschläge, zu hohe Bestände, gleichzeitig zu viele Fehlteile. Das Budget für den Wechsel lag bei etwa 380.000 Euro über zwei Jahre.

Vor der Entscheidung wurde eine Stichprobe von 200 A- und B-Artikeln gegen die tatsächlichen Lieferzeiten der letzten 18 Monate geprüft. Ergebnis: Bei 63 Prozent wich die hinterlegte Wiederbeschaffungszeit um mehr als fünf Werktage von der real gemessenen ab — in beide Richtungen. Bei 31 Artikeln lag der hinterlegte Wert bei einem Lieferanten, der seit über zwei Jahren nicht mehr belieferte.

Die Wirkung war genau das beschriebene Doppelbild: Zu kurz hinterlegte Zeiten erzeugten Fehlteile, zu lang hinterlegte erzeugten Überbestand. Beides gleichzeitig, im selben Lager, aus derselben Ursache. Das gebundene Kapital in Artikeln mit überhöhter Wiederbeschaffungszeit lag bei rund 210.000 Euro.

Ein neues ERP hätte diese Daten übernommen. Es hätte sie schneller und schöner falsch verarbeitet.

Der Fix

Der ERP-Wechsel wurde nicht abgesagt, aber verschoben — und zuerst wurde ein Datenprojekt gemacht, das drei Monate dauerte und einen Bruchteil kostete.

Zuerst wurde die Wiederbeschaffungszeit nicht mehr gepflegt, sondern gemessen: aus den tatsächlichen Bestell- und Wareneingangsdaten der letzten 24 Monate, je Artikel und Lieferant, mit Median statt Mittelwert. Das ließ sich weitgehend automatisiert auswerten, weil die Daten vorhanden waren — nur nie ausgewertet worden.

Zweitens bekam jedes kritische Stammdatenfeld einen Verantwortlichen und ein Überprüfungsintervall. Nicht als Richtlinie, sondern als terminierte Aufgabe bei einer namentlich benannten Person.

Drittens wurde eine einfache Abweichungsmeldung eingerichtet: Weicht die reale Lieferzeit eines Wareneingangs deutlich vom hinterlegten Wert ab, entsteht eine Aufgabe. Damit pflegt sich der Stamm im laufenden Betrieb selbst nach.

Nach sechs Monaten waren die Fehlteile deutlich zurückgegangen und der Bestand um rund 140.000 Euro gesunken. Ob der ERP-Wechsel überhaupt noch nötig ist, wird inzwischen anders diskutiert als vorher.

Das Muster ist übertragbar: Ein System ist nur so gut wie die Daten, mit denen es rechnet — und das prüft man, bevor man das System tauscht. Genau diese Reihenfolge ist Teil einer Prozessanalyse. Fester Umfang, feste Dauer, fester Preis.

Der nächste Schritt

Ziehen Sie zwanzig Ihrer wichtigsten Artikel und vergleichen Sie die hinterlegte Wiederbeschaffungszeit mit den letzten fünf echten Wareneingängen. Wenn mehr als eine Handvoll deutlich abweicht, haben Sie kein Systemproblem.

Cookie-Einstellungen

Wir nutzen technisch notwendige Cookies, um diese Seite bereitzustellen. Optional helfen anonymisierte Analyse-Cookies (Google Analytics) dabei, die Seite zu verbessern — diese setzen wir nur mit Ihrer Einwilligung.

Mehr in der Datenschutzerklärung