FAQ: SAP Contract Governance

SAP Contract Governance ist die laufende, systematische Steuerung von SAP-Verträgen nach der Unterzeichnung, über die gesamte Vertragslaufzeit und über alle SAP-Produkttypen hinweg. Sie verbindet die vertragliche, betriebliche und kommerzielle Sicht in einem kontinuierlichen Steuerungsmodell. Das Ziel ist, dass Unternehmen zu jedem Zeitpunkt einen vollständigen Überblick über ihre SAP-Verpflichtungen, Nutzungsrechte und Kostenentwicklungen haben und auf dieser Basis proaktiv handeln können.

SAP-Lizenzmanagement konzentriert sich klassisch auf die Vermessung und Klassifizierung von Benutzern, vor allem im On-Premise-Umfeld und typischerweise in jährlichem Rhythmus. SAP Contract Governance geht weiter: Sie stellt die Verbindung zwischen vertragsrechtlicher Grundlage, tatsächlicher Nutzung und finanzieller Planung her, und das über die gesamte Vertragslaufzeit in einem kontinuierlichen Prozess. In Cloud-Vertragsmodellen wie RISE reicht Lizenzmanagement allein nicht aus, um die Komplexität von Credit-Mechaniken, Verbrauchslogiken und Klausel-Risiken zu steuern.

Empfehlenswert ist ein Start 12 bis 18 Monate vor dem geplanten Vertragsende (Quellen: saplicensingexperts.com, saprisenegotiations.com). Diese Vorlaufzeit ist notwendig, um Verbrauchsdaten vollständig zu erheben, Klauseln zu analysieren, Verhandlungsziele zu definieren und interne Stakeholder auszurichten, bevor SAP ein Renewal-Angebot vorlegt. Wer später beginnt, verhandelt unter Zeitdruck und mit schwächerer Datenbasis.

Wenn das Kündigungsfenster vor dem Vertragsende verpasst wird, verlängert sich der Vertrag automatisch zu den bestehenden Konditionen, in der Regel für ein weiteres Jahr. Bei RISE-Verträgen mit mehrjähriger Bindung kann das Kündigungsfenster weit vor dem nominellen Vertragsende liegen. Die genaue Frist ist im Vertrag geregelt und sollte frühzeitig im Kalender vermerkt sein (Quelle: saprisenegotiations.com, saplicensingexperts.com).

Full Use Equivalents (FUE) sind die Maßeinheit für die Benutzerlizenzierung in S/4HANA Cloud unter RISE with SAP. Ein Advanced User entspricht einem höheren FUE-Äquivalent als ein Core User oder Self-Service User. Die Klassifizierung basiert auf Berechtigungen: Hat ein Benutzer eine Berechtigung, die einem Advanced-Lizenztyp entspricht, wird er als Advanced gezählt, unabhängig von der tatsächlichen Nutzung der Berechtigung. Zu breite Berechtigungsrollen haben damit direkte Auswirkungen auf die Lizenzkosten.

BTP Credits im CPEA/BTPEA-Modell verfallen in der Regel am Ende des Vertragsjahres, wenn sie nicht verbraucht wurden. AI Units (PUPM: Per User Per Month) verfallen meist monatlich. Dagegen helfen: laufendes Monitoring des Credit-Verbrauchs auf Service-Ebene, frühzeitige Identifikation von Credit-Überschüssen, Hochlaufen geplanter BTP-Projekte vor Jahresende, und gegebenenfalls Nutzung ungenutzter Credits für interne Entwicklungs- oder Testzwecke. Die proaktive Steuerung setzt eine monatliche Verbrauchssicht voraus, keine jährliche (Quellen: SAP Help Portal, SAP Community Blogs, saplicensingexperts.com).

Digital Access ist das SAP-Lizenzmodell für Szenarien, in denen Drittanbieter-Systeme auf SAP-Daten zugreifen oder SAP-Transaktionen auslösen, ohne direkten menschlichen Benutzer. CRM-Systeme, E-Commerce-Plattformen oder IoT-Schnittstellen können je nach Architektur und Vertragsstand eine zusätzliche Lizenzierungspflicht auslösen. In RISE-Verträgen sind bestimmte Digital Access-Szenarien inklusive, andere nicht. Die eigene Integrationslandschaft zu dokumentieren und auf Lizenzrelevanz zu prüfen ist eine Governance-Aufgabe, die laufend relevant bleibt, nicht nur bei der Erstlizenzierung (Quellen: redresscompliance.com, saprisenegotiations.com).

RISE with SAP garantiert in der Standardausprägung eine Systemverfügbarkeit von 99,7%. Der übliche Industriestandard für Enterprise Cloud-Dienste liegt bei 99,9%. Der Unterschied entspricht im Jahr etwa 17 Stunden tolerierbarer Ausfallzeit (99,7%) gegenüber etwa 8,7 Stunden (99,9%). Für Unternehmen mit produktionskritischen Systemen auf RISE ist das ein relevantes Verhandlungsargument. SLA-Upgrades sind in manchen Vertragsstrukturen verfügbar, aber nicht Standard (Quellen: SAP Help Portal, saprisenegotiations.com, The Register).

Bei Unternehmensübernahmen, Fusionen oder Carve-outs sind bestehende SAP-Verträge direkt betroffen. Affiliate Licensing-Klauseln regeln, welche verbundenen Unternehmen im Rahmen des bestehenden Vertrags SAP nutzen dürfen. Bei M&A-Transaktionen können übernommene Unternehmen bestehende Lizenzprobleme mitbringen. Eine Vertragscheck-Due-Diligence vor dem Closing der Transaktion ist eine anerkannte Best Practice, um Compliance-Risiken aus dem erworbenen Portfolio zu erkennen (Quellen: redresscompliance.com, saprisenegotiations.com).

Der Annual Contract Value (ACV) ist der jährliche Vertragswert eines SAP-Vertrags. Er ist die Grundlage für viele vertragsrelevante Berechnungen, darunter prozentuale Preisanpassungen (CPI-Klausel), Übernutzungsgebühren und Governance-Preismodelle. Der Total Contract Value (TCV) ist der Gesamtvertragswert über die vollständige Laufzeit. Bei einem RISE-Vertrag über fünf Jahre entspricht der TCV dem fünffachen ACV, zuzüglich geplanter Preisanpassungen. Beide Kennzahlen sind für Budget-Planung und Renewal-Vorbereitung relevant.

Reaktive Governance agiert, wenn SAP einen Schritt einleitet: Renewal-Angebot, Rechnungsstellung, Vermessungsergebnis. Das eigene Team reagiert ohne vorbereitete Datenbasis. Proaktive Governance baut laufend eine Datenbasis auf und handelt vor den Ereignissen: Verbrauchsdaten werden monatlich ausgewertet, Renewal-Vorbereitung beginnt 12-18 Monate vorher, Klausel-Risiken sind bekannt bevor sie wirken. Der Unterschied liegt nicht in der Expertise, sondern in der Struktur: Wer eine kontinuierliche Steuerungsgrundlage aufgebaut hat, hat in jedem dieser Momente eine bessere Ausgangslage.

Governance-Angebote sind am Markt unterschiedlich strukturiert. FinOptory berechnet für das Self-Service-Modell ("Sie steuern.") 1,5% des ACV der verwalteten Verträge pro Jahr. Für das Managed Service-Modell ("Wir steuern. Sie entscheiden.") 2,2% des ACV pro Jahr. Der Einstieg erfolgt über einen Vertragscheck zu einem Festpreis von 7.900 EUR (4 Wochen, ein Vertrag). Floor und Cap für laufende Governance-Modelle werden individuell vereinbart.

Beides ist möglich, und die Antwort hängt von der internen Kapazität und der Portfoliokomplexität ab. Intern aufgebaute Governance funktioniert gut, wenn dedizierte Kapazität vorhanden ist, SAP-Vertragswissen aufgebaut werden soll und ein klarer Governance-Prozess definiert werden kann. Externe Unterstützung ist sinnvoll, wenn das Portfolio zu komplex für die vorhandene Kapazität ist, ein Renewal kurz bevorsteht oder eine M&A-Situation die Komplexität sprunghaft erhöht hat. Die beiden Modelle schließen einander nicht aus: Ein Einstieg mit externer Unterstützung kann der Ausgangspunkt für den Aufbau interner Kompetenz sein.

Bei CPEA-Verträgen verfallen nicht genutzte Credits am Ende des Verbrauchszeitraums. Ein automatischer Roll-over in das Folgejahr ist im Standard nicht vorgesehen. Ob eine Roll-over-Vereinbarung im Vertrag enthalten ist, lässt sich in den Contract Schedules prüfen. Quelle: SAP Help Portal, CPEA Vertragslogik; saplicensingexperts.com.

CPEA (Cloud Platform Enterprise Agreement) ist das ältere Vertragsmodell für BTP, das in vielen laufenden Verträgen noch aktiv ist. BTPEA (BTP Enterprise Agreement) ist das aktuelle Nachfolgemodell. Beide arbeiten mit jährlichen Credit-Budgets, unterscheiden sich aber in Service-Katalog, Abrechnungslogik und der Art, wie Restguthaben behandelt werden. Bei einem bestehenden CPEA-Vertrag lohnt es sich, den Umstieg auf BTPEA im Rahmen des nächsten Renewals zu evaluieren. Quelle: SAP Community; saplicensingexperts.com.

SAP Business AI Units, die über den Generative AI Hub oder AI Services auf BTP konsumiert werden, folgen einer anderen Verbrauchslogik als das allgemeine CPEA-Guthaben. Per-User-Per-Month-Requests (PUPM) verfallen in der Regel am Monatsende, nicht am Jahresende. Das bedeutet, dass ungenutzte AI-Anfragen innerhalb eines Monats nicht in den Folgemonat übertragen werden. Wer AI-Services eingeführt hat, aber noch nicht im produktiven Betrieb ist, sollte die monatlichen Verbrauchsdaten gesondert beobachten. Quelle: SAP Community Blog; SAP Help Portal.

BTP-Verbrauchsdaten lassen sich im SAP BTP Cockpit auf Subaccount-Ebene auswerten. Eine verursachergerechte Zuordnung zu Projekten oder Kostenstellen erfordert eine bewusste Subaccount-Struktur, in der BTP-Ressourcen je Geschäftsbereich oder Projekt in separaten Subaccounts betrieben werden. Diese Strukturentscheidung muss früh getroffen werden, da eine nachträgliche Reorganisation der Subaccount-Hierarchie aufwendig ist. Quelle: SAP Help Portal, BTP Account Model Documentation.

Pre-Signature-Beratung ist auf den Vertragsabschluss ausgerichtet. Sie endet mit der Unterzeichnung. Post-Signature-Governance beginnt nach der Unterzeichnung und erstreckt sich über die gesamte Laufzeit. Sie steuert laufend Nutzung, Berechtigungen, Infrastruktur und Kosten und bereitet das Renewal auf Basis einer belastbaren Datenbasis vor. Beide Disziplinen ergänzen einander; sie ersetzen einander nicht.

Steuerungsmomente entstehen monatlich, quartalsweise und jährlich. Monatlich: PCE-Metering-Auswertung, BTP-Credit-Verbrauch, Rechnungsabgleich. Quartalsweise: Gesamtüberblick Vertragsperformance, Budget-Perspektive. Jährlich: vollständige Bestandsaufnahme, Einordnung aller anstehenden Renewals. Zusätzlich entstehen situative Steuerungsmomente bei Organisationsveränderungen, neuen Produkttypen oder M&A-Ereignissen.

Ja, wenn dedizierte Kapazität vorhanden ist und SAP-Vertragswissen intern aufgebaut werden soll. Das Self-Service-Modell ("Sie steuern.") ist genau dafür konzipiert. Die Plattform liefert die Datenbasis, das interne Team steuert. Wer feststellt, dass die Portfoliokomplexität die interne Kapazität übersteigt, kann jederzeit in das Managed-Service-Modell wechseln, ohne Datenverlust.

Der strukturierte Einstieg ist der Vertragscheck: Ein Vertrag, vier Wochen, 7.900 EUR Festpreis. Er klärt die Ausgangslage, identifiziert Steuerungsmomente und gibt eine Einschätzung, welches Folgemodell zur Organisation passt. Besonders sinnvoll ist er, wenn ein Renewal in den nächsten 24 Monaten bevorsteht oder eine Vertragsverantwortung neu übernommen wurde.

- Hub: SAP Contract Governance: Verträge nach der Unterschrift steuern - Steuerungsmomente bei SAP-Verträgen verstehen - SAP Contract Governance über alle neun Produkttypen

Nein. Ein sinnvoller Einstieg beginnt mit den volumenstärksten Verträgen im eigenen Portfolio: typischerweise RISE oder On-Premise mit Wartung. Von dort lässt sich die Governance schrittweise auf weitere Produkttypen ausweiten. Entscheidend ist, dass eine gemeinsame Datenbasis von Anfang an als Grundlage aufgebaut wird, die spätere Erweiterungen ohne Systembruch ermöglicht.

Weil sie aus der Wahrnehmung vieler Teams unter HR oder Einkauf fallen und nicht unter "SAP-Vertragssteuerung" subsumiert werden. In der Praxis sind aber genau die variablen Transaktionsgebühren von Ariba und die Benutzerfluktuations-Abweichungen bei Concur häufige Ursachen für Budgetabweichungen, die beim ersten Auftreten schwer erklärbar sind. Governance bedeutet, diese Produkttypen bewusst einzubeziehen.

Eine Bestandsaufnahme: Welche SAP-Verträge bestehen aktuell, bei wem liegen sie, wann laufen sie aus? Diese einfache Frage ist der Ausgangspunkt. Ein strukturierter Vertragscheck schafft in vier Wochen die Grundlage, um diese Frage vollständig zu beantworten und die nächsten Schritte zu priorisieren.

In der Praxis empfiehlt sich folgende Priorisierung: zuerst die Produkte mit den höchsten ACV-Anteilen und den nächsten Renewal-Terminen. Danach die Produkte mit den komplexesten Verbrauchsmodellen (BTP, RISE). Produkte mit einfacheren Per-User-Modellen (Concur, IBP) können in einem zweiten Schritt einbezogen werden. Diese Reihenfolge orientiert sich an Steuerungswirkung, nicht an Produktsystematik.

Die meisten Organisationen starten zwischen Stufe 1 und Stufe 2: Vertragsunterlagen existieren, aber eine konsolidierte Governance-Datenbasis fehlt. Renewal-Fristen sind irgendwo dokumentiert, aber nicht aktiv im Blick. Verbrauchsdaten werden zwar erhoben, aber nicht regelmäßig mit der Vertragsbasis abgeglichen. Ein strukturierter Vertragscheck ist typischerweise der erste konkrete Schritt, um diese Ausgangslage zu klären und auf Stufe 2 zu kommen.

Nein. Das Reifegradmodell beschreibt eine Richtung, nicht ein universelles Ziel. Für eine Organisation mit einem einzelnen RISE-Vertrag und einem Renewal in vier Jahren kann eine gut etablierte Stufe 3 vollständig ausreichen, mit planbaren Budgets, einer informierten Verhandlungsposition und laufend genutzten Steuerungsmomenten. Stufe 4 ist vor allem für Portfolios mit hoher Komplexität, mehreren SAP-Produkttypen und strategischer SAP-Abhängigkeit relevant.

Das hängt von der Komplexität des Vertragsportfolios und der internen Kapazität ab. Mit einem strukturierten Vertragscheck als Ausgangspunkt und einer definierten Governance-Verantwortung lässt sich Stufe 2 in vier bis acht Wochen erreichen. Der Übergang zu Stufe 3, also die Einbettung in den Betriebsrhythmus, dauert typischerweise ein bis drei Quartale. Mit externem Managed-Service-Support verkürzt sich dieser Zeitraum erheblich, weil die Governance-Datenbasis und der Rhythmus sofort etabliert werden, ohne internen Aufbau abzuwarten.

Klassische Software Asset Management-Reifegradmodelle konzentrieren sich auf Lizenz-Compliance und Benutzerklassifizierung, typischerweise im On-Premise-Umfeld. Das SAP Contract Governance-Reifegradmodell ist breiter angelegt: Es umfasst alle vier Steuerungsmomente-Bereiche (Nutzung, Berechtigungen, Infrastruktur, Kosten), die Koordination aller vier beteiligten Rollen und die strategische Verankerung der Governance. Der Fokus liegt auf der Post-Signature-Phase über alle SAP-Produkttypen, nicht nur auf der Compliance-Messung zu einem Stichtag.

SAM4U ist für die berechtigungsbasierte Nutzerklassifizierung im S/4HANA-Umfeld entwickelt worden und liefert dafür verlässliche Messdaten. Als Allokationswerkzeug für die interne Kostenverrechnung ist es nicht konzipiert: Es fehlen die Verbindung zu Vertragskosten, die Causation-Logik für Projektbezug und die Reporting-Formate für den internen Budgetdialog.

Lizenzmanagement stellt sicher, dass die Nutzung der SAP-Software im vertraglichen Rahmen bleibt und Compliance gegenüber SAP nachweisbar ist. Interne Verrechnung ordnet die entstehenden Kosten den verursachenden Organisationseinheiten zu. Beides setzt unterschiedliche Daten, Prozesse und Werkzeuge voraus. In vielen Organisationen ist das Lizenzmanagement etabliert, die interne Verrechnung dagegen noch nicht strukturiert.

Eine monatliche Aktualisierung ist sinnvoll, weil wesentliche SAP-Verbrauchskomponenten monatlich abgerechnet werden (AI Units verfallen monatsweise, BTP-Verbrauch läuft monatlich). Eine quartalsweise Aggregation reicht für Budget-Forecasting, erfasst aber keine unterjährigen Verschiebungen, die für Renewal-Vorbereitung relevant sind.

Die wesentlichen Quellen sind: Vertragsdokumente mit Komponenten und Preisstruktur, SAM4U-Messdaten für Nutzerklassifizierung, BTP-Verbrauchsdaten aus dem BTP Cockpit, sowie eine Zuordnungslogik, die Verbrauch mit Projekten oder Geschäftsbereichen verbindet. Diese Zuordnungslogik fehlt in den meisten SAP-eigenen Werkzeugen und muss außerhalb aufgebaut werden.

Die meisten Organisationen starten zwischen Stufe 1 und Stufe 2: Eine grundlegende Dokumentation der Lizenzbasis ist vorhanden, aber kein laufender Governance-Rhythmus. USMM wird gelegentlich ausgeführt, SAM4U ist nicht installiert oder nicht aktiv genutzt. Fehlklassifizierungen sind bekannt oder werden vermutet, aber nicht systematisch adressiert. Ein strukturierter Vertragscheck ist typischerweise der erste konkrete Schritt, um diese Ausgangslage zu klären.

Ja. Das allgemeine Reifegradmodell (beschrieben in Pillar 1 dieser Content-Reihe) betrachtet alle vier Steuerungsmomente-Bereiche: Nutzung, Berechtigungen, Infrastruktur und Kosten, sowie die Koordination aller vier Rollen. Das Lizenz-Reifegradmodell vertieft die Lizenz-Dimension spezifisch: Named User, FUE, Vermessungstools, Berechtigungen und Audit-Readiness. Beide Modelle ergänzen sich; wer beide Standortbestimmungen durchführt, hat ein vollständiges Bild.

Erheblich. Im On-Premise-Umfeld war Stufe 2 (jährliches USMM) lange eine akzeptable Grundlage. Im PCE-Kontext, mit monatlichem automatisiertem Metering durch SAP, ist Stufe 2 strukturell nicht mehr ausreichend: Klassifizierungsfehler werden 12 Mal schneller sichtbar. Der Steuerungsmoment Berechtigungen wird faktisch zum monatlichen Steuerungsmoment. Für PCE-Kunden ist der Übergang zu Stufe 3 deshalb dringlicher als für On-Premise-Organisationen.

Das hängt vom Preisunterschied zwischen den Lizenztypen und dem Zeitraum der Unterlizenzierung ab. Ein Rechenbeispiel aus der SAP-Compliance-Praxis: 100 Nutzer mit Limited-Lizenz, die tatsächlich Professional-Transaktionen ausführen, bei einer Preisdifferenz von rund 1.500 USD pro Nutzer ergibt 150.000 USD Nachkauf, zuzüglich drei Jahre Back-Maintenance (22 Prozent per annum) ergibt ein Gesamtexposure von rund 249.000 USD. Das illustriert, warum laufende Klassifizierungsüberprüfung wirtschaftlich sinnvoller ist als reaktive Bereinigung im Audit-Kontext.

Die Kündigungsfrist ist vertragsindividuell und steht in der Order Form sowie den zugehörigen Schedules. In der Praxis beschreiben SAP-Vertragsspezialisten Fristen zwischen 90 und 180 Tagen vor Vertragsende. Maßgeblich ist ausschließlich der eigene Vertragswortlaut. Öffentliche Quellen wie saplicensingexperts.com und saprisenegotiations.com liefern Orientierungswerte, ersetzen aber keine vertragliche Prüfung.

Eine Kündigung, die nach dem vertraglich vereinbarten Fristende eingeht, löst in der Regel die automatische Vertragsverlängerung aus. Die Verlängerungsdauer ist im Vertrag definiert und beträgt häufig ein weiteres Jahr. Eine nachträgliche Kündigung vor dem neuen Vertragsende ist in den meisten Fällen wieder an eine Frist gebunden.

Ja. SAP-RISE-Verträge enthalten typischerweise eine Schriftformklausel für vertragsrelevante Mitteilungen, zu denen Kündigungen zählen. Form, Adressat und Übermittlungsweg sind in der Order Form oder in den Schedules festgelegt. Eine E-Mail kann ausreichend sein, wenn der Vertrag das ausdrücklich zulässt, ist aber durch die Eingangsbestätigung zu sichern.

Ja, das ist eine gängige Vorgehensweise in komplexen Vertragsverhandlungen. Die fristgerechte Kündigung schafft Verhandlungsdruck, ohne das Vertragsverhältnis zwingend zu beenden. Parallele Verhandlungen können bis zum Vertragsende fortgeführt werden. Voraussetzung ist eine sorgfältige rechtliche Prüfung der Vertragsbedingungen im konkreten Einzelfall.

Im Self-Service-Modell arbeitet das eigene Team direkt mit der Plattform: Es wertet Daten aus, bewertet Handlungsoptionen und entscheidet. Im Managed Service-Modell übernimmt ein externes Experten-Team diese operative Arbeit und liefert wöchentliche Handlungsempfehlungen. Die Entscheidung, was getan wird, trifft weiterhin das eigene Unternehmen. Der Hauptunterschied liegt in der operativen Steuerungsarbeit, nicht in der Entscheidungshoheit.

Nein. Im Managed Service-Modell hat das eigene Unternehmen weiterhin Zugriff auf die Plattform und alle Daten. Der Unterschied ist, dass das Experten-Team die Analyse übernimmt und die Ergebnisse aufbereitet. Transparenz und Einblick bleiben vollständig erhalten.

Ja, jederzeit. Da beide Modelle auf derselben Plattform und Datenbasis aufgebaut sind, entstehen beim Wechsel keine Datenverluste und kein Neustart. Die aufgebaute Vertragsbaseline, Verbrauchshistorie und Governance-Dokumentation bleiben vollständig erhalten.

Der Vertragscheck ist der empfohlene erste Schritt. Er schafft in vier Wochen Klarheit über die eigene Ausgangslage: Welche Datenbasis existiert, welche Klauseln sind steuerungsrelevant, was sind die nächsten Handlungsprioritäten. Auf dieser Grundlage wird die Entscheidung für das passende Folgemodell deutlich einfacher als ohne diese Basis.

- SAP Contract Governance: Verträge nach der Unterschrift steuern: Überblick über die Grundlagen - Vier Rollen, ein SAP-Vertrags-Steuerungsmodell: Wer in der Organisation was steuert - SAP Contract Governance Reifegradmodell: Wo steht Ihre Organisation heute?

Ein Steuerungsmoment ist ein konkreter Zeitpunkt im SAP-Vertragsleben, an dem eine Entscheidung möglich ist und eine nachweisliche Wirkung auf Nutzung, Kosten oder Vertragskonditionen hat. Typische Beispiele sind der Jahreswechsel bei BTP-Credits, der Monatszyklus im PCE-Metering oder das Kündigungsfenster vor einem Auto-Renewal. Wer Steuerungsmomente kennt und beobachtet, kann proaktiv agieren statt reaktiv reagieren.

Ein SAP-Audit ist eine von SAP initiierte oder vertraglich vereinbarte Prüfung der Lizenzcompliance. Ein Steuerungsmoment ist eine aus der eigenen Governance-Systematik hergeleitete Entscheidungssituation. Steuerungsmomente entstehen aus laufendem Monitoring durch die eigene Organisation, nicht durch externe Prüfungen. Wer Steuerungsmomente strukturiert beobachtet, ist in einer Audit-Situation besser aufgestellt, weil die eigene Datenbasis bereits vollständig ist.

Mit erheblichem manuellem Aufwand ist das möglich, aber kaum skalierbar. BTP-Credit-Verbräuche, FUE-Metering-Ergebnisse und Vertragsdaten liegen in unterschiedlichen Systemen. Sie manuell zusammenzuführen ist zeitaufwendig und fehleranfällig. Für ein Portfolio mit mehreren SAP-Vertragstypen ist eine Datenbasis erforderlich, die diese Quellen automatisch verbindet und Abweichungen sichtbar macht.

Das hängt von der Portfoliokomplexität ab. In einem RISE-Portfolio mit BTP und S/4HANA Cloud gibt es monatliche Metering-Zyklen, jährliche Credit-Jahresgrenzen, AI-Unit-Verfall auf PUPM-Basis und mehrjährige Renewal-Fristen. Ein strukturiertes Governance-Modell identifiziert in einem typischen RISE-Portfolio mindestens 8 bis 12 relevante Steuerungsmomente pro Jahr, die eine aktive Entscheidung erfordern.

Der Contract Manager pflegt die inhaltliche Vertragsbaseline: was ist vereinbart, welche Klauseln gelten, welche Fristen laufen. Procurement steuert die Lieferantenbeziehung und führt Verhandlungen. Beide Rollen sind für eine effektive Steuerung notwendig, aber sie sind nicht deckungsgleich. Der Contract Manager liefert den inhaltlichen Input für Verhandlungen; Procurement setzt ihn kommerziell ein.

Für größere SAP-Verträge, insbesondere RISE-Enterprise-Agreements, sollte die strukturierte Vorbereitung 12 bis 18 Monate vor dem Renewal-Datum beginnen (Quelle: saplicensingexperts.com, saprisenegotiations.com). Das umfasst die Aktualisierung der Vertragsbaseline, die Nutzungsanalyse, die Entwicklung von Szenarien und die Abstimmung der Verhandlungsstrategie. Wer mit sechs Monaten Vorlauf beginnt, hat deutlich weniger Optionen als wer den Prozess frühzeitig anstößt.

In größeren Organisationen übernimmt ein SAP Center of Excellence (CCoE) die Koordinationsfunktion. In mittelgroßen Unternehmen liegt die Koordination typischerweise beim Director SAP Plattform, der die Perspektiven der vier Rollen zusammenführt und das Reporting für den Executive aufbereitet. Entscheidend ist, dass diese Koordinationsfunktion klar benannt ist und Zugang zu den relevanten Daten aus allen Rollen hat.

Eine gemeinsame Datenbasis entsteht nicht durch das Zusammenführen von Dokumenten in einem Ordner, sondern durch eine integrierte Sicht auf Vertrag, Nutzung und Kosten. Die Verbindung dieser drei Dimensionen ermöglicht es, die Fragen aus dem Review-Meeting zu beantworten: Was kostet diese Vertragskomponente wirklich? Was bedeutet der aktuelle Verbrauchstrend für das Jahresende? Welche Steuerungsmomente bestehen vor dem nächsten Renewal? Ohne diese Integration arbeiten die vier Rollen jeweils mit einem Ausschnitt der Realität, nicht mit dem Gesamtbild.

Eine AI Unit ist SAP's konsumbasierte Verbrauchseinheit für Business AI Services. Kunden kaufen ein Prepaid-Jahres-Kontingent. Jeder AI-Service-Aufruf, ob Joule-Konversation, eingebettete Finance-Funktion oder Agenten-Ausführung, verbraucht eine definierte Anzahl AI Units, die SAP pro Service in Konversionsfaktoren veröffentlicht. Ungenutzte AI Units verfallen am Ende des Vertragsjahres, sofern keine explizite Rollover-Klausel im Order Form vereinbart wurde (Quelle: SAP Help Portal, Metering and Pricing).

PUPM-Pakete (Per-User-per-Month) weisen jedem Nutzer über den SAP Identity Service ein fixes monatliches Request-Kontingent zu. Nicht genutzte Kontingente können innerhalb eines Pakets auf andere Nutzer desselben Pakets umgelenkt werden, das ist das erlaubte Pooling. Paketübergreifendes Pooling ist nicht möglich. Alle Kontingente eines PUPM-Pakets verfallen am Monatsende ohne Übertrag (Quelle: SAP Learning, PUPM Pricing Model).

Ein RISE- oder SAP Cloud ERP Private-Vertrag enthält typischerweise einige eingebettete AI-Features wie Predictive Accounting und Intelligent AP Automation sowie fixe Transaktions-Quoten und einen View-Only-Joule-Zugang mit begrenzten Konversations-Sessions. Dieser Basisumfang ist für produktive AI-Adoption bei größeren Nutzerpopulationen nicht ausreichend. Joule Power User Seats, zusätzliche AI Units und erweiterte Capability-Pakete sind Add-Ons (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

AI Units sind die Verbrauchseinheit für Business AI Services wie Joule und AI Core. Capacity Units (CU) sind die Verbrauchseinheit für BTP-Plattformdienste wie Integration Suite, Application Development und Datenbankservices. BDC Credits messen Datenvolumen und Datenprodukte in der Business Data Cloud. Die drei Töpfe sind nicht austauschbar, werden separat gemessen und separat beschafft (Quelle: SAP Help Portal).

SAP hat RISE with SAP Premium Plus im Juni 2025 eingestellt. Das bisherige Top-Tier RISE wurde in SAP Cloud ERP Private umbenannt. AI-Capabilities, die vormals in Premium Plus enthalten waren, wurden teilweise in Cloud ERP Private hochgezogen, teilweise als separate Add-Ons neu positioniert. Insbesondere Embedded AI Units sind in Cloud ERP Private nicht mehr automatisch inkludiert, sondern separat zu erwerben. Bestandskunden mit alten Premium-Plus-Verträgen sollten prüfen, was sich im Repackaging verändert hat (Quellen: Redress Compliance, CIO Magazine).

Die Aggregations-Falle bezeichnet die SAP-Standard-Vertragsklausel, nach der der AI-Verbrauch über alle Systemumgebungen, also Entwicklung, Test und Produktion, gemeinsam auf das monatliche Kontingent angerechnet wird. Wer aktive AI-Features in Nicht-Produktivumgebungen betreibt, kann damit unerwartet hohe Verbräuche erzeugen. Eine Dev/Test-Exclusion für die AI-Unit-Zählung ist verhandelbar und sollte bei der nächsten Vertragsverhandlung oder Renewal geprüft werden (Quelle: SAP Licensing Experts).

Der Generative AI Hub bietet Zugang zu Foundation Models verschiedener Anbieter, darunter SAP-eigene Modelle für ABAP-Entwicklung und Prozesskontexte sowie Modelle externer Anbieter. Die verfügbaren Modelle variieren je nach Region, Vertragsversion und SAP-Freigabezyklus. SAP aktualisiert das Modell-Portfolio rollierend. Für Governance-Zwecke sollte die aktuelle Modell-Liste aus der SAP-Dokumentation gezogen werden, nicht aus Marketing-Material (Quelle: SAP Help Portal, Generative AI Hub).

Ein Joule Skill ist eine deterministische, vordefinierte Operation, die eine einzelne Aktion ausführt. Ein Joule Agent ist ein autonomes System, das mehrere Skills orchestriert, einen Plan entwirft und diesen selbstständig ausführt. Der Verbrauchsunterschied ist erheblich: Agenten konsumieren bei komplexen Multi-Step-Plänen deutlich mehr AI Units als einzelne Skill-Aufrufe. Für Budgetplanung und Sizing ist diese Unterscheidung zentral (Quelle: SAP Learning, Introducing Joule Agents).

Am 2. August 2026 tritt die Vollwirkung des EU AI Act für Hochrisiko-AI-Systeme in Kraft. Unternehmen, die AI-Systeme in Hochrisiko-Kategorien produktiv betreiben, müssen ab diesem Datum eine abgeschlossene Konformitätsbewertung, vollständige technische Dokumentation, ein etabliertes Risk-Management-System, definierte Human-Oversight-Mechanismen sowie aktives Logging und Monitoring nachweisen können. Als Deployer dieser Systeme liegt die Verantwortung beim Kunden, nicht bei SAP als Provider (Quelle: European Commission, SAP Trust Center).

Laut SAP Standard-AI-Terms werden Kunden-Geschäftsdaten nicht für das Training SAP-eigener Modelle verwendet. Diese Zusage ist in den AI Terms des SAP-Cloud-Vertrags verankert. Für externe Foundation Models, die über den Generative AI Hub angeboten werden, gilt jeweils der Vertrag des Modell-Anbieters mit SAP. Bei sensiblen Datenkategorien empfiehlt sich eine explizite Prüfung der Datenschutzklauseln des jeweiligen Modell-Anbieters (Quelle: SAP Trust Center, Data Sovereignty).

SAP publiziert keine öffentliche AI-Unit-Tarifliste. Der effektive Pro-Unit-Preis hängt vom gewählten Beschaffungsvehikel, der Vertragsgröße und den individuell verhandelten Konditionen ab. Als Orientierung: Standalone-BTP-Verträge haben typischerweise den höchsten Pro-Unit-Preis. RISE- oder Cloud-ERP-Bundle-Verträge bieten in der Regel günstigere Konditionen. Der SAP AI Pricing Estimator im Discovery Centre liefert Volumen-Schätzungen, aber keine Euro-Beträge. Tatsächliche Kosten ergeben sich erst aus dem im Order Form fixierten Pro-Unit-Preis (Quelle: SAP Pricing Page, SAP Licensing Experts).

Für produktive AI-Use-Cases in regulierten Bereichen oder bei Hochrisiko-Klassifizierung nach EU AI Act ist eine eigenständige Governance-Funktion erforderlich. Ohne strukturierte Inventarisierung, Klassifizierung und Beobachtbarkeit der eingesetzten AI-Systeme können weder Compliance-Anforderungen erfüllt noch Verbrauch und Kostenentwicklung planbar gesteuert werden. Der SAP AI Agent Hub (GA Q3 2026) bietet eine technische Grundlage. Die organisatorische Verankerung der Governance-Funktion liegt beim Kunden.

Nein, die Verfallsregel gilt spezifisch für das monatliche Request-Kontingent in PUPM-Paketen. Das zentrale AI-Unit-Jahreskontingent (das Prepaid-Volumen aus dem Vertrag) läuft zum Jahresende ab, nicht monatlich. Beide Töpfe folgen eigenen Regeln und sollten getrennt beobachtet werden. Quelle: SAP Help Portal, Metering and Pricing for SAP AI Core.

Nein. Ein Rollover von PUPM-Requests über Monatsgrenzen hinweg ist im Standard nicht vorgesehen. Innerhalb des laufenden Monats ist Pooling innerhalb eines Pakets möglich, also können aktive Nutzer Requests nutzen, die anderen Paketmitgliedern zugeordnet, aber noch nicht abgerufen wurden. Am Monatsende verfällt nicht genutztes Volumen unwiderruflich.

Der erste Steuerungsmoment ist der Verbrauchsabgleich: Wie viel des PUPM-Paketvolumens wurde je Paket ausgeschöpft? Der zweite Steuerungsmoment ist die Nutzerzuordnung: Sind alle zugeordneten Nutzer noch aktiv und korrekt den richtigen Paketen zugeordnet? Der dritte Steuerungsmoment ist die Overage-Prüfung: Hat ein Paket das monatliche Kontingent überschritten und zusätzliche AI Units aus dem Jahreskontingent gezogen? Diese drei Prüfpunkte lassen sich in einer monatlichen Routine zusammenfassen und bilden die Grundlage für eine belegte Dimensionierungsentscheidung in der nächsten Vertragsperiode. Quelle: SAP Learning, Analyzing the SAP Per-User-Per-Month Pricing Model.

Ja. Der EU AI Act unterscheidet zwischen Anbieter und Deployer. SAP ist der Anbieter der AI-Systeme und trägt entsprechende Pflichten, die SAP durch seine Zertifizierungen (ISO/IEC 42001, SOC 2) nachweist. Der Kunde ist als Deployer verantwortlich für den konkreten Einsatz: Use-Case-Klassifizierung, Konformitätsbewertung, Human Oversight, Logging und Monitoring. Diese Deployer-Pflichten können nicht an SAP delegiert werden (Quelle: European Commission, SAP Trust Center).

Für jeden produktiven AI-Use-Case in einer Hochrisiko-Kategorie sollten bis zum 2. August 2026 folgende Elemente vorliegen: eine dokumentierte Klassifizierung des Use Cases, eine abgeschlossene Konformitätsbewertung, ein etabliertes Risk-Management-System, definierte Human-Oversight-Mechanismen sowie aktives Logging und Monitoring. Die Inventarisierung aller eingesetzten AI-Use-Cases ist der sinnvollste erste Schritt (Quelle: Secure Privacy EU AI Act 2026 Compliance).

Der AI Agent Hub adressiert mehrere EU-AI-Act-Anforderungen direkt: Inventar aller Agenten (Registrierungspflicht), Observability mit Logging (Artikel 12), Policy-Management für Human Oversight sowie Verification für kontrollierten Betrieb. Er ist eine technische Grundlage, ersetzt aber nicht die organisatorische Governance-Funktion des Kunden. Use-Case-Klassifizierung, Konformitätsbewertung und branchenspezifische Prüfungen liegen weiterhin beim Kunden (Quelle: SAP Insider Sapphire 2026 AI Agent Guardrails).

Der erste Steuerungsmoment ist die Use-Case-Inventarisierung: Welche AI-Features in SAP Business AI werden produktiv genutzt? Welche davon fallen potenziell unter eine Hochrisiko-Kategorie des EU AI Act? Diese Grundlage bestimmt den gesamten Compliance-Aufwand. Ohne sie ist eine belastbare Einschätzung des eigenen Handlungsbedarfs nicht möglich. Für SAP-Kunden mit komplexen Vertragsportfolios ist dieser Schritt eng mit der Vertragsanalyse verknüpft: Welche AI-Capabilities sind vertraglich lizenziert, und welche davon werden tatsächlich produktiv eingesetzt?

- Hub Pillar 2: SAP Business AI: Lizenzierung, Verbrauch und Governance steuern - Cluster 4: Joule, Skills, Agents und Foundation Models

Ja. Der EU AI Act adressiert den Deployer, also das Unternehmen, das ein AI-System in Betrieb nimmt und nutzt. Ob SAP als technischer Anbieter Processor oder Controller ist, ist eine datenschutzrechtliche Frage und unabhängig von der AI-Act-Verantwortlichkeit. Als Deployer bleiben Sie für Risikoklassifikation, Human Oversight und Dokumentation zuständig.

Nein. SAPs Zertifizierung belegt SAPs Anbieter-Prozesse. Ihre Deployer-Pflichten, darunter Use-Case-Klassifikation, technische Dokumentation und Human Oversight auf Anwendungsebene, müssen Sie selbst dokumentieren und nachweisen können. SAPs Trust-Center-Dokumente sind ein hilfreicher Ausgangspunkt für die Systembeschreibung, ersetzen aber keine eigene Governance-Dokumentation.

Der EU AI Act sieht bei Hochrisiko-Systemen ohne vollständige Dokumentation Bußgelder von bis zu 30 Millionen Euro oder 6 Prozent des weltweiten Jahresumsatzes vor. Wichtiger als die Bußgeldhöhe ist die Signalwirkung: Aufsichtsbehörden können die Nutzung eines nicht-konformen Systems untersagen. Wer bis August 2026 ein strukturiertes, nachvollziehbares Dokumentationsregister vorlegen kann, hat eine deutlich bessere Ausgangslage als jemand, der keine Governance-Schicht aufgebaut hat.

SAPs AI Agent Hub (Q3 2026, auf LeanIX-Basis) bietet Discovery, Verification und Observability für AI-Agenten und ist primär als Compliance-Werkzeug konzipiert. BTP-Audit-Logs sind konfigurierbar und decken die Logging-Pflicht auf Infrastrukturebene ab. Für die Anwendungsdokumentation und das Risk-Management-System gibt es kein SAP-Standardtool: das liegt in der organisatorischen Verantwortung des Kunden.

Ein Joule Skill ist eine deterministische, vordefinierte Einzelaktion: vorhersehbarer Verbrauch, begrenztes Risiko. Ein Joule Agent ist ein autonomes System, das mehrere Skills orchestriert und eigenständig plant. Der Verbrauchsunterschied ist erheblich: Agenten konsumieren laut Praxisbeobachtungen das Drei- bis Zwanzigfache gegenüber reinen Copilot-Deployments (Quelle: SAP Licensing Experts). Diese Unterscheidung sollte bei jeder AI-Unit-Sizing-Diskussion auf der Agenda stehen.

Der Generative AI Hub bietet Zugang zu Foundation Models verschiedener großer Anbieter sowie zu SAP-eigenen Modellen wie SAP-ABAP-1 und SAP-RPT-1. SAP abstrahiert die Modell-API, sodass kein direkter Vertrag mit dem Modellanbieter erforderlich ist. Das richtige Modell hängt vom Use Case ab: SAP-eigene Modelle sind für SAP-spezifische Aufgaben optimiert und günstiger in der Token-Rate. Externe Modelle bieten mehr Flexibilität bei generischen Aufgaben (Quelle: SAP Help Portal, Generative AI Hub).

Das Model Context Protocol ist ein offener Standard, der SAP-Agenten und externe AI-Toolchains verbinden kann. SAP unterstützt MCP seit Q1 2026. Vertraglich relevant ist, dass die SAP API Policy v4/2026 autonome Dritt-AI-Agenten an SAP-APIs nicht erlaubt. Drittpartei-Komponenten dürfen Skills bereitstellen, aber nicht eigenständig agieren. Wer Hybrid-Architekturen plant, sollte diese Grenze im Order Form geklärt haben.

SAP gewährt bis Ende 2026 kostenlosen Design-Time-Zugang zu Joule Studio unter Fair-Use-Bedingungen. Das deckt die Entwicklungsumgebung ab, nicht den produktiven Betrieb. Runtime-Lizenzen für kundeneigene Agenten in Produktion sind separat zu erwerben. Organisationen, die 2026 Agenten in Joule Studio bauen, sollten frühzeitig die Runtime-Kosten für 2027 in die Budgetplanung einbeziehen.

AI-Unit-Kontingente, die im klassischen Prepaid-Modell gekauft werden, verfallen am Ende des Vertragsjahres. PUPM-Request-Kontingente verfallen monatlich. Das ist ein kürzerer Zyklus mit häufigeren Verfall-Ereignissen. Wer PUPM-Pakete kauft und die Adoption langsam hochfährt, verliert Budget nicht einmal im Jahr, sondern jeden Monat.

Nein. Pakete sind lösungsbereichsspezifisch. Finance-Pakete decken Finance-Capabilities ab, Spend-Management-Pakete decken Procurement-Capabilities ab. Paketübergreifendes Pooling ist nicht vorgesehen. Ein Nutzer, der beide Bereiche benötigt, braucht zwei separate Pakete.

Überverbrauch über das Paket-Kontingent hinaus wird aus dem zentralen AI-Unit-Pool des Unternehmens gezogen. Fehlt dort ausreichendes Kontingent, entstehen Overage-Kosten. Das ist ein weiterer Grund, den Paket-Ausschöpfungsgrad und den zentralen AI-Unit-Pool gemeinsam zu beobachten. Ein Steuerungsmoment, der Contract Manager und Controlling gleichermaßen betrifft.

Die Zuordnung ist technisch unbegrenzt. Die kommerzielle Grenze liegt im Request-Pool: Je mehr Nutzer ein Paket teilen, desto geringer ist der durchschnittlich pro Nutzer verfügbare Anteil. Die Paket-Dimensionierung sollte deshalb auf dem erwarteten Nutzungsvolumen basieren, nicht allein auf der Anzahl potenzieller Nutzer.

SAP Business AI ist die Dachmarke für alle AI-Funktionen im SAP-Ökosystem, bestehend aus drei Schichten: Context Layer (AI Foundation, Knowledge Graph, Foundation Models), Build Layer (Joule Studio 2.0 für kundeneigene Agenten) und Governance Layer (SAP AI Agent Hub für Policy und Observability). Darauf aufgesetzt ist Joule als gemeinsames Frontend und die SAP Autonomous Suite mit 224 vorgefertigten Agenten. Jede Schicht hat eigene Lizenzlogiken und Vermessungspunkte.

Seit Juni 2025 gibt es kein RISE with SAP Premium Plus mehr als eigenständigen Tier. Verträge, die diesen Begriff noch enthalten, beziehen sich auf einen abgekündigten Vertragsgegenstand. Welche Capabilities heute in SAP Cloud ERP Private enthalten sind und was als Add-On neu zu beschaffen ist, sollte aktiv geprüft werden, bevor der Vertrag ausläuft oder verlängert wird.

Der kostenlose Design-Time-Zugang zu Joule Studio läuft Ende 2026 aus. Wer in dieser Phase Agenten entwickelt, baut eine technische Abhängigkeit von Runtime-Lizenzen auf, die ab 2027 separat beschafft werden müssen. Die kommerziellen Bedingungen für diese Runtime-Lizenzen sind heute verhandelbar, nach dem Rollout der Agenten erheblich schwieriger zu verhandeln.

Der SAP AI Agent Hub wird im dritten Quartal 2026 generally available. Er ist das zentrale Governance-Werkzeug für Agenten-Inventar, Policies und Compliance-Dokumentation unter dem EU AI Act. Wer keinen Hub einsetzt, muss Agent-Governance manuell aufbauen, was für regulierte Branchen oder Hochrisiko-Use-Cases kaum praktikabel ist.

Nicht im Standard. Ungenutzte AI Units verfallen am Ende des Vertragsjahres. Ein Rollover-Recht von 10 bis 20 Prozent der nicht genutzten AI Units lässt sich in vielen Vertragsverhandlungen einbringen, es ist aber keine Standardbedingung und muss explizit im Order Form verankert sein (Quelle: SAP Licensing Experts, AI Units Explained 2026).

Der Nutzer zahlt für jedes Paket separat. Ungenutzte Kontingente aus einem Paket können nicht auf ein anderes Paket angerechnet werden. Das Cross-Package-Pooling ist in der PUPM-Logik nicht vorgesehen (Quelle: SAP Learning, Analyzing the PUPM Pricing Model).

Immer dann, wenn Joule-Funktionen oder AI-Agenten mit unternehmenseigenem Kontext geerdet werden sollen, sei es über Custom Model Grounding, Company Memory oder den SAP Knowledge Graph. In diesem Moment wird BDC zu einem aktiven Verbrauchstopf, der separat beschafft und gesteuert werden muss.

Es gibt heute kein natives SAP-Tool, das alle drei Töpfe aggregiert und gegen den Vertragsrahmen spiegelt. SAP for Me zeigt aggregierten AI-Unit-Verbrauch, das BTP Cockpit zeigt Capacity-Unit-Verbrauch auf Subaccount-Ebene, das BDC-Cockpit berichtet BDC-Credits. Die Konsolidierung liegt beim Kunden und erfordert eine eigenständige Governance-Funktion.

Ein RISE- oder SAP Cloud ERP Private-Vertrag enthält typischerweise einige eingebettete AI-Features wie Predictive Accounting und Intelligent AP Automation, fixe Transaktions-Quoten zwischen 10.000 und 50.000 AI-Transaktionen pro Monat sowie einen View-Only-Joule-Zugang mit begrenzten Konversations-Sessions. Dieser Basisumfang deckt erste Orientierungsversuche ab. Für produktive AI-Adoption bei realen Nutzerpopulationen sind Joule Power User Seats, zusätzliche AI Units und erweiterte Capability-Pakete als Add-Ons zu beschaffen (Quelle: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

SAP-Standard-Vertragsklauseln sehen vor, dass der AI-Verbrauch über Entwicklungs-, Test- und Produktivumgebungen gemeinsam auf das monatliche Kontingent angerechnet wird. Wer aktive AI-Features in Nicht-Produktivumgebungen betreibt, kann damit höhere Verbräuche erzeugen als geplant. Eine Dev/Test-Exclusion für die AI-Unit-Zählung ist verhandelbar und sollte bei der nächsten Vertragsverlängerung explizit angesprochen werden (Quelle: SAP Licensing Experts).

Sobald das vertraglich fixierte AI-Unit-Kontingent überschritten wird, greift die Overage-Klausel. Bis 20 Prozent über dem Kontingent typischerweise ohne Aufpreis, zwischen 21 und 50 Prozent über Kontingent das 1,5-Fache der Vertragsrate, bei mehr als 50 Prozent das Zwei- bis Vierfache oder Service-Suspendierung. Die genaue Formulierung steht im Order Form. Eine explizite Cap-Vereinbarung und eine Approval-Pflicht gehören in jede AI-Vertragsverhandlung (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts; Redress Compliance, RISE with SAP Tiers 2025).

Die Order-Form-Prüfung ist ein koordinierter Steuerungsmoment zwischen vier Rollen: Contract Manager prüft Vertragsstruktur und Compliance-Klauseln. Procurement bewertet Konditionen und Verhandlungspotenzial. Controlling bewertet Overage-Risiken und Budgetrelevanz. Executive gibt Freigabe für strategische Weichenstellungen wie Vertragstyp-Entscheidungen. Ohne diese Koordination werden einzelne Sektionen, etwa die Aggregation-Scope-Klausel oder Rollover-Regelungen, regelmäßig erst nach Vertragsabschluss entdeckt.

Premium Plus als Tier wurde abgeschafft. Ob ein Bestandsvertrag die ursprünglichen Premium-Plus-Konditionen fortführt oder ob beim Renewal eine Umstellung auf die neue Struktur stattfindet, hängt von den spezifischen Vertragsbedingungen und dem Renewal-Zeitpunkt ab. Wer sich auf bestehende Formulierungen verlässt, ohne das aktuelle Order Form geprüft zu haben, riskiert Lücken in der Planung.

Das lässt sich pauschal nicht beantworten. Manche Bestandskunden haben Joule im Repackaging behalten, andere haben es als Add-On neu verhandelt oder verloren. Die einzige verlässliche Antwort liefert das aktuelle Order Form und der Abgleich mit dem ursprünglichen Vertrag.

Die kommerzielle Effizienz hängt vom Gesamtportfolio ab. Standalone-BTP ist in der Regel das ungünstigste Modell. Das RISE- bzw. Cloud-ERP-Private-Bundle ist bei entsprechenden Volumen kommerziell am vorteilhaftesten, da AI Units dort subventioniert eingepreist sind. Die Entscheidung lässt sich nur auf Basis eines Vergleichs der tatsächlichen Verbrauchsstruktur treffen.

Der letzte sinnvolle Interventionspunkt liegt im Oktober. Bis dahin bleiben zwei bis drei Monate, um den Verbrauch noch zu erhöhen oder mit SAP über eine Vertragsanpassung zu sprechen. Im November sind die Optionen bereits eingeschränkt, im Dezember sind sie es erheblich.

Monatlich, auf Basis der SAP Balance Statements. Daneben gibt es vier operative Prüfpunkte im Jahr mit klaren Entscheidungsaufgaben: Ende Q1 (Baseline), Ende Q2 (Q4-Forecast und Entscheidung), Oktober (Top-Up-Prüfung und Gegenmaßnahmen), Anfang Dezember (Abschluss-Check).

Ungenutzte Credits werden am Ende der Vertragsperiode ohne Ausgleich gestrichen. Der gezahlte Betrag für diese Credits ist nicht rückerstattbar. Eine Vertragsanpassung im Nachgang ist nicht vorgesehen. Einzig eine vertraglich vereinbarte Rollover-Klausel, sofern bei Vertragsabschluss oder Renewal ausgehandelt, kann einen Teil der ungenutzten Credits in die nächste Periode retten.

Ein begrenzter Rollover ist in Vertragsverhandlungen erzielbar, aber kein SAP-Standard. Aus der Praxis sind Rollover-Vereinbarungen von 10 bis 20% der ungenutzten Credits bekannt (Community Knowledge: Rizing, Redress Compliance). Diese Werte sind Erfahrungswerte, keine garantierten Ergebnisse. Eine Rollover-Klausel muss vor Vertragsabschluss oder bei Renewal verhandelt werden, nicht nach dem Verfall.

Im BTP Cockpit lassen sich auf Subaccount-Ebene Nutzungsbenachrichtigungen konfigurieren. Empfohlen werden zwei Schwellenwerte: ein erster Alert bei 70% Verbrauch als Frühwarnung, ein zweiter bei 90% als Signal für sofortige Handlung. Beide Alerts sollten auf Subaccount-Ebene eingestellt sein, nicht nur auf Gesamtvertragsebene, weil Verbrauchsspitzen in spezifischen Subaccounts entstehen, nicht gleichmäßig verteilt.

Für eine belastbare Renewal-Datenbasis benötigen Sie: monatliche Balance Statements über zwölf bis achtzehn Monate, den Verbrauch je Depreciation Group (Group 1 und Group 2), den PUPM-Verbrauch für AI-Units, falls Business AI Services aktiv sind, und eine Aufschlüsselung nach produktiven und nicht-produktiven Subaccounts. Diese Daten liefern die Grundlage für die Credit-Volumen-Kalibrierung und die Overage-Risikoabschätzung der neuen Laufzeit.

Ohne vollständige Zeitreihe ist die Credit-Volumen-Kalibrierung nur auf Basis aktueller Stichtagswerte möglich. Das ist eine lückenhafte Grundlage, weil saisonale Schwankungen und Projektphasen nicht sichtbar sind. In diesem Fall empfiehlt sich eine konservative Hochrechnung auf Basis des verfügbaren Zeitraums, ergänzt um einen sachlich begründeten Puffer. Der strukturierte Ansatz für die nächste Laufzeit beginnt mit der laufenden Archivierung der Balance Statements ab heute.

Group 1 umfasst Basis-Infrastrukturservices mit einem niedrigeren Credit-Verbrauch je Kapazitätseinheit. Group 2 umfasst Advanced- und Integration-Services, die pro genutzter Einheit mehr Credits verbrauchen. Die Zusammensetzung des eigenen BTP-Verbrauchs nach diesen Gruppen zeigt, welcher Anteil auf Infrastruktur entfällt und welcher auf höherwertige Services, und beeinflusst damit die Kalibrierung des Gesamtvolumens für die neue Laufzeit.

BTP-Credits sind Teil des im RISE Enterprise Agreement vereinbarten Gesamtguthabens. Sie werden aus dem Gesamtguthaben gezogen, sodass ein höherer BTP-Verbrauch das für andere Komponenten verfügbare Guthaben reduziert. Diese Wechselwirkung macht die BTP-Zeitreihe zu einem integralen Bestandteil der gesamten Verbrauchsdaten-Auswertung, nicht zu einem separaten Datenstrang.

Ungenutzte Credits verfallen am Ende der Vertragsperiode. Es gibt keinen automatischen Rollover. Der bezahlte Preis bleibt, der Gegenwert ist verloren. Ein begrenzter Rollover ist in Vertragsverhandlungen als Ergebnis erreichbar, aber kein Standardbestandteil. Die wirksamere Steuerungsmaßnahme ist ein quartalsweiser Verbrauchsabgleich, der eine Unterauslastung frühzeitig sichtbar macht (Quelle: SAP FAQ CPEA).

Ja, wenn das vertraglich gesicherte Nachkaufrecht zu Ausgangsbedingungen vorhanden ist. Ohne diese Klausel hängt der Preis eines Top-Ups von der Verhandlungssituation zum Zeitpunkt des Bedarfs ab. Das Nachkaufrecht sollte deshalb bei Vertragsabschluss oder bei der nächsten Renewal explizit verankert werden (Community Knowledge: Rizing, SAP BTP Licensing Models).

Die praktisch bewährte Schwelle liegt bei 70 bis 80 Prozent Credit-Verbrauch. Bei diesem Stand ist noch ausreichend Zeit für eine strukturierte Abstimmung. Wer bis 90 Prozent wartet, hat deutlich weniger Handlungsspielraum. Wer das Kontingent überschreitet, zahlt den Listenpreis ohne Volumenrabatte.

Ein Overage Cap ist eine Vertragsklausel, die festlegt, bis zu welchem Vielfachen des Vertragspreises Overage maximal abgerechnet werden darf. Ein Cap bei 110 Prozent des Listenpreises bedeutet, dass keine Overage-Credits teurer werden als 10 Prozent über dem Listenpreis. Diese Klausel begrenzt das Budget-Risiko in Szenarien mit unerwartetem Verbrauchsanstieg. Sie ist in Vertragsverhandlungen erreichbar, aber kein Standardbestandteil.

Inform stellt vollständige Transparenz über Kosten und Verbrauch her. Optimize setzt aktive Maßnahmen zur Ausrichtung von Verbrauch und Commitment um. Operate verankert beide Aktivitäten als laufenden Governance-Prozess. Die drei Phasen sind kein einmaliger Ablauf, sondern ein iterativer Zyklus.

Die FinOps Foundation hat Licensing seit 2024/2025 als offiziellen Scope aufgenommen. BTP teilt mit Public Cloud die Grundmechanik: variables Verbrauchsmodell, Verbrauchsmetriken, Budget-Allocat ion und Optimierungspotenzial durch aktive Steuerung. SAP-spezifische Mechaniken wie Credit-Verfall und Overage-Abrechnung zum Listenpreis machen die Steuerungsdisziplin sogar anspruchsvoller als bei Standard-IaaS.

Contract Manager, Procurement, Controlling und Executive. Der Contract Manager verantwortet die Vertragskonformität und Renewal-Vorbereitung. Procurement steuert Nachkaufentscheidungen. Controlling verantwortet die monatliche Cost Allocation und Budgetabweichungsanalyse. Executive trifft Freigabeentscheidungen bei größeren Abweichungen.

SAP-Lizenzmanagement in der klassischen Form zielt auf Compliance: sind die genutzten Lizenzen korrekt erfasst und klassifiziert? BTP-FinOps zielt auf Budgetsteuerung: werden Credits so eingesetzt, dass weder Verfall noch ungeplante Overage entsteht? Beide Disziplinen sind komplementär. Für BTP braucht es beide, weil die Credit-Mechanik gleichzeitig eine Compliance- und eine Steuerungsfrage ist.

Die Operate-Phase läuft monatlich (Budget-Tracking, Anomalie-Erkennung, Forecast-Update) und quartalsweise (Quarterly Business Review). Inform und Optimize sind keine Jahresprojekte, sondern laufende Bestandteile des Operate-Rhythmus. Wichtige Steuerungsmomente wie Credit-Commitment-Anpassungen werden vorausschauend auf den Renewal-Termin hin geplant.

Ohne Subaccount-Trennung ist eine direkt verbrauchsbasierte Allokation nicht möglich. Als Übergangslösung ist eine nutzungsbasierte Schlüsselung auf Basis von Transaktionsvolumina oder Nutzeranteilen je Geschäftsbereich ein praktischer Ansatz. Parallel sollte die Subaccount-Struktur für neue Projekte konsequent nach Zurechnungseinheiten aufgebaut werden. Eine nachträgliche Umstrukturierung bestehender Subaccounts ist technisch möglich, erfordert aber Sorgfalt bei der Entitlement-Neuzuweisung (Quelle: SAP Help Portal, Monitoring Usage and Consumption Costs).

Showback macht BTP-Kosten für Kostenstellen und Projekte transparent, ohne interne Buchungen vorzunehmen. Chargeback verrechnet diese Kosten tatsächlich auf die Budgets der Fachbereiche. Showback schafft Kostenbewusstsein, Chargeback schafft Kostenverantwortung. Viele Organisationen beginnen mit Showback und führen Chargeback ein, nachdem intern Akzeptanz für die Kostenstruktur entstanden ist (Quelle: FinOps Foundation, FinOps Framework 2025).

Monatlich, weil die BTP-Balance Statements monatlich geliefert werden und relevante Verbrauchskomponenten auf Monatsbasis abgerechnet werden. Eine quartalsweise Aggregation reicht für Budget-Reviews, erfasst aber keine unterjährigen Verschiebungen, die für Renewal-Vorbereitung oder Overage-Steuerung relevant sind.

Vier Bestandteile sind notwendig: erstens die monatlichen Balance Statements je Subaccount aus dem BTP Cockpit, zweitens der vertraglich fixierte Credit-Preis aus dem Order Form, drittens das Mapping zwischen Subaccounts und internen Kostenstellen oder Projekten, und viertens ein definiertes Freigabe- und Buchungsverfahren für die monatliche Verrechnung. Der aufwändigste Teil ist in der Regel das Mapping, weil es die interne Organisationsstruktur mit der BTP-Architekturentscheidung verbindet (Quelle: SAP Help Portal, Monitoring Usage and Consumption Costs).

Als Übergangslösung bietet sich eine nutzungsbasierte Schlüsselung an: Der Gesamtverbrauch eines Subaccounts wird nach einem vorab vereinbarten Schlüssel aufgeteilt, zum Beispiel nach dem Anteil der aktiven Nutzer je Geschäftsbereich oder dem Anteil der Transaktionsvolumina. Parallel dazu sollten neue BTP-Projekte von Beginn an mit einer sauberen Subaccount-Zuordnung starten. Eine nachträgliche Umstrukturierung bestehender Subaccounts ist technisch möglich, erfordert aber Planung bei der Entitlement-Neuzuweisung (Quelle: SAP Help Portal, Monitoring Usage and Consumption Costs).

Nein. Die richtige Granularität hängt von Ihrer Organisationsgröße und Ihren Controlling-Anforderungen ab. Zu viele Subaccounts erhöhen den Verwaltungsaufwand für Entitlement-Zuweisung und Monitoring. Zu wenige Subaccounts schränken die Allokationspräzision ein. Ein praktikabler Ausgangspunkt für mittelgroße Organisationen ist die Trennung nach Geschäftsbereichen, ergänzt um eine Umgebungstrennung (Produktion, Test, Entwicklung) für die verbrauchsstärksten Projekte.

Der vertraglich fixierte Credit-Preis aus Ihrem Order Form ist die korrekte Grundlage. Der Listenpreis überschätzt die tatsächlichen Kosten systematisch, weil er Volumenrabatte aus dem Enterprise Agreement nicht berücksichtigt. Für die interne Verrechnung sollte der Vertrags-Credit-Preis verwendet werden, damit die internen Kosten die realen Vertragskosten widerspiegeln.

Monatlich, weil die BTP-Balance Statements monatlich geliefert werden. Eine quartalsweise Aggregation reicht für Budget-Reviews, erfasst aber keine unterjährigen Verbrauchsverschiebungen, die für die Steuerung relevant sein können.

Indirect Access war der historische Begriff für jeden Zugriff auf SAP-Daten über Drittsysteme, ohne klare Definition, wann genau eine Lizenzpflicht entstand. Digital Access ist das seit 2018 geltende Nachfolgemodell. Es ersetzt den unpräzisen Zugriffsgedanken durch eine klare Dokumentenlogik: Lizenzpflicht entsteht durch das Erstellen eines der neun definierten Dokumenttypen in SAP, nicht durch den Zugriff als solchen.

Die neun Dokumenttypen sind: Sales Order Items, Purchase Order Items, Service Order Items, Manufacturing Order Items, Invoice Items (Billing/AR), Payment Items (Incoming Payments), Goods Movement Items, Journal Entries und Inbound Delivery Items. Diese Liste ist abschließend.

Für interne Integrationen im Geltungsbereich des Enterprise Agreements ist Digital Access in RISE-Verträgen häufig unbegrenzt inkludiert. "Intern" ist dabei vertragsabhängig definiert. Externe Systeme, Kunden-Portale, Lieferanten-Plattformen und IoT-Integrationen fallen in der Regel nicht unter diese Inklusion. Der Vertragstext, konkret das Digital Access Supplement, ist die maßgebliche Referenz.

Named User ist in der Regel wirtschaftlich überlegen, wenn die Nutzer des Drittsystems bekannt, identifizierbar und in begrenzter Anzahl vorhanden sind. Bei wenigen internen Mitarbeitern, die über ein externes Tool SAP-Buchungen auslösen, ist Named User oft der einfachere Weg. Bei anonymen Nutzern, hohem Transaktionsvolumen oder automatisierten Prozessen ist Document-Based Licensing überlegen.

Das Digital Access Adoption Program ist ein freiwilliges SAP-Programm, das den Wechsel von historischen Indirect-Access-Verpflichtungen auf Document-Based Licensing ermöglicht. Es ist formal ein Amendment zum bestehenden SAP-Vertrag. Bestandskunden mit Verträgen, die vor 2019 abgeschlossen wurden, haben das DAAP möglicherweise noch nicht abgeschlossen. Ein Abschluss ist nicht zwingend erforderlich, schafft aber Planbarkeit und Audit-Schutz.

Es hängt von der Konfiguration ab. SAP hat für eigene IRPA-Bots (Typ 68) und zertifizierte Drittanbieter-RPA-Bots (Typ 69) kostenlose Lizenzkategorien definiert. Bots, die korrekt unter diese Kategorien klassifiziert sind, lösen keine Digital-Access-Pflicht aus. Bots außerhalb dieser Kategorien oder mit anderen Authentifizierungsmodellen können Dokument-Items in SAP erstellen und damit eine Lizenzpflicht auslösen. Jeder RPA-Einsatz sollte vor dem produktiven Rollout auf Digital-Access-Relevanz geprüft werden.

Static Read beschreibt den ausschließlich lesenden Zugriff eines Drittsystems auf SAP-Daten, ohne dass das System etwas in SAP zurückschreibt oder erstellt. Da Digital Access am Erstellen von Dokumenten ansetzt und nicht am Lesen, entsteht bei reinem Datenlesen keine Lizenzpflicht. Ein Dashboard, das SAP-Daten ausliest und visualisiert, ohne Buchungen zu erstellen, fällt daher unter Static Read und ist lizenzrechtlich unproblematisch.

Im Enhanced Audit fordert SAP eine vollständige Liste aller Drittsysteme mit SAP-Schnittstellen an. Transaktionslogs und Dokumentvolumina werden analysiert. Systeme, die Dokument-Items in SAP erstellen, ohne Named-User-Lizenz oder DAAP-Supplement als Grundlage zu haben, werden als Compliance-Lücken markiert und können retroaktive Nachforderungen auslösen.

Die Export-Regel besagt: Wenn ein lizenzierter SAP-Nutzer einen automatisierten Prozess definiert und initiiert hat, der anschließend automatisch läuft, entsteht für die automatische Ausführung keine zusätzliche Digital-Access-Pflicht. Die Bedingung ist, dass der lizenzierte Nutzer den Prozess eingerichtet hat und die Berechtigung im Kontext dieses Nutzers liegt. Bei komplexen Multi-Step-Workflows, die über mehrere Systemgrenzen laufen, ist die Anwendung der Export-Regel nicht immer eindeutig und sollte vertraglich geklärt werden.

Das Integrationsregister ist das zentrale Werkzeug. Es erfasst für jede Schnittstelle: das externe System, die Kommunikationsrichtung, die erzeugten Dokumenttypen, das monatliche Volumen, die Nutzerbasis und die Lizenzgrundlage (Named User, Digital Access Supplement oder Ausnahme). Dieses Register sollte als lebendes Dokument geführt werden, das bei neuen Integrationen aktualisiert und quartalsweise auf Vollständigkeit geprüft wird.

Ja. Wenn das im DAAP-Amendment vereinbarte Dokumentkontingent überschritten wird, greift die Overage-Regelung des Order Forms. Die konkrete Overage-Rate ist vertragsabhängig. Eine Deckelung der Overage ist verhandelbar, aber kein Bestandteil der SAP-Standardbedingungen. Ein konkretes Overage-Cap sollte in jeder Digital-Access-Verhandlung adressiert werden.

Drei Fragen sind relevant. Erstens: Welche Integrationen existieren in Ihrem Bestand, und welche Dokumenttypen erzeugen sie? Zweitens: Sind diese Integrationen über Named User oder über eine andere Lizenzgrundlage abgedeckt? Drittens: Ist das DAAP-Programm für Ihren Bestand eine wirtschaftlich sinnvolle Option? Ein Vertragscheck klärt diese Fragen systematisch und liefert eine belastbare Ausgangssituation für die nächste Renewal-Verhandlung.

Das hängt vom Umfang der Integrationslandschaft ab. Unternehmen mit zehn bis zwanzig Integrationen können die Schritte 1 bis 6 in wenigen Wochen abarbeiten. Bei komplexen Portfolios mit mehreren ERP-Systemen, internationalen Gesellschaften und umfangreichem RPA-Einsatz ist eine strukturierte Bestandsaufnahme ein mehrmonatiges Projekt. Das spricht dafür, die Schritte nicht als einmaliges Projekt zu behandeln, sondern im laufenden Steuerungsrhythmus zu verankern.

Zunächst intern abstimmen: IT, Einkauf und Legal sollten koordiniert vorgehen, bevor die erste Antwort an SAP geht. Dann den Scope der Einladung prüfen: Welche Systeme und Zeiträume sind benannt? Danach mit dem Integrationsregister (Schritt 9) den eigenen Stand einschätzen und Lücken identifizieren, die vor der Datenübergabe an SAP noch bearbeitet werden können.

Die SAP General Terms and Conditions verpflichten zur Mitwirkung an der Messung für Systeme im Vertragsscope. Systeme außerhalb des Geltungsbereichs und vertraglich ausgenommene Umgebungen sind nicht automatisch Teil des Audits. Was genau geliefert werden muss, ergibt sich aus dem spezifischen Vertragstext. Bei Unklarheiten über den Scope empfiehlt sich eine rechtliche Einschätzung vor der Datenübermittlung.

Eine selbst identifizierte und proaktiv geschlossene Lücke ist eine deutlich stärkere Verhandlungsposition als ein SAP-Finding. Wenn die Zeit reicht, vor der Datenübergabe ein DAAP-Amendment abzuschließen oder Named-User-Lizenzen nachzukaufen, verbessert das die Ausgangslage erheblich. Wenn die Zeit nicht reicht, ist zumindest die interne Dokumentation und eine belegte Einschätzung des Exposures ein sinnvoller Ausgangspunkt für die Verhandlungsphase.

SAP sendet eine formelle Audit-Benachrichtigung mit Scope, Timeline und Ansprechpartner. Der Kunde führt USMM in allen relevanten Produktivsystemen durch und konsolidiert die Ergebnisse über LAW (SLAW2). Beim Enhanced Audit fordert SAP zusätzlich Informationen zur Integrationslandschaft und analysiert Transaktionslogs aktiv. Der Prozess dauert für komplexe Umgebungen typischerweise drei bis sechs Monate. Die SAP-Audit-Abteilung (Global License Auditing) präsentiert anschließend ein Ergebnis mit identifizierten Compliance-Lücken. Darauf folgt eine Verhandlungsphase.

USMM (User and System Measurement Management) ist ein SAP-Standardprogramm (Transaktion USMM), das in jedem SAP-System verfügbar ist. Es misst Named-User-Zahlen und Engine-Metriken pro Einzelsystem. Die Ergebnisse werden als Messdatei exportiert und in LAW (SLAW2) systemübergreifend konsolidiert. Der konsolidierte Report ist das Dokument, das an SAP übermittelt wird. USMM zählt alle Named User, unabhängig davon, ob sie aktiv sind. Inaktive Accounts und Duplikate erhöhen die gemessene Zahl künstlich.

SAP markiert das betroffene System als Compliance-Lücke und beziffert das Exposure: Nachkauf der fehlenden Dokument-Kontingente zum aktuellen Listenpreis, retroaktive Lizenzgebühren für den Prüfzeitraum (typischerweise zwei bis drei Jahre) und Back-Maintenance. Das Finding wird als Ausgangspunkt für eine Verhandlung über den True-Up-Umfang verwendet. Jedes Finding kann intern bewertet und bei Bedarf angefochten werden, wenn die eigene Dokumentation eine andere Einschätzung stützt.

Die Verpflichtung zur Mitwirkung an der jährlichen Messung ist in den SAP General Terms and Conditions verankert. Eine vollständige Verweigerung ist vertragswidrig. Der Scope der Verpflichtung ist jedoch durch den Vertrag begrenzt. Systeme außerhalb des Vertragsscopes und vertraglich ausgenommene Umgebungen (Testsysteme, Sandboxes) sind nicht automatisch Bestandteil des Audits.

Vor dem nächsten Renewal-Gespräch und vor dem nächsten Enhanced Audit. Idealerweise ist die Bereinigung kein separates Projekt, sondern Teil des laufenden Steuerungsrhythmus: Integrationsregister pflegen, neue Integrationen vor Go-Live prüfen, DAAP-Amendment abschließen oder Named-User-Lizenzierung für identifizierte Lücken nachholen. Je früher eine Lücke geschlossen wird, desto geringer ist das rückwirkende Exposure bei einem späteren Audit.

Für interne Integrationen im Geltungsbereich des Enterprise Agreements ist Digital Access in RISE-Verträgen häufig unbegrenzt inkludiert. "Vollständig" trifft es jedoch nicht: Externe Systeme, Kunden-Portale, Lieferanten-Plattformen und IoT-Integrationen fallen in der Regel nicht unter diese Inklusion. Der Vertragstext ist die maßgebliche Referenz.

"Intern" bezeichnet im Digital-Access-Supplement typischerweise den direkten Vertragspartner und seine eigenen Systeme. "Affiliate" ist eine davon getrennte Kategorie für verbundene Gesellschaften, die im Vertrag explizit eingeschlossen sein müssen. Ob Konzerngesellschaften als Affiliates gelten und ob Affiliates von der EA-Inklusion erfasst sind, ist vertragsabhängig.

Ja. Die RISE-Migration überführt nicht automatisch die Lizenzgrundlagen aus dem On-Premise-Vertrag. Integrationen, die auf Named User oder historischen Indirect-Access-Regelungen basierten, benötigen eine neue Bewertung im RISE-Vertragskontext. Besonders bei einem Middleware-Wechsel, zum Beispiel von SAP PI auf BTP Integration Suite, kann sich das Digital-Access-Profil einer Integration verändern.

Für externe Integrationen außerhalb der EA-Inklusion fehlt dann die vertragliche Grundlage für Document-Based Licensing. Diese Integrationen befinden sich in einem lizenzrechtlichen Graubereich. Im Enhanced Audit kann SAP diese Lücke identifizieren und retroaktive Nachforderungen geltend machen. Ein DAAP-Amendment kann nachträglich abgeschlossen werden und schließt typischerweise auch eine Retrospektiv-Bereinigung ein.

Indirect Access war der historische Begriff für alle Zugriffe auf SAP über Drittsysteme, ohne klare Definition, wann eine Lizenzpflicht entstand. Digital Access ist das seit 2018 geltende Nachfolgemodell. Es ersetzt die vage Zugriffslogik durch ein dokumentenbasiertes Modell: Lizenzpflicht entsteht durch das Erstellen eines der neun definierten Dokumenttypen in SAP, nicht durch den Zugriff als solchen.

Das Digital Access Adoption Program ist ein freiwilliges SAP-Programm, das den formalen Übergang von historischen Indirect-Access-Verpflichtungen auf Document-Based Licensing ermöglicht. Es schließt als DAAP-Amendment und Digital Access Supplement an den bestehenden Vertrag an und ermöglicht eine retrospektive Bereinigung historischer Compliance-Lücken. Bestandskunden, deren Verträge aus der Zeit vor 2019 stammen, haben das Programm möglicherweise noch nicht abgeschlossen.

Das Programm ist freiwillig. Es schafft jedoch Planbarkeit und Audit-Schutz für die abgedeckten Dokumenttypen. Bestandskunden ohne DAAP-Supplement operieren in der historischen Indirect-Access-Grauzone, die bei einem Enhanced Audit zu Nachforderungen führen kann. Ob das DAAP wirtschaftlich sinnvoll ist, hängt vom Integrationsbestand und dem Verhältnis zwischen Nutzerbasis und Dokumentvolumen ab.

Ja. Named User bleibt ein gleichwertiger Lizenzweg für Drittanbieter-Zugriffe. Für Szenarien mit wenigen, identifizierbaren Nutzern ist es oft der einfachere Weg. Document-Based Licensing ist wirtschaftlich überlegen bei anonymen Nutzern, hohem Transaktionsvolumen oder vollständig automatisierten Prozessen.

Die neun Dokumenttypen sind: Sales Order Items, Purchase Order Items, Service Order Items, Manufacturing Order Items, Invoice Items (Billing/AR), Payment Items (Incoming Payments), Goods Movement Items, Journal Entries und Inbound Delivery Items. Diese Liste ist abschließend. Dokumente außerhalb dieser neun erzeugen keine Digital-Access-Pflicht.

Drei Bedingungen müssen gleichzeitig erfüllt sein: Das Drittsystem erstellt über eine SAP-Schnittstelle eines der neun definierten Dokumenttypen in SAP. Der Nutzer des Drittsystems hat keine Named-User-Lizenz für SAP. Das Drittsystem handelt nicht im Rahmen einer anerkannten Ausnahme (Static Read, Export-Regel).

Pro Dokument-Item. Die Metrik ist das Volumen der erstellten Positionen, nicht die Anzahl der Schnittstellen oder Systeme. Ein Purchase Order mit zehn Positionen erzeugt zehn lizenzpflichtige Items.

Nein. Wenn ein Drittsystem ausschließlich SAP-Daten liest, ohne Dokument-Items zu erstellen, entsteht keine Digital-Access-Lizenzpflicht. Das nennt SAP Static Read.

Nicht zwingend. SAP hat für eigene IRPA-Bots (Typ 68) und zertifizierte Drittanbieter-RPA-Bots (Typ 69) kostenlose Lizenzkategorien definiert. Korrekt klassifizierte Bots dieser Typen erzeugen keine Digital-Access-Pflicht. Bots außerhalb dieser Kategorien müssen gesondert bewertet werden.

Bei Named User werden die Nutzer des Drittsystems als SAP-Nutzer lizenziert. Bei Document-Based Licensing wird das Dokumentvolumen lizenziert. Named User eignet sich für wenige, identifizierbare Personen. Document-Based Licensing ist bei vielen, anonymen oder automatisierten Zugriffen wirtschaftlich überlegen.

Das hängt von der Größe des Portfolios ab. Für kleinere Integrationslandschaften mit unter zwanzig Schnittstellen ist ein strukturiertes Tabellenformat ausreichend. Für größere Portfolios oder solche mit häufigen Änderungen empfiehlt sich ein dediziertes Governance-Werkzeug, das Versionshistorie, Statusänderungen und Volumentrends abbilden kann. Das Format ist nachrangig. Entscheidend ist, dass es konsistent gepflegt wird.

Die Genauigkeit sollte ausreichen, um Overage-Risiken zu erkennen und DAAP-Kontingente zu verhandeln. Exakte tagesaktuelle Werte sind nicht erforderlich. Monatsdurchschnitte auf Basis eines zwölf-Monats-Zeitraums sind eine belastbare Grundlage. Wichtiger als Präzision auf Einzelintegrations-Ebene ist die Vollständigkeit des Registers.

In der Praxis liegt die Verantwortung an der Schnittstelle zwischen IT-Architektur, Contract Management und Procurement. Die IT liefert die technischen Informationen zu Schnittstellen und Volumina. Contract Management bewertet den Lizenzstatus. Procurement stellt sicher, dass Lizenzentscheidungen in Vertragsveränderungen überführt werden. Ohne klare Eigentümerschaft wird das Register nicht gepflegt.

Ja. Der Vertragscheck schließt die Erhebung und Bewertung des Integrationsbestands ein. Im Rahmen des Managed-Service-Modells (Wir steuern) wird das Integrationsregister als Teil des Steuerungsrhythmus laufend geführt und bei Renewal und Audit eingesetzt.

Für interne Integrationen im definierten Geltungsbereich des Enterprise Agreements ist Digital Access häufig unbegrenzt inkludiert. Vollständig trifft es nicht: Externe Systeme, Kunden- und Lieferantenportale, extern betriebene SaaS-Plattformen und IoT-Umgebungen außerhalb des EA-Scopes fallen in der Regel heraus. Der Vertragstext, konkret das Digital Access Supplement, ist die maßgebliche Referenz.

"Intern" bezeichnet im Digital-Access-Supplement typischerweise den direkten Vertragspartner und seine eigenen Systeme. "Affiliate" ist eine davon getrennte Kategorie für verbundene Gesellschaften. Ob Konzerngesellschaften als Affiliates gelten und ob Affiliates von der EA-Inklusion erfasst sind, ist vertragsabhängig. Affiliate-Klauseln variieren erheblich zwischen Vertragsversionen.

Ja. Die RISE-Migration überführt die Lizenzgrundlagen aus dem On-Premise-Vertrag nicht automatisch. Integrationen, die auf Named User oder historischen Indirect-Access-Regelungen basierten, benötigen eine neue Bewertung im RISE-Vertragskontext. Besonders bei einem Middleware-Wechsel kann sich das Digital-Access-Profil einer Integration verändern.

Für externe Integrationen außerhalb der EA-Inklusion fehlt dann die vertragliche Grundlage für Document-Based Licensing. Diese Integrationen befinden sich in einem lizenzrechtlichen Graubereich. Im Enhanced Audit kann SAP diese Lücke identifizieren. Ein DAAP-Amendment kann nachträglich abgeschlossen werden und schließt typischerweise auch eine Retrospektiv-Bereinigung ein.

Nein. Digital Access entsteht nur, wenn ein Drittsystem über eine SAP-Schnittstelle einen der neun definierten Dokumenttypen in SAP erstellt. Systeme, die SAP-Daten nur lesen (Static Read), lösen keinen Steuerungsmoment aus.

Für interne Systeme, also Systeme desselben juristischen Vertragspartners, enthält das RISE Enterprise Agreement häufig unbegrenzte Digital-Access-Rechte. Externe Systeme, Partnerportale, Kunden-Integrationen und IoT-Plattformen fallen in der Regel nicht darunter. Was "intern" im Einzelfall bedeutet, ist vertragsabhängig definiert.

Ja. RPA-Systeme haben strukturell keinen Named User. Wenn ein Bot über eine SAP-Schnittstelle Dokumente erstellt (Rechnungen, Journal Entries, Bestellungen), entsteht eine Digital-Access-Pflicht. Document-Based Licensing über ein DAAP-Supplement ist der reguläre Weg.

SAP stellt für das DAAP-Programm ein Measurement Tool zur Verfügung, das das historische Dokumentvolumen pro Dokumenttyp und Quelle misst. Ergänzend lässt sich über SAP-Transaktionslogs und Middleware-Protokolle eine Analyse aufbauen.

Ariba-Transaktionsgebühren sind Ariba-Network-spezifische Gebühren für den Dokumentaustausch auf dem Ariba-Netzwerk. Digital Access ist die SAP-seitige Lizenzpflicht für das Erstellen von Dokumenten in SAP. Beides kann gleichzeitig anfallen. Ob Ariba-Integrationen unter die RISE-EA-Inklusion fallen, ist vertragsabhängig zu prüfen.

Strukturierte Vorbereitung beginnt spätestens 18 Monate vor Vertragsende. Grund: Die Datenbasis, die für eine fundierte Verhandlungsposition benötigt wird, lässt sich nicht kurzfristig aufbauen. Verbrauchszeitreihen über 12 bis 18 Monate, vollständige Vertragsdokumentation, Stakeholder-Ausrichtung und Klausel-Review erfordern Vorlaufzeit. Darüber hinaus beginnt SAP den Renewal-Dialog auf seiner Seite typischerweise 12 bis 18 Monate vor Laufzeitende. Wer später beginnt, trifft auf einen bereits strukturierten Counterpart.

Der Vertrag verlängert sich automatisch zum Ende der Laufzeit, typischerweise um die ursprüngliche Vertragsdauer. SAP darf den Preis für die neue Periode erhöhen, sofern die Erhöhung mindestens 45 Tage vor Verlängerungsbeginn angekündigt wurde. Eine Nachverhandlung ohne Neu-Opening ist nicht möglich. Das Kündigungsrecht des Kunden bleibt auch bei Verlängerung bestehen, sofern SAP eine Preiserhöhung ankündigt.

Vier Datenkategorien: Verbrauchsdaten (FUE-Auslastung je User-Typ, BTP-Credit-Verlauf, CAS-Nutzung), Vertragsdaten (Schedule 5, Balance Statements, Sondervereinbarungen), Marktdaten (öffentliche DSAG-Berichte, spezialisierte Quellen) und Qualitätsdaten (SLA-Compliance, Ticket-Volumen, ungelöste Eskalationen). Wer alle vier Kategorien vollständig hat, kann jede Frage zu Volumen, Preis und Klausel sachlich beantworten.

SAP muss eine beabsichtigte Preiserhöhung für die Renewal-Periode mindestens 45 Tage vor dem Verlängerungsbeginn ankündigen (Schedule 5). Bei verspäteter Ankündigung gilt die Erhöhung erst für die übernächste Verlängerungsperiode. Der Kunde hat nach Eingang der Ankündigung das Recht zur ordentlichen Kündigung. Dieses Fenster ist ein strukturierter Steuerungsmoment: Wer es kennt, kann proaktiv positionieren.

Ja, mit den vertraglich definierten Einschränkungen. Cloud-Managed-Services und Cloud-Software haben eine Mindestlaufzeit von sechs Monaten, CAS-Pakete zwölf Monate. In den letzten sechs Monaten vor Vertragsende lassen sich keine neuen Managed-Service- oder Software-Subskriptionen mehr einbuchen, in den letzten zwölf Monaten keine neuen CAS-Einheiten. Third-Party-Software ist generell nicht dekommissionierbar. Volumenanpassungen müssen vor den jeweiligen Sperrfristen abgeschlossen sein.

CPI-Klauseln regeln, in welchem Umfang Preisanpassungen bei Renewal zulässig sind. Der öffentlich kommunizierte Rahmen in Schedule 5 sieht eine maximale Erhöhung von 3,3 Prozent pro Verlängerungszeitraum vor. Die genaue Klauselformulierung im individuellen Vertrag, Referenzindex, Berechnungszeitraum, Cap-Formulierung, bestimmt den tatsächlichen Anpassungsspielraum. Eine Wechselwirkung besteht mit dem Guthaben-Reduktions-Mechanismus: Bei Volumenreduktion darf SAP nach Standardbedingungen den Rabatt anpassen.

Restguthaben am Ende der Vertragslaufzeit verfällt vollständig. Der degressive Roll-Over-Mechanismus erlaubt in den Vorjahren einen Teil des Guthabens zu übertragen (30 Prozent im ersten Jahr, 20 Prozent im zweiten, 10 Prozent ab dem dritten Jahr), im letzten Jahr ist der Roll-Over ausgeschlossen. Diese Mechanik ist ein struktureller Grund, warum die Guthaben-Planung im vorletzten Vertragsjahr beginnen muss, nicht im letzten.

Die vier Rollen des SAP-Vertrags-Steuerungsmodells: Contract Manager (ab M-18, Fristenhüter und Klausel-Review), Procurement (ab M-12, Verhandlungsführung und Budget-Mandat), Controlling (ab M-12, Verbrauchsauswertung und Budget-Szenarien) und Executive (ab M-12, strategische Entscheidung und Freigabe des Verhandlungsrahmens). Das Stakeholder-Team sollte spätestens in Phase 2 formell konstituiert sein.

Exit-Rechte regeln die Bedingungen für eine Vertragsbeendigung, einschließlich Fristen, Datenmitnahme und Kosten. Der beste Zeitpunkt zur Verhandlung ist das Renewal: Wer Exit-Optionen im Renewal adressiert, muss sie nicht nachträglich über ein Amendment einbringen. Aktiv zu verhandeln sind insbesondere Datenportabilität in standardisierten Formaten, Übergangsfristen nach Vertragsende und die Kostentragung bei Exportleistungen.

BTP-Credit-Daten liefern das granulare Bild der Cloud-Plattform-Nutzung unterhalb der FUE-Ebene. Eine Zeitreihe über 12 bis 18 Monate mit Projektzuordnung und Kostenstellenstruktur ist die Mindestanforderung. Aus dieser Zeitreihe lässt sich das Credit-Volumen für die nächste Laufzeit kalibrieren, das Overage-Risiko quantifizieren und der AI-Unit-Bedarf hochrechnen, falls eine Erweiterung der Business-AI-Nutzung geplant ist. BTP-Daten sind damit direkt verwertbarer Verhandlungs-Input, nicht nur internes Reporting.

Schedule 5 legt den formalen Rahmen fest: bis zu 3,3 Prozent Erhöhung pro Verlängerungszeitraum, Ankündigungspflicht 45 Tage vor Verlängerungsbeginn. Die CPI-Klausel im engeren Sinne ist die individuelle Formulierung im Order Form oder Amendment, die festlegt, ob und wie dieser Rahmen durch einen Referenzindex, einen spezifischen Cap oder einen anderen Berechnungsmechanismus modifiziert wird. Beides zusammen ergibt das vollständige Bild.

Auf Basis von Schedule 5 ist 3,3 Prozent die vorgesehene Obergrenze pro Verlängerungszeitraum. Ob der eigene Vertrag davon abweicht, zum Beispiel durch eine individuelle Klausel im Order Form, ist im jeweiligen Vertragsdokument zu prüfen. Für die Planung gilt: Schedule 5 ist der öffentlich dokumentierte Standard.

Eine nicht fristgerechte Ankündigung hat eine klare Konsequenz: Die angekündigte Erhöhung gilt erst für die übernächste Verlängerungsperiode, nicht für die unmittelbar folgende. Wer die Ankündigungsfrist überwacht, hat hier einen Steuerungsmoment.

Bei Guthabenreduktion darf SAP nach Standardbedingungen den Rabatt anpassen, der auf Basis des ursprünglichen Volumens gewährt wurde. Das bedeutet: Wer beim Renewal weniger Volumen einbucht, kann eine Rabattanpassung erleben, die additiv zur CPI-Erhöhung wirkt. Wer beide Mechanismen isoliert betrachtet, unterschätzt die Gesamtpreiswirkung der neuen Laufzeit.

In Phase 3 des Renewal-Prozesses, das heißt neun bis sechs Monate vor Vertragsende. Zu diesem Zeitpunkt wird der Klausel-Review aller sechs kritischen Klausel-Bereiche durchgeführt: Preisanpassungsklausel, Auto-Renewal-Klausel, SLA-Struktur, Exit-Rechte, Divestiture-Klausel und Subskriptions-Flexibilität. Das Ergebnis dieses Reviews ist das Klausel-Delta, das in die Verhandlungsposition einfließt.

Nach Vertragsende ist SAP gemäß Data Processing Agreement (Schedule C) verpflichtet, personenbezogene Daten zurückzugeben oder zu löschen. Für Betriebsdaten und Konfigurationsdaten, die nicht unter das DPA fallen, gelten die vertraglich vereinbarten Regelungen. Ohne explizite Übergangsfrist-Klausel besteht kein automatisches Recht auf verlängerten Datenzugang.

Eine Übergangsphase mit definiertem Zugriff, Umfang und Kostentragung ist grundsätzlich verhandelbar. Der Renewal-Zeitpunkt ist dafür der geeignete Moment. Was konkret vereinbart werden kann, hängt von der eigenen Verhandlungsposition und den spezifischen Anforderungen ab.

Der SAP Data Export Service ermöglicht den strukturierten Export von Kundendaten aus SAP-Systemen. Für einen belastbaren Exit-Plan ist entscheidend, welche Daten in welchem Format exportiert werden und in welchem Umfang diese für eine Weitermigration nutzbar sind. Diese Punkte sollten vertraglich definiert sein, nicht erst im Bedarfsfall geklärt werden.

Ja. Exit-Klauseln definieren den Handlungsspielraum für die gesamte Vertragslaufzeit und darüber hinaus. Unternehmen, die Exit-Optionen dokumentiert haben, verhandeln Folgekontrakte mit einer anderen Ausgangssituation als Unternehmen, für die ein Wechsel technisch und rechtlich kaum darstellbar wäre. Die Nutzung dieser Optionen ist eine separate Entscheidung.

Es gibt keine einzelne Klausel, die für alle Unternehmen gleich relevant ist. Die Preisanpassungsklausel ist zentral, weil sie die Kostenentwicklung der nächsten Laufzeit direkt beeinflusst. Die Auto-Renewal-Klausel ist operativ kritisch, weil ihr Versäumnis keine Korrekturmöglichkeit kennt. Welche Klausel für das eigene Unternehmen im Vordergrund steht, hängt von der aktuellen Vertragssituation, den geplanten Veränderungen und der Unternehmenssituation ab.

SAP-Standardverträge sind der Ausgangspunkt, nicht die Grenze. Was in einem individuellen Vertrag vereinbart wird, hängt vom Verhandlungsgespräch und der eigenen Position ab. Eine fundierte Datenbasis, eine klar formulierte Klausel-Delta-Analyse und ausreichend Vorlaufzeit sind die Voraussetzungen dafür, dieses Gespräch strukturiert zu führen.

Sie verlängern den Status quo. Das muss kein Problem sein, wenn der aktuelle Stand dem eigenen Bedarf entspricht. Wo Lücken bestehen, etwa bei Datenportabilität oder Übergangsfristen nach Vertragsende, sind sie nach dem Renewal strukturell schwieriger zu adressieren als davor.

Der erste Schritt ist eine vollständige Vertragsdokumentation: Order Form, alle Schedules, alle Amendments. Die in diesem Artikel beschriebenen Klauseln befinden sich in der Regel in Schedule 5 (Preisanpassung, Auto-Renewal), Schedule B und D (SLA und Credits), Schedule C (DPA und Exit) sowie in der Order Form selbst (Sondervereinbarungen, Mindestlaufzeiten, Sperrfristen).

Vier Kategorien bilden die vollständige Datenbasis: Verbrauchsdaten (FUE-Auslastung je User-Typ, BTP-Credit-Verlauf, CAS-Nutzung, Cloud-Managed-Services gegen eingekauftes Volumen), Vertragsdaten (Schedule 5, Balance Statements, Sondervereinbarungen), Marktdaten (öffentliche Branchenquellen, DSAG-Berichte) und Qualitätsdaten (SLA-Compliance, Ticket-Volumen, ungelöste Eskalationen). Eine fundierte Verhandlungsposition erfordert alle vier Kategorien.

Die Datenbasis lässt sich nicht kurzfristig aufbauen. Verbrauchszeitreihen über zwölf bis achtzehn Monate, vollständige Vertragsdokumentation und eine koordinierte Datenlieferung über mehrere Unternehmensfunktionen erfordern einen Vorlauf von mindestens achtzehn Monaten. Wer diesen Vorlauf nicht hat, beginnt das Renewal mit lückenhafter Grundlage.

Shelfware bezeichnet Komponenten, für die Guthaben aufgewendet wird, ohne dass der vereinbarte Nutzungsumfang ausgeschöpft wird. Die Identifikation von Shelfware ist Grundlage für zwei Renewal-Szenarien: Volumenreduktion auf Basis belegter Unternutzung oder Aktivierungsplanung für bisher ungenutztes Potenzial. Beide Optionen erfordern eine dokumentierte Verbrauchshistorie.

Im RISE Enterprise Agreement liegt die Pflicht zur Meldung von Übernutzung beim Kunden. Verbrauch über das vereinbarte Guthaben hinaus muss gemeldet werden, bevor er eintritt. Nicht gemeldete Übernutzung wird mit einem 15-prozentigen Aufschlag auf die reguläre Verbrauchsgebühr fakturiert, und für die Übernutzungsphase gilt keine SLA-Garantie.

Datenbasis und Verhandlungstaktik sind keine Alternativen, sondern ergänzende Ebenen. Verhandlungstaktik ohne belastbare Datenbasis ist auf die Überzeugungskraft der Argumentation angewiesen. Eine vollständige Datenbasis ermöglicht, jede Frage zu Volumen, Preis und Klausel sachlich zu beantworten, unabhängig von der taktischen Gesprächsführung des Counterparts.

Contract Manager, Procurement, Controlling und Executive. Jede Rolle verantwortet eine spezifische Dimension des Renewal-Prozesses: Fristensteuerung und Klausel-Review (Contract Manager), Budget-Mandat und Verhandlungsführung (Procurement), Verbrauchsauswertung und Budget-Szenarien (Controlling), strategische Entscheidung und Rahmen-Freigabe (Executive). Fehlt eine Rolle, entsteht eine Entscheidungslücke, die in der Verhandlungsphase sichtbar wird.

Spätestens 12 Monate vor Vertragsende (M-12). Der Contract Manager tritt bereits bei M-18 aktiv in den Prozess ein. Das vollständige Team wird bei M-12 formell konstituiert: Verantwortlichkeiten dokumentiert, Kommunikationsrhythmus etabliert, Datenbedarf je Rolle definiert. Wer das Team erst bei M-6 zusammenstellt, verliert die Vorlaufzeit für Szenario-Analyse, Klausel-Review und Budget-Planung.

Procurement geht in das SAP-Gespräch ohne freigegebenen Verhandlungsrahmen. Entscheidungen müssen während der Verhandlung eingeholt werden, was Tempo verlangsamt und Informationsasymmetrien entstehen lässt. Die strategische Weichenstellung für die nächste Laufzeit erfolgt unter Zeitdruck, statt als vorbereitete Entscheidung.

Ja, insbesondere in kleineren Organisationen. Was nicht sinnvoll kombiniert wird: Verhandlungsführung (Procurement) und Freigabe des Verhandlungsrahmens (Executive) in derselben Person. Diese Trennung stellt sicher, dass der Verhandlungsführer einen klaren Auftraggeber und ein definiertes Mandat hat.

Phase 2, also zwischen M-12 und M-9. In dieser Phase ist die Datenbasis aufgebaut, die Szenarien werden definiert, und ein unabhängiger Blick auf die eigene Vertragsposition ist noch handlungsrelevant. Externe Expertise, die erst in der Verhandlungsphase (M-6 bis M-0) eingebunden wird, hat keine Zeit mehr, eine eigene Analyse aufzubauen.

Spätestens 18 Monate vor Vertragsende. Grund: Die Datenbasis, die für eine fundierte Verhandlungsposition benötigt wird, lässt sich nicht kurzfristig aufbauen. Verbrauchszeitreihen über 12 bis 18 Monate, vollständige Vertragsdokumentation und Stakeholder-Ausrichtung erfordern Vorlaufzeit. Darüber hinaus beginnt SAP den Renewal-Dialog auf seiner Seite typischerweise in diesem Fenster.

Der Vertrag verlängert sich automatisch, typischerweise um die ursprüngliche Vertragsdauer. SAP darf den Preis für die neue Periode erhöhen, sofern die Erhöhung mindestens 45 Tage vor Verlängerungsbeginn angekündigt wurde. Eine Nachverhandlung ohne neues Opening ist nicht möglich. Das Kündigungsrecht bleibt bestehen, sofern SAP eine Preiserhöhung ankündigt, aber der Zeitraum bis zur Entscheidung ist dann deutlich kürzer. Der Steuerungsmoment für eine proaktive Verhandlungsposition ist zu diesem Zeitpunkt bereits verstrichen.

Wenn der Renewal-Zeitpunkt näher liegt als 18 Monate, ist das Modell auf den verfügbaren Zeitraum anzupassen. Priorität hat dann: Datenbasis aufbauen (Phase 1), Stakeholder konstituieren (Phase 2), Klausel-Review abschließen (Phase 3). Phase 4 braucht mindestens sechs Monate, weil davor die Sperrfristen für neue Subskriptionen greifen. Wer mit weniger als sechs Monaten Vorlauf in die Vorbereitung einsteigt, hat bereits eingeschränkte Handlungsoptionen.

Die vertragliche Konsequenz ist der 15-prozentige Aufschlag auf den übernutzten Verbrauch, fakturiert auf der Folgerechnung. Zusätzlich entfällt die SLA-Garantie für die Dauer der Übernutzungsphase. Die Self-Report-Pflicht ist eine vertraglich festgelegte Kundenverantwortung, deren Nichterfüllung im Rahmen einer Vertragsprüfung relevant werden kann.

Monatlich. Das ist die Mindestfrequenz für eine funktionsfähige Overage-Governance. SAP stellt das Balance Statement monatlich zur Verfügung. Wer weniger häufig auswertet, hat keine belastbare Grundlage für eine Projektion des Restguthabens zum Vertragsende.

PCE-Metering ist die SAP-seitige Messung der FUE-Nutzung. Sie ersetzt die eigene Vermessung nicht, weil sie keine Grundlage für die Validierung von SAP-Messergebnissen bietet. Eigene Vermessung und SAP-Messung laufen parallel. Bei Abweichungen ist die eigene Messhistorie die Voraussetzung für eine sachgerechte Klärung.

Ja, sofern die Sperrfristen es erlauben. Neue Cloud-Managed-Service- oder Software-Subskriptionen sind bis sechs Monate vor Vertragsende möglich. Neue CAS-Einheiten bis zwölf Monate vor Vertragsende. Wer eine drohende Overage frühzeitig erkennt, hat ausreichend Optionen. Im letzten Quartal vor Vertragsende sind diese Optionen strukturell eingeschränkt.

Ungeklärte Sachstände aus der laufenden Vertragslaufzeit binden Ressourcen im Renewal-Gespräch. Eine saubere Overage-Dokumentation ist dagegen ein sachlicher Input für die Renewal-Datenbasis: Sie zeigt, welche Komponenten strukturell unter- oder überallokiert waren und welches Volumen für die nächste Laufzeit sachgerecht wäre.

Berechtigungsbasierte Klassifizierung bedeutet, dass der FUE-Typ eines Nutzers durch die ihm zugewiesenen Rollen und Berechtigungen bestimmt wird, nicht durch seine tatsächliche Systemnutzung. Die höchste Berechtigung in der Rollen-Kombination eines Nutzers bestimmt seinen FUE-Typ.

Bei nutzungsbasierter Klassifizierung würde der tatsächliche Transaktionsumfang eines Nutzers als Basis für den Lizenztyp dienen. In S/4HANA Cloud gilt dagegen das berechtigungsbasierte Modell: Zugewiesene Berechtigung schlägt tatsächliche Nutzung.

PCE Metering wird monatlich durch SAP automatisch ausgeführt. Rollenoptimierungen müssen deshalb vor dem jeweiligen Metering-Stichtag abgeschlossen sein, um im laufenden Monat wirksam zu sein.

Role Creep bezeichnet die schleichende Erweiterung von Berechtigungen über den lizenzierten Umfang hinaus. Typischerweise entstehen dadurch Nutzer, die in einem höheren FUE-Typ gemessen werden, als ihre eigentliche Arbeitstätigkeit erfordert. Ursache ist häufig die Zuweisung von Zusatzrollen ohne Prüfung der Lizenztyp-Implikation.

Die STAR-Analyse (S/4HANA Trusted Authorization Review) ist ein SAP-Werkzeug zur Analyse der Berechtigungsstruktur. Es zeigt, welche Berechtigungen zugewiesen sind. Wichtig: Rohe STAR-Daten immer zunächst intern mit Nutzungslogs abgleichen und Berechtigungen optimieren, bevor die Datengrundlage für externe Zwecke verwendet wird.

Jeder Nutzer, der von Advanced auf Core umgestuft werden kann, spart 0,8 FUE. Von Advanced auf Self-Service sind es 0,967 FUE. Von Core auf Self-Service sind es 0,167 FUE. Bei größeren Nutzerbasen summieren sich diese Einsparungen auf einen erheblichen Steuerungshebel für die Vertragsbasis beim nächsten Renewal.

In S/4HANA Cloud gilt das berechtigungsbasierte Klassifizierungsmodell: Der FUE-Typ eines Nutzers wird durch die zugewiesenen Rollen und ihre Berechtigungen bestimmt, nicht durch die tatsächlich ausgeführten Transaktionen. Was ein Nutzer tun könnte, ist die Messgröße, nicht was er tatsächlich tut.

Advanced (1,0 FUE) ist fünfmal teurer als Core (0,2 FUE) und rund dreißigmal teurer als Self-Service (0,033 FUE). Die Einsparung pro Nutzer bei einer Umstufung von Advanced auf Core beträgt 0,8 FUE, von Advanced auf Self-Service 0,967 FUE, von Core auf Self-Service 0,167 FUE.

Rollenoptimierungen verbessern den FUE-Verbrauch und damit die Headroom-Situation im laufenden Pool. Eine Reduktion des vertraglich vereinbarten FUE-Pools ist bei den meisten RISE-Verträgen während der Laufzeit nicht möglich. Optimierungen wirken deshalb primär als Verhandlungsgrundlage für das nächste Renewal, nicht als sofortige Kostenreduktion.

SAM4U (SAP Note 3646933) im Kundensystem installieren und Enhanced Usage Tracking aktivieren. Das liefert eine Datenbasis für die tatsächliche Nutzung pro Nutzer. Parallel eine STAR-Analyse intern durchführen und beide Ergebnisse abgleichen. Dieser Abgleich zeigt, wo Berechtigungen und tatsächlicher Bedarf auseinanderdriften.

Named User ist die klassische Lizenzmetrik für On-Premise-Systeme: Jede Person mit SAP-Zugang benötigt eine individuell zugeordnete Lizenz eines bestimmten Typs. FUE (Full Use Equivalent) ist die Lizenzmetrik für RISE with SAP und GROW with SAP: Kunden kaufen einen Pool aus gewichteten Einheiten und verteilen diesen intern auf Nutzertypen. Der wesentliche Unterschied liegt im Compliance-Check: Beim Named-User-Modell muss jeder Typ einzeln compliant sein. Beim FUE-Modell gilt die Compliance auf Pool-Ebene: Die gewichtete Summe aller Nutzer darf den gekauften FUE-Pool nicht überschreiten.

Advanced User: 1,0 FUE. Core User: 0,2 FUE (5 Core User = 1 FUE). Self-Service User: 0,033 FUE (ca. 30 Self-Service User = 1 FUE). Developer User: vertragsspezifisch, in der Praxis 0,5 oder 2,0 FUE je nach Vertragsversion. Der konkrete Vertrag muss geprüft werden.

In den meisten RISE-Verträgen ist eine Mid-Term-Reduktion der FUE-Anzahl ausgeschlossen. Wer zu viele FUE kauft, zahlt bis zum Renewal für ungenutzte Kapazität. Eine True-Up/True-Down-Klausel, die eine Anpassung nach 18 bis 24 Monaten erlaubt, ist verhandelbar.

Die Nomenklatur ändert sich, und SAP hat 2025 Anpassungen an der Zuordnung von Rollen zu Nutzertypen vorgenommen. Bestimmte Transaktionen, die in ECC als Limited Professional galten, können in S/4HANA Professional erfordern. Eine Reklassifizierungsanalyse vor dem Go-Live ist sinnvoll.

In der Praxis benötigen typischerweise nur 10 bis 20 Prozent aller Nutzer einer Organisation Advanced-Zugriff. Wer die genaue Verteilung nicht analysiert, zahlt strukturell zu viel.

Nein. Eine praxistaugliche Priorisierung orientiert sich am ACV-Anteil und an der Komplexität des Lizenzmodells. RISE und BTP verdienen intensivere Steuerung als ein kleines Concur-Kontingent. Sinnvoll ist eine Governance-Ebene, die alle Produkttypen sichtbar hält, aber die operative Steuerungstiefe nach Volumen und Risiko differenziert.

Die Behandlung von Renewal-Terminen als isolierte Ereignisse. Wenn RISE, SuccessFactors und Ariba unabhängig voneinander renewt werden, ohne eine gemeinsame Strategie, entstehen Verhandlungsmöglichkeiten, die sich nicht zurückholen lassen. Koordinierte Steuerungsmomente beginnen vor dem Renewal, nicht mit dem Renewal-Schreiben von SAP.

Co-Termination wird nicht automatisch von SAP angeboten. Der erste Schritt ist, die aktuellen Laufzeiten aller aktiven SAP-Verträge zu konsolidieren und die Differenz zu einem gemeinsamen Renewal-Termin zu analysieren. Daraus ergibt sich, welcher Vertrag verlängert werden müsste und zu welchem Preis. Diese Analyse ist Grundlage für die Verhandlung mit SAP oder dem zuständigen Beratungspartner.

Die Verbrauchslogik von CPEA, BTPEA und AI Units ist in Pillar 2 (SAP Business AI und BTP-Governance) und Pillar 3 (BTP FinOps) ausführlich beschrieben. Dieser Artikel behandelt BTP aus der Portfolio-Perspektive; die Detailmechanik liegt bewusst in den dedizierten Pillars.

FinOptory führt Vertrags-, Nutzungs- und Kostendaten über alle SAP-Produkttypen zusammen und stellt Steuerungsmomente je Produkttyp sichtbar dar. Die Plattform ermöglicht, Renewal-Termine, Credit-Verbräuche und Klassifizierungsabweichungen in einer gemeinsamen Ansicht zu verfolgen. Weitere Informationen zur Plattform und zum Managed Service finden Sie auf finoptory.ai.

Basic Audit ist die jährliche Standardmessung: selbst durchgeführt, begrenzte Prüftiefe, moderates Risiko. Enhanced Audit ist eine vertiefte Prüfung durch SAP GLA: tiefgehende Rollenanalyse, Transaktionsnutzung und Indirect Access werden geprüft, Laufzeit drei bis sechs Monate, erheblich höheres finanzielles Exposure.

Routinemäßig alle zwei bis drei Jahre für den Enhanced Audit. Anlassbezogen vor Renewals und RISE-Migrationen, bei M&A-Aktivitäten, nach vorangehenden Non-Compliance-Befunden oder bei Auffälligkeiten im Basic Audit.

Quartalsweise Self-Audits mit USMM und SAM4U, kombiniert mit laufender Bereinigung inaktiver Accounts. Wer die Lizenzbasis regelmäßig in einem sauberen Zustand hält, hat beim Enhanced Audit wenig zu korrigieren.

Die vertraglich geschuldeten Daten: USMM-Messdateien und den konsolidierten LAW-Report. Weitere Daten können im Enhanced Audit angefordert werden; jede Anforderung sollte gegen den vertraglichen Scope geprüft werden.

Back-Maintenance ist die rückwirkende Maintenance-Gebühr für den Zeitraum der Unterlizenzierung. SAP berechnet sie typischerweise auf Basis von etwa 22 Prozent des Lizenzwerts pro Jahr, rückwirkend für zwei bis drei Jahre. Bei 100 misklassifizierten Nutzern und 1.500 USD Preisdifferenz ergibt sich ein Gesamtexposure von rund 249.000 USD (Nachkauf 150.000 USD plus Back-Maintenance rund 99.000 USD).

Nein. Sandbox-Systeme können vertraglich ausgenommen sein, müssen es aber nicht. Die Ausnahme muss im Vertrag, konkret im beigefügten "Product and Pricing Definitions"-Dokument, explizit genannt sein. Eine allgemeine SAP-Regel, die Sandbox-Systeme grundsätzlich ausnimmt, existiert nicht.

Das hängt vom Zugriffsumfang ab. Ein Tester, der vollständige End-to-End-Prozesstests durchführt und dabei Professional-Transaktionen ausführt, benötigt denselben Typ wie im Produktivsystem. Gibt es im Vertrag einen dedizierten Test-User-Typ, kann dieser verwendet werden, sofern die Nutzungsbedingungen eingehalten werden.

Im FUE-Modell von RISE gibt es keinen eigenständigen Test-User-FUE-Typ in der Standarddefinition. Testende Nutzer fallen nach Zugriffsumfang in einen der vier FUE-Typen. Vertragliche Sonderregelungen für Testkonten sind möglich, aber ausdrücklich zu vereinbaren.

Der Test-User-Lizenztyp deckt ausschließlich den Zugriff auf definierte Testsysteme ab. Ein Konto, das einen Produktivsystem-Zugriff erzeugt, benötigt für diesen Zugriff den entsprechenden Produktiv-Lizenztyp. Ein einmaliger Produktivsystemzugriff durch ein als Test User lizenziertes Konto ist ein Compliance-Befund.

Im SAP-Softwarevertrag ist das "Product and Pricing Definitions"-Supplement beigefügt. Dort sind alle verfügbaren Lizenztypen und ihre Nutzungsbedingungen definiert. Falls dieses Dokument nicht vorliegt, ist es über den SAP Account Executive oder das SAP Support-Portal zu beschaffen.

Ja. USMM zählt jeden Named User, unabhängig von Aktivität. Inaktive Test-Accounts erhöhen die gemessene Lizenzzahl. Die Bereinigung nach 90 Tagen ohne Login gilt als etablierte Praxisregel.

USMM ist das klassische SAP-Standardtool für die Einzelsystem-Vermessung: Es zählt Named User und Engine-Metriken pro System und erzeugt eine Messdatei für die Annual Measurement oder Enhanced Audits. SAM4U geht darüber hinaus: Es analysiert tatsächliche Nutzung, identifiziert Optimierungsmöglichkeiten bei der FUE-Klassifizierung und erlaubt ab Q4/2025 auch die Simulation von Berechtigungsänderungen vor der Umsetzung. USMM misst, SAM4U steuert.

LAW und SAM4U erfüllen unterschiedliche Konsolidierungsaufgaben. LAW ist das offiziell an SAP übermittelte Konsolidierungsdokument für die Annual Measurement und ist im PCE Metering die technische Infrastruktur für den Datentransfer. SAM4U konsolidiert intern für Optimierungszwecke, ist aber nicht das Übermittlungsdokument für SAP. Beide werden benötigt: LAW für die offizielle Compliance-Perspektive, SAM4U für die interne Steuerungsperspektive.

Im On-Premise-Kontext war einmal jährlich der entscheidende Messzeitpunkt. PCE Metering triggert monatlich und automatisch. Das bedeutet: SAP for Me sollte monatlich geprüft werden, Rollenoptimierungen sollten vor dem Metering-Zyklus abgeschlossen sein, und Diskrepanzen zwischen eigenem Verständnis und SAP-Metering-Ergebnis sollten laufend dokumentiert werden. Der Steuerungsmoment Berechtigungen ist im PCE-Kontext kein jährliches, sondern ein monatliches Thema.

Ja. SAM4U ist kein Cloud-Service, sondern wird direkt im Kundensystem über SAP Note 3646933 installiert. Die Analysedaten verbleiben im Kundennetzwerk. Ab Q1/2026 steht eine Data API zur Verfügung, über die SAM4U-Daten in externe Plattformen exportiert werden können. Der Export ist optional und unter Kontrolle des Kunden.

SAM4U ist kostenlos und auf SAP-Lizenzmessung spezialisiert. Es deckt FUE-Klassifizierung, Enhanced Usage Tracking, Optimization Opportunities und ab Q4/2025 Authorization Simulation ab. Kommerzielle Software Asset Management-Tools haben einen breiteren Scope (alle Softwareprodukte), aber in der Regel keine vergleichbare SAP-spezifische Tiefe für FUE-Klassifizierung und berechtigungsbasierte Analyse. Für die SAP-Lizenz-Governance ist SAM4U das sinnvolle Instrument, das auf SAP-Vertrags- und Governance-Aspekte zugeschnitten ist.

Das System läuft weiter. Was endet, ist Mainstream Maintenance: Legal Changes, Support Packages und Fehlerkorrektur im Standard werden nicht mehr automatisch bereitgestellt. Ab dem 1. Januar 2028 ist für den Weiterbetrieb entweder ein Extended-Maintenance-Addendum erforderlich oder der Betrieb unter PCE/RISE, der Extended Maintenance im Subscription-Preis enthält.

Extended Maintenance kostet zwei Prozentpunkte zusätzlich auf die Maintenance Base. Die Maintenance Base umfasst alle BS7 Core Applications, Add-ons und Runtime-Datenbanken. Durch gezieltes Aufgeben nicht benötigter Nutzungsrechte kann die Basis vor dem Start von Extended Maintenance reduziert werden, was den Aufschlag in absoluten Zahlen deutlich verringert.

Extended Maintenance gilt für die gesamte On-Premise-BS7-Landschaft. Cherry-Picking nach Systemen ist nicht möglich. Wer Extended Maintenance beantragt, beantragt sie für alle BS7-Systeme.

Die Transition Option ist ein befristetes Cloud-Betriebsmodell für SAP ERP EhP 7 und EhP 8 in der SAP ERP Private Edition. Der Service-Start ist der 1. Januar 2031, das Ende ist der 31. Dezember 2033. Das Subskriptionsfenster liegt zwischen 2028 und 2030.

Die Transition Option kostet 20 Prozent Aufschlag gegenüber dem vergleichbaren Preis einer regulären SAP ERP Private Edition. Zusätzlich ist der Max Success Plan Transition Services verpflichtend. Kunden, die sich vor Ende 2025 subskribiert haben, zahlen keinen Aufschlag.

Ja, über das Cloud Extension Program. Drei Credit-Typen stehen zur Verfügung: Maintenance Credits, Service Credits und Cloud Credits. Die Höhe ist verhandlungsabhängig und nicht öffentlich tabelliert. Frühzeitige Verhandlungen stärken typischerweise die Verhandlungsposition.

SAP erlaubt Dual-Use-Betrieb für eine vertraglich definierte Übergangsdauer. Die übliche Praxis liegt bei sechs bis 18 Monaten. Die genaue Dauer und die Nutzungsregelungen während des Parallelbetriebs müssen im RISE-Vertrag festgelegt werden.

Add-ons ohne S/4HANA-Äquivalent können in der Transition Option noch betrieben werden, wenn sie in der verfügbaren Add-on-Liste stehen. Sie müssen aber bis spätestens Ende 2033 auf alternative Lösungen migriert werden. Das S/4HANA Compatibility Pack gilt nur bis Ende 2030 für Cloud-Subscriptions.

Shelfware sind Lizenzen, für die Maintenance gezahlt wird, ohne dass die Nutzungsrechte ausgeübt werden. Beim Wechsel zu RISE kann Shelfware als zusätzliches Argument in der Credit-Verhandlung eingesetzt werden. Die Voraussetzung ist eine vollständige Bestandsaufnahme über SAP Readiness Check und Lizenzkataster.

Die verfügbaren Add-ons umfassen Kategorien aus Supply Chain (APO als Connector, EWM), Finance (Revenue Accounting, Treasury), HCM (HR Renewal, SuccessFactors EC Integration), Compliance (GINVOICING) und Integration. Die vollständige Liste ist im SAP Help Portal und in der SAP Customer Evolution Dokumentation zugänglich. Nur EhP 7 und EhP 8 werden unterstützt.

Für Kunden, deren gesamte Systemlandschaft bis zum 1. Januar 2028 in der SAP ERP Private Cloud Edition betrieben wird, ist Extended Maintenance im Subscription-Preis enthalten, ohne zusätzlichen Aufschlag. Das ist die strukturelle Vereinfachung, die RISE gegenüber On-Prem-Extended-Maintenance bietet.

Die laufende Vertragssteuerung nach dem Go-Live umfasst die vier Steuerungsbereiche: Nutzung (FUE-Entwicklung, BTP-Credits), Berechtigungen (Rollendesign, Lizenzklassen), Infrastruktur (SLA-Monitoring, Sizing) und Kosten (ACV-Tracking, Derived Charges, Renewal-Vorbereitung). Eine strukturierte 14-Tage-Review-Systematik stellt sicher, dass Steuerungsmomente erkannt werden, bevor sie zu Budgetabweichungen führen.

Extended Maintenance ist ausschließlich für On-Premise-Betrieb relevant. Wer On-Prem mit Extended Maintenance bleibt, trifft keine Hyperscaler-Entscheidung. Erst beim Wechsel zu RISE oder der Transition Option kommt die Wahl zwischen Azure, AWS und Google Cloud ins Spiel. Diese Entscheidung ist im Vertrag zu verankern und beeinflusst sowohl komplementäre Services als auch die langfristige Kostenstruktur.

Nach Ende 2030 gibt es für On-Premise-BS7-Systeme ohne Transition Option keine strukturierte SAP-Maintenance mehr. Wer bis dahin weder Extended Maintenance abgeschlossen noch die Transition Option subskribiert hat und noch nicht auf S/4HANA migriert ist, befindet sich in einem Betriebszustand ohne vertragliche Grundlage für regulären SAP-Support. Drittpartei-Wartung ist eine mögliche Option, setzt aber eigene Vertragsstrukturen voraus und deckt typischerweise nicht den vollen Scope von SAP-Support ab.

SAP stellt mehrere Tools bereit, die in der Entscheidungsvorbereitungsphase relevant sind: Der SAP Readiness Check liefert technische Systemdaten für Sizing und Custom-Code-Analyse. SAP Signavio Process Navigator unterstützt beim Fit-to-Standard-Abgleich. SAP Cloud ALM ist nach dem Go-Live das ALM-Werkzeug für den RISE-Betrieb. Diese Tools sind im RISE-Vertrag enthalten, werden aber in der Praxis häufig erst nach Go-Live aktiviert statt bereits in der Vorbereitungsphase genutzt.

SAP-Lizenzmanagement ist auf die Compliance-Dimension ausgerichtet: Sind die tatsächlich genutzten SAP-Produkte korrekt lizenziert? Es ist eine Prüf- und Dokumentationsaufgabe, typischerweise reaktiv und auf Audit-Vermeidung ausgerichtet. Strategisches Vendor-Management geht darüber hinaus. Es steuert die gesamte SAP-Vendor-Beziehung über alle vier Steuerungsbereiche: Nutzung, Berechtigungen, Infrastruktur und Kosten. Es ist proaktiv, kontinuierlich und auf die Steuerungsmomente in der Vendor-Beziehung ausgerichtet, nicht nur auf Compliance. Ein weiterer Unterschied liegt im Zeithorizont. Lizenzmanagement ist auf den aktuellen Zustand ausgerichtet. Strategisches Vendor-Management ist auf die Entwicklung der Vendor-Beziehung über die gesamte Vertragslaufzeit und über zukünftige Vertragszyklen hinweg ausgerichtet.

Quartalsweise sind formale Reviews mit SAP-Ansprechpartnern (typischerweise CSM und AE) sinnvoll. Diese Reviews bieten eine strukturierte Gelegenheit, offene Themen zu besprechen, den Status der Vertragsbeziehung zu klären und nächste Schritte zu vereinbaren. Zusätzlich gibt es anlassbezogene Gespräche: bei Eskalationen, bei Renewal-Vorbereitung und bei M&A-Ereignissen. Diese Gespräche sind nicht nach einem festen Rhythmus getaktet, sondern reagieren auf konkrete Steuerungsmomente.

Die SAP-Vendor-Beziehung sollte von einer dedizierten Contract-Manager-Rolle verantwortet werden, die die übergreifende Vertragssicht hält. In der Praxis ist diese Rolle in vielen Organisationen nicht explizit besetzt. Sie wird zwischen IT, Einkauf und Finanz aufgeteilt, ohne dass eine Person die Gesamtverantwortung trägt. Die Empfehlung ist nicht zwingend eine separate Stellenbesetzung, sondern eine klare Rollenzuordnung: Wer trägt die übergreifende Verantwortung für die Vertragssicht? Wer koordiniert die vier Rollen? Wer ist erster Ansprechpartner für SAP und intern?

Wissenserhalt erfordert eine kontinuierliche Dokumentationsdisziplin, nicht eine einmalige Übergabe kurz vor dem Ausscheiden einer Person. Die Wissensbasis muss laufend gepflegt werden: Vertragsstruktur, Nutzungshistorie, Änderungshistorie, SAP-Ansprechpartnerkarte und offene Themen. Eine strukturierte Übergabe beim Personalwechsel ist dennoch notwendig und sollte ein Review aller offenen Steuerungsmomente, eine Einführung in die aktuell laufenden SAP-Prozesse und eine formale Vorstellung beim SAP-Ansprechpartner umfassen.

Der Eskalationspfad beginnt mit der schriftlichen Dokumentation der SLA-Abweichung über das SAP Support Portal mit einer Prioritäts-Hochstufung. Wenn der Standard-Support keine ausreichende Reaktion zeigt, werden CSM und TAM formal eingebunden. Wenn auch das nicht zur Lösung führt, wird der AE mit einer vollständigen schriftlichen Problemdokumentation eingebunden. Wenn alle diese Stufen keine Lösung bringen, ist Executive Escalation der nächste Schritt. Entscheidend ist die schriftliche Dokumentation jeder Eskalationsstufe. Diese Dokumentation ist ein Steuerungsmoment, der für spätere SLA-Verhandlungen relevant ist.

Executive Escalation bei SAP bezeichnet die Einbindung der SAP-Führungsebene in eine Eskalationssituation. Sie ist sinnvoll, wenn alle regulären Eskalationswege ausgeschöpft sind und keine ausreichende Lösung gebracht haben, oder wenn eine strategische Entscheidung auf Führungsebene erforderlich ist, die unterhalb dieser Ebene nicht getroffen werden kann. Executive Escalation sollte vorbereitet und gezielt eingesetzt werden. Wer Executive Escalation zu häufig oder ohne ausreichende Vorbereitung auslöst, wertet das Signal ab. Die Einbindung der Führungsebene signalisiert die strategische Bedeutung des Themas.

Zeitdruck im Renewal-Prozess äußert sich in der Praxis durch verkürzte Angebotsgültigkeiten, durch die Verknüpfung von Renewal-Angeboten mit zeitlich begrenzten Boni oder durch die Betonung bevorstehender Preisänderungen. Diese Kommunikationsmuster sind Teil des normalen SAP-Verhandlungsrahmens. Die Gegenstrategie ist eine ausreichend frühe Renewal-Vorbereitung, die dem Unternehmen ermöglicht, Angebote zu prüfen, Alternativen zu bewerten und Verhandlungen ohne Zeitdruck zu führen. Wer 18 Monate vor Vertragsende mit der Renewal-Vorbereitung beginnt, hat den Steuerungsmoment auf seiner Seite.

Handlungsspielraum bei einer tiefen RISE-Integration beginnt mit der genauen Kenntnis der eigenen Abhängigkeiten: Welche Daten, Schnittstellen und Eigenentwicklungen sind SAP-spezifisch? Welche Vertragsklauseln schränken den Handlungsspielraum beim Renewal ein? Auf dieser Basis können gezielte Maßnahmen ergriffen werden: die Dokumentation der technischen Abhängigkeiten, die Prüfung von Exit-Optionen (ohne dass ein Wechsel geplant sein muss), die frühzeitige Vorbereitung des Renewals und der Aufbau einer intern starken Verhandlungsposition durch vollständige Nutzungs- und Kostentransparenz.

Das hängt von den Vertragsklauseln ab, insbesondere von den Change-of-Control- und Assignment-Klauseln. Typischerweise erfordert eine Übertragung eines SAP-Vertrags auf einen anderen Rechtsträger die schriftliche Zustimmung von SAP. Diese Zustimmungspflicht sollte so früh wie möglich im M&A-Prozess adressiert werden, da SAP-interne Entscheidungsprozesse Zeit benötigen. Die Vorab-Prüfung der SAP-Vertragsklauseln auf Change-of-Control-Regelungen ist Teil einer vollständigen M&A-Due-Diligence.

Affiliate Licensing bezeichnet das Recht von Konzerngesellschaften, unter einem bestehenden SAP-Hauptvertrag SAP-Produkte zu nutzen. Die Definition des Affiliates ist vertraglich geregelt und typischerweise an eine Mehrheitsbeteiligung des Vertragspartners gebunden. Affiliate Licensing ist relevant bei M&A-Transaktionen (wenn neue Gesellschaften in den Konzernverbund kommen), bei Carve-outs (wenn Gesellschaften ausscheiden) und bei der organischen Expansion in neue Konzerngesellschaften.

Eine verhandlungsrelevante Eskalationsdokumentation enthält: Datum und Dauer der Eskalationssituation, belegte SLA-Abweichungen (Reaktionszeiten, Lösungszeiten), Auswirkung auf den Geschäftsbetrieb, alle formalen Eskalationsstufen mit Ansprechpartnern und Reaktionen sowie das Ergebnis. Diese Dokumentation sollte laufend gepflegt und als Bestandteil der Vertragshistorie behandelt werden. Bei der Renewal-Vorbereitung ist sie ein konkreter Eingabepunkt für die Bewertung der Vertragsleistung und für die Formulierung von SLA-Anpassungsforderungen.

Externe Unterstützung ist sinnvoll bei komplexen Renewals, bei Audit-Situationen, bei M&A-Transaktionen mit SAP-Vertragsimplikationen und beim initialen Aufbau einer SAP-Governance-Funktion. In diesen Phasen ist spezialisiertes Wissen gefragt, das intern nicht in der erforderlichen Tiefe vorhanden ist. Internes Know-how reicht für den laufenden Betrieb, wenn eine vollständige Dokumentation der Vertragsstruktur, ein funktionierender Governance-Kalender und die vier Rollen ausreichend besetzt und koordiniert sind. Die interne Kompetenz sollte so aufgebaut sein, dass sie die laufenden Steuerungsmomente eigenständig wahrnehmen kann.

Der Begriff "Affiliate" im SAP-Vertragskontext ist breiter als die buchhalterische Definition einer Tochtergesellschaft. Typischerweise umfasst er alle Gesellschaften, die zu mehr als 50 Prozent direkt oder indirekt kontrolliert werden. Die genaue Definition ist vertragsindividuell und sollte aus dem jeweiligen Vertragstext entnommen werden.

Das hängt vom jeweiligen Vertrag ab. Viele Verträge enthalten Meldepflichten für Änderungen im Affiliate-Kreis. Ob eine neue Gesellschaft automatisch unter den Vertrag fällt oder explizit aufgenommen werden muss, ist aus den Klauseln zur Lizenzabdeckung und dem Affiliate-Anhang zu entnehmen.

Verträge sind in der Regel nicht automatisch auf ein erworbenes Unternehmen übertragbar. Assignment-Klauseln verlangen typischerweise die Zustimmung von SAP. Ob das erworbene Unternehmen als neuer Affiliate in den bestehenden Konzernvertrag integriert werden kann, oder ob ein eigenständiger Vertrag weiterläuft oder neu verhandelt wird, ist Gegenstand der M&A-bezogenen Vertragssteuerung. Mehr dazu im Artikel SAP-Verträge bei M&A, Carve-out und Unternehmensübernahme.

Wenn SAP ein Audit durchführt und Nutzung ohne entsprechende Lizenzabdeckung feststellt, kann das zur Nachlizenzierung zum aktuellen Listenpreis führen. Das Risiko ist besonders relevant nach Akquisitionen, bei denen die Compliance-Situation des erworbenen Unternehmens nicht vollständig geprüft wurde.

Das hybride Modell ist in der Praxis häufig der pragmatische Einstieg: Interne Rollen bleiben in ihren Abteilungen, ein Koordinationsverantwortlicher wird benannt, und für übergreifende Aufgaben wie Nutzungsauswertung und Steuerungsmoment-Vorbereitung wird externe Unterstützung eingebunden. Die Entscheidung bleibt intern.

Die Steuerungsaufgaben werden dann informell verteilt oder im Tagesgeschäft verankert. Das funktioniert eine Zeit lang, solange keine außerordentlichen Ereignisse eintreten. Mit wachsendem Portfolio, herannahenden Renewals oder ersten Eskalationen zeigt sich, dass informelle Strukturen nicht ausreichen.

Quartalsweise ist in den meisten Organisationen der richtige Rhythmus. Bei Verträgen mit aktiven Renewal-Prozessen oder laufenden Eskalationen ist ein monatlicher Rhythmus der Steuerungsrunde sinnvoll.

Indem jede Abstimmung ein konkretes Ergebnis produziert: eine Entscheidung, eine Entscheidungsvorlage, oder eine dokumentierte Feststellung. Abstimmungen ohne Output sind ein Indikator, dass der Prozess nicht hinreichend strukturiert ist.

Vertragswissen, das ausschließlich in einer Person liegt, ist strukturell gefährdet. Die Lösung liegt nicht in der Bindung von Personen, sondern in der systematischen Dokumentation: Vertragsstand, Änderungshistorie, SAP-Kontaktliste und offene Punkte müssen aktuell gehalten werden, damit eine Übergabe in angemessener Zeit möglich ist. Eine Übergabe-Checkliste als organisatorischer Standard: nicht als Reaktion auf einen Abgang, sondern als laufender Prozess: verankert das.

Externe Unterstützung ist dann sinnvoll, wenn spezialisiertes Wissen benötigt wird, das intern nicht wirtschaftlich aufzubauen ist: zum Beispiel SAP-Vertragsrecht, tiefes Pricing-Wissen oder Benchmarks auf Basis eines breiteren Portfolios. Ebenso in Phasen, in denen interne Kapazität oder Erfahrung aufgebaut werden soll: externer Partner als temporäre Unterstützung mit Wissenstransfer-Mandat, nicht als dauerhafter Ersatz für interne Kompetenz.

Ein SAP CCoE adressiert typischerweise technische und architektonische Standards für die SAP-Nutzung im Unternehmen. Eine SAP-Governance-Funktion im hier beschriebenen Sinne adressiert die kommerzielle Steuerung der Vertragsbeziehung: Abrechnung, Renewal, Nutzungsabgleich, Konditionenentwicklung. Beide Bereiche sind sinnvoll: sie erfordern jedoch unterschiedliche Kompetenz und unterschiedliche Prozesse. Klarheit über die Abgrenzung vermeidet organisatorische Lücken.

SAP-seitige Renewal-Prozesse haben interne Vorlaufzeiten. Der AE hat Anreize, das Angebot nach Möglichkeit in einem bestimmten Zeitfenster seines eigenen Geschäftsjahres zu platzieren. Für Kunden bedeutet das: Renewal-Vorbereitung intern früher zu starten als das externe Angebot eintrifft, ist strukturell sinnvoll.

Der CSM ist für Adoption und Nutzungstiefe zuständig, nicht für kommerzielle Vertragssteuerung. Für Pricing, Renewal-Konditionen und Vertragsanpassungen ist der richtige Kontakt der AE, ggf. ergänzt um die Commercial-Teams. Den CSM für kommerzielle Fragen einzusetzen, erzeugt häufig längere Klärungsschleifen.

Vereinbarungen, auch informelle, gehören schriftlich festgehalten: Was wurde zugesagt? Bis wann? Durch wen? Das gilt besonders für Aussagen zu Nutzungsdaten, SLA-Interpretationen und kommerzielle Zusagen außerhalb formaler Angebote. Schriftliche Protokolle sind die Grundlage für spätere Vertragssteuerung, nicht optionale Dokumentation.

Nein. Der CSM ist auf Adoption ausgerichtet, nicht auf kommerzielle Vertragssteuerung. Für Fragen zu Konditionen, Renewal-Optionen oder Abrechnungsdetails ist der AE der richtige Ansprechpartner, für technische Fragen der TAM.

Jedes Add-on-Angebot verändert die Vertragsstruktur und erzeugt Folgekosten über die Laufzeit. Vor einer Entscheidung sollte geprüft werden, welche Komponenten tatsächlich genutzt werden, welche Maintenance-Kosten entstehen und ob das Paket auch in Einzelteilen verhandelbar ist.

Mindestens quartalsweise für ein strukturiertes Review, in dem Vertragsstand, Nutzungsentwicklung und offene Themen besprochen werden. Dazu anlassbezogen bei konkreten Steuerungsmomenten wie Renewal-Vorbereitung, Eskalationen oder strategischen Portfolioentscheidungen.

Technische Eskalationen, also Probleme mit Systemleistung, SLAs oder Infrastruktur, gehören zum TAM. Kommerzielle Eskalationen, also Fragen zu Konditionen, Abrechnungsfehlern oder Vertragsinterpretationen, gehören zum AE, der diese gegebenenfalls intern weiterleitet.

Technische Abhängigkeit in einem bestimmten Umfang ist bei einem Kernsystem wie SAP strukturell unvermeidlich. Vertraglicher und organisatorischer Lock-in ist dagegen in weiten Teilen steuerbar. Der Ansatz ist nicht die Vermeidung aller Abhängigkeiten, sondern deren bewusste Steuerung.

18 bis 24 Monate vor Vertragsende ist der sinnvolle Startpunkt für eine strukturierte Renewal-Vorbereitung. Wer erst sechs Monate vorher beginnt, hat die meisten Optionen bereits eingeschränkt. Der Governance-Kalender sollte diesen Zeitrahmen automatisch sichtbar machen.

Auto-Renewal-Regelungen finden sich typischerweise im Abschnitt zu Laufzeit und Kündigung des Vertrags. Die relevante Frage ist, wie lang die Kündigungsfrist ist und ob die Verlängerung automatisch mit denselben Konditionen oder mit Anpassungsmöglichkeiten für SAP eingetreten.

Beides sind unterschiedliche Zielsetzungen. Die hier beschriebenen Maßnahmen zielen nicht auf einen Systemwechsel, sondern darauf, die eigene Verhandlungsposition in der laufenden SAP-Beziehung informiert zu halten. Die Kenntnis der Exit-Optionen ist Teil dieser Informiertheit, ohne dass ein Wechsel beabsichtigt ist.

Die vier Maßnahmen erfordern keine vollständige SAP-Expertise im Haus. Sie erfordern eine klare Rollenzuordnung, eine strukturierte Dokumentationspraxis und einen aktiven Governance-Kalender. Für spezifische Phasen wie Renewal-Verhandlungen oder komplexe Vertragsklauseln-Bewertungen ist externe Begleitung weiterhin sinnvoll, aber als ergänzende Unterstützung, nicht als dauerhafter Ersatz für interne Steuerung.