ERP-Cutover planen: kontrolliert in Etappen umsteigen

Abhängigkeiten vor dem Stichtag klären

Bei einer gemeinsamen Umstellung müssen Stammdaten, offene Vorgänge, Schnittstellen und Anwender für den vorgesehenen Umfang bereit sein. Fehlt eine Voraussetzung, braucht es eine bewusste Entscheidung über Start, Einschränkung oder Verschiebung.

In Etappen umzustellen heißt: Ein klar abgegrenzter Bereich geht produktiv und wird im vereinbarten Betrieb geprüft, bevor der nächste folgt. Dauer, Abhängigkeiten und Rückfallweg werden für das Projekt festgelegt. So lassen sich Risiken eingrenzen; ein ausfallfreier Umstieg ist damit nicht pauschal garantiert.

Welcher Bereich zuerst geht

Wähle einen Bereich mit erkennbarem Nutzen und beherrschbaren Abhängigkeiten. Ob Einkauf, Lager oder ein anderer Ablauf zuerst passt, hängt von Daten, Schnittstellen und verfügbaren Verantwortlichen ab.

Was zuerst geht, entscheidet sich an deinen Abläufen, nicht an einer allgemeinen Empfehlung. Genau dafür gibt es den Setup-Check.

Was ein Parallelbetrieb wirklich kostet

Zwei Systeme gleichzeitig zu pflegen ist teuer und fehleranfällig, deshalb sollte die Phase kurz und klar begrenzt sein. Sinnvoll ist sie dort, wo ein Bereich noch Zahlen aus dem Altsystem braucht, etwa offene Posten während eines Monatswechsels.

Wichtig ist, vorher festzulegen, welches System in dieser Zeit führt. Ohne diese Festlegung entstehen zwei Wahrheiten, und die Aufräumarbeit danach ist teurer als der Umstieg selbst.

Den Rückfallweg vor dem Start prüfen

Vor jeder Etappe wird geprüft, welcher Datenstand wiederherstellbar ist, wer entscheidet und wie neu entstandene Vorgänge behandelt werden. Der Rückfallweg braucht eine Erprobung; seine Dauer darf nicht ohne Test vorausgesetzt werden.

Vor jeder Umstellung eine Go-/No-Go-Entscheidung treffen.

Ein Umstellungsplan braucht einen festgelegten Datenstand, den Verantwortlichen für den letzten Abgleich und den Zeitpunkt, ab dem neue Vorgänge im Zielsystem erfasst werden. Bereits offene Aufträge und Schnittstellen müssen eindeutig zugeordnet sein.

Vor dem Start prüft ihr die vereinbarten Mengen oder Summen, einen repräsentativen End-to-End-Ablauf und den Umgang mit Fehlern. Definiert, welche Abweichung den Start stoppt und wer über Freigabe oder Verschiebung entscheidet. Die Kriterien müssen vor dem Zeitdruck der Umstellung feststehen.

Eine Sicherung ist noch kein geprüfter Rückfallweg. Die Frappe-Restore-Dokumentation unterscheidet Datenbank und Dateiarchive und weist auf Versionsgrenzen hin. Für das Projekt muss geklärt sein, welcher Stand tatsächlich wiederherstellbar ist und wie seitdem neu entstandene Geschäftsvorgänge behandelt werden.

Nach dem Wechsel werden Fehler, Abgleich und Supportzuständigkeit in einer vereinbarten Beobachtungsphase kontrolliert. Parallelpflege braucht eine klare Grenze. Etappen können Risiken begrenzen; Dauer, Ausfallzeit und Wiederherstellung bleiben abhängig vom konkreten Plan und seiner Erprobung.

Frappe: Wiederherstellung und Versionsgrenzen · Migration mit geprüftem Datenstand · Erste Einführungsphase abgrenzen

Ein Umstellungsplan mit klarer Entscheidung.

Vor dem Wechsel hält der Plan mindestens fest: letzte Datenerfassung im Altsystem, finaler Exportstand, führendes System nach dem Wechsel, erlaubte Unterbrechung und Verantwortlicher für die Freigabe. Definiere, welche Schnittstellen pausieren und wann sie wieder senden dürfen.

Illustratives Szenario, kein Kundenfall: Nach dem finalen Export trifft eine Bestellung ein. Der Plan muss entscheiden, in welchem System sie erfasst und wie sie beim Abgleich berücksichtigt wird. Einfach die alte Sicherung zurückzuspielen würde den neuen Vorgang noch nicht korrekt behandeln.

Ein Start wird verschoben, wenn ein vereinbartes Stop-Kriterium erfüllt ist, etwa eine ungeklärte Bestandsdifferenz oder ein nicht erprobter Wiederherstellungsweg. Wiederherstellungszeit und zulässiger Datenverlust müssen aus Tests und Betriebsanforderungen kommen, nicht aus einer pauschalen Null-Ausfall-Zusage.