Rise with SAP: Syntax-Manager erläutert
SAP unkompliziert in die Cloud bringen
Ob gewollt oder nicht – der Umstieg in die Cloud ist für viele SAP-Anwenderunternehmen unausweichlich. Peter Schmidt, Director Business Development beim IT-Serviceprovider Syntax, verrät im Gespräch mit Elisabeth Maller, welche Herausforderungen es bei der Migration von S/4Hana in die Cloud gibt.
connect professional: Herr Schmidt, warum sollten sich Unternehmen, die SAP nutzen, mit dem Betriebsmodell Cloud auseinandersetzen?
Schmidt: SAP hat sich „Cloud first“ auf die Fahnen geschrieben, mit S/4Hana als Cloud-nativer Lösung im Mittelpunkt. Dass man in Walldorf diese Entwicklung vorantreibt, ist nachvollziehbar, denn vor allem die Public Cloud punktet als Betriebsumgebung neben ihren Stärken bei der Infrastruktur – Verfügbarkeit und Flexibilität – auch mit der einfacheren Bereitstellung zahlreicher Services und Add-ons. Hinzu kommt, dass auch sämtliche Upgrades künftig zuerst in der Cloud ausgerollt werden. Neukunden, die noch nicht über maßgeschneiderte SAP-Prozesse verfügen, erhalten mit Grow with SAP eine standardisierte und schnell einsatzbereite Cloud-ERP-Lösung. Wesentlich komplexer ist das für Bestandskunden, die SAP bisher On-Premises betrieben haben. An sie richtet sich Rise with SAP, das Transformationsangebot für eine Migration in die Cloud. Und in den allermeisten Fällen bedeutet dies: zu einem Hyperscaler.
connect professional: Welcher Hyperscaler ist dann für Interessenten die richtige Wahl?
Schmidt: Das lässt sich pauschal leider nicht beantworten und ist immer von den individuellen Anforderungen des Kunden abhängig. Die Wahl des Hyperscalers ist in jedem Fall von strategischer Bedeutung, denn als ERP-System ist S/4Hana Dreh- und Angelpunkt aller betrieblichen Prozesse und spielt auch als zentrale Datenquelle eine wichtige Rolle. Wichtig zu wissen dabei ist, dass nicht alle SaaS-Services aus der SAP Business Technology Platform in allen von SAP selektierten Regionen angeboten werden. Wenn man also geringe Latenzen und die Services ohne eine zwischengeschaltete Internetverbindung nutzen möchte, lohnt ein Blick in die Liste der Services, die verrät, was wo bereitgestellt wird. Das ist nur ein Beispiel dafür, warum eine Multi Cloud-Strategie mit mehreren Anbietern manchmal zwar unausweichlich, aber durchaus sinnvoll sein kann. Dann laufen die SAP-Systeme bei Hyperscaler A und die Non-SAP-Systeme bei Anbieter B. Technisch ist das alles machbar, in der Praxis bietet es sich aber an, den Hyperscaler mit der größten Überdeckung als primäre Plattform auszuwählen.
connect professional: Kann diese Trennung in puncto Performance nicht problematisch werden?
Schmidt: Man muss natürlich immer den Einzelfall anschauen, aber auch beim Betrieb von Drittsoftware in der Public Cloud gibt es ein paar grundsätzliche Dinge zu berücksichtigen. So sollte ein Archiv oder eine EDI-Plattform eng mit dem SAP-System verbunden sein und idealerweise im gleichen Rechenzentrum oder zumindest in der gleichen Region wie S/4Hana betrieben werden. Bei SAP-Lösungen wie EWM oder GTS gibt es hingegen mehrere Möglichkeiten. Entweder stellt man sie selbst in der eigenen Landing Zone bereit oder lässt sie im Rise-Betriebsmodell direkt durch SAP betreiben. Etwas komplizierter wird es bei Add-ons, die bisher auf dem SAP-Server gelaufen sind. Da ist dann ein Abgleich mit dem SAP Certified Solution Directory erforderlich – und gegebenenfalls müssen Alternativen oder andere Betriebsmodelle in Betracht gezogen werden.
connect professional: Ein wichtiges Thema rund um den Betrieb von SAP in der Public Cloud ist IT-Security. Was gibt es da zu beachten?
Schmidt: Auch hier spielt die Landing Zone beim ausgewählten Hyperscaler eine wichtige Rolle. Damit haben Unternehmen die Internet- und WAN-Verbindungen unter eigener Kontrolle, können eigene, zentral gemanagte Firewall-Systeme platzieren und ein eigenes Regelwerk festlegen und überwachen. Die Verbindung zwischen verschiedenen Datenquellen erfolgt innerhalb des Hyperscaler-Netzwerks und die Anbindung des SAP-Tenants mit Hilfe von Standardmechanismen wie VNet-Peering oder VPC-Peering.
connect professional: Welche weiteren wichtigen Änderungen müssen Unternehmen beim Umzug von SAP in die Public Cloud beachten?
Schmidt: Ein besonders wichtiger Aspekt sind die für die Betriebsleistung relevanten Verantwortlichkeiten. Hier hat SAP für Rise mit der Roles-and-Responsibility-Matrix eine umfangreiche Dokumentation veröffentlicht – und die unterscheidet sich in einigen Punkten deutlich von den im SAP-Basisservice gebräuchlichen Abgrenzungen. Einige Leistungen, die beim klassischen SAP-Basisbetrieb vom Dienstleister übernommen wurden, liegen aus Sicht von SAP jetzt beim Kunden. Dazu gehören beispielsweise die Bewertung und Planung von technischen Anpassungen oder Wartungsarbeiten. Die tatsächliche Umsetzung erfolgt dann durch SAP. Hier sollten sich Verantwortliche einen Überblick über das zukünftige Betriebsmodell, die dazugehörige Governance und die resultierenden Betriebsschnittstellen verschaffen. Anschließend müssen sie dann entscheiden, ob sie die „neuen“ Aufgaben der internen IT-Abteilung übertragen oder einen externen Dienstleister engagieren, der im täglichen Betrieb als Anlaufstelle zwischen den Modul- bzw. Prozessverantwortlichen oder Key Usern und SAP fungiert. Das bietet sich insbesondere bei hybriden Betriebsmodellen an.
connect professional: Hat der Betrieb in der Cloud denn auch Auswirkungen auf die IT-Prozesse?
Schmidt: Ja, der erfolgreiche Betrieb von SAP in der Public Cloud hängt sogar ganz wesentlich von der Gestaltung der IT-Prozesse ab. Denn Public Cloud-Plattformen und somit auch die Grow- und Rise-Betriebsmodelle, zeichnen sich durch einen hohen Standardisierungs- und Automatisierungsgrad aus. Deshalb ist es unerlässlich, dass SAP die Support-Prozesse in seinen ITSM-Tools sehr genau definiert und vorgibt. Dies bedeutet, dass Unternehmen in der Lage sein müssen, zukünftig alle Anpassungen und Änderungen ausschließlich über ein Ticketsystem zu beauftragen. Und das ist leider nicht für alle SAP-Anwenderunternehmen das gewohnte tägliche Zusammenarbeitsmodell. Hier sehen wir auch den Grund, warum SAP einige Leistungen aus dem SAP-Basisumfeld dem Kunden zuordnet. Um nicht mit falschen Erwartungen in den neuen Betrieb zu wechseln und dann enttäuscht zu werden, sollten sich IT-Verantwortliche daher im Vorfeld Gedanken über die eigene Prozessreife und die Nutzung von standardisierten ITSM-Tools und Prozessen machen.
Elisabeth Maller ist freie IT-Autorin München.
Lesen Sie mehr zum Thema
