Im alten ERP bedeutet der Kundenstatus „B“: vorübergehend für neue Aufträge gesperrt. Im neuen System kennt das Zielfeld jedoch nur „aktiv“, „inaktiv“ und „vollständig gesperrt“. Wird das B ungeprüft ersetzt, kann ein technisch erfolgreicher Import die falsche Geschäftsentscheidung auslösen.
Codes bei einer ERP-Datenmigration umzuschlüsseln bedeutet, jeden relevanten Quellwert auf den fachlich richtigen und technisch zulässigen Zielwert abzubilden. Diese Zuordnung heißt Wertemapping. Sie betrifft beispielsweise Statuswerte, Einheiten, Zahlungsbedingungen, Länder, Kundengruppen, Lagerarten oder Klassifikationen.
Das sichtbare Problem lautet oft: „Der Import lehnt unsere Werte ab.“ Gefährlicher ist jedoch der umgekehrte Fall. Das Ziel nimmt einen Code an, aber seine Bedeutung stimmt nicht mit dem alten ERP überein. Deshalb darf ein Wertemapping nicht nur Zeichenfolgen ersetzen. Es muss die fachliche Wirkung der Werte übersetzen.
Warum gleich aussehende Codes trotzdem etwas anderes bedeuten können
Ein Code ist zunächst nur eine kurze technische Darstellung. Seine Bedeutung entsteht durch die dahinterliegende Prozesslogik. „01“ kann im Altsystem für einen aktiven Kunden, im Ziel aber für eine bestimmte Kundengruppe stehen. „ST“ kann Stück bedeuten, während das neue ERP „PC“ erwartet. Und ein alter Status „9“ kann mehrere fachliche Fälle zusammenfassen, die im Ziel getrennt werden.
Darum sind drei Fragen wichtiger als die optische Ähnlichkeit:
- Was bedeutete der Quellwert im bisherigen Geschäftsprozess?
- Welche Wirkung hat der vorgesehene Zielwert im neuen Prozess?
- Gilt diese Zuordnung immer oder nur unter bestimmten Bedingungen?
Erst wenn alle drei Antworten zusammenpassen, ist die Umschlüsselung belastbar.
Feldmapping und Wertemapping lösen unterschiedliche Aufgaben
Ein Feldmapping verbindet beispielsweise das alte Feld Kundengruppe mit dem neuen Feld Klassifikation. Damit ist geklärt, woher die Information kommt und wo sie ankommen soll. Noch offen bleibt, wie die einzelnen Werte übersetzt werden.
Das Wertemapping beantwortet diese zweite Frage:
- Quellcode „A1“ wird Zielcode „100“.
- Die alten Codes „A2“ und „A3“ werden beide Zielcode „200“.
- Quellcode „X“ darf nicht automatisch übernommen werden, sondern benötigt eine fachliche Entscheidung.
Der übergeordnete Beitrag zum Datenmapping und zu ausführbaren Transformationsregeln beschreibt das gesamte Regelwerk. Hier geht es bewusst nur um die Übersetzung der tatsächlich vorkommenden Werte.
Fünf Fälle, die eine Mappingtabelle unterscheiden muss
1. Direkte Eins-zu-eins-Zuordnung
Ein Quellwert entspricht genau einem Zielwert. Das ist der einfachste Fall, muss aber trotzdem dokumentiert werden. Nur so lässt sich später erklären, ob der Wert bewusst übernommen oder lediglich übersehen wurde.
2. Mehrere alte Codes werden zu einem neuen Code
Historisch gewachsene Systeme enthalten oft mehrere Ausprägungen mit inzwischen gleicher Bedeutung. Wenn „DEU“, „D“ und „DE“ im konkreten Feld alle Deutschland bedeuten, können sie auf einen gemeinsamen zulässigen Zielcode führen. Vorher muss jedoch ausgeschlossen werden, dass eine Ausprägung eine zusätzliche fachliche Aussage trägt.
3. Ein alter Code reicht für die Zielentscheidung nicht aus
Manchmal muss derselbe Quellcode abhängig von Werk, Gesellschaft, Belegart oder einem zweiten Feld unterschiedlich behandelt werden. Dann genügt keine zweispaltige Suchen-und-Ersetzen-Liste. Die Regel benötigt einen sichtbaren Kontext, etwa:
Wenn Status = „B“ und Gesellschaft = „100“, dann Zielsperre „01“; bei Gesellschaft = „200“ bleibt der Datensatz zur Klärung offen.
4. Der Zielwert wird abgeleitet oder bewusst vorgegeben
Für ein benötigtes Zielfeld kann im Altsystem kein direktes Gegenstück existieren. Ein Wert lässt sich dann aus mehreren Angaben ableiten oder als fachlich freigegebener Vorgabewert setzen. Ein Vorgabewert ist dabei kein Lückenfüller, sondern eine dokumentierte Entscheidung mit bekanntem Geltungsbereich.
5. Der Wert bleibt unbekannt und muss einen Fehler erzeugen
Nicht jeder Quellcode sollte automatisch einen Zielwert erhalten. Wenn Bedeutung, Gültigkeit oder Zielwirkung unklar sind, ist eine sichtbare Fehlerausgabe die sicherere Regel. Der Datensatz bleibt damit prüfbar, statt unbemerkt unter einem scheinbar passenden Standardwert zu verschwinden.
Die tatsächlich verwendeten Quellwerte zuerst ermitteln
Alte Dokumentationen und Bildschirmmasken zeigen häufig nur die vorgesehenen Wertelisten. Für die Migration zählt zusätzlich, welche Ausprägungen in den ausgewählten Daten wirklich vorkommen. Deshalb beginnt ein belastbares Wertemapping mit einer Auswertung der Quellwerte und ihrer Häufigkeit.
Eine solche Werteliste sollte je Datenobjekt und Feld mindestens zeigen:
- den unveränderten Quellcode,
- eine vorhandene Bezeichnung,
- die Anzahl betroffener Datensätze,
- relevante Organisationseinheiten oder Zeiträume,
- sowie Beispiele für auffällige oder widersprüchliche Verwendungen.
Die Häufigkeit ersetzt keine fachliche Entscheidung. Sie setzt aber Prioritäten. Ein unbekannter Code in 40.000 Materialdatensätzen blockiert einen Testlauf anders als ein einmaliger historischer Wert, der bewusst nicht in den Migrationsumfang gehört.
Auch die zulässigen Zielwerte brauchen einen bestätigten Stand
Ein vollständiger Quellkatalog genügt nicht, wenn das Customizing des neuen ERP noch verändert wird. Zahlungsbedingungen, Einheiten, Kontengruppen oder Klassifikationen können während der Einführung umbenannt, ergänzt oder gelöscht werden. Eine gestern beschlossene Zuordnung kann dadurch heute technisch ungültig sein.
Das Projekt braucht deshalb für jede relevante Werteliste einen benannten Zielstand. Dazu gehören die zulässigen Codes, ihre Bedeutung, ihr Geltungsbereich und bekannte Abhängigkeiten. Wenn der Zielanbieter diese Informationen noch nicht bereitstellen kann, wird die Mappingfrage als offene Voraussetzung geführt – nicht als vermeintlich erledigte Zuordnung.
Herstellerseitige Migrationsobjekte enthalten ebenfalls Feldzuordnungen und Regeln zur Konvertierung von Werten. Das ändert jedoch nichts an der fachlichen Verantwortung des Unternehmens: Nur der Fachbereich kann bestätigen, welcher neue Wert die bisherige Geschäftsbedeutung richtig fortführt.
Eine belastbare Wertemapping-Tabelle braucht mehr als zwei Spalten
Für einfache Fälle reichen Quell- und Zielcode optisch aus. Für eine wiederholbare Datenmigration sollten die zugrunde liegenden Entscheidungen jedoch sichtbar bleiben:
| Information | Warum sie gebraucht wird |
|---|---|
| Datenobjekt und Feld | Ein identischer Code kann in zwei Feldern etwas anderes bedeuten. |
| Quellcode und Quellbedeutung | Die alte Prozesswirkung bleibt nachvollziehbar. |
| Kontext oder Bedingung | Abhängigkeiten von Gesellschaft, Werk oder weiteren Feldern werden ausführbar. |
| Zielcode und Zielbedeutung | Nicht nur das Kürzel, sondern auch seine neue Wirkung ist bestätigt. |
| Regelart | Direkte Zuordnung, Zusammenführung, Ableitung, Vorgabewert oder Fehlerfall werden unterschieden. |
| Status und Entscheidung | Vorschlag, fachliche Freigabe und technische Umsetzung laufen nicht auseinander. |
| Prüfnachweis | Der Test kann belegen, dass die Regel korrekt angewendet wurde. |
Damit wird die Tabelle zu einer Entscheidungs- und Prüfbasis. Sie ist nicht nur eine Liste für den einmaligen Import.
Unbekannte Codes dürfen nicht still durchrutschen
Zwischen zwei Extraktionen können neue Quellwerte hinzukommen. Vielleicht legt ein Fachbereich eine weitere Lieferantengruppe an oder nutzt einen alten Status erstmals wieder. Wenn die Transformation unbekannte Werte automatisch leer lässt oder mit einem Standard ersetzt, verändert sie Daten ohne sichtbaren Befund.
Eine robuste Regel behandelt deshalb nur bekannte und freigegebene Werte. Alles andere landet in einer Ausnahmeliste mit Datensatz, Feld, Quellwert und Häufigkeit. So wird aus einem Importfehler eine konkrete Entscheidungsliste für den nächsten Lauf.
Auch die Prüfung der ERP-Importvorlage sollte kontrollieren, ob jede Zielspalte ausschließlich zulässige Werte enthält und ob Ausnahmen vor dem Upload sichtbar wurden.
Die freigegebene Zuordnung muss in der Transformation ankommen
Ein häufiges Folgeproblem entsteht, wenn die Mappingtabelle richtig ist, die Exportdatei aber weiterhin manuell korrigiert wird. Beim nächsten Testlauf tauchen dieselben alten Codes erneut auf. Gleichzeitig ist nicht mehr klar, welche Datei welche Entscheidung enthält.
Deshalb sollte die freigegebene Umschlüsselung in einem wiederholbaren Transformationslauf umgesetzt werden – beispielsweise in einem nachvollziehbaren SQL-Skript, einer kontrollierten Mappingkomponente oder einer anderen versionierten Aufbereitung. Entscheidend ist nicht das Werkzeug. Entscheidend ist, dass derselbe Quellstand mit derselben Regel wieder dasselbe Ergebnis erzeugt.
Die Regelversion, die Mappingentscheidung und die erzeugte Importdatei müssen zusammengehören. Wird ein Zielcode geändert, entsteht eine neue prüfbare Version statt einer stillen Korrektur in Excel.
So wird das Wertemapping im Test nachgewiesen
Ein grüner Importstatus zeigt lediglich, dass das Ziel die Datei technisch verarbeitet hat. Für die fachliche Prüfung braucht das Projekt mehrere Sichten:
- Vollständigkeit: Jeder relevante Quellwert wurde einer Regel oder einem bewussten Ausschluss zugeordnet.
- Regelanwendung: Die Anzahl der Datensätze je Quell- und Zielwert passt zur erwarteten Übersetzung.
- Ausnahmen: Unbekannte Werte und ungültige Kombinationen sind vollständig sichtbar.
- Prozesswirkung: Ausgewählte Datensätze verhalten sich im neuen ERP fachlich richtig.
- Wiederholbarkeit: Der nächste Lauf wendet dieselbe freigegebene Regel ohne manuelle Nacharbeit erneut an.
Bei einer Zusammenführung mehrerer alter Codes ist besonders wichtig, nicht nur die Zielsumme zu prüfen. Die Auswertung muss zeigen, aus welchen Quellgruppen sie entstanden ist. Sonst können sich eine fehlende und eine fälschlich hinzugefügte Gruppe gegenseitig verdecken.
Die Datenvalidierung und Abnahme verbindet solche Regelprüfungen mit fachlichen Testfällen und einer nachvollziehbaren Freigabe.
Typische Fehlversuche beim Umschlüsseln von ERP-Werten
- Codes nur nach ihrer Schreibweise zuzuordnen: Gleiche Zeichen werden mit gleicher Bedeutung verwechselt.
- Nur dokumentierte statt tatsächlich verwendeter Werte zu betrachten: historische und lokal angelegte Ausprägungen fehlen.
- Für jede Lücke einen Standardwert einzusetzen: ungeklärte Fachentscheidungen werden unsichtbar.
- Kontextabhängige Regeln in eine Zweispaltenliste zu pressen: Gesellschafts-, Werk- oder Objektunterschiede gehen verloren.
- Mappingtabellen und Skripte getrennt zu ändern: Dokumentation und geladene Datei widersprechen sich.
- Nur den erfolgreichen Import zu prüfen: fachlich falsche, aber technisch zulässige Werte bleiben bestehen.
Wer entscheidet – und wer bereitet vor?
Fachbereiche entscheiden über Bedeutung, Prozesswirkung und zulässige Vereinfachungen. Das Zielsystemteam bestätigt verfügbare Codes und technische Abhängigkeiten. Die Datenmigration sollte reale Quellwerte ermitteln, Zuordnungsvorschläge vorbereiten, offene Fälle bündeln, die beschlossenen Regeln ausführbar umsetzen und den Nachweis für jeden Lauf erzeugen.
Diese Arbeitsteilung entlastet die Keyuser. Sie müssen nicht selbst Datenbankwerte suchen oder technische Transformationslogik schreiben. Sie erhalten eine konkrete Liste mit Häufigkeiten, Bedeutungen und Entscheidungsvorschlägen und konzentrieren sich auf die Fälle, für die ihr Prozesswissen gebraucht wird.
Gutes Wertemapping macht Unterschiede sichtbar
Das Ziel ist nicht, möglichst schnell für jeden alten Code irgendeinen neuen Wert zu finden. Das Ziel ist eine Übersetzung, bei der Bedeutung, Geltungsbereich und Prozesswirkung nachvollziehbar bleiben.
Wenn Ihre ERP-Migration an unbekannten Codes, wechselnden Wertelisten oder immer neuen manuellen Korrekturen festhängt, können wir Quell- und Zielwerte strukturiert gegenüberstellen, Mappingvorschläge vorbereiten und die freigegebenen Regeln in einen wiederholbaren Datenlauf überführen. Die fachliche Entscheidung bleibt bei Ihrem Unternehmen; die technische und analytische Vorarbeit übernehmen wir.
So wird aus einer schwer überschaubaren Codeliste eine kontrollierte Transformationsregel – und aus einem technisch akzeptierten Import ein fachlich belastbarer Datenbestand.