Cloud verändert den Betrieb: Warum sich nicht nur die SAP-Basis neu aufstellen muss

Alle Systeme grün – und trotzdem steht der Prozess

Alle Systeme sind grün und trotzdem hängt der Kundenauftrag. SAP meldet das S/4HANA-System als verfügbar, die BTP läuft, auch der SaaS-Anbieter sieht keine Störung. Doch ein Release hat das Verhalten einer Schnittstelle verändert. Die Integration scheitert und im Vertrieb kann niemand den Auftrag abschließen. Wer übernimmt jetzt die Führung bei der Störung?

Der Wechsel zu SAP S/4HANA Cloud, SAP BTP, ergänzenden Cloud-Lösungen und hybriden Landschaften verändert mehr als die technische Plattform. Gerade wenn mehrere Anbieter beteiligt sind, entscheidet die Organisation des Betriebs darüber, ob Geschäftsprozesse zuverlässig funktionieren.

Unsere These: Cloud verlagert technische Betriebsaufgaben zum Anbieter und erhöht zugleich den Steuerungsbedarf im Unternehmen. Wer Infrastruktur auslagert, bleibt für funktionierende Geschäftsprozesse verantwortlich. Deshalb müssen IT, Fachbereiche und Provider gemeinsam festlegen, wer Services End-to-End verantwortet, Änderungen bewertet und Störungen über Anbietergrenzen hinweg koordiniert. Dieses Betriebsmodell gehört ebenso früh auf die Agenda wie Technologie, Migrationspfad und Architektur.

Wandel im SAP-Betrieb

Vom klassischen SAP-Betrieb zum Cloud Operating Model

Im klassischen Eigenbetrieb betreute die SAP-Basis viele Komponenten selbst: Infrastruktur, Betriebssystem, Datenbank und SAP-System. Bei Managed Services und Cloud-Angeboten übernimmt der Provider je nach Vertrag einen Teil dieser Aufgaben. Die Verantwortung für Anwendung, Prozesse und das Zusammenspiel der Services muss das Unternehmen weiterhin organisieren.

Mit jeder zusätzlichen Cloud-Anwendung wachsen die Übergänge zwischen Systemen, Teams und Providern. Integration, Berechtigungen, Release-Planung und die Steuerung von Dienstleistern werden damit zu Betriebsaufgaben.

Der Betrieb wird dadurch nicht automatisch einfacher. Er wird anders.

Die direkte technische Kontrolle über einzelne Infrastrukturkomponenten nimmt ab. Gleichzeitig steigt die Bedeutung von Governance, Koordination und End-to-End-Verantwortung.

Verantwortungsmatrix

Betriebsmodelle im Vergleich: Wer verantwortet was?

Jede Stufe verschiebt die Grenze zwischen dem, was das Unternehmen selbst tut, und dem, was es einkauft. Die folgende Übersicht zeigt die typische Verteilung (im Einzelfall abhängig vom Vertrag):

Betriebsmodell	Kunde verantwortet	Provider verantwortet	Neue Kernaufgabe
Klassisch (On-Premise, Eigenbetrieb)	Infrastruktur, Basis, Anwendung	–	Systembetrieb
Betreut (Hosting, Managed Services)	Anwendung, Steuerung der Services	Infrastruktur und Basisbetrieb (je nach Vertrag)	SLA-Steuerung
Hybrid	Kernanwendung, Integration, Erweiterungen	Betrieb der Cloud-Services, z. B. BTP	End-to-End-Sicht über alle Komponenten
S/4HANA Cloud Private Edition	Anwendung, Berechtigungen, Tests, Erweiterungen	Infrastruktur, Basisbetrieb, technische Upgrades (laut Vertrag)	Release- und Änderungsplanung mit SAP abstimmen
S/4HANA Cloud Public Edition	Konfiguration, Berechtigungen, Daten, Tests	Plattform, Betrieb, Updates	Release- und Erweiterungs-Governance (Clean Core)

Bei SAP S/4HANA Cloud Private Edition bleibt viel Gestaltungsspielraum und damit auch viel Verantwortung für Erweiterungen, Tests und die Abstimmung von Upgrades mit dem Provider. Bei der Public Edition gilt der Standard: Erweiterungen laufen über definierte Wege (In-App- und Side-by-Side-Extensibility auf der BTP), Updates folgen dem Rhythmus des Anbieters. Wer beide Optionen einsetzt oder plant, betreibt faktisch zwei Betriebsmodelle mit unterschiedlichen Spielregeln.

Rolle der SAP-Basis

Die SAP-Basis verschwindet nicht, aber ihre Rolle verändert sich

Die Vorstellung, dass mit dem Wechsel in die Cloud klassische SAP-Basis-Kompetenzen nicht mehr benötigt werden, greift zu kurz. Bestimmte Aufgaben werden tatsächlich vom Cloud-Anbieter übernommen oder stärker automatisiert. Dafür gewinnen andere Fähigkeiten an Bedeutung.

Aus der klassischen technischen Betriebsrolle entwickelt sich zunehmend eine Rolle, die verschiedene technische und organisatorische Ebenen miteinander verbindet. Dazu gehören beispielsweise die Steuerung von Cloud-Services, die Koordination von Releases und Wartungsfenstern, das Monitoring von Integrationen und Services sowie die Abstimmung mit SAP und weiteren Dienstleistern.

Technisches Verständnis bleibt damit essenziell. Die Perspektive verändert sich jedoch: Weg vom Betrieb einzelner Komponenten und hin zur Steuerung einer verteilten SAP-Service-Landschaft.

Verantwortung im Unternehmen

Verantwortung lässt sich nicht vollständig in die Cloud verlagern

Im Beispiel vom Kundenauftrag kann jeder Provider für seine Komponente eine grüne Verfügbarkeit melden. Das Unternehmen braucht trotzdem eine Stelle, die den gesamten Geschäftsservice betrachtet, die Ursache eingrenzt und die Beteiligten zusammenführt.

Ein Cloud-Vertrag regelt technische Zuständigkeiten, aber nicht automatisch die Führung eines Incidents über mehrere Anbieter hinweg. Dafür braucht es einen benannten Service Owner mit Mandat, Eskalationswegen und Kenntnis der betroffenen Geschäftsprozesse.

Die Verantwortung für das funktionierende Zusammenspiel bleibt beim Unternehmen, auch wenn einzelne technische Komponenten von SAP oder anderen Providern betrieben werden.

Serviceorientierung

Aus Systembetrieb wird Service Management

Mit zunehmender Cloud-Nutzung verändert sich auch die organisatorische Perspektive. Im klassischen Betrieb standen häufig einzelne Systeme im Mittelpunkt: Ist das SAP-System erreichbar? Läuft die Datenbank? Sind die Schnittstellen verfügbar?

Für Fachbereiche ist diese Sicht jedoch nur bedingt relevant. Entscheidend ist, ob der Geschäftsprozess funktioniert.

Ein moderner SAP-Betrieb muss deshalb stärker serviceorientiert denken. Statt ausschließlich technische Komponenten zu überwachen, sollte der Fokus auf geschäftskritischen Services und Prozessketten liegen.

Ein Order-to-Cash-Prozess kann beispielsweise aus mehreren Cloud- und On-Premise-Komponenten bestehen. Technisch können sämtliche Systeme verfügbar sein und trotzdem funktioniert der Prozess nicht vollständig.

Genau hier verändert Cloud auch das Verständnis von Betrieb: Verfügbarkeit einzelner Komponenten ist nicht gleichbedeutend mit einem funktionierenden Business Service.

Zusammenarbeit

Fachbereich und IT müssen enger zusammenarbeiten

Cloud-Anwendungen bringen häufig kürzere Release-Zyklen und kontinuierliche Weiterentwicklungen mit sich. Ein einzelnes Update kann Schnittstellen, Erweiterungen oder Abläufe im Fachbereich beeinflussen.

Darum müssen IT und Fachbereich Auswirkungen früh prüfen, Tests planen und Änderungen priorisieren. Die Provider müssen Termine und technische Abhängigkeiten transparent machen. Im Beispiel des Kundenauftrags hätte eine gemeinsame Release-Planung die betroffene Integration vor dem Update in den Blick genommen.

Diese Zusammenarbeit lässt sich nicht allein über Tickets und Eskalationsprozesse organisieren. Sie benötigt klare Entscheidungswege, Verantwortlichkeiten und regelmäßige Abstimmung.

Multi-Provider-Steuerung

Auch das Provider Management wird wichtiger

Die typische SAP-Landschaft der Zukunft besteht selten aus einem einzigen Betriebsmodell. Stattdessen treffen verschiedene Welten aufeinander:

SAP S/4HANA Cloud (Public und Private Edition), SAP BTP, zusätzliche SaaS-Lösungen wie SuccessFactors, Ariba, Logistics Management, Hyperscaler-Plattformen, bestehende On-Premise-Systeme und Services verschiedener Dienstleister müssen miteinander funktionieren.

Damit verändert sich die Rolle der internen IT erneut. Sie muss nicht mehr nur selbst betreiben, sondern zunehmend ein Ökosystem unterschiedlicher Service Provider orchestrieren.

Das erfordert neue Fähigkeiten im Vendor- und Service-Management. Service Level müssen aufeinander abgestimmt, Zuständigkeiten klar definiert und Eskalationswege über Unternehmensgrenzen hinweg etabliert werden.

Denn für den Fachbereich spielt es letztlich keine Rolle, welcher Provider für eine Störung verantwortlich ist. Entscheidend ist, wie schnell der Geschäftsprozess wieder funktioniert.

Rollenmodell

Neue Rollen für ein neues Betriebsmodell

Ein Cloud Operating Model verlangt nicht zwingend zusätzliche Stellen. Es verlangt jedoch eindeutige Zuständigkeiten und die Befugnis, über Team- und Provider-Grenzen hinweg zu handeln. Besonders wichtig sind:

Service Owner: verantwortet einen Geschäftsservice wie Order-to-Cash über die beteiligten Systeme und Provider hinweg.

Provider- und Service-Manager: steuert SLAs, Eskalationswege und die Zusammenarbeit mit SAP und weiteren Dienstleistern.

Integrations- und Plattformverantwortliche: betreuen Schnittstellen, BTP-Governance und Erweiterungen im Rahmen der Architekturvorgaben.

Release- und Lifecycle-Manager: koordinieren Updates, Tests und Entscheidungen mit den Fachbereichen.

Auch Security, Identity Management und die laufenden Cloud-Kosten brauchen klare Zuständigkeiten. Bei der Kostensteuerung geht es um Transparenz über Verbrauch und gebuchte Services sowie um die Frage, wer neue Leistungen freigibt und ihren Nutzen bewertet.

Vier Entscheidungen vor dem Go-live

Cloud Transformation ist auch eine Operating-Model-Transformation

Der Wechsel zu SAP S/4HANA Cloud oder SAP BTP sollte deshalb nicht als ein reines Technologie- oder Migrationsprojekt betrachtet werden.

Das zukünftige Betriebsmodell sollte parallel zur technischen Migration entstehen. Vier Entscheidungen gehören vor dem Go-live:

Geschäftsservices benennen: Wer trägt für die kritischen Prozessketten die End-to-End-Verantwortung und darf bei einer Störung koordinieren?
Provider-Grenzen klären: Welche Aufgaben übernimmt SAP, welche ein weiterer Dienstleister und welche bleiben intern? Wo liegen Übergaben und Eskalationswege?
Releases gemeinsam steuern: Wie bewerten IT und Fachbereiche Änderungen, testen Integrationen und entscheiden über die Freigabe?
Fähigkeiten ausrichten: Welche Kompetenzen für Basis, Integration, Security, Architektur und Provider-Steuerung müssen intern verfügbar sein?

Auf den Punkt gebracht

Fazit: Weniger Infrastruktur bedeutet nicht weniger Verantwortung

Cloud nimmt Unternehmen technische Aufgaben ab. Sie nimmt ihnen jedoch nicht die Verantwortung für einen stabilen und effizienten SAP-Betrieb. Im Gegenteil: Je stärker Anwendungen, Plattformen und Provider miteinander vernetzt sind, desto wichtiger werden klare Verantwortlichkeiten, Serviceorientierung und eine funktionierende Governance.

Die SAP-Basis bleibt dabei ein wichtiger Bestandteil des Betriebs, allerdings mit einem veränderten Aufgabenprofil. Gleichzeitig müssen sich auch Application Management, Architektur, Security, Fachbereiche und Provider-Steuerung weiterentwickeln.

Die zentrale Frage lautet deshalb nicht nur:

„Wie bringen wir SAP in die Cloud?“

Sondern vielmehr:

„Wie müssen wir unseren Betrieb organisieren, damit eine hybride und cloudbasierte SAP-Landschaft dauerhaft funktioniert?“

Genau diese Frage entscheidet am Ende darüber, ob aus einer technischen Cloud-Migration auch eine erfolgreiche Cloud-Transformation wird.

FAQ

Häufige Fragen zum Cloud Operating Model

Was verändert sich im SAP-Betrieb durch die Cloud?

Technische Aufgaben gehen je nach Betriebsmodell an SAP oder andere Anbieter über. Gleichzeitig muss das Unternehmen Integrationen, Releases und Störungen über mehrere Systeme und Provider hinweg koordinieren.

Wird die SAP-Basis in der Cloud noch benötigt?

Ja. Ihr Schwerpunkt verschiebt sich: Technisches Verständnis bleibt wichtig, während Release-Koordination, Integration, Plattform-Governance und die Zusammenarbeit mit Providern mehr Gewicht bekommen.

Wer ist bei einer Störung in einer hybriden SAP-Landschaft verantwortlich?

Für einzelne Komponenten gelten die jeweiligen vertraglichen Zuständigkeiten. Das Unternehmen sollte zusätzlich festlegen, wer den betroffenen Geschäftsservice Ende zu Ende verantwortet und die beteiligten Teams und Provider zusammenführt.

Warum reicht die Verfügbarkeit einzelner SAP-Systeme nicht aus?

Ein Geschäftsprozess kann trotz technisch verfügbarer Systeme scheitern, etwa wenn eine Schnittstelle nach einem Release nicht mehr funktioniert. Deshalb müssen Monitoring und Incident Management auch die gesamte Prozesskette betrachten.

Wie unterscheiden sich SAP S/4HANA Cloud Private und Public Edition im Betrieb?

Die Modelle unterscheiden sich unter anderem bei Gestaltungsspielraum, Erweiterungen und der Planung von Änderungen. Welche Aufgaben beim Unternehmen und welche beim Anbieter liegen, muss für das konkrete Angebot und den Vertrag geklärt werden.

Was sollte vor dem Cloud Go-live organisatorisch feststehen?

Unternehmen sollten Verantwortliche für kritische Geschäftsservices benennen, Übergaben zwischen Providern klären, Release- und Testentscheidungen festlegen und die benötigten internen Kompetenzen bestimmen.

Ihr nächster Schritt

Wie sieht Ihr Operating Model nach der Cloud-Migration aus?

Wir unterstützen Unternehmen dabei, ihr SAP Operating Model parallel zur technologischen Transformation zu entwickeln: Vom Zielbild über das Rollenmodell bis zum Übergang in den Betrieb.

Von Werner Schwering, 05. Oktober 2026

Dieser Beitrag basiert auf fachlicher Expertise und Praxiserfahrungen aus dem cimt-Umfeld. KI-basierte Werkzeuge wurden unterstützend bei der redaktionellen Ausarbeitung eingesetzt. Die inhaltliche Prüfung und Freigabe liegen bei den Autorinnen und Autoren.

Kontakt

Werner SchweringSenior IT / SAP Consultant, cimt ag