Der Umstellungsplan – Statische vs. dynamische Daten

(Teil 4 der 6-teiligen Serie „Das Migrationshandbuch“)

In Teil 3haben wir die Engine entwickelt. Wir haben Austauschschemata als bevorzugtes Werkzeug hervorgehoben und die DAL-Doktrin , um die Datenintegrität zu gewährleisten.

Nun stehen wir vor dem entscheidenden Moment des gesamten Projekts: dem Go-Live-Wochenende.

Dies ist kein gewöhnliches Arbeitswochenende. Es handelt sich um eine hochgradig synchronisierte 48- bis 72-stündige Umstellungsphase, in der jede Minute verplant ist. Im Idealfall findet diese Umstellung in den Weihnachtsferienund bietet Ihnen somit ein strategisches Zeitfenster für einen reibungslosen Go-Live Anfang Januar.

Wenn man aber weniger Glück hat (was oft der Fall ist), läuft es wie bei einem typischen Wochenendsprint: Man schaltet das alte System am Freitag um 18:00 Uhr ab und muss das ERP-System bis Montagmorgen betriebsbereit, validiert und für den Geschäftsbetrieb bereit haben.

Wer in diesem Zeitfenster improvisiert, wird scheitern. Sie brauchen ein Drehbuch. Einen Masterplan. Die absolute Referenz , die jede Bewegung vorgibt. Wir nennen dieses Dokument den Umstellungs- und Migrationsplan.

Der Umstellungs-Migrationsplan: Mehr als nur eine Liste

Der Umstellungs- und Migrationsplan ist keine einfache Aufgabenliste. Es handelt sich um einen minutengenauen Zeitplan, der die technischen Berater, die Geschäftsanwender, das Infrastrukturteam und die Partner koordiniert.

Sie können diesen Plan mit dem Tool erstellen, das am besten zu den Gegebenheiten Ihres Unternehmens passt. Ob Sie Microsoft Project für präzise Wasserfallmodelle, Notion für flexible Zusammenarbeit oder einfach eine gemeinsam genutzte Excel-Datei verwenden – das Prinzip bleibt dasselbe.

Das Werkzeug ist zweitrangig; der Inhalt ist obligatorisch.

Unabhängig von der gewählten Software muss ein solider Cutover-Migrationsplan für jede einzelne Aufgabe mindestens die folgenden Spalten enthalten:

1. Aufgaben-ID & Beschreibung: (z. B. „Artikelstammdaten laden“, „Lagerwert prüfen“).
2. Verantwortlicher: die konkret zuständige Person. Es muss sich um eine namentlich genannte Einzelperson handeln, niemals um eine allgemeine Abteilung.
3. Startzeit & Dauer: grobe Schätzung (je genauer, desto besser).
4. Abhängigkeiten: „Aufgabe B kann erst beginnen, wenn Aufgabe A zu 100 % abgeschlossen ist.“
5. Validierungskriterien: Woran erkennen wir, dass es funktioniert hat? (z. B. „Zeilenanzahl stimmt mit der vorherigen überein“).
6. Upload-Datum: Hält genau fest, wann der Upload stattgefunden hat.
7. Status: Der aktuelle Stand der Aufgabe (z. B. „Ausstehend“, „In Bearbeitung“, „Erledigt“), um genau zu wissen, wo wir stehen.
8. Anmerkungen: Ein allgemeines Feld, um während des Prozesses spezifische Details, Abweichungen oder kurze Beobachtungen hinzuzufügen.

Goldene Regel: Aufgaben, die nicht im Migrationsplan stehen, werden nicht ausgeführt. Keine Schnelllösungen, kein „Wenn ich schon mal dabei bin, aktualisiere ich gleich diesen Parameter“. Disziplin ist unerlässlich.

Die Strategie: Statisch vs. Dynamisch

Der größte Fehler ist der Versuch, alles während des Go-Live-Wochenendes hochzuladen . Das ist physikalisch unmöglich. Um das zu überstehen, teilen wir die Daten in zwei Kategorien auf: Statische und dynamische Daten .

1. Statische Daten

Dies umfasst Stammdaten, die sich nicht jede Minute ändern: Artikel, Stücklisten, Arbeitspläne, Kunden, Lieferanten, Preise.

Die Strategie lautet: Wir migrieren diese Daten N Tage oder Wochen vor dem Go-Live . Wir legen keine starre Frist fest. Der Zeitrahmen wird vom Kunden anhand des Datenvolumens und der Komplexität der durchzuführenden Validierungsprüfungen bestimmt

• Wir laden das komplette Set in die Produktionsumgebung.
• Wir prüfen es in Ruhe.
• Wir führen eine „Doppelwartungsphase“ ein. Wenn ein Benutzer während dieser zwei Wochen einen neuen Kunden im Altsystem anlegt, muss er diesen auch manuell im ERP-System anlegen.
• Am Go-Live-Wochenende sind bereits 80 % der Daten vorhanden. Wir müssen uns nur noch um die Transaktionsdaten kümmern.

2. Dynamische Daten

Folgende Daten ändern sich bis zur letzten Sekunde: Lagerbestände, offene Aufträge und unfertige Erzeugnisse (WIP). Diese Daten können nur während des Systemausfalls migriert werden.

Der WIP-Albtraum: Umziehen oder nicht umziehen?

Die Migration von (Work In Progress, WIP) , die sich zur Hälfte in der Fertigung befinden, stellt die komplexeste technische Herausforderung in jedem ERP-Projekt dar.

Stellen Sie sich einen Auftrag über 100 Stück vor. Arbeitsgang 1 (Zuschneiden) ist abgeschlossen. Arbeitsgang 2 (Schweißen) ist zu 50 % abgeschlossen. Arbeitsgang 3 (Lackieren) ist noch nicht bearbeitet. Wie übertragen Sie diese Daten beispielsweise in Infor LN ?

Option A: Strategie „Produktionslinie leeren“: Zwei Wochen vor Produktionsbeginn keine neuen Aufträge mehr annehmen. Die Fabrik zwingen, alle laufenden Aufträge abzuschließen.

• Vorteile: Sie beginnen mit einem sauberen System. Keine komplexe Migrationslogik.
• Nachteile: Für Unternehmen mit langen Vorlaufzeiten (z. B. die Herstellung von Maschinen, die 6 Monate dauern) ist dies nicht immer möglich.

Option B: Migration des „Betriebsstatus“: Wenn Sie offene WIP-Daten migrieren müssen, können Sie nicht einfach einen Datensatz mit der Angabe „50 % erledigt“ einfügen. Sie müssen die Realität im ERP-System simulieren.

1. Migrieren Sie den Produktionsauftrag in LN.
2. Materialverbrauch replizieren: Eine Transaktion kann nicht migriert werden. Sie müssen erneut ausführen . Abhängig von Ihrer Parametrisierung (Rückmeldung vs. Manuell) melden Sie entweder den abgeschlossenen Vorgang, um die automatische Ausgabe auszulösen, oder Sie geben das Material manuell aus, um den WIP-Saldo auszugleichen.
3. Stunden migrieren : Logik einfügen, um die bereits geleisteten Arbeitsstunden zu buchen.
4. Ergebnis: Der Auftrag in LN hat die korrekten Kosten und den korrekten Status und ist bereit für den nächsten Vorgang.

Vermeiden Sie Option B, wenn möglich. Sie erfordert umfangreiche Tests und führt häufig zu Kostenabweichungen. Wenn Sie Option A wählen können, tun Sie dies.

Offener Auftragsumfang: Was bedeutet „offen“?

In Teil 1haben wir uns für einen klaren Schnitt. Nun müssen wir diesen im Plan strikt umsetzen. Mit „offenem Geltungsbereich“ meinen wir zukünftige Verpflichtungen, nicht historische Daten. Wir migrieren nur, was aktuell und umsetzbar ist.

Diese Logik gilt universell für Verkaufsaufträge, Bestellungen, Verträgeund alle anderen offenen Verpflichtungen. Wir migrieren nicht die Historie, sondern den verbleibenden Saldo der noch ausstehenden Lieferungen oder Lieferungen.

Abschließend noch ein Hinweis zum Inventar: Die Regel ist finanzieller Natur: Der Gesamtwert des importierten Lagerbestands muss mit dem Wert im Altsystem des Kunden übereinstimmen. Werden Abweichungen festgestellt, muss die Differenz (Delta) analysiert werden. Es gilt, die Ursache genauer zu bestimmen, um festzustellen, ob sie auf Rundungsfehler oder spezifische Kostenabweichungen zurückzuführen ist. Der Abgleich von Kostenrechnung und Lagerbewertung ist die heikelste Phase des Validierungsprozesses.

Der Punkt ohne Wiederkehr

Im Umstellungsplan ist ein Meilenstein als Punkt ohne Wiederkehr.

In diesem Moment tagt der Lenkungsausschuss. Wir überprüfen das Dashboard:

• Statische Daten: 100% geladen.
• Dynamische Daten: 100 % geladen.
• Finanzabstimmung: Abgestimmt.
• Kritische Punkte: 0.

Lautet die Antwort „GO“, geben wir das System für die Benutzer frei. Es gibt kein Zurück mehr. Das Altsystem wird schreibgeschützt. Lautet die Antwort „ No-Go“, aktivieren wir einen Rollback-Plan. Wir entsperren das Altsystem, und der Geschäftsbetrieb läuft am Montagmorgen mit dem alten ERP-System weiter, als wäre nichts geschehen.

Den Mut zu haben, ein „Nein“ zu sagen, unterscheidet einen erfahrenen Partner von einem unerfahrenen Lieferanten. Lieber eine Woche Verzögerung, als das Geschäft für ein Jahr zu ruinieren.

Fast geschafft

Die Daten sind geladen. Die Kontostände stimmen überein. Der Punkt ohne Wiederkehr ist überschritten. Am Montagmorgen werden sich die Nutzer einloggen. Sie werden Bildschirme sehen, die sie bisher nur aus Schulungen kennen. Sie werden nervös sein. Und Fehler werden sie mit Sicherheit machen.

Vor allem aber wird das System Fehler ausgeben. Im nächsten Teil werden wir besprechen, wie diese Fehler zu interpretieren sind. Wir werden über die Sprache der Protokolle und bewährte Methoden sprechen, um das Chaos der ersten Woche zu bewältigen, ohne den Verstand zu verlieren.

Verfasst von Andrea Guaccio 

2. April 2026