Ready for Hana?
Mit dem Hana Readiness Audit steht eine neutrale, marktkonforme Überprüfung der SAP-Systeme in Bezug auf die Migration der Datenbank nach Hana zur Verfügung.
Damit ist es möglich, eine bessere Planbarkeit eines bevorstehenden Hana-Projektes für IT und Fachseite und eine Kostenersparnis bei der Hana-Migration durch gute Vorbereitung und automatisierte Faktenbeschaffung zu erlangen.
Zu Beginn steht die detaillierte Vermessung der betreffenden SAP-Systeme. Diese werden mit einem Erfahrungsschatz verglichen, der über das SAP-Marktwissen von über 4500 analysierten SAP-Systemen verfügt.
Anhand von SAP-Systemen, die über einen Zeitraum sowohl auf AnyDB und nach einer Konvertierung auf Hana vermessen wurden, kann Alegri Aussagen zum erwarteten Verhalten des Systems auf Hana treffen.
Schwerpunkte der Vermessung sind die Analyse der Datenbank, Eigenentwicklungen und Add-ons sowie die Migration auf S/4 Hana.
Datenbank:
Sie ist das Kernstück der Datenkonvertierung von AnyDB nach Hana. Diese sollte man zuvor analysieren, da DB-Größe und -Wachstum ausschlaggebend für das Hana Sizing ist.
Außerdem ist eine bereitgestellte Hana-Instanz nicht leicht zu ändern – außer sie wird aus der Cloud bezogen. Eine Migration ist auch ein guter Zeitpunkt, um GDPdU-konform zu bereinigen.
Ein Teil der Daten, die von SAP gespeichert werden, sind (technische) Logs, wie z. B.: DBTABLOG, oder übertragende IDOCS, wie die Tabellen EDIDC oder EDIDS.
Erst die Transparenz über Existenz und Datengröße kann eine fundierte Entscheidung zum weiteren Vorgehen untermauern.
Auch für andere Daten gibt es verschiedene Kriterien zur Archivierung oder Housekeeping. Dies spart nicht nur teure Hardware, sondern verbessert auch die Performance und erleichtert die Migration.
Eigenentwicklungen/Add-ons:
Bei jeder Veränderung am SAP-System spielen Eigenentwicklungen eine besondere Rolle und sind meist Aufwandstreiber. Bei den ersten Migrationen von ERP-Systemen (nicht SAP BW) auf Hana war oft nach dem Projekt die Ernüchterung groß, dass die Antwortzeit sich nicht verbessert, sondern sogar stellenweise verschlechtert hatte.
Daran hatten Eigenentwicklungen und Add-ons einen hohen Anteil. Beide wurden jahrelang auf die traditionellen zeilenorientierten Datenbanken optimiert.
Eine große Erleichterung ist hier die Transparenz über Nutzung und Lastverhalten. Mit dem Wissen über die Nutzung von Eigenentwicklungen spart man Geld und Zeit, nicht genutzte Eigenentwicklungen auszulassen, und mit der Kenntnis des Lastverhaltens von Eigenentwicklungen lassen sich diese wiederum schneller optimieren.
Add-ons kommen von Drittherstellern. Diese können und sollten nicht selbst optimiert werden. Hier ist es wesentlich, eine Übersicht der wichtigen und meistgenutzten Add-ons zu bekommen: Dann lässt sich beim Hersteller ein für Hana bzw. S/4 optimiertes Release anfordern.
Anwendungsebene:
Im Falle einer Migration auf S/4 Hana ist auch der Blick auf die Anwendungsebene nötig. Auf Basis der genutzten Geschäftsprozesse wird ein Bericht erstellt über:
Prüfung, welche genutzten Transaktionen in S/4 Hana abgelöst werden Angabe, welche Transaktionen die abgelösten ersetzen Auflistung neuer Funktionen in S/4 Hana, die für die bisherigen Geschäftsprozesse infrage kommen Checkliste, welche Funktionen sich mit S/4 Hana verändern Gerade bei einer Konvertierung (Migration eines bestehenden SAP-Systems/Brownfield Approach) ist diese Analyse wichtig.
Im Falle eines Neuaufbaus (Greenfield Approach) unterstützt die Analyse beim Design der neuen Geschäftsprozesse.
Informationen:
Neben den genannten Punkten stellt das Hana Readiness Audit weitere Informationen (Releasestände, Nutzungsbereiche, Lastvolumina und weitere Größen) zur Umstellung bereit. Diese werden automatisiert zusammengestellt, sodass manuelle, potenziell fehlerträchtige Arbeit vermieden ist.
Zusammenfassung
Bei den meisten Kunden stellt sich nicht mehr die Frage ob, sondern wann auf Hana migriert wird. Das Hana Readiness Audit nutzt die Erfahrungen des Marktes und wendet diese auf das zu migrierende SAP-System an. Dies führt zu realistisch geplanten Projekten bei der Umstellung auf Hana als Datenbank oder S/4 als System.
