Stammdaten: Die stille Fehlerquelle, die wie ein Systemproblem aussieht

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 in einer eigenen Tabelle nach. 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 Rechenbeispiel mit erfundenen Zahlen. Angenommen, ein technischer Großhändler mit rund 9.000 aktiven Artikeln steht vor einem ERP-Wechsel. Die Begründung: unzuverlässige Dispositionsvorschläge, zu hohe Bestände, gleichzeitig zu viele Fehlteile. Das Budget für den Wechsel liegt bei etwa 380.000 Euro über zwei Jahre.

Vor der Entscheidung prüft der Betrieb eine Stichprobe von 200 A- und B-Artikeln gegen die tatsächlichen Lieferzeiten der letzten 18 Monate. Im Beispiel weicht bei 63 Prozent die hinterlegte Wiederbeschaffungszeit um mehr als fünf Werktage von der gemessenen ab, und zwar in beide Richtungen. Bei 31 Artikeln gehört der hinterlegte Wert zu einem Lieferanten, der seit über zwei Jahren nicht mehr liefert.

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

Ein neues ERP würde diese Daten übernehmen. Es würde sie schneller und schöner falsch verarbeiten.

Der Fix

Absagen muss der Großhändler aus dem Beispiel den ERP-Wechsel nicht. Er verschiebt ihn und macht zuerst ein Datenprojekt, das drei Monate dauert und einen Bruchteil kostet.

Zuerst wird 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 lässt sich weitgehend automatisiert auswerten, weil die Daten vorhanden sind. Ausgewertet hat sie nur nie jemand.

Zweitens bekommt jedes kritische Stammdatenfeld einen Verantwortlichen und ein Überprüfungsintervall. Nicht als Richtlinie, sondern als terminierte Aufgabe bei einer namentlich benannten Person. Wer einen Ablauf neu beschreibt, trägt diese Verantwortung gleich neben jedem Schritt ein, der das Feld liest. Wie das aussieht, zeigt der Beitrag zu Soll-Prozess und Datenmodell.

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

Das Rechenbeispiel nimmt an, dass die Fehlteile nach sechs Monaten deutlich zurückgehen und der Bestand um rund 140.000 Euro sinkt. Ob der ERP-Wechsel dann noch nötig ist, lässt sich mit diesen Zahlen neu entscheiden.

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.