Der Export aus dem alten ERP-System liegt als CSV-Datei vor. Für den ersten Test werden Spalten verschoben, Codes ersetzt, leere Pflichtfelder ergänzt und einzelne Zeilen gelöscht. Nach zwei Tagen lässt sich die Datei importieren. Beim nächsten Datenstand beginnt dieselbe Arbeit jedoch erneut – und niemand weiß mehr genau, welche manuellen Änderungen zur erfolgreichen Fassung geführt haben.
Eine CSV für den ERP-Import umzuwandeln heißt deshalb nicht, die letzte Datei so lange zu bearbeiten, bis sie akzeptiert wird. Benötigt wird ein wiederholbarer Weg vom unveränderten Quellexport zur geprüften Importdatei. Auswahl, Zuordnung, Umrechnung und Formatierung müssen als Regeln vorliegen, damit jede Testmigration mit neuen Daten nach demselben Verfahren erzeugt werden kann.
CSV für ERP-Import umwandeln: Was dabei tatsächlich passiert
CSV ist zunächst nur ein einfaches Dateiformat, in dem Werte durch Trennzeichen voneinander getrennt sind. Das Format erklärt nicht, was eine Zeile fachlich bedeutet, welche Spalte der eindeutige Schlüssel ist oder welche Werte das Zielsystem erlaubt. Diese Logik muss das Migrationsprojekt ergänzen.
Bei der Umwandlung werden daher mehrere Aufgaben verbunden:
- relevante Datensätze auswählen und ungeeignete ausschließen,
- Informationen aus mehreren Quellen zusammenführen,
- Quellfelder den Zielspalten zuordnen,
- Codes, Formate und Einheiten in gültige Zielwerte übersetzen,
- fehlende Werte sichtbar behandeln,
- und das Ergebnis in exakt der erwarteten Struktur ausgeben.
Das ist eine Transformation: Aus einem dokumentierten Quellstand entsteht nach nachvollziehbaren Regeln ein neuer Zielstand. Der Import selbst ist erst der anschließende Schritt.
1. Den Roh-Export unverändert lassen
Die Ausgangsdatei sollte direkt nach dem Export gesichert und nicht manuell korrigiert werden. Dateiname, Erstellungszeitpunkt, Quellsystem und verwendeter Filter gehören dazu. So bleibt später erkennbar, auf welchem Datenstand die Importdatei beruht.
Schon beim Einlesen sind technische Eigenschaften festzulegen:
- Zeichencodierung, damit Umlaute und Sonderzeichen erhalten bleiben,
- Trennzeichen und Textbegrenzung,
- Umgang mit Zeilenumbrüchen innerhalb von Textfeldern,
- Dezimal- und Datumsformate,
- und die Frage, ob leere Zeichenfolgen, Nullwerte und Leerzeichen unterschiedlich behandelt werden.
Wer diese Eigenschaften dem Tabellenprogramm überlässt, kann Werte bereits beim Öffnen verändern. Der Roh-Export ist dann nicht mehr zuverlässig mit dem späteren Ergebnis vergleichbar.
2. Die Zielstruktur als Vertrag festlegen
Vor der Umwandlung muss geklärt sein, welche Spalten, Datentypen und Teilstrukturen das neue ERP erwartet. Der Beitrag ERP-Importvorlage richtig befüllen beschreibt, wie Satzebenen, Pflichtfelder und Schlüssel geprüft werden.
Für die Transformation entsteht daraus ein klarer Ausgangspunkt: Jede Zielspalte erhält eine Quellangabe und eine Regel. Diese kann „unverändert übernehmen“, „über Schlüssel aus einer zweiten Tabelle ergänzen“, „Quellcode in Zielcode übersetzen“, „aus mehreren Feldern bilden“ oder „fachlich noch offen“ lauten.
Ein offenes Feld wird dabei nicht durch eine technische Vermutung geschlossen. Es bleibt sichtbar, bis der verantwortliche Fachbereich oder das Zielsystem eine belastbare Regel liefert.
3. Auswahl, Verbindung und Umwandlung getrennt denken
Ein stabiler Prozess trennt drei Arten von Regeln.
Auswahlregeln
Sie entscheiden, welche Datensätze in die Migration gehören. Bei Lieferanten kann es um aktive Konten, offene Bestellungen oder bestimmte Sperrkennzeichen gehen. Die Regel muss fachlich verständlich sein und technisch eindeutig auf Quellfelder verweisen.
Verbindungsregeln
Sie führen Informationen aus mehreren Tabellen oder Dateien zusammen. Ein Kundenstamm benötigt möglicherweise eine Anschriftendatei und eine Codedatei für Zahlungsbedingungen. Jede Verbindung braucht einen belegten Schlüssel und eine erwartete Trefferzahl.
Transformationsregeln
Sie erzeugen den Zielwert. Dazu gehören Wertezuordnungen, Formatänderungen, Berechnungen, Zusammenfassungen oder fachlich bestätigte Standardwerte. Das Datenmapping der ERP-Migration hält fest, welche Regel fachlich gelten soll.
Durch diese Trennung lässt sich ein Fehler genauer einordnen. Fehlt ein Lieferant, liegt es möglicherweise am Filter. Hat er die falsche Zahlungsbedingung, betrifft es die Wertezuordnung. Taucht er mehrfach auf, ist vermutlich die Verbindung zu einer abhängigen Tabelle ungeklärt.
4. Manuelle Korrekturen in Regeln zurückführen
Bei einem Prototyp werden zwangsläufig Sonderfälle entdeckt. Eine Artikelnummer braucht führende Nullen, ein veralteter Code muss ersetzt oder ein Text gekürzt werden. Problematisch ist nicht die Entdeckung, sondern eine Korrektur, die nur in der fertigen Datei bleibt.
Jeder sinnvolle Fix sollte deshalb zurück in die Erzeugungslogik:
- Fehler und betroffener Datensatz werden dokumentiert.
- Der Fachbereich bestätigt die gewünschte Zielregel.
- Das Mapping erhält den neuen Stand.
- Die technische Transformation wird angepasst.
- Die gesamte Datei wird neu erzeugt und erneut geprüft.
Dadurch wird auch sichtbar, ob die Korrektur unerwünschte Nebenwirkungen bei anderen Datensätzen erzeugt. Eine manuell reparierte Einzelzeile kann diese Prüfung nicht leisten.
5. Fehlerfälle nicht still entfernen
Wenn eine Transformation einen Wert nicht eindeutig bilden kann, sollte der Datensatz nicht unbemerkt verschwinden. Besser ist eine getrennte Fehlerliste. Sie enthält den Quellschlüssel, das betroffene Zielfeld, die nicht erfüllte Regel und den benötigten Klärungsschritt.
So lassen sich drei Ergebnisse unterscheiden:
- bereit: Der Datensatz erfüllt die vereinbarten Regeln.
- klärungsbedürftig: Eine fachliche Entscheidung oder Zuordnung fehlt.
- bewusst ausgeschlossen: Eine freigegebene Auswahlregel nimmt den Datensatz aus dem Umfang.
Diese Unterscheidung verhindert, dass eine sinkende Datensatzmenge fälschlich als bessere Datenqualität erscheint.
6. Vor dem ERP-Upload außerhalb des Zielsystems prüfen
Viele Fehler lassen sich erkennen, bevor das Importwerkzeug gestartet wird. Dadurch bleibt der ERP-Test für die Fragen reserviert, die nur das Zielsystem beantworten kann.
Sinnvolle Vorprüfungen sind beispielsweise:
- Spaltenzahl, Reihenfolge und Spaltennamen entsprechen der Zielstruktur.
- Pflichtfelder sind nach der freigegebenen Regel gefüllt.
- Datums-, Zahlen- und Zeichenformate sind gültig.
- Schlüssel sind eindeutig und Referenzen besitzen einen passenden Hauptdatensatz.
- Zielcodes stammen aus den bestätigten Wertelisten.
- Datensatzmengen lassen sich vom Rohbestand bis zum Ergebnis erklären.
- Bekannte Sonderfälle liefern den erwarteten Zielwert.
Erst danach wird geprüft, ob das ERP die Datei technisch akzeptiert und ob die Daten im Zielprozess richtig funktionieren. Eine Uploadmeldung allein ersetzt diese fachliche Prüfung nicht.
7. Jeden Lauf eindeutig kennzeichnen
Zu einer Importdatei gehören der verwendete Rohstand, die Fassung des Mappings und die Version der Transformationslogik. Eine eindeutige Laufkennung verbindet diese Informationen mit dem späteren Testprotokoll.
Eine Laufkennung ist lediglich ein unverwechselbarer Name für einen konkreten Erzeugungs- und Teststand. Sie verhindert Aussagen wie „Wir haben die neue CSV geprüft“, obwohl mehrere ähnlich benannte Dateien im Umlauf sind. Wie diese Verbindung dauerhaft dokumentiert wird, zeigt der Beitrag zur Dokumentation einer ERP-Datenmigration.
Excel, SQL oder ein zusätzliches Werkzeug?
Die passende Technik hängt von Umfang, Komplexität und Wiederholungsbedarf ab. Excel kann für kleine Wertelisten, fachliche Entscheidungen und einen überschaubaren Prototyp sehr hilfreich sein. Je mehr Datensätze, Quellen und wiederkehrende Regeln zusammenkommen, desto riskanter wird jedoch eine manuelle Datei.
Wenn die Quelldaten in einer relationalen Datenbank liegen, können Auswahl, Verbindungen und viele Transformationen oft direkt mit strikt lesenden SQL-Abfragen umgesetzt werden. Das Ergebnis wird anschließend als CSV in der benötigten Zielstruktur ausgegeben. Für komplexe Landschaften kann ein ETL-Werkzeug sinnvoll sein. ETL bezeichnet den Ablauf aus Extrahieren, Transformieren und Laden. Ein zusätzliches Produkt ist aber nicht automatisch nötig, nur weil mehrere Verarbeitungsschritte existieren.
Die Entscheidung sollte sich an konkreten Anforderungen orientieren:
- Wie viele Quellen und Datensätze müssen verarbeitet werden?
- Wie oft wird die Datei bis zum Go-live neu erzeugt?
- Wie komplex sind Beziehungen, Wertelisten und Ausnahmen?
- Wie muss der Weg vom Quellwert zum Zielwert nachgewiesen werden?
- Welche Technik kann das Projektteam nach einer Änderung sicher erneut ausführen?
Woran ein wiederholbarer CSV-Prozess erkennbar ist
Ein belastbarer Prozess kann mit einem neuen Roh-Export erneut ausgeführt werden, ohne die letzte Importdatei als Vorlage zu missbrauchen. Dabei entsteht neben der Datei auch ein nachvollziehbares Prüfergebnis.
Vor dem nächsten Test sollten Sie deshalb beantworten können:
- Ist der Roh-Export unverändert und eindeutig bezeichnet?
- Gibt es pro Zielspalte eine bestätigte Quelle oder Regel?
- Sind Filter, Verbindungen und Transformationen getrennt nachvollziehbar?
- Werden ungeklärte Datensätze sichtbar ausgewiesen?
- Lassen sich Mengenabweichungen erklären?
- Kann eine zweite Person denselben Lauf erneut erzeugen?
Die fachlichen Regeln und Freigaben bleiben beim Unternehmen. Operative Unterstützung kann den Altexport analysieren, das Mapping in wiederholbare SQL- oder Dateiregeln überführen, Fehlerlisten erzeugen und eine prüfbare Importdatei bereitstellen. So wird aus einer einmalig reparierten CSV ein kontrollierter Migrationsprozess, der bis zum Go-live mit neuen Daten weiterarbeiten kann.