Zweiter Anlauf nach einem gescheiterten ERP-Projekt

Ein zweiter Anlauf gelingt nur, wenn er nicht denselben Fehler wiederholt, nämlich sofort loszulegen. Erst kommt das Fundament: eine bereinigte Datenbasis, geklärte Prozesse und eine Governance, die die Steuerung bei Ihnen belässt. Auf diesem Fundament ist Business Central in einem realistischen Rahmen einführbar, statt erneut zu verlaufen.

Warum ist der erste Versuch gescheitert?

Der erste Versuch scheitert fast nie am System und fast immer am fehlenden Fundament. Die Prozesse waren nicht geklärt, bevor gebaut wurde. Die Stammdaten waren nicht bereinigt, bevor migriert wurde. Und es war nicht festgelegt, wer welche Entscheidung treffen darf. Business Central hat dann getreu abgebildet, was ihm vorgegeben wurde, nämlich Unklarheit.

Dass große Technologieprogramme Budget oder Zeit überschreiten, ist kein Einzelfall und kein Versagen Ihres Teams, sondern ein struktureller Befund. Die acht häufigsten Muster stehen im Artikel Warum ERP-Projekte scheitern. Wer den zweiten Anlauf plant, sollte davon ausgehen, dass die Ursachen benannt werden müssen, nicht die Schuldigen.

Was in der Rückschau fast immer fehlt, ist ein formaler Moment, an dem jemand mit vollständiger Information gefragt hat: Setzen wir dieses Projekt so fort, wie es definiert ist? Ohne diesen Moment werden Entscheidungen trotzdem getroffen, nur eben unbewusst und von Menschen ohne die Befugnis dazu.

Was macht der zweite Anlauf anders?

Der zweite Anlauf dreht die Reihenfolge um. Erst die Datenbasis bereinigen, dann migrieren. Erst die Kernprozesse klären, dann konfigurieren. Erst Entscheidungsrechte festlegen, dann starten. Das klingt selbstverständlich, war aber im ersten Versuch mit hoher Wahrscheinlichkeit genau umgekehrt, weil der Druck zum sichtbaren Fortschritt größer war als der zur Klärung.

Was Sie aus dem ersten Versuch mitnehmen können, ist mehr als Sie denken: Prozessaufnahmen behalten ihren Wert, bereinigte Daten ebenso, und die gelernten Anforderungen sind belastbarer als jedes Lastenheft aus der Anfangszeit. Was nicht ungeprüft mitkommt, sind Konfiguration und Anpassungen. Die werden gegen das neue Zielbild geprüft, nicht übernommen.

Der zweite Anlauf startet damit nicht bei null, sondern mit einer Bestandsaufnahme. Sie dauert typischerweise zwei bis vier Wochen und beantwortet eine einzige Frage: Was ist tragfähig, und was muss neu entschieden werden?

Warum entscheidet das Fundament, nicht die Geschwindigkeit?

Das Fundament entscheidet, weil Geschwindigkeit im ERP-Projekt eine Scheingröße ist. Ein Projekt, das in sechs Monaten live geht und danach zwei Jahre Nacharbeit braucht, war nicht schnell. Ein Projekt, das acht Monate braucht und danach trägt, war nicht langsam. Gemessen wird am Ende die Zeit bis zum verlässlichen Betrieb, nicht die Zeit bis zum Go-live.

Praktisch bedeutet das genau drei Vorleistungen, die sich nicht abkürzen lassen: benannte Verantwortliche je Datenobjekt, dokumentierte Kernprozesse mit den gewollten Änderungen, und ein Entscheidungstakt mit festen Terminen. Diese drei Punkte kosten wenige Wochen und sparen erfahrungsgemäß Monate.

Die Steuerung bleibt dabei durchgehend auf Ihrer Seite, mit Business Central als Heimat. Ein zweiter Anlauf, der die Verantwortung wieder vollständig auslagert, hat den wichtigsten Unterschied zum ersten nicht gemacht.