Dieser Artikel ist Teil unseres Guides: SAP HANA: Die In-Memory-Lösung von SAP verstehen und nutzen

SAP HANA: Millionen Datensätze schnell und flexibel extrahieren und analysieren

SAP HANA soll das Erstellen von Abfragemodellen im Data Warehouse revolutionieren. Für Business Analytics müssen aber einige Hürden beseitigt werden.

SAP-Verantwortliche reden viel darüber, welch bahnbrechende Wirkung SAP HANA auf die Softwareindustrie habe. Obwohl es viele Anwendungsfälle gibt, in denen sich durch den Einsatz der In-Memory-Anwendung ein Leistungsgewinn von mehreren hundert oder sogar tausend Prozent erzielen lässt: Es wird sich erst mit der Zeit herausstellen, ob SAP HANA tatsächlich das Zeug hat, um als „Game Changer“ die Nutzung und Entwicklung von Enterprise Software zu revolutionieren.

Daten von Hand nach Excel extrahieren

Schon lange bevor SAP eine dominante Stellung im ERP-Bereich einnahm, suchten Unternehmen nach effizienten Möglichkeiten, um ihre Geschäftsdaten in entscheidungsrelevante Informationen umzuwandeln. Das ist ein Grund dafür, warum jede Transaktion in einer Datenbank abgelegt wird. Doch genau darin liegt auch ein Dilemma. Schließlich müssen Unternehmen in der Lage sein, selbst komplexe Fragestellungen durch blitzschnelle Abfragen zeitnah und zufriedenstellend zu beantworten. Dazu müssen die in einer Datenbank gespeicherten Datensätze schnell extrahiert und in ein übersichtliches Berichtsformat transformiert werden. Wie jeder erfahrene Endanwender weiß, sieht die Praxis häufig anders aus. Daten aus SAP ERP müssen manuell und somit zeitaufwendig in eine Microsoft-Excel-Tabelle übertragen und dort für Berichte eigens aufbereitet werden – ob in Form einer Tabelle, eines Diagramms oder einer Grafik.

Mehr zu SAP HANA

Erfahren Sie, wie sich In-Memory-Anwendungen mit SAP HANA sinnvoll einsetzen lassen.

Falls Sie über die Nutzung von SAP HANA nachdenken, lesen Sie hier, wie sich die In-Memory-Plattform implementieren lässt.

Unser Autor geht der Frage nach, ob SAP HANA Business Warehouse ersetzen wird.

Es ist erstaunlich, dass viele Anwender im Zeitalter von Business-Intelligence- (BI)- und Business-Analytics- (BA-) Applikationen, wie etwa SAP BusinessObjects BI, die Daten aus transaktionalen Systemen noch per Hand nach Excel kopieren und dort bereinigen. Erst kürzlich erzählte mir ein Anwender, er habe drei Tage gebraucht, um SAP-Geschäftsdaten in eine Excel-Vorlage zu extrahieren und dort als Management-Report für die monatliche Berichterstattung aufzubereiten. Man stelle sich vor, dieser Anwender könnte in diesen drei Tagen, die er für die Erstellung von Managementberichten braucht, strategisch wichtige Aufgaben bewältigen.

Genau deswegen erblickte vor rund 30 Jahren das Data Warehouse (DW) das Licht der Welt. Von Beginn ging es auch darum, wie schnell ein Data Warehouse sich aufbauen und pflegen lässt. Allerdings haben sich die DW-Anwendungen in Unternehmen über viele Jahre hinweg zu einem umfangreichen sowie unübersichtlichen Datenlager entwickelt und an Leistungsfähigkeit eingebüßt. Angesichts neuer Anforderungen mit denen Unternehmen heute konfrontiert sind, hat sich auch die Sicht des Businesses auf die Daten verändert. Die Verantwortlichen fordern heute Reporting-Prozesse, die hochperformant sind und sich jederzeit flexibel verändern und neuen Geschäfts- sowie Marktanforderungen anpassen lassen.

Diese Problematik konnte bisher durch das Aggregieren von Daten oder den Einsatz des Business Warehouse Accelerator (BWA) als erster SAP In-Memory-Anwendung für schnelle Datenauswertungen weitgehend kompensiert werden. Während der drei Jahre, in denen ich für SAP arbeitete und BWA-Kunden betreute, war die häufigste Reaktion der Geschäftsanwender: „Wir können nicht mehr ohne den Business Warehouse Accelerator leben.“ Obwohl die Datenverarbeitung damit sehr schnell ging, beschwerten sich die Anwender darüber, dass es immer noch ewig dauert, bis die entsprechenden Abfrageberichte aufbereitet sind. Das ist heute nicht mehr vermittelbar. Auswertungen oder Abfrageergebnisse müssen zügig und in einem komfortablen Format über das Web oder ein Mobilgerät bereitgestellt werden.

Schnelle Entwicklung

Leichter gesagt als getan. Zum Beispiel kann es in einem Data Warehouse, das nach den Prinzipien einer Layered Scalable Architecture (LSA) implementiert ist, bei der Datenverarbeitung bis zu sieben Schichten geben. Dadurch verzögert sich der Verarbeitungsprozess, denn dieselben Daten müssen bis zu sieben Mal kopiert werden, bevor sie den BI-Anwendern so aufbereitet zur Verfügung gestellt werden, wie diese es wünschen.

Wird SAP HANA in Verbindung mit der Anwendung SAP NetWeaver Business Warehouse eingesetzt, lässt sich die Anzahl der Schichten theoretisch auf zwei bis drei reduzieren. Für Kenner des SAP NetWeaver BW ist das schwer zu glauben. Zudem scheint es durchaus möglich, dass SAP HANA künftig die Art und Weise komplett verändert wie Abfragemodelle in SAP NetWeaver BW erstellt werden. Diese Aussicht verwirrte allerdings die BW-Entwicklergemeinde. Daher schlug SAP vor, dass Kunden SAP HANA zunächst als Datenbank für SAP NetWeaver BW nutzen.

Zeitnahe Umsetzung, hohe Flexibilität

Durch schnellere Entwicklungszyklen dank agiler Methoden können BI-Systeme den Endanwendern inzwischen deutlich eher bereitgestellt werden als vorher. Das ist ein wichtiger Aspekt, denn es erhöht die Reaktionsgeschwindigkeit. Speziell bei Business-Analytics-Vorhaben eignen sich agile Implementierungsmethoden meinen Erfahrungen zufolge besonders gut, denn häufig kennen die späteren Anwender zu Beginn eines BI-Projekts die Leistungsfähigkeit und die Möglichkeiten des Systems noch nicht.

Wenn Millionen oder gar Milliarden von Datensätzen geladen werden, kommt es in BI-Projekten in der Regel zu längeren Ausfallzeiten, sodass die Entwickler mit ihrer Arbeit warten müssen, bis alle Daten im Data Warehouse vorliegen. Kommt es während der Ladeprozesse dann unverhofft zu Problemen oder Verzögerungen, wird der Entwicklungszyklus aufgebläht und gerät außer Kontrolle. Die Folge ist, dass die Anwender frustriert sind und das Vertrauen in ihr BI-System verlieren. Um diese Probleme zu vermeiden ist eine agile Entwicklung zwingend erforderlich.

Auch die Flexibilität steigt, wenn die Datenmodelle für das Business Warehouse in SAP HANA erstellt werden. Sie lassen sich dann häufiger wiederverwenden als in klassischen Umgebungen sowie auf den bereits extrahierten Daten können zusätzliche und neue Reporting- und Abfrageszenarien sehr viel einfacher entwickelt werden. Voraussetzung dafür sind jedoch hochqualifizierte SQL-Entwickler, die beliebige Skalierbarkeit des Arbeitsspeichers von SAP HANA und der Einsatz agiler Entwicklungsmethoden durch den IT-Systemintegrator, der das BI-Projekt ausführt.

Je ausgereifter diese Bereiche sind, desto eher werden Unternehmen SAP HANA auch in ihre BI-Landschaft einbetten. Eine bahnbrechende Entwicklung ist das aber noch nicht, denn die Anwender erwarten lediglich eine sehr kurze Laufzeit bei Business-Analytics-Abfragen.

Über den Autor: Michael Bestvina ist Head of Mobility beim IT-Dienstleister Xoomworks aus London. Xoomworks unterstützt das Management und die Führungskräfte in Unternehmen bei der Umsetzung mobile Anwendungen. Bestvina beschäftigt sich intensiv mit disruptiven IT-Technologien bei Enterprise Software und deren Einfluss auf auf Geschäftsprozesse und -modelle. Sie können ihm unter @techdisruptive auf Twitter folgen.

Folgen Sie SearchEnterpriseSoftware auf Twitter @sentsoftwarede.

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close