Das ERP-Projekt ist gescheitert. Lässt es sich retten?

In den meisten Fällen ja, aber nicht mit mehr vom Gleichen. Ein gescheitertes ERP-Projekt braucht zuerst eine schonungslose Ursachenanalyse, dann eine neu aufgestellte Projektorganisation mit realistischen Zwischenzielen und klarer Steuerung auf Ihrer Seite. Entscheidend ist, ob das Fundament tragfähig gemacht wird, bevor weitergebaut wird. Die Ursachen sind dabei selten technisch, weil Business Central als Standardsystem selten das Problem ist. Was Projekte zum Kippen bringt, liegt davor: unklare Ziele, Prozesse die im Projekt statt vorher geklärt werden, eine Datenbasis der niemand traut, und eine Projektführung ohne Entscheidungsbefugnis. Die Technik macht diese Lücken sichtbar, sie verursacht sie nicht. Deshalb beginnt eine Rettung nie mit einem technischen Review, sondern mit der Frage, welche Entscheidungen offen sind und wer sie treffen darf.

Fünf Warnsignale, bevor es kippt

Fünf Signale sind zuverlässiger als jedes Statusmeeting:

• Termin: Der Go-Live wurde zweimal oder öfter verschoben, ohne dass sich der Plan dahinter geändert hat.
• Budget: Die Kosten haben den vereinbarten Rahmen verlassen, und die Prognose beruht auf Annahmen statt auf Ist-Zahlen.
• Daten: Die Datenqualität bleibt trotz Migration schlecht, und Auswertungen müssen diskutiert werden, bevor ihnen jemand glaubt.
• Team: Das Projektteam ist dauerhaft überlastet, Tickets stauen sich, Key User fallen ins Tagesgeschäft zurück.
• Governance: Entscheidungswege sind unklar, und niemand steuert verbindlich.

Ein einzelnes Signal ist Alltag in jedem Projekt. Treffen zwei oder mehr gleichzeitig zu, ist Gegensteuern überfällig, und zwar nicht an den Symptomen. Der verschobene Termin ist ein Symptom; die Ursache liegt meist Wochen früher: ein Scope, der nie vereinbart war, Daten, die nicht bereinigt wurden, eine Entscheidung, die niemand treffen durfte. Der praktische Test: Fragen Sie, was sich im Plan inhaltlich geändert hat. Sind nur Datumsangaben nach hinten gewandert, wurde die Ursache nicht angefasst. Als messbarer Frühindikator eignet sich die Entscheidungslatenz, die Zeit zwischen aufgeworfener Frage und getroffener Entscheidung.

Warum sind die Ursachen selten technisch?

Die Ursachen sind selten technisch, weil Business Central als Standardsystem selten das Problem ist. Was Projekte zum Kippen bringt, liegt davor: unklare Ziele, Prozesse die im Projekt statt vorher geklärt werden, eine Datenbasis der niemand traut, und eine Projektführung ohne Entscheidungsbefugnis. Die Technik macht diese Lücken sichtbar, sie verursacht sie nicht.

Ein Beispiel, das wir regelmäßig sehen: Eine Prozessfrage steht im Raum, und niemand darf sie entscheiden. Also wird sie vertagt. Aus der vertagten Entscheidung wird ein Workaround, aus dem Workaround ein Sonderweg, den andere kopieren. Drei Monate später ist aus einer offenen Frage ein strukturelles Problem geworden, das im Projektbericht als technische Schuld auftaucht.

Deshalb beginnt eine Rettung nie mit einem technischen Review. Sie beginnt mit der Frage, welche Entscheidungen offen sind und wer sie treffen darf. Erst danach lohnt der Blick in die Konfiguration.

Was heißt Rettung konkret?

Rettung heißt konkret vier Schritte in dieser Reihenfolge. Erstens anhalten, was nicht weiterlaufen muss, damit nicht auf einem unklaren Fundament weitergebaut wird. Zweitens die Ursachen ehrlich benennen, getrennt von der Schuldfrage. Drittens neue, realistische Ziele setzen, die auf geprüften Restaufwänden beruhen und nicht auf dem alten Plan. Viertens die Organisation neu aufstellen, mit kurzen und prüfbaren Zwischenzielen.

Der zeitliche Rahmen ist überschaubarer, als die Lage sich anfühlt. Die Bestandsaufnahme dauert typischerweise zwei bis vier Wochen. Danach ist entschieden, ob ein Reset, ein Teilneustart oder ein geordneter Stopp der richtige Weg ist. Die Rettung selbst richtet sich nach dem Befund, folgt aber immer einem Fahrplan mit Etappen, die einzeln abgenommen werden.

Geführt wird das von einem Senior-Team, nicht von wechselnden Junior-Kräften. Das ist der Unterschied zwischen einer Reparatur und weiterem Substanzverlust, denn in einer Schieflage entscheidet Erfahrung und nicht Kapazität.

Wohin führt die Rettung?

Die Rettung führt zu einem System, das das Geschäft trägt, und das ist etwas anderes als ein System, das läuft. Ein Business Central kann technisch sauber laufen und das Geschäft trotzdem nicht tragen, weil die Regeln darunter widersprüchlich sind. Genau hier entstehen die Kosten, die im Business Case nie auftauchen.

Am Ende einer Rettung stehen drei Dinge: eine Datenbasis, der die Fachbereiche wieder trauen, Prozesse die dokumentiert und entschieden sind, und eine Governance, die Entscheidungen zeitnah in Ergebnisse überführt. Erst diese Kombination macht den Betrieb belastbar und schafft die Grundlage für alles, was danach kommt, von der Automatisierung bis zu KI-Agenten.

Das Zielsystem bleibt Business Central als Heimat, und die Steuerung bleibt auf Ihrer Seite. Wer die Rettung nutzt, um die Verantwortung erneut vollständig abzugeben, hat die Ursache nicht behoben.