Die Wahl des Betriebsmodells für SAP S/4HANA ist eine strategische Entscheidung mit langfristigen Auswirkungen auf Flexibilität, Kostenstruktur, Innovationsfähigkeit und organisatorische Komplexität. Dieser Artikel analysiert die drei zentralen Modelle – On-Premise, Private Cloud und Public Cloud – entlang ihrer technischen Architektur, ihres Betriebsmodells sowie ihrer strukturellen Vor- und Nachteile. Ziel ist eine kritische, realitätsnahe Einordnung ohne vereinfachende Narrative.
Grundlogik der drei Modelle
On-Premise-Systeme basieren auf vollständiger Kontrolle über Infrastruktur und Applikation. Private Cloud verlagert diese Systeme in externe Infrastruktur, ohne ihre technische Logik grundlegend zu verändern. Public Cloud hingegen folgt einem SaaS-Modell mit standardisierter Codebasis und zentral gesteuertem Betrieb.
SAP beschreibt die Public Cloud explizit als „standardized, multi-tenant architecture“. Diese Aussage ist zentral, da sie impliziert, dass individuelle Anpassungen systematisch eingeschränkt werden müssen, um Konsistenz und Skalierbarkeit zu gewährleisten.
Implikation: Standardisierung ist kein optionaler Vorteil, sondern eine zwingende Voraussetzung des Architekturmodells.
Die drei Modelle folgen damit drei unterschiedlichen Grundlogiken:
- On-Premise optimiert maximale Kontrolle und individuelle Anpassbarkeit.
- Private Cloud optimiert die Verlagerung von Infrastruktur, ohne die Anwendungslogik wesentlich zu verändern.
- Public Cloud optimiert Standardisierung, Upgradefähigkeit und Skalierbarkeit auf Kosten technischer Freiheitsgrade.
I. On-Premise - maximale Kontrolle und ihre Konsequenzen
On-Premise ermöglicht vollständige Kontrolle über System, Daten und Prozesse. Unternehmen können tief in die Systemlogik eingreifen, eigene Tabellenstrukturen definieren und individuelle Geschäftslogiken implementieren.
Zu den wesentlichen Freiheitsgraden gehören insbesondere:
- uneingeschränkter Zugriff auf das Customizing
- eigene ABAP-Entwicklungen ohne architektonische Restriktionen
- direkte Eingriffe in Datenbank- und Prozesslogik
- individuelle Release- und Wartungsplanung
Diese Freiheit führt jedoch zu strukturellen Herausforderungen. SAP weist darauf hin: „Modifications can make systems difficult to upgrade and maintain“.
Diese Aussage beschreibt einen fundamentalen Zielkonflikt: Anpassbarkeit erhöht kurzfristig die Passgenauigkeit, erschwert jedoch langfristig Wartung und Weiterentwicklung.
Typische Konsequenzen sind:
- zunehmende technische Verschuldung durch Eigenentwicklungen
- steigende Abhängigkeit von implizitem Wissen einzelner Mitarbeitender
- hoher Testaufwand bei Releasewechseln
- wachsende Komplexität durch enge Kopplungen und Sonderlogik
Implikation: On-Premise maximiert Flexibilität, erzeugt jedoch langfristig strukturelle Trägheit.
Gerade in historisch gewachsenen SAP-Landschaften zeigt sich, dass On-Premise nicht an einzelnen technischen Schwächen leidet, sondern an kumulierter Komplexität. Was in einzelnen Projekten jeweils als pragmatische Anpassung erschien, wird über Jahre hinweg zu einer schwer steuerbaren Gesamtarchitektur.
II. Private Cloud – Infrastrukturmodernisierung ohne Systemtransformation
Private Cloud wird häufig als Transformationsschritt interpretiert, stellt jedoch primär eine Verlagerung des Betriebsmodells dar. Technisch bleibt das System unverändert.
SAP beschreibt dieses Modell als „single-tenant environment“, in dem jedes Unternehmen weiterhin eine eigene Systeminstanz betreibt.
Zusätzlich gilt: „Upgrades are planned and executed by the customer“. Diese Aussage verdeutlicht, dass sich die Innovationslogik nicht verändert.
Im operativen Zielbild verlagern sich typischerweise folgende Elemente zum Provider:
- Rechenzentrumsbetrieb
- Hardware- und Infrastrukturverantwortung
- Teile des Basisbetriebs, etwa Monitoring oder Patching auf Infrastruktur-Ebene
- Skalierungs- und Verfügbarkeitsleistungen im Rahmen definierter SLAs
Gleichzeitig verbleiben beim Unternehmen weiterhin zentrale Aufgaben:
- Customizing und kundenspezifische Entwicklung
- Release- und Testmanagement
- fachliche Fehleranalyse
- Steuerung individueller Integrationen
Die Verantwortung verschiebt sich also teilweise vom Unternehmen zum Provider, insbesondere im Bereich Infrastruktur und Basisbetrieb.
Gleichzeitig bleiben zentrale Herausforderungen bestehen: Custom Code, individuelle Prozesslogik und Upgrade-Komplexität.
Ein häufiges Problem ist die sogenannte Lift-and-Shift-Migration, bei der bestehende Systeme unverändert übernommen werden.
Typische Folgen sind:
- keine Reduktion funktionaler oder technischer Komplexität
- Fortbestand bestehender Altlasten
- höhere Kosten durch Kombination aus Hosting, Betrieb und unverändertem Individualisierungsgrad
- falsche Erwartung eines Innovationssprungs, der faktisch nicht eintritt
Implikation: Private Cloud reduziert Infrastrukturaufwand, verändert jedoch nicht die strukturellen Eigenschaften des Systems.
Private Cloud ist daher oft weniger ein Zielbild als eine Übergangsarchitektur. Sie kann sinnvoll sein, wenn ein Unternehmen kurzfristig Rechenzentrumsrisiken reduzieren oder veraltete Infrastruktur ablösen muss. Sie ist aber keine automatische Antwort auf die Frage nach Vereinfachung, Standardisierung oder höherer Innovationsgeschwindigkeit.
III. Public Cloud - Standardisierung als Architekturprinzip
Die Public Cloud unterscheidet sich grundlegend durch ihre restriktive Architektur. SAP formuliert klar: „No modifications of SAP standard objects are allowed“.
Diese Einschränkung ist kein Nachteil im klassischen Sinne, sondern ein bewusstes Designprinzip zur Sicherstellung von Stabilität und Upgradefähigkeit.
Implikation: Anpassbarkeit wird zugunsten von Standardisierung bewusst reduziert.
Damit verschiebt sich auch die Rolle des ERP-Systems selbst. In der Public Cloud ist der Core nicht mehr der Ort für nahezu beliebige Individualisierung, sondern primär für:
- standardisierte End-to-End-Prozesse
- konsistente Stammdaten- und Transaktionslogik
- regelmäßige Innovationsübernahme über Releases
- eine kontrollierte, vom Anbieter definierte Erweiterungsarchitektur
Gesamtbewertung der Modelle
Die drei Modelle unterscheiden sich nicht nur graduell, sondern konzeptionell. Ihre jeweiligen Stärken und Risiken lassen sich wie folgt verdichten:
- On-Premise bietet maximale Kontrolle und Anpassbarkeit, führt jedoch zu wachsender technischer und organisatorischer Komplexität.
- Private Cloud reduziert infrastrukturelle Verantwortung, ohne die strukturellen Eigenschaften des Systems zu verändern.
- Public Cloud erzwingt Standardisierung und ermöglicht kontinuierliche Innovation, verlagert jedoch Komplexität in Integrationsarchitekturen und Governance.
Eine seriöse Bewertung darf daher nicht mit Schlagworten wie „modern“, „alt“, „innovativ“ oder „flexibel“ beginnen, sondern muss die zentrale Frage beantworten, an welcher Stelle ein Unternehmen bewusst Komplexität tragen will: im Core-System, im Betriebsmodell oder in der Integrationsarchitektur.
Fazit
Keines der Modelle ist per se überlegen. Die Entscheidung hängt von der strategischen Ausrichtung des Unternehmens ab.
Die zentrale Frage lautet, in welchen Bereichen Differenzierung notwendig ist und wo Standardisierung Vorteile bringt.
On-Premise ist kein veraltetes Modell, sondern ein hochflexibles System mit strukturellen Kosten. Private Cloud ist kein Zielbild, sondern häufig ein Übergang.
Public Cloud ist kein vereinfachtes On-Premise-Modell, sondern ein bewusst restriktives Architekturmodell.
Aus Management- und IT-Sicht ergeben sich daraus unterschiedliche, aber miteinander verknüpfte Entscheidungsfragen:
- Welche Prozesse schaffen tatsächlich Wettbewerbsvorteile und rechtfertigen Individualisierung?
- Welche Teile der heutigen Systemlandschaft sind historisch gewachsen, aber strategisch nicht mehr relevant?
- Ist das Unternehmen organisatorisch in der Lage, ein standardisiertes Cloud-Betriebsmodell zu akzeptieren?
- Verfügt die IT über die Kompetenzen, verteilte Integrations- und Erweiterungsarchitekturen nachhaltig zu steuern?
Erst wenn diese Fragen sauber beantwortet sind, lässt sich das passende Deployment-Modell wählen. Die eigentliche Herausforderung liegt nicht in der Technologie allein, sondern in der Fähigkeit des Unternehmens, die Konsequenzen des gewählten Modells dauerhaft organisatorisch, prozessual und architektonisch zu tragen.
