Datenvalidierung bedeutet, nach einem Datenlauf zu prüfen, ob die vereinbarten Daten vollständig, richtig und im neuen ERP-System tatsächlich nutzbar angekommen sind. Sie beantwortet also nicht nur, ob der Import technisch funktioniert hat, sondern auch, ob das Ergebnis den vorgesehenen Geschäftsprozess und den nächsten Projektschritt trägt.
„Import erfolgreich“ ist ein technischer Status. „Datenbestand freigegeben“ ist dagegen eine Projektentscheidung. Zwischen beiden Aussagen liegt die Datenvalidierung: Sie muss aus dem technischen Ergebnis einen nachvollziehbaren fachlichen Nachweis machen.
Ein grünes Importprotokoll beantwortet dafür nur einen Teil der Fragen. Es zeigt beispielsweise, welche Datensätze das Zielsystem technisch angenommen oder abgewiesen hat. Nicht geladene Quelldaten, fachlich falsch übersetzte Codes oder fehlende Beziehungen kann das Importwerkzeug jedoch nur erkennen, wenn entsprechende Regeln im System vorhanden sind und der betreffende Datensatz überhaupt beim Import ankommt.
Eine belastbare Datenvalidierung verbindet deshalb Quelle, Export, Zielsystem und fachliche Nutzung zu einer durchgängigen Beweiskette. Vor der Abnahme muss nachvollziehbar sein, welcher Datenstand geprüft wurde, welche Kriterien galten, welche Abweichungen bestehen und wofür das Ergebnis freigegeben wird.
Vor der Prüfung muss feststehen, was der Datenlauf beweisen soll
Validierung beginnt nicht nach dem Import mit einer möglichst langen Prüfliste. Sie beginnt vor dem Lauf mit einer präzisen Aussage. Soll ein früher Test nur zeigen, dass eine Datei technisch geladen werden kann? Soll er die Transformationsregeln eines Datenobjekts prüfen? Oder soll das Ergebnis bereits für einen fachlichen Prozess- oder Cutover-Test freigegeben werden?
Je größer die beabsichtigte Entscheidung, desto breiter muss der Nachweis sein. Für einen rein technischen Probelauf können Dateiformat, Pflichtfelder und Ladefehler ausreichen. Eine fachliche Abnahme verlangt zusätzlich, dass vereinbarte Mengen, Bedeutungen, Beziehungen und Geschäftsvorgänge geprüft wurden.
Vor jedem Lauf sollten daher mindestens diese Angaben feststehen:
- das geprüfte Datenobjekt und die eingeschlossenen Datensätze,
- der eindeutig bezeichnete Quelldatenstand,
- die Version der Mapping- und Transformationsregeln,
- die verwendete Zielumgebung und Zielkonfiguration,
- die erwarteten Prüfergebnisse sowie
- die Entscheidung, die nach dem Lauf getroffen werden soll.
Fehlt diese Grundlage, lässt sich ein späterer Befund kaum einordnen. Dann bleibt offen, ob eine Abweichung aus den Quelldaten, einer Transformationsregel, dem Import, der Zielkonfiguration oder einer geänderten fachlichen Erwartung stammt.
Datenvalidierung braucht vier unterschiedliche Nachweise
In ERP-Projekten hilft es, die Prüfung in vier Nachweisarten zu trennen. Sie sind keine vorgeschriebenen Testphasen. Ein Datenlauf kann mehrere davon gleichzeitig liefern. Die Trennung verhindert jedoch, dass ein technischer Erfolg versehentlich als vollständige fachliche Abnahme behandelt wird.
| Nachweis | Zentrale Frage | Geeignete Prüfungen |
|---|---|---|
| Vollständigkeit | Ist genau der vereinbarte Datenbestand angekommen? | Mengenvergleich zwischen Quelle, Export und Ziel; dokumentierte Filter und Ausschlüsse; Kontrolle fehlender oder doppelter Schlüssel |
| Technische Gültigkeit | Entsprechen Struktur und Werte den technischen Zielregeln? | Pflichtfelder, Datentypen, Feldlängen, erlaubte Werte, Importmeldungen und technische Referenzen |
| Fachliche Richtigkeit | Wurden Bedeutung, Werte und Zusammenhänge richtig übersetzt? | Wertemappings, Summenabgleiche, Beziehungen, Standardwerte, gezielte Stichproben und fachliche Plausibilitäten |
| Prozessnutzbarkeit | Funktionieren die vorgesehenen Abläufe mit den migrierten Daten? | Ausgewählte Geschäftsvorgänge, rollenbezogene Fachtests und dokumentierte Rückmeldung der verantwortlichen Keyuser |
Die vier Nachweise bauen aufeinander auf. Ein fachlich plausibler Einzelbeleg ersetzt keinen Mengenabgleich. Umgekehrt beweist eine korrekte Datensatzanzahl nicht, dass Werte richtig zugeordnet oder Beziehungen vollständig sind. Erst die zum Testziel passende Kombination trägt die Freigabe.
Ein Mengenabgleich ist nur mit derselben Grundgesamtheit aussagekräftig
Datensatzanzahlen gehören zu den schnellsten und nützlichsten Prüfungen. Sie werden aber leicht falsch interpretiert. Wenn im Quellsystem alle Kunden gezählt werden, der Export jedoch bewusst nur aktive Kunden einer bestimmten Gesellschaft enthält, dürfen beide Zahlen nicht übereinstimmen.
Vor dem Vergleich muss deshalb dieselbe Grundgesamtheit beschrieben sein: Welche Gesellschaften, Standorte, Stichtage, Statuswerte und Ausschlussregeln gelten? Wurden Dubletten zusammengeführt? Sind technische Hilfsdatensätze enthalten? Gibt es Datensätze, die bewusst archiviert statt migriert werden?
Ein belastbarer Abgleich zeigt nicht nur eine Quell- und eine Zielzahl. Er macht auch die Rechenbrücke sichtbar:
relevante Quelldatensätze – dokumentierte Ausschlüsse – zusammengeführte Dubletten + bewusst ergänzte Datensätze = erwartete Zielmenge.
Die konkrete Formel hängt vom Datenobjekt ab. Entscheidend ist, dass Differenzen erklärt werden können. Eine identische Anzahl kann falsch sein, wenn unerwünschte Datensätze geladen wurden. Eine abweichende Anzahl kann richtig sein, wenn Auswahl- und Bereinigungsregeln nachvollziehbar angewendet wurden.
Werte und Beziehungen brauchen andere Prüfungen als Datensatzmengen
Viele Migrationsfehler entstehen nicht am einzelnen Feld, sondern im Zusammenhang der Daten. Ein Kunde kann technisch vorhanden sein, während eine zugehörige Adresse, Rolle oder Zuordnung fehlt. Ein Material kann einen gültigen Einheitenwert besitzen, der fachlich dennoch falsch übersetzt wurde. Ein Standardwert kann die Pflichtfeldprüfung bestehen und gleichzeitig eine ungeklärte Entscheidung verdecken.
Deshalb sollte die Validierung je Datenobjekt festlegen, welche Zusammenhänge kritisch sind. Je nach Inhalt können dazu gehören:
- Beziehungen zwischen Haupt- und Unterobjekten,
- Referenzen auf gültige Stamm- oder Steuerungswerte,
- vollständige und eindeutige Schlüssel,
- Summen oder Salden vor und nach der Transformation,
- Werte, die durch Mapping-Regeln umgeschlüsselt wurden, sowie
- bewusst gesetzte Standardwerte und ihre fachliche Zulässigkeit.
SQL-Abfragen können viele dieser Prüfungen reproduzierbar ausführen: Sie vergleichen Mengen, suchen leere Pflichtfelder, zeigen nicht gemappte Werte, doppelte Schlüssel oder fehlende Referenzen. Die technische Prüfung ersetzt jedoch nicht die fachliche Beurteilung. Ob eine Zuordnung im Geschäftsprozess richtig ist, muss eine Person entscheiden, die die fachliche Bedeutung und den vorgesehenen Zielprozess kennt.
Stichproben sollten die riskanten Regeln treffen
Eine zufällige Stichprobe kann offensichtliche Fehler zeigen, trifft aber nicht automatisch die kritischen Transformationen. Aussagekräftiger wird sie, wenn das Projekt bewusst Datensätze auswählt, an denen sich die anspruchsvollen Regeln erkennen lassen.
Dazu zählen beispielsweise Datensätze mit umgeschlüsselten Werten, zusammengeführten Feldern, mehreren Unterobjekten, seltenen Ausprägungen, Grenzwerten oder zuvor gefundenen Fehlern. Ergänzend braucht es gewöhnliche Datensätze, damit die Prüfung nicht ausschließlich Sonderfälle betrachtet.
Die Stichprobe erhält dadurch eine klare Aufgabe: Sie soll eine benannte Regel oder fachliche Annahme prüfen. Ihr Ergebnis wird zusammen mit Datenstand, Regelversion und erwartetem Verhalten dokumentiert. So lässt sich die Prüfung nach einer Korrektur gezielt wiederholen, ohne jedes Mal eine neue Auswahl aus dem Bauchgefühl zu treffen.
Ein Befund muss zur verursachenden Regel zurückführen
Eine Fehlerliste verbessert die Migration erst, wenn jeder relevante Befund auf eine Ursache und eine Korrektur zurückgeführt wird. Wird lediglich die aktuelle Exportdatei von Hand repariert, kann der nächste Lauf denselben Fehler erneut erzeugen.
Ein belastbarer Validierungszyklus verbindet deshalb:
Eingabestand → Prüfergebnis → Abweichung → Ursache → Entscheidung → Regeländerung → erneute Prüfung.
Die Ursache kann in der Quelle, der Auswahlregel, dem Mapping, dem Transformationsskript, der Importlogik oder der Zielkonfiguration liegen. Sie kann auch eine bislang offene fachliche Frage sein. Diese Unterscheidung entscheidet darüber, wer den Befund bearbeiten muss und welche Bereiche nach der Änderung erneut getestet werden.
Wenn eine Datenmigration bereits festgefahren ist, zeigt der Beitrag ERP-Datenmigration fehlgeschlagen, wie sich Fehler nach Ursache ordnen und der nächste Lauf neu aufsetzen lässt.
Eine Freigabe gilt für einen Datenstand und einen nächsten Schritt
Fachliche Freigabe bedeutet nicht, dass ein Datenbestand perfekt oder für alle späteren Zwecke geprüft ist. Sie bedeutet, dass eine benannte verantwortliche Person anhand vorher vereinbarter Kriterien entscheidet: Dieses Ergebnis reicht unter den dokumentierten Bedingungen für den festgelegten nächsten Schritt aus.
Dieser nächste Schritt kann eine größere Testmigration, ein Integrationstest, eine Cutover-Generalprobe oder später der produktive Lauf sein. Entsprechend unterscheiden sich die erforderlichen Nachweise. Ein Datenobjekt kann beispielsweise für einen begrenzten Prozesstest freigegeben sein, obwohl bekannte Sonderfälle noch vor dem Go-live korrigiert werden müssen.
Eine belastbare Freigabe hält daher fest:
- welcher Datenstand und welche Regelversion geprüft wurden,
- welche Kriterien erfüllt sind,
- welche Abweichungen noch offen bleiben,
- welches Risiko daraus entsteht und wer darüber entschieden hat sowie
- für welchen konkreten nächsten Schritt die Freigabe gilt.
Die Frage nach weiteren Läufen wird dadurch ebenfalls präziser. Der Beitrag Wie viele Testmigrationen sind sinnvoll? ordnet die Entscheidung danach, welcher Nachweis noch fehlt und ob ein vollständiger Lauf oder ein gezielter Nachtest erforderlich ist.
Welche Unterlagen vor der Abnahme vorliegen sollten
Für die ERP-Projektleitung muss der Validierungsstand ohne Rekonstruktion aus E-Mails, Importprotokollen und verschiedenen Excel-Dateien erkennbar sein. Dafür braucht es kein schwergewichtiges Berichtswesen. Ein schlankes, aber verbundenes Paket genügt:
- Prüfumfang: Datenobjekt, Grundgesamtheit, Datenstand, Regelversion und Zielumgebung.
- Prüfkriterien: erwartete Mengen, kritische Werte und Beziehungen, fachliche Stichproben sowie relevante Prozessfälle.
- Ergebnisse: automatisierte Auswertungen, fachliche Rückmeldungen und eindeutiger Status je Kriterium.
- Abweichungen: Ursache, Auswirkung, Verantwortlicher, beschlossene Korrektur und geplanter Nachtest.
- Freigabe: verantwortliche Person, freigegebener nächster Schritt, bekannte Einschränkungen und Datum.
Diese Unterlagen sollten bereits im Datenmigrationskonzept als Vorgehen vorgesehen sein. Für den Go-live werden sie anschließend zu Eingaben des ERP-Cutover-Plans: Dort müssen Prüffenster, Verantwortliche und Go-/No-go-Kriterien in den ausführbaren Ablauf passen.
Externe Unterstützung ist sinnvoll, wenn die Beweiskette zwischen den Rollen zerfällt
In vielen Projekten liegen die notwendigen Informationen bereits vor, aber getrennt: Die IT kennt Quellmengen und Exporte, der ERP-Partner sieht Importmeldungen und Zielregeln, die Keyuser beurteilen fachliche Nutzbarkeit und die Projektleitung muss daraus eine Entscheidung ableiten. Wenn niemand diese Teile zusammenführt, bleibt der Status trotz vieler Prüfaktivitäten unscharf.
Wir können die technische Validierung vorbereiten, reproduzierbare Prüfungen aufbauen, Befunde den zugrunde liegenden Regeln zuordnen und die fachliche Rückmeldung strukturiert in den nächsten Lauf überführen. Die fachliche Freigabe und die Entscheidung über verbleibende Projektrisiken bleiben beim Kunden.
Eine belastbare Datenvalidierung endet deshalb nicht mit möglichst vielen grünen Haken. Sie endet mit einer nachvollziehbaren Aussage darüber, was geprüft wurde, welche Abweichungen verstanden sind und welche Entscheidung dieses Ergebnis tatsächlich trägt.