Datenqualität in der S/4HANA-Migration: Warum Datenvalidierung ein wiederkehrender Prozess sein muss

S/4HANA-Programme starten meist mit einer Grundsatzentscheidung zur Vorgehensweise: Brownfield, Bluefield oder Greenfield, je nach Ansatz werden System, Prozesse und Datenmigration unterschiedlich umgesetzt. Im Projektverlauf wird der Fortschritt dann häufig über technische Meilensteine gesteuert und (mindestens) bis zum Cutover verfolgt.

In der Praxis zeigt sich dabei, dass der entscheidende Erfolgsfaktor im Bereich der Datenmigration nicht die reine Datenübertragung ist, sondern speziell die fachliche Belastbarkeit, Vollständigkeit und Richtigkeit der Daten gesichert werden muss. Genau diese Aspekte erfordern eine systematische Prüf- und Qualitätssicherung, denn ein technisch stabiler Go-Live bedeutet noch lange nicht, dass Finance, Controlling oder operative Fachbereiche dem System vertrauen und damit arbeiten können.

Vielmehr muss gewährleistet sein, dass Salden, Bestände, offene Posten und Bewegungsdaten nachvollziehbar und korrekt sind. Nur so wird S/4HANA tatsächlich business-ready, Prozesse laufen stabil, Abschlüsse sind nachvollziehbar und Prüfungen durch Audit oder Wirtschaftsprüfung werden nicht zum Risiko. Qualitativ korrekte Daten sind zudem die Grundlage, damit nachgelagerte Tätigkeiten in Reporting und Planung funktionieren.

Datenqualität ist die entscheidende Voraussetzung, damit die Daten im digitalen Kern von S/4HANA als belastbare Steuerungs- und Entscheidungsgrundlage dienen.

Genau deshalb muss Datenqualität während der Migration als ein kontinuierlicher Validierungs- und Optimierungsprozess verstanden werden, nicht als punktuelle Prüfung kurz vor oder mit dem Cutover.

Besonders sichtbar wird diese Herausforderung im Finance-Bereich, etwa im Übergang von klassischen ECC-Strukturen (im Umfeld von BKPF/BSEG) zum Universal Journal (ACDOCA). Die zugrunde liegende Logik gilt ebenso für Logistik, Stammdaten und alle im S/4HANA relevanten End-to-End-Prozesse.

Migration ist kein Event, sondern ein Prozess

Viele Projekte behandeln Datenqualität allerdings wie einen einzelnen Meilenstein:

  • Einmalige Datenqualitätsprüfung zum Mock bzw. Dry-Run
  • Eine weitere Datenqualitätsprüfung mit Cutover bzw. Go Live

Das ist zu kurz gedacht.

Eine erfolgreiche Datenmigration braucht ein Umdenken, weg vom punktuellen Abgleich hin zu einem kontinuierlichen Validierungsprozess.

Das bedeutet konkret:

  • kontinuierliches Data Cleansing im Altsystem, vorbereitend zur späteren Datenmigration
  • Nachverfolgung und wachsendes Regelwerk bei Datentransformationen (etwa Zusammenführungen von Stammdatenobjekten, Sachkontenwechseln)
  • laufender Abgleich zwischen Quell- und Zielsystem bei schrittweisen Datenmigrationen.

Das schafft zwei Effekte:

  • strukturelle Datenprobleme werden frühzeitig identifiziert
  • der Druck in kritischen Phasen wie Mocks und Cutover sinkt

Schon bei einem Big-Bang-Ansatz (alle Buchungskreise und Prozesse zu einem Zeitpunkt) ist ein belastbarer Datenqualitätsabgleich anspruchsvoll. Bei sequenziellen Transitionen (Rollout je Buchungskreis oder Prozess) gilt das umso mehr.

Wer Datenqualität also laufend steuert, gewinnt Planbarkeit und reduziert Projektrisiken deutlich.

Zwei Entscheidungen, die über Go-Live-Stabilität entscheiden

In fast jedem Migrationsprojekt sind die Komplexitätstreiber auf zwei wesentliche Fragenstellungen zurückzuführen:

1. Welche Daten sollten überhaupt migriert werden?

Nicht alle in der Ausgangslandschaft vorhandenen Daten sollten identisch in die neue Umgebung übernommen werden. Mit der Migration bietet sich vielmehr die Möglichkeit historisch gewachsene Redundanzen (etwa dublette Geschäftspartner, Materialstämme), unnötige Altdokumente (etwa lange offene Kundenaufträge) oder gewachsene Sonderlogiken (eigene Auswertetabellen/ Hilfstabellen) bewusst nicht zu übernehmen. Eine Bereinigung verbessert die Datenqualität, erhöht aber auch die Anforderungen an die Validierung, weil die verbundenen Transformationen den direkten Alt/Neu-Abgleich erschweren.

2. Wie belegen wir fachlich, dass die Migration korrekt ist?

Technisch erfolgreich heißt nicht automatisch fachlich korrekt.

Salden, Bestände, offene Posten oder Bewegungen bzw. zentrale Steuerungsobjekte (wie etwa Steuerkennzeichen, Zahlungsbedingungen) müssen im Zielsystem stimmen, da ansonsten der Startpunkt des neuen Systems inhaltlich falsch ist, mit negativen betrieblichen und rechtlichen Konsequenzen (Geschäftsausfälle, fehlerhafte Abschlüsse).

Genau hier entsteht in vielen Projekten die größte Unsicherheit: Der Alt/Neu-Abgleich wird zu spät, zu manuell oder nicht reproduzierbar durchgeführt.

Warum Excel-Validierung & Co im S/4HANA-Kontext nicht mehr funktioniert

Validierungen erfolgen in vielen Projekten noch über Behelfslösungen wie:

  • Excel-Abgleiche
  • individuelle Queries
  • isolierte Listen
  • Stichprobenprüfungen

oder auch unter Zuhilfenahme des S/4HANA Migration Cockpits. Diese Ansätze funktionieren in kleinen Ausschnitten, skalieren aber nicht im S/4HANA-Umfeld, weil sie meist nur für einmalige Cutover-Prüfungen ausgelegt sind.

Die Herausforderungen sind klar:

  • stark gestiegenes Datenvolumen
  • struktureller Wandel des Datenmodells
  • hohe Integrationsdichte zwischen Finance und Logistik
  • fehlende Versionierung und Nachvollziehbarkeit
  • eingeschränkte Auditierbarkeit

Die Verfahren erzeugen oft eine trügerische Sicherheit, weil nur Stichproben geprüft werden und systematische Fehler unentdeckt bleiben.

Toolgestützte, regelbasierte Validierung ist deshalb keine Kür, sondern Mindestvoraussetzung.

Finance als stärkstes Beispiel: Universal Journal statt Objektprüfung

Am deutlichsten wird diese Herausforderung im Finance-Bereich, insbesondere durch das Universal Journal.

Mit dem Universal Journal (ACDOCA) verschmelzen FI und CO in einem zentralen Datenmodell. Validierung darf sich deshalb nicht auf Einzelobjekte beschränken, sondern muss den finanziellen Gesamtkontext abbilden:

  • Konsistenz zwischen FI- und CO-Belegen
  • Ledger- und Währungskonsistenz
  • Profit-Center- und Segmentlogiken
  • Integration von Anlagen- und Materialbewertungen
  • Beziehungen zwischen Stammdaten und Bewegungsdaten

Die gleiche Logik gilt aber auch in anderen Domänen: Materialbewertung, Bestandsführung oder Geschäftspartner sind genauso kritisch für die fachliche Abnahme.

Frühzeitige Data Quality Checks: Was geprüft werden muss

Data Quality Checks sollten nicht erst im Zuge der technischen Migration starten, sondern bereits zu Projektbeginn. Zunächst wird der bestehende Datenbestand gesichtet, anschließend bestenfalls in der Altumgebung optimiert und schließlich im Zuge der Datenmigration sauber und geprüft in die neue Umgebung übernommen. Typische Prüfungsbereiche sind dabei:

Stammdaten

  • Sachkonten, Kostenstellen, Profit Center
  • Anlagen, Geschäftspartner
  • Materialien, Werke, Kunden- und Lieferantenstrukturen

Bewegungsdaten

  • FI- und CO-Belege, offene Posten
  • Bestände, Materialbewegungen
  • Ergebnisobjekte und Bewertungslogiken

Struktur und Customizing

  • Kontenpläne, Ledger-Strukturen
  • Währungslogiken
  • Reporting- und Segmentstrukturen

Ziel ist Transparenz: Wo liegen Datenrisiken, bevor sie zum Cutover-Problem werden?

Und zusätzlich sollte auch nach der erfolgten Datenmigration die Datenqualität weiter überwacht und gesteuert werden, denn wer möchte nach einem Jahr S/4HANA-Betrieb schon den gleichen Datendschungel wie zuvor wiederfinden?

Wie Q-THOR Validierung operationalisiert

An diesem Punkt braucht es ein Werkzeug, das Datenqualität reproduzierbar macht und zusätzlich die Funktion dazu in die Hände der Business-Anwender legt:

Q-THOR hilft, Validierung aus Excel-Stichproben herauszuführen und als regelbasierten, wiederholbaren Prozess, datenbankorientiert direkt in der Systemumgebung aufzusetzen:

  • regelbasierte Datenqualitätschecks entlang der Migration
  • wiederholbare Prüfungen über Mock-Zyklen hinweg
  • fachbereichsnaher Self-Service statt reiner IT-Prüfdisziplin
  • dokumentierte Regelwerke und nachvollziehbare Historisierung

Durch die wiederholbare Ausführung einmal definierter Checks kann das Regelwerk mit Q-THOR auch nach der Migration weiter genutzt werden. Die Investition in Datenqualität wirkt damit über das Projekt hinaus.

Datenqualität als Governance- und Management-Thema

Allerdings entsteht Datenqualität nicht allein durch Tools. Es braucht klare Prozesse, Rollen und Verantwortlichkeiten.

  • Wer definiert die Validierungsregeln?
  • Wer überwacht Findings und sorgt für Korrekturen?
  • Wer trägt Data Ownership je Objektbereich?
  • Wie erfolgt Eskalation vor Go-Live?

Erfolgreiche Projekte steuern Datenqualität zudem über KPIs:

  • Anteil valider Stammdaten
  • kritische Findings pro Mock-Zyklus
  • Durchlaufzeiten zur Fehlerbehebung
  • Trendanalysen über die Projektlaufzeit

Klare Governance macht Datenqualität nachvollziehbar, messbar und damit managementfähig.

Fazit: Kontinuierliche Validierung statt punktueller Tests

Datenmigration ist kein technisches Teilprojekt, sondern ein zentrales Thema für Abnahme, Inbetriebnahme und stabilen Betrieb im Rahmen der S/4HANA-Migration.

Wer Datenqualität früh und kontinuierlich absichert, reduziert Go-Live-Risiken, erhöht die Planbarkeit und schafft die Grundlage für stabile Prozesse und Analytics im neuen S/4HANA-Kern.

Die entscheidende Frage lautet nicht: Wie migrieren wir?

Sondern: Welche Daten migrieren wir, und wie belegen wir fachlich, dass sie korrekt angekommen sind und korrekt bleiben?

Autor: Tobias Schulz

Datenqualität frühzeitig richtig aufsetzen

Sie möchten Datenvalidierung in Ihrer S/4HANA-Migration nicht dem Zufall überlassen? Sprechen Sie mit unseren Expert:innen darüber, wie kontinuierliche Validierung Risiken reduziert und Abschlüsse stabilisiert.

Jetzt Kontakt aufnehmen

Weitere spannende Themen aus unserem Newsroom

S/4HANA System Conversion

Der Artikel erklärt, wie sich Business-Downtime bei einer SAP S/4HANA...

Mehr lesen

ABAP unter S/4HANA ist alt?

Der Artikel zeigt, wie modernes ABAP unter S/4HANA sein volles...

Mehr lesen

SAP S/4HANA Modifikationen neu gedacht: Clean Core, Side-by-Side-Extensions und KI

Der Artikel erklärt, wie SAP-S/4HANA-Modifikationen mit dem Clean-Core-Ansatz neu gedacht...

Mehr lesen