SAP S/4HANA Vorbereitung und Conversion
Richtig vorbereitet auf die Zielgerade!
Richtig vorbereitet auf die Zielgerade!
Auch wenn die Begrifflichkeiten häufig verwechselt werden, beinhaltet die S/4HANA Conversion neben einem Wechsel auf die HANA-Datenbank diverse andere Aktivitäten und ist somit nicht mit ihr identisch! Richtig ist aber, dass der Schritt der Datenbank-Umstellung auch ohne Probleme noch unter SAP ERP erfolgen kann und sollte, um die eigentliche Conversion so weit wie möglich zu reduzieren. Für diesen Schritt ist allerdings die Umsetzung einer Teilmenge der Findings aus dem Precheck bzw. Custom Code Check erforderlich. Lizenztechnisch kann dieser Schritt sogar vorteilhaft sein, weil die HANA-Datenbank in den häufig bereits erworbenen S/4HANA Lizenzen inkludiert ist und somit separate Lizenzen z.B. für eine Oracle Datenbank eingespart werden können.
Sicher ist, die Objekt- und Sicherheitenverwaltung in SAP CML (SAP Loans Management) wird mit SAP S/4HANA entfallen. Dies ist eines der wichtigsten Ergebnisse des SAP S/4HANA Readiness Checks bei Banken, die SAP CML zur Darlehensverwaltung nutzen. Nach dem Grundsatz „eine Lösung für jedes Problem“ bildet das SAP Collateral Management System (CMS) zukünftig die einzige Lösung zur Verwaltung von Sicherheiten.
Neben der notwendigen Migration von Sicherheitendaten bildet dieser Themenkomplex häufig auch einen Schwerpunkt im Custom Code Check, da auch Eigenentwicklungen, die bislang auf die Datenhaushalten in der CML-Objektverwaltung zugegriffen haben, angepasst werden müssen.
Die Einführung von CMS inkl. Migration der Sicherheiten kann und sollte dabei vor der eigentlichen S/4 HANA Conversion durchgeführt werden. Ergebnis ist dann ein ERP-System mit „eingeschaltetem“ CMS als Sicherheitenverwaltung, welches dann die Grundlage für die Conversion bildet.
Neben der reinen Datenmigration spielen dabei auch die Aktivitäten in der Sicherheitenverwaltung eine wichtige Rolle. So können Prozesse wie die Bewertung und Freigabe von Sicherheiten im Gegensatz zu CML direkt im CMS-Modul abgebildet werden. Eine fachliche Analyse der möglichen Mehrwerte im Vorwege einer Migration ist daher unbedingt zu empfehlen. Darüber hinaus erlaubt CMS die Abbildung komplexer Sicherheitenkonstellationen, die so im CML bisher nicht bzw. nur über Zusatzentwicklungen abgebildet werden konnten. Dies kann im Rahmen der S/4 HANA Conversion zum Rückbau von Eigenentwicklungen genutzt werden.
In diesem Bereich gibt es häufig Missverständnisse. Zur begrifflichen Klärung: Das neue Hauptbuch ist eine bereits in SAP ERP existierende Komponente im SAP FI, welche auch als New General Ledger (New GL) bekannt ist. Viele Unternehmen verwenden aber nach wie vor das klassische Hauptbuch unter ERP. Da die neue zentrale Zusammenführung von Rechnungswesen und Controlling unter S/4 HANA, das „Universal Journal“, sehr ähnlich klingt und daher häufig mit dem New GL verwechselt wird, kommt es bisweilen zu der Fehlannahme, die Einführung des New GL wäre eine zwingende Voraussetzung für S/4 HANA.
Fakt ist: Die Einführung des neuen Hauptbuchs ist keine zwingende Voraussetzung für die S/4 HANA Conversion.
Wenn jedoch fachliche Gründe für ein Umstellung vorliegen (z. B. parallele Bewertungsbereiche bei Rechnungslegung nach HGB und IFRS), dann übernehmen wir diese für Sie vor der S/4 HANA Conversion.
In Banken sind operative Systeme (Bestandsführung) und dispositive Systeme (Auswertung, Business Warehouse) heute häufig systemtechnisch getrennt. Hintergrund hierfür sind i. d. R. die hohe Anzahl von lesenden Datenbankzugriffen und die Ressourcenbelastung durch die dispositiven Programme, die nicht das Tagesgeschäft auf den operativen Systemen belasten sollen.
Die HANA-Datenbanktechnologie stellt diese Rahmenbedingungen nun zumindest teilweise in Frage, so dass eine Zusammenlegung bzw. direkte Versorgung aus dem Bestandsführungssystem im Zuge einer S/4HANA Transformation untersucht werden kann. Dies ist allerdings nur dann sinnvoll, wenn sich hier hohe Einsparpotentiale (z. B. von Systemkosten) ergeben, da in jedem Fall eine vollständige fachliche Konzeption erforderlich ist, die auch die Grenzen dieses Ansatzes mitberücksichtigt. So können zwar unter S/4HANA komplexe Berechnungen auch zu beliebigen Stichtagen online durchgeführt werden; wenn aber zur Berechnung vergangener Stichtage erforderliche Daten im Bestandssystem durch laufende Veränderung schlicht nicht mehr zur Verfügung stehen, ist dies auch durch schnellere Datenbanktechnologie nicht zu heilen.
Die unter der HANA-Datenbank zu erwartenden Performance-Vorteile hängen maßgeblich vom Design der Datenbanktabellen und der Ausnutzung HANA-spezifischer Features ab. Es ist daher nicht automatisch mit einem Geschwindigkeitsvorteil für jedes beliebige Programm zu rechnen, wenn man von Skalierungseffekten der (unter HANA voraussichtlich mit deutlich mehr Ressourcen versehenen) Hardware absieht.
Für ressourcenkritische Anwendungen kann sich aber eine vertiefende Analyse lohnen, ob sich durch die konsequente Ausnutzung neuer Features Performance-Gewinne erzielen lassen. Ebenso sinnvoll kann es sein, den Speicherplatzverbrauch großer Anwendungen zu überprüfen, da „größere“ Systeme unter S/4HANA nicht nur mehr Plattenplatz, sondern vor allem mehr teuren Hauptspeicher benötigen.