SAP Contract Governance: Verträge nach der Unterschrift steuern
SAP Contract Governance ist die laufende Steuerung von SAP-Verträgen nach der Unterschrift, über die gesamte Vertragslaufzeit und über alle SAP-Produkttypen. Sie verbindet vertragliche, betriebliche und kommerzielle Sicht in einem Steuerungsmodell. Differenzierend ist nicht die Technologie, sondern die Phase: die Steuerung nach Vertragsabschluss.
SAP Contract Governance ist die laufende Steuerung von SAP-Verträgen nach der Unterschrift, über die gesamte Vertragslaufzeit und über alle SAP-Produkttypen. Sie verbindet vertragliche, betriebliche und kommerzielle Sicht in einem Steuerungsmodell. Differenzierend ist nicht die Technologie, sondern die Phase: die Steuerung nach Vertragsabschluss.
Inhaltsverzeichnis
- Was ist SAP Contract Governance?
- Vier Steuerungsmomente-Bereiche
- Vier Rollen, ein Steuerungsmodell
- SAP Contract Governance über alle neun SAP-Produkttypen
- Sonderfälle: Business AI, Digital Access, M&A
- Self-Service oder Managed Service
- Post-signature versus pre-signature
- SAP Contract Governance Reifegradmodell
- SLA und kritische Klauseln verstehen
- Renewal-Vorbereitung als Kern-Anwendungsfall
- Vertragscheck als Einstieg
- Worauf bei der Auswahl achten
- FAQ
- Nächste Schritte
Was ist SAP Contract Governance? {#was-ist-sap-contract-governance}
SAP Contract Governance bezeichnet die laufende, systematische Steuerung von SAP-Verträgen nach dem Vertragsabschluss. Sie umfasst alle Aktivitäten, die sicherstellen, dass ein Unternehmen über die gesamte Vertragslaufzeit hinweg den vollen Überblick über seine vertraglichen Verpflichtungen, Nutzungsrechte und Kostenentwicklungen behält, und auf dieser Basis handlungsfähig bleibt.
Ein VP IT oder Director SAP Plattform kennt diese Ausgangslage: SAP-Verträge werden sorgfältig verhandelt, juristisch geprüft und schließlich unterzeichnet. Was dann folgt, ist eine Vertragslaufzeit von fünf, sieben oder zehn Jahren, in der sich Nutzung, Organisation und Vertragsstruktur laufend verändern. Neue Produkttypen kommen hinzu, Tochtergesellschaften werden integriert, Benutzerstrukturen ändern sich, Guthaben verfallen oder laufen in Übernutzung. Renewals nahen schneller als erwartet.
Was SAP Contract Governance nicht ist
SAP Contract Governance ist kein Lizenzmanagement im klassischen Sinne. Klassisches SAP-Lizenzmanagement konzentriert sich auf die Vermessung und Klassifizierung von Benutzern, vor allem im On-Premise-Umfeld. SAP Contract Governance geht einen Schritt weiter: Sie fragt nicht nur, wie viele Lizenzen verbraucht werden, sondern was das im Verhältnis zum Vertrag bedeutet, wie sich die Kostenentwicklung zum Budget verhält, welche Klauseln in einer bestimmten Situation greifen und wann welche Handlung sinnvoll ist.
SAP Contract Governance ist auch kein Bestandteil der klassischen SAP-Implementierungsberatung. Implementierungsprojekte enden typischerweise mit dem Go-Live. Was danach kommt, die laufende Steuerung über die Vertragslaufzeit, liegt in einem anderen Verantwortungsbereich.
Die Herausforderung: Daten verteilt, Steuerung fragmentiert
Die strukturelle Herausforderung bei SAP-Vertragsportfolios ist nicht fehlender Wille zur Steuerung, sondern fehlende Datenkonnektivität. Relevante Informationen verteilen sich auf verschiedene Systeme und Verantwortungsbereiche: Vertragsdokumente liegen im Archivsystem oder beim Einkauf, Nutzungsdaten sind in SAP-internen Tools verfügbar, Rechnungen kommen über den Finanzbereich, Forecast-Annahmen entstehen im Controlling. Eine integrierte Sicht, die Vertrag, Nutzung, Kosten und Szenarien zusammenführt, ist mit diesen Einzelquellen kaum herzustellen.
In der Praxis zeigt sich, dass genau diese Datenfragmentierung zu vier wiederkehrenden Situationen führt:
Erstens trifft eine SAP-Rechnung ein und weicht vom Budget ab, ohne dass die Verbindung zwischen Rechnung, Vertragsbasis und operativen Nutzungsdaten herstellbar ist. Zweitens fragt die Geschäftsleitung nach den SAP-Kosten im nächsten Jahr, und die Antwort ist eine Schätzung mit Sicherheitsmarge statt einer fundierten Prognose. Drittens meldet sich SAP zum Renewal, legt ein überarbeitetes Angebot vor und es fehlt die Verhandlungsbasis aus eigener Datenlage. Viertens erfolgt die monatliche Systemvermessung, und falsche Berechtigungsrollen oder zu breit angelegte Lizenztypen werden laufend sichtbar, ohne dass eine strukturierte Auswertung und Reaktion möglich ist.
Das Steuerungsmodell
SAP Contract Governance verbindet drei Sichtweisen in einem Steuerungsmodell:
Die vertragliche Sicht beantwortet: Was ist vereinbart? Welche Leistungen, Mengen, Preise, Fristen und Klauseln gelten? Wo sind Handlungsfenster?
Die betriebliche Sicht beantwortet: Was wird tatsächlich genutzt? Wie verhält sich der Verbrauch zur vertraglich vereinbarten Basismenge? Wo entsteht Über- oder Unternutzung?
Die kommerzielle Sicht beantwortet: Was bedeutet die Nutzung in Euro? Wie entwickelt sich der ACV? Welche Szenarien ergeben sich für das nächste Budget-Jahr? Was ist die Verhandlungsposition beim Renewal?
Nur wenn diese drei Sichtweisen verbunden sind, ist laufende Steuerung möglich. Einzelne Sichten ohne Integration erlauben Monitoring, aber keine Steuerung.
Warum SAP Contract Governance an Bedeutung gewinnt
Zwei strukturelle Entwicklungen erhöhen den Steuerungsbedarf. Erstens wächst die Komplexität der SAP-Vertragslandschaft: Mit RISE with SAP, BTP, SuccessFactors, Ariba und weiteren Cloud-Produkten entstehen Portfolios aus heterogenen Vertragstypen mit unterschiedlichen Verbrauchsmodellen, Credit-Mechaniken und Renewal-Zyklen. Diese Heterogenität lässt sich mit manueller Übersicht schwerer beherrschen als ein klassisches On-Premise-Portfolio mit einem jährlichen Audit.
Zweitens ändert sich das Vermessungsregime: SAP hat mit der Einführung von Performance Capacity Equivalent Metering (PCE) die Messung von einer jährlichen auf eine monatliche Kadenz umgestellt. Wer Verbrauch und Klassifizierung nicht laufend im Blick hat, erhält keine Warnung vor Problemen, sondern stellt sie beim nächsten Reporting-Zyklus fest.
SAP Contract Governance ist die Antwort auf diese gestiegene Anforderung: eine strukturierte, kontinuierliche Steuerung, die nicht reaktiv auf Ereignisse reagiert, sondern vorausschauend auf Basis einer belastbaren Datenlage agiert.
Vier Steuerungsmomente-Bereiche {#vier-steuerungsmomente-bereiche}
SAP Contract Governance ist keine einmalige Analyse, sondern ein kontinuierlicher Prozess. Dieser Prozess lässt sich in vier Steuerungsmomente-Bereiche gliedern, die in einem SAP-Vertragsportfolio durchgängig relevant sind. Ein Steuerungsmoment ist ein Zeitpunkt, an dem aktives Eingreifen möglich und sinnvoll ist. Wer diese Momente kennt und nutzt, steuert vorausschauend. Wer sie verpasst, zahlt mehr als nötig, nutzt nicht aus, was bereits bezahlt ist, oder verliert Verhandlungsposition. Jeder der vier Bereiche hat seinen eigenen Rhythmus, seine eigenen Datenquellen und seine eigenen Steuerungsmomente.
Nutzung
Der erste Steuerungsmomente-Bereich befasst sich mit der tatsächlichen Nutzung des SAP-Portfolios: Wie viele Full Use Equivalents (FUE) verbraucht die Organisation aktuell? In welchem Verhältnis steht der BTP-Credit-Verbrauch zum jährlichen Kontingent? Wie entwickeln sich AI-Units und BTP Credits im Burndown-Verlauf? Welche Active Contracts weisen Über- oder Unternutzung auf?
Mit der Einführung des PCE-Metering-Modells (Performance Capacity Equivalent) erfolgt die Nutzungsmessung in S/4HANA Cloud nicht mehr einmal jährlich, sondern monatlich und automatisiert. Das verändert den Steuerungsrhythmus grundlegend: Zu breit angelegte Berechtigungsrollen werden monatlich gemessen und wirken sich unmittelbar auf die Lizenzkosten aus, nicht erst beim nächsten Audit. PCE Metering macht jeden Monat zu einem Steuerungsmoment in der Verbrauchsmessung.
In Cloud-Vertragsmodellen kommt die Verbrauchslogik einzelner Services hinzu. BTP-Credits verfallen in der Regel am Jahresende, wenn sie nicht verbraucht wurden. SAP Business AI-Credits (AI Units) verfallen in der PUPM-Logik (Per User Per Month) sogar monatlich. Burndown-Tracking, also die laufende Beobachtung, wie sich das Kontingent über das Jahr verbraucht, ist die Voraussetzung, um den Steuerungsmoment vor dem Verfall noch nutzen zu können.
Praxishinweis: Die Pflicht zur Messung und Meldung von Übernutzung liegt beim Kunden, nicht beim Anbieter (Quellen: saprisenegotiations.com, saplicensingexperts.com). Diese Self-Report-Pflicht macht eine eigene, verlässliche Nutzungserfassung zu einer vertraglichen Notwendigkeit, nicht nur zu einer optionalen Managementinformation. Der Steuerungsmoment für die Verbrauchsmessung liegt bei jeder monatlichen Metering-Auswertung, nicht erst wenn SAP die Rechnung stellt.
Berechtigungen
Der zweite Steuerungsmomente-Bereich betrifft die Klassifizierung von Rollen und Zugriffsrechten. In S/4HANA Cloud wird die Benutzerlizenzklasse berechtigungsbasiert bestimmt: Hat ein Benutzer eine Berechtigung, die einer Advanced-Lizenz entspricht, wird er als Advanced gezählt, unabhängig davon, ob er diese Berechtigung tatsächlich nutzt. Zu breite Berechtigungsrollen sind damit kein reines Security-Thema, sondern ein direkter FUE-Hebel.
Lizenzklassen wie Advanced, Core und Self-Service unterscheiden sich erheblich in ihrer FUE-Gewichtung. Wer Berechtigungsrollen strukturiert analysiert und überbreite Rollenzuweisungen bereinigt, setzt einen konkreten Steuerungsmoment: die Anpassung der Rollenzuweisung vor dem nächsten monatlichen PCE-Metering-Zyklus. Was nach dem Messzeitpunkt bereinigt wird, wirkt erst im Folgemonat.
Compliance-Bewertung im Bereich Berechtigungen bedeutet, laufend zu prüfen: Entspricht die Rollenstruktur den vertraglichen Lizenzklassen? Sind Test-User und inaktive Accounts aus der aktiven Klassifizierung herausgenommen? Test-User-Bereinigung ist ein häufig unterschätzter Steuerungsmoment, der monatlich relevant ist und sich direkt auf den gemessenen FUE-Bestand auswirkt.
PCE Metering verbindet den Berechtigungsbereich mit dem Nutzungsbereich: Die Messung wird durch Berechtigungen ausgelöst, nicht durch die tatsächliche Aktivität. Wer diese Logik kennt und im Rollenreview anwendet, steuert proaktiv. Wer sie nicht kennt, steuert reaktiv auf Messergebnisse, die sich nicht mehr korrigieren lassen.
Infrastruktur
Der dritte Steuerungsmomente-Bereich umfasst System Sizing, SLA-Tracking und den RISE/On-Prem-Mix. Infrastruktur-Parameter im SAP-Vertragskontext sind nicht nur technische Größen, sondern vertragsrelevante Parameter mit direkter Kostenwirkung.
System Sizing im RISE-Kontext bestimmt die Ressourcenbasis, auf der die Leistungsversprechen des Vertrags aufbauen. Ist das vereinbarte Sizing noch passend zur aktuellen Nutzung und zum erwarteten Wachstum? Ein Sizing-Review ist ein Steuerungsmoment, der spätestens 12 Monate vor einem Renewal angestoßen werden sollte, um bei der Renewal-Verhandlung eine eigene Datenposition zu haben.
SLA-Abgleich bedeutet, die vertraglich vereinbarten Verfügbarkeiten und Service-Level aktiv mit der tatsächlich gemessenen Performance zu vergleichen. RISE with SAP garantiert in der Standardausprägung eine Systemverfügbarkeit von 99,7%, der typische Industriestandard für Enterprise Cloud liegt bei 99,9%. Diese Differenz ist ein Verhandlungsparameter. Wer SLA-Verletzungen nicht innerhalb der vertraglich vorgesehenen Fristen meldet, verliert den Anspruch auf SLA-Credits. Der Steuerungsmoment für den SLA-Audit ist jeder Monat mit gemeldeter Ausfallzeit.
Der RISE/On-Prem-Mix ist ein Bereich, in dem Steuerungsmomente aus der Veränderung der Systemlandschaft entstehen: Werden Workloads von On-Premise auf RISE migriert? Werden On-Premise-Lizenzen als Transition-Grundlage eingesetzt? Fristen der SAP Transition Option begrenzen den Handlungsspielraum. Wer diese Fristen kennt, hat mehr Optionen. Wer sie verpasst, verliert Verhandlungsgrundlage (Quellen: SAP Help Portal, it-daily.net).
Kosten
Der vierte Steuerungsmomente-Bereich verbindet Vertragsstruktur und Nutzung mit der finanziellen Steuerung: ACV-Tracking, Derived Charges, interne Verrechnung, Renewal-Pricing und die strukturelle Budget-Planung.
ACV-Tracking bedeutet, den Annual Contract Value laufend mit dem tatsächlichen Verbrauch abzugleichen. Preisanpassungsklauseln (CPI-Escalation) greifen automatisch zum Beginn eines neuen Vertragsjahres. Wer die Klausel kennt und deren Wirkung berechnet, kann die Budgetplanung belastbar aufbauen. Wer sie nicht kennt, erlebt die Erhöhung als Überraschung auf der nächsten Rechnung. Der Steuerungsmoment für Renewal-Vorbereitung im Kostenbereich liegt 12 bis 18 Monate vor dem Renewal-Datum, nicht im letzten Quartal.
Derived Charges sind Folgegebühren, die durch Aktionen auf Basis des RISE-Hauptvertrags entstehen können. Übernutzung über das vereinbarte Cloud Service-Guthaben hinaus löst eine Verbrauchsgebühr aus, in vielen RISE-Verträgen mit einem Aufschlag von bis zu 15% auf den Standardpreis. Der Steuerungsmoment gegen Übernutzungs-Selbst-Report liegt bei jeder monatlichen Nutzungsauswertung, bevor die Grenze erreicht ist.
BTP-Credit-Verfall ist ein weiterer Steuerungsmoment im Kostenbereich: Wer gegen Jahresende einen hohen ungenutzten Credit-Bestand feststellt, hat kaum noch operative Optionen. Der Steuerungsmoment liegt daher im dritten Quartal, nicht im Dezember.
Das FinOps Inform/Optimize/Operate-Framework, das aus dem Public Cloud-Umfeld bekannt ist, lässt sich auf SAP-Vertragsportfolios übertragen. Im "Inform"-Schritt werden Kostendaten sichtbar: Welche Kostenstelle verbraucht welchen BTP-Service? Im "Optimize"-Schritt werden Steuerungsentscheidungen getroffen: Welche Services werden herunterskaliert, welche Credits vor Verfall genutzt? Im "Operate"-Schritt werden diese Prozesse in den Governance-Rhythmus eingebettet und dauerhaft wiederholt.
Interne Verrechnung von SAP-Cloud-Kosten setzt eine Governance-Datenbasis voraus, die Nutzung auf Service-Ebene mit Vertragskosten verbindet. Klassische SAP-eigene Werkzeuge bieten Nutzungsmonitoring auf Systemebene, aber keine direkte Grundlage für einen FinOps-konformen Chargeback auf Kostenstellen. Ohne diese Grundlage bleibt die interne Kostenverteilung eine Schätzung auf Basis von Pauschalen, keine verursachergerechte Abrechnung.
Vier Rollen, ein Steuerungsmodell {#vier-rollen-ein-steuerungsmodell}
SAP Contract Governance liegt an der Schnittstelle mehrerer Unternehmensfunktionen. Keine dieser Funktionen hat allein alle Informationen, die für eine fundierte Steuerung nötig wären. Ein Steuerungsmodell, das nachhaltig funktioniert, benennt jede Rolle mit ihren konkreten Steuerungsmomenten und klärt, wie die vier Perspektiven verbunden werden.
Contract Manager
Der Contract Manager hält die inhaltliche Grundlage jeder Steuerungsentscheidung: Vertragsstruktur, Compliance und laufende Steuerung über alle Amendments, Schedules, Order Forms und ergänzende Vereinbarungen. In der Praxis ist dieses Bild nicht immer vollständig konsolidiert, weil Vertragsänderungen über mehrere Jahre und mündlich vereinbarte Sonderregelungen eine Ausgangslage schaffen, die Interpretation erfordert statt klarer Auskunft.
Die Kernaufgaben umfassen die Pflege der vollständigen Vertragsbaseline, die Dokumentation aller vertragsrelevanten Fristen (Kündigung, Renewal-Ankündigung, Mindestlaufzeiten, Co-Termination) und die Compliance-Prüfung: Entspricht die aktuelle Nutzung den vereinbarten Bedingungen?
Die Steuerungsmomente des Contract Managers liegen bei jeder relevanten Vertragsänderung (Amendments, Hinzunahme neuer Produkttypen), bei der Bewertung von Klauseln in konkreten Situationen (Übernutzung, Audit, CPI-Anpassung) und bei der Vorbereitung der Renewal-Baseline. Ohne belastbare Vertragsbaseline kann keine andere Rolle sauber steuern. Der Contract Manager liefert die gemeinsame Informationsgrundlage.
Procurement
Procurement hält die Beziehung zu SAP als Lieferanten: Einkaufsentscheidungen, Konditionen, Renewal-Optionen und die kommerzielle Verhandlungsführung. Diese Rolle kennt die Gesamthistorie der Lieferantenbeziehung, einschließlich früherer Rabattstrukturen, besonderer Vereinbarungen und der Tonlage bisheriger Verhandlungen.
Die spezifische Herausforderung bei SAP: SAP ist ein strategischer Anbieter ohne direkten Wettbewerb auf Vertragsebene. Renewal-Verhandlungen laufen unter Zeitdruck, wenn SAP die Initiative ergreift. Die Stärke der eigenen Verhandlungsposition hängt direkt davon ab, wie gut die eigene Datenbasis ist.
Die Steuerungsmomente von Procurement liegen bei der strukturierten Renewal-Vorbereitung (typischerweise 12 bis 18 Monate vor Renewal-Datum, Quelle: saplicensingexperts.com, saprisenegotiations.com), bei der Bewertung neuer SAP-Angebote im Kontext des bestehenden Portfolios und bei der Verhandlung von Konditionen auf Basis aktueller Verbrauchsdaten. Renewal-Verhandlungen ohne aktuelle Nutzungsanalyse und ohne fundierte Klausel-Kenntnis sind strukturell benachteiligt. Procurement braucht Input von Contract Manager und Controlling, bevor SAP das erste Angebot vorlegt.
Controlling
Controlling verantwortet Kostenallokation, Rechnungsprüfung und Budgetklarheit für das SAP-Vertragsportfolio. SAP-Kosten sind in vielen Enterprise-Organisationen ein zweistelliger Millionenbetrag im IT-Budget. Wie gut diese Position geplant, erklärt und gesteuert werden kann, hängt direkt von der Qualität der Vertrags- und Nutzungsdaten ab.
Die strukturelle Herausforderung ist die Verbindung zwischen Vertragsbedingungen und Budget-Auswirkungen: Preisanpassungsklauseln (CPI-Escalation), Credit-Verfall, Übernutzungsgebühren und mögliche SLA-Korrekturen sind Vertragsdetails mit unmittelbarer Budget-Wirkung. Wer die Klauseln kennt, kann belastbar planen. Wer sie nicht kennt, plant mit Unbekannten.
Die Steuerungsmomente von Controlling liegen beim Budget-Forecast auf Basis des tatsächlichen Verbrauchstrends, bei der Rechnungsprüfung auf Abweichungen gegenüber dem Vertragsstand und bei der internen Kostenallokation: Welche Geschäftsbereiche oder Kostenstellen verursachen welche SAP-Kosten? Die Verbindung von Vertragskosten mit Nutzungsdaten auf Service-Ebene ist eine Governance-Aufgabe, die Controlling und Contract Manager gemeinsam lösen müssen.
Executive
Die Executive-Ebene, typischerweise VP IT, CIO oder Geschäftsführung, setzt Prioritäten, gibt Freigaben und trifft Renewal-Entscheidungen mit strategischer Bindungswirkung. Diese Ebene ist selten in der laufenden Steuerung aktiv, muss aber in definierten Situationen schnell und fundiert entscheiden können.
Das Governance-Modell muss sicherstellen, dass die relevanten Informationen verdichtet und entscheidungsreif vorliegen, wenn die Executive-Rolle gefragt ist: Freigabe von Renewal-Entscheidungen und wesentlichen Vertragsveränderungen, Priorisierung strategischer SAP-Investitionen im Kontext der IT-Gesamtstrategie, Einschätzung von Risiken auf Portfolioebene (Laufzeitverpflichtungen, Abhängigkeiten, Exit-Optionen).
Die Steuerungsmomente des Executive liegen bei strategischen Weichenstellungen: Migration, Portfoliobereinigung, neue Produkttypen, Eskalation bei kritischen Vertragsrisiken. Entscheidungen, die auf dieser Ebene getroffen werden, müssen auf einer belastbaren Grundlage stehen. Wenn die Datenbasis der anderen Rollen lückenhaft ist, überträgt sich das direkt auf die Entscheidungsqualität.
Wie die vier Rollen zusammenarbeiten
Ein Steuerungsmodell ist mehr als eine Rollenbeschreibung. Es definiert, wann welche Rollen zusammenarbeiten, auf welcher Datenbasis und mit welchem Ergebnis. Ohne definierten Rhythmus entsteht Governance nur dann, wenn ein Ereignis sie erzwingt.
In der Praxis koordiniert der Director SAP Plattform die vier Rollen. Er ist die Zielgruppe des Steuerungsmodells, nicht eine der vier Rollen selbst. Er kennt die Systemlandschaft, die Nutzung und die technischen Abhängigkeiten und führt die Perspektiven von Contract Manager, Procurement, Controlling und Executive zusammen.
Monatlich liefert Contract Manager die aktualisierte Vertragsbaseline, Controlling konsolidiert Verbrauch und Budget-Abweichungen. Quartalsweise treffen alle vier Rollen zusammen: Vertragsportfolio-Status, Budget-Perspektive, laufende Steuerungsmomente (Rightsizing, Amendment-Optionen, Renewal-Vorbereitung). Jährlich wird der strategische Review eingebettet in den Budget-Planungsprozess, mit Priorisierung aller Renewals im 12 bis 18 Monate-Horizont.
Die gemeinsame Datenbasis ist die Voraussetzung dafür, dass diese Rhythmen funktionieren. Wenn jede Rolle mit eigenen Zahlen arbeitet und keine konsolidierte Governance-Sicht existiert, entstehen im Review-Meeting Diskussionen über die Zahlen statt über die Steuerungsmomente, die handlungsreif wären. In größeren Organisationen übernimmt ein SAP Center of Excellence (CCoE) die Koordinationsfunktion, in mittelgroßen Unternehmen liegt sie beim Director SAP Plattform.
SAP Contract Governance über alle neun SAP-Produkttypen {#sap-contract-governance-ueber-alle-neun-sap-produkttypen}
SAP Contract Governance ist kein RISE-spezifisches Thema. Zwar ist RISE with SAP der volumenstärkste und vertraglich komplexeste Produkttyp in vielen Enterprise-Portfolios, aber die Governance-Anforderungen entstehen über alle SAP-Produkte. Ein vollständiges Steuerungsmodell muss alle neun relevanten Produkttypen berücksichtigen.
RISE with SAP: Enterprise Agreement und Credit-Mechanik
RISE with SAP ist strukturell ein Enterprise Agreement (EA) mit drei Säulen: Cloud Managed Services (Betrieb, Systemverfügbarkeit, Basis-Support), Cloud Software (S/4HANA Cloud, SAP BTP inklusive eines Grundkontingents, Signavio als gebündeltes Werkzeug) und Cloud Application Services (optionale Zusatzleistungen).
Das finanzielle Kernmodell ist das jährliche Cloud Service-Guthaben (Annual Cloud Service Credit). Dieses Guthaben kann für verbrauchsabhängige Services eingesetzt werden. Ein Teil des nicht genutzten Guthabens kann vertraglich in das Folgejahr übertragen werden (Roll-over), üblicherweise bis zu einem definierten Prozentsatz. Am Ende der Gesamtvertragslaufzeit verfällt ungenutztes Guthaben vollständig (Quelle: saprisenegotiations.com, saplicensingexperts.com).
Governance-kritische Parameter bei RISE:
Bei Übernutzung über das vereinbarte Guthaben hinaus fällt eine Verbrauchsgebühr zuzüglich eines Aufschlags an. Gleichzeitig sind SLA-Garantien in der Übernutzungsphase eingeschränkt (Quelle: saprisenegotiations.com). Die Pflicht zur Messung und schriftlichen Meldung von Übernutzung liegt beim Kunden.
Mindestlaufzeiten gelten für einzelne Komponenten innerhalb des RISE-Vertrags. Co-Termination-Regelungen bestimmen, ob ergänzende Vertragskomponenten mit dem Hauptvertrag synchronisiert enden oder separate Laufzeiten haben.
Auto-Renewal-Fristen sind ein häufig unterschätzter Governance-Parameter: SAP-Verträge beinhalten häufig Kündigungsfristen von mehreren Monaten vor Vertragsende. Wer diese Frist verpasst, verlängert automatisch zu den bestehenden Konditionen. Bei mehrjährigen RISE-Verträgen kann das Kündigungsfenster 12 oder mehr Monate vor Vertragsende liegen.
SAP BTP und CPEA/BTPEA: Credit-Verbrauch und Verfall
SAP BTP (Business Technology Platform) wird in Cloud-Portfolios über das Cloud Platform Enterprise Agreement (CPEA) oder das BTP Enterprise Agreement (BTPEA) lizenziert. Das Kernmodell sind Credits, die gegen eine Vielzahl von BTP-Services verbraucht werden können.
Ein Governance-kritischer Aspekt: BTP-Credits verfallen in der Regel am Ende des Vertragsjahres, wenn sie nicht verbraucht wurden. Im Gegensatz zum RISE-Roll-over-Mechanismus ist ein Übertrag ungenutzter BTP-Credits in das Folgejahr nicht in allen Vertragsmodellen vorgesehen. Wer gegen Ende des Jahres einen hohen ungenutzten Credit-Bestand feststellt, hat kaum noch Optionen (Quelle: SAP Community Blogs, saplicensingexperts.com).
Die Verbrauchslogik folgt den sogenannten Depreciation Groups: BTP-Services werden in zwei Gruppen eingeteilt, die unterschiedlich stark auf das Credit-Kontingent angerechnet werden. Group-1-Services verbrauchen Credits im Verhältnis 1:1, Group-2-Services zu einem anderen Satz. Wer seinen BTP-Service-Mix kennt, kann den Credit-Verbrauch vorausplanen.
SAP Business AI Units (auch PUPM: Per User Per Month) haben eine eigene Verbrauchslogik. Ungenutzte AI-Requests verfallen monatlich, nicht jährlich. Wer AI-Units in seinem Vertrag hat und den Verbrauch nicht monatlich verfolgt, verliert regelmäßig genutztes Budget ohne Kompensation.
S/4HANA Cloud (Public und Private Edition)
S/4HANA Cloud ist das Kernsystem in RISE-Verträgen, kann aber auch eigenständig als Cloud-ERP-System genutzt werden. Die Vertragssteuerung umfasst vor allem die FUE-basierte Nutzungsmessung (Full Use Equivalents), die Benutzerklassifizierung (Advanced, Core, Self-Service) und das monatliche Metering.
Governance-Aspekt Berechtigungsrollen: In S/4HANA Cloud wird die Benutzerlizenzklassifizierung berechtigungsbasiert durchgeführt. Hat ein Benutzer eine Berechtigung, die einer Advanced-Lizenz entspricht, wird er als Advanced gezählt, unabhängig davon, ob er diese Berechtigung tatsächlich nutzt. Zu breite Berechtigungsrollen sind damit nicht nur ein Security-Thema, sondern haben direkte Auswirkungen auf die Lizenzkosten.
On-Premise SAP: Maintenance und Transition
SAP-On-Premise-Lizenzen sind für viele Unternehmen weiterhin Teil des Portfolios. Das Ende des Extended Mainstream Maintenance für SAP ECC 6.0 und SAP Business Suite ist ein zentraler Planungsparameter: SAP hat das Ende des Mainstream Maintenance für ältere ECC-Versionen kommuniziert. Extended Maintenance mit Aufschlag auf die Standard-Maintenance-Rate ist für definierten Zeitraum verfügbar (Quelle: SAP Help Portal, it-daily.net).
Die SAP Transition Option ermöglicht es, bestehende On-Premise-Lizenzen als Ausgangsbasis für eine RISE-Migration anzurechnen. Diese Option hat zeitliche Fristen, die für die strategische Planung relevant sind. Bestehende On-Premise-Lizenzen haben damit einen Wert als Verhandlungsgrundlage, der aktiv eingesetzt werden kann.
Governance-relevant: Wer On-Premise-Lizenzen hat, die nicht mehr genutzt werden (Shelfware), kann diese als Verhandlungsgrundlage beim RISE-Übergang nutzen. Die Identifikation und Dokumentation von Shelfware ist eine Governance-Aufgabe, die frühzeitig beginnen sollte.
Ein weiterer Governance-Parameter im On-Premise-Bereich ist die SAP Extended Maintenance. Diese wird mit einem Aufschlag auf die Standard-Maintenance-Rate berechnet, der in der Vertragsplanung berücksichtigt werden sollte. Wer Extended Maintenance in Anspruch nimmt, sollte die Kostenwirkung kennen und sie aktiv in die Budget-Planung einbeziehen, anstatt sie als unvermeidlichen Posten zu akzeptieren. In Kombination mit den Fristen der SAP Transition Option ergibt sich ein Steuerungsfenster, das strategisch genutzt werden kann: Die Transition Option hat Fristen. Wer die Fristen kennt und rechtzeitig plant, hat mehr Optionen als wer sie passiv verstreichen lässt (Quellen: SAP Help Portal, it-daily.net).
SuccessFactors, Ariba, Concur, IBP und Signavio
Diese Produkttypen haben unterschiedliche Vertragslogiken und oft separate Renewal-Zyklen. Governance-relevante Besonderheiten:
SuccessFactors folgt einem jährlichen Renewal, das nicht zwingend mit dem RISE-Renewal synchronisiert ist. Co-Termination sollte aktiv geplant werden, wenn eine einheitliche Vertragsstruktur gewünscht ist.
Ariba berechnet Transaktionsgebühren auf dem Ariba Network zusätzlich zur Grundlizenz. Diese variablen Gebühren sind oft schwer vorherzusagen und erfordern eine eigene Monitoring-Logik.
Concur lizenziert per User per Month, was bei Mitarbeiterfluktuation oder Organisationsveränderungen zu Abweichungen zwischen tatsächlich genutzten und lizenzpflichtigen Usern führen kann.
Signavio ist in vielen RISE-Verträgen als gebündeltes Werkzeug enthalten. Ob es bei einem Renewal weiterhin gebündelt ist oder separat lizenziert wird, ist eine Governance-Frage, die spätestens 12 Monate vor dem Renewal geklärt werden sollte.
IBP (Integrated Business Planning) hat ein Per-User-Preismodell mit eigenen Lizenztypen und ist bei Planungsrollenveränderungen im Unternehmen governance-relevant.
Sonderfälle: Business AI, Digital Access, M&A {#sonderfaelle-business-ai-digital-access-ma}
Drei Themenbereiche tauchen in praktisch jedem SAP-Vertragsportfolio auf, werden aber selten als Teil der laufenden Governance gedacht. Sie entstehen nicht beim Vertragsabschluss, sondern entwickeln sich während der Vertragslaufzeit. Dieser Abschnitt gibt einen Überblick; jedes Thema wird in einem eigenständigen Artikel vertieft.
SAP Business AI und Joule
SAP Business AI ist ein wachsendes Themenfeld innerhalb von RISE- und BTP-Verträgen. Wer SAP Joule oder andere AI-Funktionen aus dem SAP Business AI-Portfolio nutzt, sollte die Lizenzmechanik kennen.
AI Units sind das zentrale Verrechnungsmodell für viele SAP-AI-Funktionen. Sie werden in der Regel als PUPM (Per User Per Month) zugeteilt: Eine definierte Anzahl von AI-Requests pro aktiviertem Benutzer pro Monat. Ungenutzte PUPM-Requests verfallen monatlich, nicht am Jahresende (Quelle: SAP Help Portal, SAP Community). Wer AI-Nutzung nicht monatlich trackt, verliert regelmäßig bereits bezahlte Kapazität.
Die Bepreisung von SAP Business AI ist mehrschichtig: Ein Teil ist in RISE-Verträgen oder BTP-Kontingenten enthalten, ein Teil wird über eigenständige Add-ons lizenziert. Welche Funktionen in welchem Umfang enthalten sind und welche zusätzlich lizenziert werden müssen, ist je nach Vertragsversion unterschiedlich und hat sich in 2024/2025-Verträgen verändert.
Governance-Anforderung: AI-Verbrauch auf Nutzer, Abteilung und Usecase zu verfolgen und mit dem vertraglich eingeschlossenen Kontingent abzugleichen. Bei Übernutzung entstehen zusätzliche Kosten. Dieser Vertiefung ist ein eigenständiger Artikel gewidmet.
Digital Access und Indirect Access
Digital Access betrifft Szenarien, in denen Drittanbieter-Systeme auf SAP-Daten zugreifen oder SAP-Transaktionen auslösen, ohne dass ein menschlicher SAP-Nutzer direkt beteiligt ist. SAP hat 2018 das Digital Access-Lizenzmodell eingeführt, um diesen Bereich zu strukturieren.
In der Praxis entstehen Governance-Fragen, wenn CRM-Systeme, E-Commerce-Plattformen, IoT-Schnittstellen oder andere Drittsysteme SAP-Daten lesen oder schreiben. Welche dieser Integrationen unter den Digital Access-Rahmen fallen und welche kostenfrei inkludiert sind, ist im Einzelfall zu prüfen (Quellen: redresscompliance.com, saprisenegotiations.com).
In RISE-Verträgen sind bestimmte Digital Access-Szenarien im Standard enthalten, andere erfordern eine gesonderte Lizenzierung. Wer seinen Integrationsbestand nicht dokumentiert und laufend auf Lizenzrelevanz prüft, kann bei SAP-Audits in eine Situation geraten, in der nachträgliche Lizenzierungspflichten entstehen. Eine vollständige Behandlung dieses Themas folgt in einem eigenständigen Artikel.
M&A, Carve-out und Vertragstransfer
Unternehmensübernahmen, Fusionen und Carve-outs haben direkte Auswirkungen auf bestehende SAP-Verträge. Diese Situationen entstehen während der laufenden Vertragslaufzeit und sind selten im Originalvertrag explizit geregelt.
Bei einer Übernahme stellt sich die Frage, ob der erwerbende Konzern automatisch in bestehende SAP-Verträge des übernommenen Unternehmens eintritt oder ob eine neue Vertragsstruktur erforderlich ist. Affiliate Licensing-Klauseln regeln, welche verbundenen Unternehmen im Rahmen des bestehenden Vertrags SAP nutzen dürfen. Ihr Fehlen oder ihre eingeschränkte Formulierung kann bei M&A-Transaktionen zu Compliance-Risiken führen (Quellen: redresscompliance.com, saprisenegotiations.com).
Übernommene Unternehmen können bestehende SAP-Lizenzprobleme mitbringen: Unterlizenzen, nicht gemeldete Übernutzungen oder abgelaufene Wartungsverträge. Eine Due-Diligence der SAP-Vertragslandschaft vor dem Closing ist eine anerkannte Best Practice. Dieser Themenbereich wird in einem eigenständigen Artikel vollständig behandelt.
Self-Service oder Managed Service {#self-service-oder-managed-service}
SAP Contract Governance kann auf zwei grundlegend unterschiedliche Weisen organisiert werden: als Self-Service-Modell, bei dem das eigene Team die Plattform und die Steuerungsentscheidungen selbst übernimmt, oder als Managed Service-Modell, bei dem ein spezialisiertes externes Team die laufende Steuerung übernimmt.
Beide Modelle nutzen dieselbe Plattform, dieselben Analysemethoden und dieselbe Datenbasis. Der Unterschied liegt in der Aufteilung der operativen Steuerungsarbeit zwischen internem Team und externem Experten.
Wann Self-Service sinnvoll ist
Das Self-Service-Modell passt zu Organisationen, die eigene Vendor-Management- oder FinOps-Kapazitäten aufgebaut haben und diese für die SAP-Vertragssteuerung einsetzen wollen. Voraussetzungen sind: ausreichend Kapazität im Team für laufende Analyse und Steuerung, Bereitschaft, SAP-Vertragswissen intern aufzubauen, und ein klarer interner Governance-Prozess mit definierten Verantwortlichkeiten.
Das Self-Service-Modell gibt dem internen Team die vollständige Steuerungshoheit: eigene Analysen, eigene Entscheidungsgrundlagen, eigene Zeitplanung. Wissen bleibt im Unternehmen und wächst mit jeder Vertragsperiode.
Wann Managed Service sinnvoll ist
Das Managed Service-Modell ist geeignet, wenn das interne Team die SAP-Vertragssteuerung nicht mit ausreichender Tiefe abdecken kann oder wenn die Komplexität des Portfolios ein Niveau erreicht hat, das spezialisiertes Know-how erfordert. Typische Situationen: ein RISE-Renewal steht in 18 Monaten bevor, das Portfolio umfasst mehrere Produkttypen mit heterogenen Vertragsstrukturen, oder eine M&A-Transaktion hat die Komplexität sprunghaft erhöht.
Im Managed Service-Modell übernimmt ein festes externes Team die laufende Analyse, liefert wöchentliche Handlungsempfehlungen und stellt eine einheitliche Governance-Struktur sicher. Das interne Team behält die Entscheidungshoheit: was getan wird, entscheidet der Auftraggeber. Das externe Team stellt die Analyse und die Empfehlung bereit.
Wechsel zwischen den Modellen
Ein Aspekt, der in der Praxis relevant ist: Der Wechsel zwischen Self-Service und Managed Service sollte ohne Datenverlust möglich sein. Wenn beide Modelle dieselbe Plattform nutzen, bleibt die aufgebaute Dokumentation, die historischen Analysedaten und die Verhandlungshistorie erhalten, unabhängig davon, welches Servicemodell gewählt wird. Das ermöglicht eine Anpassung der Governance-Tiefe an veränderte interne Kapazitäten oder an neue Anforderungen, die sich im Laufe der Vertragslaufzeit ergeben.
Pricing-Modell
Beide Modelle werden über den Annual Contract Value (ACV) der verwalteten Verträge bepreist. Das Self-Service-Modell berechnet 1,5% des ACV der unter Governance gestellten Verträge pro Jahr. Das Managed Service-Modell berechnet 2,2% des ACV. Floor und Cap werden individuell vereinbart.
Dieser ACV-basierte Ansatz verbindet den Governance-Aufwand direkt mit dem Vertragsvolumen: Ein größeres Portfolio mit höherem ACV erzeugt entsprechend mehr Steuerungsaufwand und wird entsprechend bepreist.
Post-signature versus pre-signature {#post-signature-versus-pre-signature}
Eine der häufigsten Fragen in Gesprächen über SAP Contract Governance ist: Wie verhält sich diese Disziplin zur Vertragsverhandlung und zur juristischen Vertragsgestaltung?
Die Abgrenzung ist klar, aber beide Phasen sind voneinander abhängig.
Pre-signature: Verhandlung und Vertragsgestaltung
Die Pre-Signature-Phase umfasst alles, was vor der Unterzeichnung eines Vertrags liegt: Bedarfsanalyse, RFP-Prozess, Verhandlung von Preisen und Klauseln, juristische Prüfung, Vertragsstrukturierung. Diese Phase hat typischerweise Projektcharakter, wird von Einkauf, Rechtsabteilung und gegebenenfalls externen SAP-Verhandlungsspezialisten begleitet und endet mit der Unterzeichnung.
Das Ziel der Pre-Signature-Phase ist ein möglichst günstiger und flexibler Vertragsabschluss. Was in dieser Phase nicht ausverhandelt oder in den Vertrag hineingeschrieben wird, ist später schwer nachzuverhandeln.
Post-signature: Laufende Steuerung
Die Post-Signature-Phase beginnt mit dem ersten Tag nach der Unterzeichnung und endet mit dem letzten Tag der Vertragslaufzeit. Sie ist keine Phase im klassischen Projektsinn, sondern ein kontinuierlicher Prozess.
SAP Contract Governance ist eine Post-Signature-Disziplin. Sie setzt voraus, dass ein Vertrag existiert, und organisiert die Steuerung über seine gesamte Laufzeit.
Was in der Post-Signature-Phase entschieden wird, ist mindestens genauso wertvoll wie das Verhandlungsergebnis der Pre-Signature-Phase: Wer seinen Verbrauch kennt, vermeidet ungewollte Übernutzungen. Wer kritische Klauseln versteht, kann rechtzeitig handeln, bevor sie wirken. Wer 18 Monate vor dem Renewal eine belastbare Datenbasis hat, verhandelt aus einer anderen Position als jemand, der sechs Monate vorher mit der Vorbereitung beginnt.
Was Post-Signature-Governance in der Praxis bedeutet
Post-Signature-Governance ist keine einmalige Aktivität, sondern ein Steuerungsrhythmus mit unterschiedlichen Kadenzebenen.
Monatlich sind folgende Governance-Aktivitäten sinnvoll: Auswertung der aktuellen FUE-Vermessung, Review des BTP-Credit-Verbrauchs im Vergleich zum Jahresplan, Prüfung auf neue SAP-Rechnungen und Abgleich mit dem Vertragsbasis, Update des internen Kostenreportings.
Quartalsweise empfiehlt sich: ein übergeordneter Review der Vertragsperformance (Nutzung vs. Budget), eine Einschätzung der Verhandlungsposition für das nächste Renewal, ein Abgleich von vertragsrelevanten Änderungen in der eigenen Organisation (neue Tochtergesellschaften, veränderte Benutzerstrukturen, neue Projekte auf BTP).
Jährlich steht an: eine vollständige Bestandsaufnahme des SAP-Vertragsportfolios, eine Bewertung aller anstehenden Renewals der nächsten zwei Jahre, und eine Einschätzung, ob das bestehende Governance-Modell den veränderten Anforderungen noch entspricht.
Dieser dreistufige Rhythmus ist das Fundament einer kontinuierlichen Post-Signature-Governance. Er lässt sich anpassen: Wer ein besonders komplexes Portfolio hat oder ein Renewal in Kürze bevorsteht, braucht möglicherweise eine engere Kadenz in bestimmten Bereichen. Das Prinzip bleibt: Governance ist ein kontinuierlicher Prozess, kein Projekt mit Enddatum.
Die Verbindung zwischen beiden Phasen
In der Praxis ist die Verbindung zwischen Pre- und Post-Signature oft schwächer als sie sein sollte. Vertragsdetails, die in der Pre-Signature-Phase vereinbart wurden, sind der Post-Signature-Governance nicht immer vollständig bekannt. Wer das Vertragsportfolio übernimmt, beginnt typischerweise damit, die bestehenden Dokumente zu lesen, Fragen zu klären und die relevanten Parameter herauszuarbeiten. Dieser Startaufwand ist real, er entsteht einmalig pro Vertrag und kann strukturiert bearbeitet werden.
Die stärkste Form der Verbindung entsteht am Übergang in das nächste Renewal: Die Post-Signature-Governance, die während der gesamten Vertragslaufzeit aufgebaut wurde, wird zur Grundlage der nächsten Pre-Signature-Phase. Verhandlungshistorie, Verbrauchsdaten, Klausel-Bewertungen und identifizierte Verbesserungspunkte fließen direkt in die Renewal-Vorbereitung ein. Dokumentation und Verhandlungsbasis wachsen mit jeder Vertragsperiode.
Warum Post-Signature selten systematisch organisiert ist
Governance nach Vertragsabschluss erfordert Kontinuität. Die Pre-Signature-Phase hat einen klaren Abschluss (Unterzeichnung) und ein klares Team (Einkauf, Recht, Management). Die Post-Signature-Phase hat keinen klaren Abschluss, kein dediziertes Team und in vielen Organisationen keine definierte Zuständigkeit.
Das ist keine Frage fehlender Expertise, sondern eine strukturelle Frage: Wer ist dauerhaft verantwortlich? Mit welchen Informationen? In welchem Rhythmus? Diese Strukturfrage zu beantworten, ist der erste Schritt in eine systematische SAP Contract Governance.
SAP Contract Governance Reifegradmodell {#sap-contract-governance-reifegradmodell}
Wo steht Ihre Organisation heute in der SAP Contract Governance? Ein Reifegradmodell hilft, den Status quo einzuordnen und realistische nächste Schritte zu identifizieren. Es gibt keinen universell richtigen Reifegrad, aber es gibt eine Richtung: von reaktiver Steuerung zu proaktiver Governance, von Datenfragmentierung zu integrierter Datenbasis.
Stufe 1: Reaktiv
Auf der ersten Stufe erfolgt SAP Contract Governance ausschließlich reaktiv. Handlungen werden ausgelöst, wenn SAP einen Schritt einleitet: Renewal-Angebot, Rechnung mit Abweichungen, Vermessungsergebnis. Das eigene Team reagiert auf Ereignisse, ohne eine vorbereitende Datenbasis zu haben.
Typische Kennzeichen: Vertragsdokumente sind vorhanden, aber nicht strukturiert aufgearbeitet. Nutzungsdaten werden nicht laufend erhoben. Budget-Abweichungen werden nachträglich erklärt, nicht vorausschauend erkannt. Renewal-Vorbereitung beginnt, wenn SAP das Renewal einleitet.
Organisationen auf dieser Stufe haben keine strukturellen Defizite, sondern typischerweise keine dedizierte Governance-Funktion. Die Steuerung erfolgt nebenbei, und das ist angesichts der Vertragsvolumina eine Risikoquelle.
Stufe 2: Dokumentiert
Auf der zweiten Stufe existiert eine strukturierte Vertragsdokumentation. Verträge sind aufgearbeitet, Fristen sind bekannt, relevante Klauseln sind identifiziert. Das Unternehmen weiß, was es hat, aber steuert noch nicht systematisch darauf.
Typische Kennzeichen: Ein Vertragsregister existiert. Renewal-Fristen sind im Kalender. Nutzungsdaten werden erhoben, aber nicht regelmäßig ausgewertet. Budget-Planung basiert auf Vorjahresdaten mit Aufschlag.
Diese Stufe ist für viele Unternehmen der Ausgangspunkt, der nach einem Vertragscheck oder einer internen Aufarbeitung erreicht wird. Sie ist besser als reine Reaktivität, aber noch keine kontinuierliche Steuerung.
Stufe 3: Operativ
Auf der dritten Stufe ist Governance in den Betriebsrhythmus eingebettet. Nutzungsdaten werden monatlich ausgewertet. Budget-Forecast basiert auf Verbrauchsdaten und Vertragslogik. Renewal-Vorbereitung startet strukturiert mit ausreichend Vorlaufzeit.
Typische Kennzeichen: Monatliches SAP-Kosten-Reporting für das Management. BTP-Credit-Verbrauch wird quartalsweise reviewed. Berechtigungsrollen werden auf FUE-Implikationen geprüft. Renewal-Prozess startet 12 Monate vor Vertragsende.
Diese Stufe ermöglicht planbare Budgets und eine informierte Verhandlungsposition beim Renewal.
Stufe 4: Analytisch
Auf der vierten Stufe werden Szenarioanalysen und Forecasts eingesetzt. Was passiert bei einer Nutzungssteigerung um 20%? Wie wirkt eine CPI-Anpassung auf den ACV im Folgevertrag? Welche Klauseln haben bei einer M&A-Transaktion Relevanz?
Diese Stufe setzt eine integrierte Datenbasis voraus, die Vertrags-, Nutzungs- und Kostendaten verbindet, sowie die analytische Kapazität, Szenarien zu modellieren.
Stufe 5: Strategisch
Auf der höchsten Stufe ist SAP Contract Governance ein strategisches Steuerungsinstrument. SAP-Vertragsstruktur und -nutzung werden aktiv als Teil der IT-Strategie gesteuert. Renewal-Verhandlungen werden langfristig vorbereitet und mit Businessfall-Überlegungen verbunden. Die Vertragsstruktur wird bewusst an die Unternehmensentwicklung angepasst.
Diese Stufe ist für größere SAP-Portfolios und Unternehmen mit hoher SAP-Abhängigkeit relevant. Sie erfordert kontinuierliche Governance-Kapazität und eine enge Verzahnung von IT-Strategie, Einkauf und Finance.
Einordnung und nächste Schritte
Ein ehrlicher Blick auf die eigene Organisation zeigt meistens, dass viele Unternehmen zwischen Stufe 1 und Stufe 2 stehen, manchmal zwischen Stufe 2 und Stufe 3. Das ist kein Urteil, sondern ein Ausgangspunkt. Der praktische erste Schritt ist häufig ein strukturierter Vertragscheck, der die Datenbasis für Stufe 2 oder 3 schafft.
Entscheidend ist auch die Frage, bei welcher Stufe eine Organisation realistische Governance-Ziele setzen sollte. Nicht jede Organisation muss Stufe 5 anstreben. Für viele ist eine gut etablierte Stufe 3 bereits ein erheblicher Fortschritt gegenüber dem Status quo, und der Nutzen in Form von planbareren Budgets, besser vorbereiteten Renewals und frühzeitig erkannten Verbrauchsabweichungen ist spürbar. Das Reifegradmodell dient der Orientierung, nicht der Perfektion.
SLA und kritische Klauseln verstehen {#sla-und-kritische-klauseln-verstehen}
Vertragssteuerung beginnt mit dem Lesen der Klauseln, die im Alltag nicht greifen, aber im Streit- oder Grenzfall entscheidend sind. Für RISE-Verträge und andere SAP-Cloud-Vereinbarungen gibt es eine Reihe von Klauseltypen, die besondere Aufmerksamkeit verdienen.
SLA-Verfügbarkeit bei RISE: 99,7% versus Industriestandard
RISE with SAP garantiert in der Standardausprägung eine Systemverfügbarkeit von 99,7% (Quelle: SAP Help Portal, saprisenegotiations.com). Der typische Industriestandard für Enterprise Cloud-Dienste liegt bei 99,9%. Diese Differenz von 0,2 Prozentpunkten klingt gering, entspricht aber einem Unterschied von circa 17 Stunden tolerierbarer Ausfallzeit im Jahr (99,7%) gegenüber circa 8,7 Stunden (99,9%).
Für Unternehmen mit kritischen Produktionssystemen auf RISE ist dieses Delta ein Verhandlungsparameter. SLA-Upgrades auf höhere Verfügbarkeitszusagen sind in manchen Vertragskonstellationen verhandelbar, kommen aber nicht standardmäßig.
SLA-Credits sind die vertraglich vorgesehene Kompensation bei SLA-Verletzungen. In vielen SAP-Verträgen ist der Prozess für die Geltendmachung von SLA-Credits an Fristen und Meldeformen gebunden. Wer eine SLA-Verletzung nicht innerhalb der vertraglich definierten Frist meldet, verliert den Anspruch auf Kompensation. Die Kenntnis dieses Prozesses ist ein Governance-Detail, das im Alltag selten gebraucht wird, aber im Ernstfall entscheidend ist.
Übernutzung und Derived Charges
Wenn der Verbrauch über das vereinbarte Cloud Service-Guthaben hinausgeht, entsteht eine Verbrauchsgebühr (Overage). Bei RISE-Verträgen kann auf Overages ein Aufschlag von bis zu 15% auf den Standardpreis des überschrittenen Services erhoben werden (Quelle: saprisenegotiations.com).
Weniger bekannt, aber vertragsrelevant: Die Pflicht zur Messung und schriftlichen Meldung von Übernutzung liegt beim Kunden. Wer seinen Verbrauch nicht laufend trackt, erfährt von einer Übernutzung möglicherweise erst, wenn SAP die entsprechende Gebühr in Rechnung stellt, zu einem Zeitpunkt, an dem keine präventive Steuerung mehr möglich ist.
Derived Charges sind Folgegebühren, die durch Aktionen auf Basis des RISE-Hauptvertrags entstehen können, zum Beispiel durch die Aktivierung von Zusatzdiensten oder durch nicht in der Basislizenz enthaltene Leistungen. Ihre genaue Definition und Berechnung ist ein Aspekt, der im Vertragstext und in der Order Form detailliert beschrieben ist.
CPI-Escalation-Klausel: Preisanpassung im laufenden Vertrag
Viele SAP-Verträge beinhalten eine Preisanpassungsklausel, die eine jährliche Erhöhung des ACV auf Basis eines Consumer Price Index (CPI) oder eines vereinbarten Prozentsatzes ermöglicht. Diese Klausel greift automatisch zum Beginn eines neuen Vertragsjahres, ohne dass sie aktiv ausgelöst werden muss.
Governance-relevant sind zwei Aspekte: Erstens sollte die Klausel bei der Budget-Planung berücksichtigt werden, damit eine Preiserhöhung nicht als Überraschung erscheint. Zweitens können Kappen (Caps) auf die jährliche Erhöhung verhandelt werden. Wer beim Vertragsabschluss keinen Cap vereinbart hat, kann beim Renewal prüfen, ob eine nachträgliche Begrenzung in den Folgevertrag aufgenommen werden kann (Quelle: saprisenegotiations.com, redresscompliance.com).
Auto-Renewal-Klausel: Kündigungsfenster und Bindungswirkung
Auto-Renewal-Klauseln sind in SAP-Verträgen üblich. Sie bewirken, dass ein Vertrag am Ende seiner Laufzeit automatisch verlängert wird, wenn keine fristgerechte Kündigung eingegangen ist. Das Kündigungsfenster bei RISE-Verträgen kann 45 Tage oder mehr vor Vertragsende betragen, bei einigen Vertragsstrukturen auch wesentlich länger (Quelle: saplicensingexperts.com, saprisenegotiations.com).
Das Governance-Risiko: Wer das Kündigungsfenster nicht aktiv im Kalender hat und es verpasst, verlängert seinen Vertrag automatisch zu den bestehenden Konditionen, typischerweise für ein weiteres Jahr. Bei einem RISE-Vertrag mit einem ACV von mehreren Millionen Euro ist das eine Bindung mit erheblichen finanziellen Konsequenzen.
AI-Training-Ausschluss-Klausel
In neueren SAP-Vertragsversionen (2024/2025) haben sich die Klauseln zur Nutzung von Kundendaten für das Training von KI-Modellen verändert. Kunden, die Datenschutz- und KI-Governance-Anforderungen ihres Unternehmens einhalten müssen, sollten prüfen, welche Klausel in ihrem Vertrag gilt und ob ein Opt-out-Recht besteht oder ein expliziter Ausschluss vereinbart werden kann (Quelle: saprisenegotiations.com, The Register).
Exit-Rechte: Daten bei Vertragsende
Was passiert mit den Daten, wenn ein RISE-Vertrag endet? Exit-Rechte definieren, in welchem Format, zu welchem Zeitpunkt und für welchen Zeitraum Kundendaten exportiert werden können. Fehlen diese Rechte oder sind sie unzureichend definiert, entsteht beim Vertragsende ein faktischer Vendor Lock-in: Der Datentransfer ist technisch möglich, aber vertraglich nicht gesichert (Quellen: redresscompliance.com, saprisenegotiations.com).
Die Aufnahme klarer Exit-Rechte in den Vertrag ist eine Pre-Signature-Aufgabe. Die Prüfung, ob sie ausreichen und ob eine Ergänzung beim Renewal sinnvoll ist, ist eine Post-Signature-Governance-Aufgabe.
Renewal-Vorbereitung als Kern-Anwendungsfall {#renewal-vorbereitung-als-kern-anwendungsfall}
Das Renewal eines RISE-Vertrags oder anderer mehrjähriger SAP-Verträge ist der Moment, in dem sich zeigt, ob eine Organisation die vergangenen Jahre gut gesteuert hat oder nicht. Wer 18 Monate vor dem Renewal eine vollständige Datenbasis hat, verhandelt in einer anderen Ausgangslage als jemand, der sechs Monate vorher beginnt, die eigene Vertragslandschaft aufzuarbeiten.
Renewal-Vorbereitung als Governance-Aufgabe umfasst fünf strukturelle Schritte.
Schritt 1: Vertragsbestand aufarbeiten. Welche Komponenten sind im aktuellen Vertrag enthalten? Welche werden genutzt, welche nicht (Shelfware)? Welche Mindestmengen wurden über- oder unterschritten? Diese Bestandsaufnahme ist die Grundlage für jede weitere Vorbereitung.
Schritt 2: Verbrauchsdaten analysieren. Wie hat sich die Nutzung über die vergangene Vertragslaufzeit entwickelt? Welche FUE-Typen werden tatsächlich genutzt? Wie ist der BTP-Credit-Verbrauch verlaufen? Welche Trends sind erkennbar? Diese Analyse ist die Grundlage für eine belastbare Schätzung des künftigen Bedarfs.
Schritt 3: Kritische Klauseln prüfen und Renewal-Ziele definieren. Welche Klauseln im bestehenden Vertrag sollten im Folgevertrag angepasst werden? Auto-Renewal-Fristen prüfen. CPI-Kappung verhandeln, wenn sie im Originalvertrag fehlt. BTP-Credit-Übertrag in den Folgevertrag sicherstellen. Exit-Rechte vor dem Renewal nachschärfen, wenn sie unvollständig sind.
Schritt 4: Verhandlungsbasis aufbauen. Welche Daten und Argumente stützen die eigene Verhandlungsposition? Shelfware-Identifikation als Verhandlungsgrundlage nutzen. Marktpreisvergleich mit ähnlichen Vertragsstrukturen. Verständnis darüber, was SAP selbst am Renewal-Abschluss interessiert ist.
Schritt 5: Stakeholder-Alignment sicherstellen. Ein SAP-Renewal betrifft alle vier Rollen: Contract Manager, Procurement, Controlling und Executive müssen ausgerichtet sein, bevor SAP ein Angebot vorlegt. Intern unabgestimmte Verhandlungsführung schwächt die eigene Position.
Wann ist der richtige Zeitpunkt für den Start?
Gemäß Empfehlungen von SAP-Lizenz-Spezialisten sollte die strukturierte Renewal-Vorbereitung 12 bis 18 Monate vor dem Vertragsende beginnen (Quelle: saplicensingexperts.com, saprisenegotiations.com). Das ist kein übertriebener Vorlauf: Verbrauchsdaten müssen erhoben, Klauseln analysiert und interne Stakeholder koordiniert werden. Bei einem RISE-Vertrag über mehrere Millionen Euro ACV ist dieser Vorlauf angemessen, nicht großzügig.
Vertragscheck als Einstieg {#vertragscheck-als-einstieg}
Wer mit SAP Contract Governance beginnt, steht vor einer klaren Ausgangsfrage: Welche Datenbasis haben wir heute, und was fehlt?
Ein strukturierter Vertragscheck ist der effizienteste Weg, diese Frage zu beantworten. In vier Wochen wird ein bestehender SAP-Vertrag, typischerweise ein RISE-Vertrag oder ein vergleichbarer Cloud-Enterprise-Vertrag, vollständig aufgearbeitet: Vertragsstruktur dokumentiert, relevante Klauseln identifiziert, Fristen und Handlungsfenster aufgezeigt, erste Steuerungsparameter abgeleitet.
Das Ergebnis ist kein Bericht, sondern eine Steuerungsgrundlage: Eine vollständige Übersicht des Vertrags, eine Einschätzung der aktuellen Governance-Situation und ein klares Bild davon, was in den nächsten zwölf Monaten steuerungsrelevant ist.
Der Vertragscheck ist ein Festpreis-Einstieg: 7.900 EUR, vier Wochen, ein Vertrag. Er ist der erste Schritt sowohl für den Übergang in das Self-Service-Modell als auch für den Start eines Managed Service-Engagements.
Was der Vertragscheck liefert
Der Vertragscheck analysiert die Vertragsstruktur des eingereichten Vertrags vollständig. Das Ergebnis enthält:
Eine strukturierte Übersicht aller relevanten Vertragsparameter: Laufzeiten, Fristen, ACV-Basis, Kernleistungen, Credit-Kontingente, Mindestmengen und Sondervereinbarungen.
Eine Einschätzung der wichtigsten Klauseln: Welche greifen im Alltag? Welche sind im Grenzfall relevant? Wo gibt es Unklarheiten oder fehlende Klauseln (insbesondere Exit-Rechte, CPI-Caps, Auto-Renewal-Fristen)?
Eine Einschätzung der aktuellen Governance-Situation: Wo sind Datenlücken? Was fehlt für eine kontinuierliche Steuerung?
Einen Aktionsplan mit konkreten Empfehlungen für die nächsten zwölf Monate.
Der Vertragscheck ist keine Verhandlungsberatung und kein Audit, sondern eine Klärung der eigenen Ausgangslage. Er schafft die Grundlage, auf der alle weiteren Governance-Aktivitäten aufbauen.
Für wen ist der Vertragscheck geeignet?
Der Vertragscheck ist geeignet für Organisationen, die einen bestehenden SAP-Vertrag haben und noch keine strukturierte Governance-Basis aufgebaut haben. Er ist besonders wertvoll, wenn das Renewal in den nächsten 24 Monaten bevorsteht, wenn ein neuer Director oder Teamlead die Vertragsverantwortung übernommen hat und sich einen vollständigen Überblick verschaffen möchte, oder wenn eine M&A-Transaktion die SAP-Vertragslandschaft verändert hat.
Wer seinen ersten Vertragscheck abgeschlossen hat, hat eine valide Datenbasis. Von dort aus entscheidet sich, welcher Folgeschritt sinnvoll ist: laufende Self-Service-Steuerung, Managed Service-Governance, oder die intensive Vorbereitung eines anstehenden Renewals.
Worauf bei der Auswahl achten {#worauf-bei-der-auswahl-achten}
Wer SAP Contract Governance strukturiert etablieren will, steht bei der Auswahl eines Governance-Modells oder eines externen Unterstützungsangebots vor mehreren praktischen Fragen.
Erstens: Unabhängigkeit. Ein SAP Contract Governance-Dienstleister sollte unabhängig von SAP und von SAP-Implementierungspartnern sein. Wer gleichzeitig RISE-Implementierungsprojekte verkauft und Contract Governance anbietet, hat strukturell unterschiedliche Interessen. Echte Unabhängigkeit entsteht durch klare Abgrenzung: Governance, nicht Implementierung.
Zweitens: Abdeckung aller Produkttypen. SAP-Portfolios sind heterogen. Ein Governance-Angebot, das sich ausschließlich auf RISE oder ausschließlich auf einen Produkttyp konzentriert, deckt typische Enterprise-Portfolios nicht vollständig ab. Relevant ist die Abdeckung aller neun Produkttypen, von On-Premise bis SuccessFactors und Ariba.
Drittens: Post-Signature-Fokus. Vertragsverhandlungsberatung und Post-Signature-Governance sind unterschiedliche Dienstleistungen. Wer nach einem Angebot für laufende Steuerung sucht, sollte prüfen, ob der Anbieter tatsächlich kontinuierliche Governance anbietet oder primär bei Verhandlungen oder Audits unterstützt.
Viertens: Datenbasis und Transparenz. Eine belastbare Governance erfordert eine eigene, unabhängige Datenbasis, die nicht ausschließlich auf SAP-eigenen Systemen und Reportings beruht. Die Fähigkeit, Vertrags-, Nutzungs- und Kostendaten eigenständig zusammenzuführen und zu analysieren, ist ein wesentliches Qualitätsmerkmal.
Fünftens: Wechsel zwischen Servicemodellen. Wer heute mit einem Managed Service einsteigt und später intern aufbauen möchte, sollte prüfen, ob der Wechsel ohne Datenverlust möglich ist. Governance-Daten, Verhandlungshistorie und Klausel-Bewertungen sollten portabel bleiben.
Sechstens: Nachvollziehbarkeit der Empfehlungen. Governance-Empfehlungen sollten nachvollziehbar und aus den eigenen Daten ableitbar sein. Eine externe Einschätzung ohne transparente Datenbasis ist schwer zu bewerten und schwer intern zu kommunizieren.
FAQ {#faq}
Was ist 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.
Was ist der Unterschied zwischen SAP Contract Governance und SAP-Lizenzmanagement?
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.
Wann sollte ich mit der Renewal-Vorbereitung beginnen?
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.
Was passiert, wenn ich das Auto-Renewal bei RISE nicht rechtzeitig kündige?
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).
Was sind Full Use Equivalents (FUE) und wie werden sie berechnet?
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.
Wie verlaufen BTP Credits und AI Units ab und was kann ich dagegen tun?
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).
Was ist Digital Access und welches Risiko entsteht bei Drittanbieter-Integrationen?
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).
Was bedeutet die 99,7%-SLA bei RISE und was ist der Industriestandard?
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).
Was passiert mit meinen SAP-Verträgen bei einer Unternehmensübernahme oder einem Carve-out?
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).
Was ist der Unterschied zwischen ACV und TCV bei SAP-Verträgen?
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.
Was ist der Unterschied zwischen reaktiver und proaktiver SAP Contract Governance?
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.
Was kostet SAP Contract Governance?
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.
Kann ich SAP Contract Governance intern aufbauen oder brauche ich externe Unterstützung?
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.
Nächste Schritte {#naechste-schritte}
Wer steuert Ihre SAP-Verträge nach der Unterschrift?
Der Vertragscheck ist der strukturierte Einstieg: Ein Vertrag, vier Wochen, ein klares Bild Ihrer aktuellen Governance-Lage. 7.900 EUR Festpreis.
Nächste Schritte
Der Vertragscheck ist der strukturierte Einstieg: Ein Vertrag, vier Wochen, ein klares Bild Ihrer aktuellen Governance-Lage. 7.900 EUR Festpreis.