Warum große ERP-Einführungen viel zu oft scheitern!

Lidl, die Deutsche Post, die Deutsche Bank und Otto: Eine leider viel zu lange Liste von gescheiterten SAP-Einführungen großer Konzerne in Deutschland. Der Chef von Liqui-Moly hat seinen Frust über die ERP-Einführung mal so richtig Luft gemacht: „Das ist schlimmer als Brexit, Trump und Handelskrieg“, tönt Ernst Prost in der FAZ vom 10.07.2019 . Es sei angemerkt, dass es sich bei Liqui Moly nicht um eine SAP-Einführung, sondern um Microsoft AX handelt. Aber im Grunde ist es egal, welche ERP-Software genutzt wird, denn die Probleme liegen nicht primär in der Software.

Woran liegt es dann und warum scheitern solche ERP Einführungen so oft?

 1.      Key-User und Prozessexperten sind nicht vorhanden oder müssen ausgebildet werden und ihre neue Rolle verstehen, akzeptieren und leben können. In vielen Fällen muss überhaupt erst geklärt werden, was Key-User und Prozessexperten sind und welche Aufgaben sie haben. Das braucht viel Zeit, die idealerweise vor dem Start des Projektes investiert werden muss und nicht während des Projektes. Denn dann ist es eigentlich schon zu spät und es ist keine Zeit mehr für die Ausbildung der Projektmitglieder vorhanden; die müssen Gas geben und nicht mehr angelernt werden. Weiterhin wichtig in diesem Kontext ist die absolute Transparenz für die Linienführungskräfte inwieweit ihre jetzt an das ERP-Projekt abgegebenen Mitarbeiter noch zur Verfügung stehen. Sind sie zu 100% in das Projekt abgegeben oder variiert die Projekttätigkeit (z.B. zu Anfang 80% für die Konzeption/Blue-Print-Phase, dann 50% während der Implementierung, dann 100% für die Tests und den Go-Live). Das muss sehr klar sein, denn oftmals gibt es im Projekt großen Ärger oder Unverständnis bzgl. der Zeitaufwände zwischen Linie und Projekt.

2.      Es gibt in jedem Unternehmen Zeiten bzw. Zeiträume im Jahr, in denen nur das Kerngeschäft zählt (Beispiel Weihnachts- oder Ostergeschäft, Saisongeschäfte, etc.) – dies sind Ausfallzeiten, die meistens nicht mit in die Projektlaufzeit eingerechnet werden. In solchen Zeiten geht aber im ERP-Projekt meistens gar nichts. Wenn es wieder weitergeht, müssen alle Beteiligten wieder neu an Board geholt werden. Das sind alles Zeiten, die oftmals nicht gesehen werden und später teuer zu stehen kommen.

3.      Externe ERP-Berater. Es geht nicht ohne, aber mit ist es meistens auch nicht leichter! ERP-Berater sind meistens gute Experten und Spezialisten in ihrem Teilgebiet oder Modul. Aber es sind halt auch nur Menschen: Von extremer Arroganz bis hin zu Nerds, die nur die Technik sehen ist da alles vertreten. Der ideale ERP-Berater würde sich voll auf das neue Unternehmen einlassen, die Branche und die Prozesse genau verstehen und vor allem sein Wissen zügig und verantwortungsvoll in die Hände der internen ERP-Experten geben. Leider steht dies dem Geschäftsmodell von ERP-Systemhäusern zu 100% entgegen. Denn diese wollen möglichst lange dabeibleiben, denn jeder abgerechnete Tag zählt. Hier wäre ein Ansatz der Zusammenarbeit wünschenswert, der die ERP-Systemhäuser mit in die Pflicht nimmt und am Risiko bzw. Erfolg des Projektes beteiligt. Dies findet nur sehr selten statt.

4.      Internes Projekt-Know-how ist oftmals nicht ausreichend. Theoretisches Rüstzeug über Projektmanagement-Methodiken ist heutzutage oft vorhanden. Es mangelt aber an der engen Zusammenarbeit mit dem (Top-)Management. Es fehlt die Seniorität und damit die Traute und die Ehrlichkeit Fehler zuzugeben, Probleme frühzeitig zu berichten, etc. . Leider ist es oft Schönmalerei und es passieren Farbwunder (gelbe Ampeln werden auf einmal grün oder rot verwischt zu gelb). Klar: Projektleiter sehen diese ERP-Einführung als Karrierechance und wollen sich nicht unbeliebt machen. Aber Ehrlichkeit währt meistens länger. Hier kann ein Coach für den Projektleiter helfen.

5.      Customizing wird von Usern gefordert anstatt im Standard zu bleiben – der Klassiker für Projektverzögerungen und die spätere Komplexitäts- und Kostenfalle. Das Problem hier: Der User/Anwender kennt nur seine bisherige Arbeitsweise und will die Prozesse genauso wieder haben, denn das ist ja – auch ein Klassiker – eine Besonderheit des Unternehmens (ohne die man nie so groß geworden wäre und wenn man die nicht mehr hat, dann geht gar nichts mehr). Diese „Besonderheit“ muss im neuen ERP aus Sicht des Users natürlich wieder genauso abgebildet werden. Andersherum: Wenn man im Standard bleibt und nicht auf die Wünsche des/der User eingeht, dann entsteht Widerstand, der dazu führen kann dass die ERP-Einführung bewusst blockiert wird – hier ist sehr viel Feingefühl und Change Management von Nöten sowie Führung: Die Chefs der Anwender müssen hier klar ihre Verantwortung erkennen und einnehmen und klar sagen wie es gemacht werden soll und auch klären was das für den User am Ende bedeutet.

6.      Testphasen werden unzureichend geplant. Key-User und User haben keine Zeit, sind noch nicht tief genug mit dem System vertraut oder können die Testfälle gar nicht abarbeiten. Fehler werden dadurch nicht erkannt. Testfallkataloge existieren oftmals nicht oder die wesentlichen Funktionen sind vergessen worden. Abnahmen von Tests sind oftmals nicht vorhanden und wie wird mit Fehlern in der Testphase umgegangen? Oft wird dann mit Blick auf die Zeit gesagt: „Das machen wir hinterher!“ Und dann fehlen auf einmal wichtige Funktionen im Live-Betrieb. Vermeintlich kleine Dinge, die dann ausgelassen werden, können auf den Gesamtprozess gesehen große Auswirkungen haben. Auf einmal geht im Live-Betrieb die Ware an den Kunden doch nicht raus, nur weil eine „Kleinigkeit“ fehlt oder nicht richtig getestet wurde. Die Komplexität ist leider oft sehr groß, aber es hilft ja nichts. Auch Kleinigkeiten müssen sich genau angeschaut werden.

7.      Thema Schulungen. Hier kann man oft sein blaues Wunder erleben. Nicht nur, dass die Kosten durch die Decke gehen, weil der Schulungsbedarf so enorm hoch ist. Die Schulungen für mehrere 100 User müssen geplant und koordiniert werden. Woher soll die Zeit für die ganzen Schulungen kommen. Das ist vorher meistens nicht so genau geplant worden. Dann kann es passieren, dass die Schulungen alleine doch nicht ausreichen für die effiziente Bedienung des neuen Systems. Hier hilft nur eine sehr frühzeitige Planung und vor allem müssen die Führungskräfte verstehen, dass ihre Mitarbeiter für lange Zeiträume nicht mehr zur Verfügung stehen; denn Schulungen und Trainings kosten viel Zeit und Koordinationsaufwand.

8.      Stammdaten: Riesen-Thema! Die Ausgangssituation vor ERP-Einführungen in Bezug auf Stammdaten gleicht meistens einem Horror-Film! Entweder Stammdaten sind gar nicht vorhanden oder in Office-Programmen oder im alten ERP nicht oder nur sehr rudimentär gepflegt und damit mit Dopplungen, veralteten Daten. Es gibt verschiedene Versionen von einem und demselben Stammdatum. Viele Stammdaten, die im neuen ERP benötigt werden gibt es noch gar nicht. Sie müssen neu generiert und aufgebaut werden. Stammdatenverantwortlichen gab es bisher nicht oder nicht wirklich. Die Key-User müssen sich dann intensiv mit Stammdaten beschäftigen und haben keine Zeit mehr für ihre eigentlichen Aufgaben im ERP-Projekt und vor allem in ihrem normalen Aufgabenfeld. Es ist daher entscheidend, dass sehr frühzeitig und am besten vor dem Projekt eine Stammdatenorganisation etabliert wird. Rollen und Verantwortlichkeiten müssen klar geregelt sein. Diese Jobs sind nicht sehr beliebt und gute Leute sind schwer zu finden, aber für den Projekterfolg sind sie maßgebend. Daher früh die richtigen Leute suchen und fit machen für die verantwortungsvollen Stammdatenrollen.

9.      Die Einführungsstrategie wird nicht ausreichend durchleuchtet und Risiken der verschiedenen Szenarien nicht genau genug eruiert. Das führt oft zu Big-Bang-Einführungen, die das Unternehmen leider zu oft gnadenlos lahmlegen. Oft sind kurze Sprints und schnelle Einführungen von Teilbereichen sinnvoller. Dann aber hat man das Problem der Schnittstellen zu Altsystemen und eine komplexe Architektur. Aber einen Tod muss man sterben und die Diskussion darüber ist zu oft ungenügend, so dass eine Einführungsstrategie oftmals nicht den Namen verdient.

10.  Es gibt auf einmal andere Prioritäten im Unternehmen. Das ERP-Projekt rutscht ganz schnell auf Prio 2 oder 3, wenn zum Beispiel ein neuer großer Kunde oder Lieferant hinzukommt, Lieferanten oder wichtige Kunden abspringen oder ein neues Unternehmen gekauft wird. Auf einmal ist alles andere wichtig. Die Awareness und das ehemalige Commitment zum ERP-Projekt im Top-Management, aber auch von Key-Usern und Prozessexperten geht auf einmal gegen Null. Das führt verständlicherweise zu Verzögerungen, die man aber nicht wahr haben will und dann trotzdem einführen möchte. Das geht meistens daneben. Verzögerungen sind aber auch schlecht, denn alle Beteiligten müssen sich wieder neu einarbeiten und die ehemalige Motivation ist schnell futsch. Dem Top-Management muss klar sein, dass Verschiebungen von Prioritäten große Auswirkungen auf den Projekterfolg haben. Ressourcen dürfen nicht von heute auf morgen in andere Projekte abgezogen werden. Hier muss sehr feinfühlig im Management entschieden werden, was gerade wirklich wichtig ist für das Unternehmen.

11.  Die sogenannte Change-Komponente eines ERP-Projektes wird gnadenlos unterschätzt. Oftmals nach dem Motto „Ich dachte es wäre ein „IT“-Projekt!“ Ist es nicht! Denn die gesamte Organisation ist gefordert und es geht primär um die Einführung von zum Teil vollständig neuen Prozessen und Arbeitsabläufen. Dies hat zur Konsequenz, dass Mitarbeiter auf einmal völlig neue Rollen und Aufgaben haben! Im worst case (aus Sicht des Mitarbeiters) ist dessen Aufgabe „weg-automatisiert“ worden. Was dann? Solche Themen müssen angegangen werden. Hier ist Führung und Coaching gefordert. Und der Betriebsrat muss frühzeitig im Boot sein.

12.  Last, but not least: Es fehlt leider viel zu oft ein echter Projektabschluss mit Übergabe an die Linie und Unterschriften aller Top-Manager sowie der gemeinsam verabschiedeten Offenen-Punkte-Liste. Nur ein solches, offizielles Dokument macht klar, dass das Projekt abgeschlossen wurde, in welchem Zustand es übergeben wurde und was noch offen ist und wer sich bis wann darum kümmert. Das ist dann nicht mehr Projektaufgabe, sondern Verantwortung der Linie und das Projekt mit seinem Projektleiter sowie Projektmitgliedern ist entlastet und ebenfalls wieder zurück in die Linie oder in ein neues Projekt beordert.

Ach, irgendwie tat es auch gut, diese 12 Punkte einfach mal so runterzuschreiben. Wenn noch was fehlt oder unklar ist, geben Sie gerne Bescheid. Ein ERP-Projekt ist ab einer gewissen Unternehmensgröße immer eine echte Herausforderung für alle Beteiligten und natürlich das Unternehmen selbst mit seinen Kunden und Lieferanten.

Neben den zwölf hier genannten Problemfeldern und dem großen Risiko des Scheiterns stellt sich natürlich die berechtigte Fragen des Nutzens und Mehrwertes. Wenn ich als Geschäftsführer oder Vorstand ein solches Projekt auf die Tagesordnung setze, dann muss ich meinen Gesellschaftern und Kunden auch erklären können warum ich das tue.

Welchen Mehrwert in Form von Kundennutzen, Prozesseffizienz oder Wettbewerbsstärke hat ein so großes und risikobehaftetes Projekt wirklich? Oder andersherum gefragt: Wann ist wirklich der „point of no return“ erreicht, zu dem das bestehende ERP nicht mehr zukunftsfähig ist und eine neue Lösung unumgänglich ist?

Darum geht es in einem der nächsten Blogbeiträge.

Bleiben Sie gespannt! Es grüßt Sie herzlich!

Volker Johanning