SAP Contract Governance über alle 9 SAP-Produkttypen: ein Überblick

Über 78% der Enterprise-Kunden betreiben hybride SAP-Portfolios, die weit über RISE hinausgehen. Eine belastbare Governance muss alle Produkttypen erfassen, denn jeder bringt eine eigene Vertragslogik, eigene Verbrauchsmodelle und eigene Steuerungsmomente mit. Dieser Artikel gibt einen strukturierten Überblick über die neun relevanten SAP-Produkttypen, zeigt, wo ihre jeweiligen Steuerungsanforderungen liegen, und erklärt, warum ein hybrides Portfolio eine koordinierte Governance-Logik braucht.

Warum Cross-Produkt-Governance mehr ist als die Summe der Einzelteile

SAP-Vertragsportfolios in Enterprise-Unternehmen sind selten monolithisch. Laut Gartner-Analysen (Gartner Magic Quadrant für Cloud ERP, 2024) betreiben die meisten großen SAP-Kunden gleichzeitig On-Premise-Systeme, Cloud-Abonnements und Hybrid-Konstrukte. Diese Portfolios sind historisch gewachsen: Eine On-Premise-Landschaft wurde durch RISE ergänzt, dann kamen SuccessFactors für HR und Ariba für Einkauf hinzu. BTP entstand als Integrationsschicht. Jeder Baustein brachte seinen eigenen Vertrag mit.

Das Ergebnis: Renewals, Credit-Zyklen und Preisanpassungsklauseln liegen auf unterschiedlichen Zeitachsen. Vertragskenntnisse sind auf verschiedene Abteilungen verteilt. Eine Rechnung passt nicht zum Forecast, weil Ariba-Transaktionsgebühren in der Budget-Planung nicht berücksichtigt wurden. Ein BTP-Kontingent verfällt am Jahresende, weil niemand den Verbrauch koordiniert hat.

Cross-Produkt-Governance beantwortet die Frage, die kein Einzelvertrag beantworten kann: Wie steuere ich mein gesamtes SAP-Portfolio als zusammenhängendes Gebilde, über die gesamte Laufzeit?

On-Premise und Wartung: die Basis, die oft vergessen wird

On-Premise-SAP-Lizenzen sind in vielen Unternehmen weiterhin das Rückgrat der Systemlandschaft. Governance-Anforderungen entstehen hier in drei Bereichen.

Erstens: Annual Maintenance. SAP berechnet die jährliche Wartungsgebühr auf Basis der ursprünglichen Lizenzkosten. Der Standard-Maintenance-Satz liegt bei 22%. Wer Extended Maintenance in Anspruch nimmt, zahlt einen Aufschlag auf diesen Satz (Quelle: SAP Help Portal). Dieser Aufschlag muss in der Budget-Planung aktiv berücksichtigt werden.

Zweitens: Shelfware. Nicht genutzte On-Premise-Lizenzen haben einen messbaren Wert als Verhandlungsgrundlage beim Übergang zu Cloud-Modellen. SAP bietet mit der Transition Option die Möglichkeit, bestehende Lizenzen auf RISE anzurechnen, diese Option hat jedoch zeitliche Fristen, die aktiv verfolgt werden müssen (Quelle: SAP Help Portal, it-daily.net). Wer Shelfware kennt und dokumentiert hat, kann sie einsetzen. Wer sie nicht kennt, verliert diese Verhandlungsgrundlage.

Drittens: Wartungsverlängerung. Das Ende des Extended Mainstream Maintenance für ältere SAP-Versionen ist ein zentraler Planungsparameter. Die Entscheidung über Verlängerung oder Migration ist ein konkreter Steuerungsmoment: Governance bedeutet hier, den eigenen Zeitplan mit dem SAP-Wartungskalender abzugleichen und diesen Steuerungsmoment zu definieren, bevor er sich schließt.

RISE with SAP: Enterprise Agreement und Credit-Mechanik

RISE with SAP ist der volumenstärkste und vertraglich komplexeste Produkttyp in vielen Enterprise-Portfolios. Strukturell handelt es sich um ein Enterprise Agreement (EA) mit drei Säulen: Cloud Managed Services (Systembetrieb, Basis-Support), Cloud Software (S/4HANA Cloud, BTP-Grundkontingent, Signavio als gebündeltes Werkzeug) und optionale Cloud Application Services.

Das finanzielle Kernmodell ist das jährliche Cloud Service-Guthaben (Annual Cloud Service Credit). Nicht genutztes Guthaben kann vertraglich bis zu einem definierten Prozentsatz in das Folgejahr übertragen werden (Roll-over, vertragsindividuell). Am Ende der Gesamtvertragslaufzeit verfällt ungenutztes Guthaben vollständig (Quellen: SAP CPEA-FAQ (sap.com, 2021), SAP Help Portal).

Governance-kritisch bei RISE sind vier Parameter. Erstens Übernutzung: Wer das vereinbarte Guthaben überschreitet, zahlt eine Verbrauchsgebühr zuzüglich eines Aufschlags, gleichzeitig sind SLA-Garantien in dieser Phase eingeschränkt. Zweitens die Selbstmelde-Pflicht: Die Pflicht zur Messung und schriftlichen Meldung von Übernutzung liegt beim Kunden. Drittens Co-Termination: Ergänzende Vertragskomponenten können separate Laufzeiten haben, was die Renewal-Planung verkompliziert. Viertens Auto-Renewal-Fristen: Das Kündigungsfenster bei RISE-Verträgen liegt häufig 12 oder mehr Monate vor Vertragsende. Dieser Zeitpunkt ist der kritischste Steuerungsmoment im RISE-Vertragszyklus. Wer diese Frist nicht aktiv verfolgt, verlängert automatisch zu bestehenden Konditionen.

BTP und CPEA: Credits, Verfall und Depreciation Groups

SAP BTP (Business Technology Platform) wird ü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 eingesetzt werden können.

Ein zentraler Governance-Aspekt: BTP-Credits verfallen in der Regel am Ende des Vertragsjahres. Ein Übertrag ungenutzter Credits ist nicht in allen Vertragsmodellen vorgesehen. Der Steuerungsmoment für den Credit-Verbrauch liegt daher im dritten Quartal, nicht im Dezember. Wer gegen Jahresende einen hohen ungenutzten Credit-Bestand feststellt, hat kaum noch operative Optionen (Quellen: SAP Community Blogs, SAP CPEA-FAQ (sap.com, 2021)).

Die Verbrauchslogik folgt den sogenannten Depreciation Groups: Group-1-Services und Group-2-Services verbrauchen Credits zu unterschiedlichen Sätzen. Wer seinen Service-Mix kennt, kann den Verbrauch vorausplanen und Kontingente gezielt einsetzen.

Für SAP Business AI Units (auch PUPM: Per User Per Month) gilt eine eigene, engere Verbrauchslogik: Ungenutzte AI-Requests verfallen monatlich, nicht jährlich. Wer AI-Units im BTP-Vertrag hat und den Verbrauch nicht monatlich verfolgt, verliert regelmäßig bereits bezahlte Kapazität ohne Kompensation.

Overage-Charges entstehen, wenn der Credit-Bestand erschöpft ist und weiter Dienste genutzt werden. Diese Mehrkosten entstehen ohne automatische Warnmeldung. Governance bedeutet hier: den Credit-Verbrauch kontinuierlich beobachten und mit dem Jahresplan abgleichen.

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 betrieben werden. In beiden Fällen gelten spezifische Governance-Parameter.

Die Lizenzierung folgt dem FUE-Modell (Full Use Equivalents). Benutzer werden nach ihrer Klassifizierung als Advanced, Core oder Self-Service gezählt. Governance-kritisch: Die Klassifizierung erfolgt berechtigungsbasiert. 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 aktiv nutzt.

Mit der Einführung von PCE-Metering (Performance Capacity Equivalent) erfolgt die Messung monatlich und automatisiert, nicht mehr einmal jährlich. Zu breite Berechtigungsrollen sind damit nicht nur ein Security-Thema, sondern haben unmittelbare Auswirkungen auf die monatliche Lizenzabrechnung.

Bei Public Edition bestehen strikte Standardisierungsanforderungen, die Anpassungsmöglichkeiten sind gegenüber Private Edition eingeschränkt. Für die Governance-Planung bedeutet das: Scope-Entscheidungen zu Beginn des Projekts haben eine längere Bindungswirkung als im On-Premise-Umfeld.

SuccessFactors: Lizenz-Stack und separater Renewal-Zyklus

SuccessFactors folgt einem Per-User-Jahreslizenzmodell, das in der Regel nicht mit dem RISE-Renewal synchronisiert ist. Diese asynchrone Vertragslaufzeit ist ein häufig unterschätzter Governance-Aspekt: Wer SuccessFactors und RISE unabhängig voneinander renewt, verliert die Möglichkeit, Konditionen koordiniert zu verhandeln.

Co-Termination sollte aktiv geplant werden, wenn eine einheitliche Vertragsstruktur gewünscht ist. Dieser Schritt erfordert frühzeitige Abstimmung, da er je nach Vertragsstand mit Mehrkosten oder Vertragsverlängerungen verbunden sein kann.

Im Bereich AI und HR-Daten entstehen durch SAP-AI-Funktionen in SuccessFactors zusätzliche Governance-Fragen: Welche AI-Funktionen sind in welcher Lizenz enthalten? Was ist Add-on? Und wie verhalten sich AI-Training-Klauseln zu den Datenschutzanforderungen der eigenen Organisation? Diese Fragen verlangen eine Auseinandersetzung mit den jeweiligen Vertragsanhängen, nicht nur mit der Hauptvereinbarung.

Ariba: Netzwerkgebühren und variable Transaktionskosten

Ariba-Lizenzen bestehen aus zwei Kostenblöcken: der Grundlizenz für die Procurement-Software und den Transaktionsgebühren auf dem Ariba Network. Diese variablen Transaktionsgebühren entstehen nutzungsabhängig und sind in ihrer Höhe schwer vorauszuplanen.

Governance-Herausforderung: Die Transaktionsgebühren spiegeln sich nicht direkt im Vertrag wider, sondern entstehen durch die operative Nutzung des Netzwerks. Wer die Gebührenstruktur kennt (Tariffs je Transaktionsvolumen und Kategorie), kann den Verbrauch einschätzen. Wer sie nicht kennt, erlebt regelmäßig Abweichungen zwischen Budget und Rechnung.

Darüber hinaus haben Ariba-Lizenzen häufig eigene Renewal-Zyklen, die nicht mit dem RISE-Hauptvertrag synchronisiert sind. Koordinierte Renewal-Planung ist auch hier der Schlüssel zur Steuerungssouveränität.

Concur: Per-User-Modell und Mitarbeiterfluktuation

Concur lizenziert per User per Month. Das Modell ist konzeptionell einfach, aber in der Praxis governance-relevant, weil Mitarbeiterfluktuation und Organisationsveränderungen direkte Auswirkungen auf die Anzahl der lizenzpflichtigen Benutzer haben.

Häufige Situation: Mitarbeiter verlassen das Unternehmen oder wechseln Rollen, bleiben aber im System als aktive Benutzer geführt. Das monatliche Nutzerprofil übertrifft den tatsächlichen Bedarf, ohne dass dies im Reporting sichtbar wird.

Governance bedeutet hier: regelmäßiger Abgleich zwischen aktiven Lizenzen und tatsächlich genutzten Accounts. Dieser Abgleich ist keine einmalige Aufgabe, sondern ein wiederkehrender Prozess, der in den Governance-Rhythmus integriert werden sollte. Auch bei Concur gilt: separate Laufzeiten gegenüber RISE erfordern aktive Co-Termination-Planung.

IBP: Supply Chain Planning und Lizenztypen

SAP IBP (Integrated Business Planning) folgt einem Per-User-Preismodell mit eigenen Lizenztypen je Planungsrolle. Governance-relevant wird IBP vor allem dann, wenn sich Planungsrollen innerhalb der Organisation verändern: Neue Planungsszenarien, Restrukturierungen oder Wachstum erhöhen den Bedarf an zusätzlichen Benutzerlizenzen.

Ohne aktive Steuerung entstehen zwei typische Situationen: Entweder wird IBP untergenutzt (bezahlte Lizenzen ohne aktive Nutzung) oder der Bedarf wächst über das vereinbarte Kontingent hinaus, was Übernutzungsgebühren auslöst.

IBP-Verträge haben häufig separate Laufzeiten gegenüber dem RISE-Kernvertrag. Auch hier gilt: Wer koordiniert renewt, hat mehr Verhandlungsmasse als wer die Verlängerungen unabhängig voneinander abwickelt.

Signavio: RISE-Bündelung und Renewal-Risiko

Signavio ist in vielen RISE-Verträgen als gebündeltes Werkzeug für Process Intelligence enthalten. Diese Bündelung ist ein Governance-Parameter, der spätestens 12 Monate vor einem RISE-Renewal aktiv geprüft werden sollte: Ist Signavio im Folgevertrag weiterhin gebündelt oder wird es separat lizenziert?

Wenn Signavio aktiv genutzt wird, aber aus der RISE-Bündelung herausfällt, entsteht beim Renewal ein unerwarteter Kostenbaustein in der Budgetplanung. Wer dies frühzeitig weiß, kann in der Renewal-Vorbereitung gezielt verhandeln.

Darüber hinaus sollte geprüft werden, ob der Nutzungsumfang dem gebündelten Kontingent entspricht oder ob Erweiterungen bereits zu zusätzlichen Lizenzanforderungen geführt haben. Signavio ist in der Praxis ein Produkt, das in seiner Vertragsrelevanz zunächst unterschätzt wird.

Cross-Produkt-Governance: Warum hybride Portfolios eine eigene Logik brauchen

Wer die neun SAP-Produkttypen einzeln betrachtet, sieht neun verschiedene Vertragslogiken. Wer sie gemeinsam betrachtet, sieht ein koordiniertes Steuerungssystem, das in der Praxis aber selten als solches aufgebaut ist.

Die vier strukturellen Herausforderungen hybrider Portfolios sind: unterschiedliche Renewal-Zeitpunkte, unterschiedliche Verbrauchsmodelle (Credit vs. Per-User vs. Transaktion), unterschiedliche Governance-Verantwortlichkeiten in der eigenen Organisation, und fehlende gemeinsame Datenbasis.

Eine koordinierte Cross-Produkt-Governance adressiert alle vier Dimensionen.

Gemeinsame Datenbasis bedeutet: Vertragsdetails, Nutzungsdaten und Kostendaten über alle Produkttypen in einer strukturierten Form zusammenführen. Nicht als einmalige Bestandsaufnahme, sondern als kontinuierlich gepflegte Grundlage, die vor Fragen verfügbar ist.

Einheitliche Governance-Rolle bedeutet: Eine Person oder Funktion trägt die Verantwortung für das Gesamtportfolio. Diese Rolle ist nicht die technische Systemverantwortung, nicht die Vertragsjuristik und nicht das Budget-Reporting allein, sondern die Verbindung dieser drei Sichtweisen.

Koordinierte Renewals bedeutet: Renewals über verschiedene Produkttypen werden als Paket verhandelt, nicht isoliert. Co-Termination-Entscheidungen werden aktiv getroffen, nicht als Ergebnis von Versäumnissen. Koordinierte Steuerungsmomente über alle Produkttypen ermöglichen eine Verhandlungsposition, die kein Einzelvertrag allein herstellen kann. Handlungsfenster werden frühzeitig markiert und genutzt.

Die Governance-Souveränität über ein hybrides SAP-Portfolio entsteht nicht durch die Überwachung einzelner Verträge, sondern durch das Verständnis ihrer Wechselwirkungen. RISE-Credit-Guthaben, BTP-Verbrauch, SuccessFactors-Benutzerzahlen, Ariba-Transaktionsvolumen: Diese Werte beeinflussen sich gegenseitig, und ihre koordinierte Steuerung ist das Ziel.

Der Einstieg in Cross-Produkt-Governance ist erreichbar: mit einem strukturierten Vertragscheck als erstem Schritt, der die eigene Portfoliostruktur sichtbar macht und Handlungsprioritäten identifiziert.

FAQ

Muss ich alle neun SAP-Produkttypen gleichzeitig in die Governance aufnehmen?

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.

Warum werden Ariba und Concur in der SAP-Governance oft vernachlässigt?

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.

Was ist der erste Schritt, wenn ich mein Portfolio noch nicht vollständig überblicke?

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.

Gibt es eine sinnvolle Reihenfolge für die Governance-Einführung über alle neun Produkttypen?

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.

Weiterführende Artikel

SAP Contract Governance: Verträge nach der Unterschrift steuern (Pillar-Hub, Sektion 4)
Steuerungsmomente bei SAP-Verträgen verstehen (Cluster 1)
Post-signature SAP Contract Governance (Cluster 5, folgt)
SAP BTP und Business AI Governance (Pillar 2, folgt)