Zusammenfassung: Der Blogbeitrag erläutert die Unterschiede zwischen den verschiedenen Betriebsmöglichkeiten von SAP S/4HANA, einschließlich HEC Multi Tenant Edition, SAP S/4HANA Extended Cloud, Private Edition und On-Premise System, und gibt Empfehlungen, welche Optionen in verschiedenen Szenarien am besten geeignet sind. Die Wahl der Betriebsmöglichkeiten hängt von verschiedenen Faktoren ab, wie z.B. der Unternehmensgröße, der IT-Strategie und den betrieblichen Anforderungen.
Für den Betrieb von S/4HANA Systemen sind aufgrund der Tatsache, dass die SAP selbst nunmehr sehr konsequent in den Markt der Cloud Computing eingestiegen ist, mittlerweile vielfältige Alternativen verfügbar. Je nachdem, mit wem man spricht sind diese Alternativen mit einer sehr unterschiedlichen – und deshalb auch für den interessierten SAP-Kenner häufig verwirrenden – Nomenklatur belegt. Ich unternehme nachfolgend den Versuch, das Ganze etwas zu entwirren und die wichtigsten Begriffe möglichst einfach zu erläutern. Hierbei gehe ich von den unterschiedlichen Betriebsmodellen aus, wie sie die SAP selbst darstellt:
Quelle: SAP SE
Unterscheidung der physischen Betriebsebenen
Grundsätzlich ist es sinnvoll, bei der Klärung der Begrifflichkeiten die physische Betriebsebene und die Applikationsebene zu unterscheiden.
Auf der physischen Betriebsebene können zwei wesentliche Arten unterschieden werden:
On-Premise:
Dies bedeutet, die Rechner, auf denen das S/4HANA (und ggfs. weitere SAP Software) installiert ist stehen physisch bei uns im Rechenzentrum oder auch als Cluster bei einem Outsourcing Dienstleister, der diese exklusiv für uns betreibt. Die Hardware, auf denen Applikationen und Datenbanken laufen, stehen also exklusiv für unsere Nutzung zur Verfügung. Wir bestimmen in diesem Fall i.d.R. maßgeblich über Architektur und Sizing der zugrundeliegenden Rechner mit.
Cloud:
Dies bedeutet, die Rechnerleistung, die wir für die für den Betrieb unseres S/4HANA Systems (und ggfs. weiterer SAP Software) benötigen, wird uns von einem entsprechenden Dienstleister zur Verfügung gestellt – die wesentlichen Player in diesem Umfeld sind derzeit einige SAP System- und Beratungshäuser wie auch die SAP selbst mit Ihrer HEC (Hana Enterprise Cloud), die, wie wohl die meisten anderen auf der Azure Cloud von Microsoft basiert.
Unterscheidung auf Applikationsebene
Auf der Applikationsebene erfolgt die Unterscheidung im Wesentlichen danach, inwieweit uns die einzelnen Elemente der betroffenen Applikationsarchitektur exklusiv zur Verfügung stehen, bzw. inwieweit wir deren Nutzung mit anderen Unternehmen „teilen“. Folgende sind die gängigen Unterscheidungen unter diesem Aspekt – angefangen von der mit dem niedrigsten individuellen Freiheitsgrad hin zu der mit dem höchsten gestellt (ich spreche im Folgenden nur von dem Produktivsystem und vernachlässigen Development, Integrations- und Q-Systeme):
Multi Tenant Edition (MTE) in der HEC (der SAP):
In einer mandantenfähigen Multi-Tenant Cloud teilt ein Cloud-Anbieter Infrastruktur, Anwendungen oder Plattformen unter mehreren Kunden auf, so dass sie alle Ressourcen gemeinsam nutzen. Der Vorteil: Der Provider selbst verwaltet bei der mandantenfähigen Cloud Skalierbarkeit, Sicherheit und Upgrades. Der Nachteil ist, dass ein Unternehmen seine ERP-Anwendungen nicht sehr gut eigenständig kontrollieren kann. In der Multi Tenant Edition in der Public-Cloud (multi-tenant (MTE), also mandantenfähige Cloud) bekommen wir einen eigenen Mandanten zur Verfügung gestellt. Dies bedeutet, dass wir zwar im mandantenabhängigen Bereich alleiniger Nutzer sind, uns den mandantenunabhängigen Bereich (also das mandantenunabhängige Customizing und Entwicklungen) mit den anderen Nutzern der Cloud teilen; ergo haben wir nicht die Freiheit in diesem Bereich individuell nur für uns etwas zu verändern, sondern sind vielmehr dazu verpflichtet, das, was die SAP als Cloud Betreiber anbietet, zu nutzen oder eben nicht. Vor diesem Hintergrund ist diese Lösung wohl insbesondere etwas für Unternehmen, die sich mit ihren Prozessen zu annähernd 100% in den Best-Practise-Prozessen (link) wiederfinden oder die Strategie haben, sich dort zu 100% einfinden zu wollen. Meiner Einschätzung nach betrifft das am ehesten kleinere Unternehmen oder Unternehmen mit einer sehr überschaubaren Anzahl von (einfachen) Prozessen, wie zum Beispiel Beratungsunternehmen.
In der Public-Cloud kommt das sogenannte Subcription Licensing zum Einsatz, dies bedeutet, die Lizenzen werden nicht gekauft, sondern man zahlt nach Nutzung der einzelnen Funktionen und dies in Abhängigkeit von dem Volumen.
In allen Cloud-Lösungen wird die Administration des SAP Systems (SAP-Basis), der Datenbanken und aller sonstigen Komponenten unterhalb der Applikation selbst von dem Cloud Betreiber übernommen.
In der MTE muss man verpflichtend an vier Release-Updates pro Jahr an den durch die SAP definierten Zeitpunkten teilnehmen.
SAP S/4 Hana Extended Cloud (also known as Single Tenant Edition – STE) in der HEC (der SAP):
Die Single-Tenant Cloud-Bereitstellung – sie wird manchmal auch als Hosted oder Managed Service bezeichnet – beinhaltet in der Regel eine größere Kontrolle über die Umgebung. Single-Tenant Cloud bedeutet, dass ein Unternehmen dedizierten Zugriff auf die Cloud-Infrastruktur, die Apps oder die Plattform erhält. Es ist vergleichbar mit dem Betrieb einer Private Cloud für diese Anwendung, mit dem Unterschied, dass diese im Cloud-Ökosystem der SAP HEC gehostet wird. Das wiederum erleichtert die Integration mit anderen Anwendungen oder Diensten, die beim selben Cloud-Anbieter laufen. In der Single Tenant Edition (STE), sind wir als also alleiniger Mieter der Infrastruktur und bekommen natürlich eine oder mehrere eigene Datenbankinstanzen für das ERP zur Verfügung gestellt; dies bedeutet, dass wir sowohl im mandantenabhängigen als auch im mandantenunabhängigen Bereich alleiniger Nutzer sind und damit ergo auch die Freiheit haben, Anpassungen in beiden Bereichen vorzunehmen. Allerdings unterliegen diese in der HEC der SAP ebenfalls strengen Restriktionen, so müssen zum Beispiel alle Add-Ons von Drittanbietern, die man in der STE nutzen möchte, vom Anbieter bei der SAP für den Betrieb in der HEC zertifiziert sein! Dies kann zu massiven Verzügen im Projekt führen; deshalb sollte man vor der Entscheidung in die SAP HEC zu gehen, alle notwendigen Add-Ons für den Betreib in der HEC zertifiziert haben. Ähnliches gilt für eigenentwickelte Programme und Datenobjekte. Eine entsprechende Klassifizierung in den unterschiedlichen Lösungen zulässiger Änderungen können Sie in dieser Präsentation finden. In dieser ist dargestellt, welche Anpassungen in der Public bzw. in der Private Cloud zulässig sind. Restriktionen gibt es insbesondere auch bei der Nutzung der Kommunikationsinfrastruktur (API). Folgende links geben Aufschluss darüber, was in den Cloud Lösungen der SAP an Kommunikationsmöglichkeiten (BAPIs und IDOCs) zur Verfügung steht:
In der Cloud wie On-Premise können BAPI’s, Idocs von S4HANA und auch die Cloud-API’s verwendet werden, die im SAP API Hub unter https://api.sap.com/ aufgelistet sind.
Die vollständige Integration ist für S4HANA Public Cloud, Ariba, SuccessFactors und OnPrem-Systeme verfügbar. Wie ein kundeneigenes On-Premise-System können Sie es nach Belieben erweitern und modifizieren, einschließlich der Darstellung von Daten über SAP-Tabellen mit Ihren eigenen benutzerdefinierten Schnittstellen (Read, Write). Für STE gilt dasselbe wie oben, mit wichtiger Einschränkung: Der SAP-Code muss unverändert bleiben, d.h. Kunden können den SAP-Code nicht ändern.
Verfügbare BAPIs und Idocs für die Integration sind in den folgenden Hinweisen dokumentiert (Achtung: zum Zugriff auf die SAP-Hinweise müssen Sie sich mit Ihrem SAP S-User anmelden):
https://launchpad.support.sap.com/#/notes/2506411 : Verfügbare iDocs in der S/4HANA Cloud zur Integration in SAP On Premise Lösungen
https://launchpad.support.sap.com/#/notes/2447593 : Verfügbare BAPIs in der S/4HANA Cloud zur Integration in SAP On Premise Lösungen
Es gibt einen guten Blog, der es wert ist, die STE-Implementierung zu überprüfen.
Auch in dieser Cloud Lösung kommt das sogenannte Subcription Licensing zum Einsatz, dies bedeutet, die Lizenzen werden nicht gekauft, sondern man zahlt nach Nutzung der einzelnen Funktionen und dies in Abhängigkeit von dem Volumen.
In allen Cloud-Lösungen wird die Administration des SAP Systems (SAP-Basis), der Datenbanken und aller sonstigen Komponenten unterhalb der Applikation selbst von dem Cloud Betreiber übernommen.
In der STE muss man verpflichtend an zwei Release-Updates pro Jahr an einem durch die SAP definierten Zeitpunkt teilnehmen.
SAP S/4 Hana Private Edition in der HEC (der SAP) Nachtrag Dez. 2020):
Wohl aufgrund massiven Kundendrucks (Darauf werde ich im Januar in BLOG-Beitrag 23 näher eingehen: „Unsere Empfehlung aufgrund der gemachten Erfahrungen: Finger weg von der HEC STE der SAP!“) hat die SAP jüngst eine neue Variante auf den Markt gebracht: die private Edition in der HEC. Hierbei handelt es sich um 1:1 dieselbe Infrastruktur wie bei der HEC STE, allerdings mit einer anderen Vertragsform mit deutlich weniger Restriktionen. Dies betrifft:
- Die Nutzung von Add-Ons von Drittanbietern (diese bedürfen keiner Zertifizierung mehr)
- Keine Verpflichtung mehr zur Durchführung von Release-Updates
- Keine vorgegebenen einzuhaltenden Standards bei Eigenentwicklungen
Man bekommt also eine quasi vollständig eigenständige SAP Umgebung in der HEC der SAP zur Verfügung gestellt – also quasi On-Premise Möglichkeiten im Rahmen eines Subscription Licensing. Man darf einerseits gespannt sein, inwieweit sich das mit den sonstigen Nutzenversprechen der SAP hinsichtlich der Vorteile der HEC Nutzung vereinbaren lässt und andererseits wird es interessant werden zu sehen, wie die SAP HEC Truppe diese unterschiedlichen Konzepte in derselben Cloud betreiben will. Ausgereifte Konzepte kommen anders daher, daher empfehle ich im Anschluss das Studium meines BLOG Beitrags 21)
On-Premise:
Bei der On-Premise Installation haben wir unsere eigenen Applikationen, deren Lizenzen wir erworben haben auf einer entsprechenden Hardware (On-Premise oder in der Cloud) installiert und per se erst einmal auch durch uns betrieben, inkl. der Administration des SAP Systems (SAP-Basis), der Datenbanken und aller sonstigen Komponenten. Natürlich sind wir bei dieser Lösung vollständig frei und unabhängig bzgl. der Anpassungen und Erweiterungen des S/4HANA Systems und wir haben auch keine Vorgaben, die wir hinsichtlich der Release-Updates einhalten müssen – natürlich mit Ausnahme der gesetzlich vorgeschriebenen. Bei dieser Lösung handelt es sich wohl um die, die beim Betrieb von SAP R/3 Systemen am meisten verbreitet ist und war. Natürlich gibt es allein in diesem Szenario dann auch noch die diversesten Make or Buy Fragestellungen, die man sich seriös beantworten sollte, insbesondere hinsichtlich des Outsourcing des Rechnerbetriebs einschl. der Administration des SAP Systems (SAP-Basis), der Datenbanken und aller sonstigen Komponenten unterhalb der Applikation; in den meisten Unternehmen zählen diese nämlich nicht zu den Kernkompetenzen, wegen derer man am Markt ist und deshalb empfiehlt es sich in der Regel, diese kompetent einzukaufen und somit einen in der Regel stabileren und günstigeren Basisbetrieb gewährleisten zu können – oder man dreht den Spieß eben um und bietet anderen Unternehmen diesen Service als zusätzliche Erweiterung des eigenen Portfolios an; auch dies haben schon viele Unternehmen erfolgreich hinbekommen, wie ich im Rahmen diverser von mir betreuter SAP Outsourcing Projekt erfahren durfte.
Nachstehendes Schema gibt eine gute Übersicht und Orientierung um sich durch die aus den vorgenannt beschriebenen Möglichkeiten ergebenen Kombinationen zu bewegen:
Nutzung On-Premise in der SAP HEC oder Non-SAP Cloud
Bei der On-Premise-Installation in der Cloud möchte ich noch auf den meiner Meinung nach wesentlichen Unterschied zwischen der Nutzung der On-Premise Lösung in der SAP HEC und der On-Premise Installation in einer Non-SAP Cloud hinweisen: In der SAP Cloud SAP HEC gibt die SAP den Aufbau der gesamten Architektur vor während man diese bei der Installation in einer Non-SAP Cloud, die wie die HEC meist auch auf MS-Azure basieren Cloud selbst definieren und auslegen kann. Dies kann erhebliche Auswirkungen auf Kosten und Performance haben, weshalb ich grundsätzlich dazu raten würde, beide Alternativen gegenüberzustellen, wenn man über ein On-Premise Installation in der Cloud nachdenkt und sich dabei von einem Experten beraten zu lassen (einen entsprechenden Kontakt kann ich gern herstellen).
Fazit:
Meiner Wahrnehmung nach fokussieren immer noch viele (produzierende) Unternehmen auf eine On-Premise Installation und dies zumeist auch auf einer On-Premise Hardware. Kaum einer wagt sich auf die Single-Tenant Edition in der Cloud der SAP, obwohl diese im Vergleich zu einer On-Premise Lösung und wenn man sich mal wirklich von (richtigen) Modifikationen verabschiedet hat, den einzigen wesentlichen Unterschied in der Verpflichtung zum jährlichen Release-Update hat – und das wäre ja in vielen Unternehmen durchaus zu begrüßen. Man muss natürlich auch mit den in der Cloud zur Verfügung stehenden API-Funktionalitäten (s. oben genannter link) zurechtkommen und sich mit seinen potentiellen Erweiterungen in dem in der STE zulässigen Rahmen bewegen. Aber wenn das gegeben ist, sollte die Nutzung der STE auch für produzierende Unternehmen durchaus eine ernsthafte Erwägung sein und unter Total-Cost-of-Ownership Gesichtspunkten mit in die Entscheidungsfindung einbezogen werden.
UND DAS IST ZUM GLÜCK AUCH RICHTIG SO – S. HIERZU BLOG BEITRAG 21
„Finger weg von der HEC STE der SAP!“
Zum guten Schluss:
Ich habe mich hier bewusst nicht zu den Kostenaspekten der unterschiedlichen Lösungen geäußert, da ich denke, dass in diesem Zusammenhang so gut wie keine Aussagen möglich sind, ohne die spezifische Situation und Gewichtung der einzelnen Aspekte zu betrachten. Auch habe ich sicherlich nicht alle Gesichtspunkte in allen Varianten vollständig in die Betrachtung einbeziehen können; ich hoffe aber, dass es mir gelungen ist, eine erste Übersicht und Orientierung zu geben.
Nachtrag Dez. 2020: Im BLOG-Beitrag 21 – „Unsere Empfehlung aufgrund der gemachten Erfahrungen: „Finger weg von der HEC STE der SAP!“ berichte ich von unseren Erfahrungen mit der HEC STE der SAP in dem jüngst beendeten Projekt. Es hat sich vieles von dem, das ich zu dem Zeitpunkt, als ich diesen Beitrag ursprünglich verfasst habe, sehr deutlich relativiert: Der Betrieb eines neuen S/4HANA Systems in der Cloud kann eine sehr sinnvolle Lösung sein, allerdings sollte man dies bei einem Partner tun, der mature und erfahren genug ist, eine solche Lösung auch gesichert und mit einem vollumfänglichen Service zu betreiben – die SAP gehört aktuell wohl nicht dazu. Da es mittlerweile auch die Möglichkeit für andere Anbieter gibt den Gesamtbetrieb des S/4HANA als SAAS Lösung im Subscription Licensing zu betreiben, sollte man auf die Auswahl des geeigneten Partners mindestens soviel Wert legen, wie auf die Wahl des Deployment Modells – und keinesfalls dem Irrglauben unterliegen, die große SAP als zudem noch Hersteller der Software müsste der beste Partner sein!