„Mach das Radio an und arbeite die Liste ab“ klingt zunächst nach einer pragmatischen Lösung. Wenn vor einer ERP-Umstellung Tausende Altdatensätze auffällig wirken, sollen Fachbereiche deshalb häufig Zeile für Zeile prüfen, Schreibweisen vereinheitlichen und fehlende Angaben nachtragen.
Für eine Datenbereinigung vor der ERP-Migration ist das jedoch oft der falsche Startpunkt. Die Länge einer Liste sagt noch nicht, welche Datensätze tatsächlich fehlerhaft sind, welche Angaben das neue ERP überhaupt benötigt und welche Abweichungen sich mit einer einzigen Regel behandeln lassen. Bevor Handarbeit verteilt wird, sollte das Projekt deshalb zuerst Zielzweck, Fehlermuster und Behandlung klären.
Die kurze Antwort lautet: Nicht jeder Altdatensatz muss vor der Migration manuell bereinigt werden. Wiederkehrende und eindeutig entschiedene Änderungen können bei der Übertragung reproduzierbar umgesetzt werden. Manuelle Arbeit bleibt dort notwendig, wo fachliche Bedeutung fehlt, mehrere Entscheidungen möglich sind oder eine Korrektur auch in der weiterhin maßgeblichen Quelle gebraucht wird.
Der Zielprozess entscheidet, was überhaupt ein Datenfehler ist
Datenqualität ist in diesem Zusammenhang kein abstrakter Zustand vollkommener Fehlerfreiheit. Entscheidend ist, ob die benötigten Daten für ihren vorgesehenen Zweck im neuen ERP vollständig, richtig verbunden und fachlich nutzbar sind. Ohne diesen Zielzweck lässt sich eine Auffälligkeit nicht sinnvoll bewerten.
Eine fehlerhafte interne Notiz kann für die Migration bedeutungslos sein, wenn sie nicht übernommen wird. Ein alter Kategoriecode kann im Altsystem korrekt sein und im neuen ERP trotzdem einen anderen Zielwert benötigen. Zwei Kundenstammsätze, die möglicherweise denselben Geschäftspartner beschreiben, verlangen dagegen eine fachliche Entscheidung, insbesondere wenn offene Vorgänge mit ihnen verbunden sind.
Deshalb steht vor der Bereinigung die Auswahl der wirklich benötigten Informationen. Wie diese Entscheidung getroffen werden kann, zeigt unser Beitrag Welche Daten gehören beim ERP-Wechsel ins neue System?. Erst danach ist klar, für welchen Bestand die Datenbereinigung überhaupt ein Migrationsproblem löst.
Eine lange Liste ist noch keine Analyse
Wer Datensätze einzeln öffnet, sieht einzelne Auffälligkeiten. Das Projekt braucht aber zunächst das Muster dahinter. Eine Datenanalyse gruppiert vorhandene Werte, zählt leere Pflichtangaben, grenzt mögliche Dubletten ein und prüft Beziehungen zwischen zusammengehörigen Informationen. So wird sichtbar, ob ein Fehler nur vereinzelt vorkommt oder eine ganze, klar beschreibbare Gruppe betrifft.
Wenn die Datenquelle es zulässt, nutzen wir dafür bevorzugt lesende SQL-Abfragen. Sie verändern keine Quelldaten, sondern machen Werteverteilungen, Häufigkeiten und Abweichungen nachvollziehbar. Auch andere geeignete Analysewege können dieselbe Aufgabe erfüllen. Entscheidend ist nicht das Werkzeug, sondern dass die betroffene Datenmenge und die gemeinsame Ursache vor der Korrektur bekannt sind.
Eine Datei mit vielen Zeilen kann lediglich wenige wiederkehrende Probleme enthalten. Umgekehrt kann eine kleine Datenmenge fachlich anspruchsvoll sein, wenn jeder Datensatz anders entschieden werden muss. Die Zahl der Zeilen bleibt deshalb eine Mengenangabe – noch keine belastbare Aufwandsschätzung für die Bereinigung.
Aus einem Fehlermuster folgt nicht immer dieselbe Behandlung
Sobald ein Muster abgegrenzt ist, muss das Projekt entscheiden, was damit geschieht. Vier Behandlungen sollten dabei nicht vermischt werden:
| Festgestellter Befund | Sinnvolle Behandlung | Entscheidende Verantwortung |
|---|---|---|
| Ein alter Wert besitzt genau einen fachlich bestätigten Zielwert. | Beim Übertragen durch eine dokumentierte Transformationsregel umwandeln. | Der Fachbereich bestätigt die Bedeutung; die technische Umsetzung kann automatisiert werden. |
| Eine weiterhin benötigte Information fehlt und lässt sich nicht sicher ableiten. | Gezielt anreichern oder in der maßgeblichen Quelle korrigieren. | Der zuständige Datenverantwortliche liefert oder bestätigt den Wert. |
| Mehrere fachlich plausible Zuordnungen oder mögliche Dubletten bleiben offen. | Als begrenzte Ausnahmeliste zur manuellen Entscheidung vorlegen. | Der Fachbereich entscheidet; Technik darf die Bedeutung nicht erraten. |
| Die Information wird für den Zielprozess nicht benötigt. | Nicht allein für die Migration bereinigen; Zugriff, Archivierung oder Löschung getrennt entscheiden. | Projektleitung und zuständige Fach- oder Rechtsverantwortung klären den weiteren Umgang. |
Diese Trennung verhindert zwei gegensätzliche Fehler. Einerseits sollte nicht jeder historische Datenbestand zur Voraussetzung für den Go-live gemacht werden. Andererseits darf „automatisierbar“ nicht bedeuten, dass eine technische Regel ungeklärte fachliche Entscheidungen verdeckt.
Automatisieren heißt nicht, Fachentscheidungen an die Technik abzugeben
Eine Transformationsregel ist eine wiederholbare Umwandlung beim Übertragen der Daten. Sie kann beispielsweise festlegen, dass ein bestätigter alter Kategoriecode immer in einen bestimmten neuen Wert übersetzt wird. Damit die Regel belastbar ist, muss jedoch vorher feststehen, welche Datensätze sie betrifft, welcher Zielwert fachlich richtig ist und welche Ausnahmen nicht unter die Regel fallen.
Genau an dieser Grenze ergänzen sich Fachbereich und technische Datenmigration. Der Fachbereich kennt Geschäftsbedeutung, Sonderfälle und die Folgen einer Entscheidung im Zielprozess. Die technische Seite kann den Bestand analysieren, betroffene Gruppen sichtbar machen, eine entschiedene Regel reproduzierbar umsetzen und die verbleibenden Ausnahmen gezielt vorbereiten.
Dadurch müssen Keyuser nicht unstrukturierte Tabellen durchsuchen und bei jeder Zeile dieselbe Frage neu beantworten. Sie bearbeiten die Fälle, in denen ihr Wissen tatsächlich gebraucht wird. Die wiederkehrende Umsetzung bleibt anschließend bei der Migrationsstrecke.
Eine Regel ist erst belastbar, wenn sie den nächsten Test übersteht
Eine automatisierte Korrektur ist nicht schon deshalb richtig, weil ein Skript ohne Fehlermeldung gelaufen ist. Nehmen wir die eindeutige Übersetzung eines alten Kategoriecodes in einen neuen Zielwert: Der Prüfnachweis muss zeigen, dass alle betroffenen Datensätze umgewandelt wurden, keine anderen Datensätze unbeabsichtigt verändert wurden und der neue Wert im vorgesehenen ERP-Prozess fachlich funktioniert.
Wir dokumentieren deshalb nicht nur Quelle und Ziel, sondern auch Auswahlbedingung, Transformationsregel, bekannte Ausnahme und Prüfkriterium. Der Beitrag Datenmapping im ERP-Projekt erklärt diese Verbindung ausführlicher. Nach der Testladung wird das Ergebnis technisch und fachlich geprüft; welche Nachweise dafür benötigt werden, behandelt unser Beitrag zur Datenvalidierung vor der Abnahme.
Der Test hat noch eine zweite Aufgabe: Er zeigt, ob das vermeintlich einheitliche Fehlermuster wirklich einheitlich war. Tauchen neue Ausnahmen auf, wird die Regel nicht still erweitert. Stattdessen wird ihre Grenze präzisiert und die neue Fallgruppe erneut entschieden. So bleibt die Bereinigung auch über mehrere Testmigrationen nachvollziehbar.
So wird aus der Großaktion ein begrenztes Arbeitspaket
Ein sinnvoller Einstieg braucht weder den gesamten Altdatenbestand noch ein unternehmensweites Datenqualitätsprogramm. Er kann mit einem priorisierten Datenobjekt und einem sichtbaren Qualitätsproblem beginnen. Für diesen ersten Fall werden Zielprozess, betroffener Bestand, Fehlermuster, beschlossene Behandlung, Verantwortlichkeit und Prüfnachweis festgehalten.
Dieses kleine Arbeitspaket liefert bereits eine belastbare Entscheidung: Lässt sich das Muster eindeutig transformieren, muss es nicht Zeile für Zeile bearbeitet werden. Bleiben nur wenige unklare Fälle übrig, erhält der Fachbereich eine gezielte Ausnahmeliste. Fehlt dagegen noch die fachliche Zielanforderung, wird genau diese Entscheidung sichtbar, bevor eine große Bereinigungsaktion Zeit bindet.
Erst aus solchen untersuchten Fällen lässt sich seriös abschätzen, wie viel Analyse, technische Umsetzung und manuelle Facharbeit für weitere Datenobjekte erforderlich sind. Eine pauschale Aufwandsschätzung allein aus Datensatzmengen wäre dafür zu grob.
Wann externe Unterstützung die Fachbereiche wirklich entlastet
Externe Unterstützung ist besonders dann sinnvoll, wenn das Unternehmen die fachliche Bedeutung seiner Daten kennt, aber Analyse, regelbasierte Aufbereitung und wiederholbare Prüfung nicht zusätzlich zum Tagesgeschäft umsetzen kann. Dann sollte ein Datenmigrationsdienstleister nicht einfach weitere Listen verteilen. Sein Arbeitspaket muss die operative Last zwischen fachlicher Entscheidung und geprüftem Zielbestand schließen.
Wir können dazu Quelldaten strukturiert untersuchen, Fehlermuster und betroffene Mengen vorbereiten, bestätigte Regeln technisch umsetzen und die Ergebnisse für Test und Freigabe dokumentieren. Die ERP-Projektleitung behält ihre Steuerungsverantwortung, der ERP-Anbieter bleibt für Zielsystem und Importanforderungen zuständig, und die Fachbereiche entscheiden Bedeutung sowie Ausnahmen. Welche Leistungen in einem solchen Auftrag konkret geregelt sein sollten, zeigt unser Beitrag über ein belastbares Angebot für die ERP-Datenmigration.
Nicht alles muss vorher sauber sein – aber jede Behandlung muss entschieden sein
Das Ziel einer ERP-Datenmigration ist kein vollkommen bereinigtes Abbild der gesamten Vergangenheit. Benötigt wird ein Datenbestand, der die vereinbarten Prozesse im neuen System zuverlässig trägt. Eine umfassendere Datenqualitätsinitiative kann sinnvoll sein, sollte dann jedoch ein eigenes Ziel, eigene Verantwortlichkeiten und einen eigenen Zeitrahmen erhalten.
Für die Migration genügt deshalb weder „alles händisch prüfen“ noch „das Skript wird es richten“. Belastbar wird die Datenbereinigung, wenn das Projekt zuerst den Zielzweck bestimmt, wiederkehrende Fehlermuster analysiert, jede Behandlung fachlich entscheidet und das Ergebnis reproduzierbar prüft. So wird aus einer unüberschaubaren Liste eine begrenzte Zahl nachvollziehbarer Regeln und echter Ausnahmen.