Es gibt drei Hauptgründe. Keiner davon ist „die Mitarbeiter sind zu dumm für SAP“. Alle drei sind systemisch.
1. Die Dispo-Parameter wurden nie sauber gepflegt
Das ist der häufigste Grund. Und der peinlichste. Weil er so einfach zu beheben wäre.
Konkretes Beispiel: Ein Zulieferer im Maschinenbau, 800 Mitarbeiter. 12.000 Materialnummern im System. 4.000 davon aktiv. 8.000 auf Status „gesperrt“, aber nicht wirklich gesperrt, sondern auf „vielleicht brauchen wir das nochmal“. Die Dispositionsparameter für die aktiven Materialien? Bei 60% noch auf dem Stand der ECC-Einführung 2016. Sicherheitsbestand, Losgrößenverfahren, Wiederbeschaffungszeit, alles einmal gesetzt und nie wieder angefasst.
Was passiert: MRP läuft, generiert Planaufträge, die keiner versteht. Die Disponentin öffnet Excel, pflegt dort ihre eigene Bedarfsrechnung. Die SAP-Vorschläge ignoriert sie, weil sie gelernt hat, dass sie nicht stimmen.
Das Problem ist nicht Excel. Das Problem ist, dass niemand dem MRP-Lauf vertraut. Und niemand vertraut ihm, weil niemand die Parameter pflegt. Und niemand pflegt sie, weil der Key User, der sie damals eingerichtet hat, vor drei Jahren in Rente gegangen ist. Ohne Übergabe.
2. Der Prozess wurde 1:1 aus ECC übernommen
S/4HANA ist live. Aber die Prozesse sind von 2014. Klingt absurd, ist aber Standard bei Brownfield-Migrationen. Und selbst bei Greenfield sehe ich es regelmäßig: Man hat zwar ein neues System aufgesetzt, aber die Fachbereiche haben ihre gewohnten Abläufe einfach nachgebaut.
Konkretes Beispiel: Ein Tier-1 Zulieferer, Automotive, 1.200 Mitarbeiter. Retouren-Prozess mit 7 Freigabestufen. 7. Sieben Stufen, bis ein defektes Teil zurückgenommen wird. Ich habe mir die Freigabe-Workflows angeschaut: 4 der 7 Stufen waren leer. Seit fünf Jahren. Kein einziger Freigabeschritt wurde dort jemals ausgeführt. Aber der Prozess war so konfiguriert, dass die Retoure trotzdem durch alle 7 Stufen laufen musste.
Was macht der Sachbearbeiter? Er umgeht das System. Er trackt Retouren in Excel, gibt im SAP nur das Endergebnis ein, und hofft, dass niemand fragt.
Das Problem: Der Prozess wurde nie hinterfragt. Er wurde migriert. Eins zu eins. Mit allem Ballast, der sich über ein Jahrzehnt angesammelt hat. Und weil in S/4HANA niemand nochmal draufgeschaut hat, lebt der Unsinn jetzt im neuen System weiter.
3. Custom Code blockiert den Standard
Das ist der teuerste Grund. Und der, bei dem es am meisten wehtut.
Konkretes Beispiel: Derselbe Automotive-Zulieferer. Custom Code für Ersatzteilprozesse. Entwickelt 2017 von einem ABAP-Entwickler, der inzwischen in einem anderen Unternehmen arbeitet. Der Code macht Folgendes: Er greift in die Verfügbarkeitsprüfung ein, modifiziert das Ergebnis basierend auf einer Z-Tabelle, die manuell gepflegt wird. In Excel.
Niemand im Unternehmen versteht den Code. Niemand weiß, warum die Z-Tabelle existiert. Aber alle wissen: Wenn man sie nicht pflegt, stimmen die Verfügbarkeiten nicht. Also pflegt jemand wöchentlich eine Excel-Liste, kopiert Werte in die Z-Tabelle, und der Custom Code rechnet dann „richtig“.
Das ist kein Prozess. Das ist organisiertes Chaos mit Versionskontrolle in Excel.
Der Standard hätte die Verfügbarkeitsprüfung problemlos abgedeckt. ATP in S/4HANA kann das. Aber weil 2017 jemand entschieden hat, dass der Standard „nicht reicht“, gibt es jetzt Custom Code, den niemand versteht, eine Z-Tabelle, die niemand dokumentiert hat, und eine Excel-Datei, die das Ganze zusammenhält.