Datenmapping legt fest, wie Informationen aus dem Altsystem in das neue ERP-System übertragen werden. Für jedes benötigte Feld wird beschrieben, woher der Wert kommt, wo er ankommen soll und ob er vorher verändert werden muss. Das Ergebnis ist die Übersetzungsanleitung für die Datenmigration.
Eine Tabelle mit zwei Spalten – Quelle links, Ziel rechts – ist dafür allerdings erst der Anfang. Sie kann vollständig aussehen und trotzdem nicht ausführbar sein. Solange dort nur Feldnamen nebeneinanderstehen, bleiben die entscheidenden Fragen offen: Welche fachliche Bedeutung hat der Quellwert? Wie muss er verändert werden? Was geschieht mit Ausnahmen? Und woran erkennt das Projekt später, dass die Regel richtig umgesetzt wurde?
Genau diese Lücken werden häufig erst beim ersten Datenlauf sichtbar. Ein technisch passendes Zielfeld nimmt Werte an, die fachlich anders gemeint waren. Ein erlaubter Standardwert verdeckt eine ungeklärte Entscheidung. Oder eine Beziehung fehlt, obwohl jeder einzelne Datensatz formal korrekt aussieht.
Ein belastbares Datenmapping verbindet deshalb fünf Dinge: die Bedeutung der Altdaten, die Anforderung des Zielsystems, eine ausführbare Transformationsregel, einen konkreten Prüfnachweis und eine benannte fachliche Entscheidung. Erst diese Verbindung macht aus einer Zuordnung eine Grundlage, mit der sich Daten wiederholbar erzeugen, testen und freigeben lassen.
Ein Feldpaar ist noch keine belastbare Mapping-Entscheidung
Die Zuordnung eines Quellfeldes zu einem Zielfeld beantwortet zunächst nur, wo eine Information herkommen und wo sie ankommen soll. Sie sagt noch nicht, ob beide Felder dasselbe bedeuten. Ebenso wenig legt sie fest, wie Formate, Schlüssel, Wertelisten oder fehlende Angaben behandelt werden.
Das wird besonders deutlich, wenn ein Quellfeld Codes enthält. Die Zuordnung Kundengruppe → Kundengruppe sieht plausibel aus. Für die technische Umsetzung fehlen aber mindestens vier Entscheidungen: Welche Quellcodes sind vorhanden? Welcher Zielcode gehört jeweils dazu? Gibt es Ausnahmen? Und was soll passieren, wenn ein bislang unbekannter Wert auftaucht?
Ein Wertemapping beschreibt genau diese Übersetzung einzelner Ausprägungen, etwa von einem alten Länder- oder Statuscode auf den im Zielsystem zulässigen Wert. Die übergeordnete Transformationsregel legt zusätzlich fest, wie der Zielwert erzeugt wird: durch direkte Übernahme, Umrechnung, Zusammenführung mehrerer Felder, Aufteilung eines Feldes, einen fachlich freigegebenen Standardwert oder eine bewusste Fehlerausgabe.
Das Datenmigrationskonzept hält fest, wie solche Entscheidungen getroffen und freigegeben werden. Das detaillierte Mapping macht sie anschließend pro Datenobjekt, Feld und Regel ausführbar.
Die fachliche Bedeutung steht vor dem Spaltennamen
Gleiche Begriffe sind in zwei ERP-Systemen kein Beweis für gleiche Logik. Eine „Stückliste“ kann im Altsystem zusätzliche Informationen enthalten, die das Zielsystem in einem anderen Objekt, in separaten Merkmalen oder gar nicht im Standard führt. Umgekehrt kann das Zielsystem Angaben verlangen, die im Altsystem nicht als eigenes Feld gepflegt wurden.
Deshalb beginnt ein gutes Mapping nicht mit der Frage „Welches Feld sieht ähnlich aus?“, sondern mit drei aufeinander aufbauenden Fragen:
- Welche geschäftliche Aussage steckt in der Quellinformation?
- Wo und in welcher Form benötigt das Zielsystem diese Aussage?
- Welche Regel überführt die vorhandenen Daten nachvollziehbar in diese Zielbedeutung?
Für einfache Informationen kann die Antwort eine direkte Übernahme sein. Bei steuernden Feldern, Beziehungen oder historisch gewachsenen Codes reicht das nicht. Dort müssen Fachbereich, Zielsystemexperten und technische Datenmigration dasselbe Verständnis herstellen, bevor aus einer vermeintlich eindeutigen Spalte eine belastbare Regel wird.
Diese Klärung setzt außerdem einen entschiedenen Datenumfang voraus. Wenn noch offen ist, welche Gesellschaften, Zeiträume, Standorte oder Datenobjekte übernommen werden, bleibt auch das Mapping beweglich. Der Beitrag Welche Daten gehören beim ERP-Wechsel ins neue System? zeigt, wie dieser Umfang vor der Detailarbeit abgegrenzt werden kann.
Was eine Mapping-Regel dokumentieren sollte
Eine einzige universelle Mapping-Vorlage gibt es nicht. Für eine prüfbare Umsetzung sollten jedoch dieselben Entscheidungsbestandteile sichtbar bleiben – unabhängig davon, ob die Regeln später in SQL, einem ETL-Werkzeug, einer Importvorlage oder einer Staging-Struktur umgesetzt werden.
| Bestandteil | Was konkret festgehalten wird | Warum das für das Projekt wichtig ist |
|---|---|---|
| Quelle | System, Tabelle oder Datei, Feld sowie relevante Auswahlbedingungen | Nur so lässt sich derselbe Eingang für einen weiteren Lauf erneut erzeugen. |
| Fachliche Bedeutung | Wofür die Information im bisherigen Prozess tatsächlich verwendet wird | Sie verhindert Zuordnungen, die nur wegen ähnlicher Feldnamen plausibel wirken. |
| Zielanforderung | Zielobjekt, Zielfeld, Format, Pflichtlogik und betroffene Beziehungen | Die Regel berücksichtigt dadurch nicht nur das Importformat, sondern auch den vorgesehenen Zweck. |
| Transformation | Direkte Übernahme, Filter, Umrechnung, Aufteilung, Zusammenführung, Wertemapping oder freigegebener Standardwert | Die technische Umsetzung folgt einer eindeutigen statt einer mündlich überlieferten Regel. |
| Ausnahmen | Behandlung unbekannter Werte, fehlender Angaben und nicht auflösbarer Beziehungen | Abweichungen werden sichtbar, statt unbemerkt mit einem beliebigen Ersatzwert geladen zu werden. |
| Prüfnachweis | Abfrage, Mengenvergleich, Werteliste, Stichprobe oder fachlicher Testfall | Das Projekt kann belegen, dass die beschlossene Regel tatsächlich angewendet wurde. |
| Status und Verantwortung | Offene Frage, vorbereiteter Vorschlag, fachliche Entscheidung, technische Umsetzung und geprüfte Version | Projektleitung und Beteiligte erkennen, was wirklich entschieden ist und was den nächsten Lauf noch blockiert. |
Eine umfangreiche Tabelle allein löst das Problem allerdings nicht. Entscheidend ist, dass fachliche Entscheidung, technische Regel und Prüfnachweis miteinander verbunden bleiben. Werden diese Informationen in getrennten Dateien ohne gemeinsamen Schlüssel gepflegt, kann bereits eine kleine Änderung zu widersprüchlichen Ständen führen.
Ein vorbereiteter Vorschlag nutzt die Zeit der Keyuser besser
Keyuser kennen die Prozesse und die Bedeutung der Daten. Trotzdem ist es selten effizient, ihnen leere Mapping-Tabellen zu übergeben und eine vollständige Erstzuordnung neben dem Tagesgeschäft zu erwarten. Gerade zu Beginn kennen sie die Zielstruktur häufig noch nicht tief genug, um jedes Zielfeld und jede technische Einschränkung sicher zu beurteilen.
Wir halten einen vorbereiteten Mapping-Vorschlag deshalb für den besseren Ausgangspunkt. Dafür werden Quellstrukturen, vorhandene Dokumentationen, Zielanforderungen und reale Werte zunächst technisch und fachlich eingeordnet. Anschließend prüfen die Keyuser den Vorschlag dort, wo ihre Kompetenz unverzichtbar ist: bei Bedeutung, Sonderfällen, Prozesswirkung und Freigabe.
Das verschiebt nicht die fachliche Verantwortung. Der Kunde entscheidet weiterhin, wie seine Daten im neuen System verwendet werden sollen. Der Unterschied liegt in der Vorbereitung: Der Fachbereich korrigiert einen konkreten Vorschlag anhand sichtbarer Daten, statt gleichzeitig Altsystemanalyse, Zielsystemrecherche und technische Dokumentation von Grund auf übernehmen zu müssen.
Transformationsregeln müssen ausführbar und reproduzierbar sein
Eine Mapping-Datei kann fachlich richtig und technisch trotzdem wirkungslos sein. Das geschieht, wenn die beschlossene Regel nicht eindeutig in der tatsächlichen Datenaufbereitung ankommt. Dann werden Werte beispielsweise noch einmal manuell in einer CSV-Datei korrigiert, während das zugrunde liegende Skript unverändert bleibt. Der nächste Lauf erzeugt denselben Fehler erneut.
In unserem technischen Ansatz bilden wir Transformationen bevorzugt in nachvollziehbaren, versionierten SQL-Skripten ab, sofern Quellsystem und Projekt dafür geeignet sind. Dort ist sichtbar, welche Tabellen und Felder verwendet, welche Datensätze gefiltert, welche Werte umgeschlüsselt, welche Beziehungen hergestellt und welche Zielspalten erzeugt werden. Die Beladung erfolgt anschließend über das vorgesehene Importwerkzeug des ERP-Systems.
SQL ist dabei kein Selbstzweck und nicht für jedes System die passende Lösung. Der entscheidende Qualitätsmaßstab lautet vielmehr: Die Transformationslogik muss eindeutig ausführbar, wiederholbar, testbar und mit der freigegebenen Mapping-Entscheidung verbunden sein. Verbirgt sich dieselbe Regel gleichzeitig in einem Skript, einer Excel-Datei und einer Importoberfläche, steigt das Risiko auseinanderlaufender Versionen.
Der erste Datenlauf prüft das Mapping – und verändert es
Vor dem ersten Lauf kann ein Mapping belastbar vorbereitet werden. Final bewährt hat es sich erst mit realen Daten im Zielsystem. Dann werden bislang unbekannte Werte, fehlende Beziehungen, abweichende Feldlängen und unterschiedliche fachliche Bedeutungen sichtbar. Gleichzeitig erkennen Keyuser an ihren eigenen Daten häufig schneller, ob die vorgesehene Abbildung im neuen Prozess funktioniert.
Diese Rückmeldung sollte nicht als ungeordnete Kommentarliste neben dem Mapping liegen bleiben. Ein belastbarer Zyklus verbindet:
Mapping-Vorschlag → ausführbare Transformation → Testladung → technische Prüfung → fachliche Rückmeldung → dokumentierte Entscheidung → neue Regelversion.
Damit wird auch die Fehlerkorrektur präziser. Statt nur einen einzelnen Datensatz in der Exportdatei zu reparieren, klärt das Projekt, welche Regel den Befund erzeugt hat, welche weiteren Daten davon betroffen sind und wie die Änderung im nächsten Lauf erneut geprüft wird. Die ERP-Migration-Checkliste für den ersten Testlauf beschreibt, welche Voraussetzungen dafür vor dem Laden erfüllt sein sollten.
Woran Projektleitungen ein belastbares Mapping erkennen
Vor dem nächsten größeren Datenlauf sollte die Projektleitung nicht nur nach dem Bearbeitungsgrad der Mapping-Tabelle fragen. Aussagekräftiger sind sechs konkrete Prüfungen:
- Für jedes benötigte Zielattribut ist eine Quelle, eine bewusst beschlossene Ergänzung oder eine dokumentierte Leerstelle vorhanden.
- Wertelisten, Standardwerte und Ausnahmen sind fachlich entschieden; unbekannte Werte erzeugen einen sichtbaren Befund.
- Abhängigkeiten und Beziehungen zwischen Datenobjekten sind in der Regel und in der Ladereihenfolge berücksichtigt.
- Die beschlossene Transformation ist in einer eindeutig bezeichneten technischen Version umgesetzt.
- Für kritische Regeln ist vorab festgelegt, mit welcher Abfrage, Stichprobe oder Prozessprüfung ihre Anwendung belegt wird.
- Offene Fragen haben einen Verantwortlichen und einen Termin, statt stillschweigend durch technische Annahmen ersetzt zu werden.
Diese Punkte machen ein Mapping nicht für alle Zeiten unveränderlich. Sie machen seinen aktuellen Stand entscheidungsfähig. Das Projekt kann erkennen, welche Regeln für den nächsten Lauf tragfähig sind und wo bewusst noch gelernt werden soll.
Externe Unterstützung sollte die Übersetzungsarbeit übernehmen, nicht die Fachentscheidung
Externe Unterstützung wird besonders dann sinnvoll, wenn das Mapping zwischen Quellsystemkenntnis, Zielsystemlogik, Fachbereich und technischer Umsetzung hängen bleibt. Ein Datenmigrationsdienstleister kann Quellstrukturen analysieren, Mapping-Vorschläge vorbereiten, Transformationsregeln umsetzen, Prüfungen aufbauen und Rückmeldungen in die nächste Version überführen.
Die fachliche Entscheidung und Freigabe bleiben dennoch beim Kunden. Gerade diese Aufteilung entlastet: Keyuser verwenden ihre knappe Zeit für Bedeutung, Sonderfälle und Prozesswirkung, während die operative Übersetzung und Dokumentation vorbereitet wird. In einem Angebot für die ERP-Datenmigration sollte deshalb erkennbar sein, ob nur eine Mapping-Tabelle geliefert wird oder auch die Iterationen bis zu einer technisch geprüften und fachlich entschiedenen Regelversion enthalten sind.
Ein belastbares Datenmapping ist damit weder eine einmalige Feldliste noch eine vollständig technische Aufgabe. Es ist die gemeinsame, ausführbare Übersetzung zwischen alter Datenrealität und neuer Systemlogik. Wenn Bedeutung, Regel, Umsetzung, Prüfung und Verantwortung zusammengeführt sind, wird aus einer grünen Tabelle eine verlässliche Grundlage für den nächsten Datenlauf.