Strategische Datenbank-Migration Zwischenschritt auf dem Weg zu S/4HANA

SAP S/4HANA wird zukünftig die SAP Business Suite ablösen. Aber S/4HANA ist noch ein sehr junges Produkt. Dennoch sollten Anwenderunternehmen die Innovationen jetzt in ihre Planung mit einbeziehen, ihre langfristige SAP-Roadmap definieren und mit den ersten Schritten beginnen. Dabei stellt sich die Frage: Kann die "Business Suite on HANA" hierbei ein hilfreicher Zwischenschritt sein?

Ablösung steht an

Im November 2015 hat SAP mit S/4HANA die nächste Generation ihrer Business Suite auf den Markt gebracht. Die alte Business Suite wird noch bis 2025 unterstützt, Anwenderunternehmen müssen bis dahin auf SAP S/4HANA umgestiegen sein. Allerdings spielt der Umstieg zu S/4HANA von der Komplexität her in der Liga einer R/2 zu R/3-Migration. So spricht die SAP bei SAP S/4HANA auch nicht von einem Upgrade sondern von einer Konvertierung.

Häufig wird im Kontext von S/4HANA auf die Philosophie des „Principle of One“ verwiesen: Dies bedeutet, dass es zukünftig für eine Anforderung nur eine Implementierungsoption gibt. Demgegenüber steht die historisch gewachsene Business Suite; hier gibt es häufig verschiedene Realisierungsmöglichkeiten für eine Anforderung.

Als Beispiel sei die Ablösung des Kunden- und Lieferantenstamms in S/4HANA durch den Business-Partner genannt. Jeder kann sich ausmalen, was die von der SAP angestrebte Bereinigung der Codebasis für Auswirkungen auf kundeneigenes Coding haben wird. Trotzdem wird SAP S/4HANA aber die SAP-Plattform der Zukunft sein. Die SAP spricht vom „Digital Core“. Die Änderungen in S/4HANA im Vergleich zur Business Suite beschränken sich auch nicht auf rein technische Aspekte, sondern umfassen insbesondere auch funktionale und prozessuale Änderungen.

Die SAP Business Suite hingegen ist ein bewährtes und stabiles Produkt. Seit 2013 ist die „Business Suite on HANA“, also die alte Business Suite auf der neuen Datenbank-Technologie SAP HANA, verfügbar und im Markt etabliert. Viele SAP Anwenderunternehmen verwenden die Business Suite noch auf einer „Nicht-HANA-Datenbank“. Die Frage ist: Inwieweit ist der Umstieg auf Suite on HANA ein sinnvoller Zwischenschritt auf dem langfristigen Weg zu S/4HANA?

Sinnvoller Zwischenschritt

Viele Unternehmen haben mittlerweile die Migration ihrer Business Suite zu HANA erfolgreich durchgeführt. Das Produkt und die entsprechenden Migrationsverfahren sind mittlerweile etabliert und ausgereift. Mit der Business Suite on HANA können SAP-Anwenderunternehmen schon heute von funktionalen Vorteilen profitieren, die mit HANA als Datenbank verfügbar werden. Einige Beispiele:

•    Die neu entwickelte und für HANA optimierte Bedarfsplanung („MRP Live“) bietet alle betriebswirtschaftlichen Vorteile und drastischen Performance-Gewinne der entsprechenden S/4HANA-Implementierung.
•    Mit einer Suite on HANA kann man von den Vorteilen eines operationalen Echtzeit-Reportings („HANA Live“) profitieren.
•    Ein BW on HANA kann im Zusammenspiel mit einer Suite on HANA neue Möglichkeiten für den effizienten Datenzugriff verwenden („Smart Data Access“).
•    Darüber hinaus sind bei einer Suite on HANA bei einigen Reports deutliche Performance-Steigerungen zu beobachten, die HANA-Optimierungen der Business Suite sind in einem SAP-Hinweis gesammelt aufgeführt.

Die wesentlichen technischen Aspekte einer Suite on HANA-Migration umfassen die Bereiche Code & Data Cleansing sowie SAP Basis und Infrastruktur. Im Bereich Code Cleansing muss das kundeneigene Coding unter Umständen für HANA angepasst werden (funktionale Korrektheit) und sollte für HANA optimiert werden (Performance). Darüber hinaus ist es empfehlenswert, die Verwendung des kundeneigenen Codings über einen längeren Zeitraum (mindestens ein Jahr) zu protokollieren, um totes Coding zu identifizieren und zu isolieren.

Im Bereich Data Cleansing bietet es sich an, im Vorfeld der HANA-Migration das Datenbankvolumen durch Housekeeping und Archivierung gezielt zu reduzieren. So lassen sich enorme Kosten sparen. Diese Code & Data Cleansing-Aktivitäten sind teilweise recht langwierig, fallen aber im Zuge einer späteren S/4HANA Konvertierung sowieso an.

Zudem kann das Rechenzentrum mit einer Suite on HANA schon Erfahrung mit dem produktiven Betrieb einer transaktionalen Applikation auf einer HANA-Datenbank sammeln, ohne eine zusätzliche Arbeitslast durch große Prozessänderungen zu erfahren. Denn gerade in punkto Infrastruktur führt HANA durch eigene Konzepte im Bereich der Hochverfügbarkeit und Ausfallsicherheit doch zu einigen Neuerungen. Mit Blick auf die Lizenzkosten muss jedes Anwenderunternehmen seine Lizenzverträge dahingehend prüfen, wie sich eine Suite on HANA auswirkt. Nicht selten ist die Summe der Lizenzkosten von Business Suite und HANA geringer als die Summe von Business Suite und Drittanbieter einer Datenbank, wie etwa von Oracle.

Wichtig ist: Eine Suite on HANA (das impliziert SAP Netweaver 7.40) beinhaltet bereits alle wesentlichen technologischen Innovationen von S/4HANA. Beispiele sind SAP UI5 (Fiori) und ABAP CDS Views – beides Technologien, die massiv in S/4HANA Verwendung finden und bei jeder künftigen S/4HANA-Implementierung eine wesentliche Rolle spielen werden. Mit einem „Suite on HANA-System“ hat die IT-Abteilung damit schon die technologischen Bausteine, um wertvolle praktische Erfahrungen bei der Implementierung und im Umgang mit den neuen Technologien zu sammeln. Wer auf diese Weise frühzeitig Know-how aufbaut, kann sich bei einer späteren S/4HANA-Implementierung voll auf die Umsetzung der Kundenanforderungen konzentrieren, ohne sich erst mühsam ins Thema einzuarbeiten oder vermeidbare Anfängerfehler zu begehen.

Mit dem Umstieg zu Suite on HANA vor einer S/4HANA-Konvertierung werden vorausschauend schon viele technische Aufgaben erledigt, die später im Zuge einer S/4HANA-Konvertierung sowieso bearbeitet werden müssten. Darüber hinaus entfällt die Notwendigkeit, Prozessänderungen zu bearbeiten – diese stehen wiederum bei einer S/4HANA-Konvertierung aufgrund der funktionalen Neuerungen unweigerlich an.

Statt einen großen Schritt von Business Suite on any-DB zu S/4HANA zu tun und dabei beide Blöcke aus technischen und funktionalen Anpassungen in einem zu bearbeiten, empfiehlt sich in vielen Fällen ein Zwei-Schritt-Verfahren mit dem Zwischenschritt einer Suite on HANA: Die Suite on HANA-Migration erlaubt eine Konzentration auf technische Aspekte; der spätere Schritt zu S/4HANA kann damit stark auf funktionale Aspekte fokussiert werden. Ergebnis: Der Aufwand und das Risiko sind bei einem späteren Wechsel zu S/4HANA deutlich reduziert.

Etablierte Migrationsverfahren

Wie man die Migration zur Suite on HANA konkret gestaltet, hängt von der Ausgangssituation der bestehenden Systeme ab. Es gibt drei verschiedene Möglichkeiten:

•    Die Neuimplementierung eines Suite on HANA-Systems mit Datenmigration (Greenfield-Ansatz),
•    ein Upgrade der SAP-Komponenten mit anschließender Datenbankmigration (klassisches zweistufiges Vorgehen) und
•    Upgrade & Datenbank-Migration in einem Schritt („Database Migration Option“ oder kurz „DMO“).

Alle Verfahren sind mittlerweile etabliert, markterprobt und stabil. Jede Option bietet Vor- und Nachteile: Der Greenfield-Ansatz mit gleichzeitiger Datenmigration bietet sich insbesondere für Split & Merge-Szenarien an, bei denen die HANA-Migration beispielsweise mit der Herauslösung eines Tochterunternehmens aus der Business Suite kombiniert werden soll. Demgegenüber steht der Aufwand für die Datenmigration. Das klassische zweistufige Vorgehen bietet den Vorteil, dass eine sehr große Anzahl von möglichen Ausgangssituationen unterstützt wird. Hierbei sind allerdings zwei Downtimes für die komplette Migration erforderlich. Das DMO-Verfahren hat den Vorteil einer Migration zu Suite on HANA in einem Schritt, der zudem noch Downtime-optimiert ist.

Darüber hinaus sind bei einer HANA-Migration in der Regel noch Aktivitäten im Bereich des Custom Coding erforderlich; diese lassen sich in drei Blöcke strukturieren:

•    Obligatorische HANA-Code-Anpassungen,
•    Datenbank-agnostische Performance-Optimierungen sowie
•    HANA-spezifische Performance-Optimierungen.

Bei der richtigen Planung des HANA Custom Code-Managements und einem pragmatischen Vorgehen sind mit überschaubarem Aufwand gute Optimierungen zu erzielen. Die Entscheidung für einen direkten Weg zu S/4HANA oder einer Suite on HANA sowie die konkrete Wahl des Migrationsvorgehens sollte stets unternehmensindividuell anhand der konkreten Situation abgeleitet werden.

Berater wie cbs Corporate Business Solutions GmbH bieten hierfür effiziente Methoden, die Managementberatung zur Bebauungsplanung und Systemarchitektur mit Technologie-Services kombinieren. Mit dem cbs S/4HANA Transition Program werden Unternehmen gezielt auf S/4HANA vorbereitet und individuellen Strategien für die digitale Transformation entwickelt.
Die Suite on HANA-Migration kann erfahrungsgemäß sehr gut mit einem Upgrade auf EHP 7 oder EHP 8 kombiniert werden. Die durch den Upgrade sowieso schon eingeplanten Testzyklen der Business Suite führen dazu, dass die HANA-Anpassungen implizit mitgetestet werden.

S/4HANA wird sich auf breiter Basis durchsetzen, steckt aber noch in den Kinderschuhen. Die SAP Business Suite on HANA hingegen ist etabliert und stabil. Die Migration zu einer Suite on HANA bietet schon jetzt viele Vorteile. Dazu minimiert sie die Arbeitslast und das Risiko beim zukünftigen Umstieg zu S/4HANA. Und vor allem: Mit bewährten Verfahren und überschaubarem Aufwand lässt sie sich effizient und zügig realisieren. (rhh)

Dr. Karsten Kötter

ist bei der cbs Corporate Business Solutions Unternehmensberatung GmbH als Senior Solution Architect für das Thema SAP HANA verantwortlich.