Fit for S/4 Hana?
Waren es zu Beginn insbesondere kleine und mittlere Unternehmen, die den Umstieg auf S/4 Hana realisiert haben, gibt es inzwischen kaum einen SAP-Kunden, der sich nicht mit einem Umstieg auf die neue Innovationsplattform auseinandersetzt.
Zu Beginn dieser neuen ERP-Ära haben Neuimplementierungen, also Unternehmen, die S/4 Hana zum Anlass genommen haben, ihre ERP-Landschaft neu von der grünen Wiese aus aufzusetzen, noch circa 3/4 des Gesamtmarktes ausgemacht.
Inzwischen hat sich dieses Verhältnis umgekehrt. So erklärte Kim Mathaess (SAP) auf der diesjährigen DSAG, dass inzwischen ca. 75 Prozent aller S/4-Hana- Projekte Systemkonvertierungen sind.
Ursächlich für diesen Wandel ist sicherlich zum einen die verbesserte Verfügbarkeit von Informationen und Tools rund um das Thema Konvertierung und das damit einhergehende gestiegene Vertrauen der Kunden in dieses Transitionszenario.
Und zum anderen die Tatsache, dass speziell größere Unternehmen sich zunächst im Rahmen von Proof of Concepts oder Roadmap-Erstellungen der Thematik angenähert haben, während die tatsächlichen Projektrealisierungen nun erst sukzessive anlaufen.
Denn gerade für Großkonzerne bedarf der Umstieg aufgrund der häufig sehr komplexen Systemlandschaften mit historisch gewachsenen Strukturen einer besonders sorgfältigen Vorbereitung, Planung und Ausarbeitung einer Transition Roadmap.
Kaum ein Unternehmen ist sich dabei der Komplexität seiner Eigenentwicklungen und Modifikationen wirklich bewusst. Erst recht mag man keinem Kunden zumuten, sich mit der inzwischen 894 Seiten starken Simplification List im Detail auseinandersetzen zu müssen, ganz zu schweigen von der Abschätzung der Implikationen auf kundeneigene Entwicklungen und Programme.
Die S/4-Hana-Konvertierung stellt somit zunächst eine Black Box dar, in der die Aufwände und die zu erwartende Timeline kaum abgeschätzt werden können. Wie bringen wir also Licht in das Dunkel?
In vier Schritten zu S/4 Hana
Für eine erste Voranalyse bedarf es keines großen Budgets. Im Rahmen des „4 Steps 2 S/4 Hana“-Ansatzes bietet Atos seinen Kunden in einem ersten Schritt ein S/4 Hana Readiness Assessment an, um die Aufwandstreiber, die maßgeblichen Einfluss auf die Dauer und zu erwartende Komplexität des S/4- Hana-Umstiegs haben, besser abschätzen zu können und sich frühzeitig möglicher Showstopper bewusst zu werden.
Herzstück des Assessments ist der Custom Code Check, eine Auflistung der kundeneigenen Objekte, die aufgrund des vereinfachten Datenmodells unter S/4 Hana angepasst werden müssen.
Hinzu kommt der S/4 Hana Readiness bzw. Simplification Item Check, welcher in Form von SAP-Hinweisen ausgeliefert wird und diejenigen Simplification Items identifiziert, die für das jeweilige Kundensystem relevant sind.
Darüber hinaus erfolgt eine Prüfung, inwiefern vorhandene Business Functions, Industrielösungen und Add-ons noch mit dem gewünschten S/4-Hana-Zielrelease kompatibel sind.
Wir empfehlen Kunden, die einen Umstieg in Betracht ziehen, diese Analysen frühzeitig vorzunehmen. Denn viele Anpassungen wie beispielsweise die Bereinigung von Dateninkonsistenzen können Kunden bereits heute in ihrem ECC-System veranlassen.
Generell gilt: Je sorgfältiger eine Konvertierung geplant und vorbereitet wird, desto reibungsloser kann der Umstieg erfolgen. Dabei empfiehlt es sich keineswegs, einfach ungeprüft Programmanpassungen vorzunehmen, sondern zunächst immer kritisch zu hinterfragen, ob Anwendungen überhaupt noch genutzt werden.
Die Ergebnisse der Checks sollten daher beispielsweise mit dem Usage Procedure Protocol abgeglichen werden, um nur diejenigen Programme anzupassen, die auch tatsächlich Verwendung finden.
Die Atos S/4 Hana Conversion Factory in Indien kann dabei unterstützen, die Ergebnislisten aus den oben genannten Analysen auszuwerten und eine Aufwandsschätzung für die erforderlichen Anpassungen zu erstellen. Erst dann ist es möglich und sinnvoll, eine detailliertere S/4 Hana Conversion Roadmap zu definieren.
Gerade für Großkonzerne, in denen komplexe Systemlandschaften mit einer Vielzahl von ERP-Systemen konvertiert werden müssen, ist eine manuelle Anpassung des Codings keine praktikable Lösung. Hier arbeitet Atos mit dem Partner SmartShift zusammen, der es ermöglicht, einen Großteil der Anpassungen automatisiert vorzunehmen und dadurch Zeit und Kosten einzusparen.
Hana Value Assessment
Das Atos-Service-Portfolio des Readiness Assessments wird flankiert durch ein S/4 Hana Value Assessment, in dem Atos gemeinsam mit seinem Kunden den individuellen Mehrwert eines Umstiegs aus S/4 analysiert. Hier kommt der strategischen Partnerschaft mit Inventy und ihrem Analysetool „Performer for SAP“ eine besondere Bedeutung zu.
Die Big-Data-Plattform Performer for SAP identifiziert anhand von knapp 1000 Performance-Indikatoren Optimierungspotenziale und errechnet automatisch den Geschäftsnutzen. Daneben werden über einen Benchmark auch Vergleiche mit anderen Unternehmen vorgenommen, um daraus Optimierungsstrategien abzuleiten.
Begleitet wird der Value-Assessment-Ansatz von S/4-Hana-Demo- und -Showcase-Workshops in Atos Business Technology & Innovation Centern (BTIC) bzw. bei Kunden vor Ort. Die Showcases finden auf dem Atos- eigenen Demosystem statt, welches auf dem aktuellsten S/4 Hana Release basiert und sich ganz im Sinne von SAP Activate Best Practice Inhalte zu Nutzen macht.
Sie tragen damit maßgeblich dazu bei, den Kunden den Nutzen von S/4 Hana inklusive der innovativen Benutzeroberfläche SAP Fiori näherzubringen. Die Szenarien gehen dabei über reine S/4-Hana- Funktionalität hinaus und beinhalten zum Beispiel auch die Integration an ein Geographisches Informationssystem (GIS) oder IoT-Anwendungen.
Umsetzungsplanung
Entscheidet sich der Kunde für einen Umstieg auf S/4 Hana im Rahmen einer Systemkonvertierung, so ist diese in der sich anschließenden Vorbereitungsphase detailliert zu planen.
Je mehr Bereinigungen des Ausgangssystems vorgenommen werden, desto weniger potenzielle Fehlerquellen wird es im Laufe der Konvertierung geben. Hier empfiehlt sich beispielsweise der Einsatz des Decommissioning Cockpits des Solution Managers, um nicht genutztes Coding im Vorfeld zu entsorgen.
Nachdem häufig zwischen den ersten Analysen und der konkreten Umsetzungsphase mehrere Monate vergehen, ist es ratsam, im Anschluss die Prüfungen und Checks gegen das tatsächliche S/4-Hana-Zielrelease des Projektes noch einmal zu wiederholen.
Warnungen vs. Fehlermeldungen
Im Simplification Item Check wird zwischen Warnungen und tatsächlichen Fehlermeldungen differenziert. In den Warnungen sind auch Hinweise enthalten, die faktisch kein Eingreifen erforderlich machen, beispielsweise wenn mit dem S/4-Umstieg automatisch bestimmte Business Functions aktiviert werden, wie die Aktivierung des Self Service Procurements.
Können negative Wechselwirkungen zu anderen Funktionalitäten ausgeschlossen werden, ist hier nichts weiter zu veranlassen. Eine intensivere Beschäftigung erfordern dagegen die Fehlerhinweise.
Von der Umstellung auf den aus dem Customer Relation Management bekannten Geschäftspartner sind alle S/4-Kunden betroffen. Diese ist bereits im Vorfeld der Konvertierung im ECC-System umzusetzen. Je nach Komplexität kann dies mehrere Wochen bis hin zu einigen Monaten in Anspruch nehmen und ist damit in der Projektplanung entsprechend zu berücksichtigen.
Ist das neue Hauptbuch noch nicht im Einsatz und sind nach der S/4-Hana-Konvertierung Funktionalitäten wie Belegsplit oder Ledgerlösungen gewünscht, so ist im Vorfeld des S/4-Projektes ein separates New-GL-Projekt zu berücksichtigen.
Ein mögliches Ergebnis des Transition Pre-Checks kann auch die Nicht-Verfügbarkeit bestimmter ECC-Funktionalitäten unter S/4 Hana sein, wie es etwa beim Präferenz- Management der Fall ist.
In solchen Fällen prüft Atos anhand der SAP-Produktroadmap, ab wann entsprechende Nachfolgeprodukte verfügbar sein werden. Kann der Kunde auch in der Zwischenzeit nicht auf die Funktionalität verzichten, so sind Alternativlösungen zu eruieren oder im schlimmsten Fall können solche Meldungen zu einem Showstopper für das Projekt werden.
Meist trifft allerdings nur ein Bruchteil der Simplification Items auch tatsächlich auf das konkrete Kundensystem zu. In bisherigen Atos-Konvertierungsprojekten lag die Bandbreite zwischen 15 und ca. 50 relevanten Meldungstypen.
Um zusätzliche Sicherheit zu gewinnen, empfiehlt Atos, in der Vorbereitungsphase eine Testkonvertierung auf einer Kopie des Produktivsystems vorzunehmen.
Upgrade auf Hana 2.0
Die Konvertierung der produktiven Systemlandschaft wird mit dem aus den Enhancement Package Upgrades bekannten SUM (Software Update Manager)-Verfahren durchgeführt. Falls gleichzeitig das Upgrade auf die Hana-Datenbank erfolgt, so geschieht die Konvertierung in Kombination mit der Database Migration Option (DMO).
Kunden, die ihre Systeme bereits auf die Hana-Datenbank umgestellt haben, müssen berücksichtigen, dass ab einem S/4-Hana-Zielrelease größer gleich 1709 die Hana-Version 2.0 erforderlich ist und ein entsprechendes Upgrade einzuplanen ist.
Die Umstellung des Entwicklungssystems auf S/4 Hana erfolgt dann auf einer Kopie, während die ECC-Systemlinie zur Versorgung des Produktivsystems erhalten bleibt. Ab diesem Zeitpunkt wird durch den Parallelbetrieb eine doppelte Entwicklung auf ECC und S/4 Hana erforderlich.
Um zu vermeiden, dass Produktivsystem und konvertierte S/4-Hana-Systeme auseinanderlaufen, empfiehlt es sich, diese Phase so kurz wie möglich zu halten. Auch aus diesem Grund empfiehlt Atos die Zuhilfenahme von automatisierten Codeanpassungen.
Primäres Ziel einer S/4-Konvertierung ist, ein bestehendes ECC-System unter S/4 Hana lauffähig zu bekommen, die Umsetzung neuer Funktionalitäten steht dabei im Gegensatz zum Greenfield-Ansatz zunächst nicht im Fokus. Diese können in einer sich anschließenden Optimierungsphase realisiert werden, indem beispielsweise ein sukzessiver Umstieg auf die neue Benutzeroberfläche SAP Fiori erfolgt.
Fazit
Für Kunden, die eine S/4-Hana-Konvertierung in Erwägung ziehen, gibt es kaum mehr Gründe, nicht schon heute mit vorbereitenden Schritten zu starten. Die Bereinigung des Systems von nicht mehr genutztem Coding oder die Identifikation von möglichen Problemfeldern im Rahmen der Pre-Checks sollten gänzlich unabhängig von einer konkreten bevorstehenden Roadmap zeitnah in Angriff genommen werden.
