SAP S/4HANA zwingt Unternehmen zu neuen Betriebsmodellen

Das Ende des ECC-Paradigmas

Der Umstieg auf SAP S/4HANA steht selten nur für eine technische Konvertierung. Das Programm greift tief in das Betriebsmodell ein, da SAP den Lebenszyklus von Funktionen, Schnittstellen und Datenobjekten stärker standardisiert und Cloud-Optionen den Release-Takt beschleunigen. In ECC-Landschaften dominiert ein Muster aus seltenen Upgrades, langen Teststrecken, stabilen Eigenentwicklungen und klar abgegrenzten Wartungsfenstern.

SAP S/4HANA bringt dagegen einen Produktbetrieb näher an den Applikationskern, der kontinuierlich Änderungen verarbeitet, Abhängigkeiten zu Cloud-Services berücksichtigt und Test- sowie Freigabeprozesse als Dauerfunktion etabliert. Der Betrieb verliert damit den Charakter eines reinen Basisbetriebs und rückt in die Rolle einer Steuerungsinstanz, die Release Readiness, Integrationsstabilität und Prozessqualität dauerhaft verantwortet.

Rise with SAP als organisatorische Neuverteilung von Verantwortung

Rise with SAP verschiebt technische Betriebsleistungen in ein durch Service-Level und Rollen definiertes Liefermodell. Im Kern bündelt Rise with SAP Infrastruktur, Basisbetrieb und Teile der Plattformservices in einem Vertrag, der die Zusammenarbeit zwischen SAP, Hyperscaler und Kunde strukturiert. Der Kunde behält weiterhin die Verantwortung für Prozessdesign, Stammdatenqualität, Berechtigungskonzepte, Integrationslogik und Change-Management, nur die operative Ausführung einzelner Schichten verlagert sich.

Diese Konstruktion zwingt Organisationen, den Betrieb nicht mehr entlang der klassischen Schichten Server, Datenbank, Applikation zu strukturieren, sondern entlang von Serviceverantwortung, Messgrößen und Eskalationswegen. Gerade im Mittelstand führt das zu einer Neuordnung von Rollen, da die bisherige Basisabteilung entweder schrumpft oder sich in Richtung Service Owner, Security Owner und Integrationsbetrieb entwickelt. SAP beschreibt die Rollenverteilung für S/4HANA Cloud Private Edition in eigenen Verantwortlichkeitsmodellen und setzt damit einen Rahmen, den Kunden in Betriebsprozesse und Verträge übersetzen müssen.

Release-Zyklen als Taktgeber für Prozesse und Kontrolle

SAP S/4HANA und angrenzende Cloud-Services folgen einem Release-Mechanismus, der rechtliche Änderungen, Korrekturen und funktionale Erweiterungen in festen Lieferpaketen zusammenführt. Dieser Takt wirkt direkt auf Test, Freigabe, Transportwesen und Rollout-Governance.

In klassischen ECC-Umgebungen lässt sich ein Upgrade zeitlich und organisatorisch als Sonderereignis planen. S/4HANA verankert Änderungen im Normalbetrieb, was Regressionstests, Schnittstellentests und Berechtigungsprüfungen als Routine etabliert. Daraus folgt ein Betriebsmodell, das fachliche Kontrolle nicht mehr über seltene Großprojekte organisiert, sondern über stabile Pipeline-Prozesse und reproduzierbare Testläufe.

Clean Core grenzt Eigenentwicklung und Betrieb ein

Das Clean-Core-Konzept verändert die Logik von Anpassung und Betrieb stärker als viele technische Detailfragen. Statt tief in den Kern einzugreifen, fordert SAP Erweiterungen über definierte Extensibility-Modelle, Side-by-Side-Ansätze und klare Upgrade-Kompatibilität. Für den Betrieb bedeutet das weniger Freiheit bei schnellen Kernanpassungen, dafür mehr Disziplin im Lifecycle-Management von Erweiterungen. Custom Code rückt in eine Produktlogik, die Versionierung, API-Stabilität, Security-Reviews und Decommissioning einschließt. SAP liefert dafür technische Leitlinien für ABAP-Erweiterbarkeit im Kontext von Clean Core und ordnet Erweiterungen in Level-Konzepte ein, die unmittelbar auf Betriebsrisiken und Upgrade-Aufwand wirken.

Diese Vorgaben zwingen Unternehmen, Entwicklerteams enger mit Basisbetrieb, Security und Fachprozessverantwortung zu verzahnen. Der klassische Reflex, eine Prozesslücke kurzfristig per Modifikation zu schließen, kollidiert mit Upgrade-Fähigkeit und Cloud-Taktung. Der Betrieb gewinnt damit eine Gatekeeper-Funktion, da jede Erweiterung nicht nur funktional, sondern auch betrieblich und sicherheitstechnisch tragfähig bleiben muss. Im Mittelstand entsteht daraus ein Bedarf nach schlanken, aber verbindlichen Architektur- und Review-Gremien, da eine reine Projektsteuerung ohne technische Durchsetzungskraft die Clean-Core-Disziplin kaum hält.

Migrationspfade definieren zukünftiges Betriebsmodell

Der Weg zu S/4HANA entscheidet über mehr als Zeitplan und Budget. System Conversion, New Implementation/Greenfield und Selective Data Transition setzen jeweils andere Anforderungen an Datenqualität, Prozessharmonisierung, Testtiefe und Betriebsaufwand. Eine System Conversion hält organisatorisch vieles stabil, verschiebt aber den Aufwand in die Nachbearbeitung, da alte Prozessvarianten und Custom Code in der neuen Plattformlogik weiterlaufen.

Eine Greenfield-Implementierung zwingt zu Prozessstandardisierung, erzeugt aber hohe Anforderungen an Datenmigration, Cutover-Planung und Fachbereichsdisziplin. Selective Data Transition bringt zusätzliche Werkzeuge und Governance, da Datenextraktion, Archivlogik und Prozesskontinuität technisch sauber aufeinander abgestimmt sein müssen.

SAP selbst verankert die technische Einsatzbereitschaft über Werkzeuge, die den Umstieg deterministisch vorbereiten. Der SAP Readiness Check identifiziert relevante Punkte und technische Abhängigkeiten für Upgrades oder Konvertierungen. Der Simplification Item Check prüft die technische Eignung eines Systems für die Konvertierung und markiert Objekte, die den Umstieg blockieren. Diese Mechanismen wirken als technische Leitplanken, die den Gestaltungsspielraum reduzieren und damit indirekt das Betriebsmodell prägen.

Toolchain und Betriebsautomatisierung im SAP-Lifecycle

Ein S/4HANA-Betriebsmodell im Mittelstand steht oder fällt mit der Toolchain, da manuelle Abläufe die Release-Taktung und Integrationsdichte nicht tragen. Der Software Update Manager (SUM) bildet den Standardpfad für Wartung, Upgrades und Konvertierungen. Die Database Migration Option (DMO) koppelt Update und heterogene Datenbankmigration und unterstützt damit den Wechsel auf SAP HANA im Rahmen einer technischen Konvertierung. SAP beschreibt SUM und DMO als zentrale Werkzeuge für Systempflege und Konvertierung.

Aus Betriebssicht folgt daraus ein Paradigmenwechsel. Cutover verliert den Charakter eines seltenen Events und entwickelt sich zu einem wiederholbaren Verfahren mit vordefinierten Checks, standardisierten Rollback-Entscheidungen und objektiven Abbruchkriterien. Der Mittelstand profitiert hier, wenn Build- und Testprozesse automatisiert laufen und wenn Systemkopien, Refreshes und Schnittstellentests planbar bleiben. Ohne diese Disziplin verschiebt sich der Aufwand aus dem Projekt in den Betrieb und führt dort zu Dauerstress mit hoher Fehleranfälligkeit.

Integration als permanenter Betriebszustand

SAP S/4HANA fungiert im Mittelstand selten als isoliertes Kernsystem. Cloud-Anwendungen, E-Commerce, Manufacturing Execution System (MES), Dokumentenmanagement, Data Warehouse, Identitätsanbieter und Security-Services hängen per Schnittstellen an der ERP-Logik. Das neue Betriebsmodell muss daher Integrationsbetrieb als eigenen Service begreifen. Dazu gehören API-Governance, Versionsmanagement, Monitoring über Systemgrenzen hinweg, technische Ownership für Datenflüsse und belastbare Fehlerbehandlung.

In ECC-Umgebungen toleriert der Betrieb oft Schnittstellen, die über Jahre kaum verändert laufen. Die Cloud-Optionen von SAP S/4HANA reduzieren diese Stabilität, da Release-Zyklen auf mehreren Ebenen parallel laufen und Clean-Core-Regeln Erweiterungen stärker in externe Schichten drücken. Daraus folgt ein Integrationsbetrieb, der stärker nach Mustern des Site Reliability Engineering (SRE) arbeitet, mit messbaren Service Level Objectives (SLO), Incident-Prozessen und klarer Observability.

Security und Berechtigungskonzepte als Betriebskern

SAP S/4HANA verschiebt Risiken in Richtung Identität, Berechtigung und Protokollierung. Rollenbasierte Fiori-Apps, OData-Services und externe Integrationen erweitern die Angriffsfläche gegenüber klassischen GUI-zentrierten Nutzungsmustern. Das Betriebsmodell muss daher Identity and Access Management (IAM) enger mit Change-Management koppeln.

Jede neue App, jede neue Schnittstelle und jede neue Erweiterung bringt neue Berechtigungsobjekte, neue Kommunikationspfade und neue Audit-Anforderungen. In Cloud-Szenarien kommt hinzu, dass Schlüssel, Secrets Management und Mandantentrennung in eine geteilte Verantwortung fallen. Der Kunde behält die Verantwortung für Rollenmodell, die Prüfung der Funktionstrennung und fachliche Berechtigungsfreigaben, auch wenn Teile der technischen Plattform in ein Managed-Modell wechseln. Für den Mittelstand bedeutet dies, dass Security nicht als externer Prüfpunkt am Projektende funktioniert, sondern als Prozessbestandteil in Design, Entwicklung und Betrieb integriert bleibt.

Wirtschaftliche Effekte durch Subscription, Bündelung und Exit-Fragen

SAP S/4HANA zwingt nicht nur technisch zu neuen Betriebsmodellen, sondern auch finanziell. Rise-with-SAP-Verträge bündeln Leistungen, verschieben Investitionskosten in laufende Kosten und knüpfen Budgets an Nutzungsmetriken und Leistungsumfänge. Das ändert Controlling, Beschaffung und Vertragsmanagement. In ECC-Logik lässt sich ein großer Teil der Kosten über Infrastrukturabschreibung und interne Betriebsaufwände abbilden. In Rise-with-SAP-Logik dominiert ein Servicebudget, das an Service Level Agreement (SLA), Verfügbarkeit und inkludierte Leistungen gekoppelt ist. Daraus folgen neue Anforderungen an Vertragsprüfung, Exit-Planung und Datenportabilität, da die Bündelung den Wechselaufwand erhöhen kann.

Eine neutrale Betrachtung kommt an Vendor-Lock-in-Risiken nicht vorbei, da technische Abhängigkeiten aus Plattformdiensten, Integrationen und Erweiterungsmodellen auch ohne Absicht des Anbieters faktisch Bindung erzeugen. Veröffentlichungen aus dem SAP-Umfeld zu Souveränität betonen zugleich den Ausbau souveräner Cloud-Angebote, was in der Praxis eine Abwägung zwischen regulatorischen Anforderungen und Plattformbindung erzwingt.

Für den Mittelstand ergibt sich daraus eine harte Aufgabe. Das Betriebsmodell muss FinOps-Fähigkeiten aufbauen, um Kosten zu steuern, Kapazitäten zu planen und die eigene Verhandlungsposition über saubere Nutzungsdaten und messbare Servicequalität zu stärken. Ohne diese Fähigkeiten läuft die Subscription-Logik in eine Blackbox, in der Kosten steigen, ohne dass technische oder organisatorische Gegenmaßnahmen greifen.

Digitale Souveränität als Anforderung in Deutschland und der EU

In Deutschland und der EU entwickelt sich digitale Souveränität immer mehr zur konkreten Anforderung, gerade in regulierten Branchen und im öffentlichen Umfeld. Das betrifft Datenresidenz, Zugriffskontrolle, Schlüsselverwaltung, Support-Standorte, Auditrechte und die Abhängigkeit von außereuropäischen Rechtsräumen.

Für den Mittelstand wirkt dieses Thema indirekt. Kundenanforderungen, Lieferketten-Audits und Branchenregeln verlangen zunehmend nach belastbaren Nachweisen. Der Kriterienkatalog C5 des BSI definiert Mindestanforderungen für sichere Cloud-Nutzung und entwickelt sich mit C5:2025 weiter. Das beeinflusst die Auswahl von Betriebsmodellen und Dienstleistern, wenn Geschäftsprozesse oder personenbezogene Daten in Cloud-Plattformen laufen.

Parallel diskutiert Europa Cloud-Zertifizierung und Souveränitätskriterien. Die European Union Agency for Cybersecurity (ENISA) bietet eine Plattform für EU-Cybersicherheitszertifizierung, die Debatte um das EU Cybersecurity Certification Scheme for Cloud Services (EUCS) bleibt politisch und regulatorisch umkämpft. Für Unternehmen bedeutet das eine unsichere Planungsbasis. Anforderungen an Cloud-Souveränität sind nicht stabil ausformuliert, aber in Vergaben und Compliance-Programmen wirken diese breits.

SAP positioniert in diesem Umfeld eigene souveräne Cloud-Angebote für Europa und Deutschland. Öffentlich verfügbare Informationen verweisen auf die Delos Cloud als souveräne Plattform im deutschen Verwaltungskontext und auf Pläne, Rise-Angebote auf souveränen Azure-Varianten zu betreiben. Für den Betrieb ergibt sich daraus kein Automatismus, sondern eine Prüfpflicht. Organisationen müssen technische und organisatorische Souveränitätskriterien in Betriebsprozesse übersetzen, inklusive Schlüsselhoheit, Admin-Zugriff, Support-Prozesse, Logging, Forensik und Auditfähigkeit.

Welche Perspektive ergibt sich für den Mittelstand?

Im industriellen Mittelstand koppeln sich Fertigung, Logistik und Finance oft eng an ERP, häufig mit MES-Integration, EDI-Verkehr, Chargenrückverfolgung, Qualitätsdaten und langen Produktlebenszyklen. SAP S/4HANA verschiebt den Schwerpunkt von individuellen Anpassungen im Kern hin zu standardisierten Prozessketten plus Erweiterungen außerhalb des Kerns.

Das zwingt zu einer Neugewichtung zwischen Prozessstandard und Wettbewerbsdifferenzierung. Unternehmen, die sich bisher über Eigenentwicklung im ERP-Kern unterscheiden, müssen diese Differenzierung in BTP-nahe Erweiterungen (Business Technology Platform), Integrationslogik oder Datenprodukte verlagern. Der Betrieb muss diese Schichten als produktive Systeme behandeln, nicht als Projektartefakte, mit eigener Verfügbarkeit, eigener Überwachung und eigener Security Governance.

Im Handel und E-Commerce steigt der Druck durch Echtzeit-Bestände, Preislogik, Promotion-Mechanik und hohe Schnittstellenlast. SAP S/4HANA rückt hier in ein Betriebsmodell, das von Lastprofilen, API-Stabilität und Ereignisverarbeitung abhängt. Release-Taktung und Clean-Core-Regeln erhöhen den Bedarf an automatisierten Tests für Schnittstellen und Berechtigungen. Ohne diese Automatisierung kippt der Betrieb in eine Lage, in der jede Änderung Ausfälle triggert und in der Fachbereiche auf Schatten-IT-Lösungen ausweichen.

In regulierten Branchen spielen Nachweisführung, Audit, Zugriffskontrolle und Datenresidenz eine dominierende Rolle. Der Betrieb muss C5- oder vergleichbare Anforderungen operationalisieren, also nicht nur Dokumente pflegen, sondern Prozesse definieren, die Logging, Incident Handling, Change-Freigaben und Berechtigungs-Reviews reproduzierbar ablaufen lassen. SAP S/4HANA zwingt damit zu einem Betriebsmodell, das Compliance als laufende Funktion abbildet.

Betriebsmodelle in der Praxis

Ein tragfähiges S/4HANA-Betriebsmodell im Mittelstand verbindet fünf Leitplanken:

1. Eine Release Governance, die funktionale Änderungen, technische Wartung und Security-Pflege in einen gemeinsamen Takt bringt.
2. Eine Integrationsorganisation mit eindeutiger Ownership pro Datenfluss.
3. Ein Erweiterungsmodell nach Clean-Core-Regeln, das Kernmodifikationen praktisch ausschließt und Erweiterungen technisch versionierbar hält.
4. Ein Security-Betrieb, der Identität, Berechtigungen und Protokollierung als zentrale Betriebsdomäne führt.
5. Ein Kosten- und Vertragsmodell, das Subscription-Mechanik, SLA-Messung und Exit-Fähigkeit operationalisiert.

SAP Readiness Check und Simplification Item Check erzwingen technische Vorarbeit und reduzieren Spielraum bei problematischen Altlasten. SUM und DMO definieren den Standardpfad für Wartung und Konvertierung. Clean-Core-Guidelines definieren die Grenzen von Eigenentwicklung. Release-Zyklen drücken Änderungen in den Regelbetrieb. Souveränitätsanforderungen aus C5 und europäischen Debatten über Cloud-Zertifizierung erhöhen den Aufwand für Governance und Nachweise.