Articles

Articles

Articles

Datenaufbereitung für die Migration: 5 Regeln aus der EYOND‑Praxis

26. September 2025

Colorful software or web code on a computer monitor
Colorful software or web code on a computer monitor
Colorful software or web code on a computer monitor

Einleitung: Warum Datenaufbereitung über Erfolg und Misserfolg entscheidet

ERP‑Migrationen scheitern selten an der reinen Technik. In der Praxis stolpern Projekte über unvollständige Kundendaten, widersprüchliche Artikelstämme, uneinheitliche Steuerschlüssel, doppelte Debitoren oder fehlerhafte Bankverbindungen. Wird Datenqualität erst während der Testmigration sichtbar, entstehen teure Nacharbeiten, Terminverzug und Vertrauensverlust bei Fachbereichen.

Die gute Nachricht: Viele Risiken lassen sich vorher beherrschbar machen. Dieser Beitrag verdichtet Erfahrungen aus EYOND‑Projekten im E‑Commerce‑Umfeld – vom Wechsel aus Altsystemen in moderne Cloud‑ERPs wie etwa Exact Online Premium oder Reybex bis hin zu Re‑Plattformierungen zwischen aktuellen Systemen. Das Ziel: eine sauber geführte, nachvollziehbare und auditierbare Migration, die am Go‑Live‑Tag produktiv nutzbare Daten bereitstellt.

Im Kern empfehlen wir fünf Regeln, die in unterschiedlichen Branchen und Systemlandschaften zuverlässig funktionieren:

  1. Datenqualität messen, bevor migriert wird.

  2. Stammdaten konsequent bereinigen.

  3. Mapping‑Regeln fachlich wie technisch dokumentieren.

  4. Pilotmigrationen als Realitätstest nutzen.

  5. Datenqualität als kontinuierlichen Prozess verankern.

1. Datenqualität messen, bevor Sie migrieren

Datenqualität ist kein Bauchgefühl, sondern messbar. Bevor Feldbezeichner und Schnittstellen entworfen werden, braucht es ein objektives Bild:

  • Profiling der Bestände: Vollständigkeit, Korrektheit, Eindeutigkeit, Konsistenz und Aktualität. Prüfen Sie Pflichtfelder, Referenzen (z. B. Kunde ↔ Adresse), Semantik (z. B. Netto/Brutto), Wertebereiche und Formate (IBAN, USt‑IdNr., E‑Mail).

  • Messbare KPIs definieren:

    • Dublettenquote Debitoren/Kreditoren [%]

    • Anteil ungültiger Adressen [%]

    • Pflichtfeld‑Vollständigkeit je Objektklasse [%]

    • Quote fehlerhafter Steuerschlüssel in Belegen [%]

    • Anzahl „verwaister“ Referenzen (z. B. Bestellungen ohne existierende Kunden-ID)

  • Werkzeuge und Vorgehen: SQL‑Abfragen, Python/pandas, OpenRefine, KNIME, Validierungslibraries (z. B. für IBAN, USt‑IdNr.), ggf. Address‑Validation APIs. Ergebnisse in einem zentralen Datenqualitätsbericht festhalten.

Praxisbeispiel: In einem Handelsunternehmen zeigte das Profiling 18 % Kundendubletten und 7 % ungültige PLZ‑Ort‑Kombinationen. Erst der messbare Befund schuf Priorität, Budgets und bereichsübergreifende Unterstützung für die Bereinigung.

Checkliste „Profiling starten“

  • Zielobjekte festlegen (Kunden, Lieferanten, Artikel, Preise, Belege, Kontenplan).

  • KPI‑Set definieren und Schwellenwerte vereinbaren.

  • Datenextrakte aus Altsystem sichern (mit Zeitstempel, Quelle).

  • Prüfskripte versionieren und Ergebnisse dokumentieren.

2. Stammdatenbereinigung ist Pflicht, keine Kür

Stammdaten verbreiten sich als Referenzen in allen Prozessen. Jede Unschärfe wird in Einkauf, Verkauf, Buchhaltung, Logistik und Reporting sichtbar. Bereinigung vor der Migration vermeidet exponentielle Folgekosten.

Kernmaßnahmen

  • Dubletten entfernen: Matching via deterministischer Regeln (z. B. exakte Übereinstimmung) plus fuzzy Matching (z. B. Levenshtein, Soundex). Fachliche Bestätigung ist Pflicht, bevor zusammengeführt wird.

  • Standardisierung:

    • Adressformate (Straße/Hausnummer getrennt, ISO‑Ländercodes, valide PLZ‑Ort‑Kombinationen)

    • Kommunikationsdaten (E‑Mail‑Regex, Telefonnummern mit Ländervorwahl, einheitliche Schreibweise)

    • Bankdaten (IBAN/BIC‑Prüfung)

    • Identifikatoren (USt‑IdNr., interne IDs, externe Referenzen)

  • Ausmisten: Inaktive Lieferanten/Artikel kennzeichnen oder entfernen; Alt‑Artikel mit Auslaufkennzeichen, gesperrt oder archiviert übernehmen.

  • Sicht der Fachbereiche: Vertrieb, Einkauf, Finance und Logistik entscheiden über Zusammenführungen, Namenskonventionen und Mindestanforderungen pro Objektklasse.

E‑Commerce‑Spezifika

  • Artikelvarianten und Sets: Variantenlogik (Größe/Farbe) konsistent halten, Set‑/Bundle‑Beziehungen explizit modellieren.

  • SKU‑Governance: Ein SKU‑Schema festlegen (präfixe, Prüfziffern, Längen).

  • Preislisten und Steuern: Netto/Brutto‑Logik, Kundengruppenpreise, B2B/B2C‑Richtlinien, länderspezifische Steuersätze validieren.

  • Medien & SEO: Produktbilder, GTIN/Barcode, Marken, Kategorisierung, Meta‑Daten prüfen – Migration ist die Chance zur Vereinheitlichung.

Organisatorisch

  • Daten‑Owner und RACI: Wer entscheidet, wer arbeitet zu, wer wird informiert? Ohne klare Verantwortung scheitert Bereinigung an Grauzonen.

  • Vier‑Augen‑Prinzip: Zusammenführungen und Löschungen werden protokolliert und freigegeben.

3. Mapping‑Regeln sauber dokumentieren

Migration ist nie nur ein Transfer, sondern immer eine Transformation. Deshalb sind Mapping‑Regeln das fachliche Herzstück. Sie bestimmen, wie alte Semantik in die neue Welt übersetzt wird.

Was gehört in eine Mapping‑Spezifikation?

  • Quelle/Ziel: System, Tabelle, Feld, Datentyp, Pflicht/Optional.

  • Regel: 1:1, 1:n, n:1, feste Zuordnung, berechnet, Lookup, Default.

  • Semantik: Business‑Bedeutung und Beispiele.

  • Validierung: Prüfkriterien, Fehlermeldung, Umgang mit Ausnahmen.

  • Versionierung: Änderungsdatum, Autor, Ticket‑Referenz.

Beispiel (vereinfacht)

Quelle (Alt)

Ziel (Neu)

Regel

Anmerkung

cust_no

customer_id

1:1

Alphanumerisch, führende Nullen erhalten

vat_code

tax_category

Lookup

Tabelle T_VAT_MAP pflegen, Default „standard“

street + house_no

street_line1

Transform

Zusammensetzen mit Trennzeichen „ “

country_text

country_iso2

Normalize

ISO‑Abbildung, Sonderfälle UK/GR beachten

Kontenplan, Steuern, Einheiten

  • Kontenplan (YCOA/CoA): Altes zu neues Konto mit Gültigkeitsbereich, Steuerungskennzeichen, Kostenstellenlogik.

  • Steuerlogik: Länder, Lieferland, B2B/B2C, OSS/IOSS, Reverse‑Charge. Fehlende Kombinationen müssen bewusst ausgeschlossen oder neu modelliert werden.

  • Mengen‑ und Preiseinheiten: Einheitencodes (z. B. ISO‑UOM), Umrechnungen, Rundungsregeln, Dezimalstellen – insbesondere für Marktplatz‑Integrationen.

Dokumentation & Nachvollziehbarkeit

  • Ein zentrales, versioniertes Repository (z. B. Confluence, Git, SharePoint) für Mappingtabellen, SQL/ETL‑Skripte und Testfälle.

  • Änderungsverfolgung über Tickets; jede Änderung hat einen Reviewer.

  • Verbindliche Namenskonventionen für Mappings und Transformationsjobs.

4. Pilotmigrationen als Realitätstest nutzen

Papier ist geduldig – erst Testläufe zeigen, ob Daten fachlich verwendbar sind. Eine Pilotmigration reduziert Risiko, schafft Vertrauen und liefert harte Zahlen.

Pilotstrategie

  • Sinnvolle Teilmengen: z. B. ein Quartal Buchungen, 1 000 Debitoren, 2 000 Artikel mit Medien, repräsentative Bestellungen aus Kernländern.

  • End‑to‑End testen: Von der Übernahme in das Ziel‑ERP über Workflows bis in Finanz‑ und Logistikprozesse.

  • Abstimmung mit Fachbereichen: Key‑User prüfen reale Anwendungsfälle: Auftragserfassung, Retouren, Steuerberechnung, Auswertungen.

Qualitätssicherung nach der Pilotmigration

  • Saldo‑Abgleich: Debitoren/Kreditoren‑Salden, Sachkontensalden und Lagerbestände je Stichtag.

  • Vollständigkeit: Stichprobenartig Quell‑Belege nachverfolgen und im Zielsystem wiederfinden.

  • Regelkonformität: Pflichtfelder, Validierungsfehler, Ausnahmelogik.

  • Performance & Durchsatz: ETL‑Laufzeiten, Fehlerraten, Re‑Runs.

Beispiel aus der Praxis: In einer Pilotmigration waren 95 % der Aufträge korrekt, 5 % scheiterten an der Steuerlogik, weil veraltete Codes nicht auf neue Kategorien gemappt waren. Durch eine ergänzte Lookup‑Tabelle und ergänzende Validierung sank die Fehlerquote im nächsten Lauf auf unter 0,5 %.

5. Datenaufbereitung als kontinuierlichen Prozess verstehen

Nach dem Go‑Live ist vor der nächsten Änderung. Datenqualität gehört in die Linie, nicht nur ins Projekt.

Bausteine einer nachhaltigen Data Governance

  • Datenverantwortung: Benannte Data Owner je Objektklasse, regelmäßige Qualitätsberichte.

  • Regelmäßige Kontrollen: Automatisierte Validierungen (täglich/wöchentlich), Good‑Data‑Dashboards, Warnungen bei KPI‑Verstößen.

  • Change Management: Neue Felder, Steuerregeln, Marktplatzanforderungen; jede Änderung zieht Mapping‑Pflege und Regressionstests nach sich.

  • Onboarding/Training: Schulungen für Stammdatenpfleger, klare Arbeitsanweisungen und Definitionen (Data Dictionary).

Typische Governance‑KPIs

  • Anzahl neu erkannter Dubletten pro Monat

  • Zeit bis zur Behebung von Datenfehlern (Mean Time to Repair)

  • Abdeckungsgrad Pflichtfelder nach Objektklasse

  • Fehlerrate in ETL‑Läufen

Häufige Fallstricke – und wie man sie vermeidet

  • „Wir mappen das später.“ Ohne früh dokumentierte Regeln wächst die technische Schuld. Gegenmaßnahme: Mapping‑Backlog mit Priorität und Abnahme.

  • „Das prüft die IT.“ Fachliche Semantik gehört in die Fachbereiche. Gegenmaßnahme: Gemeinsame Workshops, formale Abnahmen, RACI.

  • „Pilot sparen wir uns.“ Ohne Realitätstest drohen Überraschungen im Echtbetrieb. Gegenmaßnahme: Mindestens ein vollständiger End‑to‑End‑Pilot mit Saldenabgleich.

  • „Alles Altlasten übernehmen.“ Legacy‑Sonderfälle verkomplizieren die neue Welt. Gegenmaßnahme: Bewusste Entscheidung, was migriert, archiviert oder neu aufgesetzt wird.

  • „Einmal sauber, immer sauber.“ Datenqualität erodiert ohne Governance. Gegenmaßnahme: Regelmäßige Checks, klare Verantwortlichkeiten, Automatisierung.

Vorgehensmodell: In 7 Schritten zur belastbaren Migration

  1. Scope & Ziele klären: Welche Datenobjekte, Stichtage, rechtlichen Vorgaben, Zielsysteme.

  2. Profiling & KPI‑Set: Datenqualitätsmessung mit klaren Schwellenwerten.

  3. Bereinigung: Dubletten, Standardisierung, Löschkonzept.

  4. Mapping‑Design: Fachlich/technisch dokumentieren, Validierungsregeln definieren.

  5. Pilotmigration: Repräsentatives Datenpaket, End‑to‑End‑Tests, Saldenabgleich.

  6. Korrekturschleifen: Findings in Mappings und Bereinigungslogik einarbeiten.

  7. Go‑Live & Governance: Cutover‑Plan, Monitoring, Data‑Owner‑Prozesse.

Technische Bausteine und Tooling

  • Extraktion: Datenabzüge als CSV/Parquet; Quelltabellen mit Zeitstempel und Quelle kennzeichnen; sensible Daten pseudonymisieren, wenn nötig.

  • Transformation (ETL/ELT): SQL‑Views, Python/pandas, KNIME‑Flows; klare Job‑Namen und Dependency‑Graphen; Re‑Runs idempotent gestalten.

  • Validierung: Regelwerke wie „Great Expectations“‑ähnliche Tests; Regex‑Prüfungen, Referenzintegrität, Wertebereiche, fachliche Saldendifferenzen.

  • Protokollierung: Laufzeiten, Datensätze, Fehlerlisten mit Referenzen; Artefakte revisionssicher ablegen.

  • Schnittstellen/Connectoren: Shop‑, ERP‑, Logistik‑Integrationen über standardisierte APIs; Tracing über Korrelations‑IDs.

  • Sicherheit: Zugriff nach Need‑to‑Know, Verschlüsselung ruhender und übertragener Daten, Audit‑Trails, DSGVO‑Konformität.

EYOND‑Erfahrungen aus Projekten (anonymisiert)

  • Omnichannel‑Händler: Ausgangslage mit 20 % fehlerhaften Adressen, drei parallelen SKU‑Schemata und uneinheitlichen Steuerschlüsseln. Durch Profiling, Standardisierung und eine refaktorierte Mapping‑Tabelle sank die Fehlerrate in Testmigrationen auf unter 1 %. Go‑Live fristgerecht, Retourenquote stabil, Finanzreporting konsistent.

  • D2C‑Brand mit Marktplatzfokus: Viele Bundles/Sets und variantenreiche Kataloge. Ein explizites Varianten‑ und Bundle‑Modell plus klare UOM‑Definitionen verhinderte Preis‑ und Mengenfehler in Marktplatzfeeds. KPI‑Dashboards machten Qualitätsabweichungen früh sichtbar.

  • B2B‑Großhandel: Verschachtelte Rabatt‑ und Zahlungskonditionen, historisch gewachsene Kundengruppen. Nach fachlicher Bereinigung und Neu‑Clustering konnten Preise konsistent gemappt werden; der Debitorensaldo stimmte im Stichtagsabgleich auf Cent.

Praxisanhang

A. Minimaler Datenqualitätsbericht (Beispielstruktur)

  • Übersicht: Datenobjekte, Extraktionszeitpunkt, Verantwortliche

  • KPI‑Tabelle je Objektklasse

  • Top‑10 Datenfehler mit fachlicher Einschätzung

  • Maßnahmenplan mit Verantwortlichen und Terminen

B. Beispiel für eine VAT‑Mapping‑Tabelle (Auszug)

Alt‑Code

Beschreibung (Alt)

Ziel‑Kategorie

Bemerkung

A0

Inland 0 %

exempt

innerbetriebliche Vorgänge

A7

Inland 7 %

reduced

Lebensmittel

A19

Inland 19 %

standard

Standard

EU0

EU 0 %

icl

innergemeinschaftliche Lieferung

RC

Reverse Charge

reverse_charge

§13b UStG

C. Cutover‑Checkliste (Auszug)

  • Letzter Delta‑Extrakt aus Altsystemen erstellt

  • Sperren für Stammdatenänderungen aktiviert

  • ETL‑Pipelines mit Produktivparametern durchgelaufen

  • Saldenabgleich Debitoren/Kreditoren/Sachkonten dokumentiert

  • Fachliche Smoke‑Tests abgeschlossen (Auftrag, Rechnung, Zahlung, Versand)

Fazit

Migration ist ein Organisationsprojekt mit technischen Mitteln. Wer Datenqualität früh misst, Stammdaten konsequent bereinigt, Mappen nachvollziehbar dokumentiert, Pilotmigrationen ernst nimmt und Data Governance dauerhaft etabliert, reduziert Risiken signifikant. Der Nutzen ist unmittelbar spürbar: weniger Korrekturschleifen, schnellere Prozesse, belastbare Reports und zufriedene Anwender.

Kontaktiere uns für eine kostenlose Migrations‑Checkliste: Eine kompakte, praxisnahe Übersicht aller Schritte, Rollen, Artefakte und Qualitätsprüfungen für Ihre ERP‑Migration.

Sprich mit uns über dein Setup.

Ob du erst am Anfang stehst oder mitten im Umbau: Wir helfen dir, Prozesse, Systeme und Datenflüsse klarer, stabiler und zukunftssicher zu gestalten.

Sprich mit uns über dein Setup.

Ob du erst am Anfang stehst oder mitten im Umbau: Wir helfen dir, Prozesse, Systeme und Datenflüsse klarer, stabiler und zukunftssicher zu gestalten.

Sprich mit uns über dein Setup.

Ob du erst am Anfang stehst oder mitten im Umbau: Wir helfen dir, Prozesse, Systeme und Datenflüsse klarer, stabiler und zukunftssicher zu gestalten.