SAP BW in Zeiten von Hana
Ein SAP BW wurde grundsätzlich entwickelt, um aus verschiedenen SAP- und Non-SAP-Systemen Daten derart abzulegen, dass ein performanter Zugriff für Datenanalysen über Fachbereichsgrenzen hinweg ermöglicht wird.
Historie
Seiner Zeit empfahl sich das Stern-Schema, um solche Datenmengen zu handhaben. So wurden Datenbanken initial als analytisch (OLAP) oder transaktional (OLTP) eingestellt, um einen effizienten Datenzugriff zu ermöglichen. In einem OLTP-System einen analytischen Zugriff abzusetzen macht jedoch genauso wenig Spaß wie in einem OLAP-System transaktional zu arbeiten. Für analytische Zugriffe sind spaltenorientierte Datenbank-Managementsysteme (DBMS) besser als zeilenorientierte DBMS geeignet. Um die analytischen Zugriffe auf das SAP BW zu verbessern, wurde daher mit dem SAP BW Accelerator ein spaltenorientiertes DBMS ausgeliefert.
Kehrtwende
Mit einer Hana-Datenbank werden die Datenzugriffe aufgrund der In-memory-Datenhaltung sowohl für analytische als auch für transaktionale Zugriffe performant. Die Einstellung der DB für OLAP oder OLTP fällt weg.
Da statistisch weitaus mehr lesend auf die Daten zugegriffen wird als schreibend, werden die Daten in Hana im Standard spaltenorientiert abgelegt. Eine zusätzliche Zeilenorientierung empfiehlt sich für Tabellen, auf die schreibend zugegriffen wird.
Da die Hana-DB die von SAP bevorzugte DB für die ERP-Anwendungen ist, können nun alle operativen Daten auch sofort für Analysen genutzt werden. Wozu dann noch ein SAP BW?
Auf das SAP BW könnten Sie in dem Moment verzichten, in dem Sie alle – unternehmensweit alle – Daten inkl. Historie in dieser einen Hana-DB haben. Technisch ist solch ein Szenario realisierbar. Aber leider besteht IT nicht nur aus Technik.
Anforderungen an ein zentrales System
Historie: Da Echtzeitdaten vor allem für das operative Reporting geeignet sind, ist festzulegen, welche Daten in der Hana-DB für strategische Aussagen historisiert werden sollen.
Damit der Speicherbedarf nicht unnötig steigt und somit zusätzliche Speicher- und damit Lizenzkosten verursacht werden, kann mit einem Nearline Storage gearbeitet werden. Leider wird dabei die Performance für strategische Berichte beeinträchtigt.
Datenverschneidung und -anreicherung: Alle Fachbereiche, die noch nicht ihre Daten in dieser Hana-DB haben, müssen angedockt werden, um ihre Daten für einen unternehmensweiten, fachübergreifenden Zugriff zur Verfügung zu stellen. Hierzu müssen anschließend fachübergreifende Datenmodellierungen und auch Datenanreicherungen stattfinden.
Datenqualität und -aktualität: Die vorgehaltenen Daten müssen unternehmensweit einen Single Point of Truth bilden. Hierzu ist genau abzustimmen, welche Daten zu welchem Zeitpunkt wie berechnet und eingeschränkt zur Verfügung gestellt werden. Aktuell bedeutet in diesem Zusammenhang nicht unbedingt in Echtzeit.
Berechtigungen: Stellen Sie sich vor, Sie haben die Gesamtverantwortung der Personaldaten im Unternehmen und verantworten in dieser Rolle auch das SAP-HR-System.
Sie sollen jetzt zusammen mit dem SAP ERP auf einem System alle Mitarbeiterdaten ablegen. Werden Sie nachts ruhig schlafen? Noch heute wird bei der Entscheidung nach einem SAP-BW-HR-System lieber ein eigenes System bevorzugt, als in das bereits existierende zentrale BW-System zu gehen, wo unterschiedliche Fachbereiche ihre Daten vorhalten.
Auch wenn das Berechtigungswesen entsprechend aufgebaut werden kann. Es geht um ein sehr sensibles Thema der Datenhoheit und damit des Datenschutzes. Es gilt hier immer noch: Je isolierter das System, desto besser.
Application Service Management: Ein zentrales System – wie auch immer geartet – muss auch verwaltet werden. Welcher Fachbereich erklärt sich bereit, diese zentrale Instanz für die anderen Fachbereiche und den Vorstand vorzuhalten?
Dabei geht es um Themen wie Installation, Upgrade, laufender Betrieb, Lizenzen, Projekte, Change Management, Notkorrekturen, Sarbanes-Oxley Compliance, Self Services u.v.a.m. Kurzum, das gesamte Application Service Management muss für das System betrieben werden.
Kosten: Der operative Betrieb eines solchen zentralen Systems ist somit mit Aufwand und damit mit Kosten verbunden, nicht zuletzt aufgrund der benötigten Arbeitskräfte. Diese Kosten müssen, am besten verursachergerecht, verteilt werden.
Für ein strategisches Reporting in einer Hana-DB müssen vor allem die ersten beiden Punkte bzgl. Historie und Datenverschneidung geklärt sein.
Reporting mit SAP BW
Durch den Einsatz einer Hana-DB unter einem SAP-BW-System sind nicht nur die Aktivierungen von Datentöpfen und Antwortzeiten von Berichten schneller geworden, sondern es besteht die Möglichkeit, Echtzeitdaten aus einem herkömmlichen operativen SAP System (ERP, CRM etc.) mit in das SAP-BW-Berichtswesen zu integrieren.
Hierzu werden die Daten, die die Geschäftsleitung oder der Fachbereich brauchen, mithilfe des SAP Landscape Transformators (SLT) in die Hana des SAP BW repliziert.
Aus dem jeweiligen Hana-Schema heraus können nun die replizierten Tabellen in Form von Information-Views (Analytical oder Calculation Views) direkt oder noch mit zusätzlicher Logik versehen im SAP BW mithilfe von virtuellen Infoprovidern angezeigt bzw. in Multiprovider eingebaut und damit mit bestehenden Berichten verschnitten werden.
Die im SAP-BW-Umfeld genutzten Content- und Analyseberechtigungen können für die Analyse von derartigen Echtzeitdaten genauso genutzt werden.
Das ist ein nicht zu unterschätzender Vorteil gegenüber der direkten Datenanalyse auf der Hana-Tabelle, die ihrerseits eine eigene Berechtigung verlangt, die es zu verwalten gilt.
Umbau SAP BW
Um die bestehende SAP-BW-Landschaft für die Zukunft vorzubereiten, sind folgende Investitionsschritte notwendig:
1. Hana-zertifizierte Hardware.
2. Hana-Lizenzen – neben der OEM für reine SAP-BW-Nutzung auch der Hana Modeller.
3. Migration auf SAP BW on Hana.
Wird bereits darüber nachgedacht, S/4 einzusetzen, so muss – etwas anders skaliert – der Investitionsschritt 1 auch getan werden. Sollte also Hardware-technisch sowieso ein IT-Umbau anstehen, so könnte ein solcher Schritt bereits in Erwägung gezogen werden.
Mit einem BW on Hana besteht die Möglichkeit, die neuen Eigenschaften und Funktionalitäten von Hana bereits einzusetzen und Erfahrungen mit der Echtzeitdatenbank zu sammeln.
Auch bietet das SAP BW mittlerweile einfachere Modellierungsmöglichkeiten (Stichworte ADSO, Composite Provider), die – vor allem mit der Eclipse-basierten Vorwärtsmodellierung – den Umgang mit dem SAP BW wesentlich vereinfachen.
Vor allem der Einsatz der Composite Provider im Zusammenhang mit fachbereichsspezifischen Workspaces erlaubt einen Self-Service-BI-Ansatz, mit dem Fachbereiche ihre Berichte mit eigenen Zuordnungen erweitern und anschließend mit den bestehenden Berechtigungen ausführen können.
Auch wenn derartige Erweiterungen wohl nur von einem PowerUser durchgeführt werden, so gibt es dem Fachbereich doch eine Flexibilität, die den IT-Governance-Richtlinien entspricht. Der Workspace selbst wird dabei von der IT zur Verfügung gestellt.
Zukünftige Nutzung des SAP BW
Es ist nach der initialen Migration des bestehenden SAP-BW-Inhaltes möglich, neue BW-Inhalte unter Berücksichtigung des Schichtenmodells (Stichwort LSA++ etc.) so aufzubauen, dass das Reporting sowohl für operative als auch für strategische Zwecke genutzt wird.
Das stellt für die Fachbereiche einen immensen Vorteil dar. Werden weitere Daten benötigt, kann die IT die benötigten Tabellen/Views in der Replikation via SLT einfach hinzunehmen. Aufwändige Realtime-Data-Acquisition-Extraktoren (RDA) entfallen und müssen nicht mehr gewartet werden.
Vorstellbar ist auch, die BW-Funktionalität lediglich für die Historisierung und Datenanreicherung zu nutzen und am Ende direkt aus Hana heraus die Berichte aufzubauen, ohne die OLAP-Funktionalität zu nutzen.
Da derzeit die BEx-Query noch immer die Surrogate ID (SID) nutzt, werden etwa 80 Prozent der gesamten Berichtslaufzeit für das initiale Erstellen und Mapping der SID verbraucht. Bei direkter Hana-Nutzung würden die Berichte somit insgesamt schneller prozessiert.
Am Ende der derzeitig geplanten Roadmap steht ein S/4, mit dem nicht nur alle bekannten SAP-Modelle vereinfacht werden, sondern u. a. auch die BW-Funktionalität enthalten ist.
Sollte sich herausstellen, dass das zentrale BW-System in solch einem zentralen S/4 aufgehen könnte – nicht nur technisch, sondern vor allem vom Gesichtspunkt der IT Governance aus –, so wurden alle bisherigen Investitionen nicht umsonst getätigt.
Im Gegenteil, es wurden wertvolle Erfahrungen im Umgang mit einer komplexen Hana-Landschaft gesammelt, die helfen werden, die richtige Entscheidung für oder gegen ein zentrales Data Warehouse zu fällen.
