Die erste Importvorlage ist bereits befüllt, dann ergänzt der ERP-Anbieter ein Pflichtfeld. Eine Woche später ändern sich zulässige Statuswerte. Beim nächsten Systemstand wird aus einer flachen Tabelle eine Struktur mit Kopf- und Positionsdaten. Plötzlich wirkt es, als müsse das Mapping zum dritten Mal neu begonnen werden.
Wenn sich das Zielsystem während der Datenmigration ändert, braucht das Projekt kein dauerhaft „fertiges“ Mapping, sondern nachvollziehbare Mappingstände und eine gezielte Auswirkungsprüfung. So können stabile Entscheidungen weiterverwendet werden, während nur die tatsächlich betroffenen Felder, Regeln und Tests erneut bearbeitet werden.
Das ist bei ERP-Einführungen kein seltener Sonderfall. Konfiguration, Prozesse und Importobjekte entwickeln sich parallel. Problematisch wird es erst, wenn niemand mehr sagen kann, welche Zielversion einer Zuordnung zugrunde lag und was eine neue Änderung für bereits vorbereitete Daten bedeutet.
Zielsystem ändert sich während der Datenmigration: Warum Warten meist zu spät ist
Ein Mapping legt fest, wie Informationen aus dem Altsystem in die benötigten Strukturen und Felder des neuen ERP gelangen. Für die ersten Analysen muss nicht jedes Zielfeld endgültig entschieden sein. Datenobjekte, fachliche Bedeutungen, wichtige Beziehungen und große Teile des Migrationsumfangs lassen sich häufig schon früher bearbeiten.
Wartet die Datenmigration dagegen bis zur vollständigen Konfiguration, fehlen die eigenen Daten oft in den frühen Systemtests. Kritische Quellstrukturen, Transformationen und Datenqualitätsprobleme werden erst erkannt, wenn Integrationstest oder Go-live bereits näher rücken.
Die gegenteilige Annahme ist ebenso riskant: Ein früher Entwurf darf nicht stillschweigend als endgültige Zielanforderung behandelt werden. Sonst wird ein vorläufiges Feld zur festen Transformationsregel, obwohl sich der neue Geschäftsprozess noch verändert.
Das eigentliche Problem ist nicht die Änderung, sondern ihre unbekannte Wirkung
Eine neue Feldbezeichnung kann ohne technische Folge bleiben. Ein neues Pflichtfeld kann dagegen jeden Datensatz eines Objekts betreffen. Wird eine Kontengruppe geändert, können zusätzliche Werte, Nummernkreise oder abhängige Felder notwendig werden. Aus einer kleinen Konfigurationsänderung entsteht dann eine neue Migrationsregel.
Deshalb sollte jede Zieländerung gegen dieselben fünf Ebenen geprüft werden:
- Migrationsumfang: Ändert sich, welche Datenobjekte oder Datensätze benötigt werden?
- Mapping: Sind Zielstruktur, Feldbedeutung oder zulässige Werte betroffen?
- Transformation: Muss eine technische Regel, Ableitung oder Dateistruktur angepasst werden?
- Ladeweg: Ändern sich Vorlage, Reihenfolge, Schlüssel oder Importvoraussetzungen?
- Prüfung: Welche bisherigen Testfälle und Freigaben verlieren ihre Aussagekraft?
Diese Auswirkungsprüfung verhindert zwei Extreme: das ungeprüfte Weiterarbeiten mit veralteten Regeln und den unnötigen Neustart des gesamten Mappings.
Fünf Arten von Zieländerungen verlangen unterschiedliche Reaktionen
1. Nur Bezeichnung oder Darstellung ändern sich
Ein Feld erhält einen neuen Namen, behält aber Bedeutung, Datentyp und technische Identität. Dann genügt möglicherweise eine dokumentierte Aktualisierung. Die Transformationslogik muss nicht automatisch neu gebaut werden.
2. Zulässige Werte oder Customizing ändern sich
Ein Status, eine Einheit, Zahlungsbedingung oder Organisationszuordnung wird ergänzt, ersetzt oder entfernt. In diesem Fall sind Wertemapping und betroffene Datenbestände zu prüfen. Wie alte und neue Codes kontrolliert verbunden werden, beschreibt der Beitrag zum Umschlüsseln von ERP-Werten.
3. Pflicht, Format oder Feldlänge ändern sich
Ein bisher optionales Feld wird verpflichtend, ein Datum erhält ein anderes Format oder eine Zeichenlänge wird begrenzt. Dann muss geklärt werden, ob die Quelle die Information liefert, ob eine fachlich zulässige Ableitung existiert oder ob eine offene Entscheidung entsteht.
4. Die Struktur eines Migrationsobjekts ändert sich
Informationen wechseln von einer Tabelle in eine abhängige Struktur, ein neues Positionssegment kommt hinzu oder Schlüsselbeziehungen ändern sich. Das betrifft nicht nur eine Spalte. Extraktion, Transformation, Dateiaufbau, Ladefolge und Prüfungen können gemeinsam betroffen sein.
5. Der Zielprozess verändert den fachlichen Umfang
Wenn das neue ERP einen Vorgang anders abbildet, kann ein zusätzliches Datenobjekt erforderlich werden oder ein bisher geplantes Objekt entfallen. Dann reicht keine technische Anpassung. Projektleitung und Fachbereich müssen den Migrationsumfang und die fachliche Zielentscheidung erneut bestätigen.
Jedes Mapping braucht einen benannten Zielstand
„Mapping aktuell“ ist keine ausreichende Versionsangabe. Ein prüfbarer Stand sollte erkennen lassen, auf welcher Grundlage er entstand. Das kann beispielsweise die Version einer Importvorlage, ein ERP-Release, ein Konfigurationsstand, ein dokumentierter Systemtermin oder eine Kombination daraus sein.
Für jedes Datenobjekt sollten mindestens folgende Informationen zusammengehören:
- der verwendete Zielstand,
- die zugehörige Mappingversion,
- die Version der ausführbaren Transformation,
- die daraus erzeugte Testdatei,
- das Testergebnis und
- offene beziehungsweise vorläufige Entscheidungen.
Damit lässt sich eine spätere Änderung präzise einordnen. Das Projekt vergleicht nicht „alt gegen neu“ im Allgemeinen, sondern beispielsweise Zielvorlage 3 mit Zielvorlage 4 und sieht, welche konkreten Bestandteile abweichen.
Vorläufige Entscheidungen müssen sichtbar vorläufig bleiben
Frühes Arbeiten ist nur dann effizient, wenn der Reifegrad einer Zuordnung erkennbar ist. Dafür genügt ein kleiner, konsequent verwendeter Status:
- Vorbereitet: Quelle und wahrscheinliches Ziel wurden analysiert, die fachliche Entscheidung fehlt noch.
- Vorläufig bestätigt: Die Regel ist für den aktuellen Zielstand plausibel und darf getestet werden.
- Fachlich bestätigt: Bedeutung und Prozesswirkung sind freigegeben.
- Technisch umgesetzt: Die bestätigte Regel ist in der benannten Transformation enthalten.
- Geprüft: Die Umsetzung wurde mit dem zugehörigen Zielstand nachgewiesen.
- Erneut zu prüfen: Eine Zieländerung kann die bisherige Entscheidung beeinflussen.
Diese Stati dürfen nicht zum Selbstzweck werden. Ihr Nutzen liegt darin, dass eine Zieländerung nur die betroffenen Zuordnungen zurücksetzt. Unveränderte und weiterhin gültige Entscheidungen bleiben erhalten.
Eine kleine Abhängigkeitskette macht Änderungen beherrschbar
Damit die Auswirkungsprüfung nicht von Erinnerung abhängt, sollte jedes kritische Zielfeld mit seiner Umsetzung und seinem Nachweis verbunden sein:
Zielobjekt und Zielfeld → Quellfelder → fachliche Mappingregel → technische Regelversion → Testfall → Prüfergebnis.
Ändert sich beispielsweise die Zieldefinition eines Lagerstatus, lässt sich dadurch ermitteln, welche Quellwerte, Skriptteile, Importspalten und Testfälle betroffen sind. Ohne diese Verbindung müsste das Team mehrere Dateien durchsuchen oder auf die Person hoffen, die die Regel ursprünglich gebaut hat.
Der vorhandene Artikel zum Datenmapping im ERP-Projekt zeigt, welche Bestandteile eine einzelne Transformationsregel nachvollziehbar machen. Für ein veränderliches Ziel kommt zusätzlich die Verbindung zum konkreten Zielstand hinzu.
So läuft eine kontrollierte Zieländerung durch die Migration
- Änderung beschreiben: Was wurde im Ziel wirklich geändert – und ab welchem Stand gilt es?
- Betroffene Objekte ermitteln: Welche Felder, Werte, Beziehungen, Regeln und Testfälle hängen daran?
- Fachliche Wirkung entscheiden: Ist nur die Technik betroffen oder ändert sich der Geschäftsprozess?
- Regel gezielt anpassen: Nur die betroffenen Transformationsbestandteile erhalten eine neue Version.
- Begrenzten Regressionstest ausführen: Bereits geprüfte Fälle werden dort erneut geladen, wo die Änderung wirken kann.
- Neuen Stand freigeben: Mapping, Transformation, Datei und Ergebnis werden wieder eindeutig verbunden.
Ein Regressionstest prüft hier, ob eine Änderung bislang funktionierende Migrationsfälle unbeabsichtigt verschlechtert hat. Dafür muss nicht jedes Mal der gesamte Datenbestand geladen werden. Eine gezielte Auswahl kann früh zeigen, ob die Anpassung korrekt und vollständig ist.
Eigene Daten machen ein unfertiges Ziel früher verständlich
Abstrakte Feldlisten reichen für viele fachliche Entscheidungen nicht aus. Ein Keyuser erkennt die Wirkung einer neuen Struktur oft schneller, wenn darin ein vertrauter Kunde, ein reales Material oder eine bekannte Auftragskonstellation erscheint. Begrenzte Testmigrationen mit repräsentativen eigenen Daten verbinden deshalb Systementwicklung und Mapping.
Dafür muss noch kein vollständiges Datenobjekt fertig sein. Ein kleiner, bewusst ausgewählter Prototyp kann unterschiedliche Werke, Sonderfälle, Wertelisten und Beziehungen abdecken. Der Fachbereich sieht am Zielprozess, welche Information fehlt oder anders verstanden wurde. Die Rückmeldung fließt anschließend in die nächste Mappingversion.
So wird ein unfertiger Zielstand nicht zur Ausrede für Stillstand. Er wird zu einer prüfbaren Arbeitsgrundlage – mit klarer Kennzeichnung, welche Aussagen bereits belastbar und welche noch vorläufig sind.
Zielreife sollte je Datenobjekt bewertet werden
Die Aussage „Das ERP ist zu 80 Prozent fertig“ hilft der Datenmigration wenig. Für Kundenstämme kann die Zielstruktur bereits stabil sein, während Produktionsdaten noch grundlegende Änderungen durchlaufen. Deshalb sollte die Projektleitung Zielreife je Datenobjekt betrachten.
Für den Start eines ersten Mappings reichen häufig:
- ein bestätigtes fachliches Zielobjekt,
- eine sichtbare vorläufige Zielstruktur,
- benannte Ansprechpartner für offene Fach- und Systemfragen,
- ein Verfahren zur Versionierung von Änderungen und
- die Möglichkeit, begrenzte Testdaten zu laden oder zumindest technisch zu prüfen.
Für eine fachliche Freigabe braucht es dagegen den stabilen Zielprozess, gültige Wertelisten, vollständige Pflichtanforderungen und einen nachweisbaren Test. Startkriterium und Abschlusskriterium sind bewusst nicht dasselbe.
Typische Fehlversuche bei einem beweglichen Zielsystem
- Bis zur vollständigen ERP-Konfiguration warten: Quellprobleme und Migrationslücken werden zu spät sichtbar.
- Den ersten Zielentwurf als endgültig behandeln: vorläufige Annahmen werden unbemerkt in Skripte und Dateien eingebaut.
- Nach jeder Änderung das gesamte Mapping neu öffnen: stabile Entscheidungen werden ohne Grund erneut diskutiert.
- Nur die Importvorlage austauschen: Mapping, Transformation und Testfälle bleiben auf dem alten Stand.
- Änderungen in Meetings weitergeben: ohne benannten Zielstand und Auswirkungsliste geht Wissen zwischen Beteiligten verloren.
- Nur technisch erneut importieren: eine veränderte Prozesswirkung bleibt fachlich ungeprüft.
Wer muss bei Zieländerungen zusammenarbeiten?
Der ERP-Anbieter oder das Zielsystemteam beschreibt die Änderung und stellt die aktuelle technische Anforderung bereit. Der Fachbereich entscheidet, wie sich die neue Zielstruktur auf den Geschäftsprozess und die Bedeutung der Daten auswirkt. Die Datenmigration ermittelt die betroffenen Quellfelder, Mappingregeln, Transformationen und Prüfungen und setzt die freigegebene Anpassung wiederholbar um.
Eine externe Migrationsunterstützung kann diese Verbindung führen: Zielstände vergleichen, Auswirkungen je Datenobjekt sichtbar machen, konkrete Entscheidungsvorschläge vorbereiten und nur die tatsächlich betroffenen Regeln und Testfälle neu bearbeiten. Die fachliche Freigabe bleibt beim Unternehmen.
Ein veränderliches Ziel braucht Kontrolle, keinen Stillstand
Das neue ERP muss nicht vollständig fertig sein, bevor die Datenmigration beginnen kann. Es muss aber klar sein, mit welchem Zielstand gearbeitet wird, welche Entscheidungen vorläufig sind und wie Änderungen bis in Mapping, Transformation und Test nachverfolgt werden.
Wenn Ihre Mappingarbeit nach jeder neuen Importvorlage zurück auf Anfang springt, lohnt sich zuerst eine strukturierte Auswirkungsanalyse. Wir helfen dabei, Zielstände und Mappingregeln zu verbinden, betroffene Stellen gezielt zu identifizieren und wieder einen belastbaren nächsten Testlauf vorzubereiten.
So wächst die Datenmigration kontrolliert mit dem Zielsystem – statt ihm ständig hinterherzulaufen.