Herausforderungen der SAP S/4HANA-Migration - Teil 2

Herausforderung 1: Sizing

Der Speicherbedarf der SAP HANA-Datenbank ist deutlich höher als bei anderen Datenbanken und steht in direktem Zusammenhang mit der Datenmenge in einer Datenbank. Folglich erfordert eine größere Speichermenge eine höhere CPU-Leistung und mehr Speicherplatz. All dies führt zu einem höheren Endpreis der Hardware. Andererseits können unterdimensionierte Server zu einem deutlichen Leistungsabfall der HANA-Datenbank führen. Außerdem sollte die Planung des Datenbankwachstums nicht vergessen werden (eine spätere Größenanpassung der Hardware könnte sich als schwierig erweisen), und es gibt neben dem Produktionssystem noch andere Systeme wie Entwicklungs-, Test- und Sandbox-Systeme, die ebenfalls umgestellt werden müssen. An dieser Stelle ist es sinnvoll, einen Konvertierungspartner zu kontaktieren, da das Sizing von einem erfahrenen Berater durchgeführt werden sollte.

Herausforderung 2: Datenvolumen

Die Verwaltung des Datenvolumens ist nicht nur wichtig, um die Hardware-Anforderungen niedrig und die Gesamtleistung des Systems hoch zu halten, sondern ist auch eine entscheidende Aktivität während der Konvertierungsvorbereitung. Dies trägt nicht nur dazu bei, die Hardwareanforderungen zu reduzieren, sondern bietet auch die einmalige Gelegenheit, "Müll" wie ungenutzte Stammdaten, veraltete Protokolle, veraltete Daten usw. loszuwerden. Wir empfehlen, mit den Vorbereitungen im Voraus zu beginnen, um genügend Zeit für die Planung und Durchführung von Aktivitäten wie Datenbereinigung und Archivierung zu haben.

Herausforderung 3: Benutzerdefinierter Code

Das Datenmodell in SAP S/4HANA hat sich im Vergleich zu SAP ERP 6.0 erheblich verändert, insbesondere in den Finanz- und Logistikmodulen. Darüber hinaus wird der SAP-Standardcode an diese Änderungen angepasst, sowohl in Bezug auf die Codesyntax als auch auf die Ausführungsleistung. Kundenspezifische Codes, die möglicherweise im SAP ECC-System der Unternehmen vorhanden sind, müssen während des SAP S/4HANA-Einführungsprozesses noch angepasst werden. Bei einer sehr hohen Anzahl von kundenspezifischen Code-Objekten im System kann der Arbeitsaufwand für diese Tätigkeit in Mannmonaten gemessen werden. Daher ist es notwendig, im Vorfeld eine Custom-Code-Analyse durchzuführen (z.B. auf Basis der Custom-Code-Analyse im Rahmen des Readiness-Checks) und die Aktivität sorgfältig zu planen. Benutzerdefinierter Code ist jedoch nur ein Teil von RICEFW (ein Akronym für "Reports, Interfaces, Conversions, Extensions, Forms, and Workflows"), der katalogisiert, kategorisiert und verwaltet werden muss, damit er entweder ausgemustert, ersetzt oder angepasst werden kann.

Herausforderung 4: Datenaufbereitung für CVI

Seit SAP S/4HANA Version 1511 ist "Business Partner" die einzige Möglichkeit, Kunden- und Lieferantenstammdaten im SAP S/4HANA-System zu verwalten. Das bedeutet, dass alle bestehenden Kunden- und Lieferantendaten vor der technischen Umstellung des Systems integriert werden müssen. Obwohl das CVI Cockpit als zentrales Werkzeug für die Umstellung eine große Erleichterung darstellt, müssen einige Schritte im Vorfeld durchgeführt werden und können nicht automatisiert werden, z. B. die Datenbereinigung (Deduplizierung, Entfernung veralteter Daten und Ermittlung von Beziehungen zwischen Kunden- und Lieferantendaten) und Entscheidungen über Nummernkreise.

Herausforderung 5: New General Ledger (New GL)

Der Einsatz der neuen Anlagenbuchhaltung ist in SAP S/4HANA nötig, was die Verwendung des SAP New General Ledger erfordert. Die Migration vom klassischen Hauptbuch zum neuen Hauptbuch kann auf zwei Arten erfolgen:

1. als komplette Migration, in einem separaten Projekt vor der Umstellung auf SAP S/4HANA, mit allen neuen Funktionalitäten wie Belegaufteilung oder parallele Rechnungslegung.
2. als Migration während der Umstellung, bei der nur die Mindestfunktionalitäten aktiviert werden (technisches Upgrade auf New GL). Zusätzliche Funktionalitäten können nach Abschluss der Umstellung aktiviert werden.

Da die erste Option zeit- und ressourcenaufwändiger ist als die zweite, ist es wichtig, die geschäftlichen Anforderungen und Vorteile einer vollständigen Migration sorgfältig zu analysieren, das Reengineering der Prozesse zu planen und zu entscheiden, in welchem Umfang die neue GL genutzt werden soll.

Herausforderung 6: Testen von Verfahren und Ergebnissen

Testläufe sind ein wichtiger Bestandteil in jedem Implementierungs- und Migrationsprojekt. Sie umfassen Unit-, Integrations- und Benutzerakzeptanztests, die in verschiedenen Systemen und unterschiedlichen Migrationsphasen durchgeführt werden. In einem Konvertierungsprojekt ist es schwieriger Fehler zu korrigieren als bei einer Neuimplementierung, da in den meisten Fällen die einfache Erstellung eines neuen Transportauftrages mit einer Korrektur nicht möglich ist. Daher ist es wichtig, nicht nur die Ergebnisse der Konvertierung, sondern auch den Konvertierungsprozess selbst zu testen. Es kann notwendig sein, die Konvertierung mehrmals zu wiederholen, und zwar in Entwicklungs- und Testsystemen sowie in einem oder mehreren Sandbox-Systemen (Hardware-Ressourcen!), die dem Produktivsystem so weit wie möglich ähneln. Dies verlängert das Projekt, aber man sollte keine Abkürzungen nehmen in der Hoffnung, dass die erfolgreiche Konvertierung eines Systems auch die erfolgreiche Konvertierung eines anderen Systems bedeutet.

Herausforderung 7: Konvertierungsverfahren verfeinern

Die Methoden für Systemkonvertierungen sind allgemein bekannt, aber da sich jede Systemlandschaft (und jedes System) individuell von anderen unterscheidet, muss ein detailliertes Verfahren für die Konvertierung jeder Landschaft erstellt werden. Dies muss während der Konvertierung des ersten Systems (Entwicklung oder Sandbox) geschehen und während der Konvertierung der anderen Systeme verfeinert werden. Schließlich sollte daraus ein detailliertes Skript für die Umstellung des Produktionssystems resultieren.

Herausforderung 8: Umstellung

Die Konvertierung von Produktionssystemen findet in der Regel während eines Ausfallzeitfensters statt; in den meisten Fällen an einem Wochenende. Um die Konvertierung unter solchen zeitlich begrenzten Umständen abzuschließen und den Benutzern zu Beginn ihres Arbeitstages ein konvertiertes System zu liefern, muss das Migrationsteam die genaue Abfolge der Aktivitäten und deren Dauer kennen. Daher ist es notwendig, die Umstellung auf der Grundlage geprüfter und vereinbarter Umstellungsprozeduren (siehe oben) sorgfältig zu planen. Außerdem muss ein "Dry Run" auf einem System durchgeführt werden, das mit dem Produktionssystem weitgehend identisch ist (neues Sandbox-System), um zu überprüfen, ob die Umstellung im geplanten Zeitrahmen durchgeführt werden kann.