Der überwiegende Teil an Unternehmen, die derzeit noch auf SAP ERP ECC 6.0 unterwegs sind und parallel ein SAP BW on HANA System betreiben, haben den Blick oft nur auf ihre SAP S/4HANA Transition gerichtet.
Diese müssen jetzt aber ebenso die Modernisierung ihres SAP BW Systems, als auch die ihres Reporting-Frontends auf die Agenda nehmen.
SAP BW 7.40 ist bereits Ende 2020 aus der Wartung gelaufen, und SAP BW 7.50 wird Ende 2027 aus der Mainstream und 2030 Extended Maintenance fallen.
Zudem funktioniert der BEx Analyzer unter Excel 64 Bit nicht mehr – eine Umstellung der BEx Tools ist ohnehin vonnöten – und ebenso hat SAP Lumira 2.x sein Ende im Jahr 2027 angekündigt bekommen.
Modernisierungs-Varianten im Back-End
Aufgrund ihrer Cloud-First-Strategie propagiert SAP seit circa zwei Jahren drei mögliche Modernisierungs-Varianten, die, was das SAP BW/4HANA betrifft, allerdings auch als On-Premise-Lösung möglich ist und nicht zwingend als „Cloud Private Edition“ bei der SAP gehostet sein muss. Für SAP BW/4HANA liegt das Wartungsende derzeit erst im Jahr 2040.
Der erste Weg (1) ist eine Migration des heutigen SAP BW Systems nach SAP BW/4HANA. Diese kann je nach Release auf drei Wegen erfolgen:
- In-place = Konvertierung im eigenen System
- Remote = Greenfield BW mit Übernahme aller alten Objekte und Daten
- Shell = Greenfield BW mit Übernahme aller alten Objekte, ohne Daten, welche aber nachträglich noch ins System geladen werden können
Weg (2) ist analog zu (1) allerdings erweitert, um die Möglichkeit, das echte Cloud-System SAP Datasphere einzusetzen, das seit 2019 unter dem Namen SAP Data Warehouse Cloud begonnen und 2023 als SAP Datasphere weiterentwickelt wurde. Im Jahr 2022 kam hier die sogenannte BW Bridge hinzu, die einen vollständigen Umstieg auf die SAP Datasphere erleichtern soll.
Die BW Bridge ist ebenfalls ein SAP BW/4HANA System, gehostet bei der SAP, jedoch besitzt es reine Backend-Funktionalitäten bis zur Composite-Provider-Ebene, dafür aber einen ABAP-Stack, um sämtliche historische Entwicklungen beibehalten zu können.
Der dritte Weg (3) zeichnet sich durch eine vollständige Greenfield-Implementierung in einem leeren System aus. Diese kann parallel oder nach der SAP S/4HANA Transition erfolgen.
Die gestrichelte Linie in Abbildung 1 stellt einen hybriden Ansatz dar. Das heißt selbst, wenn man auf SAP BW/4HANA bleiben möchte, kann man bestimmte Neu-Entwicklungen auf der SAP Datasphere beginnen oder auch Self-Service BI für bestimmte Fachbereiche anbieten.
Ein Thema, das hier auf jeden Fall beleuchtet werden sollte, sind die Möglichkeiten und Einschränkungen in der Quellsystem-Anbindung:
Ohne die Berücksichtigung des derzeitigen beziehungsweise künftigen Reporting-Tools für die Anwender sollte die Entscheidung allerdings auch nicht getroffen werden. Warum, sehen wir gleich.
Modernisierung im Front-End
Beim Thema Front-End-Modernisierung fällt die Entscheidung deutlich leichter, sofern man bei SAP Standardsoftware bleiben und nicht auf 3rd-Party-Tools setzen möchte.
Das Analysis for MS Office ist im Wesentlichen zu Ende entwickelt, und wird noch bis 2029 gewartet, weil vermutlich erst bis dahin das SAP Analytics Cloud (SAC) Add-In für MS Office einen ähnlichen Reifegrad haben wird. Damit bleibt als web-basiertes Reporting-Frontend ohne Ablauftermin, Stand heute, einzig die SAP Analytics Cloud als Ersatz für Lumira oder ähnliche Anwendungen, wie SAP Design Studio oder SAP Webi.
Wenn Sie mehr über die SAP Analytics Cloud erfahren möchten, erfahren Sie hier, wie Sie diese unverbindlich testen und hier, welche Visualisierungsmöglichkeiten die SAC bereithält. Wie das Zusammenspiel mit der SAP Datasphere aussieht, können Sie außerdem in diesem Blog-Beitrag nachlesen.
Modernisierungsstrategien in Back-End und Front-End
Den richtigen Weg zu wählen ist nicht einfach, da jedes Für und Wider gut abgewogen werden muss. Ein entscheidender Punkt ist beispielsweise, ob man bereits die SAP Analytics Cloud als Front-End einsetzt oder noch nicht.
Stories auf gleichbleibenden BW Queries von BW on HANA nach BW/4HANA zu migrieren, erfordert keinen weiteren Aufwand, wohingegen die „Queries der SAP Datasphere“, die sogenannten Analytischen Modelle komplett andere Objekte sind, und bisherige Stories darauf noch einmal analog aufgebaut werden müssten.
Ähnlich verhält es sich mit Excel-Arbeitsmappen. Falls noch nicht erfolgt, lassen sich diese gut in Analysis Office-Arbeitsmappen konvertieren und auch unter BW/4HANA weiternutzen.
Der Wechsel zur SAP Datasphere und dem SAC Add-In erfordert faktisch einen Neubau der Arbeitsmappen.
Queries mit zwei Strukturen und vielleicht sogar Zelldefinitionen lassen sich derzeit weder im Analytischen Modell noch in einer SAC Story Tabelle so erstellen, wie man es im BEx Query Designer oder den BW Modeling Tools gewohnt war. Hier ist der Live-Zugriff auf die BW Query auf jeden Fall der entscheidende Vorteil.
Ein Mehrwert der SAC, den man unbedingt erwähnen sollte, ist, dass man auch die CDS Views der Analytischen Apps im SAP S/4HANA System verwenden kann, um darauf eigene Live-Stories zu bauen, ohne die S4-Daten extrahieren und in der SAC speichern zu müssen.
Bei vielen Unternehmen spielen neben dem Berichtswesen oft auch Planungsanwendungen eine große Rolle. Alte Planungsfunktionen, wie beispielsweise noch aus BW-IP Zeiten, in die sogenannten Datenaktionen der SAC zu überführen, kann aufgrund der dort genutzten Skript-Sprache einiges an Aufwand bedeuten.
Aus unserer Sicht sollte die Anlage neuer Planungsanwendungen in der SAC nach Möglichkeit aufgeschoben werden, bis Ende 2024 klar wird, wie die direkte Integration des Planmodells in die SAP Datasphere aussehen wird.
Es wird auf jeden Fall eine große Erleichterung sein, nicht mehr Daten zwischen SAP Datasphere und SAC-Modell hin und her kopieren zu müssen, sondern sein SAC-Reporting aus einer einzigen Datenquelle aufzubauen, wie man es seit Jahrzehnten im BW gewohnt war.
Bei Projekten oder Change Requests, oft außer Acht gelassen, ist meistens auch das Thema Berechtigungen. Daher sei es an dieser Stelle einmal erwähnt. Auch die bisherigen Analyseberechtigungen können einen zusätzlichen Aufwand bedeuten.
Über ein separates Programm wird zwar ermöglicht, bisherige Berechtigungen über eine Remote-Tabelle der SAP Datasphere bereitzustellen, aber unter Umständen kann es Sinn ergeben, das bisherige Konzept zu erneuern und dann auf die Standard Data-Access-Controls der SAP Datasphere umzubauen.
Ein letzter Punkt, der neben all den vorher genannten, oft auch eine entscheidende Rolle spielt, sind die Lizenzkosten der jeweiligen Produkte. Außer bei der SAC sind bei SAP BW/4HANA oder der SAP Datasphere nicht die Anzahl User das Kriterium, sondern die Größe der Datenbank (RAM) und die CPUs.
Auf der HANA-Datenbank belegen die Reporting-Daten deutlich weniger Speicherplatz, womit gegebenenfalls eine heute eingesetzte Archivierungslösung entfallen kann. SAP BW/4HANA bringt von Haus aus das sogenannte „Data-Tiering-Optimization“-Konzept mit, wodurch länger ungenutzte Daten automatisch in den Warm- oder Kalt-Bereich verschoben werden können.
Mit der SAP BW Bridge, wie auch der SAP Datasphere entfallen die heutigen Kosten eigener Hardware und der Betrieb im eigenen Rechenzentrum oder bei einem Dienstleister. Diese wird dafür durch eine monatliche Lizenzgebühr an die SAP, für die Nutzung der Cloud-Produkte im Rechenzentrum eines Hyperscalers, ersetzt.
Fazit
Die grundlegende Modernisierung einer SAP Business Warehouse Landschaft erfordert eine ähnliche Herangehensweise wie eine SAP S/4HANA Migration und kann nicht vollumfänglich in einem einzigen Blog-Beitrag beschrieben werden.
Wir unterstützen Sie gerne bei einer Bestands-Aufnahme ihrer Ist-Situation, der Entwicklung Ihrer Datenstrategie und Ziel-Architektur sowie der Umsetzung in Ihrem künftigen BW-Modernisierungs-Projekt. Sprechen Sie uns gerne an!
