Transformation zu S/4 und Hana: Wie bewerkstelligen?

S/4 ist kein Papiertiger

Odysseus hatte für seine Heimkehr aus Troja zehn Jahre Zeit und kam in seiner Heimat Ithaka als Bettler an. Dem SAP-Bestandskunden stehen nur etwa fünf Jahre zur Verfügung und er will nicht als Gestrandeter, sondern mit einem erfolgreichen Change-Management-Projekt dastehen.

Ein „Releasewechsel“ ist keine neue oder ungewöhnliche Situation. Seit den erfolgreichen R/2-Tagen gehört es zu den guten Sitten, ein SAP-System nur mithilfe erfahrener Berater und Experten zu customizen. Aber bei Hana und S/4 geht es nicht nur ums Customizen!

Wie der Bericht von Heiko Friedrichs, Hinrich Mielke und Achim Zimmermann deutlich zeigt, sind diesmal die Anforderungen wesentlich höher. Es ist die digitale Transformation der SAP-Welt. Es ist kein technischer Versionswechsel.

Zu berücksichtigen sind bei der Transformation zu S/4 auch betriebswirtschaftliche, organisatorische, technische und lizenzrechtliche Aspekte. Der Einsatz von Beratern und Experten ist dafür ein ganz natürliches Vorgehen.

In der Phase der „digitalen Transformation“ benötigt der SAP-Bestandskunde viel Erfahrung und Wissen, das später im operativen Betrieb nicht mehr täglich gebraucht wird. Ein korrekt eingestelltes SAP-System ist zwar kein Perpetuum mobile, aber dennoch eine gut geölte Maschine, die nur zeitweise Blutauffrischung braucht.

Das Hinzuziehen von Beratern und Experten, wie es die Mannschaften von Devoteam Alegri und QPCM darstellen, ist somit der natürliche Customizing-Vorgang in der SAP-Community. Bei SAP sieht man es ähnlich, nur hat der Hana-Erfinder und S/4-Anbieter einen Fehler gemacht: Berater und Experten sind nicht beliebig verfügbar und auch deren Tag hat lediglich 24 Stunden.

Die ganz großen SAP-Bestandskunden haben schon vor vielen Monaten Tausende Manntage bei den globalen Beratungsunternehmen eingekauft. Hier sind bis 2025 keine Ressourcen mehr vorhanden.

Es ist den mittelständischen SAP-Partnern zu danken, dass diese bereits vor langer Zeit begonnen haben, auf eigene Kosten Hana- und S/4-Wissen aufzubauen, das momentan viele Bestandskunden dringend brauchen. Ob SAP angesichts der knappen Berater-Ressourcen an der Zeitschraube drehen soll oder muss, wird sich wahrscheinlich erst 2022 entscheiden.

Warten ist jedoch in keiner Weise eine Option. Und noch ein Tipp für die SAP-Community. Genau genommen handelt es sich bei dieser digitalen Transformation um zwei Themen: Datenbank und ERP.

Hana kann eine fantastische, aber auch herausfordernde Datenbank sein. Achim Zimmermann von QPCM könnte darüber Bücher füllen. S/4 ist ein neues ERP-Modell und Konzept. Heiko Friedrichs und Hinrich Mielke von Devoteam Alegri können das an vielen Beispielen beweisen.

Im folgenden Text wird das Thema kurz am Beispiel des neuen Hauptbuchs erläutert. Betroffen sind aber in jedem Fall die Bereiche FI/CO und Logistik. S/4 ist demnach kein Papiertiger – im Gegenteil: Es ist eine Herausforderung, der man viel Aufmerksamkeit widmen sollte, auch mit Expertenunterstützung! (pmf)

Es gibt eine offizielle Deadline mit 2025

Das Problem: Bis 2025 ist der Support für ECC 6.0 von SAP zugesichert. Für die Zeit danach ist zum aktuellen Stand lediglich der Support für S/4 Hana signalisiert. Das heißt, der Wechsel auf S/4 muss in fünfeinhalb Jahren abgeschlossen sein.

Dieser Zeitraum ist geringer, als es sich anhört. Ähnlich wie bei der Jahr-2000-Umstellung und der Euroumstellung wird es mit zunehmender Nähe zum Stichtag schwerer, qualifiziertes Personal zu bekommen. Dies gilt intern wie extern sowie weltweit. Die Herausforderung ist eine ähnliche: Es war keine Option, beim Wechsel auf das Jahr 2000 oder den Euro „nicht mitzumachen“.

Ebenfalls ist zu beachten, dass neben dem technologischen Strang (Wechsel auf neue Datenbank, gegebenenfalls neues Betriebssystem) auch Geschäftsprozesse und Eigenentwicklungen betrachtet werden müssen.

Parallel sind Fragen zur Front­-End-Strategie (Fiori) zu klären, die Einbindung neuer, cloudbasierender Services sowie allgemein die Betrachtung und Bewertung von Cloud- Möglichkeiten (IaaS, PaaS, SaaS) sind durchzuführen.

Sämtliche Geschäftsprozesse und Eigen­entwicklungen sind auf den Prüfstand zu stellen, auch diejenigen, die bisher außerhalb von ECC liefen. Im einfachsten Falle werden diese Geschäftsprozesse und Eigen­entwicklungen lediglich an die veränderten Möglichkeiten angepasst.

Somit werden jedoch die veränderten Gelegenheiten nur unvollständig genutzt. Besser ist es, sich mit den neuen Möglichkeiten intensiv vertraut zu machen und diese bestmöglich für die bestehenden Geschäftsmodelle zu nutzen.

Diese Aufgaben sind jedoch seit einigen Jahren bekannt – jeder CIO oder Leiter SAP wird hierzu entsprechende Lösungsansätze vorbereitet und ein entsprechendes Programmmanagement aufgesetzt haben. Die entstehenden Aufwände sind nicht zu unterschätzen. Sie sind gut investiert – und lassen sich mit einem erfahrenen Partner laut einer Faustregel etwa halbieren.

Das Hauptproblem ist jedoch meist die Unterstützung der Fachbereiche: Es mangelt an Key-Usern, denen die Zeit und oft auch der vorhandene oder gewährte Freiraum fehlt, um „neu zu denken“.

Dies führt in manchen Fällen dazu, dass der CIO den Wechsel auf S/4 Hana bei seinen Kunden, den Fachbereichen, pushen muss, das Projekt als ungeliebt wahrgenommen wird und somit eher schleppend betrieben wird.

Zwei Bereiche sind durch die Umstellung auf S/4 unmittelbar und direkt betroffen. Im Bereich FI/CO entsteht durch die zwingende Umstellung auf das neue Hauptbuch, die Customer-Vendor-Integration (CVI) und das Zusammenwachsen von FI und CO erheblicher Handlungsbedarf.

Etablierte Geschäftsprozesse müssen revidiert, 3rd-Party-Applikationen neu verprobt und das Reporting aus der veränderten Tabellenstruktur aufgesetzt werden. Die Verbesserungen sind erlebbar, der Nutzen ist zu spüren – es ist dem­entsprechend ein Change-Projekt aufzusetzen.

S/4 plus Ariba

Im Bereich Logistik sind ebenfalls gewichtige Veränderungen zu managen. Hier ist der Geschäftsnutzen jedoch unmittelbarer und somit ein ROI eher darzustellen. Ein technisch interessantes Detail ist die Nutzung von „Pull“ für kurzfristige Statusinformationen aus 3rd-Party-Systemen, z. B. der Standort von Gütern im Transport.

Somit löst hier „Pull“ das traditionelle „Push“ ab und reduziert die Systemlast. Ebenso werden durch die integrierte Anbindung von Ariba als Beschaffungsplattform Medienbrüche reduziert und Prozesse durchgängig im SAP-Universum gestaltet.

Optimal ist jedoch, neue und gänzlich veränderte Geschäftsprozesse zu etablieren, die aufgrund der neuen Gegebenheiten möglich sind. Hierzu ist jedoch Know-how über die fachlichen und technischen Möglichkeiten nötig sowie das „Denken außerhalb der Box“.

Ein Partner mit unverstelltem Blick wird diesen Prozess initial ungemein beschleunigen und auch aufgrund der Außensicht stets neu befruchten. Diese erneuerten Geschäftsprozesse wird jeder Kunde für sich entwickeln und etablieren – nur so lässt sich ein Vorsprung zum Marktbegleiter erarbeiten.

All diese Veränderungen werden sich auf die Zusammenarbeit zwischen Fachbereich, IT und externem Partner auswirken. Um die nötige Agilität zu erreichen, werden interdisziplinäre Teams erforderlich sein, die auch die Fachsprache der jeweils eingebundenen Fachleute verstehen und idealerweise auch sprechen.

Eine klassische Aufteilung nach Kunde und Dienstleister ist nicht erfolgversprechend. Nur bei einer kollegialen Gleichberechtigung und viel Eigen­initiative wird die Veränderung in einem zielführenden Kontext realisiert.

Dies wird, so viel sei vorweggenommen, auch nach der Umstellung weiterhin ein Erfolgsrezept für einen agilen und wertschöpfenden Umgang mit den neuen Möglichkeiten sein. Somit ist diese Veränderung ebenfalls ein Change in der Organisation, der Zusammenarbeit unterschiedlicher Bereiche und der Wahrnehmung der Geschäftsbeiträge.

Devoteam Alegri hat mittels der S/4- Booster-Methodik einen einfachen, minimalinvasiven Ansatz, um seinen Kunden in kürzester Zeit die Veränderungen und Vorteile von S/4 darzustellen. Und zwar mit den Prozessen, Daten und Abläufen aus dem bestehenden ECC-6.0-System – in einem schlanken S/4, das an das Kundensystem angebunden ist.

S/4 Booster & iHAL

So lassen sich die Vorteile von S/4 und Hana schnell erfahren – mit den eigenen Daten und Prozessen. Dieses S/4 kann z. B. kurzfristig aus der Cloud heraus bereitgestellt werden (bereits mit Azure durchgeführt) und bei positiver Bewertung on-premises eingerichtet werden.

Der Nutzen ist, dass ein Fachbereich schnell den Vorteil von S/4 mit eigenen Daten und Prozessen erleben kann – und somit diese Transformation inhaltlich und moralisch unterstützen wird.

Ein anderes Beispiel ist die iHAL (intelligent Hana Assurance List), entwickelt vom SAP-Partner QPCM: SAP Hana entwickelt sich rasant. Wie bei jeder Weiterentwicklung einer Software enthält jede Revision, neben Verbesserungen und neuen Funktionen, auch Bugs. Diese können sowohl alte als auch neue Revisionen betreffen.

Logische Softwarefehler sind schwerwiegend, da sie durch keine HA-Lösung abgefangen werden können. Um die Risiken durch Softwarefehler im Betrieb von Hana zu minimieren, müssen die nötigen SAP-Hinweise zyklisch geprüft werden.

Eine Prüfung der Hinweise – passend auf das eigene Szenario – kann schnell aufwändig werden. Mit der iHAL hat QPCM ein Tool geschaffen, womit diese Prüfungen schnell, effektiv und effizient durchgeführt werden.

Cloud, IaaS und Governance

Diese Beispiele zeigen, wie Technologien dem Kunden beim Wechsel auf S/4 helfen. Ebenso ist die Nutzung der Cloud als IaaS ein probates Mittel, um Tests, Projekte und Schulungssysteme in Stunden und Tagen aufzusetzen, statt sich mit der Beschaffung von Hardware on-premises oder beim Outsourcer zu beschäftigen.

Solange man IaaS im Pay-as-you-go-Modell betreibt, lassen sich Systeme ebenfalls innerhalb von Stunden in der Größe verändern oder auch wieder dekommissionieren. Das hat zur Folge, dass es keinerlei Sizing-Risiken mehr gibt. Was nicht passt, wird passend gemacht – mit der Down­time eines „Durch-Bootens“.

Diese Kommissionierung und Dekommissionierung muss mit entsprechenden kaufmännischen Prozessen hinterlegt sein. Anderenfalls kann schnell ein Wildwuchs an Systemen entstehen – der entsprechende Kostensteigerungen nach sich zieht.

Dies ist keine theoretische Gefahr, unterschiedlichste Kundenerfahrungen sprechen hier eine deutliche Sprache. Natürlich muss die Nutzung von Cloud-Services mit einer entsprechenden Governance belegt werden. Hier kann ein erfahrener Partner die Vorbereitungszeit entscheidend abkürzen, sodass die Agilität der Cloud schnell und einfach genutzt werden kann.

Die Wahl des Cloud-Anbieters für IaaS ist – systematisch angegangen – für die meisten Kunden eines der schlankeren Vorläuferprojekte: Er muss von SAP supportet sein, den Anforderungen an Compliance und Zertifizierungen Genüge tun und die angebotenen Standorte des Anbieters müssen zu den Anforderungen und technischen Randbedingungen passen.

Ein wichtiger Aspekt ist die Integration des Cloud-Anbieters in die bestehende Umgebung – oftmals werden bereits Services konsumiert, sodass hier Synergieeffekte gehoben werden können.

Vorgangsmethodik und Scope

Leicht lässt sich sehen, dass dieser Wechsel komplex werden kann und herkömmliche Vorgehensweisen oft nicht ausreichen, um den maximalen Nutzen aus der Umstellung zu realisieren.

Die Informationsfindungsphase und das Festlegen des Scopes sind komplexer und noch wichtiger als bei herkömmlichen Veränderungen. Parallel ist ein agiles Vorgehen mit regelmäßiger Bestimmung des Standorts und einer Nachjustierung des nächsten Abschnitts erforderlich.

Devoteam Alegri hat aufgrund der Erfahrungen und des Know-hows eine Vorgehensweise konzipiert. Diese ist an Vorgaben von SAP angelehnt und wurde um Erfahrungen der Consultants ergänzt.

Sowohl aus der jahrelangen Erfahrung mit Ausschreibungen wie auch dem Betrieb in einer IaaS-Umgebung als auch aus Greenfield- und Brownfield-Projekten zu S/4 wurden Hilfsmittel und Werkzeuge erstellt, die Projektlaufzeiten und -risiken reduzieren und Aufwände für Kunden minimieren.

Administration von S/4 Hana

Das Entwickeln einer Strategie – unter Einbeziehung neuer Möglichkeiten aus der Cloud, Architektur inklusive der Fiori-Systeme – sowie die eigentliche Transformation sind das eine. Nach einer Hyper­care-phase ist der anschließende Betrieb ein anderes, häufig (zu) spät betrachtetes Thema: Bei vielen Umstellungen organisiert man Unterstützung zum Aufsetzen der neuen Prozesse, Anbindung der Cloud bis zum Go-live des S/4-Systems.

Aber wie kann ein Kunde seine bestehende Administrationsorganisation auf die neue Architektur abbilden und unterbrechungsfrei transformieren? Die klassische SAP-Basis als auch die Applikationsteams werden sich auf neue Strukturen, Lösungen und Aufgaben einstellen müssen. Zwei einfache Beispiele sollen dies verdeutlichen:

1. Administrative Aufgaben wie Monitoring oder Security werden sich ändern. Aktuelle Monitoringlösungen in SAP sind auf Abap- und Java-Systeme zugeschnitten, ein übergreifendes Monitoring on- premises als auch Cloud-Lösungen meistens nur über Umwege integrierbar. Analog verhält es sich mit Sicherheitseinstellungen.

Kann eine unternehmenseigene IT noch die Sicherheit vollumfänglich innerhalb des eigenen On-premises-Netzwerks sicherstellen, so stößt sie bei Einbindung von Cloud-Lösungen an ihre Grenzen. Hier bedarf es ebenso wie beim Monitoring neuer Wege zur komfortablen und abgesicherten Nutzung und Überwachung.

2. Applikationssupport als auch Entwicklung sind aktuell meist systembezogen organisiert, da auch die Geschäftsprozesse innerhalb eines Systems ablaufen. Dies wird sich künftig ändern und Prozesse werden system- und weltübergreifend ablaufen.

Somit müssen Entwicklung wie auch der Support entsprechende übergreifende Kenntnisse aufbauen. Dazu gehört beispielsweise auch ein angepasstes ­Change-Management, da Änderungen in Zukunft über deutlich mehr Systeme und Systemwelten hinweg konsistent zu organisieren sind.

Ebenfalls werden neue Organisationsstrukturen zu etablieren sein, da administrative und fachliche Teams deutlich enger zusammenarbeiten.

Die Wandlung von der klassischen SAP- Systembetreuung zur modernen hybriden Unterstützung von Prozessen und Services rund um den digitalen Kern in Form des S/4-Systems unter Einbindung diverser Cloud-Strukturen und -Applikationen ist komplex. Sie bedarf erfahrener Experten, die analoge Umstellungen bereits erfolgreich absolviert haben und Vorteile als auch Risiken potentieller Strukturen bereits kennen.

Dabei muss man noch gar nicht von einer Einbeziehung von IoT, künstlicher Intelligenz oder Blockchain sprechen, ein einfacher Blick auf die Verlagerung von SAP-Funktionalitäten auf Cloud- Lösungen (WebIDE, SCM- Funktionalitäten, Monitoring Cockpits, Schnittstellen- und Datenintegration…) reicht völlig aus.

Fazit

Der Wechsel auf S/4 ist alternativlos, soll bis 2025 abgeschlossen sein und ist nicht zu unterschätzen. Die potenziellen Gewinne durch die Umstellung rechtfertigen bei sorgfältiger Planung den Aufwand. Ebenso sind S/4 und Hana die Voraussetzung für eine nahtlose Integration von Lösungen aus dem Portfolio von SAP – sei es Ariba oder auch die Anbindung mittels SCP.

Auch die Verarbeitung von IoT- Daten wird durch den Einsatz von S/4 vereinfacht und unmittelbar wirksam. Der Kunde kann die Geschwindigkeit und Qualitätsstufe der künftigen Landschaft beeinflussen, benötigt dazu aber entsprechend Zeit und Expertise – beides schon heute eine begrenzte Ressource.

Eine Wahrnehmung als „Releasewechsel“ wird sowohl dem Projekt als auch seinen Auswirkungen nicht gerecht und ist eine grob fahrlässige Unterschätzung. Ebenso ist ein zeitliches Aufschieben des Projekts unangemessen, denn der Mangel an erfahrenen Consultants für die Zahl der Projekte wird im Laufe der Zeit eklatant zunehmen.

Die Hoffnung, dass SAP die Deadline 2025 erweitert, ist verständlich – kann aber nicht die Grundlage des Handelns sein. Ebenso ist die Wahrscheinlichkeit hoch, dass SAP neben den bereits klar sichtbaren Vorteilen eines Wechsels auf S/4 den Verbleib auf ECC 6.0 auch wirtschaftlich zunehmend unattraktiver gestalten wird.

Denn SAP hat ein hohes Interesse daran, die Wechselrate auf S/4 und Hana zu beschleunigen – nur so können weitere Produkte und Lizenzen beim Kunden platziert werden. Ein Partner wie der Verbund von Devoteam Alegri und QPCM – neutral, ohne eigene Lizenz­interessen und mit großer Erfahrung – mit jahrelanger praktischer Erfahrung kann hier den Unterschied machen.

Eine Bestandsaufnahme der Ist-Situation, ein Advisory zum aktuellen Lösungsraum und dann ein Masterplan – schon ist diese Veränderung handhabbar und auch den eigenen Stakeholdern zielführend zu erklären.