Die Frage zum ERP-Scheitern, die niemand ehrlich beantworten will
Fragen Sie, warum ein ERP-Projekt gescheitert ist, bekommen Sie meist eine von drei Antworten: schlechtes Change Management, fehlende Rückendeckung aus der Geschäftsführung oder unklar definierte Anforderungen. Diese Antworten sind nicht falsch. Aber sie beschreiben Symptome, keine Ursachen. Sie erklären, was in den letzten Monaten eines scheiternden Projekts sichtbar wurde, nicht die strukturelle Dynamik, die das Scheitern lange vorher erzeugt hat.
ERP-Projekte scheitern selten plötzlich. Es ist ein schleichender Prozess struktureller Verschlechterung, im formalen Reporting unsichtbar, der sich über den Projektverlauf stetig aufbaut, bis das angesammelte Gewicht aufgeschobener Entscheidungen, falscher Annahmen und Governance-Lücken die nächste Projektphase unmöglich macht.
Wie sich ERP-Scheitern in der Praxis zeigt
In Wirklichkeit sieht es so aus: Die ersten drei Monate läuft das Projekt pünktlich, die Statusberichte bleiben grün. Dann fangen die Termine an zu rutschen, jedes Mal für sich erklärbar. Budgetdruck kommt auf, wird aber immer Scope-Änderungen zugeschrieben. Governance-Strukturen, die informell funktioniert haben, ächzen unter wachsender Komplexität. Die Lücke zwischen dem, was berichtet wird, und dem, was tatsächlich passiert, wird Monat für Monat ein Stück größer.
Warum die üblichen Erklärungen am Kern vorbeigehen
„Schlechtes Change Management“ ist als Beschreibung zutreffend, als Erklärung aber unzureichend: Es sagt nicht, warum das Change Management schlecht war. „Fehlende Rückendeckung“ erklärt nicht, warum sich die Sponsoren zurückgezogen haben. „Unklare Anforderungen“ sagt nicht, ob die fehlende Klarheit ein Prozessproblem war, ein Governance-Problem, eine Kompetenzlücke oder die kommerzielle Entscheidung, ohne Klarheit weiterzumachen, weil die Alternative war, den Auftrag zu verlieren. Die folgenden Muster wirken genau auf der Ebene, auf der diese Ergebnisse entstehen.
Die teuersten ERP-Projekte sind nicht die, die man nicht hätte verhindern können. Es sind die, die man zu einem Bruchteil der späteren Kosten hätte verhindern können, in einem Moment, in dem die Signale schon da waren und das Fenster zum Gegensteuern noch offen stand.
Acht strukturelle Gründe, warum ERP-Projekte scheitern
1. Governance, die keine Entscheidungen trifft
Das häufigste strukturelle Muster ist ein Governance-Modell, das Meetings produziert, keine Entscheidungen. Die meisten Programme haben Lenkungsausschüsse, Projektboards und Eskalationswege. Was oft fehlt, ist ein Modell, das Themen schnell genug in Entscheidungen überführt, um das Tempo zu halten. Themen werden aufgeworfen, eskaliert, diskutiert und dann vertagt. Der Zyklus wiederholt sich.
2. Ein Scope, der nie wirklich vereinbart wurde
Kommerzieller Druck in der Vertragsphase schafft Anreize, breite, mehrdeutige Scope-Definitionen zu akzeptieren. Das Ergebnis ist ein Vertrag, den beide Seiten unterschrieben haben, während sie unterschiedliche Vorstellungen davon hatten, was vereinbart wurde. Der Widerspruch wird sichtbar, sobald die ersten großen Lieferentscheidungen anstehen.
3. Die Lücke zwischen Reporting und Realität
Grüne Statusberichte in scheiternden Programmen sind eines der beständigsten Muster der Branche. Das ist keine bewusste Täuschung, sondern das Ergebnis einer Reporting-Kultur, die von Genauigkeit zu Beschwichtigung gedriftet ist, weil ein ehrliches Bild Mut, Vertrauen und ein Umfeld braucht, in dem das Ansprechen von Problemen als wertvoll gilt, nicht als Bedrohung.
4. Nicht passende Partner-Kompetenz
Ein Partner, der lokale Business-Central-Einführungen im Mittelstand hervorragend beherrscht, hat nicht automatisch die Governance-Kapazität, die internationale Koordinationserfahrung oder die Senior-Führung, die ein Multi-Country-Rollout im Konzern verlangt. Diese Lücke wird vor Vertragsschluss selten explizit geprüft.
5. Stakeholder-Fehlausrichtung, die sich mit der Zeit verstärkt
Fehlausrichtung ist kein Ausgangszustand, sie entwickelt sich schrittweise. Frühe Unstimmigkeiten, die nicht adressiert werden, wachsen. Wenn die Lücke zwischen Partner- und Kundenverständnis für die Führungsebene sichtbar wird, ist der Abstand oft nur noch mit formaler Intervention zu überbrücken.
6. Technologie-Entscheidungen vor Prozessklarheit
Wer sich auf eine Plattform festlegt, bevor die Zielprozesse klar sind, verbringt die Konfigurationsphase damit, festzustellen, dass die Prozessannahmen nicht zum gewählten System passen. Das ist teuer und durch eine saubere Standortbestimmung vor Projektstart weitgehend vermeidbar.
7. Termindruck, der die Ehrlichkeit verzerrt
Sobald ein Termin steht, ändern sich die Anreize aller Beteiligten. Der Effekt ist ein Programm, das technisch im Plan und praktisch gefährdet ist. Termindruck erzeugt selektive Ehrlichkeit: eine systematische Bevorzugung von Informationen, die den Plan stützen, gegenüber solchen, die ihn infrage stellen.
8. Das Fehlen eines definierten Entscheidungsmoments
Viele Programme hätten gerettet werden können, wenn jemand einen formalen Moment geschaffen hätte, an dem die Frage „Sollen wir dieses Projekt so wie definiert fortsetzen?“ mit vollständigen Informationen gestellt und beantwortet wird. Das Fehlen dieses Moments verhindert nicht, dass Entscheidungen getroffen werden. Es verhindert, dass sie bewusst getroffen werden, von den Menschen mit der Autorität dazu.
Was diese Muster gemeinsam haben
Acht verschiedene Muster, eine gemeinsame Dynamik. Jedes ist strukturell. Jedes baut sich auf, bevor es sichtbar wird. Jedes ist vorhersehbar, wenn man weiß, worauf man achten muss. Und jedes ist vermeidbar, wenn man es im richtigen Moment erkennt.
Die Warnsignale: worauf Sie achten sollten, bevor es teuer wird
- Statusberichte durchweg positiver, als direkte Gespräche mit den Beteiligten vermuten lassen
- Entscheidungen werden in Governance-Runden aufgeworfen und wiederholt ohne Lösung vertagt
- Scope-Klärungen häufen sich und dehnen die ursprüngliche Definition schleichend aus
- Partner- und Kundenteams arbeiten mit zunehmend unterschiedlicher Sicht auf den Fortschritt
- Termindruck führt zu Erklärungen für Verzug statt zu dessen Auflösung
- Eine Governance-Struktur, die Meetings erzeugt, aber keine Entscheidungen trifft
Wie Sie reagieren, wenn Sie diese Muster erkennen
Vier Reaktionen stehen zur Verfügung, mit steigender Eingriffstiefe:
- Internes Governance-Review: eine strukturierte Prüfung von Entscheidungsbefugnissen und Eskalationswegen, geführt von der Programmleitung mit externer Moderation.
- Senior-geführte externe Standortbestimmung: eine neutrale Bewertung von außen, die ein gemeinsames, faktenbasiertes Bild vom strukturellen Zustand des Programms liefert.
- Struktureller Reset: eine formale Entscheidung auf Programmebene, Governance neu aufzustellen, Scope-Vereinbarungen zu überarbeiten oder die Lieferstruktur zu ändern.
- Geplante Rettung: für Programme in der Krise ein strukturierter Prozess, der eine belastbare Grundlage für die Entscheidung „weiter, zurücksetzen oder stoppen“ schafft.
Wenn Sie eines dieser Muster wiedererkennen
Das ist selten Zufall. Lassen Sie uns im Gespräch anschauen, wo die Steuerung hakt, senior-geführt, mit Business Central als Heimat.
