Irrtümer bei der SAP S/4HANA Transformation – Wir räumen mit den gängigsten Fehlannahmen auf

Irrtum Nummer 1:

„SAP S/4HANA ist nicht mehr als ein ERP-System auf einer schnelleren Datenbank.“

Das sagen die Scheer Experten:

SAP S/4HANA ist eine vollständig neue ERP-Applikation, die auf der In-Memory Datenbank SAP HANA basiert. Sie bietet damit völlig neue Möglichkeiten für ERP-Applikationen. Auf Grundlage der neuen Technologie können innerhalb von SAP S/4HANA durch Simplifizierungen (d. h. an vielen Stellen verschlankt und standardisiert) gänzlich neue Prozesse, Applikationen, Prozess- oder Geschäftsbereiche abgebildet werden. Dies war in der Vergangenheit, beispielsweise mit der klassischen ERP-Software von SAP, nicht möglich. Mit SAP S/4HANA erhalten wir eine Mischung aus einer hypermodernen Technologie als Grundlage für das ERP-System und einer vollständig auf diese Technologie angepassten, neuen Software-Applikation.

Eine wichtige Rolle spielt hierbei auch das Wartungsende: SAP S/4HANA ist bis 31.12.2040 bei SAP im Support (Stand: Juni 2022). Kunden haben somit eine 18-jährige Planungssicherheit. Die Einführung der ERP-Software SAP S/4HANA stellt an der Stelle also eine nachhaltige Investition für Kunden dar. Dies wäre mit älteren ERP-Software-Lösungen, wie z. B. der klassischen Business Suite, nicht der Fall, denn hier ist das Wartungsende bereits für 2027 terminiert (zzgl. Extended Maintenance).

Irrtum Nummer 2

„Unsere Prozesse sind ideal und bedürfen keiner Verbesserung.“

So stehen die Scheer Experten zu dieser Aussage:

Diesen Irrtum hören wir oft in Kundenprojekten. Dabei haben verschiedene Abteilungen oftmals auch unterschiedliche Meinungen zur Prozess-Thematik. Während einige Abteilungen gewisse Prozesse als passend einstufen, gilt dies für andere wiederum nicht. Nichtsdestotrotz ist im Zusammenhang mit SAP S/4HANA und Transformationsprojekten allgemein wichtig zu wissen, dass es immer sogenannte Weak Points im System gibt. Häufig sind es Prozesse, deren Performance nicht passt. Diese können durch SAP S/4HANA und der dazugehörigen Technologie schneller und somit performanter gestaltet werden. Außerdem gibt es unter Umständen hochgradig komplex abgebildete Prozesse im System (= Individualentwicklungen), die durch einen im Standard befindlichen Prozess abgelöst werden könnten. Dies ist auch hinsichtlich Wartbarkeit und Nachhaltigkeit interessant, denn zukünftige Releases lassen sich viel leichter ins System einspielen, wenn man einem Prozess nach Softwarestandard folgt.

Weitere wichtige Themen sind Abgleichungen und Anpassungen bei jedem Release-Wechsel, d. h. auch hier können durch das gezielte Anpassen von verschiedenen Prozessen (immer mit Blick auf den Standard) wirklich Potentiale im System aufgedeckt werden. Dies vereinfacht die Wartbarkeit und begünstigt eine weniger komplexe Systembetreuung sowie ein effizienteres Handling des Systems für den Kunden und seine Endanwender.

Ein zusätzlicher wichtiger Aspekt: Die SAP ERP-Lösung S/4HANA ist das integrierteste ERP-System am Markt. Dies gilt auch für Plattformen anderer Hersteller oder ERP-Systeme. Der manuelle Pflegeaufwand, also die Tätigkeit Daten in Excel zu importieren und aus Excel wieder zu exportieren, kann bei der SAP S/4HANA Transformation direkt optimiert werden. Hier wird versucht die Daten im SAP-Kontext (= S/4HANA Kern) oder in umliegenden Cloud Applikationen zu halten.
 

Irrtum Nummer 3:

„Greenfield ist nichts für uns, wir müssen alles behalten, was wir bereits angeschafft haben.“

Die Scheer Experten sehen die Thematik so:

Wir verstehen den Gedanken, dass Kunden ihre bisherigen Investitionen schützen wollen. Verständlicherweise möchte man nicht alles, was in eine ERP(Business Suite)-Implementierung investiert wurde, wieder über Bord werfen.

Jedoch ist hierbei wichtig, dass man die Aussage erst dann treffen kann, wenn eine dedizierte Roadmap erstellt oder eine Vorstudie durchgeführt wurde. Denn es kann sein, dass das alte System stark modifiziert ist und viele Daten, „Altdaten“ sowie nicht benötigte Objekte enthält, die man nicht in einer neuen In-Memory-Datenbank halten möchte. In diesen Fällen ist die eigentliche Transformation oftmals zu aufwändig.

Ein Beispiel: Im Rahmen einer Transformation müssen 20.000 Simplifizierungsobjekte berücksichtigt werden. Hier sollte man in jedem Fall überlegen, ob ein so hochkompliziertes Transformationsprojekt (Brownfield/BLUEFIELD™) durchgeführt werden soll oder ob man es besser als Greenfield-Projekt neu implementiert. Letzteres hat den Vorteil, dass man das gesamte System verschlanken kann und nur die Daten behält, die wirklich benötigt werden – bspw. aus gesetzlichen Gründen.

Weiterhin gibt es Kunden, bei denen die Wahrheit irgendwo in der Mitte liegt. Dies ist der Fall, wenn der Kunde gewisse Applikationen/Prozessbereiche übernehmen möchte, weil diese individuell auf ihn zugeschnitten sind, sehr gut funktionieren und auch in SAP S/4HANA weiterbenutzt werden können. Es gibt jedoch unter Umständen auch Aspekte, bei denen der Kunde wünscht, näher am Standard zu sein oder Verbesserungspotentiale entdeckt – in diesem Fall eignet sich der BLUEFIELD™-Approach. Kunden können die alten Inhalte ihres Systems übernehmen und sie zeitgleich mit neuen Inhalten anreichern. Sozusagen der goldene Mittelweg zwischen dem Brownfield- und Greenfield-Ansatz.
 

Irrtum Nummer 4:

„Wir kennen unsere Systeme und Ausgangslage genau. Wir wissen, welchen Ansatz wir brauchen und können direkt mit der Transformation beginnen.“

So schätzen die Scheer Experten dieses Thema ein:

Für uns ist es wichtig, zu Anfang sicherzustellen, dass der Kunde seine Ausgangslage und seine Systeme wirklich kennt und bewerten kann. Dies überprüfen wir beispielsweise im Rahmen einer Vorstudie (Assessment). Wurde diese bereits durchgeführt, sehen wir uns die Ergebnisse genau an. Die SAP stellt ein ganzes Set an möglichen Tools und Berichten zur Verfügung, die das Assessment unterstützen (auch mit dem SNP Crystal Bridge Analyzer möglich).

Wir empfehlen hierbei alle zur Verfügung stehenden Tools für die Analyse des bestehenden Systems zu Rate zu ziehen, um wirklich objektiv sicherzugehen, dass das System transformierbar ist, oder um zu identifizieren, welche Altlasten darin enthalten sind, die vorab aus dem System entfernt werden müssen. Denn genau diese Fakten müssen noch vor der Transformation bekannt sein. Eine grobe Einschätzung reicht an dieser Stelle nicht, denn der Kunde wird schnell den Punkt erreichen, dass er in die Transformation geht, im System klickt und der Vorgang dann abgebrochen wird. Den Fehler nun zu korrigieren ist häufig nicht (mehr) möglich. Also muss das System restort werden und man beginnt von vorne. In der Vergangenheit war es möglich bei Problemen  in ein Update zu gehen, eine einfache Fehlerkorrektur zu machen und das System dann weiterlaufen zu lassen. Dies funktioniert heute nicht mehr.

Deswegen ist bei der SAP S/4HANA Transformation eines essentiell wichtig: die richtige Vorbereitung. Man muss seine Systeme analysieren und genau wissen, was einen erwartet. Denn erst dann wird deutlich, welcher Transformationsansatz der richtige ist und man kann entsprechend vorbereitet mit diesem starten.

Irrtum Nummer 5:

„Brownfield geht immer schneller.“

So stehen die Scheer Experten zu dieser Aussage:

Dies lässt sich für uns relativ einfach beantworten: Grundsätzlich stimmt diese Aussage. Wenn die Vorbereitung jedoch nicht sauber verläuft, man auf Hindernisse stößt oder der Ablauf gestört wird, muss das System restort und von vorne begonnen werden. Passiert dies häufiger, wird ab der dritten oder vierten Iteration, bei der eine Brownfield Transformation erfolglos gestartet wurde, der Zeitaufwand so viel größer, dass der Greenfield-Approach doch ratsamer gewesen wäre. 

Deswegen gilt: Wenn das Projekt gut vorbereitet ist, braucht der Kunde höchstens eine oder zwei Iterationen, um eine Brownfield Transformation zu durchlaufen – dann war das Projekt erfolgreich. Wenn die Transformation nicht sauber vorbereitet ist, dann fallen unter Umständen 4, 5 oder sogar 6 Iterationen an. In diesem Fall befindet sich der Kunde auf einem kostspieligen, langwierigen und frustrierenden Weg. Alles was über 6 Iterationen hinaus geht, bedeutet für Transformationsprojekte, dass das Vorprojekt sorgfältiger hätte durchgeführt werden müssen oder der Kunde besser direkt einen Greenfield Approach gewählt hätte. Hinsichtlich Aufwand wäre er dann nämlich mindestens auf dem gleichen Niveau, wenn nicht sogar schneller und günstiger gewesen. Deswegen ist es wichtig, sich klar zu machen, was die Unterschiede der Transformationsansätze sind. Der Brownfield-Approach bedeutet: Das alte System wird in ein neues transformiert. Mit Greenfield hat man hingegen die Möglichkeit, das neue System direkt schlanker, effizienter und standardisierter zu bauen, sodass nachher auch ein besseres System betrieben werden kann. Der Greenfield-Approach eröffnet die Möglichkeit, sämtliche Potentiale, die die neue Software bietet, direkt auszukosten.

Irrtum Nummer 6:

„Greenfield bedeutet immer am meisten Arbeit.“

Die Meinung der Scheer Experten:

Generell können wir dieser Aussage zustimmen, da beim Greenfield-Ansatz mehr Aufwand im Bereich Customizing anfällt. Das System wird von Grund auf neu abgebildet und im weiteren Verlauf erfolgt eine entsprechende Datenmigration.

Aber ist dies wirklich IMMER der Fall? Wenn der Kunde zum Beispiel ein sehr komplexes, modifiziertes Altsystem hat, aber eine Brownfield-Konvertierung bevorzugt, muss zunächst der Aufwand geprüft werden, den solch eine Konvertierung unter diesen Voraussetzungen mit sich bringen würde. Wenn dieser Aufwand über ein gewisses Maß hinausgeht, macht gegebenenfalls eher der Greenfield-Approach Sinn. Es wäre schneller alles neu zu bauen, als alles im Altsystem separat zu betrachten, anzupassen und letztendlich zu transformieren. In diesem Fall wäre also eine Greenfield Transformation schneller und weniger aufwändig als der Brownfield-Ansatz.

Per se ist der Brownfield-Approach schneller durchführbar als Greenfield, aber – und das ist ein sehr wichtiger Punkt – es ist immer davon abhängig, wie die Ausgangssituation des Systems beim Kunden ist.

Irrtum Nummer 7:

„SAP S/4HANA ist nur für Finanzprozesse geeignet.“

Die Einschätzung der Scheer Experten:

Am Anfang gab es tatsächlich nur S/4HANA Simple Finance, da die SAP – wie bei jeder ERP-Software, die sie entwickeln – erst einmal mit den Finanzprozessen startet. Es stimmt, dass viele Optimierungspotentiale in den entsprechenden Finance-Prozessen liegen, aber auch die Logistikbereiche sind z. B. komplett oder nahezu vollständig in SAP S/4HANA abgebildet und dürfen nicht unberücksichtigt bleiben. Mittlerweile ist SAP S/4HANA ein vollumgängliches ERP-System, das für die Prozesse aller Unternehmensbereiche geeignet ist. Wenn wir auf das Jahr 2015 zurückschauen, wäre diese Aussage noch valide, aber seitdem hat sich viel in SAP S/4HANA getan.

Irrtum Nummer 8:

„Unser User Interface (UI) läuft auf SAP S/4HANA viel schneller.“

Die Bewertung der Scheer Experten:

Die Schnelligkeit des UI hat mit SAP S/4HANA direkt erst einmal nichts zu tun. SAP S/4HANA bietet die Möglichkeit, ein neues UI zu nutzen. Läuft dieses auch grundsätzlich schneller? Das lässt sich nicht pauschal beantworten. Die HANA Datenbank beschleunigt natürlich Prozessschritte innerhalb der Applikation, also zwischen Applikation und Datenbank, das funktioniert dann um ein Vielfaches schneller. Wenn man jedoch eine schlecht konfigurierte IT-Infrastruktur – egal ob Cloud, Rechenzentrum oder On-Premises – zwischen dem Backend-System von SAP S/4HANA inklusive Datenbank und dem UI hat (welches irgendwo auf Client-Seite liegt und dazwischen vielleicht auch noch Notebook, Netzwerk, Gateway Server, Web-Dispatcher etc. geschaltet sind), würde auch mit einem enorm schnellen SAP S/4HANA-Backend-System das UI quälend langsam laufen. Das bedeutet: Ein schnelles Backend-System führt nicht automatisch auch zu einem schnellen UI. Hier ist es ganz wichtig, eine sinnvolle Systemarchitektur zu haben, damit das Backend inklusive der beteiligten Netzwerkkomponenten und Umsysteme gemeinsam schnell läuft.

Irrtum Nummer 9:

„Wir benötigen keine Vorstudie.“

So stehen die Scheer Experten zu dieser Aussage:

Unsere Erfahrungen haben gezeigt, dass es zwar einige Kunden gibt, die diese Meinung vertreten, diese jedoch nur bei einem kleinen Teil tatsächlich zutrifft. Das lässt sich am besten anhand eines Beispiels zeigen: Wenn ein Kunde sein ERP/ECC-System erst vor wenigen Jahren eingeführt hat, es sehr nah am Standard ist, der Kunde seine Systeme kennt und das System auch nicht zu groß und nicht so stark modifiziert ist, dann wird dieser Kunde es mit ein paar rudimentären Checks schaffen, das System auf SAP S/4HANA umzustellen. In diesem Fall wäre zumindest keine tiefgreifende Vorstudie nötig.

Ist es dennoch sinnvoll, eine Vorstudie in abgespeckter Version durchzuführen? Wir sagen ja! Zum einen ist eine kurze Ist-Analyse hilfreich, um zu verifizieren, dass das Transformationsprojekt erfolgreich wird und zum anderen findet man möglicherweise trotzdem nochmal den ein oder anderen Prozess mit Optimierungspotential, der dann simplifiziert oder standardisiert werden kann. All dies ermöglicht SAP S/4HANA, weswegen auch in diesem Fall eine kleine Vorstudie ratsam ist.

Daher unser Fazit: Vorstudie per se ja, aber es muss überprüft werden, ob der Kunde nur eine kleine Übersicht benötigt, um sicher zu stellen, dass alles funktioniert oder ob eine detaillierte Vorstudie bis auf Objektebene des Systems notwendig ist. Deswegen variiert die Dauer einer Vorstudie auch sehr: Es gibt Vorstudien, die sind in 6 oder 7 Tagen abgeschlossen; es gibt aber auch Vorstudien, die 300 Tage oder mehr brauchen.

Irrtum Nummer 10:

„Brownfield ist für jedes Unternehmen geeignet.“

Die Einschätzung der Scheer Experten:

Brownfield ist für manche Unternehmen besonders interessant, genauso wie für andere Greenfield oder BLUEFIELD™ interessant sein können. Per se gibt es keine „Transformationsfarbe“, die heraussticht. Dennoch gibt es Situationen, in denen der eine oder andere Transformationsansatz besser geeignet ist.

Wenn der Kunde zum Beispiel einen Merge durchführen möchte, neue Prozesse eingeführt werden sollen, es auch um Optimierung der Prozesse geht, im Rahmen des Projekts auch standardisiert werden soll und massiv in die Systemlogik eingegriffen wird, dann ist der Brownfield-Ansatz nicht sinnvoll. Beim Brownfield-Approach wird erstmal so viel wie möglich übernommen und danach macht man sich Gedanken, was optimiert werden kann. Das wäre in diesem Fall das Unterscheidungskriterium bei der Wahl des Transformationsansatzes.

Zusammenfassend bedeutet das: Wenn Kunden auf uns zukommen und alles im bestehenden System möglichst so übernommen werden soll wie es ist, dann ist Brownfield eine gute Möglichkeit. Sobald man aber in die Applikationslogik eingreift, sollte es mindestens in Richtung BLUEFIELD™ oder sogar in Richtung Greenfield gehen. Es sei denn der Kunde bevorzugt ein Zweischrittverfahren, in dem er zunächst alles übernimmt, wie es ist, sich dann die Potentiale anschaut und nachgelagert entsprechende Optimierungsprojekte durchführt – dann würde auch der Brownfield-Ansatz funktionieren.

Wenn man sich für den Brownfield-Approach entscheidet, gibt es allerdings ein paar wichtige Daten, auf die geachtet werden muss. Denn letztendlich müssen Customizing-Anpassungen durchgeführt und Kontenpläne angepasst bzw. modernisiert/harmonisiert werden. Es bietet sich an, solche Vorhaben idealerweise immer zu einem Geschäftsjahreswechsel durchzuführen. Das Projekt muss daher sehr gut getimt sein.  

Irrtum Nummer 11:

„Testen ist nicht bei allen Transformations-Ansätzen notwendig.“

Das sagen die Scheer Experten:

In Kundenprojekten hören wir häufig, dass gerade beim Brownfield-Ansatz deutlich weniger getestet werden müsse als beim Greenfield-Ansatz. Generell widersprechen wir dieser Aussage, denn auch beim Brownfield-Approach gibt es einige Änderungen, die durchgeführt werden: Im Prinzip wird jeder Layer im System geändert, vom User Interface über die Software, die Datenbank, die Datenbanktechnologie, gegebenenfalls auch die entsprechenden Infrastruktur-Komponenten und das Deployment Modell. Für uns bedeutet das automatisch, es muss getestet werden. Idealerweise gibt es dazu ein Testmanagement, vielleicht sogar eine Testautomatisierung, die entsprechend unterstützt und dabei hilft, die Prozedur zu beschleunigen. Deswegen sagen wir: Bei allen Transformationsansätzen muss getestet werden.