ERP-Projekt in der Krise: Woran man sie erkennt – und wie man sie noch dreht

Es gibt einen Moment in vielen ERP-Projekten, der sich schleichend ankündigt und dann plötzlich da ist. Der Projektleiter schreibt im Statusbericht weiterhin „grün“, aber in den Meetings ist die Stimmung angespannt. Meilensteine werden verschoben – zunächst um Wochen, dann um Monate. Das Systemhaus spricht von „offenen Punkten“, die das Unternehmen als kritische Lücken erlebt. Die Geschäftsführung bekommt widersprüchliche Informationen, je nachdem wen sie fragt.

Dieser Zustand ist gefährlicher als ein klares Scheitern. Weil er sich tarnt. Weil die Beteiligten – aus nachvollziehbaren Gründen – daran arbeiten, ihn nicht sichtbar werden zu lassen. Weil die Hoffnung, dass es sich von selbst löst, länger anhält als sie sollte.

Und weil jeder Monat, in dem die Krise nicht benannt wird, die Optionen zur Gegenwehr reduziert.

Ein ERP-Projekt in der Krise zeigt:

Ein ERP-Projekt in der Krise ist nicht:

Statusberichte sind in ERP-Projekten ein Lagebild. Das Problem: Sie werden von Beteiligten erstellt, die ein Interesse daran haben, dass das Projekt gut aussieht – gegenüber der Geschäftsführung, gegenüber dem Auftraggeber, manchmal auch gegenüber sich selbst.

Das Ergebnis sind Statusberichte, die technisch korrekt sind und inhaltlich irreführend. Meilensteine werden als „erledigt“ markiert, obwohl die dahinterliegenden Inhalte noch offen sind. Risiken werden in der Formulierung so weichgespült, dass ihre tatsächliche Tragweite nicht erkennbar ist. „In Abstimmung“ bedeutet in der Praxis oft: seit vier Wochen ungelöst.

Ein verlässlicheres Bild entsteht nicht aus dem Statusbericht, sondern aus Gesprächen – mit Key Usern, die das System testen. Mit Abteilungsleitern, die von der Einführung betroffen sind. Mit dem Projektteam in der zweiten Reihe, das die operative Realität kennt und selten in Steuerungsrunden sitzt.

Wenn das, was diese Menschen sagen, und das, was im Statusbericht steht, deutlich auseinandergehen – ist das kein Kommunikationsproblem. Es ist ein Krisenindikator.

ERP-Projekte erfordern Entscheidungen. Viele davon sind unbequem: Prozesse müssen verändert werden, Altgewohnheiten aufgegeben, Kompromisse zwischen Abteilungen gefunden. Wenn diese Entscheidungen nicht fallen – wenn Themen von Meeting zu Meeting mitgenommen werden, wenn niemand Verantwortung übernimmt, wenn der Konsens immer einen Schritt entfernt ist –, akkumuliert sich ein Entscheidungsstau, der das Projekt irgendwann zum Stehen bringt.

Entscheidungsstau entsteht fast nie aus Faulheit. Er entsteht aus unklaren Verantwortlichkeiten, aus fehlender Eskalationsstruktur und aus Führungssituationen, in denen niemand bereit ist, eine unbequeme Entscheidung zu verantworten.

In einem Projekt im Großhandel haben wir bei der Übernahme einer Projektkrise festgestellt, dass dreiundzwanzig offene Entscheidungen seit mehr als acht Wochen auf der Agenda standen – ohne dass eine einzige davon getroffen worden war. Das Systemhaus wartete auf Klärung, das interne Projektteam wartete auf Freigabe, die Geschäftsführung war nicht informiert, dass die Klärung bei ihr lag. Drei dieser dreiundzwanzig Entscheidungen waren für den Go-Live-Termin kritisch. Alle drei hätten sich in einem halbtägigen Workshop lösen lassen.

Dieses Muster ist subtil und deshalb besonders gefährlich. Das Systemhaus liefert technisch korrekte Lösungen – die aber nicht das abbilden, was das Unternehmen im Alltag braucht. Das Unternehmen beschreibt Anforderungen – die das Systemhaus technisch anders interpretiert als gemeint. Beide Seiten sind überzeugt, das Richtige zu tun. Niemand lügt. Aber das Projekt entfernt sich Schritt für Schritt von dem, was am Ende gebraucht wird.

Die Ursache liegt fast immer in der Anforderungsphase: Prozesse wurden nicht klar genug dokumentiert, Akzeptanzkriterien nicht definiert, Missverständnisse nicht früh genug aufgelöst. Was am Anfang als kleine Lücke begann, wird zur Kluft – und je später sie erkannt wird, desto teurer ist die Überbrückung.

Wenn in Projekttreffen mehr über Vertragstext als über Lösungen gesprochen wird, ist das ein verlässlicher Indikator dafür, dass das Vertrauensverhältnis bereits beschädigt ist. Ab diesem Punkt braucht es eine externe Perspektive – jemanden, der keine Partei ist und beiden Seiten helfen kann, wieder in dieselbe Richtung zu arbeiten.

Technisch läuft das Projekt – aber die Fachabteilungen verweigern die Mitarbeit in Tests, Key User haben keine Zeit, Führungskräfte zeigen keine Ownership. Das System wird fertig konfiguriert, aber niemand hat Interesse daran, dass es wirklich funktioniert.

Das ist kein Motivationsproblem. Das ist ein Einbindungsproblem. Die betroffenen Bereiche wurden zu spät oder gar nicht in die Projektgestaltung einbezogen. Sie erleben das Projekt als etwas, das ihnen angetan wird – nicht als etwas, das gemeinsam gestaltet wird. Die Konsequenz ist eine passive Resistenz, die sich in Testergebnissen, Schulungsquoten und letztlich in der Go-Live-Stabilität niederschlägt.

Mehr Druck. Der Reflex, bei Verzug den Druck zu erhöhen – mehr Meetings, kürzere Reporting-Zyklen, härtere Deadlines – löst keine strukturellen Probleme. Er beschleunigt den Konsum von Energie, die für die Lösung gebraucht wird.

Mehr Budget. Geld löst Ressourcenprobleme. Es löst keine Klarheitsprobleme, keine Entscheidungsstaus und keine Vertrauensprobleme. Wer mehr Geld in ein Projekt gibt, das an strukturellen Ursachen leidet, bekommt ein teureres Problem.

Abwarten. Die häufigste und schädlichste Reaktion. Projekte in der Krise erholen sich nicht von selbst. Die Probleme akkumulieren sich, die Optionen werden weniger, der Aufwand für die Rettung steigt.

Eine ehrliche Standortbestimmung. Bevor irgendetwas anderes: ein klares Bild davon, was wirklich los ist. Nicht aus dem Statusbericht. Nicht von den Beteiligten, die ein Interesse an einer bestimmten Darstellung haben. Sondern von jemandem, der keine Partei ist und die Situation unvoreingenommen einschätzen kann.

Diese Standortbestimmung muss schnell gehen – in Projektsituationen zählen Wochen. Und sie muss in konkrete Prioritäten münden: Was sind die drei bis fünf Punkte, die sofort adressiert werden müssen? Was kann warten?

Entscheidungen herbeiführen, nicht abwarten. Die meisten Krisen haben einen Kern aus ungelösten Entscheidungen. Diese müssen identifiziert, mit den richtigen Personen besprochen und getroffen werden – mit klarer Verantwortung und dokumentiertem Ergebnis.

Das Vertrauensverhältnis reparieren, wenn nötig. Wenn die Zusammenarbeit zwischen Auftraggeber und Systemhaus zerrüttet ist, braucht es Moderation. Nicht Schuldzuweisung. Das Ziel ist nicht, zu klären, wer recht hat – sondern das Projekt wieder arbeitsfähig zu machen.

Scope realistisch bewerten. Manchmal ist die ehrlichste Antwort: Der ursprünglich geplante Scope ist mit den vorhandenen Mitteln und dem verbleibenden Zeitrahmen nicht mehr erreichbar. Eine Scope-Reduzierung ist keine Niederlage – sie ist professionelles Projektmanagement. Wer den Scope nicht reduziert und stattdessen auf einen Go-Live drängt, der nicht tragfähig ist, zahlt es nach dem Go-Live zurück.

Es gibt in Projektsituationen einen Moment, in dem die Krise noch beherrschbar ist – und einen, in dem sie es nicht mehr ist. Der Unterschied liegt meistens nicht in der Schwere der Probleme, sondern im Zeitpunkt der Intervention.

Unternehmen, die früh externe Hilfe holen, tun das oft mit einem schlechten Gewissen: Hat das Projekt wirklich versagt? Ist das eine Niederlage? Zeigen wir damit Schwäche?

Wer wartet, bis das Scheitern unbestreitbar ist, hat weniger Optionen. Wer früh handelt, hat mehr.

ERP-Projekte in der Krise sind kein Sonderfall. Sie sind eine vorhersehbare Konsequenz aus der Komplexität solcher Vorhaben. Was den Unterschied macht, ist nicht ob eine Krise entsteht – sondern wann und wie sie erkannt und adressiert wird.

Die vier Warnsignale sind verlässlich. Sie tauchen früh auf, lange bevor das Projekt formal scheitert. Wer sie kennt und ernst nimmt, hat Zeit zu handeln.

Wenn Sie sich in einem der Muster dieses Artikels wiederfinden – oder wenn Sie das Gefühl haben, dass der offizielle Projektstatus und die erlebte Realität auseinandergehen – ist ein externer Blick der sinnvollste nächste Schritt.

In einem kostenlosen 30-minütigen Erstgespräch besprechen wir, wo die kritischen Punkte in Ihrem Projekt liegen – und welche Maßnahmen jetzt den größten Hebel haben.

Es gibt keine formale Schwelle – und das ist Teil des Problems. Projekte geraten schleichend in die Krise, nicht durch ein einzelnes Ereignis. Verlässlichere Indikatoren als Terminverzug allein sind: wiederkehrende ungelöste Entscheidungen, wachsender Abstand zwischen Statusbericht und erlebter Realität, und nachlassendes Vertrauen zwischen den Beteiligten. Wenn zwei oder mehr dieser Muster gleichzeitig auftreten, ist externe Unterstützung meistens sinnvoller als internes Weiterarbeiten.

In den meisten Fällen nein – ein vollständiger Neustart ist teurer und riskanter als eine strukturierte Rettung. Die Ausnahmen: wenn die Prozessdefinition so grundlegend falsch ist, dass eine Nachkorrektur mehr Aufwand erzeugt als ein Neuaufsetzen, oder wenn das Vertrauensverhältnis zwischen Auftraggeber und Systemhaus so beschädigt ist, dass eine funktionierende Zusammenarbeit nicht mehr möglich ist. Beides lässt sich in einer Standortbestimmung beurteilen – bevor die Entscheidung getroffen wird.

Die Standortbestimmung – das Erstellen eines klaren Lagebilds mit priorisierten Maßnahmen – dauert in der Regel zwei bis vier Wochen. Was danach kommt, hängt von den Befunden ab: Manche Krisen lassen sich mit gezielten Interventionen in wenigen Wochen stabilisieren, andere erfordern eine längere Begleitung bis zum Go-Live. Entscheidend ist, dass die ersten Maßnahmen schnell wirken – Projekte in der Krise brauchen frühe sichtbare Fortschritte, um das Vertrauen der Beteiligten zurückzugewinnen.

Quellen: Standish Group CHAOS Report (2023); McKinsey & Company, Delivering large-scale IT projects on time, on budget, and on value (2012, aktualisiert 2022); eigene Projekterfahrung aus ERP-Begleitungen und Projektrettungen im Handel und Großhandel