Woran ERP-Projekte wirklich scheitern

Auch im Zeitalter der digitalen Plattformökonomie – geprägt durch digitale Champions, wie Google, Apple, Facebook und Amazon – spielen Enterprise Resource Planning (ERP)-Systeme nach wie vor eine wichtige/tragende Rolle in den IT-Landschaften der meisten Unternehmen. Die wesentliche Wertschöpfung von ERP-Systemen besteht zunächst in der Integration von Unternehmensfunktionen/-prozessen und der funktions-/prozessübergreifenden Steuerbarkeit von Unternehmen.

Darüber hinaus sind die Aspekte der „Governance“ und „Compliance“ durch gesetzliche bzw. regulatorische Anforderungen in den vergangenen Dekaden immer stärker in den Vordergrund gerückt. Und schließlich zwingt die fortschreitende Digitalisierung und der Wettbewerb mit digitalen Plattformunternehmen viele Unternehmen mit ihren linearen Geschäftsmodellen dazu, sich intensiver mit der Frage auseinanderzusetzen, wie sie ihre Stamm- und Bewegungsdaten nutzen können, um ihre Kunden besser zu bedienen bzw. neue Kunden zu gewinnen.

Nun sollte man meinen, dass die große Mehrheit der Unternehmen 25 Jahre nach der Markteinführung von SAP R/3 in 1993 genug Kompetenzen aufgebaut bzw. Erfahrungen gesammelt hat, um ERP-Einführungsprojekte ohne große Probleme stemmen zu können. Trotzdem hört man immer wieder von Projekten, die hinsichtlich Zeit, Kosten oder Qualität signifikant aus dem Ruder gelaufen sind. Warum ist das eigentlich so?

Google liefert auf die Suchanfrage „Woran ERP-Projekte scheitern“ 13.200 Treffer, darunter befinden sich recht fundierte Analysen, wie z. B. der Artikel von Bernd Hilgenberg (ehemaliger CIO der Handelskette „Fressnapf“) aus der Computerwoche vom 02.07.2014 unter der Überschrift „Fehler bei der ERP-Einführung: Woran ERP-Projekte wirklich scheitern“: https://www.computerwoche.de/a/woran-erp-projekte-wirklich-scheitern,2530844.

Aus diesem Artikel möchte ich folgende substanzielle Beobachtung zitieren, die bereits einen der „root causes“ für problematische ERP-Projektverläufe adressiert:

„Der Vorteil von ERP-Systemen – ihr integrierter Ansatz – kann sich unter Umständen nachteilig auswirken. Ein ERP-System zeichnet sich bekanntlich durch seine stark prozessorientierte Sicht- und Arbeitsweise aus, und diese Eigenart ist der Keim vieler Probleme in der Einführung und im Betrieb.

In einer verteilten Softwarelandschaft mit unterschiedlichen Anwendungen nutzen einzelne Abteilungen jeweils auf ihre individuellen Bedürfnisse zugeschnittene Software. Die Kommunikation zwischen den Anwendungen geschieht über Schnittstellen, die jedoch meist nur Teilmengen an Informationen austauschen. So kann jeder Unternehmensbereich das eigene System optimieren und verändern, ohne die nachfolgenden Systeme zu berühren. Damit entstehen einzelne Ökosysteme mit häufig jeweils eigenem Reporting.

Das hat zwei Konsequenzen: Zum einen ist die Durchgängigkeit von Prozessen über die Bereiche hinaus nicht gewährleistet. Zum anderen entwickeln eigene Systeme automatisch auch eigene Zahlen, deren Richtigkeit sich schwer überprüfen lässt oder die Spielraum für Interpretationen eröffnen. Hier existiert also kein „Single-Point-of-Truth“. Unternehmen verlieren so an Steuerungs- und Wettbewerbsfähigkeit.“

Zitat Ende

Neben den eingangs genannten unbestreitbaren Vorteilen einer ERP-Einführung aus gesamtunternehmerischer Sicht (Integration, Transparenz, Steuerbarkeit, Governance, Compliance, Kundenservice) können ERP-Systeme durchaus Nachteile für einzelne Funktionen und Prozesse eines Unternehmens mit sich bringen, wenn man sie aus dem Blickwinkel der dezentralen Unternehmenseinheiten betrachtet. Beispiele:

• Schlechtere Prozessunterstützung im Vergleich zu den bisherigen IT-Systemen, da diese nicht selten maßgeschneidert und individuell für die Funktion bzw. den Prozess entwickelt wurden. Auch die ungewohnte Benutzeroberfläche und der aus Anwendersicht geringere Bedienkomfort des neuen Systems können Anwender (vor allem wenn sie unzureichend geschult sind und nach der Einführung nicht angemessen betreut werden) leicht gegen das neue ERP-System aufbringen. Der Mensch ist ein Gewohnheitstier und niemand akzeptiert gerne widerspruchslos, dass sich sein über Jahre mühsam eingerichtetes und optimiertes Arbeitsumfeld durch ein neues IT-System schlagartig verschlechtert.
• Mehraufwand durch die notwendige höhere Qualität bzw. den größeren Umfang bei der Erfassung von Bestands- und Bewegungsdaten. So müssen Auftragsabwickler zum Beispiel plötzlich Daten erfassen, die sie „früher nie gebraucht haben“, „nur damit irgendwelche Sesselfurzer in der Zentrale sich mit nutzlosen Auswertungen beschäftigen können“. Die Integration von Prozessen (Vertrieb, Engineering, Service, Buchhaltung, …) mit der angestrebten Einmalerfassung von Daten kann zu Mehraufwänden insbesondere am Anfang der Prozesskette führen (die in der Regel lautstark kommuniziert werden), während die Minderaufwände am Ende der Prozesskette meistens verschämt verschwiegen werden. Auch die Standardisierung bzw. Harmonisierung von Nummernkreisen oder Datenschlüsseln verursacht zunächst nur zusätzliche Aufwände, ohne dass der Großteil der Mitarbeiter einen Nutzen daraus ziehen könnte.
• Nicht jeder mag Transparenz, denn sie führt dazu dass die Leistungen der verschiedenen Unternehmensfunktionen besser gemessen und miteinander verglichen werden können. Und nicht jeder begreift es als Chance, die Leistungs- und Wettbewerbsfähigkeit der eigenen Unternehmenseinheit durch systematische Vergleiche mit den Leistungskennziffern („Key Performance Indicators“) anderer Unternehmenseinheiten verbessern und optimieren zu können. Hinzu kommt das „Not-invented-here“-Syndrom, denn naturgemäß sind Führungskräfte und Mitarbeiter in den verschiedenen Unternehmenseinheiten häufig davon überzeugt, ihren Job bestmöglich zu erledigen und nicht auf „Best-Practices“ aus anderen Unternehmenseinheiten angewiesen zu sein. Oder es gibt separate Inselprojekte zur Suboptimierung von Teilfunktionen (häufig HR oder Einkauf), die sich ungern in zentrale IT-Programme integrieren (weil die zentrale IT „ja zu viel langsam ist und von unseren Prozessen und deren Besonderheiten eh keine Ahnung hat“).

Es „menschelt“ also an allen Ecken und Enden und jeder Entscheidungsträger ist gut beraten, seine Entscheidungen zur Durchführung von ERP-Projekten (einschließlich deren Fokus und Umfang) nicht ausschließlich aus dem gesamtunternehmerischen Blickwinkel zu treffen. Vielmehr müssen die Konsequenzen und Seiteneffekte für alle Funktionen und Prozesse des Unternehmens systematisch auch aus dem Blickwinkel der betroffenen Führungskräfte und Mitarbeiter betrachtet, durchdacht, offen und ehrlich mit den Betroffenen erörtert und deren Erwartungshaltung moderiert werden. Je komplexer Geschäftsmodell sowie Aufbau- und Ablauforganisation eines Unternehmens, desto schwieriger ist es, sinnvolle und angemessene Entscheidungen im Hinblick auf Einsatz und Ausgestaltung von ERP-Systemen zu treffen. Zumal der Teufel erfahrungsgemäß im Detail liegt, so dass selbst bei bester Planung nicht alle potenziellen Stolperfallen rechtzeitig identifiziert und entschärft werden können.

„Think big“-Ansätze führen prinzipiell eher zu großen, umfangreichen und langlaufenden ERP-Projekten, durch die gravierende Versäumnisse der Vergangenheit (z. B. heterogene, fragmentierte IT-Landschaften mit einer Vielzahl von Datensilos) auf einen Schlag repariert und behoben werden sollen. Obgleich zentrale IT-Architekturen aus gesamtunternehmerischer Sicht durchaus viele Vorteile bieten, bergen solche Großprojekte eine wesentlich höhere Gefahr, sich zu verzetteln und die Organisation durch zu viele Veränderungen auf einen Schlag zu überfordern. Ich will damit nicht ausdrücken, dass solche Großprojekte per se nicht erfolgreich sein können, allerdings wird selbst das beste Projektteam besetzt mit Top-Experten aus IT und Business bei optimalem Projektverlauf nicht in der Lage sein, sämtliche Geburtswehen zu vermeiden, wenn an zu vielen Schrauben auf einmal gedreht wird.

Zudem lassen sich insbesondere in großen Unternehmen normalerweise wesentliche Rahmenbedingungen, wie die Aufbau- und Ablauforganisation oder das Geschäftsmodell, nicht über Zeiträume von mehr als 18 bis 24 Monaten stabil halten. Neben dem „Faktor Mensch“ sind wesentliche Veränderungen des Projektauftrags in fortgeschrittenem Projektstadium ein häufiger Grund dafür, dass ERP-Einführungsprojekte ins Schlingern kommen. Auch agile Vorgehensmodelle helfen Ihnen nicht, wenn Sie bildlich gesprochen das Projektteam zunächst auf die Reise schicken, um einen Familienwagen zu entwickeln und auf halber Strecke die Anforderung stellen, dass dieser Familienwagen auch Rennen gewinnen und/oder Lasten transportieren können muss.

Bernd Hilgenberg weist in seinem Computerwoche-Artikel vom 02.07.2014 auf ein weiteres signifikantes Risiko hin:

„Lässt sich dieses Manko (= Fehlen eines Single-Point-of-Truth) durch die Einführung eines ERP-Systems per se beheben? Leider nein! Auch ein integriertes ERP-System kann so konfiguriert oder besser verbogen werden, dass sich die Module wie selbständige Anwendungen verhalten. Das daraus produzierte Zahlenwerk ist dann genauso wenig durchschaubar. Damit besteht die konkrete Gefahr, dass ein Unternehmen in wirtschaftliche Probleme gerät, weil ein schlecht konfiguriertes ERP-System dauerhaft hohe Kosten verursachen kann. Zudem beraubt sich das Unternehmen der Möglichkeit, aus den vorhandenen Zahlen rechtzeitig negative Geschäftsentwicklungen zu erkennen sowie die eigenen Prozesse zu optimieren.“

Diese Beobachtung deckt sich absolut mit meinen eigenen Erfahrungen und möchte sie noch durch den wichtigen Hinweis ergänzen, dass Standardsoftware unter dem Druck der Anwender nicht selten durch Modifikationen und Erweiterungen so verbogen und modifiziert wird, dass die Vorteile aus dem Einsatz von Standardsoftware (z. B. Teilhabe an kontinuierlichen Weiterentwicklungen des Standards durch den Hersteller) nicht mehr zum Tragen kommen, da die verbogenen ERP-Systeme de facto nicht mehr releasewechselfähig sind.

Der Einsatz von Standardsoftware und Cloud-basierter Software – letztere vor allem, wenn man sie als Software as a Service (SaaS) nutzen will (siehe: https://www.computerwoche.de/a/was-sie-ueber-die-cloud-wissen-muessen,2504589,2) ist vor allem (ich sage nicht „ausschließlich“) für diejenigen Funktionen und Prozesse eines Unternehmens sinnvoll, die weder wettbewerbsdifferenzierend sind, noch das Kundenerlebnis („Customer Experience“) maßgeblich beeinflussen.

Man kann von einer Standardsoftware grundsätzlich nicht erwarten, dass sie spezifische Unternehmensprozesse genauso gut unterstützt, wie maßgeschneiderte Individualsoftware, und man sollte sich davor hüten, eine Erwartungshaltung zu wecken bzw. zu schüren, dass Anzüge von der Stange genauso gut sitzen wie Maßanzüge – das ist fast immer unrealistisch. Diese Feststellung gilt unabhängig davon, dass Standardsoftware durch Customizing normalerweise bis zu einem gewissen Grad an spezifische Anforderungen einzelner Unternehmen bzw. Unternehmenseinheiten angepasst werden kann. Bevor Sie ein Projektteam beauftragen, ihr vorhandenes IT-System Eins-zu-eins durch ein ERP-System abzulösen, verbrennen Sie Ihr Geld besser für andere Zwecke, denn das ist in der Regel aus folgenden Gründen eine sinnlose Mission impossible:

• Zum einen ist es in bestimmten Fällen durchaus gewollt, vorhandene Freiheitsgrade in den Geschäftsprozessen, z. B. bei der Erfassung und Bearbeitung von Aufträgen bzw. Daten, im Zuge einer ERP-Einführung einzuschränken, um spätere Möglichkeiten zu einer differenzierten Auswertung zu gewährleisten oder um rechtlichen Anforderungen Genüge zu tun.
• Zum anderen sollte die Einführung einer Standardsoftware unbedingt dazu genutzt werden, um die Geschäftsprozesse zu verschlanken und alte Zöpfe abzuschneiden. Wenn nicht jetzt, wann dann? Die Ausgestaltung eines ERP-Systems sollte sich nicht an der Vergangenheit eines Unternehmens ausrichten, sondern an dessen Zukunft, weshalb die frühzeitige Einbeziehung von Unternehmensfunktionen, wie Strategie oder Business Development für den Erfolg von ERP-Projekten unabdingbar ist.

Die Entwicklung von Individualsoftware für Unternehmen ist in den vergangenen dreißig Jahren (soll man sagen „leider“?) völlig aus der Mode gekommen, sollte aber nicht dogmatisch ausgeschlossen werden, da Unternehmensprozesse nun einmal maßgeblich durch die sie tragenden IT-Systeme beeinflusst werden und Standardsoftware ein Unternehmen in der Regel nicht in die Lage versetzt, sich von seinen Wettbewerbern zu differenzieren (zumindest nicht dauerhaft). Der Erfolg digitaler Plattformunternehmen, wie Google, Apple, Facebook oder Amazon beruht nicht zuletzt auf deren Fähigkeit, ihren Kunden eine einfache Benutzeroberfläche anzubieten, um mit ihnen ins Geschäft zu kommen und im Zuge dessen möglichst viele kundenspezifische Daten zu erfassen und für eigene Zwecke nutzbar zu machen.

Die Erwartungshaltung (insbesondere des Top-Managements) muss auch noch in einem weiteren wichtigen Punkt in die richtige Richtung gemanagt werden: Ich kenne kein großes ERP-Projekt, das vor Projektbeginn in der Lage gewesen wäre, belastbare Aussagen zu den Auswirkungen der ERP-Einführung auf die zukünftigen Prozesskosten des Unternehmens zu treffen – häufig allein schon deshalb, weil die Prozesskosten im Ist-Zustand nicht bekannt sind und damit die Bezugsbasis („Baseline“) für Vergleiche fehlt.

Während man die Kostenseite des ERP-Projektes nach der Definitionsphase auf Basis von Erfahrungswerten und Annahmen einigermaßen qualifiziert und realistisch kalkulieren kann – und zwar sowohl im Hinblick auf die Kosten für Customizing und Entwicklung von notwendigen Erweiterungen des ERP-Systems (Stichwort: Fit-Gap-Analysen, Schätzklausuren), als auch im Hinblick auf die Kosten für den Roll-out inklusive Schulungen, Vor-Ort-Betreuung und Babysitting sowie auf die Kosten für den zukünftigen Betrieb des ERP-Systems – halte ich qualifizierte Abschätzungen zu den Auswirkungen einer ERP-Einführung auf die zukünftigen Prozesskosten eines Unternehmens für schwierig bis unmöglich.

Dies hat auch einen Grund, denn wenn die Implementierung eines ERP-Systems abgeschlossen wurde, ist die wesentliche Arbeit nicht beendet, sondern sie fängt damit erst an, denn nun gilt es, das ERP-System und seine Möglichkeiten zur funktions- und prozessübergreifenden Steuerung und Optimierung des Unternehmens systematisch zu nutzen. Dies setzt wiederum voraus, dass entsprechende Funktionalitäten zur Messung der Prozessleistung vorhanden sind und auch genutzt werden.

Dies führt uns unmittelbar zu der Binsenweisheit, dass ein ERP-System nur dann die angestrebte funktions-/prozessübergreifende Steuerbarkeit des Unternehmens ermöglichen kann, wenn die Daten in dem ERP-System eine angemessene Qualität haben. Um diese zu gewährleisten, müssen in der Regel vor der Übernahme von Daten aus vorhandenen IT-Systemen aufwändige Datenbereinigungen durchgeführt werden, die bei den damit betrauten Anwendern zumeist auf wenig Begeisterung stoßen, da sie diese häufig als Zusatzaufgabe zu ihrem normalen Vollzeitjob aufs Auge gedrückt bekommen. Darüber hinaus muss gewährleistet werden, dass neue Daten (z. B. Kunden, Lieferanten, Aufträge) im ERP-System mit hinreichender Datenqualität erfasst werden können. Dazu sind häufig Pflegeprozesse und Qualitätssicherungsmechanismen zu implementieren, die es in der alten IT-Systemlandschaft in dieser Form nicht gab. In jedem Fall muss eine ERP-Einführung eingebettet sein in die Definition und Ausgestaltung eines integrierten Datenmodells und eines IT-Bebauungsplans in dem die Schnittstellen und Abhängigkeiten zum Rest der IT-Landschaft dokumentiert werden.

Bernd Hilgenberg nennt in seinem Computerwoche-Artikel vom 02.07.2014 noch weitere wesentliche Fehler bei der Einführung von ERP-Systemen, wie z. B. eine zu starke Abhängigkeit von externen Beratern („Beraterhörigkeit“), die häufig dadurch verursacht bzw. verstärkt wird, dass dezentrale Unternehmenseinheiten nicht bereit sind, ihre Top-Leute an ERP-Einführungsprojekte abzugeben. In manchen Fällen führt dies dazu, dass externe Berater grundlegende Richtungsentscheidungen treffen (müssen), die eigentlich von internen Mitarbeitern des Unternehmens getroffen werden müssten.

Die vorgenannte Auflistung erhebt keinen Anspruch auf Vollständigkeit (z. B. fehlen „no-brainer“ wie das notwendige Backing durch das Top-Management, intensive Zusammenarbeit zwischen IT und Business bei der Einrichtung des ERP-Systems oder der Hinweis auf den Einfluss der Unternehmens- und Führungskultur), sie sollte aber zumindest alle „big points“ von entscheidender Bedeutung umfassen. Falls aus Ihrer Sicht wichtige Punkte fehlen, bin ich für entsprechende Hinweise dankbar.

Fazit:

Eine sorgfältige Analyse, ob bzw. in welchem Umfang das (zukünftige) Geschäftsmodell und die (zukünftigen) Geschäftsprozesse eines Unternehmens durch Standardsoftware anforderungsgerecht unterstützt werden können, ist die wesentliche Voraussetzung für den Erfolg von ERP-Einführungsprojekten und anderen Projekten in denen (Cloud-basierte) Standardsoftware eingeführt werden soll. Diese Analyse muss als wesentliche Grundlage zur Festlegung eines sinnvollen und machbaren Projektumfangs dienen. Nicht alles, was aus gesamtunternehmerischer Sicht sinnvoll und wünschenswert ist, kann in der Praxis auch im gesamten Unternehmen umgesetzt werden. Eine ganz zentrale Frage dabei ist, wie viel Veränderungsleistung man der eigenen Organisation zumuten kann bzw. will. Die Antwort auf diese Frage hängt u. a. von Größe, Heterogenität und Personalqualität der betroffenen Organisationen ab. Veränderungsmanagement, Schulungs- und Betreuungsmaßnahmen sind unabdingbar, jedoch keine Garantie für einen reibungslosen Projektablauf. Entsprechend der Gauß’schen Normalverteilung werden sich in der Regel ca. 15 bis 20% der Führungskräfte und Mitarbeiter in einer Organisation schwer tun, die notwendigen Veränderungen im Zuge einer ERP-Einführung zu akzeptieren und umzusetzen. Grundlegende Veränderungen des Projektauftrags während der Projektlaufzeit sollten vermieden werden. Ohne ein integriertes Datenmodell und Maßnahmen zur Sicherstellung einer angemessenen Datenqualität wird ein ERP-Projekt genauso wenig erfolgreich sein können, wie ohne die Einbettung in einen IT-Bebauungsplan als Grundlage für das Management von Schnittstellen und Abhängigkeiten zu vor- und nachgelagerten IT-Systemen. Schließlich sollte eine zu starke Abhängigkeit von externen Beratern vermieden werden.

Sollte Ihnen dieser Blog zum Thema ERP-Projekte gefallen haben, finden Sie unter https://kubraconsult.blog/2017/09/06/digitale-geschaeftsmodelle-und-plattformoekonomie/ meinen Blog vom 06.09.2017 zum Thema „Digitale Geschäftsmodelle und Plattformökonomie“ und unter https://kubraconsult.blog/2018/01/13/krypto-assets-die-wichtigsten-fragen-und-antworten/ meinen Blog vom 13.01.2018 zum Thema „Krypto Assets – die wichtigsten Fragen und Antworten“.