Viele SAP-Anwenderunternehmen fragen sich, welche Rolle die Datenbankentwicklungen ihres Anwendungslieferanten in ihrer künftigen IT-Strategie spielen sollen. Einerseits eröffnet SAP HANA (High-Performance Analytic Appliance) den Unternehmen viele neue Möglichkeiten und wird in Zukunft sicher eine zentrale Rolle in SAP-orientierten BI-Umgebungen spielen. Auf der anderen Seite gilt es für die IT-Verantwortlichen je nach Anwendungsszenario sorgfältig abzuwägen, wie sich bereits vorhandene BI-Tools aus der SAP-Welt weiter sinnvoll einsetzen und ergänzen lassen. Und sie müssen Antworten auf wichtige Fragen finden: Ist eine BI-Strategie mit SAP HANA als zentraler Dreh- und Angelpunkt für jedes Unternehmen gleichermaßen sinnvoll?
Integration von HANA in eine bestehende BI-Landschaft
SAP bietet bereits eine große Auswahl an Lösungen rund um das Thema BI und Enterprise-Performance-Management (EPM) an. Schon allein die BI-Plattform "Business Objects 4.0" besteht mittlerweile aus einer Vielzahl von Einzelwerkzeugen wie "WebIntelligence", "Exploration Views" und "Crystal Reports", um nur einige zu nennen. Auch für den Bereich Mobile-BI bietet der Softwarekonzern verschiedene, App- oder Browser-basierte Lösungsszenarien an. Vor diesem Hintergrund überlegen viele Unternehmen, wie ihre BI-Infrastruktur am besten aussehen sollte und ob SAP HANA bestehende Lösungen wie beispielsweise den "Business Warehouse Accelerator" (BWA) oder andere Third-Party-Werkzeuge rund um das Kernprodukt SAP ERP überflüssig macht.
Vorneweg: Tools auf dem Hause SAP arbeiten besser mit HANA zusammen als Werkzeuge anderer Anbieter. Das überrascht wenig, dennoch wäre es wünschenswert, die Entwicklung generischer Treiber stärker voranzutreiben, um auch Nicht-SAP-Tools an die In-Memory-Datenbank anbinden zu können. Erste Tests haben ergeben, dass auch die Schnittstelle zwischen den Systemen eine große Rolle bei der reibungslosen Integration spielt. Auf Basis eines Vergleichstests zwischen SAP- und Nicht-SAP-Tools lassen sich grob drei grundlegende Anwendungsszenarien unterscheiden:
-
Setzt ein Unternehmen unterschiedliche BI-Plattformen ein (SAP und Nicht-SAP), so ist es möglich, SAP HANA in einem "Side-by-side"-Szenario zu nutzen. Dabei werden unterschiedliche Datenquellen via SLT ("SAP Landscape Transformation"), "SAP DataServices" oder "Informatica" mit der SAP-HANA-Box verbunden. Im SAP-HANA-Studio-Modeler kann die Fachabteilung mittels eines Information Composers die unterschiedlichen Quellen kombinieren, verfeinern und für die Analyse zur Verfügung stellen. SAP HANA dient in diesen Fall als reine Datenbank für das zentrale Reporting.
-
Für Unternehmen, die bisher keine Plattform für Business Intelligence verwenden, sondern das Berichtswesen im operativen System aufsetzen, beispielsweise auf SAP ECC, kann SAP HANA ebenfalls eine Option sein. Ausgelieferte Rapid Deployment Solutions (RDS) versetzen ein Unternehmen in kurzer Zeit in die Lage, die Sys-temlast eines operativen Reportings von SAP ECC auf SAP HANA zu verlagern. Dabei werden Datenmodelle und Berichte in SAP Business Objects zur Verfügung gestellt. Gerade im Kontext einer Markt- und Segmentrechnung werden häufig die Anfragen bis auf die Einzelpostenebene vorgenommen. Das führt zu extremen Langläufern und behindert zusätzlich die eigentlichen Aufgaben des operativen Systems. Diese Aufgaben in HANA zu verlagern entlastet die operativen SAP-Systeme.
-
Der zurzeit offensichtlichste Anwendungsfall für eine Integration von SAP HANA in die BI-Landschaft ist die Migration einer bestehenden SAP-Business-Warehouse-(BW-)Installation. Dabei lässt sich mittels RDS der Austausch der konventionellen Datenbank gegen die HANA DB unterstützen. Mit einer BW-on-HANA-Installation erhält der Anwender neue Modellierungsformen, die es ihm erlauben, ein Near-Realtime-Reporting im Unternehmen aufzusetzen oder HANA-Modelle, zum Beispiel auch Nicht-SAP-Quellen, im SAP BW (Business Warehouse) zu integrieren.
Die gesamten Datenmodelle eines BW-Systems werden bei dem Austausch der Datenbank beibehalten, wobei einige der InfoProvider als In-Memory-fähig geschaltet werden, andere davon jedoch ausgeschlossen sind. Unternehmen, deren Upload-Prozesse im SAP BW für die Stamm- und Bewegungsdaten über die Nacht hinausgehen und dadurch eventuell operative Prozesse stark einschränken, werden in einer SAP-HANA-Umgebung in puncto der Aktivierungsläufe von Data Store Objects (DSO) oder aber der Hierarchie-Attributs-Änderungsläufe bei Stammdaten spürbare Beschleunigungen erkennen. Aggregate und fallweise sogar InfoCubes werden obsolet, da DSO über die Möglichkeiten der In-Memory-Technik direkt vom Reporting angesprochen werden können. Hier ergeben sich Möglichkeiten, die BI-Landschaft zu vereinfachen.
Möglichkeiten und Grenzen von HANA
Viel diskutiert wird unter BI-Experten, inwieweit SAP HANA ein Allheilmittel für die gesamte BI-Landschaft sein kann. Vor dem Hintergrund der Kosten einer SAP-HANA-Appliance gilt es, einerseits den Business Case genau zu berechnen, andererseits ist zu prüfen, ob die konventionellen Möglichkeiten innerhalb einer BI-Plattform bereits voll ausgereizt wurden. Dabei darf man nicht nur die Infrastrukturkosten betrachten. Bei einer Einführung von SAP HANA ist auch zusätzliches Know-how im Unternehmen erforderlich: Komplexe Geschäftslogiken, die sich in einem operativen System oder aber in einem BW-System zu Langläufern entwickelt haben, müssen, um von den Geschwindigkeitsvorteilen zu profitieren, in SAP HANA mittels SQL Script neu programmiert werden. Auch Modellierungskenntnisse im "HANA Studio Modeler" sind notwendig, beispielsweise für das Aufsetzen eines zusätzlichen Berechtigungskonzeptes im selben System.
Möchten Unternehmen auf ein BW on HANA migrieren, so ist außerdem zu beachten, dass sich die neuen InfoProvider erst ab dem "SAP BW Netweaver 7.30 Support Package 08"solide nutzen lassen. Dies hat zur Folge, dass eine Vereinfachung von Modellierungsstrecken, beispielsweise der Verzicht auf die InfoCube-Schicht, in Fällen wie einem Bestands-Reporting oder aber der Planung, nicht möglich ist.
Bei Aufgaben rund um Near-Realtime-Reporting bilden die heutigen ETL-Werkzeuge wie SAP DataServices oder Informatica, die per Open Database Connectivity (ODBC) die Daten in SAP HANA bereitstellen, einen extremen Flaschenhals. Auch die Standard-Extraktoren im BW-on-HANA-Kontext werden hier keine Erneuerung erleben. Vielmehr muss über ein Trigger-basiertes Extraktionsverfahren nachgedacht werden, was der Hersteller beispielsweise mit SAP Landscape Transformation (SLT) anbietet. Daraus ergeben sich neben den Reporting-Anforderungen auch neue Vorgehens- und Modellierungsformen in der Extraktion.
Fazit
Unternehmen, die eine heterogene BI-Landschaft betreiben, ermöglicht SAP HANA, über einen semantischen Layer einen zentralen Ort für ein performantes Reporting einzurichten. Dabei sollten jedoch Geschäftslogiken aus den Vorsystemen genau darauf überprüft werden, ob sie in SAP HANA abgebildet werden sollen. Near-Real-time-Anforderungen an das Reporting sind mit den häufig eingesetzten ETL-Werkzeugen nicht erfüllbar. Hier muss die Funktionalität des SLT gerade im Kontext von Nicht-SAP-Systemen näher geprüft werden.
Nutzen Unternehmen bereits das Business Warehouse von SAP, so gilt es, klassische Schmerzpunkte wie "Reporting zu langsam" oder "Datenladeprozess zu lange" genauer zu spezifizieren. Oft sind die konventionellen Möglichkeiten im BW-System noch nicht ausgeschöpft. Sind die Tuning-Maßnahmen im SAP BW jedoch vollständig ausgereizt, kann SAP HANA eine gute Alternative sein. Setzt man ein BW-on-HANA auf, ist eine exakte Konzeption der HANA-Implementierung im Vorfeld notwendig. Nicht alle BW-Daten-Provider sind per Transaktion oder Programm In-Memory-fähig.
Viele Unternehmen im deutschsprachigen Raum, seien es Mittelständler oder Großunternehmen, verwenden SAP BW als zentrale BI-Plattform. Gerade Branchen, in denen große Mengen an Daten anfallen und für das Reporting relevant sind, beispielsweise im Handel mit Bon-Daten oder aber bei Banken in Form von Transaktionsdaten, und deren SAP BW an technische und/oder funktionale Grenzen stößt, oder Unternehmen, die schnell auf Ereignisse reagieren müssen, zum Beispiel Provider von Online-Spielen, sollten sich verstärkt mit SAP HANA auseinandersetzen. (ba)
HANA Partner Race - Softwarepartner bauen HANA-Lösungen für die Praxis
Anfang September 2012 hat SAP den Startschuss für das "HANA Partner Race" gegeben. Mehr als zwei Dutzend Entwicklerteams arbeiten seitdem an neuen Anwendungen für HANA. Zielvorgabe ist, bis zum Frühjahr 2013 marktreife Lösungen präsentieren zu können. Auf der CeBIT will SAP die besten HANA-Lösungen prämieren. Hier einige Beispiele: GFT arbeitet an einer Lösung für Finanzinstitute, mit deren Hilfe sich Risiken bei der Kreditvergabe besser einschätzen lassen sollen. In Echtzeit laufen Daten aus dem Bestandsgeschäft in eine Simulation zukünftiger Kreditportfolien sowie deren zu erwartender Risiken. Information Works entwickelt mit "netWORKS in SAP HANA" ein Analysewerkzeug für soziale Netze. Neben klassischen Kennzahlen wie der Anzahl der "Likes" soll sich damit auch anhand der Vernetztheit und der Online-Aktivität die Wichtigkeit der jeweiligen Personen ermitteln lassen. J&M Management Consulting geht mit einem Werkzeug für Weather Correlated Planning (WCP) an den Start. Damit sollen Unternehmen wetterbedingte Einflussfaktoren besser in ihre Absatzplanung für Produkte wie beispielsweise Eis oder Grillfleisch einbeziehen können. Uniorg baut ein Ordertracking für HANA. Über eine mobile App soll ein Echtzeit-Monitoring von Kundenaufträgen möglicht sein. Die Ciber AG entwickelt mit "Ciber ProfitBoost@Sales" ein Prognose-Tool, mit dem sich durch bessere Vorhersagen der Umsatz steigern lassen soll. Das Tool analysiert, an welchen Stellen Preissteigerungen realistisch sind und sich ohne großen Aufwand im System und den Prozessen umsetzen lassen. Camelot ITLab arbeitet am "Camelot Logistic Transport Cost Analyzer". Damit sollen Unternehmen Logistikprozesse in Echzeit analysieren und verschiedene Transportszenarien simulieren können, um ihr Transport-Management zu verbessern.