Datenmigration beim ERP-Wechsel – warum Entrümpeln vor dem Umzug entscheidet

Ein ERP-System ist im Kern eine Datenbankanwendung. Seine Qualität hängt direkt von der Qualität der darin gespeicherten Daten ab. Das klingt technisch, ist aber eine sehr praktische Aussage: Wer mit schlechten Daten in ein neues System geht, hat nach der Migration dasselbe Problem – nur in einem anderen Interface.

Was sind schlechte Daten im Landmaschinenhandel? Ein paar Beispiele aus der Praxis:

Kunden, die mehrfach angelegt sind – einmal mit dem vollständigen Namen, einmal mit Kurzform, einmal vom neuen Mitarbeitenden, der den alten Datensatz nicht gefunden hat. Drei Datensätze, ein Kunde. Wenn das neue System automatisch Angebote oder Rechnungen zuordnen soll, hat es damit ein Problem.

Felder, die zweckentfremdet wurden. Im Faxnummernfeld steht die zweite Telefonnummer. Im Adressfeld steht eine interne Notiz. Im Artikelbeschreibungsfeld steht eine Lieferantennummer. Das ist kein Einzelfall – das ist Standard in Systemen, die über Jahre gewachsen sind und in denen Mitarbeitende pragmatisch Lösungen für fehlende Felder gesucht haben.

Maschinendaten mit Lücken. Seriennummern fehlen. Servicehistorien sind unvollständig. Maschinen tauchen in verschiedenen Systemteilen unter verschiedenen Bezeichnungen auf.

Buchwerte, die nicht mit Lagerbeständen übereinstimmen. Weil Abwertungen in der Buchhaltung vorgenommen wurden, aber im Warenwirtschaftssystem nie ankamen.

Datenmigration wird in vielen ERP-Projekten als technische Aufgabe behandelt: IT überführt Daten aus System A in System B, es gibt ein paar Mapping-Regeln, fertig. Das unterschätzt das Problem grundlegend.

Schlechte Stammdaten sind kein technisches Artefakt – sie sind das Ergebnis von Prozesslücken und fehlenden Datenpflege-Regeln. Wenn diese Regeln nicht vor der Migration definiert werden, entstehen nach der Migration dieselben Lücken. Neue Mitarbeitende tragen Daten in die falschen Felder ein. Kunden werden wieder doppelt angelegt. Maschinen werden nicht konsistent erfasst.

Die Migration ist der einmalige Moment, in dem der Händler die Kontrolle zurückgewinnen kann. Danach ist es deutlich schwieriger.

Datenmigration beginnt nicht mit dem Import-Skript. Sie beginnt mit einer ehrlichen Bestandsaufnahme.

Kundenstamm: Wie viele Datensätze gibt es? Wie viele davon sind Duplikate? Welche Felder sind systematisch falsch befüllt? Wer ist verantwortlich für die Pflege nach der Migration?

Maschinendaten: Sind alle relevanten Maschinen im System? Mit Seriennummer, vollständigen Konfigurationsdaten, Servicehistorie? Welche Lücken bestehen – und lassen sie sich vor der Migration schließen?

Artikelstamm: Gibt es veraltete Artikel, die nie mehr bestellt werden, aber das System belasten? Welche Kategorisierungen sind konsistent, welche nicht?

Finanzdaten: Stimmen Lagerbuchwerte mit Lagerbeständen überein? Gibt es offene Posten, die eigentlich längst ausgeglichen sind?

Das klingt nach viel Arbeit. Das ist es auch. Aber diese Arbeit ist unvermeidlich – die Frage ist nur, ob man sie vor oder nach der Migration macht. Vor der Migration ist sie einfacher, billiger und zielführender.

Eng verbunden mit der Datenqualität ist die Prozessdefinition. Ein ERP bildet Prozesse ab – es erfindet sie nicht. Wer nicht definiert hat, wie ein Serviceprozess ablaufen soll, bekommt kein ERP-System, das ihn automatisch optimiert. Er bekommt ein digitales Abbild seines aktuellen, möglicherweise ineffizienten Prozesses.

Das betrifft besonders Unternehmen mit mehreren Standorten. Wenn jeder Standort seine eigenen Datenpflege-Gewohnheiten hat, entsteht im gemeinsamen System Wildwuchs: Jeder trägt Daten in Felder ein, die dafür nicht gedacht sind. Jeder hat leicht abweichende Prozesse. Das Ergebnis ist eine Datenqualität, die sich nie stabilisiert.

Die Konsequenz: Vor dem System kommt der Prozess. Welche Abläufe sollen standortübergreifend einheitlich sein? Welche Datenfelder sind Pflichtfelder – und für wen? Wer prüft Kundendaten auf Duplikate, bevor ein neuer Datensatz angelegt wird? Diese Regeln müssen existieren, bevor das erste Datum migriert wird.

Es gibt noch einen weiteren Grund, warum Datenmigration heute ernster genommen werden sollte als in der Vergangenheit: KI.

Moderne ERP-Plattformen integrieren zunehmend KI-Funktionen – von der automatischen Servicedokumentation über KI-gestützte Garantiebearbeitung bis hin zur intelligenten Systemnavigation. All diese Funktionen arbeiten auf den Daten im System. Saubere, vollständige, konsistente Daten sind die Grundlage für sinnvolle KI-Ergebnisse. Fragmentierte, lückenhafte, widersprüchliche Daten produzieren fragmentierte, lückenhafte, widersprüchliche KI-Outputs.

Wer heute eine ERP-Einführung plant, trifft damit auch eine Entscheidung über seine KI-Fähigkeit in zwei bis drei Jahren. Der Händler, der jetzt entrümpelt und sauber migriert, baut die Datenbasis auf, auf der morgen KI sinnvoll arbeiten kann. Der Händler, der das überspringt, schiebt das Problem nur vor sich her.

Datenmigration ist keine Aufgabe für die IT. Sie ist eine Führungsaufgabe. Die Entscheidung, welche Daten wie migriert werden, welche Prozesse harmonisiert werden und welche Datenqualitäts-Standards gelten, muss von der Geschäftsführung oder dem Projektverantwortlichen getroffen werden – nicht von der IT überlassen.

Das braucht Zeit. Es braucht Konsequenz. Und es braucht die Bereitschaft, das Alte wirklich loszulassen – auch wenn man zwanzig Jahre lang so gearbeitet hat. Aber wer das tut, kommt nach der Migration in ein System, das wirklich neu ist. Nicht nur neu aussieht.