Im Abstimmungstermin wird entschieden, dass gesperrte Lieferanten nicht ins neue ERP-System übernommen werden. Das Mapping ist angepasst, im Besprechungsprotokoll steht der Beschluss ebenfalls. Das Skript für die nächste Migrationsdatei arbeitet jedoch noch mit der alten Regel. Der Import läuft technisch fehlerfrei – und trotzdem landen die falschen Datensätze im Testsystem.
Eine ERP-Datenmigration zu dokumentieren bedeutet deshalb nicht, am Projektende einen Bericht zu schreiben. Die Dokumentation muss während der Umsetzung dafür sorgen, dass fachliche Entscheidung, Mapping, technische Regel, erzeugte Datei und Prüfergebnis denselben Stand beschreiben. Fehlt diese Verbindung, kann jede einzelne Unterlage korrekt aussehen, während der nächste Datenlauf bereits davon abweicht.
ERP-Datenmigration dokumentieren: Was damit konkret gemeint ist
Eine belastbare Dokumentation verbindet den Weg einer Datenregel vom Zielsystem bis zur Freigabe. Für eine einzelne Regel lässt sich dieser Weg so lesen:
Zielanforderung → Quellbeleg → freigegebene Mappingregel → Skriptversion → erzeugte Datei → Prüfergebnis → Freigabe
Der Quellbeleg zeigt dabei, auf welche Tabelle, welches Feld oder welche nachvollziehbare Auswertung im Altsystem sich die Regel stützt. Das Mapping hält fest, welche Zielinformation daraus entsteht und welche Umwandlung dafür erforderlich ist. Das Skript setzt diese Regel technisch um. Die erzeugte Datei und das Prüfergebnis belegen anschließend, was mit genau diesem Stand tatsächlich ins Zielsystem gelangt ist.
Entscheidend sind nicht die einzelnen Dokumente, sondern die Verbindungen dazwischen. Ein Projektteam muss bei einer Abweichung erkennen können: Welche Regel galt? Wo wurde sie umgesetzt? Mit welchem Skript entstand die geprüfte Datei? Und auf welchen Datenstand bezieht sich die Freigabe?
Ein Fachentscheid muss bis zum Prüfergebnis nachverfolgbar bleiben
Bleiben wir bei den gesperrten Lieferanten. Die Projektleitung entscheidet gemeinsam mit Einkauf und Buchhaltung, dass sie nicht migriert werden. Diese Entscheidung ist erst dann wirksam dokumentiert, wenn sie den gesamten Arbeitsweg erreicht.
1. Die Zielanforderung wird eindeutig
Zunächst muss feststehen, was das neue ERP-System fachlich erhalten soll: nur aktuell nutzbare Lieferanten oder zusätzlich bestimmte gesperrte Datensätze, weil sie noch für offene Vorgänge benötigt werden? „Gesperrte Lieferanten ausschließen“ wäre zu grob, wenn verschiedene Sperrarten im Altsystem unterschiedliche Bedeutungen haben.
2. Die Quelle der Entscheidung wird belegt
Danach wird festgehalten, an welchen Quellfeldern sich die Auswahl erkennen lässt und ob weitere Tabellen oder Bedingungen dazugehören. Dieser Beleg ist wichtig, weil eine fachlich verständliche Regel sonst technisch anders ausgelegt werden kann als beabsichtigt.
3. Das Mapping enthält die freigegebene Regel
Im Mapping der ERP-Datenmigration wird nicht nur ein Quellfeld einem Zielfeld zugeordnet. Dort gehört auch die Auswahl- oder Transformationsregel hin, die für das Datenobjekt beschlossen wurde. In unserem Beispiel muss erkennbar sein, welche Sperrkennzeichen ausgeschlossen werden, welche Ausnahmen gelten und wer diese Regel fachlich bestätigt hat.
4. Die technische Umsetzung verweist auf genau diese Regel
Das SQL-Skript oder eine andere Transformationslogik setzt den freigegebenen Stand um. Die komplette Regel sollte nicht zusätzlich in mehreren Dokumenten neu formuliert werden. Besser ist eine eindeutige Referenz: Das Mapping beschreibt die fachliche Wahrheit; die technische Umsetzung ist über Regelkennung und Version damit verbunden.
Eine Version ist hier kein kompliziertes Softwaresystem. Gemeint ist zunächst nur ein eindeutig benannter Stand, an dem später erkennbar bleibt, welche Fassung verwendet wurde. Schon eine konsequente Änderungsnummer mit Datum und Verantwortlichem ist besser als Dateien mit Namen wie „final_neu_2“.
5. Datei, Test und Freigabe gehören zu demselben Lauf
Die nächste Migrationsdatei erhält eine eindeutige Laufkennung – also einen Namen, der sie zweifelsfrei einem Testlauf und einem Erzeugungsstand zuordnet. Das Prüfergebnis verweist auf diese Datei. Die fachliche Freigabe gilt ebenfalls nur für diesen Stand und nicht pauschal für das Datenobjekt „Lieferant“.
So lässt sich später nicht nur sagen, dass getestet wurde. Es ist nachvollziehbar, welche Regel in welcher Datei geprüft wurde und ob die technische Umsetzung tatsächlich der fachlichen Entscheidung entsprach.
Mapping, Skript und Test erfüllen unterschiedliche Aufgaben
Viele Dokumentationsprobleme entstehen, weil mehrere Unterlagen gleichzeitig zur vermeintlich vollständigen Wahrheit werden. Das Besprechungsprotokoll erklärt, warum eine Entscheidung gefallen ist. Es steuert aber nicht automatisch den nächsten Datenlauf. Das Mapping beschreibt die verbindliche fachliche Zuordnung. Es erzeugt jedoch noch keine Daten. Das Skript führt die Regel aus, beweist aber allein nicht, dass die Regel fachlich richtig ist. Erst der Test zeigt, was im Zielsystem angekommen ist.
Diese Aufgaben sollten getrennt bleiben, aber sichtbar aufeinander verweisen:
- Das Entscheidungsprotokoll hält Begründung, Beteiligte und Datum fest.
- Das Mapping ist der verbindliche Arbeitsstand für Quelle, Ziel und fachliche Regel.
- Das Skript setzt diesen Stand reproduzierbar um und trägt eine eindeutige Version.
- Die Migrationsdatei zeigt das Ergebnis eines konkreten Erzeugungslaufs.
- Test und Freigabe belegen, was technisch und fachlich geprüft wurde.
Die Dokumentation ersetzt damit weder die technische Umsetzung noch die fachliche Prüfung. Sie sorgt dafür, dass beides nicht unbemerkt auseinanderläuft.
Warum die Dokumentation trotz vieler Dateien unvollständig sein kann
Beschlüsse bleiben in Protokollen oder E-Mails hängen
Ein Protokoll ist sinnvoll, um eine Entscheidung festzuhalten. Problematisch wird es, wenn niemand den Beschluss in Mapping und Umsetzung überführt. Dann kennt ein Teil des Teams die neue Regel, während die nächste Datei weiterhin nach dem alten Stand entsteht.
Dieselbe Regel wird mehrfach gepflegt
Steht eine Transformation in einer Word-Datei, einer Excel-Liste, einem Ticketsystem und noch einmal als Kommentar im Skript, entstehen vier mögliche Wahrheiten. Jede Kopie erhöht den Pflegeaufwand. Deshalb sollte eine Regel an einer Stelle verbindlich beschrieben und aus den übrigen Arbeitsmitteln dorthin verwiesen werden.
Testbefunde werden ohne Datenstand weitergegeben
Die Aussage „Lieferantentest war erfolgreich“ reicht nicht. Wurde danach das Mapping geändert oder die Quelldatei neu erzeugt, ist möglicherweise schon ein anderer Stand im Umlauf. Für die Validierung und Abnahme einer ERP-Datenmigration muss deshalb erkennbar sein, welcher konkrete Lauf geprüft wurde.
Die Dokumentation wird erst kurz vor dem Go-live rekonstruiert
Eine nachträglich erstellte Projektdokumentation kann ordentlich aussehen. Sie hilft jedoch nicht mehr dabei, fehlerhafte Teststände zu verhindern. Außerdem muss das Team Entscheidungen aus E-Mails, Chats, Tabellen und Erinnerungen zusammensuchen. Das kostet genau dann Zeit, wenn der nächste Test oder der Go-live vorbereitet werden soll.
So bleibt die Dokumentation leichtgewichtig
Für eine nachvollziehbare ERP-Datenmigration ist nicht automatisch ein weiteres Werkzeug nötig. In vielen Projekten reicht eine klar geführte Mappingdatei als verbindlicher Index, ergänzt um versionierte Skripte und ein Testprotokoll. Wichtig ist, dass die Verbindung konsequent hergestellt wird.
Pro Datenobjekt sollten mindestens folgende Angaben zusammenfinden:
- der fachlich verantwortliche Bereich und der aktuelle Freigabestatus,
- Quelltabellen und Quellfelder, auf denen die Regel beruht,
- Zielfeld, Auswahlregel und notwendige Transformation,
- die zugehörige Fassung des Skripts oder der technischen Umsetzung,
- die Kennung der daraus erzeugten Migrationsdatei,
- offene Befunde, Prüfergebnis und fachliche Freigabe.
Das ist keine Aufforderung, jede Einzelheit doppelt zu beschreiben. Der leichtgewichtige Weg arbeitet mit Verweisen. Das Mapping kann beispielsweise auf die technische Regel im Skript und auf den zugehörigen Testlauf verweisen. Das Testprotokoll nennt wiederum Datenobjekt und Laufkennung. So bleibt jede Information dort, wo sie bearbeitet wird, und ist trotzdem Teil derselben Nachweiskette.
Änderungen brauchen einen festen Rückweg durch die Kette
Bei jeder Testmigration entstehen neue Erkenntnisse. Ein Keyuser bemerkt beispielsweise, dass bestimmte gesperrte Lieferanten wegen offener Bestellungen doch benötigt werden. Damit beginnt kein beiläufiger Zuruf an die Technik, sondern ein kurzer, sichtbarer Änderungsweg:
- Der Befund wird dem betroffenen Datenlauf zugeordnet.
- Der Fachbereich entscheidet, welche Ausnahme künftig gilt.
- Das Mapping erhält den neuen freigegebenen Stand.
- Die technische Regel wird angepasst und eindeutig versioniert.
- Eine neue Datei wird erzeugt und mit der Änderung erneut geprüft.
- Das Ergebnis wird für genau diesen Stand bestätigt.
Dadurch bleibt die Dokumentation lebendig, ohne unübersichtlich zu werden. Alte Stände werden nicht still überschrieben. Sie bleiben als frühere Fassung erkennbar, während der aktuelle Arbeitsstand eindeutig ist.
Wann ein Datenmigrationskonzept oder eine Testcheckliste nicht ausreicht
Ein Datenmigrationskonzept für das ERP-Projekt klärt vor der Umsetzung unter anderem Umfang, Rollen, Grundregeln und Freigaben. Die Dokumentation während der Umsetzung beantwortet eine andere Frage: Entspricht der tatsächlich erzeugte Datenstand noch diesen Entscheidungen?
Auch eine Checkliste für den ersten Testlauf ist hilfreich, um Voraussetzungen zu prüfen. Sie ersetzt aber nicht die fortlaufende Verbindung zwischen jeder Regeländerung, ihrer technischen Umsetzung und dem folgenden Prüfergebnis. Konzept, Checkliste und laufende Dokumentation ergänzen sich; sie sind keine austauschbaren Dokumente.
Welche Verantwortung beim Unternehmen bleibt
Das Unternehmen muss weiterhin entscheiden, welche Daten benötigt werden, welche fachlichen Regeln gelten und wann ein Ergebnis akzeptiert wird. Auch Qualitäts- oder Nachweisanforderungen, die sich aus der eigenen Branche und internen Verantwortung ergeben, können nicht an ein Dokument oder Werkzeug delegiert werden.
Operative Unterstützung kann jedoch die Strecke zwischen diesen Entscheidungen schließen: Quellstrukturen analysieren, Mappingvorschläge vorbereiten, freigegebene Regeln versioniert in SQL oder einer anderen Transformationslogik umsetzen, wiederholbare Dateien erzeugen und Prüfergebnisse mit dem jeweiligen Datenstand verbinden.
Gerade darin liegt der praktische Wert einer guten Dokumentation. Sie ist nicht zusätzlicher Papieraufwand neben der Migration. Sie macht sichtbar, ob fachliche Entscheidung und technische Wirklichkeit noch zusammenpassen – und ermöglicht, den nächsten Datenlauf zu erzeugen, zu prüfen und zu erklären, ohne das Projektwissen jedes Mal aus Postfächern und Einzeldateien rekonstruieren zu müssen.