Leitfaden zum S/4HANA Datenmapping in 7 Schritten

Ein fehlendes Werk im Geschäftsbereich, eine unklare Umrechnungseinheit oder ein nicht abgestimmter Debitor können einen S/4HANA-Cutover erheblich verzögern. Der Leitfaden zum S/4HANA Datenmapping setzt deshalb nicht bei technischen Tabellen an, sondern bei der Frage, welche Daten im Zielsystem fachlich gültig, vollständig und nachweisbar sein müssen. Datenmapping ist keine vorbereitende Dokumentationsaufgabe. Es ist ein zentraler Steuerungsmechanismus für Migration, Integration, Tests und den stabilen Betrieb.

Warum S/4HANA Datenmapping über den Go-Live entscheidet

Beim Wechsel auf S/4HANA werden Daten selten nur von einem System in ein anderes übertragen. Häufig treffen historisch gewachsene ERP-Strukturen, Vorsysteme, Schnittstellen, Stammdatenverantwortung und neue S/4HANA-Prozesse aufeinander. Die eigentliche Herausforderung besteht darin, die fachliche Bedeutung eines Quellwerts eindeutig in die Logik des Zielsystems zu überführen.

Ein Mapping beantwortet daher mehr als die Frage, welches Feld auf welches Feld geschrieben wird. Es definiert, ob ein Wert übernommen, transformiert, neu abgeleitet, verworfen oder manuell geklärt wird. Bei Geschäftspartnern, Materialstämmen, Finanzdaten und Organisationsstrukturen sind diese Entscheidungen unmittelbar geschäftskritisch. Fehler werden oft erst sichtbar, wenn Buchungen nicht verarbeitet werden können, offene Posten falsch zugeordnet sind oder Reporting-Zahlen nicht mehr abstimmbar erscheinen.

Ein gutes Datenmapping schafft belastbare Daten für drei Zeitpunkte zugleich: für die fachliche Freigabe vor der Migration, für den technischen Migrationslauf und für die Abstimmung nach Produktivsetzung. Das reduziert nicht nur Nacharbeit, sondern schafft auch eine nachvollziehbare Grundlage für revisionssicheres Reporting.

Die sieben Schritte für belastbares S/4HANA Datenmapping

1. Datenobjekte nach Risiko und Geschäftswirkung priorisieren

Nicht jedes Datenobjekt benötigt zu Beginn dieselbe Detailtiefe. Ein Projekt sollte zuerst die Objekte identifizieren, deren Fehler den Betrieb, den Abschluss oder regulatorische Nachweise gefährden. Dazu gehören typischerweise Geschäftspartner, Kunden- und Lieferantendaten, Materialstämme, Kontenpläne, offene Posten, Anlagen, Konditionen sowie zentrale Organisationsdaten.

Die Priorisierung muss sich am Migrationsansatz orientieren. Bei einer selektiven Datenmigration ist die Frage entscheidend, welche historischen Daten tatsächlich mitgeführt werden. Bei einer Systemkonvertierung können vorhandene Datenstrukturen erhalten bleiben, dennoch müssen S/4HANA-relevante Vereinfachungen und neue Datenmodelle geprüft werden. Wer alle Datenobjekte gleichzeitig in gleicher Tiefe bearbeitet, erzeugt früh viel Dokumentation, aber wenig Steuerbarkeit.

2. Eine eindeutige Datenbasis und führende Quellen festlegen

Vor dem ersten Feldmapping muss klar sein, welches System für welches Attribut führend ist. In der Praxis liegen Adressdaten, Zahlungsinformationen, Klassifikationen oder Vertriebsattribute oft in mehreren Anwendungen. Ohne eine verbindliche Entscheidung entstehen widersprüchliche Mappings und wiederholte Bereinigungszyklen.

Für jedes kritische Attribut sollte dokumentiert werden, ob die Quelle verbindlich ist, nach welchen Regeln der Wert übernommen wird und wer Abweichungen entscheidet. Ein vermeintlich gleicher Wert kann unterschiedliche fachliche Bedeutungen haben. Die Kennzeichnung eines Kunden im CRM ist beispielsweise nicht automatisch mit einer Debitorenrolle im ERP gleichzusetzen.

Besondere Aufmerksamkeit erfordert die Umstellung auf den Geschäftspartner. Die Zusammenführung von Kunden- und Lieferanteninformationen betrifft nicht nur Stammdatenfelder, sondern auch Rollen, Nummernkreise, Dublettenlogik und nachgelagerte Schnittstellen. Hier braucht das Projekt eine fachlich akzeptierte Zielstruktur, bevor technische Transformationsregeln implementiert werden.

3. Zielmodell und Mapping-Regeln fachlich beschreiben

Ein Mapping-Dokument sollte lesbar sein für Fachbereich, Data Owner, Migrationsteam und Testmanagement. Reine technische Feldlisten reichen nicht aus. Zu jeder Regel gehören mindestens Quellobjekt und Quellfeld, Zielobjekt und Zielfeld, fachliche Beschreibung, Transformation, Standardwert, Pflichtfeldprüfung, Verantwortlichkeit und Status.

Die Regel „Land aus Quellsystem übernehmen“ ist nur dann ausreichend, wenn Format, zulässige Werte und Umgang mit Ausnahmen definiert sind. Häufig benötigt das Zielsystem ISO-Codes, während die Quelle interne Schlüssel führt. Ebenso müssen Default-Werte fachlich begründet werden. Ein Standardwert kann einen Migrationslauf technisch ermöglichen, aber spätere Prozessfehler verursachen, wenn er für die betroffene Geschäftseinheit nicht zutrifft.

Für komplexere Regeln empfiehlt sich eine klare Trennung zwischen fachlicher Regel und technischer Umsetzung. Die fachliche Regel beschreibt etwa die Ableitung einer Kontenzuordnung anhand von Buchungskreis und Materialgruppe. Die technische Umsetzung legt fest, wo diese Logik ausgeführt wird. Diese Trennung erleichtert Änderungen und verhindert, dass Fachentscheidungen nur in Transformationsskripten verborgen bleiben.

4. Datenqualität als Teil des Mappings behandeln

Datenbereinigung und Mapping werden häufig getrennt organisiert. Das ist nur begrenzt sinnvoll, denn viele Bereinigungsfälle ergeben sich erst aus dem Zielmodell. Wenn ein Zielattribut Pflicht ist, aber in der Quelle nicht vorhanden oder nicht verlässlich gepflegt wird, ist das kein späteres Testproblem. Es ist eine offene Mapping-Entscheidung.

Für jedes kritische Feld sollten Qualitätsregeln definiert werden: Vollständigkeit, Eindeutigkeit, Wertebereich, Referenzintegrität und Aktualität. Dabei kommt es auf messbare Schwellenwerte an. Beispielsweise kann das Projekt festlegen, dass vor dem Mock Load keine Geschäftspartner ohne gültige Steuerklassifikation und keine Materialien ohne definierte Mengeneinheit übertragen werden dürfen.

Nicht jede Datenlücke muss automatisiert geschlossen werden. Bei kleinen Mengen mit hoher geschäftlicher Bedeutung ist eine fachliche Klärung oft sicherer als eine pauschale Ableitung. Bei großen Mengen wiederkehrender Abweichungen ist dagegen eine kontrollierte Transformationsregel sinnvoll. Entscheidend ist, dass diese Abwägung dokumentiert, freigegeben und testbar bleibt.

5. Verantwortlichkeiten und Freigaben verbindlich steuern

Datenmapping scheitert selten an fehlenden Spalten in einer Arbeitsmappe. Es scheitert an ungeklärten Entscheidungen. Deshalb braucht jedes Datenobjekt einen fachlichen Data Owner, eine verantwortliche Person für die technische Umsetzung und eine klar definierte Instanz für Eskalationen.

Ein wirksames Freigabeverfahren unterscheidet zwischen Entwurf, fachlicher Prüfung, technischer Validierung und produktiver Freigabe. Änderungen nach einer Fachfreigabe dürfen nicht informell in Transformationslogiken erfolgen. Sie müssen versioniert, bewertet und erneut getestet werden. Das gilt besonders für Regeln, die Finanzbuchhaltung, Steuerlogik, Berechtigungen oder externe Meldungen beeinflussen.

Ein Mapping-Backlog mit eindeutigen IDs, Status, Entscheidungstermin und Auswirkungsanalyse schafft hier Transparenz. Für Projektleitungen wird sichtbar, welche offenen Punkte den nächsten Testlauf oder den Cutover tatsächlich gefährden. Für Fachbereiche bleibt nachvollziehbar, welche Entscheidung sie getroffen haben und welche Daten betroffen sind.

6. Mapping früh mit Testfällen und Abstimmungen verbinden

Ein Mapping ist erst belastbar, wenn es anhand repräsentativer Daten geprüft wurde. Ein technischer Import ohne Fehlernachricht belegt lediglich, dass die Daten geladen werden konnten. Er belegt nicht, dass Kontierungen stimmen, Belegketten vollständig sind oder Berichte die erwarteten Werte ausweisen.

Testfälle sollten deshalb aus konkreten Mapping-Risiken abgeleitet werden. Dazu zählen Dubletten beim Geschäftspartner, Umrechnungen von Mengen und Währungen, Zuordnungen zu Organisationseinheiten, historisierte Konditionen und die Übernahme offener Posten. Besonders aussagekräftig sind End-to-End-Tests, bei denen migrierte Stammdaten in realistischen Folgeprozessen verwendet werden.

Neben fachlichen Tests braucht es abgestimmte Kontrollsummen. Anzahl, Beträge, Salden und ausgewählte Schlüsselattribute müssen zwischen Quelle, Staging-Bereich und Zielsystem verglichen werden. Welche Kennzahlen maßgeblich sind, hängt vom Objekt ab. Bei offenen Posten sind Beträge und Fälligkeiten zentral, bei Materialstämmen eher Vollständigkeit, Klassifikation und abhängige Einheiten.

7. Mapping in Cutover und Betrieb überführen

Der letzte Migrationslauf ist kein isoliertes technisches Ereignis. Er benötigt eine belastbare Abfolge aus Datenextraktion, Sperrzeiten, Transformation, Ladeprozessen, Validierung, Fehlerbehandlung und fachlicher Freigabe. Die Mapping-Regeln bestimmen dabei, welche Prüfschritte erforderlich sind und welche Abweichungen akzeptabel sind.

Ein Cutover-Plan sollte daher pro Datenobjekt benennen, wer die Daten bereitstellt, wer den Lauf überwacht, wer Ergebnisse abstimmt und wer den Übergang in den Betrieb freigibt. Ebenso wichtig ist ein geregelter Umgang mit Fehlerdatensätzen. Werden sie nachbearbeitet, zurückgestellt oder über einen separaten Prozess angelegt? Ohne diese Entscheidung entstehen im Go-Live Zeitverluste und unklare Verantwortlichkeiten.

Auch nach der Produktivsetzung bleibt Mapping relevant. Neue Schnittstellen, Prozessänderungen oder zusätzliche Gesellschaften können Regeln verändern. Eine gepflegte Mapping-Dokumentation wird damit zum Bestandteil der Datenarchitektur und unterstützt stabilen Betrieb statt nur den einmaligen Projektabschluss.

Typische Fehlannahmen im Projekt

Die Annahme, Mapping sei eine Aufgabe des Migrationsteams, greift zu kurz. Das Team kann Regeln implementieren und Daten analysieren, aber es kann die fachliche Bedeutung eines Attributs nicht verbindlich festlegen. Ebenso riskant ist die Erwartung, Datenqualität ließe sich kurz vor dem Go-Live abschließend bereinigen. Je später eine Lücke sichtbar wird, desto höher sind meist der Abstimmungsaufwand und das Betriebsrisiko.

Auch standardisierte Vorlagen ersetzen keine fachliche Analyse. Sie beschleunigen die Strukturierung, können aber nicht entscheiden, ob lokale Geschäftsregeln, kundenspezifische Erweiterungen oder regulatorisch relevante Merkmale übernommen werden müssen. Standardisierung ist sinnvoll, wenn sie bewusst erfolgt und Ausnahmen transparent behandelt werden.

Datenmapping als steuerbare Projektleistung

Ein belastbares Datenmapping verbindet Fachprozess, Zielarchitektur, Datenqualität, Testmanagement und Cutover-Steuerung. Es macht Entscheidungen sichtbar, bevor sie sich als Fehler im Zielsystem manifestieren. Gerade in Projekten mit mehreren Gesellschaften, Vorsystemen oder engen Betriebsfenstern ist diese Transparenz wichtiger als eine früh gefüllte Mapping-Liste.

Mapping-Quick-Check für laufende S/4HANA-Projekte

Quteco unterstützt S/4HANA-Vorhaben mit Datenflussanalyse, Mapping-Workshops, Testmanagement und Cutover-Planung. Ein fokussierter Quick Check kann offene Datenobjekte, ungeklärte Verantwortlichkeiten und kritische Testlücken strukturiert bewerten. Daraus entsteht eine priorisierte Arbeitsgrundlage für Migration und stabilen Betrieb - mit dokumentierten Entscheidungen statt kurzfristiger Annahmen.