S/4HANA System Conversion

S/4HANA System Conversion: Business Downtime senkt man mit Methodik – nicht mit Hoffnung

Jede Stunde Business Downtime hat einen Preis – und ist in Conversion-Projekten meist kein Naturgesetz, sondern das Ergebnis von Messdaten, Methodik und Governance. In vielen S/4HANA-System-Conversion-Projekten entsteht die „gefühlte Downtime“ nicht im eigentlichen SUM-Block, sondern in den nachgelagerten Post-Aktivitäten, in der FI/ML-Datenkonvertierung und in der Business-Validierung. Genau dort eskaliert der Cutover, wenn technische und fachliche Aktivitäten nicht sauber entkoppelt und vorgezogen werden.

Für die frühe Phase liefert der Planned Downtime Calculator im SAP Readiness Check eine modellbasierte erste Abschätzung der geplanten Business Downtime – auch ohne eigene Run-Historie. Der Planned Downtime Calculator bietet einen Überblick über die gesamte geplante Dauer der Geschäftsunterbrechung, die während der Umstellung auf SAP S/4HANA zu erwarten ist. Es gibt mehrere Optionen für die Durchführung einer Umstellung auf SAP S/4HANA. Die angezeigten Laufzeiten gelten jedoch nur für eine Standardumstellung über den Software Update Manager innerhalb eines einzigen Rechenzentrums.

Downtime ≠ Downtime

Die nüchterne Einordnung gehört am Anfang auf den Tisch. Bei der Wahl des SUM-Vorgehens wird primär die technische Downtime beeinflusst – der fachliche Abschluss und die Business Downtime werden dadurch nicht automatisch verkürzt. SAP weist zudem darauf hin, dass die Downtime-Optimized Conversion (DOC) Limitierungen/Restriktionen hat und die Gesamtlaufzeit trotz Downtime-Reduktion hoch sein kann (Datenvolumen, FI-Inkonsistenzen).

Neben dem Standardansatz existieren – je nach Szenario – Hebel wie Downtime-Optimized DMO, die Teile der technischen Verarbeitung in die Uptime verschieben. Die datengetriebene Konvertierung bleibt dennoch ein separater Brocken.

Quelle: learning.sap.com

Downtime-Optimized Conversion

Downtime-Optimized Conversion geht hier einen Schritt weiter und verlagert ausgewählte Downtime-relevante Konvertierungs- und Migrationsaktivitäten teilweise in die Uptime. Während der Uptime laufen Teile von Migration und Datenumstellung bereits im Hintergrund, obwohl die Fachbereiche weiter im System arbeiten. Dadurch können sich Daten in Tabellen verändern, die zu diesem Zeitpunkt schon verarbeitet wurden. Um diese Parallelität sauber zu beherrschen, setzt der Update-Prozess auf eine triggerbasierte Protokollierung. Änderungen, die während der Uptime entstehen, werden mitgeschrieben und in einer späteren Phase kontrolliert nachgezogen. Das Prinzip ist vergleichbar mit Verfahren wie nZDM sowie Downtime-optimierten Migrationsansätzen (z. B. DMO).

Quelle: learning.sap.com

Die Abbildung zeigt zum einen den Standardlauf mit klassischen Pattern. FI-Delta-Customizing wird typischerweise erst nach dem SUM-Lauf erzeugt. Dadurch landet die Arbeit in Post-Aktivitäten/Validierung und verlängert faktisch den Business Freeze, obwohl die reine „technical downtime“ schon vorbei ist.

Zum anderen zeigt die Abbildung das Gegenstück. Die Downtime-Optimized Conversion. FI-Customizing wird auf Basis eines separaten Standard-Conversion-Laufs vorgezogen und über einen Customer Buffer so bereitgestellt, dass SUM es bereits in der Uptime (SHD/TMP) anwenden kann. SAP beschreibt den Standard-Run zur Erzeugung der FIN-Customizing-Artefakte als Voraussetzung.

Dies alles ist aber nicht einfach ein „Häkchen im Wizard“, sondern eine Experten-Disziplin mit klaren Rahmenbedingungen. SAP setzt für die Downtime-Optimized Conversion den Einsatz entsprechend zertifizierte Experten voraus.

Der Mechanismus ist simpel, die Governance dahinter nicht. Customizing muss sauber erzeugt, in den Transport-Buffer überführt und als Customer-Buffer-Datei dem SUM-Lauf bereitgestellt werden. Ohne stringente Transport-Reihenfolge, Freeze-Regeln und Regressionstest-Nachweis ist der Downtime-Gewinn sofort wieder weg – und zwar genau dann, wenn im Cutover niemand Zeit für Improvisation hat.

Fazit

Downtime-Optimierung ohne Messdaten bleibt Bauchgefühl. Für belastbare Planung braucht es Projektstatistiken. Nach einem SUM-Run stehen strukturierte Laufzeit- und Downtime-Daten zur Verfügung, ergänzt um Zusatzdaten für manuelle Konvertierungsanteile. Daraus lassen sich Engpässe, Simulationen (z. B. Archivierung vs. Approach) und ein belastbarer Cutover-Plan ableiten.

Empfehlung CALM (optional):

Viele Eigenentwicklungen sind historisch seriell aufgebaut – insbesondere im Hintergrund. Mit steigenden Datenmengen wird das zunehmend zum Problem. S/4HANA bietet die technische Basis, um Verarbeitungen sinnvoll zu parallelisieren: etwa über asynchrone RFCs, parallele (ABAP-)Verarbeitung oder datenbankseitige Parallelisierung.

Richtig eingesetzt lassen sich damit Laufzeiten deutlich reduzieren und gleichzeitig Sperrzeiten auf kritischen Objekten minimieren. Gerade für buchungsnahe oder massenintensive Prozesse ist das ein spürbarer Stabilitätsgewinn im Tagesgeschäft.

Autor: Martin Winn

S/4HANA System Conversion