ERP-Projekt gescheitert: Ursachen erkennen und Neustart-Strategie entwickeln

Es gibt einen Moment, den niemand geplant hat und den trotzdem viele Unternehmen erleben: Das ERP-Projekt ist gescheitert. Nicht in dem Sinne, dass die Software nicht installiert wurde – sondern in dem Sinne, dass das Ergebnis nicht das ist, was versprochen wurde. Die Prozesse laufen nicht besser. Die Datenqualität ist schlechter als vorher. Die Mitarbeitenden arbeiten am System vorbei. Die Investition hat sich nicht gelohnt.

Für die Geschäftsführung ist das ein schmerzhafter Moment. Für das Projektteam ist es frustrierend. Und für die gesamte Organisation hinterlässt es eine Narbe, die weit über das Projekt hinausreicht: das Vertrauen in große Veränderungsvorhaben ist beschädigt. Und doch zeigt die Erfahrung aus über zehn Jahren ERP-Beratung: Ein gescheitertes Projekt ist kein Endpunkt. Es ist ein Wendepunkt. Vorausgesetzt, man geht mit dem Scheitern professionell um – analysiert die Ursachen ehrlich, zieht die richtigen Lehren und plant den Neustart so, dass die Fehler der Vergangenheit nicht wiederholt werden.

Nicht jedes Projekt, das Probleme hat, ist gescheitert. Es gibt einen wichtigen Unterschied zwischen einem Projekt in der Krise – das durch gezielte Intervention noch gerettet werden kann – und einem Projekt, das seine fundamentalen Ziele verfehlt hat. Die Unterscheidung ist entscheidend, weil sie bestimmt, ob eine Rettung oder ein Neustart der richtige Weg ist.

Ein ERP-Projekt ist in der Regel dann gescheitert, wenn mehrere der folgenden Merkmale gleichzeitig zutreffen: Das System ist live, wird aber von den Fachabteilungen nicht akzeptiert und aktiv umgangen. Die Kernprozesse funktionieren im neuen System schlechter als im alten. Die Datenqualität hat sich durch die Migration verschlechtert statt verbessert. Die Investition steht in keinem Verhältnis mehr zum erzielten Nutzen. Das Vertrauensverhältnis zwischen Auftraggeber, Projektteam und Systemhaus ist so beschädigt, dass eine produktive Zusammenarbeit nicht mehr möglich ist. Wenn Sie sich in mehreren dieser Punkte wiedererkennen, ist es wichtig, das offen zu benennen – nicht als Schuldzuweisung, sondern als notwendigen ersten Schritt, um einen besseren Weg einzuschlagen.

In meiner Beratungspraxis sehe ich immer wieder dieselben Muster. Das Scheitern eines ERP-Projekts hat selten eine einzige Ursache – es ist fast immer eine Kombination aus mehreren Faktoren, die sich gegenseitig verstärken. Die folgenden fünf Ursachen sind dabei die häufigsten und folgenreichsten.

Die Wahl des ERP-Systems ist eine der folgenreichsten Entscheidungen im gesamten Projekt. Und sie wird erstaunlich oft auf der Grundlage unvollständiger Informationen getroffen. Unternehmen lassen sich von Referenzen beeindrucken, die wenig mit der eigenen Situation zu tun haben. Sie wählen den Marktführer, weil er als sicher gilt – ohne zu prüfen, ob seine Stärken zu den eigenen Anforderungen passen. Oder sie entscheiden sich für das günstigste Angebot, ohne die Gesamtkosten realistisch zu kalkulieren. Eine fundierte Systemauswahl beginnt nicht mit dem Markt, sondern mit dem eigenen Unternehmen. Welche Prozesse sind wirklich differenzierend? Wo reicht der Standard? Welche Branchenanforderungen sind nicht verhandelbar? Erst wenn diese Fragen beantwortet sind, lässt sich sinnvoll evaluieren, welches System passt.

Der Wunsch, alles auf einmal zu lösen, ist nachvollziehbar. Wenn schon die Anstrengung eines ERP-Projekts auf sich genommen wird, dann soll es sich auch lohnen. Also werden alle Abteilungen eingebunden, alle Schnittstellen berücksichtigt, alle Sonderprozesse abgebildet. Das Ergebnis ist ein Projektplan, der auf dem Papier ambitioniert und in der Praxis nicht umsetzbar ist. Ein realistischer Scope bedeutet nicht, Abstriche beim Ergebnis zu machen. Er bedeutet, die Einführung so zu strukturieren, dass jede Phase beherrschbar bleibt. Komplexität wird nicht durch den Umfang des Projekts reduziert, sondern durch die intelligente Reihenfolge der Umsetzung.

Jedes ERP-Projekt verändert die Art, wie Menschen arbeiten. Gewohnte Abläufe fallen weg, neue Verantwortlichkeiten entstehen, Transparenz nimmt zu. Für viele Mitarbeitende ist das bedrohlich – nicht weil sie Veränderung grundsätzlich ablehnen, sondern weil sie nicht verstehen, warum sie notwendig ist, und weil sie nicht das Gefühl haben, Teil der Gestaltung zu sein. Organisatorischer Widerstand ist keine Fehlreaktion der Mitarbeitenden. Er ist die logische Konsequenz aus fehlendem Change Management. Wer die Menschen nicht frühzeitig einbindet, nicht erklärt, warum Veränderung notwendig ist, und keinen Raum für Bedenken schafft, darf sich nicht wundern, wenn das System nach dem Go-Live umgangen wird.

Ein ERP-Projekt ist kein IT-Projekt, das nebenbei gemanagt werden kann. Es erfordert eine dedizierte Projektleitung mit klaren Befugnissen, strukturierte Governance mit definierten Entscheidungswegen und ein systematisches Risikomanagement, das Probleme identifiziert, bevor sie kritisch werden. In der Praxis sehe ich häufig Projekte, in denen die Projektleitung weder die Zeit noch die Autorität hat, um das Projekt wirklich zu steuern. Entscheidungen werden nicht getroffen, weil die Eskalationswege nicht definiert sind. Meilensteine werden verschoben, ohne dass die Konsequenzen für den Gesamtplan bewertet werden. Das Projekt driftet – und niemand fühlt sich zuständig, es wieder auf Kurs zu bringen.

Die Datenmigration wird in vielen Projekten unterschätzt – sowohl im Aufwand als auch in ihrer Bedeutung für den Projekterfolg. Stammdaten, die über Jahre gewachsen sind, enthalten Duplikate, Inkonsistenzen und veraltete Einträge. Wenn diese Daten unbereinigt in das neue System übernommen werden, ist das Ergebnis vorhersehbar: Das neue System liefert falsche Ergebnisse, Berichte sind unbrauchbar, und die Fachabteilungen verlieren das Vertrauen in das System, bevor es sich beweisen konnte. Datenqualität ist kein IT-Thema – es ist ein organisatorisches Thema. Ohne klare Datenverantwortlichkeiten, definierte Qualitätskriterien und einen realistischen Bereinigungsplan wird die Datenmigration zum stillen Killer des ERP-Projekts.

Wenn ein ERP-Projekt gescheitert ist, steht das Unternehmen vor einer fundamentalen Entscheidung: Lässt sich das bestehende Projekt noch retten, oder ist ein Neustart der bessere Weg? Diese Entscheidung hat weitreichende Konsequenzen – finanziell, operativ und psychologisch. Sie sollte deshalb nie aus dem Bauch heraus getroffen werden, sondern auf der Grundlage einer strukturierten Analyse.

Eine Rettung ist dann sinnvoll, wenn das gewählte System grundsätzlich passt, die Probleme auf Projektebene liegen – also bei Scope, Governance oder Change Management – und das Vertrauensverhältnis zwischen den Beteiligten reparierbar ist. Ein Neustart ist dann der richtige Weg, wenn die Systemwahl fundamental falsch war, wenn die Konfiguration so weit vom Sollzustand entfernt ist, dass eine Nachbesserung teurer wäre als ein Neuanfang, oder wenn das Vertrauensverhältnis so beschädigt ist, dass eine produktive Zusammenarbeit auf der bestehenden Basis nicht mehr möglich ist.

Bevor ein Neustart geplant wird, muss das Scheitern verstanden werden. Nicht als Ritual. Nicht als Schuldzuweisung. Sondern als systematischer Prozess, der die tatsächlichen Ursachen identifiziert und sicherstellt, dass sie im nächsten Anlauf nicht wiederholt werden. Ein wirksamer Lessons-Learned-Prozess umfasst Gespräche mit allen relevanten Stakeholdern – nicht nur mit dem Projektteam, sondern auch mit betroffenen Fachabteilungen, Key Usern und der Geschäftsführung.

Die Analyse untersucht nicht nur, was schiefgelaufen ist, sondern auch, warum die Probleme nicht früher erkannt oder adressiert wurden. Welche Warnsignale gab es? Wer hat sie gesehen? Warum wurden sie nicht eskaliert? Die Ergebnisse dieses Prozesses sind die wichtigste Grundlage für den Neustart. Sie definieren, welche Rahmenbedingungen sich ändern müssen, welche Fehler in der Governance, im Scope oder in der Zusammenarbeit korrigiert werden müssen – und welche Anforderungen an die neue Projektstruktur nicht verhandelbar sind.

Ein ERP-Neustart ist kein einfaches Wiederholen des ersten Versuchs. Er erfordert eine grundlegend überarbeitete Vorgehensweise, die die Lehren aus dem Scheitern konsequent umsetzt. Die folgende Strategie hat sich in der Praxis bewährt – bei Unternehmen, die nach einem gescheiterten Projekt den zweiten Anlauf erfolgreich gemeistert haben.

Der erste Schritt ist eine schonungslos ehrliche Bestandsaufnahme – nicht durch das Projektteam, das am bisherigen Verlauf beteiligt war, sondern durch eine externe, unabhängige Instanz, die keine Partei ist und kein Interesse an einer bestimmten Darstellung hat. Diese Standortbestimmung bewertet: Welche Teile des bisherigen Projekts sind nutzbar? Welche technischen Grundlagen können übernommen werden? Wo ist ein Neuanfang unausweichlich? Und wie steht es um die organisatorische Bereitschaft für einen zweiten Anlauf? Die Analyse dauert in der Regel zwei bis vier Wochen und mündet in ein klares Lagebild mit konkreten Empfehlungen.

Die Root-Cause-Analyse geht tiefer als der Lessons-Learned-Prozess. Sie fragt nicht nur, was schiefgelaufen ist, sondern warum. Warum wurde das falsche System gewählt? Weil die Anforderungsanalyse unvollständig war – oder weil die Entscheidung politisch getroffen wurde? Warum gab es organisatorischen Widerstand? Weil das Change Management fehlte – oder weil die Organisationskultur Veränderungen grundsätzlich erschwert? Warum war das Projektmanagement mangelhaft? Weil die Projektleitung überfordert war – oder weil sie nie die nötige Autorität bekommen hat? Erst wenn diese tieferliegenden Ursachen identifiziert sind, lassen sich die richtigen Gegenmaßnahmen definieren.

Der überarbeitete Scope muss realistisch sein – nicht ambitioniert. Er basiert auf den tatsächlichen Kapazitäten des Unternehmens, den verfügbaren Ressourcen und einem Zeitrahmen, der Puffer für Unvorhergesehenes enthält. Die Priorisierung unterscheidet klar zwischen dem, was für den Go-Live unbedingt notwendig ist, und dem, was in späteren Phasen umgesetzt werden kann. Diese Klarheit fehlt in den meisten gescheiterten Projekten – und sie ist der Schlüssel zum Erfolg des Neustarts.

Die Governance-Struktur des Neustarts muss die Schwächen des ersten Anlaufs adressieren. Das bedeutet in der Regel: eine Projektleitung mit klarer Autorität und ausreichend Kapazität. Ein Lenkungsausschuss, der tatsächlich lenkt – und nicht nur berichtet bekommt. Definierte Eskalationswege, die bei offenen Entscheidungen greifen. Und ein Risikomanagement, das nicht nur Risiken dokumentiert, sondern aktiv Gegenmaßnahmen einleitet. Wenn diese Struktur im ersten Projekt gefehlt hat, ist das ein klares Signal: Der Neustart braucht eine andere Projektorganisation.

Der Neustart selbst erfolgt in kontrollierten Phasen mit definierten Quality Gates. Jede Phase hat klare Ergebnisse, die erreicht sein müssen, bevor die nächste beginnt. Das Monitoring ist eng, die Feedback-Zyklen sind kurz, die Eskalationsmechanismen sind aktiviert. Diese Disziplin kostet am Anfang mehr Aufwand – aber sie ist die Versicherung dagegen, dass sich die Fehler des ersten Anlaufs wiederholen.

Die technischen und organisatorischen Aspekte eines Neustarts sind wichtig. Aber sie sind nicht alles. Nach einem gescheiterten ERP-Projekt ist die Organisation erschöpft. Das Projektteam ist frustriert. Die Fachabteilungen sind skeptisch. Und die Geschäftsführung ist unter Druck, den Misserfolg zu erklären und gleichzeitig einen neuen Anlauf zu rechtfertigen. Diese psychologische Dimension wird bei Neustarts oft unterschätzt – und genau das führt dazu, dass auch der zweite Versuch scheitert.

Der Neustart muss deshalb auch ein Signal des Neuanfangs sein. Das beginnt mit einer ehrlichen Kommunikation darüber, was schiefgelaufen ist und was sich ändert. Es erfordert eine sichtbare Veränderung in der Projektorganisation und im Umgang mit den Beteiligten. Und es braucht frühe Erfolge – schnelle, sichtbare Fortschritte, die zeigen, dass dieser Anlauf anders ist. Ein Team, das nicht an den Erfolg glaubt, wird ihn auch nicht herbeiführen.

Besondere Aufmerksamkeit verdient das Stakeholder-Management. Die Geschäftsführung braucht Vertrauen, dass die Investition sich lohnt. Der Betriebsrat muss eingebunden werden, wenn Veränderungen die Arbeitsbedingungen betreffen. Die Fachabteilungen brauchen das Gefühl, dass ihre Erfahrungen aus dem ersten Projekt gehört werden. Und das Systemhaus – ob dasselbe oder ein neues – muss wissen, welche Lehren gezogen wurden und welche Spielregeln diesmal gelten. Wer nach einem Scheitern so tut, als sei nichts gewesen, verliert die Glaubwürdigkeit für den Neustart.

Ein Neustart nach einem gescheiterten ERP-Projekt ist einer der Momente, in denen externe Unterstützung den größten Hebel hat. Nicht weil die internen Kompetenzen nicht ausreichen – sondern weil die internen Beteiligten Teil der Geschichte sind. Sie waren am ersten Projekt beteiligt, haben Positionen bezogen, haben Vertrauen verloren oder verursacht. Ein externer Berater bringt das, was intern am meisten fehlt: eine unbelastete Perspektive, keine politische Agenda und die Erfahrung aus vergleichbaren Situationen. Entscheidend ist dabei die Unabhängigkeit des Beraters. Wer den Neustart begleitet, darf kein Interesse am Verkauf eines bestimmten Systems haben. Die Beratung muss auf der Seite des Unternehmens stehen – nicht auf der Seite eines Anbieters. Diese Unabhängigkeit ist kein Luxus. Sie ist die Voraussetzung dafür, dass die Beratung wirkt.

Unternehmen, die ein gescheitertes ERP-Projekt professionell aufarbeiten, stehen am Ende oft besser da als Unternehmen, die im ersten Anlauf einen mittelmäßigen Kompromiss akzeptiert haben. Weil sie die Ursachen kennen. Weil sie wissen, was nicht funktioniert. Weil sie die Fehler des ersten Versuchs nicht wiederholen werden. Der Weg dorthin erfordert Mut zur Ehrlichkeit, die Bereitschaft zur Veränderung und die Disziplin, den Neustart professionell zu planen und umzusetzen.

Wenn Ihr ERP-Projekt gescheitert ist oder kurz vor dem Scheitern steht – dann ist jetzt der richtige Moment für eine ehrliche Standortbestimmung. In einem kostenlosen 30-minütigen Erstgespräch analysieren wir gemeinsam, wo die wahren Ursachen liegen, ob eine Rettung oder ein Neustart der sinnvollere Weg ist – und welche ersten Schritte jetzt den größten Hebel haben.

Die Kosten eines Neustarts hängen stark davon ab, wie viel vom bisherigen Projekt übernommen werden kann. In vielen Fällen lassen sich technische Grundlagen, bereinigte Daten und dokumentierte Prozesse weiterverwenden – das reduziert den Aufwand erheblich. Erfahrungswerte zeigen, dass ein gut geplanter Neustart in der Regel 40 bis 60 Prozent des ursprünglichen Budgets erfordert, wenn die Vorarbeit konsequent genutzt wird. Die eigentliche Frage ist nicht, ob ein Neustart teuer ist – sondern ob das Festhalten an einem gescheiterten Projekt auf Dauer nicht noch teurer kommt.

Das hängt von der Ursache des Scheiterns ab. Wenn das System grundsätzlich zu den Anforderungen passt und die Probleme auf Projektebene lagen – falscher Scope, fehlendes Change Management, mangelhaftes Projektmanagement –, ist ein Systemwechsel selten notwendig und oft kontraproduktiv, weil er zusätzliche Komplexität erzeugt. Wenn die Systemwahl jedoch der Kern des Problems war – weil das System die Branchenanforderungen nicht abbildet oder technische Grenzen erreicht hat –, führt kein Weg an einem Wechsel vorbei. Die Antwort liefert die Root-Cause-Analyse.

Die Stabilisierungsphase – Standortbestimmung, Root-Cause-Analyse und Neuplanung – dauert in der Regel sechs bis zwölf Wochen. Der eigentliche Neustart hängt vom Umfang ab, liegt aber erfahrungsgemäß bei neun bis achtzehn Monaten bis zum ersten Go-Live. Insgesamt sollten Unternehmen also mit zwölf bis vierundzwanzig Monaten rechnen. Das klingt lang – ist aber deutlich realistischer als der Versuch, das gescheiterte Projekt in wenigen Monaten irgendwie zu retten. Geschwindigkeit ist weniger wichtig als Stabilität.

Quellen: Standish Group CHAOS Report (2023); Panorama Consulting Group ERP Report (2024); Gartner, Predicts: ERP Initiatives Will Fail More Often (2022); eigene Projekterfahrung aus ERP-Begleitungen und Neustarts im Mittelstand