Migration auf S4/HANA betrifft die bestehenden DatenS/4HANA Umstieg ist komplexer als gedacht

Der prognostizierte Zuwachs an Umstiegen auf S/4HANA wurde noch nicht realisiert, so bringt es die Deutschsprachige SAP Anwendergruppe (DSAG) auf den Punkt. Trotz zahlreicher Projekte habe die Zahl der Umstellungen nicht merklich zugenommen. Das könnte daran liegen, dass sich der Übergang komplexer erweist als gedacht. Doch ein „Aussitzen“ macht wenig Sinn, denn spätestens 2025 ist es soweit: Dann läuft die Wartung für ältere SAP-Releases aus. Bis zu diesem Zeitpunkt sollten SAP-Bestandskunden auf S/4 HANA umgestiegen sein. Vor allem für die Datenmigration sind daher Tools gefragt, die den Umstieg erleichtern.

Modernisierung ist angesagt bei allen SAP-Bestandskunden, denn 2025 läuft der Support für die „alte Business Suite“ aus. Zwar werden noch einige Jahre bis dahin vergehen, doch wenn man große SAP-Installationen umstellen muss, sind Zeitspannen von mehreren Jahren für diese Aufgabe durchaus üblich. Denn es sind viele Anpassungen zu untersuchen und sinnvollerweise durch bei S/4 HANA neu hinzu gekommene Module zu ersetzen. Denn so können Unternehmen über diese Vereinfachungen – Simplifications genannt – wieder Erweiterungen zurück in den „Standard“ führen.

Zudem sollten Unternehmen auch gleich den „Aufräumeffekt“ nutzen: in vielen SAP-Installationen werden Daten mitgeschleppt, die gar nicht mehr genutzt werden: Teilweise sind ganze Buchungskreise noch enthalten, die nicht mehr gebraucht werden, oder Werke bzw. Zweigstellen sind im Unternehmen gar nicht mehr vorhanden. Die braucht man im neuen System nicht, die benötigt man lediglich für eine eventuelle Revision.

Drei S4/HANA-Umstiegsoptionen

Für Thomas Failer, Gründer der Data Migration Services AG, lautet in einem derartigen Umfeld die entscheidende Frage: Was soll mit den Altsystemen passieren, wenn die Daten einmal in das neue Zentralsystem übertragen wurden? Darauf gibt es nach seiner Einschätzung drei Antworten: Die Altsysteme werden weiterbetrieben und gewartet, solange darin gespeicherte Informationen gesetzlich aufbewahrt werden müssen. Oder man friert die Altsysteme sozusagen in einer Art Zeitkapsel als App in einer virtuellen Umgebung ein, speichert sie auf einem Medium speichern und fährt sie bei Bedarf hoch – und das bis zum Ende der Aufbewahrungspflicht. Als dritte Option bringt er die Trennung der gespeicherten Informationen von den SAP-Bestandssystemen mit dem anschließenden Betrieb der herausgelösten Daten und Dokumente auf einer separaten Plattform ins Spiel.

„Der Weiterbetrieb der Altsysteme ist sicherlich am kostspieligsten“, gibt Failer zu bedenken. „Schließlich müssen sie permanent gewartet werden, um zum Beispiel Programmierfehler zu beheben oder Sicherheitslücken zu schließen. Zudem müssen sie für neue gesetzliche Anforderungen nachgerüstet werden, sofern dies technisch überhaupt möglich ist.“ Rechtliche Risiken bestehen nach seiner Einschätzung genauso für die Variante, die Altsysteme und ihre Informationen einzufrieren. Mehr noch: „Programmfehler und Sicherheitslücken bleiben dauerhaft bestehen. Zu den rechtlichen kommen also noch erhebliche Sicherheitsrisiken hinzu.“

Aus der Sicht von Failer sind zirka 50.000 Anwenderunternehmen von einem Umstieg auf S4/HANA betroffen. Hierzu bietet SAP einige Werkzeuge (Funktionalitäten des Solutions Managers, oder das SAP Migration Cockpit) für den Umstieg an, doch die werden nur für die wenigsten Unternehmen passen. Denn viele Anwenderunternehmen haben individuelle Ausprägungen und man wird vielfach auch nicht mehr die Funktionen finden, die das alte System bereitstellt.

Landscape Transformation betrifft die Datenbank

Bei einer „Landscape Transformation“ geht man bei einer Umstellung auf der Datenbankeben die Sache an. Dabei handelt es sich unter Umständen um 100.000 von Tabellen, die es umzustellen gilt, denn S4/HANA – sie basiert auf der In-Memory-Datenbank SAP HANA – kommt eine komplett neue Datenstruktur im Vergleich zu R3 zum Einsatz. Der Migrationsweg muss über saubere Schnittstelle laufen wie das SAP Migration Cockpit. Es gilt als die passende Schnittstelle von SAP, und erledigt die Validierung der Daten, sie stellt Datenkonsistenz im Zielsystem sicher.

Eine schlaue Lösung sollte zuerst die Daten reduzieren. Hier kommt eine Lösung wie Jivs ins Spiel. Es kann die Datenhistorie konsolidieren und alles Überflüssige wegnehmen. Zudem bleibe die Datenhistorie über das Jivs im Zugriff und nur die für den aktuellen Betrieb nötigen Daten werden dann via Migration Cockpit in die S4/HANA-Umgebung gezogen. Das kann in der Cloud sein aber auch „on premise“. Zudem spielt das Argument In-Memory mit: Je weniger Daten man im Arbeitsspeicher vorhält, umso eleganten aber auch umso günstiger ist die Lösung. (rhh)

Hier geht es zu Data Migration Service 

Hier geht es zu Jivs