Cloud: Technische Innovation, kaufmännischer Verwandlungsdruck und digitale Souveränität

Im Zentrum dieser Epochenwende durch Cloud Computing steht der Paradigmenwechsel vom klassischen Softwarekauf hin zum abonnementsbasierten Bezug von IT-Funktionalitäten über Cloud-Infrastrukturen. Für den weltweiten Bestandskundenkreis des ERP-Weltmarktführers SAP bedeutet diese Entwicklung jedoch keineswegs nur einen technischen Generationswechsel, sondern eine kaufmännische, rechtliche und organisatorische Reorganisation.

Getrieben von den Erwartungshaltungen der internationalen Kapitalmärkte, die wiederkehrende und prognostizierbare Subskriptionserlöse verlangen, hat die SAP-Konzernspitze die Strategie des reinen Softwareverkaufs faktisch aufgegeben. Mit der Festlegung des Wartungsendes für die etablierte SAP Business Suite 7 sowie das Kernsystem SAP ERP 6.0 auf das Jahresende 2027 – flankiert von einer kostenpflichtigen, optionalen Verlängerung bis Ende 2030 – wird auf den Mittelstand wie auf Großkonzerne ein immenser Transformationsdruck ausgeübt.

Diese Zwangslage erfordert von den Verantwortlichen in den IT-Abteilungen, in den Führungsetagen sowie in den Customer Centers of Expertise (CCoE) eine nüchterne und kritische Analyse: Die Verlockungen der Cloud-Marketing-Rhetorik versprechen agilere Geschäftsprozesse, den mühelosen Zugang zu künstlicher Intelligenz sowie drastisch reduzierte Betriebskosten. Die betriebliche Realität im deutschsprachigen Raum und weltweit offenbart dagegen ein hohes Maß an Skepsis und architektonischer Ernüchterung. Ein beträchtlicher Teil der SAP-Bestandskunden sperrt sich gegen den aufgezwungenen, hastigen Gang in öffentliche Wolkenarchitekturen und sucht nach Wegen, die eigene digitale Souveränität, die ungestörte Kontrolle über geschäftskritische Kronjuwelen und den Werterhalt historisch gewachsener Prozesslogiken zu sichern, siehe Abap-Modifikationen.

Vor diesem Hintergrund wandelt sich das Thema Cloud Computing von einer rein technischen Infrastrukturentscheidung zu einer existenziellen Frage der strategischen Handlungsfreiheit. Die theoretische Differenzierung des Cloud Computing gliedert sich traditionell in die drei bekannten Servicemodelle Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS).

IaaS, PaaS und SaaS

Während IaaS lediglich die rein virtuelle Rechenleistung, Speichermedien und Netzwerkkapazitäten bereitstellt, liefert PaaS den SAP-Bestandskunden strukturierte Laufzeitumgebungen, Datenbanken und Anwendungsdienste. Das SaaS-Modell hingegen verkörpert die vollständige Entmachtung der internen IT-Infrastrukturverwaltung, indem den ERP-Anwendern die betriebsbereite Softwareanwendung inklusive aller Wartungs- und Betriebsaufgaben schlüsselfertig über das Internet zur Verfügung gestellt wird.

In der praxisnahen Realität komplexer Industrieunternehmen hat sich jedoch gezeigt, dass starre, monolithische SaaS-Ansätze den hochgradig differenzierten Anforderungen moderner Wertschöpfungsketten selten gerecht werden. Es bedarf vielmehr flexibler, hybrider Cloud-Architekturen, die lokale Rechenzentren, dedizierte Private-Cloud-Instanzen und skalierbare Hyperscaler-Kapazitäten nahtlos miteinander orchestrieren.

In diesem Gefüge nimmt der Open-Source-Spezialist Red Hat eine Schlüsselrolle für das gesamte SAP-Ökosystem ein. Während Linux seit vielen Jahren das unangefochtene Standard-Betriebssystem für das In-memory-Datenbankfundament SAP Hana bildet, hat sich das Betriebssystem Red Hat Enterprise Linux (RHEL) zum bevorzugten Backbone und Standardfundament für die internen IT-Landschaften der SAP sowie für das gesamte Kundenportfolio der SAP Enterprise Cloud Services entwickelt. Die Partnerschaft zwischen SAP und Red Hat garantiert, dass anspruchsvolle SAP-Workloads auf einer gehärteten, zertifizierten und ausfallsicheren Infrastruktur betrieben werden können, gleichgültig ob dies im eigenen lokalen Rechenzentrum oder auf den Infrastrukturen globaler Hyperscaler geschieht.

Enterprise Kubernetes

Die eigentliche architektonische IT-Befreiung des SAP-Bestandskunden von proprietären Bindungen gelingt jedoch erst durch den Einsatz der Enterprise-Kubernetes-Plattform Red Hat OpenShift. OpenShift fungiert als universaler Abstraktions- und Integrationslayer, der sich als herstellerunabhängiges Klammerkonstrukt über traditionelle On-prem-Infrastrukturen, private Hosting-Umgebungen sowie die öffentlichen Plattformen von Microsoft Azure, Amazon Web Services und Google Cloud legt. Durch diese cloudagnostische Abstraktion schützt OpenShift den Anwender vor einem schleichenden Vendor-Lock-in bezüglich des jeweiligen Cloud-Providers. ERP-Entwickler und IT-Architekten gewinnen die strategische Freiheit, Anwendungen einmalig zu konzeptionieren und sie flexibel an beliebigem Ort zu betreiben: Develop once, deploy anywhere!

Die Kombination von OpenShift mit der Red Hat Ansible Automation Platform erlaubt zudem die vollständige Ende-zu-Ende-Automatisierung von komplexen Systemlandschaften, Roll-out-Prozessen, Sicherheitsrichtlinien und täglichen IT-Betriebsaufgaben. Ein herausragendes Beispiel für die IT-Verschmelzung von Open Source und SAP-Architektur bildet die SAP Edge Integration Cell (EIC), die als moderne, containerisierte Nachfolgerin klassischer Process-Orchestration-Systeme dient.

„Wir schaffen Sicherheit in der Cloud mit KI-Agenten durch
den Aufbau einer Runtime-Umgebung mit unserem Technologiepartner Nvidia.”

Thomas Pfiester,
Head of Global Customer Engagement and Adoption,
SAP, (Keynote-Sprecher auf dem DSAG-Jahreskongress)

Die Edge Integration Cell erfordert eine ausfallsichere Kubernetes-Laufzeitumgebung und wurde offiziell für Red Hat OpenShift freigegeben, wodurch Unternehmen geschäftskritische API-Endpunkte und Datenintegrationen lokal im eigenen Werk oder in einer Private Cloud betreiben können, während gleichzeitig die Anbindung an die Business Technology Platform (SAP BTP) gewährleistet bleibt. Auch im Rahmen von Microsoft-Infrastrukturen setzt das Azure Center for SAP Solutions auf das gemeinsam entwickelte SAP Deployment Automation Framework (SDAF) auf und nutzt Red-Hat-Komponenten für die automatisierte Infrastrukturbereitstellung. Open Source und hybride Container-Plattformen erweisen sich somit als der unentbehrliche Schild zur Wahrung der digitalen Souveränität des europäischen Industriesektors in der Cloud.

Ein Blick auf das Angebotsportfolio der SAP offenbart ein differenziertes Spektrum an Betriebs- und Lizenzierungsoptionen, die sich in ihrem Funktionsumfang, ihren Konfigurationsfreiheiten und ihren kaufmännischen Verpflichtungen drastisch voneinander unterscheiden. Am traditionellen Ende dieses Spektrums steht das klassische On-prem-Modell. Hierbei erwirbt oder mietet das Anwenderunternehmen die Softwarelizenzen und betreibt das S/4-System im eigenen Rechenzentrum oder im Rahmen eines dedizierten Hostings bei einem Dienstleister. Der unschätzbare Vorteil dieser Variante liegt in der uneingeschränkten Systemkontrolle, der vollen Konfigurationsfreiheit im Backend sowie dem zeitlich ungebundenen Release- und Patchmanagement. Das Unternehmen behält die absolute Datenhoheit und ist nicht gezwungen, starren herstellerseitigen Upgrade-Zyklen zu folgen.

Der gravierende Nachteil liegt jedoch in der vollen betrieblichen Eigenverantwortung für Hardware, Datenbanksicherung, Ausfallsicherheit und das Vorhalten hochspezialisierten IT-Personals. Zudem schließt SAP die Bestandskunden mit reinen On-prem-Installationen zunehmend von innovativen Erweiterungen wie nativen KI-Szenarien oder spezifischen BTP-Funktionen aus, um den Migrationsdruck künstlich zu erhöhen.

Rise and Grow with SAP

Als primären Transformationspfad für den bestehenden Kundenstamm propagiert SAP das umfassende Komplettpaket Rise with SAP. Das Herzstück dieses Programms bildet die S/4 Hana Cloud Private Edition. Bei der Private Cloud handelt es sich technisch gesehen um ein dediziertes Single-Tenant-System, das auf der Infrastruktur der SAP oder ausgewählter Hyperscaler betrieben und als gemanagter Service bereitgestellt wird.

Im direkten Unterschied zur Public Cloud bietet die Private Edition nahezu den identischen betriebswirtschaftlichen Funktionsumfang sowie die breite Branchenabdeckung der On-prem-Version. Der Bestandskunde kann mit der Private Edition weiterhin die gewohnte SAP-GUI nutzen, tiefgreifendes Customizing durchführen und bestehende Z-Entwicklungen weiterführen, während der infrastrukturelle Basisbetrieb, das Einspielen von Sicherheitspatches und definierte technische Services in die Hände von SAP übertragen werden. Allerdings baut SAP auch innerhalb der Private Edition den Druck auf den Kunden kontinuierlich aus, das Clean-Core-Prinzip einzuhalten und kundenindividuelle Erweiterungen schrittweise auf die Business Technology Platform oder in entkoppelte Strukturen auszulagern.

Den entgegengesetzten Pol verkörpert das kommerzielle Paket Grow with SAP, das gezielt auf Neukunden, mittelständische Unternehmen mit stark standardisierten Prozessen oder abgegrenzte Tochtergesellschaften ausgerichtet ist. Fundament von Grow ist die S/4 Hana Cloud Public Edition, ein echtes mandantenfähiges Multi-Tenant-SaaS-Produkt.

In der Public Cloud teilen sich mehrere Kunden die physische Infrastruktur und die grundlegenden Softwarefunktionen, während die Daten strikt logisch getrennt bleiben. Dieses Modell verspricht kurze Implementierungszeiten, kontinuierliche funktionale Innovationen und die vollautomatische Einspielung von System-Updates direkt durch SAP. Dieser scheinbare Komfort wird jedoch durch erhebliche Einschränkungen erkauft: Ein direkter Zugriff auf den Abap-Backend-Code oder die klassische Datenbankebene ist kategorisch ausgeschlossen. Anpassungen sind ausschließlich über vordefinierte In-App-Erweiterungen oder über externe Side-by-Side-Erweiterungen auf der BTP möglich. Der SAP-Cloud-Kunde muss bereit sein, seine betrieblichen Abläufe radikal den vordefinierten Best-Practice-Prozessen der SAP unterzuordnen.

Die Migration von einer traditionellen On-prem-Landschaft in die Cloud-Welt von Rise oder Grow geht mit einer notwendigen Umgestaltung der vertraglichen und bilanziellen Rahmenbedingungen einher. In der historischen R/3- oder ECC-Welt erwarben Unternehmen unbefristete Kauflizenzen (Perpetual Licenses), die als kaufmännisches Anlagevermögen (CapEx) in der Bilanz aktiviert wurden. Hinzu kam eine jährliche Wartungsgebühr von in der Regel 22 Prozent für den technischen Support und das Recht auf Software-Updates.

Mit dem Eintritt in einen Cloud-Subskriptionsvertrag wandelt sich diese Struktur vollständig in laufende Betriebsausgaben (OpEx). Das Eigentum an der Software verbleibt beim Hersteller; der Kunde erwirbt lediglich ein zeitlich befristetes Nutzungsrecht in Form einer Miete. Zahlt das Unternehmen die monatlichen oder jährlichen Raten nicht mehr, erlischt die Zugriffsmöglichkeit auf das ERP-Cloud-System vollständig.

Cloud-Lizenzmetrik

Das zentrale Steuerungsinstrument dieser Lizenztransformation ist die Metrik des Full Use Equivalent (FUE). Anstatt wie früher eine exakte Anzahl von spezifischen Nutzerlizenztypen (wie Professional, Functional oder Productivity User) zu erwerben, abonniert das Unternehmen einen variablen Vorrat an FUE-Punkten. Die Umrechnung der verschiedenen S/4-Cloud-Nutzungstypen erfolgt über festgeschriebene Äquivalenzfaktoren: Ein FUE entspricht exakt einem S/4 for Advanced Use (vergleichbar mit dem früheren Professional User), fünf S/4 for Core Use (vergleichbar mit dem Functional User) oder dreißig S/4 for Self-Service Use.

Für den Entwicklerzugriff (Developer Access) verlangt SAP im FUE-Schlüssel im Verhältnis zwei FUE pro Entwickler. Während SAP das FUE-Modell als flexible Lösung anpreist, die eine bedarfsgerechte Verschiebung von Kapazitäten innerhalb der gebuchten Nutzerstaffeln ohne langwierige Vertragsnachverhandlungen erlaubt, warnen unabhängige Lizenzexperten vor drastischen verdeckten Preissteigerungen.

Die primäre Kostenfalle des FUE-Modells liegt in der kaufmännischen Umstellung von einer nutzungsbasierten (Did-Do) auf eine berechtigungsbasierte (Could-Do) Systemvermessung. Während in der alten ECC-Welt gemessen wurde, welche Transaktionen ein Mitarbeiter in der Praxis tatsächlich ausgeführt hat, lizenziert SAP in den S/4-Cloud-Editionen rigoros nach den im System vergebenen Berechtigungen und Rollen.

Wenn ein Mitarbeiter aufgrund unbereinigter, historisch gewachsener „Monsterrollen“ oder pauschaler Systemprofil-Zuweisungen rein theoretisch die Berechtigung besitzt, fortgeschrittene Logistik- oder Finanzfunktionen aufzurufen, wird er vom herstellerseitigen Prüfwerkzeug (dem STAR-Service bzw. S/4 Trusted Authorization Review) automatisch in die teuerste Lizenzkategorie (Advanced Use) eingestuft, selbst wenn er diese Funktionen im Arbeitsalltag niemals nutzt. Ohne eine gründliche Bereinigung der Berechtigungsstrukturen im Vorfeld einer Cloud-Vertragsumstellung drohen den Bestandskunden Kostensteigerungen von 20 bis 50 Prozent gegenüber ihren bisherigen On-prem-Wartungsgebühren.

Zusätzlich zu den FUE-Subskriptionen verschärfen verbrauchsbasierte Abrechnungsmodelle (Consumption Models) auf der Business Technology Platform und innerhalb der Business Data Cloud (SAP BDC) das kaufmännische Risiko. Über BTP Capacity Units, Cloud Credits oder verbrauchsabhängige AI Units zahlt der Kunde für die tatsächliche Inanspruchnahme von Rechenleistung, Datenvolumina oder KI-Token.

Cloud Bill Shocks

Die vertragliche Herausforderung liegt hierbei in einer Verfallslogik: Im Voraus bezahlte Kreditkontingente (wie im Rahmen eines CPEA- oder BTPEA-Vertrags) verfallen am Ende des jeweiligen Vertragsjahres ersatzlos, wenn sie mangels produktiver Anwendungsfälle nicht verbraucht wurden. Kommt es hingegen im laufenden Betrieb zu unvorhergesehenen Lastspitzen oder unkontrollierten Datenabfragen, stellt SAP den Mehrverbrauch sofort zu den signifikant höheren Listenpreisen nach, was regelmäßig zu gefürchteten Cloud Bill Shocks führt.

Flankiert wird diese strikte Monetarisierung durch das belegbasierte Lizenzmodell Digital Access sowie die im April 2026 erlassene Version vier der SAP API Policy. Mit der API Policy hat Walldorf eine digitale Zollschranke errichtet, die den direkten, unlizenzierten Massendatenabzug und den Zugriff fremder KI-Agenten auf das ERP-System reglementiert.

Wer geschäftskritische Daten ohne teure BTP-Maut zu Drittsystemen exportiert, wird mit Gebühren für indirekte Nutzung oder belegbasierte Lizenzen belastet. Europäische Anwendervereinigungen wie die DSAG und der Cloud-Verband CISPE verurteilen diese Praxis scharf als kartellrechtlich bedenklichen Versuch, einen geschlossenen Markt zu erzwingen und Anwender unerbittlich an das proprietäre BTP-Ökosystem zu ketten.

Der direkte Vergleich der drei primären Betriebsmodelle offenbart tiefgreifende strukturelle Unterschiede, die weit über reine Hosting-Fragen hinausgehen. Im Bereich der System-Governance und der betrieblichen Flexibilität erweist sich das klassische On-prem-Modell nach wie vor als Benchmark für hochkomplexe Industrieunternehmen: Der Anwender behält die uneingeschränkte Hoheit über den Zeitpunkt von System-Upgrades, Feature-Packs und Datenbank-Patches. Es existieren keinerlei vordefinierte Zwangswartungsfenster und kundenindividuelle Entwicklungen im Abap-Namensraum können ohne Einschränkungen betrieben werden. Allerdings muss das Unternehmen sämtliche Aufwände für Hardware-Sizing, Betriebssystem-Betreuung, Datenbankverwaltung sowie die Einhaltung komplexer Compliance- und IT-Sicherheitsstandards in Eigenregie oder über separate Dienstleisterverträge organisieren.

Die S/4 Cloud Private Edition (im Rahmen von Rise with SAP) versucht, die funktionale Vollständigkeit des On-prem-Systems mit dem Komfort einer verwalteten Cloud-Umgebung zu verbinden. Aus technischer Sicht handelt es sich um eine isolierte Single-Tenant-Instanz, bei der das Hosting an SAP übergeht, aber der Bestandskunde weitgehende Mitbestimmungsrechte bezüglich des spezifischen Hyperscalers (Azure, AWS, Google Cloud oder europäische Anbieter) und des konkreten geografischen Rechenzentrumssitzes behält.

Private Cloud vs. On-prem

Der Funktionsumfang der Cloud Private Edition umfasst alle 31 Branchenlösungen und 39 Sprachversionen der On-prem-Welt. Zwar genießt der SAP-Bestandskunde eine deutlich flexiblere Upgrade-Strategie als in der Public Cloud und kann Systemaktualisierungen innerhalb des Mainstream-Wartungsfensters zeitlich schieben, jedoch ist er an die infrastrukturellen Vorgaben der SAP gebunden. Die Dimensionierung des Hana-Datenbankspeichers und der Applikationsserver ist direkt an die gebuchte FUE-Menge gekoppelt, Benötigt ein System aufgrund komplexer In-memory-Analysen zusätzlichen Arbeitsspeicher ohne Anstieg der Nutzerzahlen, müssen teure Infrastruktur-Add-ons nachlizenziert werden.

Demgegenüber stellt die S/4 Cloud Public Edition (im Rahmen von Grow with SAP) das radikalste Cloud-Konzept dar. Als echtes Multi-Tenant-SaaS-Modell bietet es die geringsten spezifischen Betriebskosten für die IT-Basis, da Softwareaktualisierungen, Sicherheitspatches und Infrastrukturskalierungen vollautomatisch durch SAP im Hintergrund abgewickelt werden. Der funktionale Kern wächst automatisch mit den halbjährlichen SAP-Releases.

Abap-Modifikationen

Allerdings erfordert die Public Cloud eine absolute Unterwerfung unter das Clean-Core-Diktat. Klassische Z-Entwicklungen, Modifikationen von SAP-Standardobjekten oder direkte Schreibzugriffe auf Datenbanktabellen sind technisch unmöglich. Unternehmen mit spezialisierten Fertigungsprozessen, gewachsenen Sonderabwicklungen oder komplexen Drittsystem-Integrationen stoßen in der Public Edition schnell an unüberwindbare Barrieren. Dies erklärt, warum laut den Investitionsreporten der DSAG eine überwältigende Mehrheit der etablierten Bestandskunden in der DACH-Region die Public Cloud für ihren zentralen ERP-Kern nach wie vor ablehnt und sich stattdessen für On-prem- oder kontrollierte Private-Cloud-Szenarien entscheidet.

In der strategischen Kommunikation der SAP-Konzernführung hat sich ein bemerkenswerter Wandel vollzogen: Auf den internationalen Kundenkonferenz Sapphire 2026 Orlando wurde die jahrelang gepriesene North-Star-Architektur der klassischen SAP Business Suite 7 schleichend beerdigt. An ihre Stelle trat das spektakuläre Zielbild des SAP Autonomous Enterprise. Aus dieser neuen, KI-zentrierten Perspektive erweist sich S/4 Hana keineswegs als der finale Endpunkt der ERP-Evolution, sondern lediglich als das notwendige, transaktionale Datenfundament und als eine hinlänglich notwendige Durchgangsstation. Der klassische ERP-Kern wird zu einem reinen „System of Record“ degradiert, das im Hintergrund als verlässlicher Buchungsserver agiert, während die eigentliche Prozessabwicklung und die Interaktion mit dem Anwender auf übergelagerte Intelligenzschichten verlagert werden.

Das operative Gesicht dieser neuen Ära bildet die Benutzeroberfläche Joule Work in Kombination mit der SAP Autonomous Suite. Anstatt dass Mitarbeiter Hunderte von Fiori-Kacheln aufrufen oder komplexe Transaktionscodes eingeben, beschreiben sie ihre geschäftlichen Intentionen in natürlicher Sprache. Im Hintergrund orchestrieren über 50 domänenspezifische Joule-Assistenten und mehr als 200 spezialisierte KI-Agenten autonome End-to-End-Prozesse in den Bereichen Finanzen, Beschaffung, Lieferkette und Personalwesen. Ein autonomer Assistent wie der „Autonomous Close Assistant“ übernimmt dabei die eigenständige Analyse von Abweichungen, die Abstimmung von Konten und die Vorbereitung des Monatsabschlusses, während der Mensch im Sinne eines „Human in the Loop“ nur noch bei unlösbaren Ausnahmesituationen eingreift.

Um diesen KI-Agenten das Verständnis für das komplexe, aus über sieben Millionen Datenfeldern und Zehntausenden Tabellen bestehende historische Datenmodell (SQL-Server-basiert) der SAP zu ermöglichen, dient der SAP Knowledge Graph als unentbehrliches semantisches Gehirn. Der Knowledge Graph übersetzt relationale Datenbanktabellen automatisch in maschinenlesbare Ontologien und ein Netzmodell aus Knoten und Kanten. Er liefert den Sprachmodellen und KI-Agenten den exakten betriebswirtschaftlichen Kontext – etwa was die Beziehungsgeflechte zwischen Kundenaufträgen, Materialstammdaten, Rechnungen und Lieferabrufen bedeuten –, um stochastische Halluzinationen im geschäftskritischen Hauptbuch wirksam zu unterdrücken.

SAP Knowledge Graph

Die Behauptung, dass KI-Agenten und der SAP Knowledge Graph ein klassisches ERP-System künftig vollständig überflüssig machen könnten, hält einer analytischen Prüfung jedoch nicht stand: Ein ERP-System bleibt unersetzbar, weil betriebswirtschaftliche Kernfunktionen wie die Finanzbuchhaltung, die Steuer-Compliance, die Kostenrechnung und die rechtssichere Bilanzierung nach absoluter, deterministischer Exaktheit verlangen.

Sprachmodelle basieren auf probabilistischen Wahrscheinlichkeitsberechnungen; informationstheoretische Grundgesetze belegen, dass eine stochastische KI niemals eine hundertprozentige Fehlerfreiheit garantieren kann. Wenn ein probabilistischer KI-Agent ohne die regelbasierte Logik eines deterministischen ERP-Kerns agieren würde, führten bereits geringste Abweichungen zu rechtlich unzulässigen Buchungen oder fehlerhaften Produktionsfreigaben. S/4 Hana und das Cloud-ERP bleiben somit das unverzichtbare mathematische Fundament, auf dem die kognitive Autonomie der KI-Agenten als Steuerungsschicht aufsetzt.

Die langfristige Perspektive des Cloud Computing im SAP-Umfeld wird zunehmend von Fragen der geopolitischen Resilienz, der Rechtssicherheit und der Vermeidung einer irreversiblen Herstellerabhängigkeit dominiert. Während SAP ihre Bestandskunden mit enormem Druck in proprietäre Cloud-Strukturen drängt, fehlt in den offiziellen Vertragswerken nach wie vor eine technisch und kaufmännisch durchführbare Cloud-Exit-Strategie.

Cloud- und KI-Exit

Wer seine bestehenden On-prem-Kauflizenzen im Rahmen einer Contract Conversion einmal in Cloud-Subskriptionen umgewandelt hat, vernichtet sein historisches Anlagevermögen unwiederbringlich. Ein Ausstieg aus der SAP-Cloud lässt den Kunden mit nackten, ohne die proprietären Cloud-Algorithmen und Laufzeitumgebungen wertlosen Rohdaten zurück.

Noch dramatischer präsentiert sich das Fehlen einer KI-Exit-Strategie: Da SAP im Bereich kognitiver Basismodelle keine eigene Kernkompetenz besitzt und sich primär auf US-Pioniere wie Anthropic (mit dem Modell Claude) stützt, werden europäische Anwender extrem verwundbar gegenüber geopolitischen Entscheidungen ausländischer Regierungen.

In dieser heiklen Konstellation bietet der rechtliche Rahmen der Europäischen Union – namentlich der am 22. Dezember 2023 im Amtsblatt veröffentlichte EU Data Act – einen wichtigen Hoffnungsschimmer für die Wiedererlangung der digitalen Souveränität. Der EU Data Act soll den Wechsel zwischen verschiedenen Cloud-Anbietern erleichtern und künstliche Wechselbarrieren, überhöhte Datenübertragungsgebühren sowie vertragliche Knebelklauseln gesetzlich unterbinden.

Auch wenn die konkreten EU-Musterverträge und technischen Durchführungsbestimmungen für komplexe ERP-Landschaften noch in der Ausarbeitung begriffen sind, verpflichtet die europäische Gesetzgebung Anbieter wie SAP zunehmend zur Bereitstellung offener Schnittstellen und standardisierter Datenportabilitätsmechanismen. Flankiert wird diese regulatorische Entwicklung durch die Initiativen europäischer Infrastrukturanbieter wie StackIT (dem europäischen Hyperscaler der Schwarz-Gruppe), die Rise-Workloads auf Basis europäischen Rechts und ohne das Risiko des US Cloud Act bereitstellen.

Für die praktische Formulierung einer zukunftssicheren Cloud-Exit- und Entkopplungsstrategie müssen Anwenderunternehmen auf moderne, herstellerunabhängige Architekturstandards setzen: Anstatt kundenindividuelle Algorithmen starr in der proprietären BTP zu programmieren oder sich exklusiv an den SAP Knowledge Graph zu ketten, etabliert sich der Aufbau eines herstellerunabhängigen „Enterprise Semantic Backbone“.

Über quelloffene W3C-Standardformate wie das Resource Description Framework (RDF) und die Abfragesprache SPARQL können Unternehmen ihre geschäftsspezifischen Ontologien und Datenbeziehungen auf souveränen Open-Source-Plattformen (wie Suse Rancher, Suse AI oder Red Hat OpenShift) selbstständig modellieren.

Eine absolute Schlüsselrolle für den entkoppelten Betrieb von KI-Agenten nimmt zudem das herstellerunabhängige Model Context Protocol (MCP) ein. Als offener Standard – vergleichbar mit einem universellen USB-C-Anschluss für KI-Systeme – stellt das MCP eine saubere Trennung zwischen den Sprachmodellen und dem transaktionalen ERP-Kern her. Über entkoppelte MCP-Server (wie sie von Anbietern wie Boomi, Suse oder Open-Source-Communitys bereitgestellt werden) können KI-Agenten sicher, kontrolliert und lückenlos auditierbar auf S/4-Daten zugreifen, ohne dass der SAP-Bestandskunde in die unkalkulierbare Lizenzfalle der SAP API Policy gerät.

Für das Customer Center of Expertise (CCoE) und die IT-Führung eines SAP-Bestandskunden lautet das Fazit dieser Analyse: „Nutzen Sie die technischen Vorteile der Cloud und der künstlichen Intelligenz dort, wo sie echten betriebswirtschaftlichen Mehrwert stiften. Bewahren Sie jedoch gleichzeitig die strikte Kontrolle über Ihre Systemarchitektur. Indem Sie Ihren Kern konsequent mit SAP Clean Core bereinigen, Ihre Lizenzen vor jeder Vertragsunterzeichnung berechtigungsseitig optimieren, auf quelloffene Hybrid-Cloud-Fundamente wie Red Hat setzen und Ihre Datenstrukturen über offene Standards wie MCP und RDF entkoppeln, sichern Sie sich eine zukunftsfähige, agile und digital souveräne ERP-Zukunft auf Augenhöhe mit dem Hersteller.“