Der Import ist grün, die Datensätze sind vorhanden – und trotzdem stimmen die Daten im neuen ERP nicht. Ein Material trägt die falsche Einheit, ein Kunde ist der falschen Organisation zugeordnet oder eine Summe weicht vom Altsystem ab. In dieser Lage hilft es wenig, nur den sichtbaren Zielwert zu korrigieren.
Wenn Daten nach der ERP-Migration fachlich nicht stimmen, muss derselbe Wert von seiner bestätigten Bedeutung über Quelle, Mapping und Transformation bis ins Ziel verfolgt werden. Erst dieser Vergleich zeigt, ob bereits die Quelldaten falsch waren, eine fachliche Zuordnung nicht passte, die beschlossene Regel technisch anders umgesetzt wurde oder das Zielsystem den geladenen Wert in einem anderen Kontext interpretiert.
Ein technisch akzeptierter Wert kann fachlich falsch sein. Umgekehrt kann eine Abweichung zum Altsystem im neuen Prozess beabsichtigt und richtig sein. Deshalb beginnt die Diagnose nicht mit dem Überschreiben des Zielwerts, sondern mit der Frage, welcher Wert für welchen Prozess tatsächlich erwartet wurde.
Daten stimmen nach der ERP-Migration nicht: Die kurze Antwort
Für einen auffälligen Datensatz wird eine Wertspur aufgebaut. Sie verbindet sechs Belege:
- die fachlich erwartete Aussage im neuen Prozess,
- den ursprünglichen Quellwert und seinen bisherigen Kontext,
- die bestätigte Mapping- oder Transformationsregel,
- den durch das Skript erzeugten Wert,
- den tatsächlich geladenen Zielwert und
- die Wirkung dieses Werts im Zielprozess.
Der erste Punkt, an dem Erwartung und belegtes Ergebnis auseinanderlaufen, bestimmt die Korrektur. Liegt der falsche Wert bereits in der Quelle, ist eine Bereinigungs- oder Ausnahmeentscheidung nötig. Ist die fachliche Regel richtig, aber die Importdatei falsch, muss die technische Transformation geändert werden. Stimmt auch die Datei, liegt die Ursache im Import, in der Zielkonfiguration oder in der späteren Verarbeitung.
Zuerst festlegen, was „richtig“ in diesem Fall bedeutet
Ein Vergleich zwischen altem und neuem Feld reicht nicht immer. Das Zielsystem kann andere Kategorien, Einheiten, Organisationen oder Berechnungsregeln verwenden. Ein anderer Zielwert ist deshalb nicht automatisch ein Migrationsfehler.
Vor der Ursachenanalyse muss der Fachbereich für den konkreten Befund beantworten:
- Welche fachliche Aussage soll der Zielwert tragen?
- Für welchen Prozess, Standort oder Gültigkeitszeitraum gilt sie?
- Soll der alte Wert unverändert übernommen, umgeschlüsselt oder neu abgeleitet werden?
- Welche Quelle oder Entscheidung belegt den erwarteten Wert?
- Ist die Abweichung für alle Datensätze oder nur für eine bestimmte Teilmenge falsch?
Ohne diese Erwartung lässt sich lediglich feststellen, dass zwei Werte verschieden sind. Ob Quelle, Transformation oder Ziel richtig ist, bleibt offen.
Vier Werte lokalisieren den fachlichen Bruch
Für die erste Diagnose genügt häufig ein Vier-Werte-Vergleich. Gemeint ist die direkte Gegenüberstellung von Quellwert, fachlich erwartetem Zielwert, technisch erzeugtem Importwert und tatsächlich gespeichertem Zielwert.
| Vergleich | Was er zeigt | Wahrscheinlicher Korrekturort |
|---|---|---|
| Quellwert ist bereits fachlich falsch | Die Migration hat eine bestehende Unstimmigkeit sichtbar gemacht. | Quelle bereinigen oder eine bestätigte Migrationsregel für die betroffene Teilmenge festlegen. |
| Erwarteter Zielwert passt nicht zur Mapping-Regel | Die fachliche Übersetzung wurde falsch, unvollständig oder mehrdeutig beschlossen. | Mappingentscheidung mit Fachbereich und Zielsystemteam korrigieren. |
| Mapping-Regel ist richtig, Importwert aber falsch | Die technische Umsetzung entspricht nicht der freigegebenen Regel. | Transformationsskript, Wertetabelle oder verwendete Version korrigieren. |
| Importwert ist richtig, Zielwert oder Prozesswirkung aber falsch | Importlogik, Zielkonfiguration, Bezugsschlüssel oder Folgeverarbeitung verändern die Bedeutung. | Zielsystem und Importverhalten gemeinsam mit dem ERP-Partner prüfen. |
Der Vergleich ist nur aussagekräftig, wenn alle vier Werte zum selben fachlichen Schlüssel, Datenstand und Regelstand gehören. Sonst werden möglicherweise ein alter Export, eine neuere Mapping-Tabelle und ein Zielbestand aus einem anderen Lauf miteinander verglichen.
Ursache 1: Die Migration übernimmt einen falschen Quellwert korrekt
Eine Migration kann technisch genau das tun, was vereinbart wurde, und trotzdem ein unbrauchbares Ergebnis erzeugen. Wenn ein Status, eine Einheit oder eine Zuordnung im Altsystem falsch gepflegt war und unverändert übernommen werden sollte, erscheint derselbe Fehler im Ziel.
Dann liegt die Lösung nicht darin, pauschal alle Zielwerte nachzubessern. Zuerst wird die betroffene Teilmenge bestimmt. Anschließend entscheidet der Fachbereich, ob die Quelle noch korrigiert werden kann, ob eine eindeutige Bereinigungsregel existiert oder ob einzelne Fälle manuell geklärt werden müssen.
Unser Beitrag zur Datenbereinigung vor der ERP-Migration zeigt, wie wiederkehrende Fehler regelbasiert behandelt und echte Ausnahmen begrenzt werden.
Ursache 2: Die Mapping-Regel übersetzt die fachliche Bedeutung falsch
Ein Mapping verbindet nicht nur zwei Spaltennamen. Es legt fest, wie die alte Bedeutung in die neue Zielstruktur überführt wird. Fehler entstehen, wenn ähnlich benannte Felder gleichgesetzt werden, obwohl sie unterschiedliche Sachverhalte beschreiben, oder wenn ein alter Code je nach Kontext mehrere Zielwerte benötigt.
Eine Regel wie „A wird zu 1“ reicht beispielsweise nicht, wenn derselbe Quellcode in verschiedenen Gesellschaften unterschiedlich verwendet wurde. Dann braucht die Zuordnung zusätzliche Bedingungen. Ebenso darf ein leerer Quellwert nicht automatisch zu einem fachlichen Standard werden, nur weil das Zielfeld technisch verpflichtend ist.
Eine belastbare Mappingkorrektur hält deshalb fest:
- welche Quellwerte und Kontexte betroffen sind,
- welche Zielbedeutung erreicht werden soll,
- welche Bedingung die jeweilige Zuordnung auslöst,
- welche Ausnahmen sichtbar bleiben und
- wer die fachliche Entscheidung bestätigt hat.
Wie diese Regeln aufgebaut werden, vertieft der Beitrag Datenmapping im ERP-Projekt.
Ursache 3: Die technische Transformation weicht von der bestätigten Regel ab
Eine richtige Mappingentscheidung wirkt nur, wenn genau diese Fassung im verwendeten Skript oder Aufbereitungsprozess umgesetzt ist. In laufenden Projekten können jedoch mehrere Mapping-Dateien, Wertelisten und Skriptstände nebeneinander bestehen. Dann wird fachlich eine Regel geprüft, während der Datenlauf noch eine ältere oder manuell veränderte Fassung verwendet.
Für einen auffälligen Zielwert sollte sich deshalb beantworten lassen:
- Welche Regelversion war für den Lauf freigegeben?
- Welche technische Version hat die Importdatei tatsächlich erzeugt?
- Welche Quellwerte und Bedingungen hat sie für diesen Schlüssel verarbeitet?
- Welcher Zwischenwert entstand vor der Ausgabe?
- Wurde die fertige Datei danach noch von Hand verändert?
Die Korrektur gehört in die wiederholbare Transformation. Eine Änderung nur in der aktuellen CSV-Datei verbessert zwar den sichtbaren Test, geht beim nächsten Export aber verloren.
Ursache 4: Das Zielsystem interpretiert einen richtigen Importwert anders
Manchmal stimmen Quelle, Regel und Importdatei, doch der Wert wirkt im Ziel weiterhin falsch. Dann kann das Zielsystem zusätzliche Logik anwenden. Ein geladener Code verweist vielleicht auf eine anders konfigurierte Kategorie. Eine Einheit wird zwar akzeptiert, aber über eine abweichende Umrechnung verwendet. Ein Gültigkeitsdatum entscheidet, welcher Satz im Prozess greift.
Auch Anzeige und Speicherung müssen getrennt werden. Die Oberfläche kann einen beschreibenden Text zeigen, während technisch ein Schlüssel gespeichert ist. Berichte oder berechnete Felder können Werte aus mehreren Datensätzen ableiten. Deshalb sollte der ERP-Partner klären, welche Zielkonfiguration, Referenz und Folgelogik den beobachteten Wert erzeugt.
Eine Abweichung zwischen Importdatei und Bildschirm ist damit noch kein Beweis, dass der Import den Wert verändert hat. Der technische Zielbestand und die Prozesswirkung müssen gemeinsam geprüft werden.
Ursache 5: Der einzelne Wert stimmt, aber seine Beziehung ist falsch
Viele fachliche Fehler sitzen nicht im Feld selbst. Ein Ansprechpartner kann mit korrektem Namen und korrekter Telefonnummer vorhanden sein, aber dem falschen Kunden zugeordnet sein. Ein Betrag kann stimmen, jedoch an der falschen Belegposition hängen. Ein Material trägt eine zulässige Einheit, doch die Umrechnung bezieht sich auf die falsche Basiseinheit.
Solche Fehler bleiben in einer reinen Feldprüfung unsichtbar. Für kritische Beziehungen müssen deshalb Hauptschlüssel, Unterobjektschlüssel und Zielreferenzen gemeinsam verglichen werden. Außerdem ist zu prüfen, ob Zusammenführungen oder neue Nummernkreise die ursprüngliche Identität verändert haben.
Je abhängiger ein Geschäftsprozess von diesen Beziehungen ist, desto wichtiger wird ein fachlicher Prozesstest. Ein Datensatz kann auf dem Bildschirm plausibel aussehen und erst beim Auftrag, bei der Disposition oder bei einer Buchung die falsche Wirkung zeigen.
Summenabweichungen brauchen eine erklärbare Rechenbrücke
Bei Beständen, offenen Mengen, Salden oder Werten reicht die Prüfung einzelner Datensätze nicht aus. Gleichzeitig ist ein bloßer Gesamtvergleich zu grob. Eine Differenz kann aus Ausschlüssen, Zusammenführungen, Rundung, Einheitenumrechnung, Währungsumrechnung oder einer falschen Transformationsregel entstehen.
Eine Rechenbrücke zerlegt die Abweichung in nachvollziehbare Bestandteile. Sie zeigt beispielsweise Ausgangssumme, bewusst ausgeschlossene Teilmenge, regelbedingte Umrechnungen, ergänzte Werte und erwartete Zielsumme. Jede Differenz benötigt einen benannten Grund und eine betroffene Schlüsselliste.
Dadurch wird sichtbar, ob die Zielsumme falsch ist oder lediglich nach einer anderen, bestätigten Logik entsteht. Erst danach lässt sich entscheiden, ob Mapping, Transformation, Zielkonfiguration oder Prüferwartung geändert werden muss.
Warum schnelle Zielkorrekturen selten ausreichen
Den Zielwert direkt zu ändern kann einen einzelnen Testfall reparieren. Ohne Korrektur der verursachenden Regel entsteht derselbe Fehler im nächsten Lauf erneut.
Das Altsystem zum alleinigen Maßstab zu machen ist sinnvoll, wenn Werte unverändert übernommen werden sollen. Bei bewusst neuer Zielstruktur kann es dagegen die richtige Transformation fälschlich als Fehler erscheinen lassen.
Nur zufällige Stichproben zu prüfen kann offensichtliche Abweichungen finden. Systematische Regelgrenzen, seltene Codes oder bestimmte Organisationen werden damit möglicherweise nie getroffen.
Alle Fehler als Datenbereinigung zu behandeln vermischt Quelle, Mapping, technische Umsetzung und Zielkonfiguration. Die Fachbereiche bearbeiten dann Werte, obwohl die eigentliche Ursache im Skript oder Zielsystem liegt.
Die Korrektur braucht einen gezielten Wiederholungstest
Nach der Ursachenklärung wird nicht sofort der gesamte Bestand erneut freigegeben. Zuerst entsteht eine kleine, aber aussagekräftige Testmenge. Sie enthält:
- den ursprünglich fehlerhaften Fall,
- weitere Datensätze derselben betroffenen Teilmenge,
- einen Grenzfall der korrigierten Regel,
- eine bewusst nicht betroffene Vergleichsgruppe und
- gegebenenfalls einen abhängigen Prozessfall.
Damit wird nicht nur geprüft, ob der sichtbare Fehler verschwunden ist. Der Test zeigt auch, ob die Änderung an anderer Stelle neue falsche Werte erzeugt. Erst wenn erwarteter Wert, Importwert, Zielwert und Prozesswirkung zusammenpassen, kann die korrigierte Regel in den nächsten vollständigen Lauf übernommen werden.
Ein Befund gehört zu Datenstand, Regel und Verantwortung
Damit Fehler nicht zwischen Fachbereich, Migrationsentwicklung und ERP-Partner pendeln, sollte jeder relevante Befund kompakt dokumentiert werden:
- fachlicher Schlüssel und betroffene Teilmenge,
- beobachteter sowie erwarteter Zielwert,
- Quellwert und Kontext,
- verwendete Mapping- und Skriptversion,
- Importwert und tatsächlicher Zielwert,
- zugeordnete Ursache, Entscheidung und Verantwortlichkeit sowie
- Prüffall und Ergebnis des Nachtests.
Diese Befundkette ergänzt die umfassende Datenvalidierung vor der Abnahme. Sie konzentriert sich nicht auf alle Nachweise eines Datenlaufs, sondern auf die Frage, warum ein vollständig angekommener Datensatz fachlich die falsche Aussage trägt.
Wer entscheidet und wer korrigiert?
Der Fachbereich beschreibt die erwartete fachliche Bedeutung und bestätigt Regeln sowie Ausnahmen. Das Zielsystemteam erklärt Konfiguration, zulässige Werte und Folgelogik. Die interne Projektleitung bewertet Auswirkung, Priorität und Freigabe.
Wir können die Wertspur technisch aufbauen, Quell-, Regel-, Datei- und Zielstand zusammenführen, betroffene Teilmengen analysieren und bestätigte Korrekturen reproduzierbar in Transformation und Prüfung umsetzen. Welche Bedeutung ein Zielwert für das Unternehmen haben soll, entscheiden wir jedoch nicht anstelle des Fachbereichs.
Der sichtbare Fehler wird dort behoben, wo seine Bedeutung kippt
Wenn Daten nach der ERP-Migration nicht stimmen, ist das Zielsystem nur der Ort, an dem die Abweichung auffällt. Die Ursache kann schon in den Quelldaten liegen, bei der fachlichen Übersetzung entstehen, durch eine falsche technische Version eingebaut oder erst durch die Zielkonfiguration wirksam werden.
Die Wertspur trennt diese Möglichkeiten. Dadurch korrigiert das Projekt nicht irgendeinen sichtbaren Wert, sondern genau den frühesten falschen Beleg. Der nächste Test kann anschließend nachweisen, dass die Regel fachlich richtig, technisch wiederholbar und im vorgesehenen Prozess nutzbar ist.