Wenn der Bediener klüger ist als das System

Wenn man über SAP MFS spricht, denkt man an Logik, Telegramme, klare Regeln. An ein System, das Material zuverlässig dahin steuert, wo es hin soll. Was selten jemand sagt: Die Menschen, die täglich mit diesem System arbeiten, wissen oft mehr über das Lager als jede Spezifikation. Und das ist kein Problem. Es ist eine Chance, die meist verschenkt wird.

1. Workarounds sind keine Schwäche - sie sind Diagnose

In fast jedem Lager gibt es sie: Bediener, die heimlich Etiketten neu kleben, Behälter manuell umbuchen, eine bestimmte Bahn einfach meiden. Das wirkt auf den ersten Blick wie ein Disziplinproblem. Auf den zweiten Blick ist es eine der ehrlichsten Rückmeldungen, die ein System bekommen kann.

Wo ein Workaround entsteht, hat das System eine Lücke. Die Frage ist nicht, wie man den Workaround unterbindet. Die Frage ist, was er über das System verrät.

2. Das System sieht Zustände. Der Bediener sieht Geschichten.

Ein MFS kennt Status: belegt, frei, gestört, leer. Der Bediener kennt etwas anderes: Kontext. Er weiß, dass Bahn 3 immer dann zickt, wenn die Spätschicht beginnt. Er weiß, dass die Behälter von Lieferant X regelmäßig zu eng gestapelt sind. Er weiß, dass der neue Kollege bei einer bestimmten Meldung immer das Falsche klickt.

Das System sieht nichts davon. Es sieht nur die Folge: eine Störung, eine Korrekturbuchung, eine offene Order. Die Ursache liegt in einer Geschichte, die niemand dokumentiert.

3. Erfahrungswissen lässt sich nicht spezifizieren

In jedem Lager existiert ein zweites, unsichtbares Betriebshandbuch. Es steht nicht im Lastenheft. Es wird mündlich weitergegeben, in der Pause, beim Übergabegespräch, am Arbeitsplatz.

Ein erfahrener Bediener hört am Geräusch, dass ein Sorter in zwei Minuten klemmen wird. Kein Sensor fängt das. Keine KPI macht es sichtbar. Wer dieses Wissen ignoriert, weil es nicht im System steht, verliert genau die Information, die in den nächsten zwei Minuten zählt.

4. Wer Schattenlogik wegrationalisiert, baut sprödes System

Eine häufige Fehlannahme in MFS-Projekten: Wenn man alle manuellen Eingriffe abschafft, wird das System stabiler. In der Theorie stimmt das. In der Praxis stimmt das Gegenteil.

Manuelle Eingriffe sind oft das, was ein System überhaupt am Laufen hält. Sie sind die menschliche Reaktion auf das, was die Logik nicht abgedeckt hat. Wer sie wegrationalisiert, ohne zu verstehen, was sie eigentlich kompensiert haben, baut ein System, das beim ersten unerwarteten Ereignis stehenbleibt.

5. Gute MFS-Projekte hören zu, bevor sie automatisieren

Die wichtigste Phase eines MFS-Projekts ist nicht die Spezifikation. Es ist das Mitlaufen. Eine Schicht früh, eine Schicht spät, einmal Wochenende. Fragen stellen, ohne sofort eine Lösung zu wollen. Workarounds dokumentieren, ohne sie zu bewerten.

Wer das tut, findet Anforderungen, die in keinem Lastenheft stehen. Und er gewinnt etwas, das jede Spezifikation übertrifft: Vertrauen. Wenn der Bediener spürt, dass sein Wissen ernstgenommen wird, wird er es teilen. Wenn nicht, wird er es behalten. Und das System wird ohne dieses Wissen leben müssen.

Fazit

Ein gutes MFS macht den Bediener nicht überflüssig. Es macht sein Wissen sichtbar. Das gelingt nicht über bessere Algorithmen, sondern über eine andere Haltung: Der Mensch im Lager ist kein Risikofaktor, den man kontrollieren muss. Er ist ein Sensor, den man bisher nicht ausgelesen hat.

Die besten Projekte, die ich begleitet habe, hatten eines gemeinsam: Sie haben dem Bediener zugehört, bevor sie ihm eine Oberfläche gebaut haben. Das Ergebnis war jedes Mal das gleiche. Ein System, das funktioniert, weil es passt. Nicht weil es vorgeschrieben wurde.