Viele Unternehmen nennen ihr ERP-Projekt gescheitert, sobald Go-Live-Termine mehrfach verschoben sind und das Budget längst überschritten ist. Nach einer Untersuchung von Horváth zu SAP-S/4HANA-Transformationen reißen 60 Prozent der Projekte Budget und Zeitplan (Horváth, 03/2025). Wer die typischen Muster einer solchen Krise kennt, kann früher gegensteuern, statt erst beim Blick auf die Restbudgetliste zu reagieren.
Als ERP-Projekt gescheitert gilt ein Vorhaben, wenn Budget, Zeitplan oder die geplante Prozessqualität dauerhaft aus dem Ruder laufen. Nach Horváth (03/2025) betrifft das 60 Prozent der SAP-Transformationen, im Schnitt dauern sie 30 Prozent länger als geplant. Wer früh die typischen Ursachen erkennt, kann gegensteuern, bevor ein Abbruch die einzige Option bleibt.
Die häufigsten Gründe, warum ein ERP-Projekt gescheitert ist
Horváth hat SAP-S/4HANA-Transformationen untersucht und kommt zu einem deutlichen Befund. 60 Prozent der Projekte reißen Budget und Zeitplan, im Durchschnitt dauern sie 30 Prozent länger als ursprünglich geplant (Horváth, 03/2025). Selbst dort, wo am Ende ein Go-Live steht, bleibt häufig ein Rest an offenen Mängeln zurück.
der Unternehmen berichten trotz Budget- und Terminüberschreitung zusätzlich von Qualitätsmängeln im laufenden Betrieb.
Horváth, 03/2025
Ein Grund dafür liegt im Zuschnitt der Projekte selbst. Nach derselben Untersuchung sagen 78 Prozent der befragten Unternehmen, dass zu viele Themen gleichzeitig in die Transformation gepackt werden (Horváth, 03/2025). Ein ERP-Projekt, das parallel zur Systemumstellung noch die Organisationsstruktur, das Berichtswesen und mehrere Altlasten mit erledigen soll, verliert den Fokus, den ein Programm dieser Größe braucht.
Wie tief dieser Effekt reicht, zeigt ein zweiter Befund. Die Computerwoche berichtet unter Berufung auf einen ISG-Report, dass nur 18 Prozent der Unternehmen ihre Prozesse im Zuge der Migration tatsächlich neu gestalten, 49 Prozent übernehmen die alten Abläufe weitgehend unverändert (Computerwoche, 02/2026). Wer die neue Software wie die alte bedient, verschenkt einen Großteil des eigentlichen Nutzens und zahlt trotzdem die vollen Projektkosten.
| Ursache | Wirkung im Projekt |
|---|---|
| Umfangserweiterung | Zusätzliche Themen verdrängen den ursprünglichen Kern des Vorhabens |
| Schwaches Projektmanagement | Risiken und Verzögerungen werden spät statt frühzeitig sichtbar |
| Unterschätzte Testphase | Fehler zeigen sich erst kurz vor oder nach dem Go-Live |
| Unterschätzte Datenmigration | Altdaten passen nicht zum neuen Datenmodell, Nacharbeit bindet Kapazität |
| Ausbleibende Entscheidungen | Offene Fragen stauen sich auf und verzögern nachgelagerte Arbeitspakete |
Diese fünf Ursachen treten selten einzeln auf. Ein zu großer Projektumfang erschwert das Projektmanagement, ein überlastetes Projektmanagement schiebt Entscheidungen weiter vor sich her, und ausbleibende Entscheidungen lassen wiederum die Testphase zusammenschrumpfen. Wer nur eine dieser Ursachen behebt, während die anderen bestehen bleiben, verschiebt das eigentliche Problem meist nur um wenige Wochen. Wie sich ein wachsender Projektumfang von Anfang an eingrenzen lässt, beschreibt der Beitrag Scope Creep stoppen: Wie Projekte ihren Rahmen zurückbekommen.
Welche Schritte aus der ERP-Krise herausführen
Der erste Schritt ist eine nüchterne Bestandsaufnahme, unabhängig von der bisherigen Projektorganisation. Wer den eigenen Status selbst berichtet, neigt dazu, Fortschritt optimistischer darzustellen, als er ist, besonders wenn die eigene Position an einem positiven Ausgang hängt. Das lässt sich niemandem persönlich vorwerfen, ändert aber nichts daran, dass die Zahlen am Ende stimmen müssen. Eine externe Sicht auf Budget, Testabdeckung und offene Entscheidungen schafft die Grundlage, auf der sich überhaupt sinnvoll weiterplanen lässt. Ohne diesen Schritt wird jede weitere Planung auf einem Zahlenbild aufgebaut, das der Realität schon hinterherhinkt.
Darauf folgt eine klare Trennung zwischen Muss und Kann. Themen, die ursprünglich nicht Teil des Projekts waren, gehören zurück in ein separates Vorhaben, selbst wenn das unbequem ist und Stakeholder enttäuscht. Ein Projekt, das wieder auf seinen ursprünglichen Kern reduziert wird, gewinnt an Steuerbarkeit zurück.
Test- und Datenmigrationsphasen brauchen anschließend einen eigenen, realistischen Zeitplan statt eines Restpuffers am Projektende. Wer Migrationsläufe erst kurz vor dem Go-Live zum ersten Mal vollständig durchspielt, entdeckt Datenprobleme zu spät, um sie noch geordnet zu beheben.
Offene Entscheidungen schließlich brauchen einen Namen und einen Termin. Ein Entscheidungsstau lässt sich selten durch mehr Meetings auflösen, meist braucht es eine funktionierende Projekt-Governance mit einer einzelnen Person, die die Befugnis hat, eine offene Frage endgültig zu klären. Manchmal führt der Weg aus der Krise über den Wechsel des ausführenden Partners. Wie sich das rechtlich und technisch geordnet umsetzen lässt, zeigt der Beitrag Dienstleister wechseln im laufenden Projekt: Rechtlich und technisch geordnet.
Nicht jedes ERP-Projekt in der Krise lässt sich retten. Passt die ursprüngliche Systementscheidung nicht mehr zum Geschäftsmodell, oder übersteigen die verbleibenden Kosten eines Weiterarbeitens die Kosten eines Neustarts, ist ein geordneter Abbruch die günstigere Entscheidung, so unbequem er im Moment wirkt.
Standortbestimmung für das eigene ERP-Projekt
Eine externe Einschätzung von Budget, Zeitplan und Risiken lässt sich in der Regel innerhalb weniger Tage terminieren.
Häufige Fragen
Woran erkennt man früh, dass ein ERP-Projekt gescheitert ist?
Frühe Warnzeichen sind wiederholt verschobene Meilensteine, eine wachsende Liste ungeklärter fachlicher Fragen und Testphasen, die im Zeitplan systematisch verkürzt werden, sobald es eng wird. Auch ein steigender Anteil an Umgehungslösungen im Projektalltag deutet darauf hin, dass die ursprüngliche Planung nicht mehr zur Realität passt. Ein weiteres Signal steckt im Ton der Statusberichte. Wo Zahlen durch Formulierungen ersetzt werden, fehlt meist genau die Zahl, die niemand berichten möchte.
Nachverhandeln oder abbrechen?
Das hängt von der Ursache ab. Liegt das Problem an Umfang, Ressourcen oder Zeitplan, lässt sich meist nachverhandeln, etwa über einen reduzierten Funktionsumfang oder ein verschobenes Go-Live. Liegt das Problem an der Systementscheidung selbst oder an einem Dienstleister ohne die nötige Erfahrung, führt Nachverhandeln oft nur zu einer verzögerten Wiederholung desselben Problems. Vor beiden Wegen steht dieselbe Rechnung, nämlich was ein Weiterarbeiten ab heute noch kostet und was ein Neustart kosten würde.
Wer sollte die Analyse machen?
Eine Person oder ein Team ohne Verantwortung für den bisherigen Projektverlauf liefert die unabhängigere Einschätzung. Wer das eigene Projekt seit Monaten leitet, hat selten die Distanz, eigene Fehleinschätzungen offen zu benennen, auch beim besten Willen nicht. Externe Prüfer bringen außerdem den Vergleich zu anderen Projekten mit, an dem sich Ausmaß und Dringlichkeit der Lage einordnen lassen. Intern lässt sich diese Rolle nur besetzen, wenn die prüfende Person nachweislich kein eigenes Interesse am Ergebnis hat, was in der Praxis selten der Fall ist.
Ein ERP-Projekt in der Krise braucht jemanden, der die Steuerung übernimmt und die verbliebenen Entscheidungen trifft. torck stellt dafür eigene Entwicklungs- und Projektteams in Maxhütte-Haidhof, Wien und Rabat bereit und führt die technische Seite der Sanierung selbst, statt nur einen weiteren Bericht zu liefern. Vertragspartner ist die deutsche torck GmbH. Wer eine zweite Einschätzung zum eigenen ERP-Projekt braucht, kann das in einem Erstgespräch klären.
German 
English 
French