Der Kundenstamm liegt im alten ERP, aktuelle Ansprechpartner stehen im CRM und einzelne Sperrlisten werden in Excel gepflegt. Für das neue ERP wird daraus trotzdem genau ein Kundenbestand benötigt. Wer jetzt jede Quelle für sich in eine Importvorlage kopiert, erzeugt meist doppelte Datensätze, widersprüchliche Werte und Zuordnungen, deren Herkunft später niemand mehr erklären kann.
Bei einer Datenmigration aus mehreren Systemen wird deshalb nicht zuerst nach Dateien, sondern nach dem benötigten Zielobjekt gearbeitet. Für jedes Zielfeld wird festgelegt, aus welcher Quelle es kommt, über welchen stabilen Schlüssel die Informationen zusammengehören und welche Regel bei widersprüchlichen Werten gilt. Erst danach werden ERP-Daten, Fachanwendungen und Excel-Listen technisch zu einem wiederholbar erzeugten Bestand verbunden.
Das ist eine andere Aufgabe als eine dauerhafte Systemintegration. Die Migration soll die für den Start benötigten Daten zu einem bestätigten Zeitpunkt in das neue ERP überführen. Sie soll nicht mehrere Anwendungen auf Dauer miteinander synchronisieren.
Datenmigration aus mehreren Systemen: Die kurze Antwort
Ein belastbarer Zusammenführungsprozess benötigt sechs Entscheidungen:
- Welche Informationen verlangt das Zielobjekt im neuen ERP?
- Welche Quelle enthält welchen Teil dieser Informationen?
- Welcher Schlüssel verbindet Datensätze über die Systemgrenzen hinweg?
- Welche Quelle ist für ein konkretes Zielfeld maßgeblich?
- Wie werden Widersprüche, Lücken und Mehrfachtreffer behandelt?
- Wie bleibt für jeden Zielwert nachvollziehbar, woher er stammt und nach welcher Regel er entstanden ist?
Die technische Zusammenführung beginnt erst, wenn diese Fragen zumindest für einen begrenzten Datenbereich beantwortet sind. So entsteht nicht irgendeine große Datei, sondern ein prüfbarer Bestand, der zur Zielstruktur passt.
Warum eine Datei pro Altsystem noch keinen Migrationsbestand ergibt
Mehrere Exporte können dieselben fachlichen Objekte unterschiedlich beschreiben. Das alte ERP kennt den Kunden vielleicht unter der Kundennummer 4711. Im CRM existiert derselbe Kunde unter einer eigenen internen ID. Eine Excel-Liste enthält nur Name und Ort. Schon bei kleinen Abweichungen in Schreibweise oder Adresse ist nicht mehr sicher, welche Zeilen zusammengehören.
Hinzu kommt, dass keine Quelle automatisch in jeder Hinsicht die beste sein muss. Das ERP kann für Kontierungsmerkmale maßgeblich sein, während das CRM die aktuelleren Ansprechpartner enthält. Eine freigegebene Excel-Liste kann wiederum dokumentieren, welche Datensätze bewusst nicht übernommen werden sollen. Die Frage lautet daher nicht: „Welches System gewinnt?“ Sie lautet: „Welche Quelle liefert für welches Zielfeld und welchen Gültigkeitsbereich die bestätigte Information?“
Genau hier liegt die fachliche Arbeit. Das bloße Aneinanderhängen von Dateien löst weder Identität noch Widerspruch oder Zielbedeutung.
Schritt 1: Vom benötigten Zielobjekt rückwärts planen
Am Anfang steht ein konkretes Zielobjekt, zum Beispiel ein Kunde, ein Material oder ein Lieferant im neuen ERP. Dafür werden die benötigten Zielfelder, Pflichtbeziehungen und zulässigen Werte erfasst. Erst anschließend wird geprüft, welche Quelle die jeweilige Information liefern kann.
Dieses Vorgehen verhindert, dass vorsorglich große Datenmengen zusammengeführt werden, die im neuen System gar nicht gebraucht werden. Zugleich werden Lücken früh sichtbar. Wenn das Ziel beispielsweise eine eindeutige Vertriebsorganisation verlangt, aber keine Quelle diese Zuordnung zuverlässig enthält, ist das eine offene fachliche Entscheidung und kein Problem, das eine spätere Excel-Formel von selbst lösen kann.
Die grundlegende Zuordnung zwischen alter Information, Zielbedeutung und technischer Regel gehört in ein Datenmapping für das ERP-Projekt. Bei mehreren Quellen kommt zu jedem Zielfeld noch die bestätigte Quellenrolle hinzu.
Schritt 2: Ein Quellenregister statt einer unübersichtlichen Dateisammlung
Ein Quellenregister ist eine kurze Übersicht darüber, welche Datenbestände für die Migration verwendet werden. Es muss kein umfangreiches Handbuch sein. Für jede Quelle sollten jedoch mindestens folgende Angaben feststehen:
- System, Datei oder verantwortlicher Fachbereich,
- enthaltene Objekte und ungefährer Abdeckungsgrad,
- verfügbarer fachlicher und technischer Schlüssel,
- Datenstand beziehungsweise Exportzeitpunkt,
- bekannte Lücken, Dubletten oder Sonderverwendungen sowie
- Rolle der Quelle im späteren Zielbestand.
Damit lässt sich früh erkennen, ob zwei Dateien tatsächlich voneinander unabhängige Quellen sind oder ob eine Excel-Liste nur ein älterer Auszug aus dem ERP ist. Dieser Unterschied ist wichtig: Ein zusätzlicher Auszug erhöht nicht die Datenqualität. Er kann vielmehr einen veralteten Stand in die Zusammenführung bringen.
Schritt 3: Ein Brückenschlüssel verbindet dieselbe Sache über Systemgrenzen
Der Brückenschlüssel ist die Information, mit der derselbe Kunde, dasselbe Material oder derselbe Lieferant in verschiedenen Quellen erkannt wird. Idealerweise existiert eine stabile gemeinsame Nummer. Fehlt sie, kann eine kontrollierte Zuordnungstabelle die unterschiedlichen IDs einmalig miteinander verbinden.
Bevor dieser Schlüssel verwendet wird, braucht er drei einfache Prüfungen:
- Abdeckung: Wie viele relevante Datensätze besitzen den Schlüssel?
- Eindeutigkeit: Kommt er innerhalb einer Quelle wirklich nur einmal pro fachlichem Objekt vor?
- Übereinstimmung: Wie viele Schlüssel finden in der jeweils anderen Quelle genau einen passenden Satz?
Mehrfachtreffer und nicht gefundene Schlüssel werden als eigene Arbeitsliste ausgegeben. Eine automatische Verbindung über Name, Straße oder Bezeichnung kann bei einer überschaubaren Restmenge Vorschläge erzeugen. Sie sollte jedoch nicht unbemerkt zur Identitätsregel für den gesamten Bestand werden.
Schritt 4: Die führende Quelle wird pro Zielfeld festgelegt
Eine führende Quelle ist die Quelle, deren Wert für ein bestimmtes Zielfeld als maßgeblich gilt. Diese Führung sollte nicht pauschal für das gesamte Objekt vergeben werden. Für einen Kunden können beispielsweise unterschiedliche Regeln gelten:
| Zielfeld oder Zielbereich | Mögliche führende Quelle | Erforderliche Entscheidung |
|---|---|---|
| Kundennummer und Buchungskreis | Altes ERP | Welche aktiven Organisationszuordnungen werden übernommen? |
| Ansprechpartner und Kommunikationsdaten | CRM | Welcher Datenstand gilt und wie werden ausgeschiedene Kontakte erkannt? |
| Migrationssperre | Fachlich freigegebene Ausnahmeliste | Wer darf Datensätze ausschließen und wie lange gilt die Entscheidung? |
| Zahlungsbedingung im neuen ERP | Bestätigte Transformationsregel | Wie werden alte Codes auf die neuen Zielwerte übersetzt? |
Eine ergänzende Quelle darf einen fehlenden Wert liefern, ohne automatisch bereits vorhandene Werte zu überschreiben. Eine Prüfquelle kann Abweichungen melden, ohne selbst in das Ziel zu schreiben. Diese Rollen machen aus einem pauschalen „CRM ist aktueller“ eine ausführbare und prüfbare Regel.
Widersprüche werden entschieden und nicht still überschrieben
Wenn zwei Quellen unterschiedliche Werte für dasselbe Zielfeld liefern, sollte die Transformation keinen zufälligen Sieger bestimmen. Zuerst wird der Konflikt als konkrete Teilmenge sichtbar gemacht. Danach kann je nach Feld eine eindeutige Regel beschlossen werden, zum Beispiel:
- Der Wert aus dem führenden System gilt, sofern er nicht leer ist.
- Ein neuerer Zeitstempel gilt nur, wenn beide Systeme dieses Feld tatsächlich pflegen und die Zeitstempel vergleichbar sind.
- Eine fachlich bestätigte Ausnahmeliste übersteuert den regulären Quellwert.
- Unvereinbare Werte bleiben offen und werden vor dem nächsten Testlauf entschieden.
„Die neueste Datei gewinnt“ ist selten eine belastbare allgemeine Regel. Ein jüngerer Export kann einen älteren fachlichen Inhalt tragen. Ebenso sagt eine vollständigere Quelle noch nichts darüber aus, ob der einzelne Wert für den neuen Prozess richtig ist.
Dubletten entstehen oft erst durch die Zusammenführung
Jedes Altsystem kann für sich plausibel aussehen und trotzdem gemeinsam doppelte Zielobjekte erzeugen. Das passiert etwa, wenn ein Kunde im ERP und im CRM unterschiedliche Nummern besitzt oder wenn mehrere Standorte im einen System als eigene Kunden, im anderen aber als Adressen eines Kunden geführt werden.
Deshalb wird vor dem Zusammenführen festgelegt, was im Ziel als ein Objekt gilt. Die technische Ähnlichkeit von Namen oder Anschriften liefert anschließend nur Kandidaten. Ob zwei Sätze wirklich zusammengehören, hängt auch von Organisation, Rolle, Gültigkeit und den abhängigen Daten ab.
Unser Beitrag zum Zusammenführen von Dubletten bei der ERP-Migration beschreibt, wie Identitäten konsolidiert werden, ohne Beziehungen zu Ansprechpartnern, Belegen oder Standorten zu verlieren.
Die technische Verarbeitung muss jederzeit wiederholbar sein
Nach den fachlichen Entscheidungen werden die Quellen in einem getrennten Arbeitsbestand verarbeitet. Dort bleiben die ursprünglichen Exporte unverändert. Skripte oder klar versionierte Verarbeitungsschritte übernehmen vier Aufgaben:
- Quellen auf einheitliche Datentypen und Schlüssel vorbereiten,
- zusammengehörige Sätze über den bestätigten Brückenschlüssel verbinden,
- Quellen- und Konfliktregeln anwenden und
- die Zielstruktur in der erwarteten Reihenfolge erzeugen.
Zu jedem erzeugten Zielwert sollte zumindest technisch nachvollziehbar bleiben, aus welcher Quelle, welchem Quellschlüssel und welchem Datenstand er stammt. Diese Herkunftsinformation muss nicht vollständig in die ERP-Importdatei geschrieben werden. Sie gehört jedoch zum prüfbaren Arbeitsstand der Migration.
Manuelle Korrekturen ausschließlich in der letzten CSV-Datei unterbrechen diese Kette. Beim nächsten Export fehlen sie oder werden anders wiederholt. Eine wiederholbare Transformation macht dagegen aus einer bestätigten Änderung automatisch einen Bestandteil des nächsten Testlaufs.
Fünf Kontrollen zeigen, ob aus mehreren Quellen ein belastbarer Bestand wurde
Eine erfolgreiche Importmeldung beantwortet nicht, ob die Zusammenführung vollständig und fachlich richtig war. Vor und nach dem Import sollten deshalb mindestens fünf Kontrollen möglich sein:
- Abdeckung je Quelle: Wie viele relevante Sätze wurden erwartet, verbunden, ausgeschlossen oder blieben ungeklärt?
- Schlüsselprüfung: Welche Schlüssel fehlen, sind mehrfach vorhanden oder treffen auf mehrere Sätze?
- Konfliktbilanz: Wie viele widersprüchliche Werte wurden automatisch geregelt, fachlich entschieden oder bewusst offengelassen?
- Zielvollständigkeit: Sind alle Pflichtfelder und abhängigen Beziehungen des Zielobjekts vorhanden?
- Fachliche Stichprobe: Stimmen ausgewählte Normalfälle, Grenzfälle und bekannte Ausnahmen im neuen Prozess?
Diese Nachweise werden mit dem jeweiligen Daten- und Regelstand verbunden. Der ausführliche Beitrag zur Datenvalidierung bei der ERP-Migration zeigt, wie daraus eine belastbare Freigabe entsteht.
Vier naheliegende Lösungswege, die nur begrenzt tragen
Alle Quellen früh in eine große Excel-Datei kopieren: Das kann einen ersten Überblick geben. Ohne stabile Schlüssel, Herkunftsspalten und reproduzierbare Regeln wird daraus jedoch schnell ein manueller Sonderstand, der sich beim nächsten Test nicht verlässlich erneuern lässt.
Ein System für das gesamte Objekt zur Wahrheit erklären: Das ist richtig, wenn dieses System fachlich tatsächlich alle benötigten Informationen führt. In einer gewachsenen Landschaft liegt die Verantwortung aber häufig feldweise verteilt.
Datensätze nur über Namen und Adressen verbinden: Ähnlichkeitsregeln können Kandidaten finden. Als automatische Hauptregel riskieren sie falsche Zusammenführungen und übersehene Dubletten.
Jeden Fachbereich eine fertige Importdatei liefern lassen: Das verteilt Arbeit, erzeugt aber oft unterschiedliche Datenstände, Formate und Regelversionen. Fachbereiche sollten Entscheidungen und Prüfungen liefern; der gemeinsame Migrationsbestand braucht eine kontrollierte technische Erzeugung.
Wer muss welche Entscheidung treffen?
Die Fachbereiche bestätigen, welche Quelle für ihre Informationen maßgeblich ist, welche Konfliktregeln fachlich zulässig sind und welche Ausnahmen übernommen werden dürfen. Die ERP-Projektleitung bestimmt Umfang, Datenstand und Freigabe. Der Zielsystempartner erklärt Zielstruktur, Pflichtfelder und Importverhalten.
Wir können die Quellen technisch untersuchen, Schlüsselabdeckung und Konflikte sichtbar machen, bestätigte Regeln in eine wiederholbare Zusammenführung übersetzen und die Nachweise für Testmigrationen vorbereiten. Welche Quelle im Unternehmen die fachliche Wahrheit für ein Feld trägt, entscheiden wir nicht still im Skript, sondern gemeinsam mit den dafür Verantwortlichen.
Ein gemeinsamer Zielbestand entsteht durch klare Quellenrollen
Bei einer Datenmigration aus mehreren Systemen ist die Menge der Dateien nicht das eigentliche Problem. Kritisch wird es, wenn Identitäten, Zuständigkeiten und widersprüchliche Werte ungeklärt bleiben. Dann sieht die fertige Importdatei zwar geschlossen aus, enthält aber Entscheidungen, die niemand bewusst getroffen hat.
Ein zielorientiertes Mapping, ein geprüfter Brückenschlüssel, feldweise Quellenrollen und sichtbare Konfliktregeln ändern das. ERP, CRM, Fachanwendung und Excel-Liste werden nicht pauschal vermischt. Sie liefern nachvollziehbare Bestandteile eines Zielobjekts, das sich für jeden Testlauf erneut erzeugen, prüfen und fachlich freigeben lässt.