Die Sprache der Protokolle und bewährte Migrationsmethoden

Teil 5 der 6-teiligen Serie „Das Migrationshandbuch“

In Teil 4 haben wir den Umstellungsplan, unser detailliertes Drehbuch für den Go-Live. Ein Drehbuch ist jedoch erst dann wirksam, wenn alle Beteiligten ihre Texte gründlich geprobt haben.

Wenn Sie in der letzten Woche den ersten Versuch mit voller Ladung starten, ist die Wahrscheinlichkeit eines Scheiterns extrem hoch. Die Fehler werden zu zahlreich, die Belastung zu hoch und die Zeit zu kurz sein, um sie zu beheben.

In diesem Artikel blicken wir vom eigentlichen Go-Live zurück und konzentrieren uns auf die Monate der Vorbereitung. Wir beleuchten den iterativen Kreislauf der Testläufe, die Kunst der verständlichen Protokollierungund die strikten Namenskonventionen , die Ihr Projekt vor dem Chaos bewahren.

Die iterative Schleife: Der Weg zur Perfektion

Die Datenmigration funktioniert eher wie ein Kreislauf aus Fehlschlägen und Verbesserungen als wie ein einfacher linearer Prozess (Extrahieren -> Transformieren -> Laden -> Fertig).

Wir führen diese Zyklen in einer speziellen Simulationsumgebung (TRN), die ein Spiegelbild der Produktionsumgebung sein muss.

Laufschleifen:

1. Durchlauf 1: Wir laden die Rohdaten und erwarten eine hohe Fehlerrate. Das ist normal. Das System verwirft alle Daten, die nicht den strengen Validierungsregeln des ERP-Systems entsprechen.
2. Analyse & Korrektur: Wir gehen , wann immer möglich , der eigentlichen Ursache in den Quelldateien (oder der Transformationslogik) auf den Grund , anstatt manuelle Korrekturen direkt in Infor LN vorzunehmen.
3. Durchlauf 2: Wir laden neu. Die Fehlerrate sinkt nun deutlich. Es handelt sich um subtile Logikfehler (z. B. gehört Artikel A zu einer nicht existierenden Verkaufsgruppe).
4. Durchlauf 3: Wir erreichen nahezu Perfektion . Nun betritt der Key-User das System. Er zählt nicht nur die Zeilen, sondern versucht auch, den Artikel zu versenden und dem Kunden die Rechnung zu stellen
5. Durchlauf N: Wir wiederholen den Vorgang, bis er langweilig wird. Eine langweilige Migration ist eine erfolgreiche Migration.

Strategischer Nutzen: Erstens werden häufige Fehlertypen systematisch erfasst und ein Schema erwarteter Fehler erstellt, sodass wir nicht unvorbereitet sind. Zweitens, und vielleicht noch wichtiger,bieten diese Testläufe die beste Gelegenheit, Vertrauen aufzubauen – nicht nur in die Daten, sondern auch zwischen den Teams. Datenmigration ist zwar ein technischer Prozess, aber sie basiert auf dem Zusammenspiel von Menschen, die einander korrigieren, überprüfen und vertrauen müssen.

Ohne dieses gegenseitige Vertrauen kann kein Migrationsskript helfen. Wenn die Schlüsselbenutzer sehen, dass ihr Feedback umgesetzt und Fehler in nachfolgenden Durchläufen behoben werden, löst sich die Barriere „Wir gegen die“ auf und wird durch ein einheitliches Team ersetzt, das bereit für den Go-Live ist.

Die Sprache der Protokolle: Fehler vermenschlichen

Wenn Infor LN einen Datensatz ablehnt, geschieht dies in technischen Hinweisen.

• Beispiel: Referenz existiert nicht: tibom3109001.cmbb->tibom3009001.cmba ['WS0001' ' 9861532' '012' '000002']

Das Senden dieses Rohprotokolls an einen Produktionsleiter ist wirkungslos. Er hat keine Ahnung, was tibom310 oder cmba bedeuten. Als Berater ist es Ihre Aufgabe, als Übersetzer.

Die Übersetzungsmatrix

Sie müssen kryptische Datenbankfehler in umsetzbare Geschäftsaufgaben umwandeln und dabei die wahrscheinlichsten Ursachen angeben.

• Rohprotokoll: Referenz existiert nicht: tibom3109001.cmbb->tibom3009001.cmba ['WS0001' ' 9861532' '012' '000002']
• Analyse des Beraters: Dieses Protokoll weist darauf hin, dass der Hauptartikel (übergeordneter Artikel) der zu importierenden Stückliste ungültig ist. Dafür kann es zwei Hauptgründe geben: Der Artikel existiert nicht im Artikelstamm. Oder der Artikel existiert zwar, aber es fehlen die spezifischen Unterartikeleinstellungen, die erforderlich sind, um als Produktionsartikel .
• Übersetzte Aktion: Artikel 9861532 kann nicht als übergeordneter Stücklistenartikel verwendet werden. Bitte überprüfen Sie, ob der Artikelcode in der Quelldatei korrekt ist und ob die korrekten Unterelemente für die Produktion eingerichtet sind.

Bewährte Vorgehensweise: Bearbeiten Sie die Rohdatendatei, bevor Sie sie an den Kunden senden. Importieren Sie sie in Excel, filtern Sie technische Störungen heraus (die „falsch positiven“ Ergebnisse, die wir in Teil 3), fügen Sie eine Spalte mit klaren Anweisungen in natürlicher Sprache hinzu und dann an den Dateneigentümer.

Namenskonventionen: Ordnung im Chaos schaffen

Im dritten Monat des Projekts werden Sie Hunderte von Dateien haben. Eine willkürliche Benennung der Dateien (z. B. Items_Final.csv, Items_Final_v2.csv) führt zu Fehlern und Verwirrung. Beim Go-Live ist Präzision unerlässlich.

Sie benötigen eine strikte Namenskonvention.

Jede Datei muss einer strengen Syntax folgen: [Objekt]_[Umgebung]_[Batch-ID]_[Datum]_[Status]

• Objekt: Was befindet sich darin? (z. B. Artikelstammdaten, Verkaufsauftrag).
• Umwelt: Wohin geht es? (TRN, PRD).
• BatchID: Entspricht der Aufgaben-ID in Ihrem Umstellungsplan (z. B. 10A).
• Datum: ISO-Format (JJJJMMTT).
• Status: Original (Unveränderte Quelle), Eingabe (Für den Upload transformiert), Protokoll (Ergebnis/Fehler).

Beispiel:

• Originaldatei: ItemMaster_PRD_10A_20251101_Original (die vom Kunden erhaltene, unveränderte Datei vor jeglicher Bearbeitung).
• Eingabedatei: ItemMaster_PRD_10A_20251101_Input (die tatsächlich verarbeitete Datei).
• Protokolldatei: ItemMaster_PRD_10A_20251101_Log (die Ausgabe enthält Fehler und Verarbeitungsdetails).

Ordnerhierarchie

Verwenden Sie ein gemeinsames Repository mit einer gesperrten Ordnerstruktur, um die Ordnung aufrechtzuerhalten:

1. 01_Source_Received (Unveränderliche Originale vom Client).
2. 02_Ready_For_Upload (Validierte Dateien, warten auf grünes Licht).
3. 03_Archive_Processed (Dateien erfolgreich geladen).
4. 99_Errors_Logs (Hier befinden sich die schlechten Nachrichten).

Die Trockenübung – Freigabe

Bevor wir den Umstellungsplan in der Produktion umsetzen, führen wir einen vollständigen Testlauf in der Testumgebung durch. Dies ist eine Generalprobe. Wir messen jeden Schritt.

• Der strategische Puffer: Wenn das Laden von Kundenaufträgen im Testlauf exakt 4 Stunden dauerte, planen wir im Umstellungsplan nie genau 4 Stunden ein. Wir fügen systematisch einen Zeitpuffer ein, um unvorhergesehene Störungen (Netzwerklatenz, eine gesperrte Datenbanktabelle oder eine Datenänderung in letzter Minute) aufzufangen und sicherzustellen, dass ein einzelnes Problem nicht den gesamten Go-Live-Prozess gefährdet.
• Wenn etwas abstürzt: Wir analysieren und beheben den Fehler sofort.

Der Testlauf endet mit einer formellen Abnahme. Die Hauptbenutzer müssen bestätigen: „Wir haben die migrierten Daten in TRN getestet und genehmigen die Übertragung in PRD.“ Diese Unterschrift minimiert Risiken und stellt sicher, dass die Produktivsetzung planmäßig erfolgt.

Warum dies verpflichtend ist

Diese Anforderung steht in direktem Einklang mit globalen Standards für Compliance und Risikomanagement.

• Compliance-Prüfung (SOX/ITGC): Für jedes Unternehmen, das Prüfungen unterliegt (Sarbanes-Oxley oder ähnliche Vorschriften), ist die Datenmigration ein kritischer Kontrollpunkt. Externe Wirtschaftsprüfer (wie die Big Four) benötigen einen Nachweis über die Benutzerakzeptanztest (UAT), bevor Finanzdaten in die Hauptbuchhaltung übernommen werden. Ohne diese Abnahme gilt die ITGC-Prüfung . Referenz: ISACA – Grundlagen der IS-Prüfung: Prüfungsprogramme
• Projektmanagementstandard (PMBOK): Laut Project Management Institute (PMI) ist die „Validierung des Projektumfangs“ ein formaler Prozess, der die schriftliche Abnahme der Projektergebnisse (der Daten) durch die Stakeholder erfordert, um die Projektphase abzuschließen. Referenz: PMI Community – Validate Scope Process
• Methodik des Anbieters: Die offizielle Infor-Implementierungsmethode sieht ausdrücklich eine „Go/No-Go“-Entscheidungsphase vor, die auf erfolgreichen Tests in einer Simulationsumgebung basiert.

Wir haben so lange getestet, bis der Prozess langweilig geworden ist. Unsere Dateien sind so gut organisiert, dass selbst ein Fremder die Migration durchführen könnte. Wir haben die Fehler der Maschine in menschliche Aktionen übersetzt.

Wir sind bereit. Das System ist live. Die Nutzer loggen sich ein. Doch das Projekt ist noch nicht abgeschlossen. Tatsächlich stehen uns die schwierigsten 72 Stunden erst bevor. Im letzten Teil dieser Reihe behandeln wir Validierung und Hypercare. Wir sprechen darüber, wie wir dem Finanzvorstand den Mehrwert nachweisen und die unvermeidlichen Krisensituationen .

Verfasst von Andrea Guaccio 

9. April 2026