Erkenntnisse aus der Praxis Erfolgreiche Migration auf S/4HANA

Viele Unternehmen haben einen wichtigen Punkt auf ihrer Agenda: Es zeichnet sich die Migration auf S/4HANA ab – und damit der Umstieg in eine „neue Welt“. Doch wie sehen die Voraussetzung für die Umstellung aus? Was ist technisch und beim Know-how der Mitarbeiter und Dienstleister zu beachten? Antworten auf diese und andere Fragen geben zwei SAP-Spezialisten aus dem Haus Fujitsu: Manuel Thalhofer, Offering Manager SAP Services und André Weller, Head of SAP Commerce & Analytics.

Nicht nur die Technik

Steht die Migration von einer bestehenden SAP-Umgebung auf die HANA-basierte S/4HANA-Suite an, gibt es – abhängig von der Migrations- beziehungsweise Konvertierungsmethode – technische Voraussetzungen, die eine Konvertierung erst ermöglichen. Aber auch hier gilt, so Manuel Thalhofer, Offering Manager SAP Services bei Fujitsu: „Der Weg zu S/4HANA ist nicht nur technischer Natur. Die Umstellung betrifft auch die Mitarbeiter der IT-Abteilung, die das notwendige Datenbank-Know-how haben müssen. Das reicht vom Programmierer, da es eine neue Art des Coding gibt, bis hin zum Fachbereich.“

Denn die Prozesse und Oberflächen verändern sich so, dass Know-how bis auf die Fachbereichsebene aufgebaut werden muss. Gefragt sind zudem neue Auflistungen, so André Weller, Head of SAP Commerce & Analytics bei Fujitsu: „Aufgrund der Zusammenführung von Tabellen – Stichwort Simplifizierung – sind hier neuartige Ansätze gefragt. Eine Umstellung bedeutet daher die Validierung und/oder Aufnahme des aktuellen Standes aus technischer Sicht, sowie der aktuell genutzten Prozesse. Dazu ist es vor allem wichtig, die notwendigen Vorarbeiten zu analysieren, eine vernünftige Umstellung aufzubauen.“ Für den Experten gehören dazu sowohl die Umstellungsmethodik, als auch das Einplanen von Mitarbeiterschulungen und Workshops. Zudem sollten ausgewählte Oberflächen mit einem motivierten Key User-Kreis getestet werden.

Stehen derartige Änderungen in der IT-Umgebung an, stellt sich für die IT-Verantwortlichen immer die Frage, ob spezielle Datenvorbereitungen nötig sind. Es geht dabei meist um Themen wie die Datenqualität, denn es macht Sinn, nicht mehr benötigte Daten – den vielzitierten Datenmüll – zu entfernen. Zudem stellt sich die Frage, ob man nicht mehr benötigten Code ebenfalls löschen sollte.

Hier empfiehlt Manuel Thalhofer: „Im Rahmen der Konvertierung gilt es, vorab zu prüfen, welcher Code umgestellt werden muss und ob es überhaupt sinnvoll ist, einen Code umzustellen.“ Nach seiner Ansicht müsse nicht mehr benötigter Code nicht zwingend entfernt werden. Dennoch mache es Sinn, sich im Rahmen der Konvertierung oder Migration auch „historische Daten“ – den Datenmüll – anzuschauen – Stichwort Lifecycle Management. „Als einen positiven Nebeneffekt ergibt sich nicht nur die Reduzierung von Speicherplatz, sondern damit zusammenhängend auch die Minimierung finanzieller Aufwände, da weniger Wartungsarbeiten benötigt werden. Allgemein ist es sinnvoll, dies nicht nur im Rahmen einer Konvertierung durchzuführen, sondern auf regelmäßiger Basis.“

André Weller geht sogar noch einen Schritt weiter: „Die Code-Umstellung sollte bei erfahrenen Entwicklern eines Dienstleisters liegen, die auch ABAP for SAP HANA sowie die Ausgangsanalyse beherrschen.“ Fujitsu beispielsweise stelle ein Coding in der Regel so um, dass die Logik komplett auf der Datenbank erfolgt und die Prozesse um ein Vielfaches beschleunigt werden. „Aber auch hier sollte man sicher immer fragen, wo es sich wirklich lohnt, umzustellen und sich darauf beschränken“, empfiehlt Weller. „Diese Analyse und Bewertung machen wir in der Regel vor jeder Umstellung.“

Zielvorstellungen

Die wichtigste Aufgabenstellung, so Thalhofer, für Unternehmen sollte heutzutage lauten: „Die Geschäftsprozesse sind so abzubilden, dass sie sich agil auf Veränderungen anpassen lassen. Das ist ein echter Kurswechsel: Die letzte Dekade wurde hauptsächlich darauf verwendet, bestehende Geschäftsprozesse immer effizienter abzubilden. Das ging aber leider häufig auf Kosten der Agilität. Das muss sich nun ändern, damit Unternehmen mit dem raschen Wandel, der mit der Digitalen Transformation einhergeht, schritthalten können.“

Damit rückt das Unterstützen neuer Business Cases in den Mittelpunkt. „Ein wichtiger Aspekt ist die Verbindung aus Business Analytics und den Echtzeit-Daten, die ein Unternehmen generiert“, wirft Weller ein. „Die bei S/4HANA zugrunde liegende Datenbank, SAP HANA, bietet den Vorteil, dass sich Geschäftsdaten schnell und zielgerichtet abrufen und visualisieren lassen.“

Wenn es darum geht, bestehende Anwendungen auf die neue Plattform heben, empfiehlt sich der Einsatz von Spezialisten: „Die Migration von Alt-Systemen auf SAP HANA ist für Fujitsu als SAP-Partner eine der absoluten Kernaufgaben“, stellt Thalhofer heraus. „Hier gibt es keine Standardlösung, die sich auf alle Unternehmen anwenden lässt, denn jede Legacy-IT ist individuell und erfordert eine eigene Vorgehensweise.“

Auf die Frage, wie der Wechsel auf S/4HANA zu vollziehen sein, gibt Weller zu Protokoll: „Das hängt ganz klar vom Modell ab, sprich: Geht es um eine Konvertierung oder um einen Neuaufbau mit Übernahme der Altdaten. Letzteres macht in vielen Fällen Sinn, wenn die Voraussetzungen, um die Migration zu schaffen, einen sehr hohen Aufwand bedeuten würden.“

Bei einer Migration sollte man in der Regel mit einer Sandbox-Umgebung starten, also einer Testmigration. Damit ergibt sich eine relative Unabhängigkeit von der bestehenden Systemlandschaft. „Die Erfahrungen, die dort mitgenommen werden“, so Weller, „fließen in die eigentliche Migration mit ein. Das beinhaltet Codeumstellungen, Abschlüsse, eventuell die Migration auf das neue Hauptbuch, etc. Der Grund für dieses Vorgehen ist, dass ein Entwicklungssystem in der Regel nur wenige Daten enthält. Es ist daher nur geringfügig aussagekräftig – zum Beispiel in Hinblick auf die Migrationsdauer und Codeoptimierung – und die Sandboxumgebung eine Kopie des produktiven Systems. Bei einem Neuaufbau sieht dies schon anders aus.“

Infrastruktur

Wo die Infrastruktur für die neue S/4HANA-Umgebung steht, kann das Anwenderunternehmen je nach Bedarf entscheiden. Das hängt oftmals von den jeweiligen Compliance- und Netzwerk-Anforderungen ab oder ob Anwenderunternehmen zum Beispiel lieber in die eigenen Rechenzentren investieren möchten, erläutert Thalhofer. „In jedem Fall sollte darüber nachgedacht werden, SAP-Systeme als Service zu beziehen. Dies ist on-premise, in der Cloud, aber auch in Kombination möglich und vereinfacht die Implementierung.“ Erfahrungsgemäß erfolge ein kompletter Wechsel zu Software-as-a-Service selten, so Thalhofer weiter. „Viele Kunden wählen für ihre IT einen hybriden Ansatz, wenn sie heute Cloud-Dienste nutzen. So können sie viele Dienste und Applikationen weiterhin lokal mit einem Server betreiben, ergänzt mit Apps aus der Cloud.“

Ein wesentlicher Aspekt bei der Umstellung betrifft die neue Datenbank – SAP HANA. „In der Regel wird diese Aufgabe in bestimmte Phasen gegliedert“, führt Weller aus. „In der ersten Phase stehen die Vorbereitungen und das Schaffen aller Voraussetzungen für eine erfolgreiche Umstellung an. Dies ist nicht zu unterschätzen. Für die komplette Nutzung von S/4HANA Finance beispielsweise ist eine vorige Migration von Classic GL auf New GL notwendig. Das bedeutet in der Regel ein eigenes Projekt oder auch Upgrades bei der alten Datenbank, dem Betriebssystem oder anderen Teilen.“

Anschließend kommen, so Weller, die Pre-Migration-Schritte, um die bestehende auf die neue Umgebung vorzubereiten. „Hier stellen sich Fragen wie: Ist das System überhaupt bereit zur Migration mit Umstellungen und Codeanalyse?“ Die Migration selbst erfolge in der Regel mit Hilfe von Distributed Management Objects, erklärt Weller. „Dabei erfolgt ein Upgrade auf das notwendige Release, oder etwa die Umstellung auf Unicode gemeinsam mit der Datenbankmigration in einem Schritt. Das reduziert auch den notwendigen Testaufwand. Anschließend sind noch Nacharbeiten durchzuführen.“

Nach dem technischen Datenbankaustausch ist das System noch auf S/4HANA umzustellen, etwa auf S/4HANA Finance. Außerdem muss im Vorfeld die Umgebung für SAP Fiori aufgebaut werden. Das betrifft das Gateway, Zugänge, Berechtigungen zur Anzeige der neuen Applikationen, Umstellung von kundenspezifischen Anwendungen auf SAP Fiori etc. „Anders sieht dies bei einem Neuaufbau aus“, gibt Thalhofer zu Protokoll. „Hier steht neben dem Customizing in einem neuen System die Herausforderung vor allem bei der Übernahme der Altdaten in das neue System an, etwa mittels SAP Landscape Transformation.“

Generell sollte man vor dem Umstieg auch eine Risikobewertung durchführen. Hierbei helfen die Analyse der bestehenden Landschaft und die anschließende Bewertung mithilfe eines Beraters. „Zudem lässt sich das Risiko einer Umstellung mit dem Aufbau einer Sandbox-Umgebung beziehungsweise durch einen möglichen Proof of Concept – POC – reduzieren“, erklärt Weller. „So ist es möglich, zu analysieren, wo wirklich die Probleme und Aufwände entstehen. Aus diesem Grund stellen wir vor jeder Migration ein POC oder eine Sandbox-Umgebung zur Verfügung. Wie erwähnt dienen die daraus gewonnenen Erkenntnisse für die eigentliche Umstellung der Systemlandschaft.“

Zudem könne die Umstellung der Systemlandschaft schrittweise erfolgen. So würde man im ersten Schritt nur eine Datenbankmigration absolvieren und erst zu einem späteren Zeitpunkt eine Umstellung der Prozesse und/oder der Oberflächen. „Dies ist immer abhängig von der Ist-Situation und vom Bedarf des Anwenders“, bringt es Weller auf den Punkt. „Zudem setzen wir bei einer gewünschten Umstellung auf S/4HANA auf unsere Projektmethodik Process/4. Hier können wir auch dem Kunden zeigen, wie aktuelle Prozesse aussehen, wie sie wirklich laufen, welche Kosten dadurch entstehen und was eine Optimierung der Systemlandschaft mit einer Migration mit sich bringen kann. Neben dieser Bewertung nutzen wir, aufgrund der Erfahrungen, die wir hier seit Jahren sammeln konnten, Abläufe, welche das Risiko weiter minimieren.“

Rainer Huttenloher

Hier geht es zu Fujitsu