ERP Einführungen – Komplexität nach wie vor massiv unterschätzt
Bereits im 2012 durfte ich an einem WinLink Referat über meine Erfahrungen bei einer grösseren ERP Einführung sprechen. Damals unter dem provokativen Titel
«Ist die Krise bei der Umsetzung von ERP Einführungen vorprogrammiert?»
In meiner Präsentation nahm ich den Standish Group’s CHAOS Report zur Hilfe um aufzuzeigen, dass laut dieser Statistik nur ca. 30% aller IT-Projekte (über 5 M USD) auf Anhieb erfolgreich sind, ca. 70% irgendwann einmal (zT massive) Probleme bekommen und dann ca. 20 % der Projekte gestoppt und ganz abgeschrieben werden müssen.
Nach zahlreichen Mandaten im Umfeld von IT- Projekten, ist diese Statistik unterdessen ein fixer Bestandteil meines Repertoires geworden.
Auch kürzlich, fast 10 Jahre später, musste ich erneut auf diesen Report zugreifen und einem Executive Board erklären, dass ihr Projekt hochgradig gefährdet ist und wir nun alles daransetzen müssen, damit es nicht vollständig zum Fehlschlag wird. Getreu dem Thema von Rilke : «Wer spricht hier von Siegen, überstehen ist alles».
Es ist ernüchternd, dass auch heutzutage mit all den neuen Methodologien (Agil, Scrum, Sure Step, ASAP, etc) ein IT-Projekt immer noch nicht eine grössere Chance als ca. 30% hat, auf Anhieb erfolgreich zu sein. Noch schlimmer, dass immer noch über ca. 20% der IT-Projekte gestoppt und ganz abgeschrieben werden müssen.
Prominenteres Beispiel aus der Gegenwart ist zB die SAP Einführung bei V-Zug, welche das Mutterhaus Metall Zug zu einer Gewinnwarnung zwang. Aber es gibt noch viele andere IT-Projekte, welche weniger öffentlich in Schieflage geraten sind.
Zahlreiche Beratungsfirmen produzieren am Laufmeter Hochglanz-Präsentationen, welche aufzeigen sollen, wie man es richtig macht. Doch leider ohne wirklich durschlagenden Erfolg.
Woran liegt es wirklich, dass IT-Projekte (zB ERP Einführungen) immer noch zu oft fehlschlagen? Hier ein Erklärungsversuch aus meiner Erfahrung der letzten 10+ Jahre
- Ein Unternehmen wird nur ca. alle 10-20 Jahre ein neues ERP einführen. Das bedeutet, dass die diesbezügliche Erfahrung im Unternehmen nicht (mehr) vorhanden ist. Für die meisten Projektleiter (aber auch Projektsponsoren, Lenkungsausschüsse, etc), ist es das erste Mal, dass sie für ein hochkomplexes IT-Projekt die Verantwortung tragen müssen. Die Erwartungen sind hoch und manch einer möchte sich ja im Unternehmen auch profilieren. Daher ist man nur allzu gerne bereit, selbst zu sehr unrealistischen Terminvorgaben u/o Budgets ja zu sagen. Am Ende weiss man es oftmals einfach nicht besser und es gibt ja auch kein ERP ab Stange, zu einem Standardpreis.
- Viele Unternehmen haben als Ausgangslage ein eigen-entwickeltes ERP, welches über die letzten 10+ Jahre hochgradig auf die Anforderungen des Unternehmens ausgerichtet wurde und zusammen mit dem Unternehmen gewachsen ist. Nun wurde aber die Weiterentwicklung zu teuer und man hat sich (auf Drängen des Verwaltungsrates) deshalb entschlossen, auf eine Standardsoftware (SAP, MS Dynamics, Oracle, etc.) zu wechseln. Hier kommt aber bereits die erste Herausforderung, indem man sich nun entscheiden muss, ob das Unternehmen seine angestammten und optimierten Prozesse an das neue Standardtool anpassen (Best-practice) oder aber das Standardtool wiederum hochgradig auf die eigenen Anforderungen ummünzen soll. Beides ist möglich, das letztere kostet einfach sehr viel Zeit und Geld.
- Oftmals zeigt sich dann, dass die Prozesse zwar aktuell gelebt werden, nie aber richtig dokumentiert wurden. Das wiederum macht es natürlich schwierig eine verlässliche Schätzung des Aufwands zu erstellen. Hier empfiehlt sich sicherlich in einem Vorprojekt die to-be Prozesse einmal strukturiert aufzunehmen und in einem BPM (Business-Process-Modeling) Tool festzuhalten. Viele Unternehmen scheuen aber den Aufwand hierfür und versuchen die Prozesse parallel zur Implementation zu definieren. Diese Fast-track Methodologie hat den grossen Nachteil, dass der Scope des Projekts nur sehr high-level definiert werden kann und daher eine Abschätzung des notwendigen Zeit- & Geldbedarfs sehr ungenau wird.
- Bei dieser Aufnahme der Prozesse werden naturgemäss Begehrlichkeiten geweckt. Die Erwartungshaltung der Benutzer ist hoch und das neue System soll für alle Unzulänglichkeiten des bestehenden Systems herhalten, dieses in allen Belangen übertreffen. Dem Hauptvorteil eines neuen Systems, nämlich der verbesserten Erweiterbarkeit und ggf. konzernübergreifender Transparenz, wird hier zu wenig Beachtung geschenkt. Sehr oft kommt es in dieser Phase zu einem schleichenden «Scope creep», bei dem alle Stakeholder noch sicherstellen wollen, dass auch ihre Ansprüche an das neue System berücksichtigt werden. Schlussendlich sind die Anforderungen an das neue System derart hoch, dass es schon technisch unmöglich wird, diese zu realisieren.
- Was zudem oftmals vergessen geht, ist die Einordung des neuen Systems in eine übergeordnete Digitale Strategie. Das ERP (ggf. schon historisch als Daten Silo konzipiert) wird erneut als Daten Silo geplant, ohne Abstimmung mit den umliegenden Systemen (CRM, CAQ, MES, etc). Die Folge davon sind erneut hochkomplexe Schnittstellen und eine verpasste Möglichkeit, mit diesem ERP Ersatz auch das Unternehmen digital zu transformieren.
Eine saubere Abklärung und Einordnung in die übergeordnete Digitalisierung helfen, das Projekt besser zu positionieren. Auch muss entschieden werden, ob sich das Unternehmen mit dieser ERP Einführung mehr nach den Prozessen ausrichten will. Wenn dem so ist, geht es hier nicht mehr nur um ein IT-Projekt, sondern um eine vollumfängliche Business Transformation mit allen Konsequenzen und Anforderungen an ein angepasstes Change-Management. - Bevor über ein Standardtool (SAP, MS Dynamics, Oracle, etc.) nachgedacht werden kann, müssen die Prozesse klar definiert werden. Dennoch fangen viele Unternehmen viel zu früh mit dieser Diskussion an und vergeben sich damit wertvolle Entscheidungsoptionen.
Die Toolfrage kommt erst sehr viel später im Projekt. Wichtiger ist es das «was» zu verstehen, bevor man über das «wie» nachdenkt.
Fazit
Meine Erfahrung der letzten 10+ Jahre zeigt, dass IT-Projekte nach wie vor massiv unterschätzt und «nebenbei» eingeführt werden. Ohne den richtigen Fokus sind solche IT-Projekte aber zum Scheitern verurteilt.
Der Erfolg oder Misserfolg einer ERP Einführung beginnt bereits mit den strategischen Überlegungen ganz am Anfang eines Projektes. Ohne klare Strategien über das «was» wird ein jedes IT-Projekt früher oder später beim «wie» scheitern.
Folgende Aktivitäten müssen in dieser Sequenz durchgeführt werden:
- Entscheid über Einbindung in eine übergeordnete Digitalisierungsstrategie (Digitale Business Transformation)
- Definition der to-be Prozesse
- Wahl einer auf die Unternehmensbedürfnisse angepassten Standardsoftware (SAP, MS Dynamics, Oracle, etc.)
- Wahl eines geeigneten und reputierten Implementierungspartners
- Bereitstellung der notwendigen Strukturen, sowie eines dedizierten (100%) und erfahrenen Projektteams. Ein ERP Einführung ist kein gutes Projekt, um sich seine Sporen abzuverdienen…
Am Schluss noch der Tipp, sich auch regelmässige mit anderen Unternehmen auszutauschen, welche sich in einer analogen Transformation befinden (Erfa-Gruppe) und ggf. einen externen Berater einzubeziehen (als Sounding Board, für einen Audit oder als Teil des Lenkungssauschusses).
Viel Erfolg bei Ihrem IT-Projekt!
Kommentare sind geschlossen.