Lizenzsteuerung über mehrere SAP-Produkttypen: Portfolio-Perspektive für hybride Landschaften
RISE, BTP, SuccessFactors und Ariba folgen unterschiedlichen Lizenzmodellen. Wer alle gleichzeitig im Portfolio betreibt, steuert nicht einen Vertrag, sondern ein System aus Verbrauchsmetriken, Renewal-Terminen und Compliance-Anforderungen, die in keiner gemeinsamen Übersicht zusammenlaufen. Dieser Artikel beschreibt, was Cross-Produkt-Lizenzsteuerung konkret bedeutet, wo die Steuerungsmomente je Produkttyp liegen und welche Koordinationslogik hybride Portfolios tragen.
Übersicht: Lizenzmodelle im SAP-Portfolio im Vergleich
SAP hat für unterschiedliche Produktkategorien unterschiedliche Lizenzmodelle entwickelt. Was auf den ersten Blick nach Produktdifferenzierung aussieht, ist aus Governance-Sicht eine strukturelle Herausforderung: Jedes Modell bringt eigene Messgrößen, eigene Abrechnungszyklen und eigene Risikoprofile mit.
| Produkttyp | Lizenzmodell | Messgröße | Abrechnungszyklus |
|---|---|---|---|
| S/4HANA Cloud (RISE/PCE) | FUE-Pool | Full Use Equivalents | Monatlich (PCE Metering) |
| S/4HANA On-Premise | Named User | Zugeordnete Nutzertypen | Jährlich (USMM/Audit) |
| BTP (CPEA/BTPEA) | Credit-basiert | Credits je Service | Jährlich (Credit-Verfall) |
| SuccessFactors | Per Employee | Aktive Mitarbeiter | Jährlich |
| Ariba | Subscription + Transaktion | Netzwerk-Transaktionen | Laufend |
| Concur | Per User per Month | Aktive Nutzer | Monatlich |
Das Nebeneinander dieser Modelle ist nicht per se ein Problem. Das Problem entsteht, wenn Steuerungsverantwortung und Datenbasis über diese Modelle fragmentiert sind: der FUE-Verbrauch wird in einer Abteilung verfolgt, die SuccessFactors-Benutzerzahl in einer anderen, und die BTP-Credit-Entwicklung schaut niemand an, bis das Jahresende naht.
Cross-Produkt-Lizenzsteuerung schafft eine gemeinsame Perspektive über alle aktiven Produkttypen und sorgt dafür, dass Steuerungsmomente in jedem Modell rechtzeitig erkannt und genutzt werden.
SuccessFactors: Per-Employee-Modell und seine Governance-Anforderungen
SuccessFactors lizenziert nach aktiven Mitarbeitern, also per Employee per Year. Dieses Modell ist konzeptionell einfach, verlangt in der Praxis aber einen kontinuierlichen Abgleich zwischen HR-Systemdaten und Vertragsbasis.
Der primäre Steuerungsmoment ist die Mitarbeiterfluktuation. Neueintritte, Abgänge, Elternzeiten, Werkvertragsnehmer mit Systemzugang: Jede dieser Veränderungen hat eine potenzielle Lizenzrelevanz. Organisations, die SuccessFactors aktiv nutzen, stellen regelmäßig fest, dass ihr aktiver Mitarbeiterbestand und die vertraglich lizenzierte Nutzerzahl auseinanderdriften, in beide Richtungen.
Ein zweiter Aspekt betrifft den Renewal-Zyklus. SuccessFactors-Verträge laufen in vielen Organisationen asynchron zu RISE. Das bedeutet: Renewal-Verhandlungen finden isoliert statt, ohne die Verhandlungsgrundlage des Gesamtportfolios zu nutzen. Co-Termination, also die Angleichung der Vertragslaufzeiten, ist hier eine aktive Steuerungsentscheidung, keine automatische Option.
Drittens: SAP-AI-Funktionen in SuccessFactors. Welche AI-Funktionen in welchem SuccessFactors-Modul enthalten sind und welche als Add-on hinzukommen, ist nicht einheitlich geregelt. Mit dem EU AI Act (ab August 2026 für Hochrisikosysteme relevant) entstehen zusätzliche Governance-Anforderungen für AI-gestützte HR-Prozesse. Wer SuccessFactors-AI-Funktionen im Einsatz hat, sollte prüfen, ob die Vertragsanhänge diese Nutzung vollständig erfassen.
Ariba: Transaktionsgebühren laufend steuern
Ariba-Governance hat zwei Ebenen: die Subscription für die Procurement-Software und die variablen Transaktionsgebühren auf dem Ariba Network.
Die Subscription folgt einem Jahresmodell und ist planbar. Die Transaktionsgebühren sind es nicht ohne aktives Monitoring. Sie entstehen transaktionsbasiert: Je nach Volumen und Transaktionstyp fallen unterschiedliche Gebühren an. Die Gebührenstruktur ist vertraglich definiert, aber der laufende Verbrauch ist ohne dediziertes Reporting schwer zu überblicken.
In der Praxis führen Ariba-Transaktionsgebühren häufig zu Budgetabweichungen, die erst bei der Rechnungsprüfung sichtbar werden. Der Steuerungsmoment liegt früher: im laufenden Monitoring des Transaktionsvolumens gegen eine geplante Benchmark. Wer dieses Monitoring eingerichtet hat, kann frühzeitig eingreifen, bevor Übernutzungen die Abrechnung belasten.
Zusätzlich gilt für Ariba: Wie für SuccessFactors laufen Renewal-Zyklen oft nicht synchron mit RISE. Eine koordinierte Renewal-Planung über das Gesamtportfolio erhöht die Verhandlungsposition gegenüber SAP, weil Volumen gebündelt verhandelt werden kann.
BTP: Credit-Verfall und monatlicher AI-Unit-Verfall
BTP-Governance ist technisch die komplexeste Dimension im SAP-Portfolio. Das liegt nicht an der Produktstruktur, sondern an zwei spezifischen Verfallsmechaniken, die in der Praxis regelmäßig zu Budgetverschwendung führen.
Jährlicher Credit-Verfall (CPEA/BTPEA): BTP-Credits verfallen am Ende des Vertragsjahres. Ein Übertrag ungenutzter Credits in die nächste Periode ist nur in wenigen Vertragsmodellen und in begrenztem Umfang vorgesehen. Der Steuerungsmoment liegt im dritten Quartal: Wer seinen Credit-Verbrauch bis dahin nicht analysiert hat, hat gegen Jahresende kaum noch operative Möglichkeiten, verbleibende Credits sinnvoll einzusetzen.
Monatlicher Verfall von AI Units (PUPM): SAP Business AI Units, lizenziert als Per User Per Month-Modell, verfallen monatlich. Ein Übertrag in den Folgemonat ist vertraglich nicht vorgesehen. Das bedeutet: Nicht genutzte AI Units in einem Monat sind unwiederbringlich verloren, auch wenn die Gesamtlaufzeit des BTP-Vertrags noch Monate umfasst. Diese Verbrauchslogik verlangt ein monatliches Monitoring, das in den meisten Governance-Rhythmen noch nicht als Standard etabliert ist.
Für die Portfolio-Perspektive gilt: BTP-Credits und AI Units sind keine abstrakten Bilanzpositionen. Sie sind eingekaufte Kapazität mit zeitlichem Verfall. Wer diese Kapazität nicht aktiv steuert, zahlt für Ressourcen, die nie eingesetzt werden.
Eine ausführliche Behandlung der BTP-Credit-Mechanik und der AI-Unit-Logik findet sich in Pillar 2 (SAP Business AI und BTP-Governance) und Pillar 3 (BTP FinOps).
Co-Termination als Steuerungsoption
Co-Termination ist die Angleichung von Vertragslaufzeiten über mehrere SAP-Produkttypen auf einen gemeinsamen Renewal-Termin. Was technisch wie eine administrative Vereinfachung klingt, ist in Wirklichkeit eine strategische Steuerungsentscheidung.
Warum Co-Termination relevant ist: Wer RISE, SuccessFactors und Ariba unabhängig voneinander renewt, verhandelt dreimal aus einer eingeschränkten Position. SAP sieht in jedem dieser Gespräche nur den Teilvertrag. Wer alle drei zusammenführt, bringt das Gesamtvolumen als Verhandlungsgrundlage ein.
Gleichzeitig hat Co-Termination einen Preis: Laufzeitangleichungen bedeuten fast immer, dass ein Vertrag verlängert oder vorzeitig renewt werden muss. Diese Kosten sind einmalig und sollten gegen den langfristigen Verhandlungsvorteil abgewogen werden.
Der richtige Zeitpunkt, Co-Termination zu prüfen, ist mindestens 18 bis 24 Monate vor dem nächsten größeren Renewal, nicht kurz davor. Wer Co-Termination erst verhandeln will, wenn SAP bereits in der Renewal-Phase ist, hat den optimalen Steuerungsmoment verpasst.
Co-Termination ist kein Standardangebot von SAP, sondern muss aktiv angefragt und verhandelt werden. Die Bereitschaft auf SAP-Seite ist vertragsabhängig und variiert.
Vier Rollen in der Cross-Produkt-Governance
Cross-Produkt-Lizenzsteuerung gelingt nicht als Einzelaufgabe. Die vier Rollen, die im SAP-Lizenzmanagement-Reifegrad-Modell beschrieben sind, tragen auch in der Portfolio-Governance Verantwortung, allerdings mit einer erweiterten Koordinationsanforderung.
Contract Manager trägt die Gesamtübersicht: Welche Produkttypen sind aktiv? Welche Laufzeiten, Renewal-Termine und Kündigungsfristen gelten? Die Herausforderung im Portfolio-Kontext ist, dass diese Informationen in unterschiedlichen Systemen und Abteilungen liegen. Der Contract Manager konsolidiert sie und hält die Datenbasis aktuell.
Procurement verantwortet die Renewal-Koordination über alle Produkttypen. Das bedeutet konkret: Co-Termination-Entscheidungen vorbereiten, Handlungsoptionen je Produkttyp analysieren und koordinierte Renewal-Pakete verhandeln, statt Einzelverträge in Folge abzuarbeiten.
Controlling stellt sicher, dass FUE-Verbrauch, BTP-Credit-Entwicklung, SuccessFactors-Benutzerzahl und Ariba-Transaktionsvolumen im Budget-Forecast zusammenlaufen. Eine fragmentierte Kostenperspektive, in der jeder Produkttyp in einem anderen Kostenstellenbericht erscheint, erschwert die Gesamtsteuerung erheblich.
Executive trifft die strategischen Entscheidungen: Welche Produkttypen bleiben langfristig im Portfolio? Wo soll das Volumen wachsen? Welche Co-Termination-Entscheidungen werden getroffen? Diese Entscheidungen verlangen eine konsolidierte Datenbasis, die die anderen drei Rollen gemeinsam aufbauen.
Die Koordinationsleistung, die Cross-Produkt-Governance von allen vier Rollen verlangt, ist erheblich. In der Praxis scheitert sie häufig nicht an fehlendem Fachwissen, sondern an fehlender gemeinsamer Datenbasis und unklaren Zuständigkeiten zwischen den beteiligten Abteilungen.
FAQ
Muss jeder Produkttyp im Portfolio mit gleicher Intensität gesteuert werden?
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.
Was ist der häufigste Fehler bei der Portfolio-Lizenzsteuerung?
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.
Wie lässt sich Co-Termination in der Praxis einleiten?
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.
Wo finde ich die detaillierte BTP-Credit-Mechanik?
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.
Wie hilft FinOptory bei der Cross-Produkt-Lizenzsteuerung?
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.
Weiterführende Artikel
Nächste Schritte
Möchten Sie Ihre SAP-Verträge auf Fristen, Klausel-Risiken und Handlungsspielräume prüfen lassen?
Dieser Beitrag gehört zum Themen-Hub SAP-Lizenzmanagement und Reifegradmodell. Für die Bewertung eines konkreten Vertrags liefert der FinOptory Vertragscheck in vier Wochen eine strukturierte Grundlage.
Zuletzt aktualisiert: Juli 2026