SAP BW und SAP BW/4HANA während der S/4HANA-Migration. Was ist konkret zu tun?

SAP BW und SAP BW/4HANA (folgend auch: BW) sind als analytische Zielsysteme eng einem S4/HANA-Migrationsvorhaben verbunden. Durch die enge Verzahnung beider Systeme entstehen zwingende Aufgaben, die vor, während und nach dem Wechsel erledigt werden müssen. Gleichzeitig eröffnet die Transformation zusätzliche Optionen, durch die BW nachhaltig von der Modernisierung profitiert.

Besonders kritisch ist, dass es während des Cutover des S/4HANA-Systems kein plausibles Fallbackszenario gibt, das entgangene Daten dem SAP BW nachträglich zur Verfügung stellt. Wird daher SAP BW nicht rechtzeitig vorbereitet oder werden zentrale Tätigkeiten ausgelassen, fehlen nach dem Go-Live Daten, die später nicht mehr vollständig oder korrekt rekonstruiert werden können. In der Folge werden wesentliche Teilaufgaben, zeitlich geordnet, besprochen.

Phase 1: Strategisch und wichtig: Planung und Festlegung des Migrationsansatzes

Der Umgang mit SAP BW hängt maßgeblich davon ab, wie S4/HANA migriert wird. Der Unterschied zwischen Brownfield, Bluefield und Greenfield wirkt sich direkt auf die technische Anbindung, die Harmonisierung der Daten und den Aufwand auf Seiten der SAP-BW-Umgebung aus. Dies gilt insbesondere für Ansätze (Bluefield, Greenfield) bei denen das „alte“ ERP ECC-System nicht weiter betrieben wird.

Eine technisch saubere, jedoch recht aufwändige Herangehensweise für SAP BW ist, ein neues S/4HANA-Quellsystem anzubinden. Diese Vorgehensweise ermöglicht eine klare Trennung zwischen altem und neuem Datenhaushalt, erfordert jedoch Anpassungen in den Datenmodellen sowie eine sorgfältige Harmonisierung der Inhalte. In vielen Projekten wird daher, insbesondere bei zeitgleichem Wechsel aller Werke und Buchungskreise, ein pragmatischer Ansatz gewählt, der lediglich die RFC-Verbindung auf das neue System umstellt. Dieser Ansatz reduziert datenmodellbezogenen Aufwand, verlangt jedoch besondere Aufmerksamkeit für die Stabilität der Delta-Mechanismen.

Die Ladestrategie ist ein weiterer kritischer Betrachtungsfaktor. Während Voll- oder Snapshot-Ladungen recht einfach realisierbar sind, stellen Delta-Prozesse auf Belegebene die eigentliche Herausforderung dar. Sie müssen im Hinblick auf Deltazeiger, Queue-Strukturen und Prozessänderungen unter S4/HANA fachlich und technisch abgesichert werden. Parallel dazu ist eine vollständige Prüfung aller genutzten Datasources erforderlich, sowohl hinsichtlich der technischen Funktionsweise als auch der inhaltlichen Richtigkeit.

Phase 2.1: Wo ist zu handeln? Prüfung der Kompatibilität genutzter SAP BW-Extraktoren

Die Funktionsfähigkeit von Standardextraktoren wird über SAP-Hinweise wie zum Beispiel Hinweis 2500202 dargestellt, jedoch reicht diese rein formale Prüfung nicht aus. Zusätzlich müssen kundeneigene Extraktoren (sogenannte Z-Extraktoren), die unter Umständen kundeneigene Tabellen, Funktionsbausteine oder Programme nutzen, geprüft werden. Änderungen in Strukturen, Feldlängen oder Business-Logik können hier zu unbemerkten Abweichungen führen. Weiterhin gilt es, die Funktion von Kundenerweiterungen der Standard-Extraktoren im Detail zu prüfen.

Neben der reinen technischen Prüfung ist die Validierung und das (Regressions-)Testen der über die Extraktoren gelieferten Dateninhalte entscheidend. Diese kann nur in enger Abstimmung zwischen BW-Team und S4HANA-Prozessexperten erfolgen, da Veränderungen im Customizing oder in der Prozessabwicklung sich unmittelbar in den extrahierten Daten widerspiegeln. Gerade in Bereichen wie der Profit-Center-Rechnung, CO-PA, FI-CO-Kontenplanlogik, Kostenstellenstrukturen, der Einführung des Business Partner oder der Integration neuer Komponenten wie EWM kommt es regelmäßig zu inhaltlichen Verschiebungen, die aktiv adressiert werden müssen.

Phase 2.2: Orientierungshilfe - Typische Bereiche mit Änderungen durch S/4HANA

Die Umstellung auf S4/HANA führt zu häufig tiefgreifenden strukturellen und prozessualen Änderungen, die sich deutlich auf die Datenweitergabe nach SAP BW auswirken. Ein zentraler Bestandteil ist die Einführung der ACDOCA (und ACDOCP, ACDOCU) als universelles Journal, das große Teile der bisherigen FI-CO-Tabellenlandschaft ablöst. Dadurch verändern sich die logischen Zusammenhänge in Bereichen wie der Profit-Center-Rechnung (Wegfall der CO-EP-Tabellen, neue Profit-Center-Rechnung über ACDOCA) oder CO-PA, die nun vollständig auf ACDOC* basieren. Pauschal lässt sich die Auswirkung aber nicht feststellen, da z.B. die Profit-Center-Rechnung auch weiterhin „alt“ in S/4HANA laufen kann – auch wenn dies gegen die Empfehlung der SAP ist. Kern der Aktivität für SAP BW im Rahmen des S/4HANA-Projektes ist es, Änderungen zu erkennen, bestehende Datenflüsse dahingehend vorzubereiten und Lösungen zu schaffen in dem existierenden Daten mit neuen Daten gemeinsam funktionieren. SAP BW ist in diesen Szenarien häufig die Stelle, in der langfristige Zeitreihenanalysen möglich bleiben – eine Fähigkeit, die auch für Abschlussaktivitäten und Dokumentationspflichten interessant sein kann.

Auch Kontenpläne, Kostenstellenhierarchien und Bewertungsstrukturen werden häufig im Zuge der Migration angepasst oder harmonisiert. Mit der Einführung des Business Partner entsteht zudem ein konsolidiertes Objektmodell, das die bisherige Debitoren- und Kreditorenlogik ersetzt und damit sowohl technische als auch inhaltliche Auswirkungen auf die Extraktion hat. Im Finanzumfeld gewinnt ferner das Group Reporting an Bedeutung und bringt neue Anforderungen an die konsolidierten Daten mit sich.

In den operativen Bereichen sorgen Strukturänderungen bei der Materialnummer (von maximal 18 auf 40 Stellen) und modernisierte Prozesse wie EWM (Extended Warehouse Management) oder neue Fertigungslogiken für veränderte Datenflüsse. All diese Änderungen wirken sich direkt auf Extraktionslogiken, Delta-Mechanismen und die fachliche Datenvalidierung aus. Eine enge Abstimmung der beteiligten Teams ist daher zwingend erforderlich.

Phase 2.3: Orientierungshilfe 2 - Technische Detailaspekte für SAP BW und BW/4HANA

Im Folgenden sollen einige technische Details erwähnt werden, die aus meiner Projekterfahrung heraus zu beachten sind und/ oder in der Vergangenheit für unerwartete Überraschungen führt haben.

So betrifft ein Aspekt etwa Nummernkreise, die unter S4/HANA unter Umständen neu starten. Dies kann zu fehlerhaften Schlüsseln, doppelten Datensätzen und/oder unerwünschten Aggregationen im SAP BW führen, wenn die Datenflüsse nicht entsprechend angepasst werden.

Darüber gibt es einige Datasources, die unter S4/HANA im Delta-Verfahren technische Einschränkungen oder unerwartetes Verhalten zeigen. Für viele dieser Fälle existieren erprobte Lösungsansätze, die projektspezifisch umgesetzt werden müssen.

Auch der Umgang mit der Quellsystem-ID im SAP BW sollte sorgfältig geplant werden, da eine Änderung direkte Auswirkungen auf Deltaprotokolle und historische Datenbestände haben kann.

Nicht zuletzt müssen die Berechtigungen für Extraktionsuser vollständig geprüft werden, da fehlende Rechte häufig zu unvollständigen oder verfälschten Ergebnissen führen, ohne dass unmittelbar Fehlermeldungen auftreten.

Phase 3: Es wird hektisch - die Cutoverphase

Die Cutoverphase erfordert eine hochpräzise zeitliche Steuerung. Der Ablaufplan muss die gewählte Datenladestrategie exakt abbilden und sicherstellen, dass speziell für Deltaverfahren des LO-Cockpit, Queue-Mechanismen und Deltazeiger in der richtigen Reihenfolge gesetzt werden und letzte bzw. erste Datenladung zeitlich passend stattfinden. Es ist dringend empfehlenswert, alle Schritte in einem interdisziplinären Cut-Over-Drehbuch, mit Tätigkeiten aus Modul-, Basis-, und BW-Team zusammenzufassen und eine gemeinsame und proaktive Kommunikationskultur vorzubereiten.

Eine Generalprobe auf einem Vorsystem oder Testsystem ist unbedingt empfohlen, besonders wenn der eingangs beschriebene „datenmodellaufwandsarme“ Weg über eine einfache RFC-Umstellung genutzt wird. Dies ist wichtig, um so ein eingespieltes und damit zeitlich effizientes Vorgehen zu gewährleisten – denn Zeit zum Ausprobieren und der Fehleranalyse bleibt während des Produktiv-Cut-Overs nicht, da jede Stunde S/4HANA-Migrationszeit gleichbedeutend mit dem Stillstand operativer Prozesse ist.

Bezogen auf Bearbeitung des Drehbuchs ist wichtig, dass die Schritte im interdisziplinären Team durchgeführt, geprüft und freigegeben werden, um Konsistenz und Vollständigkeit der Daten sicherzustellen.

Für umfangreiche Beladungsaufgaben empfiehlt sich ferner, dedizierte automatisierte Ladeprozesse oder Jobketten einzusetzen. Dabei gilt es zu berücksichtigen, dass mitunter nicht alle Daten des neuen S/4HANA-Systems in die SAP BW-Umgebung geladen werden dürfen. Historische Übernahmewerte wie Initialbuchungen, Salden oder Offene Posten sind häufig schon aus der „alten“ Welt im SAP BW vorhanden und müssen so aktiv bei der Verbuchung ausgeschlossen werden.

Phase 4.1: Aufmerksam bleiben - Nach dem Go Live entscheidet sich Datenqualität

Unmittelbar nach dem Go-Live beginnt eine Phase intensiver Überwachung. Das BW-Team sollte alle Ladeprozesse eng verfolgen und fachliche Prüfungen wie Kontenabgleiche, Bestandsvergleiche gegen das S/4HANA-System durchführen sowie die Überprüfung fachlicher Schlüsselwerte durchführen. Eine strukturierte Hypercare-Phase mit klaren Prüfpfaden ist entscheidend, um Fehler schnell zu erkennen und zu beheben.

Phase 4.2: Nach der Migration - Verbesserungen, Optimierungen, Nutzenerweiterungen

Neben den zwingenden Anpassungen bietet eine S4HANA-Migration die Chance, die analytische Architektur rund um SAP BW zu modernisieren. Dies kann – wenn nicht schon proaktiv und vorbereitend erfolgt – nach und nach in der Zeit nach der Migration erfolgen.

Die Umstellung auf ODP (Operational Data Provisioning) erhöht die Ladeperformance und reduziert Staging-Aufwände (Wegfall der PSA) im SAP BW, erfordert jedoch eine Überprüfung Selektionslogiken, die auf Ebene der Infopackage enthalten waren.

Die Migration von BW-Extraktor-Erweiterungslogiken von Customer Exit hin zu BADIs verbessert Wartbarkeit und Upgrade-Fähigkeit erheblich. Noch zukunftssicherer sind CDS-basierte Extraktionen, die konsistente Semantiken bereitstellen und das Ziel eines Clean Core unterstützen.

Darüber hinaus können Unternehmen bestehende Anwendungen durch reine S/4HANA-Szenarien ersetzen und die analytische Datenverarbeitung stärker in die operative Prozesswelt integrieren. Hier gilt es eine genaue Prüfung der Eignung durchzuführen – Datenintegration aus mehreren Quellen, Bedarf historischer Analysen oder die Belastung der operativen Umgebung sind hier zu berücksichtigen.

In vielen Fällen sinnvoll zu betrachten sind hybride Ansätze, bei denen SAP BW die historische Wahrheit enthält und S/4HANA Echtzeitdaten für operative Analysen bereitstellt – alles mit einem zentralen Datenzugang.

Fazit

Ein S/4HANA-Projekt muss zwingend die bestehenden SAP BW- und SAP BW/4HANA-Systeme in den Ablauf und die Vorbereitung einbinden. Die konkrete Ausgestaltung hängt von Migrationsansatz, Systemlandschaft und organisatorischen Rahmenbedingungen ab. Neben unverzichtbaren technischen und fachlichen Aufgaben existieren vielfältige Potenziale, SAP BW leistungsfähiger, moderner und zukunftssicher zu gestalten.

Autor: Michael Natterer

BW & S/4HANA sauber zusammenbringen

Wir zeigen Ihnen, wie Sie Ihr Reporting während der Migration stabil halten und zukunftssicher aufstellen.

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