Stellen Sie sich vor, Sie sitzen im Lenkungsausschuss eines mittelständischen Maschinenbauers. Es ist Dienstagnachmittag, und der Projektleiter für die Software-Einführung schiebt eine Folie an die Wand, die das Budget in tiefem Rot zeigt. Wir sprechen hier nicht über ein paar Tausend Euro für neue Lizenzen. Es geht um einen zweistelligen Millionenbetrag, der bereits verbrannt wurde, während die Produktion stillsteht, weil das Lager und der Verkauf nicht mehr miteinander kommunizieren. Ich habe dieses Szenario in den letzten fünfzehn Jahren bei Dutzenden Unternehmen miterlebt. Oft liegt es daran, dass die Führungsebene glaubt, ein SAP Enterprise Resource Planning System sei eine reine IT-Angelegenheit, die man einfach per Installation lösen kann. In der Realität ist es eine Operation am offenen Herzen Ihres Unternehmens. Wenn der Chirurg — in diesem Fall Ihr Implementierungspartner — nicht versteht, wie Ihr Geschäft im Kern funktioniert, oder wenn Sie ihm falsche Informationen über Ihren Gesundheitszustand geben, wird der Patient auf dem Tisch bleiben. Das kostet nicht nur Geld, das kostet Marktanteile und im schlimmsten Fall die Existenzgrundlage.
Der Mythos der Standardisierung um jeden Preis
Ein fataler Fehler, den ich immer wieder sehe, ist der blinde Glaube an den „Best Practice“-Ansatz. Berater kommen ins Haus und erzählen Ihnen, dass Sie Ihre Prozesse einfach an die Software anpassen müssen, weil das System so am effizientesten arbeitet. Das klingt logisch, ist aber oft der Anfang vom Ende Ihrer Wettbewerbsfähigkeit. Wenn Ihr Unternehmen seit vierzig Jahren erfolgreich ist, weil Sie eine ganz spezifische Art der Ersatzteillogistik haben, die Ihre Kunden lieben, dann ist diese Eigenheit Ihr Kapital.
Werden diese Prozesse nun gewaltsam in ein starres Korsett gepresst, nur um Modifikationen am SAP Enterprise Resource Planning System zu vermeiden, verlieren Sie genau den Vorsprung, der Sie groß gemacht hat. Ich habe erlebt, wie Firmen ihre Lieferzeiten verdoppelt haben, nur weil das System „out of the box“ keine Teillieferungen in einer bestimmten Logik vorsah. Die Lösung ist nicht, alles zu verbiegen, sondern messerscharf zu unterscheiden: Wo bringt uns der Standard Effizienz (etwa in der Buchhaltung) und wo zerstört er unseren Wert (etwa in der kundenspezifischen Fertigung)? Man muss den Mut haben, an den richtigen Stellen Nein zum Standard zu sagen, auch wenn die Beraterrechnung für die Anpassung erst einmal wehtut. Langfristig ist ein Prozess, der nicht zu Ihrem Geschäft passt, weitaus teurer als jede Programmierung.
Die unterschätzte Gefahr durch marode Stammdaten
Es gibt diesen alten Spruch: „Garbage in, garbage out.“ Er wird oft zitiert, aber selten ernst genommen. In der Praxis sieht das so aus: Ein Unternehmen migriert Daten aus drei verschiedenen Altsystemen. Im ersten System heißt der Kunde „Müller GmbH“, im zweiten „Müller Logistik“ und im dritten existiert nur eine Kundennummer mit einer veralteten Adresse. Wenn Sie diesen Datenmüll unbereinigt in das neue SAP Enterprise Resource Planning System kippen, wird das System sofort unbrauchbar.
Ich war bei einem Projekt dabei, bei dem die automatische Disposition im Einkauf aktiviert wurde. Da die Mindestbestellmengen in den Stammdaten aber völlig veraltet waren und teilweise noch aus den 90er Jahren stammten, bestellte das System plötzlich Material für die nächsten fünf Jahre im Wert von drei Millionen Euro. Das Lager platzte aus allen Nähten, während die Liquidität in den Keller ging.
Warum die Datenbereinigung vor dem Go-Live passieren muss
Es reicht nicht, die Daten während der Migration zu „glätten“. Sie müssen vorab eine Radikalkur machen. Das bedeutet, dass Fachabteilungen tausende Excel-Zeilen händisch prüfen müssen. Das ist eine undankbare Aufgabe, die niemand machen will, aber sie ist das Fundament. Wenn die Basis nicht stimmt, berechnet das System falsche Margen, falsche Liefertermine und falsche Lagerbestände. Verlassen Sie sich nicht darauf, dass die Software Ihre Daten „intelligent“ erkennt. Ein System ist nur so schlau wie die Informationen, die Sie ihm füttern.
Das Kompetenz-Vakuum in der internen Projektleitung
Ein Projekt dieser Größenordnung wird oft einem IT-Leiter oder einem fähigen Abteilungsleiter als Zusatzaufgabe übertragen. Das ist ein Rezept für ein Desaster. Ein solches Vorhaben benötigt eine Vollzeit-Besetzung durch jemanden, der nicht nur die IT versteht, sondern die Macht hat, Prozessänderungen gegen den Widerstand alteingesessener Mitarbeiter durchzusetzen.
Oft erlebe ich, dass externe Berater das Ruder übernehmen, weil intern niemand die Zeit oder die Expertise hat. Das Problem dabei: Die Berater gehen nach dem Projekt wieder. Wenn das Wissen über die Konfiguration des Systems nur bei Externen liegt, sind Sie dauerhaft abhängig und zahlen für jede kleine Änderung horrende Tagessätze. Ich habe Firmen gesehen, die nach drei Jahren Betrieb feststellten, dass sie nicht einmal einen einfachen Report selbst anpassen konnten. Bauen Sie intern eine Taskforce auf, die vom Tagesgeschäft befreit ist. Diese Leute müssen verstehen, warum welcher Haken im System gesetzt wurde. Ohne diese interne Souveränität wird die Software zur Blackbox, die Ihr Unternehmen steuert, statt umgekehrt.
Warum das Change Management meistens nur Lippenbekenntnis bleibt
Es wird viel über „die Mitarbeiter mitnehmen“ geredet, aber meistens erschöpft sich das in einer bunten Powerpoint-Präsentation und einem zweistündigen Training kurz vor dem Start. Das ist kein Change Management, das ist Alibi-Politik. Die Wahrheit ist: Menschen hassen Veränderung, besonders wenn sie komplex ist.
Stellen Sie sich einen Lagermitarbeiter vor, der seit zwanzig Jahren seine Listen im Kopf oder auf Papier hat. Jetzt soll er plötzlich jedes Kleinteil mit einem Handscanner erfassen und jeden Schritt im System bestätigen. Wenn dieser Mann nicht versteht, warum das für das Unternehmen wichtig ist, wird er Wege finden, das System zu umgehen. Er wird Daten falsch eingeben oder „Schattenbuchführungen“ in seinen eigenen Notizbüchern führen. Das führt dazu, dass die Daten im System nach drei Monaten nicht mehr die Realität im Lager widerspiegeln. Echte Veränderung braucht Zeit, Präsenz vor Ort und vor allem die Akzeptanz derer, die am Ende die Tasten drücken müssen. Wenn die Basis das System boykottiert, haben Sie Millionen für ein Werkzeug ausgegeben, das niemand richtig benutzt.
Der fatale Vorher-Nachher-Vergleich in der Realität
Um zu verdeutlichen, was der Unterschied zwischen einer naiven und einer realistischen Herangehensweise ist, schauen wir uns ein typisches Szenario in der Fertigungssteuerung an.
Der naive Ansatz (Vorher): Ein Unternehmen führt die Software ein und übernimmt die bestehenden Fertigungspläne eins zu eins. Man verlässt sich darauf, dass die „erweiterte Planung“ des Systems schon alles optimieren wird. Die Mitarbeiter erhalten eine Schulung nach dem Motto „Hier klicken, dann dort klicken“. Am Tag des Go-Live stellt man fest, dass die Durchlaufzeiten im System viel kürzer hinterlegt sind als in der Realität. Die Folge: Das System plant Aufträge ein, die die Maschinen physisch gar nicht leisten können. Die Werkstattplanung bricht zusammen, Disponenten greifen zum Telefon und regeln alles wieder manuell per Zuruf. Das teure System wird zum reinen Schreibprogramm degradiert, das den Ist-Zustand nur noch mühsam dokumentiert, statt ihn zu steuern.
Der pragmatische Ansatz (Nachher): Dasselbe Unternehmen investiert vorab drei Monate nur in die Messung realer Durchlaufzeiten und Rüstzeiten. Es werden Pilotbereiche definiert, in denen das System trocken läuft, während die Mitarbeiter Feedback geben können. Man erkennt frühzeitig, dass die Standard-Planungstafel für die speziellen Maschinen nicht ausreicht und baut eine gezielte Erweiterung. Die Mitarbeiter werden nicht nur geschult, wie sie das System bedienen, sondern auch, was passiert, wenn sie eine Rückmeldung vergessen — nämlich dass der nachgelagerte Prozess beim Kollegen blind wird. Beim Go-Live gibt es zwar immer noch Stress, aber die Datenbasis ist so solide, dass das System realistische Pläne auswirft. Nach sechs Monaten sinken die Bestände um 15 Prozent, weil die Planung endlich verlässlich ist.
Die Kostenfalle durch unkontrollierte Anpassungen
Während ich davor gewarnt habe, den Standard blind zu erzwingen, gibt es das gegenteilige Extrem: Die „Wünsch-dir-was“-Mentalität. Jede Abteilung möchte, dass das System genau so aussieht wie die alte Software, nur schöner. Das führt zu hunderten von Modifikationen (Z-Entwicklungen), die den Kern des Systems verändern.
In meiner Laufbahn habe ich Systeme gesehen, die so stark angepasst waren, dass ein einfaches Update auf eine neue Version zwei Jahre Vorbereitung und Millionen an Testkosten verschlungen hat. Das System war quasi eingefroren. Jede Änderung an einer Stelle löste unvorhersehbare Fehler an fünf anderen Stellen aus. Hier muss die Projektleitung eine extrem harte Linie fahren. Jede Anpassung muss durch einen strengen Genehmigungsprozess: Welchen geschäftlichen Wert hat diese Änderung? Gibt es einen Workaround im Standard, der vielleicht weniger komfortabel, aber wartungsarm ist? Oft ist der Wunsch nach einer Anpassung nur die Angst vor einer Prozessänderung. Man muss lernen, Bequemlichkeit von Notwendigkeit zu unterscheiden.
Fehlende Testtiefe und der Kollaps am Tag X
Der größte Fehler passiert oft in den letzten acht Wochen vor dem Go-Live. Das Budget ist fast leer, die Nerven liegen blank und der Zeitplan ist gefährdet. Was wird als Erstes zusammengestrichen? Die Testphasen. Man macht einen „Integrationstest“, bei dem alles halbwegs funktioniert, und hakt das Thema ab.
Ein echter Test bedeutet aber, dass man Massendaten durch das System jagt. Was passiert, wenn nicht 10, sondern 1.000 Aufträge gleichzeitig verarbeitet werden? Was passiert, wenn ein LKW an der Rampe steht und die Internetverbindung kurz abbricht? Ich habe erlebt, wie ein Unternehmen am ersten Tag nach dem Go-Live keine einzige Rechnung schreiben konnte, weil ein kleiner Steuerparameter für Auslandsverkäufe falsch gesetzt war. Niemand hatte diesen speziellen Fall getestet, weil „wir das ja so selten machen“. Am Ende standen die LKWs Schlange, weil ohne Rechnung keine Ware das Gelände verlassen durfte. Ein Tag Stillstand kostete hier mehr als alle Tests zusammen gekostet hätten.
Ein ehrlicher Realitätscheck für Ihr Vorhaben
Wenn Sie glauben, dass Sie dieses Projekt nebenbei stemmen können, lassen Sie es lieber bleiben. Ein solches System einzuführen bedeutet Schmerz. Es bedeutet, dass langjährige Mitarbeiter frustriert sein werden, dass Prozesse, die jahrelang „irgendwie“ funktionierten, plötzlich gnadenlos als ineffizient entlarvt werden und dass die Kostenplanung wahrscheinlich nicht halten wird, wenn Sie nicht von Anfang an radikal ehrlich zu sich selbst sind.
Es gibt keine Abkürzung zum Erfolg. Ein SAP Enterprise Resource Planning System wird Ihr Unternehmen nicht durch Magie effizienter machen. Es ist lediglich ein Spiegel Ihrer internen Disziplin. Wenn Ihre Prozesse chaotisch sind, wird die Software dieses Chaos nur beschleunigen. Wenn Ihre Daten schlecht sind, wird das System falsche Entscheidungen automatisieren.
Erfolgreich sind am Ende nicht die Unternehmen mit den größten Budgets oder den teuersten Beratern. Es sind die, die bereit waren, ihre eigenen Arbeitsweisen tiefgreifend zu hinterfragen, die ihre Hausaufgaben bei den Daten gemacht haben und die verstanden haben, dass Software nur Werkzeug ist. Die echte Arbeit findet in den Köpfen Ihrer Mitarbeiter und in der Qualität Ihrer Prozesse statt. Wer das ignoriert, kauft sich für viel Geld ein sehr komplexes Problem. Wer es ernst nimmt, bekommt das Nervensystem, das ein modernes Unternehmen braucht, um in einem globalen Markt zu bestehen. Es ist nun mal so: Es wird hart, es wird teuer, und es wird Nerven kosten — aber wenn man die typischen Fehler vermeidet, ist es am Ende den Aufwand wert.
