Umstieg auf SAP S/4HANA über ein Conversion Vorprojekt

Viele Unternehmen beschäftigen sich zur Zeit mit der Frage, welcher Weg am besten geeignet ist, bis 2027 auf S/4HANA umzusteigen. Der beste Weg ist dabei sicherlich je nach Unternehmen ein anderer. In diesem Blog Artikel beleuchten wir die technische Umsetzung der Brownfield Conversion.

Mit einer S/4HANA Conversion (auch bekannt als Brownfield-Ansatz) kann man mit den entsprechenden Rahmenbedingungen sehr schnell nach S/4HANA gelangen. Im Gegensatz dazu fängt man bei sogenannten Greenfield-Projekten ganz von vorne an, indem man seine Prozesse auf leeren S/4HANA Systemen neu definiert.

Projektscope im SAP S/4HANA Conversion Vorprojekt

Zur Zeit begleiten wir ein Brownfield-Kundenprojekt, bei welchem die SAP ERP Business Suite Landschaft mittels S/4HANA Conversion auf S/4HANA 2022 aktualisiert wird. Die Systeme des Kunden sind sehr nah am SAP-Standard und vom Umfang her gut überschaubar, weswegen der Conversion-Ansatz hier bevorzugt wird. Der eng gesteckte Zeitrahmen ist notwendig, um die Conversion vor einem zukünftigen SAP-Rollout in weiteren Ländern abzuschließen. Das Ziel ist, das System „as-is“ zu konvertieren und nur die mindestens notwendigen Anpassungen durchzuführen, wie zum Beispiel die obligatorische Ablöse diverser FI-Transaktionen durch Fiori Apps.

Um frühzeitig mögliche Fallstricke zu erkennen, wurden Sandboxen erstellt, auf denen eine Test-Conversion durchgeführt werden sollte. Die zwei Sandbox Systeme wurden in der Cloud bei AWS von SPIRIT/21 aufgebaut und werden dort auch von uns betrieben.

Die Conversion haben wir dann auf technischer Seite von der SPIRIT/21 vorbereitet, begleitet und durchgeführt.

Außerdem muss der Kunde im Vorfeld auch ein Update seiner bestehenden HANA Systeme von SLES 12 SP5 auf SLES 15 SP4 durchführen, da nur diese Version als OS für die HANA Datenbanken zugelassen ist. Das war für ERP 6.0 noch anders.

Im weiteren Verlauf wird die Conversion via SUM gestartet und verhält sich zu großen Teilen sehr ähnlich zu einem „normalen“ Upgrade eines SAP-Systems. Besonders bei den Add-Ons musste in der Sandbox viel Zeit aufgewendet werden, da die 3rd-Party Hersteller nicht schnell genug eine Lösung liefern konnten. Es dauerte etwa drei Wochen, bis alle Add-Ons „ready“ waren. Hier sollte man schon im Vorfeld eine ausführliche Analyse durchführen und die Anbieter kontaktieren.

Die eigentliche technische Konvertierung lief dann fast reibungslos durch und die Sandbox war in wenigen Stunden konvertiert.

Post-Processing / Downtime Optimization in der SAP S/4HANA Transformation

Im Nachhinein laufen dann noch die sogenannten Silent Data Migrations (2907976 - Silent Data Migration (SDMI) - FAQ). Hier werden Applikationsdaten automatisch nachmigriert. Man hat die Wahl, das während der Downtime oder danach zu tun. Wir konnten dadurch einige Stunden Downtime einsparen.

In Zusammenarbeit mit dem Kunden wurden dann mittels Fiori Rapid Activation das Launchpad konfiguriert und erste Apps für den FI-Bereich eingerichtet.

Zusammengefasst noch einmal wichtige Punkte, die aus dieser ersten Conversion mitgenommen wurden:

• Add-Ons sollten frühzeitig auf Kompatibilität geprüft werden
• Vorrausschauende Planung für APO / SCM ist notwendig, falls im Einsatz
• Default Security Profile Parameter überspringen und im später abgleichen, da sehr restriktiv
• Silent Data Migration kann viele Stunden Downtime sparen
• Im Nachgang auf HANA-Seite NSE (Native Storage Extension) prüfen, da dies mit der Konvertierung automatisch aktiviert wird.
• Der Kunde evaluiert aktuell das konvertierte Sandbox-System, um zu entscheiden, ob wir direkt in der produktiven Landschaft weitermachen können.