Raus aus dem Alt-Reporting: Was ein Umstieg auf S/4HANA wirklich bedeutet

Wenn das Quellsystem wechselt, von einem Data-Warehouse-Altbestand und manuellen Extrakten hin zu S/4HANA, lautet die naheliegende Hoffnung: „Wir hängen das neue Backend an und das Reporting läuft weiter." Diese Hoffnung trügt. Ein Plattformwechsel ist kein Lift-and-Shift, sondern eine Re-Modellierung.

Die Ausgangslage

Ein gewachsenes Reporting wurde historisch aus einem Data-Warehouse-Altbestand und ergänzenden manuellen Extrakten gespeist. Mit dem Umstieg auf S/4HANA änderten sich die Quellen grundlegend: neue Views, andere Körnung, verschobene Semantik. Die alten Auswertungslogiken ließen sich nicht einfach auf die neuen Views umbiegen.

Das Problem: Semantik wandert mit

Beim Plattformwechsel ändert sich mehr, als auf den ersten Blick sichtbar ist:

• Views liefern andere Granularität als die alten Extrakte. Was vorher eine Zeile war, sind jetzt mehrere (oder umgekehrt).
• Spaltensemantik verschiebt sich: Ein gleich benanntes Feld bedeutet im neuen System nicht zwangsläufig dasselbe.
• Quellen bleiben in Bewegung: Views werden umbenannt, ergänzt, ersetzt. Über Monate hinweg, während das Reporting schon produktiv ist.

Wer in dieser Phase das DAX direkt auf die jeweils aktuellen Staging-Objekte zeigen lässt, baut sich eine fragile Kette: Jede Umbenennung im Quell-Layer bricht Measures.

Die Lösung: eine stabile DAX-Oberfläche

Der wirksamste Hebel ist eine Entkopplung zwischen dem volatilen Quell-Layer und den Measures. Statt dass DAX direkt auf Staging-Ausdrücke (STG_*) zeigt, wird je Fakt eine leere, versteckte Tabelle (FCT_*, isHidden) angelegt, deren Partition auf den Staging-Ausdruck verweist. Measures referenzieren ausschließlich diese FCT_*-Tabellen.

Der Effekt: Wird ein Staging-Ausdruck umbenannt oder umgebaut, bricht kein Measure. Die FCT_*-Oberfläche bleibt konstant. Die Quell-Volatilität wird an genau einer Stelle aufgefangen.

Die Stolperfallen

1. Spaltensemantik unbesehen übernehmen. Ein Feld, dessen Name auf eine bestimmte Bedeutung schließen lässt, kann im neuen System aus einer ganz anderen Quelle stammen. Vor dem Umbau prüfen, woher der Wert wirklich kommt. Nicht dem Namen vertrauen.
2. Quell-Archäologie überspringen. Wird eine Kennzahl neu angebunden, deren altes Measure längst entfernt wurde, lohnt der Blick in die Versionshistorie: Aus welcher Tabelle und mit welchem Filter zog die alte Definition wirklich? Solche Details (etwa abweichende Szenario-Bezeichnungen an der Quelle) sind die typischen stillen Fehlerquellen.
3. Strukturelle Unterschiede als Detail behandeln. Eine geänderte Körnung oder eine zusätzliche Summenzeile in der Quelle führt zu Doppelzählung, wenn sie nicht bewusst gefiltert wird.

Das Takeaway

Ein Quellsystemwechsel ist eine Gelegenheit, das Modell sauber neu aufzusetzen. Nicht, das alte zu kopieren. Zwei Prinzipien tragen durch die Übergangsphase: eine stabile, versteckte DAX-Oberfläche, die Quell-Churn abfängt, und Quell-Archäologie statt Namensvertrauen. Dann bleibt das Reporting auch dann verlässlich, wenn im Backend noch monatelang gearbeitet wird.