Vorbereitungen für die Hana-Reise

Die Erfahrung zeigt: Hana hilft im Kontext von ERP eher in speziellen Szenarien, die durch In-memory-Technologie beschleunigt werden können. Dazu gehören sowohl Klassiker wie die Ergebnis- und Marktsegmentrechnung oder die Logistikinformationssysteme als auch lang laufende Prozesse wie die Gehaltsabrechnung im Personalwesen oder die Materialbedarfsplanung.

Einige der Module und Prozesse für Hana müssen aktuell optimiert werden. Bei anderen Anwendungen beginnt SAP eine komplette Runderneuerung. Die erste in einer Reihe der sogenannten S-Innovations ist SAP Simple Finance. Weitere auf Hana beruhende Lösungen sind geplant.

Im Business-Warehouse-Bereich ist das anders. Eine einfache 1:1-Migration von einer klassischen Datenbank auf Hana kann die Performance deutlich verbessern. Natürlich wird dadurch ein schlechtes Datenmodell nicht automatisch in ein gutes, effizientes umgebaut.

Eine Migration kann ein erster, einfacher Schritt zum Erschließen von „Quick Wins“ im Bereich Performance und Systembetrieb sein. Die sollte aber immer mit begleitenden Projekten – von Housekeeping über Datenmanagement (Nearline Storage oder Smart Data Access) und Code-Optimierung bis zu Systemmonitoring oder Alerting – verbunden werden. Eine reine Migration auf Hana ist ein guter erster Schritt, aber hebt noch lange nicht das vorhandene Potenzial.

Zweifelsohne ist Hana ein großer Wurf, dennoch handelt es sich dabei „nur“ um eine Datenbank. Wenn die Datenmodellierung nicht optimal ist, kann dies auch bei Hana die Performance verringern. In einigen Fällen arbeitet die Plattform sogar langsamer als die bisherige „klassische“ Datenbank.

Der Grund hierfür ist, dass in SAP-Systemen bisher viel Arbeitslast auf den Applikationsservern lag, weshalb die Programme auch darauf ausgelegt sind. Wenn die SAP-Systeme nun komplett auf Hana laufen, um die Geschwindigkeit der In-memory-Technologie auszuschöpfen, ist es empfehlenswert, die Datenmodellierung und gegebenenfalls auch den Abap-Code anzupassen.

Einfacher Betrieb als Datenbank

Hana ist im Praxisbetrieb als Data Warehouse eigentlich einfach zu betreiben, beispielsweise als Ersatz für eine herkömmliche Datenbank. Dabei ist weder eine Vielzahl spezieller Engines noch Hana-Studio nötig.

Von den Vorteilen, insbesondere hinsichtlich der Geschwindigkeit und der damit verbundenen Flexibilität im Reporting, können vor allem im BW-Umfeld alle SAP-Kunden profitieren.

Der Mythos einer „teuren Migration auf Hana“ ist unbegründet. In der Praxis verbinden SAP-Anwenderunternehmen die Migrationsprojekte aber meist mit anderen, längst überfälligen Projekten.

Die Klassiker dafür sind Systemkonsolidierungen, Harmonisierungen, Upgrades, Archivierung/NLS, Unicode-Umstellungen, Outsourcing oder auch Prozessänderungen. Durch solche integrierten Projekte werden Migrationen auf Hana fälschlicherweise als langwierig, teuer und schwer zu handhaben wahrgenommen.

On demand oder on premise?

SAP-Anwenderunternehmen können Hana sowohl on demand als auch on premise nutzen. Auch in der On-pre­mise-Variante können Unternehmen die Technologie mit einem angemessenen Aufwand betreiben.

Sie profitieren davon, dass sie Hana besser kontrollieren und wertvolle Erfahrungen sammeln können. Für andere Firmen ist die Alternative on demand geeigneter. Sie sollten dabei den Vertrag inklusive der vereinbarten Service Level Agreements prüfen.

Für die Einführung von Hana und die Durchführung einer Migration bedarf es auf jeden Fall etwas mehr als bei einer reinen Migration des Betriebssystems oder der Datenbank.

Durch die In-memory-Technologie müssen das Datenmodell und der Systembetrieb angepasst werden, um das System fit für die Zukunft zu machen.

Nicht alle Daten migrieren

Bei der Einführung stellen Hardware- und Softwarekosten die größte Herausforderung für Unternehmen dar. Darüber hinaus wächst der Bestand an Daten kontinuierlich an, während ihr Wert gleichzeitig abnimmt.

Der Schlüssel ist an dieser Stelle die elektive Systemmigration nach Hana. Diese ermöglicht nicht nur eine unkomplizierte Einführung, sondern auch eine Reduktion der Systemgröße, Verbesserung der Ladeperformance sowie eine Senkung der Betriebskosten.

Anstatt das ganze System einfach zu kopieren, wird auf Basis des Datenmodells des Produktivsystems ein Leersystem erstellt – jedoch ohne Transaktionsdaten oder Masterdaten.

Entsprechend vordefinierten Auswahlkriterien wie zeitlichen oder organisatorischen Kriterien werden Daten ins neue Hana-System migriert. Die geschäftskritischen Daten bleiben dabei immer und in Echtzeit zugänglich.

Gleichzeitig lassen sich somit die Total Cost of Ownership (TCO) senken, da ausschließlich relevante Daten migriert werden und die gesamte SAP-Landschaft vereinfacht wird.

Effektives Hana Sizing

Für das Hardware Sizing der Hana Appliance gibt es verschiedene Möglichkeiten, das Sizing in der „Nicht-Hana“-Umgebung durchzuführen:

• Hana Sizing mit QuickSizer Tool – ein webbasiertes Tool, das über den SAP Service Marketplace ausgeführt wer- den kann
  Hana Sizing mit DB-spezifischen Scripts – Download über SAP Note 1637145 – SAP BW on Hana: Sizing SAP In-Memory Database
• Hana Sizing mit einem Abap-Report – Download über SAP Note 1793345 – Sizing for SAP Suite on Hana
• DataVard BW Fitness Test
  • Proof of Concept für das Migrations-
  projekt auf Hana

Abap-Report ist der Standard

Die meisten SAP-Anwenderunternehmen verwenden den Abap-Report. Er prüft alle Objekte (Tabellen, Größen) in der „Nicht-Hana“-Umgebung. Aufbauend auf den Ergebnissen schlägt der Abap-Report ein dediziertes Sizing vor.

Dies beinhaltet unter anderem Speicher für Row Store, Spaltenspeicher, Zeilenspeicher, CPU, Disks usw. Der Output für den Abap-Report sieht beispielsweise folgendermaßen aus:

Der Abap-Report rechnet nicht mit ADK-Technologie (Archive Development Kit). Das führte bei einem Unternehmen beispielsweise dazu, dass 6 TB Daten in archivierten Dateien verloren gegangen sind.

In diesem Fall war Hana von Beginn an zu klein angesetzt. Zudem bezog sich der Abap-Report nicht auf die Datenbank „Deep Compression“ (abgesehen von der DB2-Kompression).

Conclusion

Hana ist kein Allheilmittel, aber die In-memory-Technologie ist eine äußerst schnelle Datenbank. Sie bringt sowohl im ERP- als auch im Business-Warehouse-Bereich große Vorteile.

Unternehmen sind gut beraten, diese Vorteile zu nutzen. Sie sollten sich aber auf jeden Fall im Vorfeld darüber Gedanken machen, wofür sie Hana einsetzen wollen. Daraus können sie ein zwingend notwendiges Datenmanagement ableiten.

Die große Frage lautet: Welche Daten müssen in Echtzeit im Hauptspeicher vorgehalten werden? Aus diesem Grund werden das Datenmanagement und das Information Lifecycle Management auch immer wichtiger.

Zweifelsohne gehört Hana die Zukunft. Aber die meisten SAP-Anwenderunternehmen müssen sich noch effizient darauf vorbereiten. Denn auch bei Migrationen auf Hana gilt: Die Vorbereitung ist entscheidend.