Stammdatenprobleme lassen sich nicht wegmigrieren

Im ERP-Projekt werden Datenprobleme häufig spät sichtbar. Die Software ist ausgewählt, Prozesse sind konfiguriert und der Go-live rückt näher. Dann soll das Migrationsteam Kunden, Lieferanten, Artikel, Preise und offene Vorgänge aus mehreren Altsystemen übernehmen.

Dabei zeigt sich: Gleiche Kunden besitzen unterschiedliche Nummern, Artikel haben keine einheitlichen Mengeneinheiten, Pflichtfelder sind historisch leer und verschiedene Abteilungen verwenden denselben Statusbegriff mit anderer Bedeutung. Der naheliegende Auftrag lautet dann: „Bereinigt das bei der Migration.“

Ein technisches Team kann Werte umformen, Datensätze zusammenführen und Regeln automatisieren. Es kann aber nicht entscheiden, welche fachliche Definition künftig gilt, welcher Dublette vertraut wird oder wer einen strittigen Datensatz freigibt.

Die entscheidende Trennung lautet deshalb: Datenmigration bewegt und transformiert Daten. Datenqualität und Stammdatenverantwortung bestimmen, welche Daten gelten sollen.

Eine Migration ist kein fachlicher Schiedsrichter

Eine Migration beantwortet technische Fragen:

• Aus welcher Quelle wird gelesen?
• Welche Datensätze werden ausgewählt?
• Wie werden Quell- und Zielfelder zugeordnet?
• Welche Werte müssen umgerechnet oder ergänzt werden?
• In welcher Reihenfolge werden abhängige Objekte geladen?
• Welche Datensätze wurden erfolgreich oder fehlerhaft verarbeitet?

Fachliche Fragen liegen davor:

• Was ist in unserem Unternehmen ein aktiver Kunde?
• Welches System oder welche Rolle ist für die Kundenadresse führend?
• Dürfen zwei Artikelnummern zusammengeführt werden?
• Welche historischen Vorgänge müssen operativ verfügbar bleiben?
• Welche Qualitätsmängel verhindern den Go-live?
• Wer darf eine Ausnahme genehmigen?

Wenn diese Entscheidungen fehlen, werden sie häufig unbemerkt in Mappingtabellen, Skripte oder manuelle Excel-Korrekturen verlagert. Die technische Umsetzung trifft dann fachliche Regeln, ohne dafür legitimiert zu sein.

Nicht alle Daten gehören in denselben Umfang

Vor der Bereinigung muss das Projekt unterscheiden, welche Arten von Daten überhaupt betrachtet werden. Ein hilfreicher Ausgangspunkt ist:

Datenart	Beispiele	Zentrale Entscheidung
Stammdaten	Kunden, Lieferanten, Artikel, Konten, Mitarbeitende	Welche Definition und welcher Owner gelten künftig?
Konfigurationsdaten	Währungen, Steuercodes, Nummernkreise, Parameter	Welche Zielprozesse und Organisationsstrukturen werden eingerichtet?
offene Bewegungsdaten	Aufträge, Bestellungen, Bestände, offene Posten	Welcher Stichtag und welche fachliche Abstimmung sind erforderlich?
historische Daten	abgeschlossene Vorgänge, alte Belege, Auswertungsdaten	Was muss im neuen System liegen, was darf revisions- oder lesbar archiviert werden?
Dokumente	Verträge, Anhänge, Rechnungen, technische Unterlagen	Welcher Bezug, Schutzbedarf und Aufbewahrungsweg gelten?

Die aktuelle Microsoft-Dokumentation zu Konfigurations- und Migrationsdaten verwendet eine vergleichbare Trennung für Dynamics-365-Projekte und nennt Planung, Quellanalyse, Mapping, Transformation, Tests und Validierung als eigene Aufgaben. Die Details sind produktspezifisch. Die organisatorische Schlussfolgerung gilt darüber hinaus: Datenmigration ist ein eigener Arbeitsstrom mit fachlichen und technischen Verantwortungen.

„Alles übernehmen“ ist dabei keine neutrale Entscheidung. Jeder zusätzliche Datensatz erzeugt Mapping-, Test-, Speicher-, Schutz- und späteren Pflegeaufwand. „Nichts Altes übernehmen“ kann umgekehrt Betrieb, Auskunft oder Nachweisführung beeinträchtigen. Der Umfang muss aus Nutzung und Pflicht entstehen, nicht aus Bequemlichkeit.

Sieben Entscheidungen vor der technischen Migration

1. Datenobjekte und Geschäftszweck festlegen

Für jedes Datenobjekt wird beschrieben, wofür es im Zielsystem benötigt wird. Ein Kundenstamm dient beispielsweise nicht nur der Rechnungsadresse. Vertrieb, Logistik, Service und Buchhaltung können unterschiedliche Attribute und Qualitätsanforderungen besitzen.

Erst der Geschäftszweck beantwortet:

• welche Datensätze benötigt werden,
• welche Felder relevant sind,
• welche Aktualität erforderlich ist,
• welche Beziehungen erhalten bleiben müssen,
• welche Tests die Nutzbarkeit belegen.

Ohne diesen Zweck wird Vollständigkeit leicht mit Qualität verwechselt.

2. Künftige Definitionen und führende Quellen bestimmen

Wenn mehrere Systeme denselben Gegenstand beschreiben, benötigt das Zielmodell eine Regel. Welches System liefert welchen Wert? Wer darf ihn später ändern? Welche Quelle gilt bei einem Widerspruch?

Der ERP-Auswahlleitfaden fordert deshalb bereits vor der Produktauswahl Klarheit über führende Daten und Integrationen. In der Migration wird diese Entscheidung konkret. Ein Feldmapping ohne Datenhoheit beschreibt nur, wo ein Wert landet – nicht, warum er gelten soll.

Eine Definition sollte in der Sprache des Geschäfts formuliert werden. „Status = A“ hilft wenig. „Aktiver Kunde: besitzt mindestens einen laufenden Vertrag oder einen Auftrag innerhalb des festgelegten Zeitraums und ist nicht für weitere Geschäfte gesperrt“ ist prüfbarer. Der konkrete Zeitraum und die Regeln müssen das Unternehmen selbst entscheiden.

3. Daten-Owner und Entscheidungsrechte benennen

Der Daten-Owner verantwortet nicht jede einzelne Eingabe. Er entscheidet über Definition, Qualitätsregel, zulässige Ausnahme und fachliche Abnahme eines Datenobjekts.

Für die Migration werden mindestens benötigt:

• fachlicher Owner je Datenobjekt,
• operative Ansprechpartner für Bereinigung,
• technische Verantwortung für Extraktion, Transformation und Laden,
• Freigabeberechtigung für Regeln und Ausnahmen,
• Vertretung und Eskalationsweg.

Der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ zeigt, warum eine benannte Rolle ohne Entscheidungsrecht nicht genügt. Genau diese Lücke führt in Migrationen zu offenen Mappingfragen und verspäteten Freigaben.

4. Qualitätsregeln und Abnahmekriterien definieren

„Die Daten sollen sauber sein“ ist kein prüfbares Ziel. Benötigt werden Regeln je Datenobjekt und kritischem Attribut.

Mögliche Qualitätsdimensionen sind:

• Gültigkeit: Entspricht der Wert dem vereinbarten Format oder Wertebereich?
• Vollständigkeit: Sind alle für den Zielprozess benötigten Angaben vorhanden?
• Eindeutigkeit: Werden gleiche reale Objekte als Dubletten geführt?
• Konsistenz: Widersprechen sich Werte oder Beziehungen?
• Aktualität: Ist die Information für den vorgesehenen Zweck noch brauchbar?

ISO 8000-8:2015 beschreibt Grundkonzepte der Informations- und Datenqualität sowie Voraussetzungen ihrer Messung. Die Norm liefert keinen universellen Grenzwert für einen ERP-Go-live. Die Organisation muss selbst festlegen, welche Mängel für welchen Prozess akzeptabel sind.

Ein Abnahmekriterium kann daher lauten: Alle aktiven Lieferanten besitzen eine gültige Zahlungsbedingung; Datensätze ohne eindeutige Zuordnung werden nicht automatisch übernommen, sondern in einer Ausnahmeliste entschieden. Die konkrete Regel hängt vom Zielprozess ab.

5. Bereinigung und Transformation trennen

Bereinigung korrigiert die fachliche Qualität in der Quelle oder in einem verantworteten Zwischenbestand. Transformation übersetzt Daten in Struktur und Werte des Zielsystems.

Beispiele:

• Eine ungültige Postleitzahl zu korrigieren ist Bereinigung.
• Ein Datumsformat umzuwandeln ist Transformation.
• Zwei bestätigte Dubletten zusammenzuführen ist Bereinigung mit fachlicher Entscheidung.
• Einen alten Statuswert auf einen neuen Zielstatus abzubilden ist Transformation auf Basis einer vorher freigegebenen Regel.

Diese Trennung macht sichtbar, welche Entscheidungen dauerhaft in den Quellprozessen behoben werden müssen. Sonst korrigiert das Projekt die Daten einmalig, während die Organisation bis zum Cutover weiterhin neue Fehler produziert.

Das Government Data Quality Framework behandelt Datenqualität als organisationsweite Aufgabe, einschließlich Ownership, Metadaten, Ursachenanalyse und laufender Pflege. Für ein ERP-Projekt folgt daraus: Eine technische Migration kann eine Qualitätsinitiative auslösen, sie kann deren dauerhafte Verantwortung aber nicht übernehmen.

6. Wiederholbare Probeläufe und Abstimmung planen

Ein erfolgreicher Import beweist zunächst nur, dass Daten technisch geladen wurden. Eine fachliche Probe muss zeigen, dass die Zielprozesse mit ihnen funktionieren.

Ein belastbarer Probelauf umfasst:

1. festgelegten Datenstand und dokumentierte Extraktion,
2. versionierte Mapping- und Transformationsregeln,
3. Fehlerprotokoll mit Verantwortlichen,
4. Mengen- und Summenabgleich zwischen Quelle und Ziel,
5. Prüfung kritischer Beziehungen,
6. fachliche Tests repräsentativer Geschäftsvorgänge,
7. dokumentierte Abweichungen und Entscheidungen,
8. erneuten Lauf nach Korrektur.

Die Abnahme betrachtet nicht nur Datensatzanzahlen. Hundert Prozent geladene Kunden helfen wenig, wenn offene Aufträge nicht auf den richtigen Rechnungsempfänger zeigen.

7. Cutover, Delta und Rückfall festlegen

Zwischen letztem Probelauf und Go-live ändern sich die Quelldaten weiter. Deshalb benötigt das Projekt eine klare Cutover-Regel:

• Wann wird welche Quelle eingefroren?
• Welche Änderungen werden als Delta nachgezogen?
• Wer prüft die letzte Abstimmung?
• Ab wann arbeitet der Fachbereich nur noch im Zielsystem?
• Welche Kriterien führen zum Abbruch?
• Wie wird bei einem fehlgeschlagenen Cutover zurückgefallen?
• Wie bleiben nicht migrierte historische Daten zugänglich?

Der Rückfall darf nicht erst in der Go-live-Nacht diskutiert werden. Wenn Daten im Ziel bereits verändert wurden, kann eine Rückkehr komplizierter sein als das Zurücksetzen einer Anwendung.

Konstruiertes Beispiel: Zwei Kundenlisten, keine gemeinsame Wahrheit

Das folgende Beispiel ist konstruiert.

Vertrieb und Buchhaltung liefern jeweils eine Kundenliste. Gleiche Unternehmen besitzen unterschiedliche Nummern, Schreibweisen, Zahlungsbedingungen und Statuswerte. In der Vertriebsliste gilt ein Kunde mit laufender Verkaufschance als aktiv. In der Buchhaltung ist aktiv, wer offene Posten oder aktuelle Buchungen besitzt.

Ein technisches Mapping kann Spalten zusammenführen und ähnliche Namen markieren. Es kann aber nicht entscheiden, ob die Datensätze fachlich identisch sind, welche Zahlungsbedingung gilt und welche Definition im neuen ERP verwendet werden soll.

Das Projekt richtet deshalb vor der nächsten Testmigration einen fachlichen Owner für das Datenobjekt Kunde ein. Vertrieb und Buchhaltung vereinbaren eine gemeinsame Zieldefinition, Regeln für Dubletten und eine Liste strittiger Fälle. Erst danach werden die Transformationsregeln angepasst.

Das Beispiel zeigt keinen garantierten Projekterfolg. Es zeigt die richtige Reihenfolge: Fachliche Entscheidung vor automatisierter Übernahme.

Bekannte Mängel dürfen bewusst übernommen werden

Eine vollständige Bereinigung aller historischen Daten kann unverhältnismäßig sein. Bestimmte Lücken haben für den künftigen Prozess möglicherweise keine relevante Wirkung. Dann ist eine bewusste Übernahme zulässig, wenn:

• der Mangel beschrieben und quantifiziert ist,
• die betroffenen Prozesse und Auswertungen bekannt sind,
• ein Owner die Ausnahme freigibt,
• Nutzer die Einschränkung verstehen,
• eine Nachbearbeitung oder dauerhafte Akzeptanz entschieden ist.

Das ist etwas anderes als ein unbemerkter Fehler. Transparente Restmängel ermöglichen Priorisierung; unbekannte Restmängel werden erst im Betrieb zu Überraschungen.

Eine harte Abbruchbedingung liegt vor, wenn kritische Prozesse, Bestände, offene Posten oder gesetzlich beziehungsweise vertraglich notwendige Informationen nicht verlässlich abgestimmt werden können. Welche Daten diese Schwelle erreichen, muss die Organisation mit ihren fachlich zuständigen Stellen bestimmen.

Ein Datenobjekt-Steckbrief

Für jedes wesentliche Datenobjekt kann ein kompakter Steckbrief verwendet werden:

Feld	Inhalt
Datenobjekt	Kunde, Lieferant, Artikel, Konto oder anderes fachliches Objekt
Geschäftszweck	Prozesse und Entscheidungen, die davon abhängen
fachlicher Owner	Rolle mit Entscheidungs- und Abnahmerecht
Quellen	Systeme, Dateien und verantwortliche Stellen
Zieldefinition	fachliche Bedeutung im neuen System
Umfang	aktive, offene, historische und ausgeschlossene Datensätze
Qualitätsregeln	Gültigkeit, Vollständigkeit, Eindeutigkeit, Konsistenz und Aktualität
Mapping	freigegebene Quell-Ziel-Zuordnung und Transformation
Ausnahmen	bekannte Mängel, Freigabe und Nachbearbeitung
Abnahme	fachliche Testfälle, Mengen, Summen und Beziehungen
Cutover	Freeze, Delta, Freigabe und Rückfall

Dieser Steckbrief ist kein Ersatz für technische Mappings. Er stellt sicher, dass deren Regeln aus nachvollziehbaren fachlichen Entscheidungen entstehen.

Datenqualität endet nicht mit dem Go-live

Wenn Prozesse und Verantwortung unverändert bleiben, erzeugt das neue ERP nach kurzer Zeit dieselben Qualitätsprobleme. Deshalb sollte jede zentrale Qualitätsregel in den späteren Betrieb überführt werden:

• Pflicht und Plausibilitätsprüfung bei der Erfassung,
• eindeutige Rolle für Freigabe und Korrektur,
• kontrollierte Schnittstellen statt paralleler Schattenlisten,
• regelmäßige Qualitätsauswertung,
• sichtbarer Fehler- und Eskalationsprozess,
• Änderung der Definition nur mit dokumentierter Wirkung.

Der Leitfaden zur Prozessprüfung vor Digitalisierung hilft dabei, Ergebnis, Datenquelle und Verantwortung des zugrunde liegenden Ablaufs zu klären. Denn Datenqualität ist selten nur eine Eigenschaft der Datenbank. Sie ist das Ergebnis der Prozesse, in denen Informationen entstehen und verändert werden.

Der erste sinnvolle Schritt ist eine Datenobjekt-Liste, keine Bereinigungsaktion. Wählen Sie die fünf Objekte, ohne die der erste produktive Prozess nicht funktioniert. Für jedes werden Definition, Owner, Quelle, Qualitätsregel und Abnahme festgelegt. Erst dann lässt sich seriös entscheiden, welche technische Migration vorbereitet werden muss.