Hintergrund
Die Anwendung S/4HANA wurde vor fünf Jahren ins Leben gerufen. Schon seit fast zehn Jahren gibt es den Namen HANA (ursprünglich für High Performance Analytic Appliance) für die darunterliegende Datenbank. SAP sagt recht unbescheiden, mit S/4HANA sei „the intelligent enterprise“ möglich. (Anmerkung: An Anglizismen im SAP-Universum haben wir uns gewöhnt, auch dieser Blog-Beitrag wird keine Übersetzungsversuche unternehmen.) Im Kern bietet S/4HANA die performante Verarbeitung und Analyse erheblich größerer Datenmengen als im bisherigen System möglich, mehr Informationen in Realtime, vereinfachte Simulationsmöglichkeiten, einfachere Bedienungsoberflächen und die Möglichkeit, auf das eine oder andere Vorsystem oder Umsystem, das im Wesentlichen aus Performancegründen eingerichtet wurde, zu verzichten. Dem uralten Menschheitstraum von der Single Source of Truth kommt Ihr Unternehmen mit S/4HANA ein gutes Stück näher. Dies wird ermöglicht durch die Architektur der unter S/4HANA liegenden Datenbank (die nicht Gegenstand dieses Beitrags ist) und das auf die Architektur ausgerichtete Neuschreiben der Applikation S/4HANA.
Das Minimalziel,
das eine Unternehmung mit der Einführung von S/4HANA erreicht, ist das Ersetzen des bisherigen SAP-ERP-Systems durch ein System, das – man beachte! – im Wesentlichen einen gleichartigen Umfang beinhaltet. Man findet nicht mehr unbedingt die vertrauten Modulnamen wie FO, CO, MM und SD. Viele grundlegende Transaktionen hingegen (Buchung einer Eingangsrechnung, Buchung eines Warenausgangs, …) sind dem Wesen nach gleichgeblieben – manchmal in neuem Gewand. Sogar dieses Minimalziel ist jedoch bereits eine Transformation, die tief in die Prozesslandschaft der Unternehmung eingreift: durch die neue Technologie wird eine neue zentrale Tabelle der Datenbank, die den „eingängigen“ Namen ACDOCA trägt, in Echtzeit aktualisiert. In dem Moment, in dem die ebengenannten Beispiele (Eingangsrechnung, Warenausgang) gebucht sind, steht die Information allen Modulen, allen Transaktionen und Auswertungen sofort zur Verfügung. Damit fallen einige Transaktionen zwischen Modulen weg, andere Prozesse werden verschlankt oder beschleunigt.
Weitergehende Ziele
Jedes SAP nutzende Unternehmen legt selbst fest, welche Geschäftsprozesse in die Digitale Transformation aufgenommen werden sollen – und welche Produkte und Technologien zum Einsatz kommen sollen. Im Umfeld von S/4HANA bietet SAP entsprechende, die Funktionen erweiternde Systeme an, die in der Regel durch Zukäufe ihren Weg in das SAP-Universum gefunden haben und in die Gesamtarchitektur integriert werden. Bekannte Beispiele sind Successfactors, Ariba und C/4HANA. Der SAP-Kunde muss evaluieren, ob er SAP-Produkte oder Produkte alternativer Anbieter einsetzt. Die Nutzung neuer Technologien wie Artificial Intelligence, Machine Learning oder Robotic Process Automation ermöglicht an vielen Stellen das Verschlanken und die Beschleunigung der Prozesse. Auch bezüglich dieser Technologien muss das Unternehmen evaluieren, welche Technologien für welche Geschäftsprozesse erfolgreich eingesetzt werden können. Ebenso das Erstellen eines optimierten Zeit- und Ablaufplans ist von entscheidender Bedeutung: Welche Transformationsgeschwindigkeit kann das Unternehmen bewältigen? Welche Ressourcen können für die Transformation freigemacht werden?
IT-Architektur: S/4HANA als Software as a Service oder als Produkt
Eine wesentliche Entscheidung, die das Unternehmen bei der Einführung von S/4HANA treffen muss, ist die Frage, ob das System in der Form Software as a Service oder als Produkt erstellt und betrieben werden soll.
S/4HANA als Produkt: dies ist sicher eine Struktur, die der Ist-Situation am Nächsten kommt. S/4HANA wird einmal im Jahr funktional aktualisiert; es ist im Entscheidungsbereich des Kunden, wie häufig er auf die neue S/4HANA-Version umsteigt. Die aktuelle Version ist 1909, eingeführt im September 2019; es steht zu vermuten, dass im September 2020 die nächste Version, 2009, eingeführt wird. Der Kunde ist eher frei, Anpassungen und Erweiterungen vorzunehmen (möglichst nicht am Code von S/4HANA selbst). Das Produkt S/4HANA wird von SAP als „AnyPremise“ vermarktet; der Kunde hat die Wahl, das System im eigenen Rechenzentrum (On Prem) zu betreiben, im Outsourcing oder bei einem Hyperscaler (Azure, AWS, …); es besteht auch die Möglichkeit, den von SAP angebotenen Infrastructure as a Service-Dienst Hana Enterprise Cloud (HEC) zu nutzen; in dieser Variante leistet SAP über die Bereitstellung des Produkts S/4HANA hinaus einige Services im Betrieb des Systems.
In der Ausprägung S/4HANA Software as a Service werden zwei Versionen, „Essential Edition“ und „Extended Edition“, angeboten:
Cloud, Essential Edition: diese Edition bietet S/4HANA als reines Software as a Service-Modell an, die Governance des Systems liegt bei SAP. Die Software bekommt alle drei Monate ein Update; derzeit läuft die Version 2005. Die Updates werden automatisch von SAP eingespielt; der Kunde hat hier nicht die Möglichkeit, einen Cloud-Anbieter (AWS, Azure, …) selbstständig zu wählen. Der Kunde hat des Weiteren vergleichsweise wenig Möglichkeiten, das System zu verändern. In dieser Version ist die Standardisierung sicher am höchsten, die Total Cost of Ownership dürfte am niedrigsten sein, jedoch auf Kosten der Flexibilität und Erweiterbarkeit. Die Essential Edition richtet sich eher an Firmen, die in einem Land tätig sind und nicht branchenspezifische Anforderungen mit dem S/4HANA-System abbilden wollen. (Diese Edition hieß bis vor kurzem Multi Tenant Edition.)
Cloud, Extended Edition: obwohl auch als Software as a Service angeboten, ist diese Edition dem Wesen nach sehr nahe an On Premises; die Software nutzt zwar die gleiche Basis wie die Essential Edition, der Funktionsumfang ist jedoch so groß wie bei der On Premises-Variante: SAP hat diese Edition für 25 Branchen und 50 Länderversionen ausgeprägt – ergo können viele länder- oder branchenspezifische Anforderungen im Standard abgebildet werden. Auch liegt hier die Entscheidung über Upgrades etc. beim Kunden. Der Unterschied zu on Prem ist also eher technisch, sprich das System wird in der Cloud betrieben, und lizenzrechtlich, sprich das System, wird als SaaS betrieben – beispielsweise bei SAP, oder auch bei anderen Anbietern (AWS; Azure, …). Ergänzend sei erwähnt, dass diese Edition bis vor kurzem Single Tenant Edition hieß.
Es gehört zum Projektinhalt in einer recht frühen Phase, die Entscheidung über diese IT-Architektur zu treffen.
Aus unserer Erfahrung hat es sich bewährt, diese Fragen in einem vorbereitenden, neutralen Scoping Projekt zu beantworten. So stellen Sie sicher, dass sie den maximalen Nutzen aus Ihrer S/4HANA Migration ziehen.
Bereits erschienen ist Teil 1: “Ihre Ist-Situation – Appetizer für S/4HANA”. Der dritte Teil “Der Weg zu S/4HANA” erscheint in Kürze.
Hinweise:
Fragen, Feedback und Kommentare zu diesem Beitrag senden Sie bitte an acent.marketing@acent.de
| 10.07.2020