Die Kosten von KI für einen SAP-Bestandskunden

Auslaufmodell On-prem-Lizenzen und Engine-Gebühren

Wenn SAP-Chef Christian Klein lautstark verkündet, dass das klassische Abonnement-Modell im Zeitalter der künstlichen Intelligenz töricht sei, sollten bei jedem SAP-Bestandskunden augenblicklich alle Alarmglocken schrillen. Kleins Argumentation beruht auf der Annahme, dass eine Abrechnung nach der Zahl der menschlichen Nutzer (User-based) im Zeitalter des Autonomous Enterprise obsolet wird, da hochentwickelte KI-Agenten die manuelle Arbeit der Menschen im ERP-System weitgehend automatisieren und den Personalbedarf der Unternehmen drastisch reduzieren. Wenn statt hundert Sachbearbeitern künftig nur noch eine Handvoll KI-Operatoren das System steuert, bricht das traditionelle, auf Full Use Equivalents (FUE) basierende Lizenzmodell für den Walldorfer Softwarehersteller in sich zusammen. Um diese drohende Kannibalisierung der eigenen Einnahmen abzuwenden, forciert SAP einen radikalen kaufmännischen Paradigmenwechsel hin zu „Pay per AI-Usage“ und ergebnisorientierten Abrechnungsmodellen.

Pay per AI-Usage und Total Cost of Ownership (TCO)

Was vordergründig nach einer fairen, nutzenbasierten Bepreisung klingt, entpuppt sich bei analytischer Durchleuchtung jedoch als ein geschickt konstruiertes Instrument zur maximalen Monetarisierung von Datenströmen und Prozessen, bei dem die Total Cost of Ownership (TCO) für die Kunden in astronomische Höhen getrieben werden soll.

In diesem neuen vertrieblichen Geflecht stehen sich zwei grundlegende Abrechnungsphilosophien gegenüber: das traditionelle Subscription-Modell und das verbrauchsbasierte Consumption-Modell.

Bei einer klassischen Subscription zahlt der SAP-Bestandskunde eine feste, im Voraus kalkulierbare monatliche oder jährliche Gebühr für definierte Servicepakete. Der Vorteil für den Cloud-Anwender liegt in der absoluten Planungssicherheit; der gravierende Nachteil besteht im Risiko von „Shelfware“, also für ungenutzte Kapazitäten zu bezahlen.

Demgegenüber verspricht das Consumption-Modell – wie es auf der SAP Business Technology Platform (BTP) über das Cloud Platform Enterprise Agreement (CPEA) oder das neuere BTP Enterprise Agreement (BTPEA) angewendet wird – maximale Agilität und eine bedarfsgerechte Skalierung, bei der der SAP-Bestandskunde über ein prepaid-artiges Guthabenkonto verfügt.

Doch für den souveränen SAP-Bestandskunden ist Consumption keineswegs per se besser als Subscription. Während das Abonnement planbare IT-Budgets garantiert, erzeugt das verbrauchsabhängige Modell einen permanenten ROI-Druck auf die Fachbereiche. Da kaum ein Unternehmen im Vorfeld präzise abschätzen kann, wie viele Transaktionen ein KI-Algorithmus zur Beantwortung einer Frage tatsächlich benötigt, wird die Budgetierung bei einer reinen Consumption-Strategie schnell zum unkalkulierbaren finanziellen Blindflug im laufenden Betrieb.

Die Frage ist aufgrund der hohen KI-Investitionen von SAP, OpenAI, Oracle, Anthropic etc. und aktuell sehr niedrigen Gebühren und Token-Preisen berechtigt: Ich habe bei Anthropic Claude mein Limit überschritten und musste teure Token nachkaufen. Ich habe bei Claude nachgefragt und bekam von der KI die Antwort, dass es nach einer Vollkostenrechnung für mich noch immer preiswert sei, denn mein 200-Dollar-Claude-Abo entspricht etwa dem Wert von 75.000 US-Dollar. Die Differenz ist momentan subventioniert und alle KI-Anbieter schreiben Verluste!

Subscription versus Consumption

Die Kostenfallen dieses Consumption-Modells sind vielfältig und bedrohen die finanzielle Stabilität der IT-Infrastruktur unvorbereiteter SAP-Anwender. Erstens ist das tückische Verfallsprinzip der vorab erworbenen Cloud Credits zu nennen. Bestandskunden müssen sich im Rahmen von Verträgen wie dem BTPEA zu jährlichen Mindestabnahmemengen verpflichten.

Das perfide Detail: Ungenutzte Cloud Credits verfallen am Ende eines jeden Vertragsjahres ersatzlos, was einen enormen kaufmännischen Druck aufbaut, Services krampfhaft zu konsumieren, um kein Geld zu verbrennen. Zweitens droht auf der anderen Seite des Verbrauchs-Spektrums der gefürchtete „Cloud Bill Shock“.

Cloud Bill Shock

Sobald das im Voraus bezahlte Kontingent an Cloud Credits erschöpft ist, schlägt SAP unbarmherzig zu und berechnet jede weitere Übernutzung unrabattiert zum extrem teuren Listenpreis. Das flexibel wirkende Pay-As-You-Go-Modell (PAYG) entpuppt sich hierbei als kaufmännische Mogelpackung, da die dortigen Servicegebühren von vornherein nicht rabattfähig sind und somit bei skalierendem Einsatz im produktiven Alltag die mit Abstand teuerste aller Betriebsformen darstellen.

LLM-Token und SAP BTP GenAI Hub

Ein dritter, oft völlig unterschätzter Kostentreiber ist der schiere Token-Verbrauch großer Sprachmodelle innerhalb des Generative AI-Hub der BTP. Im Gegensatz zu deterministischer Software arbeiten Large Language Models probabilistisch. Werden komplexe, iterative Prompts gestartet oder KI-Agenten aufgerufen, die im Rahmen von RAG-Architekturen (Retrieval-Augmented Generation) riesige Kontextfenster durchsuchen, explodieren die API-Kosten in kürzester Zeit.

Durch das Phänomen des „Lost in the Middle“, bei dem Sprachmodelle Informationen im Mittelteil langer Texte schlichtweg übersehen und ignorieren, müssen oft mehrfach verfeinerte Suchanfragen gestartet werden, was den Token-Zähler unbemerkt im Hintergrund nach oben treibt. Jede einzelne Abfrage bei einem Copiloten wie Joule oder einem BTP-Agenten kostet bares Geld. Wenn am Ende doch ein menschlicher Experte im Sinne des „Human in the Loop“-Prinzips jede KI-Buchung mühsam kontrollieren und freigeben muss, stellt sich die wirtschaftliche Sinnhaftigkeit dieses statistischen Blackbox-Ansatzes unter dem permanenten Druck explodierender Token-Gebühren dringender denn je.

SAP API Policy und Digital Access

SAP errichtete eine digitale Zollschranke durch die neue, restriktive API Policy. Unter dem Deckmantel von Sicherheitsbedenken schränkt der Walldorfer Konzern SAP den direkten Datenzugriff externer KI-Agenten von Drittanbietern auf die geschäftskritischen SAP-Systeme rigoros ein. Wer wertvolle ERP-Daten abziehen möchte, um sie mit den KI-Werkzeugen der Hyperscaler zu analysieren, wird blockiert und in das proprietäre, teure Ökosystem der BTP und der SAP Business Data Cloud (BDC) gezwungen.

Diese Abschottung greift tief in das bewährte Prinzip des „Digital Access“ ein. Hierbei wird nicht mehr der menschliche Nutzer lizenziert, sondern die schiere Anzahl der in Nicht-SAP-Quellen erstellten und in den SAP-Kern importierten Belege, was bei unvollständiger Planung zu verheerenden Nachzahlungen führen kann. Da die Listenpreise für dieses Dokumentenvolumen absurd hoch angesetzt sind, versucht SAP die Kunden mit befristeten Rabattprogrammen wie dem Digital Access Adoption Program (DAAP) in das neue Modell zu locken, um sie danach vertraglich dauerhaft an die Belegzählung zu binden.

Letztendlich machen die teuren, aber obligatorischen Hana-Datenbanklizenzen auf der BTP einfache, innovative Low-Code-Applikationsentwicklungen für den Mittelstand von Beginn an unwirtschaftlich.

SAP Autonomous Enterprise

Fragt sich der SAP-Bestandskunde, was das viel gepriesene Autonomous Enterprise konkret kostet, stößt man auf ein undurchsichtiges Geflecht aus intransparenten Preisen und technischen Abhängigkeiten. Es gibt keine einfache Flatrate für autonome Intelligenz. Stattdessen setzt sich die Kostenstruktur aus zahlreichen Mosaiksteinen zusammen: Neben den Basiskosten für die Cloud-Transformation (Rise mit SAP) müssen zusätzliche Lizenzen für die BTP-Plattforminfrastruktur erworben werden. Vorgefertigte Embedded-AI-Szenarien und Joule-Meldungen sind zwar formal in bestimmten Cloud-Abonnements in geringen Kontingenten enthalten, doch sobald diese Grenzen überschritten werden, verlangt SAP den teuren Zukauf von sogenannten AI-Units.

SAP Discovery Center

Wie sich diese virtuellen Währungen in echte Euro umrechnen, hängt von individuell ausgehandelten Verträgen ab, was jegliche Transparenz im Keim erstickt. Ein konkretes Rechenbeispiel aus dem SAP Discovery Center verdeutlicht das Preisgefüge: Die automatisierte Erstellung eines ESG-Reports mit generativer KI auf Basis des SAP Sustainability Control Towers schlägt bei einem Berichtsumfang von 100 Seiten mit zwölf AI-Units zu Buche, was bei einem fiktiven Unit-Preis von 7 Euro monatliche Kosten von 84 Euro beziehungsweise 1.008 Euro pro Jahr allein für dieses eine funktionale Feature bedeutet.

Darüber hinaus lauern weitere versteckte Kosten an den Rändern dieser neuen Architektur. Die BDC, die von Kritikern in der Anwendervereinigung DSAG treffend als „Business Data Complexity“ verspottet wird, zwingt Unternehmen dazu, ihre historischen Daten in eine teure Lakehouse-Architektur zu spiegeln, um überhaupt Zugang zu modernen KI-Services zu erhalten, was de facto einer ruinösen Datenverdopplungssteuer entspricht.

Falle: SAP Contract Conversion

Auch bei der klassischen S/4-Migration drohen erhebliche Kostenrisiken: Neben den drastisch steigenden Wartungsgebühren für ältere ECC-Systeme verlangt SAP bei einer erweiterten Wartung bis 2030 einen saftigen Aufschlag von zwei Prozent auf die bestehenden Wartungsgebühren, was effektiv einer versteckten Preiserhöhung von rund neun Prozent entspricht. Wer diese Verträge unvorbereitet unterzeichnet und die Lizenzen per „Contract Conversion“ konvertiert, verliert alle Altrechte an seinen On-prem-Lizenzen, wechselt in ein reines, dauerhaftes Mietverhältnis und sieht sich mit Preisaufschlägen von 20 bis 50 Prozent konfrontiert.

Governance mit Customer Center of Expertise (CCoE)

Um sich in diesem hochkomplexen kommerziellen Minenfeld vor einer unkontrollierten Kostenexplosion zu schützen, müssen SAP-Bestandskunden eine eiserne technische und organisatorische Governance etablieren. Als elementare Kontrollinstanz muss das Customer Center of Expertise (CCoE) beziehungsweise das IT-Asset-Management zu einer strategischen FinOps-Zentrale ausgebaut werden, die die Verbräuche von Cloud Credits, AI-Units und Tokens nicht nur einmalig beim Vertragsabschluss bewertet, sondern als kontinuierliche Steuerungsaufgabe über die gesamte Vertragsperiode hinweg überwacht.

SAP-Bestandskunden sollten bei Verhandlungen mit der SAP niemals mit zu großen Cloud-Credit-Paketen (BTPEA) starten, um den ersatzlosen Verfall von Guthaben am Jahresende wirksam zu verhindern, sondern stattdessen kleinvolumig einsteigen. Weiters ist eine gründliche Bereinigung der Stamm- und Bewegungsdaten (Cleansing) sowie die rechtssichere Stilllegung von Altsystemen unerlässlich, um unnötig teuren Datenverkehr und Hauptspeicherbedarf zu minimieren. Ebenso müssen die Berechtigungen im System konsequent nach dem Prinzip der minimalen Berechtigung restrukturiert werden, da SAP-Systemvermessungswerkzeuge wie STAR manche Benutzer fälschlicherweise anhand von zugewiesenen Rollenberechtigungen statt der tatsächlichen Nutzung klassifizieren, was zu einer massiven, vermeidbaren Überlizenzierung führt. Letztendlich ist vor jedem Audit eine akribische Analyse aller Schnittstellen zu Non-SAP-Systemen zwingend erforderlich, um ungeplante Digital-Access-Zahlungen zu blockieren und kostenfreie Datentransfers wie den „Indirect Static Read“ vertraglich festzuschreiben.

KI-Entwickler sollten an der SAP-Basis darauf achten, durch Grounding-Techniken wie optimierte RAG-Chunk-Größen, Prompt-Caching und datenschutzkonformes Preprocessing auf dem SAP AI Core den Token-Verbrauch der Sprachmodelle systematisch einzudämmen, damit die künstliche Intelligenz am Ende nicht die wirtschaftliche Existenz des Unternehmens auffrisst.