Migration auf SAP S/4 Hana: So sieht der richtige Ansatz aus

Bis 2025 müssen SAP-Bestandskunden auf die neue Softwaregeneration S/4 Hana migrieren. Nur bis dahin hat die SAP eine Supportgarantie für ERP/ECC 6.0 abgegeben, zuletzt auf dem DSAG-Jahreskongress 2018. Die meisten SAP-Bestandskunden verbinden mit der Migration das Ziel einer agilen Applikationslandschaft, mit deren Hilfe sie die He­rausforderungen der Digitalisierung meistern können.

Doch Vorsicht: Was als Ziel auf der Ebene der Anwendungen völlig richtig ist, lässt sich nicht eins zu eins auf die Ebene der Daten übertragen. Denn Daten aus Unternehmensanwendungen stehen stets in einem Geschäftskontext, der aus rechtlichen Gründen für die Zeitdauer der gesetzlich vorgeschriebenen Aufbewahrungsfristen zusammen mit den Daten erhalten werden muss.

Außerdem enthält dieser Geschäftskontext wichtige Zusatzinformationen zum Beispiel über die Historie und Qualität einer Geschäftsbeziehung zu einem Kunden oder Lieferanten, die auch Jahre später für das jeweilige Unternehmen wertvoll sein können.

Auf der Ebene der Daten geht es also weniger um Agilität als um Stabilität. Das ist der Grund, warum sich bei jeder Migration auf neue Softwaregenerationen – innerhalb wie außerhalb von SAP – große Datenvolumen in den Rechenzentren der Unternehmen ansammeln, die wegen des Geschäftskontextes zusammen mit den Alt­anwendungen aufbewahrt und gepflegt werden – und das zum Teil für viele Jahrzehnte und zu erheblichen Kosten.

Beim Umstieg auf S/4 stellt sich das Problem, dass Altsysteme weiterbetrieben werden müssen, erneut und dazu noch in verschärfter Form. Zum einen ergibt es schon aus Kostengründen keinen Sinn, sämtliche Daten und Dokumente aus den Bestandssystemen in die Hana-Datenbank zu übernehmen.

Zwar sind Speichermedien insgesamt deutlich billiger geworden, doch Hauptspeicher und Rechenressourcen erfordern immer noch spürbare Investitionen. Zum anderen wird die Datenstruktur beim Umstieg auf SAP Hana massiv verändert.

So wird sich die Zahl der Tabellen bei großen Installationen von über hunderttausend auf fünfzehntausend bis maximal zwanzigtausend reduzieren. Damit setzen sich die Unternehmen enormen rechtlichen Risiken aus, wenn sie keine vernünftige Lösung für ihre Altdaten und -systeme finden.

Eine Frage der Architektur

Die alles entscheidende Frage lautet daher: Wie lassen sich die entgegengesetzten Ziele Agilität und Stabilität miteinander in Einklang bringen? Mithilfe eines neuen Ansatzes: einer anderen Architektur der Applikationslandschaft, die Altdaten und -dokumente von den agilen Apps der Zukunft trennt. Altsysteme lassen sich dadurch abschalten, neue Softwaregenerationen dauerhaft schlank und agil halten.

Schlüsselelement dieser neuen Architektur ist eine eigene systemunabhängige Umgebung für Daten, Dokumente und ihren Geschäftskontext, die nicht mehr in den operativen Systemen benötigt werden.

Eine solche Umgebung sorgt für die gebotene Stabilität auf der Datenebene. Gleichzeitig erhöht sie die Rechts- und IT-Sicherheit. Denn sie lässt sich anders als viele Altsysteme weiter patchen und absichern.

Zudem erlaubt sie, mittels Funktionalitäten für Retention Management den gesamten Lebenszyklus von Altdaten und -dokumenten auf der Ebene der einzelnen Datensätze und Dokumente lückenlos zu managen.

Dies schließt ausdrücklich das gezielte Löschen von Daten und Dokumenten mit ein – eine der wesentlichen Anforderungen der Europäischen Datenschutz- Grundverordnung (EU-DSGVO).

Eine Zertifizierung nach dem Standard IDW PS 880 des Instituts der Wirtschaftsprüfer sorgt dafür, dass auch Wirtschaftsprüfer und die Finanzämter Vertrauen in diese Umgebung haben, was die Unveränderbarkeit der aus den operativen Systemen übernommenen Daten und Dokumente sowie ihres Geschäftskontexts anbelangt.

Sparen bis zu 80 Prozent

Die Folge: Die Altapplikationen können abgeschaltet werden, was zu operativen Einsparungen gegenüber ihrem Weiterbetrieb von bis zu 80 Prozent – und manchmal sogar mehr – führt. Was aber im Zusammenhang mit der anstehenden Migration auf S/4 mindestens ebenso wichtig ist:

Wenn geschäftliche Daten und Dokumente, sobald sie operativ nicht mehr gebraucht werden, in diese Umgebung ausgelagert werden, bleiben die aktuellen Anwendungen und Systeme auf Dauer schlank und agil. In der Regel lässt sich das operative Datenvolumen um 50 bis 75 Prozent reduzieren. Jeder unnötige Ballast wird damit vermieden.

Warum das so wichtig ist, zeigt eine einfache Rechnung: Rund 10.000 SAP-Bestandskunden haben ihren Sitz im deutschsprachigen Raum. Selbst wenn man mit einem Durchschnittswert von 2000 Personentagen pro Projekt rechnet, entstünde bis 2025 ein Kapazitätsbedarf von 20 Millionen Manntagen im DACH-Markt, also rund 3,2 Millionen pro Jahr.

Selbst wenn alle geschätzt 2000 Experten für Datenmigration in den deutschsprachigen Ländern 365 Tage im Jahr arbeiten würden, stünden lediglich Kapazitäten von jährlich 730.000 Manntagen bereit.

Urlaubs- und sonstige Ausfallzeiten mit eingerechnet wären wohl fünf Mal so viele Migrationsexperten nötig wie tatsächlich vorhanden, um die Projekte bis 2025 zu realisieren. Dies wird nach Adam Riese schlicht nicht möglich sein.

Zeit gewinnen und agil werden

Werden nicht mehr benötigte Daten und Inhalte aus den operativen Applikationen kontinuierlich auf eine rechtssichere sys­temunabhängige Plattform übertragen, wird die Unternehmens-IT insgesamt deutlich agiler und kann verschiedenste Geschäftsszenarien mit sehr geringem Aufwand unterstützen.

Beispiel Zu- und Verkauf von Firmen und Geschäftsbereichen: Dabei gilt es zu entscheiden, welche Anwendungen von dem gekauften Unternehmen übernommen werden sollen, weil sie gegenüber den eigenen Vorteile aufweisen, und welche nicht mehr gebraucht werden.

Damit hängt unmittelbar die Frage zusammen, welche Daten und Dokumente in die Live-Systeme migriert werden sollen. Der Weiterbetrieb von Altsystemen in den Unternehmen ist ein wesentlicher Grund dafür, dass in der Regel 80 Prozent des gesamten IT-Budgets allein für den Betrieb aufgewendet werden.

Hinzu kommen Compliance- und Security-Risiken, wenn die übernommenen Systeme nicht mehr zuverlässig gewartet oder mittels regelmäßiger Sicherheits- Patches abgesichert werden können.

Und die Nachrüstung, um zum Beispiel die Löschanforderungen der EU-DSGVO zu erfüllen, ist bei vielen Altsystemen technisch gar nicht mehr möglich oder nur unter sehr großem Aufwand realisierbar.

Beispiel Konsolidierung von heterogenen Applikationslandschaften auf zentrale Systeme wie SAP: Bei der Konsolidierung der SAP-Systemlandschaft handelt es sich nicht um ein rein technisches Projekt.

Vielmehr verbinden die Unternehmen damit betriebswirtschaftliche und strategische Ziele: Durch die Zentralisierung sollen die Komplexität reduziert, der entsprechende Wartungs-, Administrations- und Kostenaufwand gesenkt sowie Innovationen beschleunigt werden.

So bietet die Konso­lidierung weltweit verteilter SAP-­Landschaften die Möglichkeit, Änderungen und Weiterentwicklungen schneller zu implementieren und global bereitzustellen. Diese Ziele lassen sich jedoch nur erreichen, wenn die Altsysteme stillgelegt werden.

Beispiel Konsolidierung von weltweit verteilten Rechenzentren: Projekte zur Konsolidierung von Rechenzentren beginnen mit einer umfassenden Bestandsaufnahme und Analyse der Applikations- und Systemlandschaft.

Welche davon können wirklich ohne größere Änderungen an den zentralen Standort umgezogen werden? Gibt es lokale Vorschriften und Gesetze, die den Umzug verbieten, weil die zu bestimmten Transaktionen oder Personen gehörigen Daten wie zum Beispiel aus Finanzbuchhaltung oder dem Personalwesen Landesgrenzen nicht übertreten dürfen?

All diese Überlegungen gefährden das eigentliche Ziel der Konsolidierung, die Zen­tralisierung, und drohen auch den Teilumzug sehr komplex und damit aufwändig sowie kostspielig werden zu lassen. Viele Standorte können nämlich nicht stillgelegt werden, wenn keine Lösung für Altdaten und -dokumente gefunden wird.

Faktor Datenqualität und Zukunft

Beispiel der Datenqualität: Ein Kunde, viele Datensätze und dazu noch unterschiedliche, sodass die Unternehmen von verschiedenen Kunden ausgehen statt von einem einzigen. Denn sie können bei Auswertungen keine Beziehung zwischen den Datensätzen feststellen.

Das ist der heutige Stand in vielen Unternehmen. Daten im Detail zu analysieren ist aber geradezu die Voraussetzung für optimierte digitale Prozesse, neue digitale Produkte und Services.

Wer keinen korrekten Überblick über die Kaufhistorie eines Kunden hat, wird ihn nicht mit den richtigen Angeboten und mit dem richtigen Maß an Personalisierung ansprechen. Kurz: Die Grundlage für digitale Geschäftsmodelle fehlt.

Für die Zeit vor wie nach der S/4-Hana- Migration: SAP-Systeme wachsen. Schon nach kurzer Zeit müssen die Speicherkapazität erweitert und die Rechenressourcen vergrößert werden, damit Anfragen von Fachanwendern gegen das System nicht spürbar zulasten der Performance gehen.

Für SAP-Bestandskunden kommt eine neue Herausforderung hinzu. Denn ihre Bestandssysteme laufen in der Regel noch nicht auf der neuen Datenbank Hana, sondern auf einem der gängigen relationalen DBMS-Systeme. In Zukunft aber müssen sie Lizenzen für SAP Hana erwerben, die zudem volumenabhängig sind!

SAP-Bestandskunden haben daher ein starkes Interesse daran, ihre Datenbestände zu reduzieren, bevor sie auf die Hana-Datenbank migrieren. Die Lösung für die Herausforderungen in den genannten Geschäftsszenarien heißt Stilllegung der nicht mehr benötigten IT-Systeme und die Überführung der darin enthaltenen Daten und Dokumente auf eine moderne Plattform, um den Lebenszyklus der Altinformationen und ihres Geschäftskontextes verwalten zu können.

Dürfen bestimmte Daten und Dokumente Landesgrenzen nicht verlassen, lassen sie sich auf lokalen Instanzen der Plattform aufbewahren und vorhalten, stehen aber weltweit im Zugriff. Zudem lassen sich die Daten auf Redundanz, Konsistenz und Korrektheit hin überprüfen und auf Basis von Regeln korrigieren und anreichern.

Genau für diese und andere agile Geschäfts- und Anwendungsszenarien wurde die Java-basierende Plattform JiVS entwickelt. Sie zeichnet sich dadurch aus, Daten aus abgeschalteten Altsystemen, aber auch die zugehörigen Dokumente in ihrem Geschäftskontext weiter rechtssicher vorzuhalten. JiVS ist damit das Kernelement einer agilen Applikationslandschaft in den Unternehmen: So sieht der richtige Ansatz aus.