Money Makes the World Go Round

Die digitale Transformation der betriebswirtschaftlichen Kernprozesse wird vom Walldorfer Softwarekonzern SAP unermüdlich als grenzenloses, agiles und cloudbasiertes ERP-Paradies gefeiert, doch bei kritischer Analyse der vertraglichen Realitäten entpuppt sich dieses Versprechen als ein hochkomplexes strategisches Zwangskorsett, das die SAP-Bestandskunden in einen beispiellosen Vendor-Lock-in treibt.

Im Zentrum dieser tektonischen Verschiebung steht der Paradigmenwechsel vom klassischen, eigentumsbasierten On-prem-Modell hin zu einem Cloud-Subskriptionsmodell, flankiert von einer undurchsichtigen Preis- und Konditionenliste (PKL), neuen API-Restriktionen und der rigorosen Monetarisierung von Datenströmen.

Für den SAP-Bestandskunden bedeutet der Wechsel auf S/4 Hana längst nicht mehr ein technisches Release-Upgrade, sondern eine fundamentale Neuausrichtung seiner kommerziellen IT-Architektur, bei der die Gefahr von Kostenexplosionen, Überlizenzierungen und dem totalen Verlust der digitalen Souveränität ständiger Begleiter ist. Wer die Mechanismen der SAP-Cloud-Subscription, der Business Technology Platform (SAP BTP), der Business Data Cloud (SAP BDC) und der neuen Lizenzmetriken nicht bis ins kleinste Detail dekonstruiert, wird unweigerlich Opfer einer meisterhaft orchestrierten Monetarisierungsmaschine.

Der historische Übergang in die Cloud-Welt von SAP, primär vorangetrieben durch die allumfassenden Vertragspakete Rise und Grow, markiert für den ERP-Anwender den komplexen Wechsel von einer Investitionsausgabe (Capex) zu laufenden Betriebs­ausgaben (Opex). Während On-prem-Lizenzen als unbefristetes Eigentum erworben wurden und selbst bei einer Kündigung der Wartungsverträge das fortlaufende, rechtmäßige Nutzungsrecht am System garantierten, degradiert das Cloud-Abonnement den Kunden zum wehrlosen Mieter.

SAP wandelt existierende On-prem-Lizenzen über die sogenannte Contract Conversion in Cloud-Subskriptionen um, was zur unwiederbringlichen Vernichtung der alten, wertvollen Kauflizenzen führt. Das zentrale Instrument dieser Transformation ist die Metrik des Full Use Equivalent (FUE), ein hochkomplexes Regelwerk, das die bisherige detaillierte nutzungsbasierte User-­Vergabe aus der ECC-Welt in standardisierte Cloud-Nutzungstypen presst.

Ein FUE dient dabei als Verrechnungseinheit, die mit unterschiedlichen Gewichtungsfaktoren auf Nutzertypen wie Developer Access, Advanced Use, Core Use oder Self-Service Use aufgeteilt wird. Die kritische Herausforderung für den SAP-Bestandskunden liegt hierbei in der Bemessungsgrundlage: In der neuen S/4-Cloud-Welt lizenziert SAP nicht mehr primär nach der tatsächlichen Nutzung der Software, sondern rigoros nach den im System vergebenen Berechtigungen.

Berechtigungsbasierte Vermessung

Da in den gewachsenen SAP-Landschaften R/3, R/3 Enterprise und ERP/ECC 6.0 (SAP Business Suite) die Berechtigungen oftmals ex­trem großzügig vergeben wurden, führt diese berechtigungsbasierte Vermessung bei einer unvorbereiteten Migration zu einer massiven Überlizenzierung.

Unabhängige Lizenzexperten warnen, dass die neue Cloud-Metrik die Lizenzkosten um alarmierende 50 bis 150 Prozent in die Höhe treiben kann, da selbst für Gelegenheitsnutzer plötzlich teure Professional- oder Advanced-Lizenzen fällig werden, sobald ihnen systemseitig weitreichende Rollen zugeordnet sind.

SAP versucht, die Kunden mit dem sogenannten S/4 Trusted Authorization Review (Star-Service) bei der Klassifizierung zu unterstützen, doch dieses Werkzeug analysiert stumpf die Berechtigungsobjekte und weist unklaren Fällen automatisch den teuersten Lizenztyp zu, was als brandgefährliche Kostenfalle für ahnungslose Anwender gilt.

Die vertragliche Grundlage für diese wolkigen Konstrukte bildet die SAP-Preis- und Konditionenliste, die sich im Cloud-Zeitalter zu einem wahren juristischen Laby­rinth ausgewachsen hat. Die PKL besteht nicht mehr nur aus einer simplen Excel-Preisliste und einem Masterdokument, sondern fragmentiert sich in ein unüberschaubares Geflecht aus Cloud Supplements, Service Description Guides, Cloud AGBs und Service Level Agreements (SLAs), die allesamt untrennbare Bestandteile der sogenannten Order Form werden.

Toxische Cloud Supplements

Die Cloud Supplements regeln detailliert die Nutzungsbeschränkungen, Metriken und Provisionierungsdetails für jeden einzelnen Cloud-Service. Das toxische Element ist, dass SAP diese Dokumente und Metriken quartalsweise ändert und anpasst, was eine verlässliche und langfristige Budgetierung für den CFO unmöglich macht. Für den SAP-Bestandskunden bedeutet dies, dass er bei jedem Vertragsabschluss oder bei jeder Verlängerung – dem sogenannten Renewal – gezwungen ist, die tagesaktuellen Supplements rechtssicher zu archivieren, da SAP sich das Recht vorbehält, bei Laufzeitverlängerungen einseitige Preisanpassungen durchzuführen oder ehemals inkludierte Funktionen plötzlich separat zu bepreisen.

Noch drastischer offenbaren sich die kommerziellen Risiken bei der Business Technology Platform, die von SAP als das technische Rückgrat und die essenzielle Innovationsschicht der Clean-Core-Strategie propagiert wird. Auf der BTP sollen künftig alle kundenindividuellen Erweiterungen (Side-by-Side Extensibility) und Integrationen stattfinden, um den digitalen Kern von S/4 Hana sauber und upgradefähig zu halten.

BTPEA und Cloud Bill Shock

Die Lizenzierung der BTP-Services erfolgt primär über verbrauchsbasierte Consump­tion-Modelle, namentlich das Cloud Platform Enterprise Agreement (CPEA) oder das neuere BTP Enterprise Agreement (BTPEA), bei denen der Kunde vorab sogenannte Cloud Credits einkauft. Die kaufmännische Falle dieser Modelle liegt im drohenden Verfall der erworbenen Credits: Ungenutzte Cloud Credits verfallen ausnahmslos am Ende eines jeden Vertragsjahres, wodurch ein ex­tremer Druck entsteht, die Services auch tatsächlich zu konsumieren, um keine sogenannte Shelfware zu finanzieren.

Gleichzeitig lauert bei einer intensiven Nutzung der gefürchtete Cloud Bill Shock. Sobald das vorab gekaufte Kontingent an Cloud Credits erschöpft ist, rechnet SAP jede weitere Übernutzung gnadenlos und unrabattiert zum Listenpreis ab. Alternativ bietet SAP ein Pay-As-You-Go-Modell an, das zwar keine Mindestabnahmemenge erfordert, bei dem die Servicegebühren jedoch nicht rabattfähig sind und das somit bei skalierendem Einsatz die teuerste aller Betriebsformen darstellt.

Das Management und Monitoring dieser BTP-Verbräuche über das SAP-for-Me-Portal oder das BTP Cockpit wird von Anwendervereinen wie der DSAG als hochgradig unzureichend und intransparent kritisiert, da granulare Kostenauswertungen auf Ebene einzelner Geschäftsprozesse oftmals fehlen. Ein ähnlich restriktives Bild zeigt sich bei der SAP Integration Suite, dem cloudbasierten Nachfolger der klassischen Middleware SAP PI/PO aus dem NetWeaver-Stack. Die Lizenzierung dieses essenziellen Integrationswerkzeugs, das für die Verbindung von SAP- und Non-SAP-Systemen unabdingbar ist, basiert häufig auf Metriken wie Tenants und Paketen von jeweils 10.000 Messages.

Die betriebswirtschaftliche Herausforderung für den SAP-Bestandskunden liegt in der Vorhersagbarkeit des Nachrichtenaufkommens. In modernen, ereignisgesteuerten (Event-driven) ERP-Landschaften und IoT-Szenarien explodiert die Anzahl der zu verarbeitenden Systemnachrichten oft unkontrolliert. Da die Integration Suite zentral über die BTP provisioniert wird, ist eine interne Leistungsverrechnung auf spezifische Fachbereiche kaum möglich, während plötzliche Lastspitzen das Cloud-Credit-Guthaben rapide aufzehren und unkalkulierbare Mehrkosten verursachen.

Der Gipfel der SAP’schen Monetarisierungsstrategie offenbart sich jedoch in der neuen Business Data Cloud (SAP BDC) und der SAP Datasphere. Die BDC wird vom SAP-Marketing vollmundig als offenes, harmonisiertes Datenfundament (Data Fabric) gepriesen, das historische SAP-Datensilos aufbrechen und mit Hyperscaler-Diensten wie Databricks oder Snowflake föderieren soll. Liest man jedoch das Kleingedruckte der Verträge und Service Description Guides, entpuppt sich die BDC als ein System restriktiver Daumenschrauben, das die DSAG treffend als „Business Data Complexity“ verspottet. SAP limitiert die Datennutzung extrem scharf. Bei jeder Überschreitung der minimalen Grenzen behält sich SAP vor, mit zusätzlichen und empfindlichen Gebühren zu bestrafen. Diese harten technischen und kommerziellen Barrieren konterkarieren das Versprechen einer offenen Datenkultur vollständig und sie zwingen Unternehmen, ihre Datenanalysen exakt nach den teuren Volumenvorgaben zu drosseln.

SAP API Policy

Eskaliert wird diese Abschottungstaktik durch die im April 2026 von SAP veröffentlichte, stark umstrittene neue API Policy. Unter dem Vorwand von Sicherheitsbedenken und Systemstabilität reglementiert SAP nun präzise, unter welchen Bedingungen Bestandskunden ihre eigenen Daten in Drittsysteme übertragen dürfen.

Die API-Richtlinie verbietet explizit die Nutzung von SAP-APIs für nicht ausdrücklich dokumentierte Zwecke und untersagt systematische Massendatenextraktionen in externe Data Warehouses oder Data
Lakes, sofern SAP diesen spezifischen Anwendungsfall in der Produktdokumentation nicht explizit erlaubt hat.

Für den SAP-Bestandskunden ist dies ein fataler Schlag gegen die eigene digitale Souveränität. Wer künftig seine historischen S/4-Daten effizient abziehen möchte, um sie mit KI-Tools von Drittanbietern oder auf Plattformen wie Microsoft Fabric zu analysieren, wird durch die Blockade performanter Schnittstellen (wie ODP) de facto in die hauseigenen, teuren Lösungen wie SAP Datasphere und SAP BDC gezwungen.

Besonders brisant ist das Verbot für autonome und generative KI-Agenten von Drittanbietern: KI-Systeme dürfen nicht mehr frei und eigenständig auf SAP-Daten über APIs zugreifen. SAP errichtet hier faktisch eine digitale Zollschranke, an der jeder externe Zugriff, der die Walldorfer Datenhoheit berührt, künftig reglementiert und mit an Sicherheit grenzender Wahrscheinlichkeit monetarisiert wird, um den eigenen, oftmals technisch hinterherhinkenden KI-Assistenten wie Joule einen künstlichen Wettbewerbsvorteil zu sichern.

Die API-Restriktionen verschmelzen nahtlos mit einem der gefährlichsten Lizenzthemen der SAP-Geschichte: der indirekten Nutzung und dem Preismodell Digital Access. In der Ära von Industrie 4.0, Robotics Process Automation (RPA) und vernetzten Lieferketten greifen unzählige Fremdsysteme automatisiert auf das ERP-System zu. SAP hat mit Digital Access ein ergebnisorientiertes (Outcome-based) Lizenzmodell geschaffen, das nicht mehr den menschlichen Nutzer zählt, sondern die schiere Anzahl der in Nicht-SAP-Quellen initial erstellten und in den SAP-Kern importierten Dokumente. Die Listenpreise für dieses Dokumentenvolumen sind astronomisch hoch angesetzt, weshalb SAP die Kunden mit Rabattprogrammen (Digital Access Adoption Program, DAAP) von bis zu 90 Prozent in das neue Modell locken muss.

Doch diese Rabatte sind eine vertragliche Illusion: Hat sich ein Unternehmen einmal für Digital Access entschieden, gibt es keinen Weg mehr zurück in die alte, potenziell kostengünstigere userbasierte Welt. Die Beweislast für die korrekte Zählung der Dokumente, etwa die Unterscheidung zwischen lizenzpflichtiger Neuanlage und lizenzfreiem Lesen (Indirect Static Read), wird durch unzulängliche Vermessungstools wie das SAP Passport-Tool oftmals vollständig auf den Kunden abgewälzt. Jeder externe KI-Agent oder IoT-Sensor, der künftig autonom Bestellungen in S/4 Hana anlegt, wird die Zählerstände bei Digital Access in die Höhe schnellen lassen und ohne strenge Governance zu Nachforderungen führen.

Cloud-Exit-Strategie

Die ultimative Gefahr im SAP-Cloud-Subskriptionsmodell offenbart sich jedoch an dessen Ende: Es gibt schlichtweg keine native, vertraglich zugesicherte Cloud-Exit-Strategie seitens der SAP. Die All-in-Cloud-Verträge unter Rise with SAP fungieren als mathematische Trapdoor-Funktion – eine strategische Einwegstraße. Da der Kunde bei der Contract Conversion seine unbefristeten On-prem-Lizenzen unwiederbringlich aufgeben musste, steht er am Ende der Cloud-Vertragslaufzeit mit leeren Händen da. Wenn ein Anwenderunternehmen die teuren Subskriptionsgebühren nicht mehr bezahlen kann oder will, erlischt das Zugriffsrecht auf die Software augenblicklich.

Diese Asymmetrie versetzt SAP bei jeder anstehenden Vertragsverlängerung (Re­new­al) in eine absolute Monopolposition, wodurch der Konzern einseitige Preiserhöhungen und ungünstigere Metriken rücksichtslos diktieren kann, ohne dass der Kunde eine realistische Möglichkeit zum Wechsel hätte.

Auch die rechtlichen Bemühungen der Europäischen Union durch den EU Data Act, der Cloud-Lock-in-Effekte aufbrechen und die Datenportabilität erzwingen soll, laufen in der ERP-Praxis weitgehend ins Leere, da das Gesetz zwar die technische Datenhe­rausgabe regelt, aber das Problem der fehlenden Applikationslizenzen für die weitere Datenverarbeitung nicht löst.

Transparenz und Optimierung

Angesichts dieses verminten kaufmännischen Terrains formulierte das E3-Magazin schon öfter in Übereinstimmung mit unabhängigen Lizenzexperten und der DSAG drastische, aber essenzielle Empfehlungen für jeden SAP-Bestandskunden: Oberstes Gebot ist die absolute Transparenz und Optimierung der eigenen Lizenzlandschaft, bevor auch nur eine Unterschrift unter einen Rise-with-SAP- oder Cloud-Vertrag gesetzt wird. Der Weg in die Cloud darf keinesfalls mit historischen Altlasten und ungenutzter Shelfware (Regalware) angetreten werden.

SAP-Bestandskunden müssen die Kon­trolle über ihre User- und Berechtigungsstrukturen zurückerlangen. Da die zukünftige Metrik in S/4 auf vergebenen Berechtigungen und nicht mehr auf reiner Nutzung basiert, muss ein Redesign der SAP-Rollen zwingend vor der Anwendung von SAPs eigenem Star-Service erfolgen.

Es wird dringend empfohlen, auf unabhängige Software-Asset-Management- Tools (SAM) von spezialisierten Anbietern wie USU, Snow, Flexera oder Dynamic License Control zurückzugreifen, die die tatsächliche Nutzung simulieren und aufzeigen, welche teuren Berechtigungsobjekte in den Rollen eliminiert werden können, um eine fatale Einstufung in die teuren Professional-Lizenzen zu verhindern. Wer hier im Vorfeld bereinigt, kann den finalen FUE-Bedarf für die Cloud massiv senken.

Die E3-Redaktion warnt davor, die eigenen, unbefristeten On-prem-Kauflizenzen voreilig in das Cloud-Subskriptionsmodell (Contract Conversion) umzuwandeln. Wo immer es vertraglich noch möglich und sinnvoll ist, sollte auf einer Product Conversion beharrt werden, die den Erhalt des Lizenzbestandes und alter Sondernutzungsrechte garantiert.

Für Unternehmen, die den Cloud-Betrieb anstreben, aber die digitale Souveränität wahren wollen, empfiehlt sich das Bring-Your-Own-License-Modell (BYOL) auf der Infrastruktur eines neutralen Hyperscalers (IaaS) oder bei Green Lake von Hewlett Packard Enterprise. Hierbei bleibt der SAP-Bestandskunde juristischer Eigentümer der Softwarelizenzen und kann bei Unzufriedenheit den Hosting-Provider wechseln oder die Lizenzen zurück ins eigene Rechenzentrum (Private Cloud On-premises) transferieren.

Die Fallstricke der BTP und der indirekten Nutzung müssen minutiös verhandelt werden. Bei der Nutzung des BTP Enterprise Agreements (BTPEA) sollten Unternehmen niemals mit zu großen Cloud-Credit-Paketen starten, da ungenutzte Volumina am Jahresende unweigerlich verfallen. Vielmehr sollte ein kleinvolumiger Einstieg gewählt oder auf sichere Subskriptionsmodelle für klar definierte, dauerhaft benötigte Services (wie die Integration Suite) zurückgegriffen werden.

Bezüglich Digital Access müssen Unternehmen ihre Systemarchitektur und alle Schnittstellen zu Non-SAP-Systemen vor einem Audit exakt analysieren. Nicht jeder Datentransfer löst automatisch eine Belegzählung aus; Funktionen wie der Indirect Static Read müssen vertraglich wasserdicht als kostenfrei definiert bleiben.

Forensische Genauigkeit

Beim Lesen der SAP-Verträge muss eine geradezu forensische Genauigkeit angewandt werden. Ein SAP-Cloud-Vertrag ist nicht auf dem Order Form beendet. SAP-Bestandskunden müssen die tagesaktuell gültigen Cloud Supplements und Service Description Guides aus dem SAP Trust Center herunterladen, lesen und physisch archivieren, da genau diese Dokumente die harten Metriken, Restriktionen (wie die Limitierung auf 2000 OData API Calls in der BDC) und Support Level Agreements vorgeben. Da SAP diese Links und Dokumente regelmäßig ändert, ist eine spätere Beweisführung bei Lizenzstreitigkeiten ohne eine solide eigene Archivierung aussichtslos.

Der kritische IT-Entscheider muss begreifen, dass das aktuelle SAP-Cloud- und ERP-Lizenzmodell keineswegs primär der Befreiung des Kunden dient, sondern ein meisterhaft konstruiertes, kaufmännisches Geflecht zur Maximierung und Verstetigung der SAP-Erlöse darstellt.

Wer sich ohne fundierte IT-Strategie, ohne externe Rechtsberatung und ohne unabhängige Lizenzwerkzeuge auf die Rise-with-SAP-Präsentationen verlässt, wird unweigerlich in eine Kostenfalle tappen, die die Total Cost of Ownership auf Jahre hinaus ruinös in die Höhe treibt und das eigene Unternehmen dauerhaft an den Tropf des Softwaregiganten hängt.

Die digitale Souveränität des SAP-Bestandskunden lässt sich heute nicht mehr durch blindes Vertrauen in die Roadmap der SAP sichern, sondern erfordert radikale Eigenverantwortung, tiefes technisches und vertragliches Verständnis sowie die Bereitschaft, dem ERP-Weltmarktführer bei jeder Lizenzverhandlung auf Augenhöhe und mit äußerster Härte zu begegnen.