S/4HANA Produkt Versionen

Inhaltsverzeichnis

• Einleitung
• Versionen
• Public Cloud
• Private Cloud
• On-Premise
• Vergleich
• Erweiterung
• Steampunk
• Embedded Steampunk
• Fazit

In diesem Artikel schauen wir uns einmal die verschiedenen Versionen von S/4HANA Produkten an, was die Gemeinsamkeiten und die Unterschiede dabei sind.

 

Einleitung

Du möchtest auf die S/4HANA Public Cloud Edition wechseln, weißt aber gar nicht ob dein System das überhaupt kann oder welche Herausforderungen dort auf dich warten? Daher solltest du dir im ersten Schritt einmal die verschiedenen Versionen anschauen und Vor- und Nachteile abwägen. Daher wollen wir in diesem Artikel auf die unterschiedlichen Punkte innerhalb der Versionen eingehen.

 

Versionen

Gehen wir zunächst auf die verschiedenen Systemversionen ein, wie sie sich voneinander unterscheiden und welche Gemeinsamkeiten sie aufweisen. Um die Differenzen zwischen den einzelnen Releases zu verdeutlichen, hilft ein Blick auf die folgende Grafik:

• Auf der linken Seite siehst du ein klassisches ECC-System, das unseren Ausgangspunkt vor der Migration darstellt.
• In der Mitte sind die verschiedenen Zielversionen abgebildet, auf die eine Migration möglich ist.
• Die rechte Seite ist vor allem für die Themen Extensibility und Erweiterungen in der BTP relevant, darauf werden wir am Ende dieses Artikels noch einmal im Detail eingehen.

© SAP SE

 

Hinweis: Für unsere Erklärung drehen wir die Reihenfolge der verschiedenen Systeme noch einmal um und beginnen mit dem Cloudsystem.

 

Public Cloud

Bei der Public Cloud Lösung handelt es sich um das Standardprodukt der SAP. Hier übernimmt die SAP den Betrieb sowie die Wartung komplett und kümmert sich eigenständig um die Upgrades. Weiterhin hältst du dich hierbei strikt an die Standardprozesse, die du so auch in einem S/4HANA-System vorfindest. Die Upgrades erhältst du in diesem System sehr regelmäßig, in diesem Fall alle sechs Monate. Dabei musst du allerdings beachten, dass die Extensibility (Erweiterbarkeit) des Systems stark eingeschränkt ist. So waren Erweiterungen in der Vergangenheit primär über die Key User Extensibility möglich. Das umfasst das Hinzufügen von Feldern oder Informationen sowie gewisse Logik-Anpassungen, die über Cloud BAdIs implementiert werden. Weitere Möglichkeiten gab es in der Vergangenheit kaum. Seit wenigen Jahren ist jedoch die Erweiterung über ABAP Cloud möglich. Dies umfasst die Entwicklung von kundeneigenen Anwendungen, Tabellen oder Erweiterungen direkt auf der Plattform mittels ABAP und anderer ABAP Cloud Standards.

In der Vergangenheit wurden Public Cloud Systeme vor allem als 2-System-Landschaft aufgebaut. Das bedeutete, es gab einen Customizing- und Extensibility-System für die Entwicklung und Qualitätssicherung sowie einen produktiven Tenant für den Live-Betrieb. In aktuellen Szenarien kann mittlerweile eine 3-System-Landschaft angefordert werden. Dabei kommt als drittes System ein dediziertes Development-System hinzu. Dieses ist notwendig, um tiefergehende Erweiterungen mit ABAP Cloud (On-Stack Extensibility) effizient durchführen und testen zu können, bevor sie in die Qualitätssicherung und Produktion gelangen.

Eine weitere Besonderheit ist der automatische Upgrade-Prozess von SAP Fiori-Anwendungen, die per Extensibility erweitert wurden. In diesem Fall wird nach einem Upgrade zunächst eine Kopie der ursprünglichen Anwendung im System erzeugt. Diese muss anschließend manuell durch einen Entwickler geprüft und gesichtet werden. Erst nach dieser Prüfung erfolgt die Übernahme der Erweiterungen in die Originalanwendung. Das bedeutet im Umkehrschluss: Wenn die App nach einem Upgrade nicht aktiv geprüft wird, arbeitet der Anwender weiterhin mit einer veralteten Kopie der Anwendung im System, anstatt von den Neuerungen des Upgrades zu profitieren.

 

Private Cloud

Bei der Private Cloud Edition handelt es sich im Grunde um einen Mittelweg zwischen der Public Cloud und einer On-Premise-Installation. Den Betrieb dieser Version übernehmen primär die SAP oder entsprechend zertifizierte Partner. Das System selbst wird dabei bei einem Hyperscaler der eigenen Wahl (z. B. Azure, AWS oder GCP) gehostet. Hinsichtlich der Erweiterbarkeit bietet die Private Cloud, genau wie die On-Premise-Variante, weiterhin den vollen Funktionsumfang. Ein Kunde kann somit selbst entscheiden: Strebt er einen "Clean Core"-Ansatz an und nutzt dafür die entsprechenden modernen Methoden (ABAP Cloud), oder führt er seine bestehenden Prozesse wie bisher fort. Letzteres bedeutet jedoch oft, dass veraltete Technologien wie klassische Reports oder die SAP GUI im Einsatz bleiben. Daher unterscheidet sich die Private Cloud vor allem im Betriebsmodell, nicht jedoch in der technologischen Freiheit der Erweiterbarkeit. Ein wichtiger Unterschied bleibt der Innovationszyklus, da neue Releases hier aktuell nur alle zwei Jahre ausgeliefert werden.

 

On-Premise

Kommst du ursprünglich von einem klassischen ECC-System, welches du selbst im eigenen Rechenzentrum betrieben hast, landest du bei einer Migration meistens auf einer On-Premise-Version eines S/4HANA-Releases. Diese Version stellt aktuell den Standard dar, wenn es um die Transformation von Anwendungen und Systemen geht. Viele Unternehmen sind derzeit damit beschäftigt, ihr altes ECC-System auf ein neues S/4HANA On-Premise-System zu migrieren. Dabei sind zunächst die klassischen Migrationsszenarien zu berücksichtigen: Das bedeutet, dass die Simplification Items geprüft und entsprechende Anpassungen im System vorgenommen werden müssen. Doch sind nach der erfolgreichen Migration wirklich keine weiteren Punkte mehr zu beachten? Der Betrieb läuft zwar weiterhin im eigenen Rechenzentrum oder bei einem Partner der Wahl, und auch die Erweiterungsszenarien sind technisch nicht eingeschränkt. Alle bisherigen Technologien können theoretisch weiterverwendet werden. Dennoch solltest du dir zwingend Gedanken über das Thema "Clean Core" machen. Möchtest du wirklich noch alle (teils veralteten) Technologien nutzen, die SAP in diesem Portfolio anbietet oder nutzt du den Umstieg für eine technologische Modernisierung deines Systems.

 

Vergleich

Hier findest du noch einmal einen übersichtlichen Vergleich der aktuellen Versionen und Ausprägungen zu verschiedenen Kriterien die wir gewählt haben.

 

Geht es um die Entscheidung, welche Version eingesetzt werden soll, sollte der Fokus vor allem auf der Erweiterbarkeit des Systems liegen. Hierbei ist zentral zu prüfen: Können die eigenen Prozesse in einer standardisierten Cloud-Lösung abgebildet werden? Oder sind derart tiefgreifende Erweiterungen notwendig, die einen Umzug in eine Public Cloud unmöglich machen? Darüber hinaus müssen essenzielle Themen wie Datensicherheit, Datenschutz und Zugriffsberechtigungen geklärt werden, insbesondere die Frage, ob die Cloud-Vorgaben mit den internen Compliance-Richtlinien des Unternehmens vereinbar sind. Der eigentliche technische Betrieb des Systems ist bei dieser strategischen Entscheidung daher oft nur zweitrangig.

 

Erweiterung

Für die Erweiterung von S/4HANA-Systemen gibt es verschiedene Szenarien, wie die On-Stack Extensibility und die Side-by-Side Extensibility. Die folgende Grafik bietet dazu einen kurzen Überblick, auch wenn wir hier nicht im Detail auf die einzelnen Szenarien eingehen werden. Diese dienen lediglich als Ausgangspunkt für zwei Begriffe, die wir im Folgenden genauer erläutern wollen, um Verwirrungen bei deren Nutzung zu vermeiden: "Steampunk" und "Embedded Steampunk". Hierbei handelt es sich im Grunde um Arbeits- bzw. Projekttitel, die intern bei der SAP verwendet wurden, und nicht um offizielle Produktnamen. Dennoch haben es diese Begriffe in den allgemeinen Sprachgebrauch geschafft, wenn es um die Architektur oder die Benamung der Systeme geht.

© SAP SE

 

Steampunk

Hierbei handelt es sich um ein System, welches in der BTP läuft und verwendet werden kann, um Side-by-Side-Extensions zu bauen. Der offizielle Name lautet "SAP BTP ABAP Environment", diesen findest du auch genau so im Servicekatalog der BTP. Das System ist ein reiner ABAP-Stack, der alle Core-Funktionalitäten bietet, welche die ABAP-Plattform zur Verfügung stellt. Dabei gibt es keine Standardmodule wie zum Beispiel FI/CO oder MM auf dem System. Die neuesten Releases werden hier alle drei Monate ausgeliefert. Damit eignet sich das System perfekt dazu, die eigenen Mitarbeiter in den aktuellsten Technologien und ABAP Best Practices zu schulen.

 

Embedded Steampunk

Beim Embedded Steampunk handelt es sich nicht um ein eigenständiges System, sondern vielmehr um eine Architektur, welche die SAP eingeführt hat. Dabei geht es primär um die Nutzung von "ABAP Cloud" auf den entsprechenden S/4HANA Cloud-Systemen. Mit diesem Ansatz wollte die SAP die Möglichkeiten erweitern, ein S/4HANA Cloud-System anzupassen, ohne wie bisher nur auf die Key User Extensibility angewiesen zu sein. Die Bezeichnung Embedded Steampunk lehnt sich daran an, dass hier die gleiche Methodik wie auf einem Steampunk-System (ABAP Environment) verwendet wird: nämlich ABAP Cloud zur Erweiterung des Systems unter Verwendung von Software-Komponenten zur Kapselung der entsprechenden Logik. Hierbei dürfen, wie bei diesem Modell üblich, nur offiziell freigegebene SAP-APIs und Objekte innerhalb des Systems verwendet werden.

 

Fazit

Nicht nur im Beratungsgeschäft kann es wichtig sein die Unterschiede und Gemeinsamkeiten zu kennen. Unternehmen stehen heute vor er Aufgabe, die richtige Version in der Migration für sich zu finden oder wenn man komplett neu in das SAP Ökosystem einsteigt.

 

YouTube
Video