Wie gelingt der zweite Anlauf nach einem gescheiterten ERP-Projekt?

Ein zweiter Anlauf gelingt in drei Schritten: Erstens eine ehrliche Diagnose, warum der erste Anlauf gescheitert ist, benannt in Ursachen statt Schuldigen. Zweitens eine Bestandsaufnahme, was verwertbar bleibt: Daten, Prozessaufnahmen, Schulungswissen. Drittens ein Neustart mit geänderter Steuerung, kleinerem ersten Schritt und einem Fortschrittsmaß, das nicht aus Statusberichten besteht. Wer nur den Zeitplan erneuert, wiederholt das Projekt.

Warum zweite Anläufe anders scheitern als erste

Der erste Anlauf scheitert an Ursachen, der zweite an Hypotheken. Das Budget ist angegriffen, die Geduld der Geschäftsführung verbraucht, und die Mannschaft hat gelernt, dass Ankündigungen nichts kosten. Ein zweiter Anlauf startet deshalb nie bei null, sondern im Minus, und genau das übersehen Pläne, die einfach eine neue Version des alten Projektplans sind.

Dazu kommt ein stiller Zeitdruck: Das Geschäft ist weitergelaufen. Prozesse haben sich verändert, Daten sind gealtert, Anforderungen von damals stimmen nicht mehr. Je länger der erste Anlauf her ist, desto weniger taugt sein Konzept als Vorlage.

Die gute Nachricht steht dagegen: Die meisten Abbrüche haben behebbare Ursachen. Ob sich ein gescheitertes ERP-Projekt retten lässt, entscheidet sich fast immer an Steuerung, Verantwortung und Datenqualität, nicht an der Software.

Erst die Diagnose, dann der Neustart

Vor jedem Neustart steht die Frage, woran der erste Anlauf wirklich gescheitert ist. Die Antwort im Haus lautet oft „am Partner“ oder „am System“, und beides ist bequem, weil es niemanden im eigenen Haus meint. Eine belastbare Diagnose prüft vier Felder: Waren Prozesse und Anforderungen geklärt? Trug die Datenbasis? Gab es eine Steuerung mit Entscheidungsrecht? Und hatte der Umsetzungspartner die richtige Aufgabe, oder die falsche unter falschen Vorgaben?

Für diese Diagnose lohnt ein Blick von außen, denn die Beteiligten des ersten Anlaufs sind Partei. Eine Zweitmeinung von außen liefert den Befund in Tagen statt Monaten und beantwortet die heikelste Frage gleich mit: ob der bisherige Partner Teil des zweiten Anlaufs sein sollte.

Zur Diagnose gehört die Inventur des Verwertbaren. Bereinigte Stammdaten, dokumentierte Prozesse, geschulte Key User und selbst die Fehlerliste des ersten Anlaufs sind bezahltes Kapital. Es wäre teuer, sie aus Frust mit zu entsorgen.

Der Neustart-Fahrplan in fünf Schritten

1. Befund festschreiben: Ursachen, Verwertbares, Nicht-Verhandelbares. Eine Seite, von der Geschäftsführung unterschrieben.
2. Steuerung neu besetzen: eine Person mit Entscheidungsrecht auf Ihrer Seite, ein Eskalationsweg, ein Fortschrittsmaß aus dem System statt aus Folien.
3. Datenbasis vor Funktionen: erst die Daten auf den Stand bringen, den der erste Anlauf schuldig geblieben ist, dann über Funktionen sprechen.
4. Kleiner erster Schritt: ein abgegrenzter Bereich produktiv, mit echtem Monatsabschluss. Der zweite Anlauf braucht früh einen Beweis, kein Versprechen.
5. Partnerfrage geordnet klären: bleiben, neu ausschreiben oder den Partner mitten im Projekt wechseln. Jede der drei Antworten ist zulässig, aber nur als Ergebnis des Befunds.

Go-live-Rettung: wenn das Projekt kurz vor dem Start kippt

Ein Sonderfall des zweiten Anlaufs beginnt kurz vor dem ersten: Der Go-live-Termin steht, aber Migrationstests scheitern, offene Punkte wachsen schneller als sie schließen, und niemand mag die Verschiebung aussprechen. Hier gilt: Ein verschobener Start kostet Wochen, ein misslungener kostet das Vertrauen des ganzen Hauses und oft das Projekt.

Die Entscheidung braucht harte Kriterien statt Zuversicht: eine vollständige Generalprobe der Datenübernahme, ein geprobter Tagesbetrieb für die Kernprozesse, benannte Verantwortliche für die erste Woche und eine Rückfalllinie, falls es ernst wird. Sind diese Punkte nicht belegbar erfüllt, ist die Verschiebung keine Niederlage, sondern Steuerung. Kippt der Start trotzdem, gilt die gleiche Reihenfolge wie beim großen Neustart: stabilisieren, Befund, dann geordnet wieder anlaufen.

Woran Sie einen tragfähigen zweiten Anlauf erkennen

An drei Merkmalen, noch bevor die erste Funktion live ist: Der Befund des ersten Anlaufs liegt schriftlich vor und wurde nicht wegmoderiert. Das Fortschrittsmaß kommt aus dem System, etwa aus Migrationsläufen und Testabdeckung, nicht aus Ampelfolien. Und es gibt eine Person auf Ihrer Seite, die Nein sagen darf, zum Umfang, zum Termin und zum Partner.

Fehlt eines davon, ist der zweite Anlauf der erste mit neuem Datum. Die Warnsignale sind dieselben wie beim ersten Mal, sie kommen nur schneller. Genau diese Steuerung übernehmen wir senior-geführt: Governance und Delivery Management, mit der Steuerung auf Ihrer Seite und Business Central als Heimat.