SAP-Lizenzmanagement und Reifegradmodell: Vom reaktiven zum strategisch verankerten Ansatz

SAP-Lizenzmanagement besteht aus drei verzahnten Disziplinen: korrekte Lizenztyp-Klassifizierung (Named User und FUE), laufende Vermessung mit USMM, LAW und SAM4U sowie eine organisationale Governance-Reife, die bestimmt, wie systematisch diese Disziplinen im Betriebsrhythmus verankert sind. Wer alle drei zusammenführt, steuert den Steuerungsmoment Berechtigungen und den Steuerungsmoment Nutzung planbar und unabhängig von externen Audit-Anforderungen.

Inhaltsverzeichnis

Warum Lizenzmanagement mehr ist als Compliance
Named User-Lizenztypen: ECC, S/4HANA On-Premise, Abgrenzungen
FUE-Modell: Mechanik, Konversionsgewichte, Berechnungsformel
Berechtigungsbasierte Klassifizierung in S/4HANA und FUE-Implikationen
Vermessungstools: USMM, LAW, SAM4U, SAP for Me
PCE Metering: Paradigmenwechsel und aktuelle Qualitätsgrenzen
Audit-Typen, Auslöser und der strukturierte Audit-Prozess
Häufige Compliance-Lücken und ihr finanzielles Exposure
SAP-Lizenz-Reifegradmodell: Vier Stufen, konkrete Standortbestimmung
Cross-Produkt-Lizenzsteuerung: SuccessFactors, Ariba, BTP im Portfolio
Lizenzmanagement organisieren: Rollen, Rhythmus, Werkzeuge
HowTo: Lizenz-Governance in sechs Schritten aufbauen
FAQ
Nächste Schritte

1. Warum Lizenzmanagement mehr ist als Compliance {#1-warum-lizenzmanagement-mehr-ist-als-compliance}

Der Begriff "SAP-Lizenzmanagement" wird in der Praxis häufig auf einen einzigen Anwendungsfall verengt: die Vorbereitung auf einen bevorstehenden SAP-Audit. Das greift zu kurz. Wer Lizenzmanagement nur in Audit-Kontexten denkt, adressiert die Konsequenz, nicht die Ursache.

Zwei Dimensionen: Compliance und laufende Steuerung

Compliance ist die Grundbedingung: Named-User-Typen und FUE-Volumen müssen mit der tatsächlichen Nutzung übereinstimmen. Wer diese Bedingung nicht erfüllt, riskiert Nachzahlungen, Back-Maintenance und geschwächte Verhandlungsposition beim nächsten Renewal.

Laufende Steuerung ist die weitergehende Disziplin: Steuerungsmomente im Lizenzbereich systematisch zu erkennen, zu nutzen und zu dokumentieren. Der Steuerungsmoment Nutzung fragt, ob FUE-Typen mit dem tatsächlichen Zugriffsbedarf der Nutzer übereinstimmen. Der Steuerungsmoment Berechtigungen fragt, ob Rollen korrekt geschnitten sind und ob das PCE-Metering diese Rollen korrekt bewertet. Beide Steuerungsmomente entstehen nicht beim Audit, sondern im laufenden Betrieb, Monat für Monat.

Vier Steuerungsmomente-Bereiche und ihre Lizenz-Relevanz

Das SAP-Lizenzmanagement berührt alle vier Steuerungsmomente-Bereiche, die FinOptory für die laufende Vertragssteuerung unterscheidet:

Nutzung ist die direkteste Dimension: Wie viele Nutzer welchen Typs sind aktiv? Welche FUE-Typen werden tatsächlich benötigt? Inaktive Accounts, falscher FUE-Typ, unterschätzte Wachstumsraten, all das wird im Steuerungsmoment Nutzung sichtbar.

Berechtigungen sind in S/4HANA Cloud der entscheidende Faktor, weil die Klassifizierung berechtigungsbasiert erfolgt: Was ein Nutzer darf, nicht was er tut, bestimmt den FUE-Typ. Rollendesign ist damit ein direkter Lizenzkostenhebel.

Infrastruktur betrifft die Frage, welche Systeme überhaupt lizenziert sind und welche Systemumgebungen in die Vermessung einfließen. DR-Systeme, Sandbox-Systeme und Schulungsumgebungen können Lizenzpflichten auslösen, die in der initialen Planung nicht berücksichtigt wurden.

Kosten schließlich verbindet FUE-Verbrauch, Rechnungsabgleich, interne Verrechnung und Renewal-Planung. Wer die Kostenentwicklung im Steuerungsmoment Kosten nicht laufend begleitet, bemerkt Abweichungen erst auf der nächsten Abrechnung.

Warum reaktives Lizenzmanagement planbare Budgets erschwert

Lizenzmanagement, das nur auf den nächsten Audit reagiert, kommt nach der Unterschrift zu spät. Wer Steuerungsmomente im Bereich Nutzung und Berechtigungen planbar nutzen will, braucht eine laufende Governance-Disziplin. In der Praxis zeigt sich, dass bei Organisationen ohne strukturierten Lizenz-Rhythmus Klassifizierungsfehler über mehrere Jahre aufgeschichtet werden. Die Bereinigung im Audit-Kontext ist dann aufwendiger und kostenintensiver als eine kontinuierliche Steuerung es wäre.

Abgrenzung zu SAM-Tools

Dieser Pillar behandelt SAP-Lizenzmanagement in seiner vollen Breite: Lizenztypen und FUE-Mechanik, Vermessungstools, Audit-Prozesse und organisationale Governance-Reife. SAM-Tools (Software Asset Management-Tools allgemeiner Natur) liegen außerhalb des Scope dieses Pillars. Wo SAP-eigene Werkzeuge wie SAM4U, USMM und LAW relevant sind, werden sie im Detail besprochen.

2. Named User-Lizenztypen: ECC, S/4HANA On-Premise, Abgrenzungen {#2-named-user-lizenztypen-ecc-s4hana-on-premise-abgrenzungen}

Named User ist die klassische SAP-Lizenzmetrik: Jede Person, die auf SAP zugreift, benötigt eine individuell zugeordnete Lizenz. Concurrent-User-Modelle existieren bei SAP nicht. Die Lizenztypen unterscheiden sich in Zugriffsumfang und Preis erheblich. Eine Fehlklassifizierung ist einer der häufigsten Befunde in Enhanced Audits und erzeugt rückwirkend erhebliche Nachforderungen.

ECC-Lizenztypen im Überblick

In klassischen SAP-ECC-Landschaften (auch bekannt als SAP R/3) gelten fünf primäre Lizenztypen:

Professional User ist der umfangreichste Typ: Er erlaubt vollen, uneingeschränkten Zugriff auf alle Module und Transaktionen. Power User, Controller, Modulberater und Administratoren fallen typischerweise in diese Kategorie. Der Listenpreis liegt im Bereich von 3.000 USD einmalig, mit etwa 22 Prozent jährlicher Maintenance (Quellen: Redress Compliance, SAP Product and Pricing Definitions).

Limited Professional User erlaubt eingeschränkten Zugriff auf definierte Module oder Funktionen. Lesender und schreibender Zugriff innerhalb eines Funktionsbereichs sind typisch. Lagermitarbeiter, Sachbearbeiter im Einkauf oder Buchhalter mit begrenztem Transaktionsspektrum entsprechen diesem Typ. Der Listenpreis liegt bei etwa 1.500 USD einmalig.

Employee Self-Service (ESS) deckt einfache Self-Service-Aufgaben ab: Zeiterfassung, Reisekostenabrechnung, HR-Stammdateneinsicht. Dieser Typ ist für alle Mitarbeiter mit minimalem SAP-Zugang konzipiert und wird oft in Bulk-Paketen bezogen.

Developer User ermöglicht Zugriff auf ABAP Workbench, Entwicklungstools und Customizing. Der Typ richtet sich an ABAP-Entwickler und technische Berater. Wichtig ist, dass Developer User ausschließlich für Entwicklungszwecke eingesetzt werden dürfen, nicht für produktive Geschäftsprozesse.

Test User ist vertragsabhängig geregelt und wird für QA-Teams und Testautomatisierung in Test- und QA-Systemen eingesetzt. Die genauen Bedingungen variieren je nach Vertrag erheblich.

Für jeden Lizenztyp gilt: Das Audit prüft, ob die tatsächlich ausgeführten Transaktionen dem zugewiesenen Lizenztyp entsprechen. Wer einen Limited-Typ hat, aber Professional-Transaktionen ausführt, ist unterlizenziert.

S/4HANA On-Premise-Kategorien

Mit der Einführung von S/4HANA hat SAP die Nomenklatur der Named-User-Typen angepasst. Die fünf Kategorien für S/4HANA On-Premise lauten:

Professional User entspricht dem ECC-Professional und gewährt vollen Zugriff auf alle Module und End-to-End-Prozesse. Der Listenpreis liegt je nach Region und Verhandlungsposition bei 3.000 bis 6.000 USD einmalig.

Functional User (auch Limited Functional User) entspricht dem Limited Professional und erlaubt Zugriff auf definierte Funktionsbereiche. Ein Mitarbeiter, der ausschließlich Logistik-Transaktionen ausführt, fällt typischerweise in diesen Typ.

Productivity User ist eine Weiterentwicklung des ESS-Typs und erlaubt schmalen Zugriff: Daten ansehen, Freigaben erteilen, einfache Eingaben tätigen. Dieser Typ wird in Bulk-Rates bezogen.

Self-Service User entspricht dem ECC-ESS und deckt einfache Self-Service-Funktionen über Fiori oder das Portal ab: Zeiterfassung, Gehaltszettelabruf, einfache Anträge.

Developer User hat dieselbe Funktion wie im ECC-Kontext: ABAP-Entwicklung, Customizing, kein Einsatz für produktive Geschäftsprozesse.

Was sich beim Wechsel von ECC zu S/4HANA ändert

Die Nomenklatur-Änderung von ECC zu S/4HANA ist nicht nur begrifflich. SAP hat 2025 Anpassungen an der Zuordnung von Rollen zu Nutzertypen vorgenommen. Bestimmte Transaktionen, die in ECC als "Limited" galten, können in S/4HANA "Professional" erfordern. Das kann den Lizenzbedarf bei gleichbleibender Nutzerbasis erhöhen. Bei jedem Upgrade oder Vertragsreview empfiehlt es sich, die aktuelle Rollen-Nutzertyp-Zuordnung mit der vorherigen Version zu vergleichen.

Für Organisationen, die eine ECC-zu-S/4HANA-Migration planen oder durchführen, ist eine Reklassifizierungsanalyse vor dem Go-Live sinnvoll. Der Steuerungsmoment Berechtigungen für die Migrationsphase ist ein konkreter Planungspunkt, der im Governance-Rhythmus verankert sein sollte.

Named User vs. FUE: Wann gilt welche Metrik?

On-Premise-Systeme (ECC, S/4HANA On-Premise) und Private Cloud Edition (PCE) mit alten Vertragsstrukturen werden nach Named-User-Typen lizenziert: Jeder Typ einzeln compliant.

RISE with SAP (S/4HANA Cloud Private Edition) und GROW with SAP (S/4HANA Cloud Public Edition) verwenden das FUE-Modell: Die gewichtete Summe aller Nutzertypen bildet den Gesamt-FUE-Bedarf, der mit dem gekauften FUE-Pool verglichen wird.

In Hybridlandschaften, in denen On-Premise-Systeme und Cloud-Systeme parallel betrieben werden, laufen beide Metriken gleichzeitig. Das erfordert eine getrennte Governance für die Named-User-Dimension und die FUE-Dimension, mit getrennten Vermessungstools und getrennten Review-Rhythmen.

3. FUE-Modell: Mechanik, Konversionsgewichte, Berechnungsformel {#3-fue-modell-mechanik-konversionsgewichte-berechnungsformel}

Das FUE-Modell (Full Use Equivalent) ersetzt Named User in RISE- und S/4HANA-Cloud-Verträgen durch eine gewichtete Aggregation. Kunden kaufen einen FUE-Pool und verteilen ihn intern auf Nutzertypen. Das Modell bietet Flexibilität, macht aber die Klassifizierungsqualität zum entscheidenden Kostenhebel.

FUE-Definition und Kernprinzip

Ein FUE ist eine standardisierte Einheit, die verschiedene Nutzertypen in ein einheitliches Lizenzierungsmaß umrechnet. Die Compliance-Bedingung ist eindeutig: Solange die gewichtete Summe aller aktiven Nutzer innerhalb des gekauften FUE-Pools bleibt, ist die Organisation compliant. Interne Rollenverschiebungen, zum Beispiel von Advanced auf Core, erfordern keine Neuverhandlung mit SAP, solange der FUE-Headroom vorhanden ist.

Dieses Poolprinzip unterscheidet das FUE-Modell grundlegend vom Named-User-Modell: Beim Named User muss jeder Typ einzeln compliant sein. Beim FUE-Modell kann ein Überschuss bei einem Typ (zum Beispiel Self-Service) einen Mehrbedarf bei einem anderen Typ (zum Beispiel Core) kompensieren, solange der Gesamtpool nicht überschritten wird (Quelle: SAP Community, RISE with SAP FUE Concept).

Konversionsgewichte

Die vier FUE-Typen haben folgende Gewichte (Quelle: SAP-Dokumentation, SAP Community):

Nutzertyp	FUE-Gewicht	Nutzer pro FUE
Advanced	1,0	1
Core	0,2	5
Self-Service	0,033	ca. 30
Developer	vertragsspezifisch	vertragsspezifisch

Die Kostenrelation zwischen den Typen ist der entscheidende Planungsparameter: Ein Advanced User entspricht 5 Core Usern oder etwa 30 Self-Service Usern in FUE-Gewichtung. Das bedeutet, ein Advanced User kostet in Lizenzterms 30 Mal mehr als ein Self-Service User und 5 Mal mehr als ein Core User (Quelle: redresscompliance.com, FUE Licensing Explained).

Für den Developer-Typ ist besondere Vorsicht geboten: In der Praxis zeigen sich abweichende Gewichtungen in verschiedenen Vertragsversionen. Einige Vertragsformulierungen rechnen 0,5 FUE pro Developer (zwei Developer pro FUE), andere 2,0 FUE pro Developer (ein Developer entspricht zwei FUE). Bei 20 Developern ergibt sich ein Unterschied von bis zu 30 FUEs, was im sechsstelligen Bereich liegen kann. Der konkrete Vertrag muss geprüft werden, bevor eine Kalkulation auf dieser Basis aufgestellt wird.

Berechnungsformel und Rechenbeispiel

Die Grundformel für den FUE-Bedarf lautet:

Total FUEs = (Advanced x 1,0) + (Core x 0,2) + (Self-Service x 0,033)

Das Ergebnis wird aufgerundet.

Ein konkretes Beispiel: Eine Organisation mit 50 Advanced Usern, 100 Core Usern und 300 Self-Service Usern ergibt:

50 Advanced x 1,0 = 50,0 FUE
100 Core x 0,2 = 20,0 FUE
300 Self-Service x 0,033 = 10,0 FUE
Summe: 80 FUE

Würde dieselbe Organisation alle 450 Nutzer als Advanced lizenzieren, wären 450 FUE erforderlich. Die korrekte Klassifizierung reduziert den Bedarf in diesem Beispiel um über 80 Prozent (Quellen: SAP Community Blog by SAP: RISE with SAP FUE concept, RISE SDG v11-2024).

Einsparpotenzial durch Role-Access-Alignment

Das größte Optimierungspotenzial liegt in der korrekten Zuordnung von Nutzertypen zu tatsächlichem Zugriffsbedarf. Wenn ein Nutzer als Advanced lizenziert ist, aber tatsächlich nur Core-Funktionalität nutzt, werden 0,8 FUE pro Nutzer verschwendet. Bei einer Umstufung von Advanced auf Self-Service werden 0,967 FUE pro Nutzer frei.

Korrekte Klassifizierung nach tatsächlichem Funktionsumfang ist laut SAP Service Description Guide verpflichtend. Organisationen, die pauschal alle Nutzer als Advanced klassifizieren, zahlen strukturell zu viel. Die Optimierung beginnt mit einer Analyse, welcher Nutzer welche Transaktionen tatsächlich ausführt, nicht welche Berechtigungen er theoretisch hat.

Mid-Term-Reduktion nicht möglich

Ein strukturell wichtiger Vertragsaspekt: Die meisten RISE-Verträge verbieten eine Reduktion der FUE-Anzahl während der Laufzeit. Wer zu viele FUE kauft, zahlt bis zum Renewal für ungenutzte Kapazität. Die initiale FUE-Kalkulation ist damit nicht korrigierbar, bis das Renewal kommt.

Das macht die Ausgangskalkulation zu einem der wichtigsten Steuerungsmomente im FUE-Bereich: Sie entscheidet über die Kostenbasis der gesamten Vertragslaufzeit. Eine True-Up/True-Down-Klausel, die nach 18 bis 24 Monaten eine Anpassung erlaubt, ist verhandelbar und sollte in der Vertragsverhandlung aktiv adressiert werden.

Developer-FUE: vertragsspezifisch prüfen

Wie oben beschrieben, variiert das Developer-FUE-Gewicht je nach Vertragsversion. Bei 20 Developern kann der Unterschied zwischen 0,5 und 2,0 FUE pro Developer erheblich sein. Dieser Punkt ist in vielen Organisationen unbekannt oder nicht dokumentiert. Der Steuerungsmoment Nutzung für Developer-User umfasst deshalb explizit die Verifikation, welches Gewicht im aktuellen Vertrag gilt.

4. Berechtigungsbasierte Klassifizierung in S/4HANA und FUE-Implikationen {#4-berechtigungsbasierte-klassifizierung-in-s4hana-und-fue-implikationen}

In S/4HANA Cloud wird die Nutzerklassifizierung berechtigungsbasiert durchgeführt: Wer eine Rolle mit Advanced-Berechtigung zugewiesen hat, wird als Advanced gezählt, unabhängig davon, ob er diese Berechtigung tatsächlich nutzt. Rollendesign ist deshalb kein reines Sicherheitsthema, sondern ein Lizenzkostenthema mit direkter Auswirkung auf den FUE-Bedarf.

Wie berechtigungsbasierte Klassifizierung funktioniert

Die Grundlogik der berechtigungsbasierten Klassifizierung folgt dem Role-Based Access Control-Prinzip (RBAC): Jeder Nutzer erhält Rollen zugewiesen, und jede Rolle ist einem FUE-Typ zugeordnet. Die höchste Berechtigung, die ein Nutzer über seine Rollen besitzt, bestimmt seinen FUE-Typ. Wenn eine Rolle Advanced-Berechtigungen enthält, ist der Nutzer ein Advanced User, auch wenn er die Advanced-Funktionen im Alltag nicht nutzt.

Dieser Unterschied zur nutzungsbasierten Klassifizierung ist grundlegend: Nutzungsbasierte Klassifizierung würde messen, was ein Nutzer tatsächlich tut. Berechtigungsbasierte Klassifizierung misst, was er tun könnte. In S/4HANA Cloud gilt das berechtigungsbasierte Modell.

PCE Metering und sein Zusammenhang mit Rollen

Im Kontext der Private Cloud Edition (PCE) führt SAP monatliches automatisiertes Metering durch. Dabei werden die zugewiesenen Rollen gemessen, nicht die tatsächliche Nutzung. Das Metering-Ergebnis fließt in die LAW-Konsolidierung ein und landet über SAP for Me als Verbrauchsdaten beim Kunden.

Der Steuerungsmoment Berechtigungen muss deshalb im PCE-Kontext monatlich adressiert werden, nicht jährlich. Wenn eine Rollen-Überprüfung einmal jährlich stattfindet, gibt es elf Monate, in denen Fehlklassifizierungen im Metering erfasst werden, ohne dass die Organisation davon weiß.

"Role Creep" als Klassifizierungsrisiko

Ein in der Praxis häufig beobachtetes Muster ist Role Creep: die schleichende Erweiterung von Berechtigungen über den lizenzierten Umfang hinaus. Typisch ist der Fall eines Self-Service Users, dem zusätzliche Rollen zugewiesen werden, die de facto Core-Berechtigungen enthalten. Das Ergebnis: Der Nutzer ist im System als Self-Service klassifiziert, das Metering zählt ihn aber als Core, weil die Rollenbreite das entsprechende Niveau überschreitet.

Die Konsequenz ist nicht nur ein Compliance-Risiko, sondern ein stiller Steuerungsmoment-Verlust: FUE-Volumen wird verbraucht, ohne dass eine bewusste Entscheidung darüber getroffen wurde. Technische Restriktionen, also die konsequente Begrenzung von Rollen auf das tatsächlich benötigte Berechtigungsniveau, sind der zuverlässigste Schutz gegen Role Creep.

STAR-Analyse: Möglichkeiten und Grenzen

SAPs STAR-Analyse (S/4HANA Trusted Authorization Review) ist ein Werkzeug zur Analyse der Berechtigungsstruktur im System. Es zeigt, welche Berechtigungen zugewiesen sind, und liefert damit die Datenbasis für eine FUE-Optimierungsanalyse.

Eine wichtige Einschränkung gilt jedoch: STAR-Ergebnisse zeigen zugewiesene Berechtigungen, nicht tatsächliche Nutzung. Rohe STAR-Daten ohne vorherigen Abgleich mit Nutzungslogs können überhöhte FUE-Zählungen ausweisen und einen Anlass für Compliance-Maßnahmen von SAP liefern. Die empfohlene Vorgehensweise ist deshalb: STAR intern durchführen, Ergebnisse mit tatsächlichen Nutzungslogs abgleichen, Berechtigungen optimieren, und erst die optimierte Datengrundlage als Basis für Verhandlungen oder Übermittlungen verwenden.

Rollenoptimierung vor PCE-Metering-Zyklus

Der Steuerungsmoment Berechtigungen hat im PCE-Kontext eine klare zeitliche Logik: Rollenoptimierungen, die vor dem monatlichen Metering-Zyklus abgeschlossen sind, verbessern das Metering-Ergebnis für diesen Monat. Optimierungen, die danach abgeschlossen werden, wirken sich erst im Folgemonat aus.

Eine quartalsweise Überprüfung der Rollen als Betriebsstandard ist deshalb sinnvoll: Sie stellt sicher, dass Fehlklassifizierungen nicht über mehrere Metering-Zyklen aufgeschichtet werden, bevor sie adressiert werden.

5. Vermessungstools: USMM, LAW, SAM4U, SAP for Me {#5-vermessungstools-usmm-law-sam4u-sap-for-me}

SAP stellt mehrere Standardwerkzeuge für die Lizenzmessung bereit. Welches Werkzeug wofür geeignet ist, und wie sie im Zusammenspiel funktionieren, bildet die Grundlage jeder strukturierten Lizenz-Governance. Ein laufender Einsatz dieser Tools ist besser als ein einmaliger Audit-Vorbereitungseinsatz.

USMM (User and System Measurement Management)

USMM ist das klassische Einzelsystem-Vermessungstool. Die Transaktion USMM steht in jedem SAP-System zur Verfügung und wird typischerweise vom SAP Basis-Administrator ausgeführt. Sie misst Named-User-Zahlen nach Lizenztyp sowie Engine-Metriken für das jeweilige System.

Eine wichtige Eigenschaft von USMM: Es zählt jeden Named User, unabhängig davon, ob er aktiv ist. Inaktive Accounts und Duplikate erhöhen die gemessene Zahl. Das macht die regelmäßige Bereinigung inaktiver Accounts zur Voraussetzung für eine belastbare USMM-Messung. Die empfohlene Schwelle ist 90 Tage ohne Login, nach der ein Account für die Bereinigung vorgemerkt werden sollte.

Im On-Premise-Kontext wird USMM mindestens jährlich für die Annual Measurement eingesetzt. Im PCE-Kontext löst monatliches automatisiertes Metering die manuelle USMM-Ausführung für die Verbrauchsmessung weitgehend ab, USMM bleibt aber für interne Self-Audits und Plausibilitätsprüfungen relevant (Quelle: SAP Help, License Administration Workbench).

LAW (License Administration Workbench)

LAW (Transaktionscode SLAW2) ist das Multi-System-Konsolidierungstool. Seine Kernleistung liegt in der Deduplizierung: Wenn dieselbe Person in mehreren Systemen Benutzerkonten hat, zählt LAW sie nur einmal im konsolidierten Report. Das ist in Multi-System-Landschaften entscheidend, weil USMM pro System misst und keine systemübergreifende Deduplizierung vornimmt.

Der LAW-Konsolidierungsprozess umfasst das Exportieren der USMM-Messdateien aus allen Systemen, den Import in LAW, das automatische und manuelle Matching von Benutzerkonten über Systeme hinweg sowie die Generierung des konsolidierten Reports, der an SAP übermittelt wird.

Eine Herausforderung ist das User-Matching: Wenn dieselbe Person in verschiedenen Systemen unterschiedliche User-IDs hat (zum Beispiel "bmaendle" in ECC und "bernhard.maendle" in BW), muss die Zuordnung manuell gepflegt werden. Schlechte Datenhygiene bei User-IDs führt zu künstlich erhöhten Lizenzzahlen im LAW-Report.

Im PCE Metering ist LAW ein zentrales Konsolidierungselement: Die automatisierten Metering-Daten aus dem Kundensystem werden über LAW konsolidiert, über ein gesichertes und anonymisiertes Übertragungsprotokoll (mit gehashten User-IDs) an SAP übermittelt und dort im SAP for Me-Dashboard sichtbar gemacht.

SAM4U (SAP Software Asset Manager)

SAM4U ist ein kostenloses Tool, das über SAP Note 3646933 im Kundensystem installiert wird. Ein wesentlicher Vorteil: Die Daten verbleiben im Kundennetzwerk. Es handelt sich nicht um einen Cloud-Service, bei dem Daten an SAP oder einen Drittanbieter übertragen werden.

SAM4U bietet ein interaktives Dashboard mit mehreren Funktionsbereichen:

Enhanced SAP Usage Tracking liefert präzisere und regelmäßigere Nutzungsdaten als klassisches USMM und bildet die Grundlage für fundierte Klassifizierungsentscheidungen.

Optimized Opportunities identifiziert konkrete Umstufungsmöglichkeiten: Nutzer, bei denen eine Reklassifizierung von einem höheren auf einen niedrigeren FUE-Typ möglich wäre, weil ihre tatsächliche Nutzung das niedrigere Niveau rechtfertigt.

Die Authorization Simulation (neu ab Q4/2025) erlaubt es, Berechtigungsänderungen zu simulieren und deren Auswirkung auf den FUE-Gesamtbedarf zu bewerten, bevor die Änderungen tatsächlich umgesetzt werden.

Ab Q1/2026 steht eine Data API zur Verfügung, über die SAM4U-Daten in externe Reporting-Plattformen integriert werden können (Quelle: SAP Note 3646933, DSAG AK Lizenzen 11/2025). Das ermöglicht eine Einbindung in übergreifende Governance-Werkzeuge, ohne Daten aus dem Kundennetzwerk herauszugeben.

SAP for Me

Das Cloud-Portal SAP for Me (erreichbar unter me.sap.com/consumption) bietet ein Dashboard für Entitlements und Verbrauch über Zeit. Das relevante Zugriffsrecht ist "License Utilization for Private Cloud". Über SAP for Me kann die Entitlement-Situation sowie die Verbrauchsentwicklung über Zeiträume hinweg visualisiert werden.

Im PCE-Kontext ist SAP for Me das primäre Dashboard-Instrument: Es empfängt die über LAW konsolidierten und von SAP angereicherten Metering-Daten und macht sie für den Kunden zugänglich. Die Granularität auf Nutzer-Ebene ist im Standard eingeschränkt; SAP for Me berichtet aggregiert, nicht auf Einzelnutzer-Ebene.

Zusammenspiel der Tools

Die vier Tools haben komplementäre Funktionen:

USMM liefert Einzelsystem-Daten auf Named-User-Ebene. LAW konsolidiert und dedupliziert über alle Systeme. SAM4U optimiert und analysiert, mit Simulationsfunktion für Berechtigungsänderungen. SAP for Me visualisiert Entitlements und Verbrauch auf Portal-Ebene.

Für eine vollständige Lizenz-Governance ist die Kombination relevant: USMM und LAW für die Basis-Vermessung, SAM4U für laufende Analyse und Optimierung, SAP for Me für die Verbrauchsübersicht und den Abgleich mit dem vertraglichen Rahmen.

6. PCE Metering: Paradigmenwechsel und aktuelle Qualitätsgrenzen {#6-pce-metering-paradigmenwechsel-und-aktuelle-qualitaetsgrenzen}

Mit der Private Cloud Edition (PCE) hat SAP von jährlicher Selbstvermessung auf monatliches automatisiertes Metering umgestellt. Das verändert die Rollenverteilung zwischen Kunde und SAP grundlegend und erhöht die Anforderungen an die laufende Steuerung.

Paradigmenwechsel im Überblick

Im On-Premise-Modell führte der Kunde die Messung einmal jährlich selbst durch und übermittelte das Ergebnis an SAP. Fehler oder Optimierungsbedarf wurden typischerweise einmal pro Jahr sichtbar.

Im PCE-Modell triggert SAP das Metering monatlich und automatisch. Der Frequenzunterschied ist gravierend: Compliance-Fehler werden potenziell 12 Mal schneller sichtbar. Gleichzeitig liegt die Verantwortung für die Datenqualität weiterhin beim Kunden, denn die Grundlage des automatisierten Meterings sind die im Kundensystem hinterlegten Berechtigungen und Rollen.

Diese Verschiebung hat eine direkte Konsequenz für die Steuerungsmomente: Der Steuerungsmoment Berechtigungen, der bisher einmal jährlich relevant war, wird im PCE-Kontext zu einem monatlichen Steuerungsmoment.

Technische Voraussetzungen

Für das PCE Metering sind technische Mindestvoraussetzungen erforderlich: Minimum SAP BASIS 740 inklusive aller relevanten Support Packages. Systeme müssen für das Metering erreichbar sein; Systeme in Wartungsfenstern sind temporär nicht messbar. Diese Unterbrechungen sollten dokumentiert werden, da fehlende Metering-Daten für bestimmte Perioden zu Folgefragen führen können.

Architektur des PCE-Metering-Flusses

Der technische Ablauf folgt einem definierten Pfad: Das Kundensystem liefert die Metering-Daten. LAW konsolidiert Engine-Ergebnisse und Nutzerdaten, wobei User-IDs für die Übertragung gehasht werden. SAP verarbeitet die Daten und reichert sie mit den vertraglichen Entitlement-Informationen an. Das Ergebnis wird in SAP for Me als Verbrauchsdashboard für den Kunden zugänglich gemacht.

Der Transfer ist gesichert und anonymisiert. Die gehashten User-IDs erlauben SAP die korrekte Deduplizierung, ohne dass personenbezogene Daten im Klartext übertragen werden.

Aktuelle Qualitätsgrenzen (Stand Q4/2025)

In der Praxis zeigen sich bei PCE Metering bekannte Qualitätsgrenzen, die SAP weiter adressiert. Diskrepanzen zwischen automatisiertem Metering und STAR Reports sind dokumentiert: Was das STAR-Werkzeug als Berechtigungsstruktur zeigt, weicht in manchen Fällen von dem ab, was das automatisierte Metering erfasst. Die Ursachen liegen teils in der noch nicht vollständigen Qualität der Engine-Ergebnisse, teils in Implementierungsunterschieden zwischen Kundenumgebungen.

Die Empfehlung lautet: Diskrepanzen dokumentieren, nicht stillschweigend akzeptieren. Wer eine Abweichung zwischen dem eigenen Verständnis der Berechtigungsstruktur und dem Metering-Ergebnis erkennt, sollte diese Abweichung schriftlich festhalten. Eine nicht dokumentierte Diskrepanz kann im Renewal-Kontext zum Nachteil werden.

Was PCE Metering für die Governance-Steuerung bedeutet

Der monatliche Metering-Rhythmus erfordert einen monatlichen Governance-Rhythmus. Das PCE-Metering-Dashboard in SAP for Me sollte monatlich geprüft werden: Liegt der Verbrauch innerhalb des Erwartungsrahmens? Gibt es Ausreißer, die auf Role-Creep oder Fehlklassifizierungen hinweisen? Entsprechen die Metering-Ergebnisse den internen Berechnungen?

Rollenoptimierungen sollten vor dem Metering-Zyklus abgeschlossen sein, nicht danach. Wer eine Bereinigung plant, muss den Metering-Zeitpunkt kennen und die Optimierung zeitlich so planen, dass sie im relevanten Monat wirksam ist.

7. Audit-Typen, Auslöser und der strukturierte Audit-Prozess {#7-audit-typen-ausloser-und-der-strukturierte-audit-prozess}

SAP hat das vertragliche Recht, Lizenznutzung zu prüfen. Wer die Mechanik kennt, kann Audits strukturiert begleiten, anstatt reaktiv zu verwalten. Die Grundlage dafür sind die vier Steuerungsmomente-Bereiche, die im Audit-Kontext nicht isoliert, sondern als Einheit betrachtet werden.

Basic Audit vs. Enhanced Audit

Der Basic Audit ist die jährliche Standardmessung. SAP sendet eine Messaufforderung per E-Mail, der Kunde führt USMM/LAW-Messungen selbst durch und übermittelt die Ergebnisse. Die Prüftiefe ist begrenzt: SAP vertraut weitgehend den selbst-reporteten Daten. Offensichtliche Abweichungen zwischen lizenzierten und gemessenen Usern werden erkannt, tiefgehende Rollenanalysen finden in der Regel nicht statt.

Der Enhanced Audit ist eine vertiefte Prüfung, die SAP alle zwei bis drei Jahre oder anlassbezogen initiiert. SAP Global License Auditing (GLA) ist involviert. Der Umfang ist deutlich breiter: Rollenanalyse, Transaktionsnutzung, Indirect Access, Systemlandschaft. Die Laufzeit beträgt typischerweise drei bis sechs Monate für komplexere Umgebungen. Das finanzielle Exposure ist beim Enhanced Audit erheblich größer, weil tiefergehende Findings aufgedeckt werden können.

Typische Audit-Auslöser

Audits fallen nicht zufällig an. In der Praxis zeigt sich, dass Enhanced Audits häufig mit kommerziellen Events zusammenfallen:

Vor Renewals und RISE-Migrationen hat SAP ein Interesse daran, den Ist-Zustand der Lizenznutzung zu kennen, bevor neue Vertragsbedingungen verhandelt werden. M&A-Aktivitäten, also Fusionen, Übernahmen und Ausgliederungen, verändern die Systemlandschaft und machen eine Neuermittlung der Lizenzbasis notwendig. Vergangene Non-Compliance-Befunde erhöhen die Prüffrequenz für die betreffende Organisation. Auffälligkeiten im Basic Audit, wie signifikante Abweichungen zwischen gemeldeten und erwarteten Werten, können einen Enhanced Audit auslösen.

Diese Muster zeigen: Wer seine Lizenz-Governance dauerhaft stabil hält, schafft bessere Voraussetzungen für Audit-Situationen, die ohnehin kommen werden.

Vier-Phasen-Prozess

Ein SAP-Audit läuft typischerweise in vier Phasen ab:

Phase 1: Benachrichtigung (Woche 1). SAP sendet die formelle Audit-Benachrichtigung per E-Mail mit Scope, Timeline und Ansprechpartnern. Die erste Maßnahme ist die sofortige Aktivierung des internen Audit-Response-Teams. Dieses Team sollte mindestens vier Funktionen abdecken: IT/Basis, Procurement, Legal und CFO/CIO-Sponsor. Je schneller das Team handlungsfähig ist, desto besser ist die Position für die weiteren Phasen.

Phase 2: Messung und Datenerhebung (Wochen 2 bis 4). USMM wird in allen relevanten Systemen ausgeführt, LAW-Konsolidierung wird durchgeführt. Vor der Datenübermittlung an SAP ist eine interne Prüfung und Bereinigung sinnvoll: Inaktive Accounts bereinigen, Duplikate korrigieren, Fehlklassifizierungen adressieren. Diese Schritte sind keine Manipulation der Daten, sondern legitime Datenhygiene, die vor der Messung hätte stattfinden sollen.

Phase 3: Datenübermittlung und SAP-Analyse (Wochen 4 bis 8). Der konsolidierte LAW-Report wird über das SAP Support-Portal übermittelt. Die Empfehlung: Nur die vertraglich geschuldeten Daten liefern, nicht mehr. SAP kann Rückfragen stellen und weitere Daten anfordern; jede Anforderung sollte gegen den vertraglichen Scope geprüft werden.

Phase 4: Ergebnis und Verhandlung (Wochen 8 bis 16 und länger). SAP präsentiert die identifizierten Lücken. Jedes Finding sollte einzeln geprüft werden: Stimmt die Grundlage? Ist die Klassifizierung korrekt? Ist der Zeitraum der geltend gemachten Unterlizenzierung nachvollziehbar? Verhandlung über den True-Up-Umfang und die Konditionen ist in dieser Phase möglich und üblich.

Empfehlung für die Audit-Vorbereitung

Kooperativ, aber kontrolliert agieren ist die Grundhaltung, die sich in der Praxis bewährt. Das bedeutet: Fristen einhalten und kommunikativ sein, aber gleichzeitig nur das übermitteln, was vertraglich geschuldet ist.

Das Audit-Response-Team sollte nicht improvisiert werden, sondern im Vorfeld definiert sein. Die vier Rollen, die im Audit-Kontext Verantwortung tragen, spiegeln die vier Rollen im allgemeinen Steuerungsmodell wider: Contract Manager für die Vertragsstruktur und Compliance-Bewertung, Procurement für die kommerzielle Verhandlung, Controlling für die Kostenbewertung der Findings, und Executive für Freigaben und strategische Entscheidungen.

8. Häufige Compliance-Lücken und ihr finanzielles Exposure {#8-haufige-compliance-lucken-und-ihr-finanzielles-exposure}

Die meisten Compliance-Lücken in SAP-Landschaften entstehen nicht durch vorsätzliche Unterlizenzierung, sondern durch unzureichende Datenhygiene, fehlende Lifecycle-Prozesse und Klassifizierungsfehler, die sich über Jahre aufschichten. Die Herausforderung liegt in der Struktur, nicht bei den Personen.

Misklassifizierte User (häufigster Befund)

Nutzer mit Limited-Lizenz, die Professional-Transaktionen ausführen, sind nach übereinstimmenden Einschätzungen aus der SAP-Compliance-Praxis der häufigste Audit-Befund. Das finanzielle Exposure berechnet sich aus der Preisdifferenz zwischen den Lizenztypen, multipliziert mit den Jahren der Unterlizenzierung und zuzüglich Back-Maintenance.

Ein Rechenbeispiel: 100 Nutzer mit Limited-Lizenz, die tatsächlich Professional-Transaktionen ausführen, bei einer Preisdifferenz von rund 1.500 USD pro Nutzer ergibt 150.000 USD Nachkauf. Zuzüglich drei Jahre Back-Maintenance (22 Prozent per annum auf 150.000 USD) kommt ein Gesamtexposure von rund 249.000 USD zusammen (Quelle: Redress Compliance, SAP License Audit: A Survival Guide).

Brancheneinschätzungen aus der SAP-Compliance-Beratung gehen davon aus, dass 15 bis 25 Prozent der Named-User-Lizenzen in einem durchschnittlichen Unternehmen fehlklassifiziert oder überflüssig sind. Diese Spanne illustriert, dass Misklassifizierung kein seltenes Ausnahmefall ist, sondern ein strukturell häufiges Muster in Organisationen ohne laufenden Review-Rhythmus (Quelle: Reveal Compliance, SAP User License Categories Explained).

Inaktive Accounts und Duplikate

USMM zählt jeden Named User, unabhängig von Aktivität. Ein Nutzer, der seit 18 Monaten das Unternehmen verlassen hat, aber nicht aus dem System gelöscht wurde, erhöht die gemessene Lizenzzahl. In Organisationen ohne strukturiertes Offboarding-Prozedere ist diese Kategorie erheblich.

Duplikate entstehen in Multi-System-Landschaften, wenn dieselbe Person in verschiedenen Systemen unterschiedliche User-IDs hat und LAW sie nicht automatisch als identisch erkennt. Schlechte Datenhygiene bei User-IDs ist die häufigste Ursache. Die 90-Tage-Schwelle ohne Login ist eine etablierte Praxisregel für die Bereinigung inaktiver Accounts.

Engine- und Paket-Überschreitungen

Neben Named-User-Klassifizierungen prüft SAP im Enhanced Audit auch Engine-Metriken: Payroll-Abrechnungen, Order Management, weitere systemspezifische Nutzungsgrößen. Überschreitungen des lizenzierten Volumens führen zu retroaktiven Lizenzkosten plus zwei bis drei Jahre Back-Maintenance.

Das Exposure ist hier besonders relevant, weil Engine-Überschreitungen häufig nicht bemerkt werden, bis SAP sie im Audit identifiziert. Ein monatlicher Alert bei 90 Prozent der lizenzierten Engine-Kapazität ist eine praktikable Präventivmaßnahme.

Indirect/Digital Access als unterschätzte Lücke

Wenn externe Systeme, also Nicht-SAP-Applikationen wie CRM-Systeme, E-Commerce-Plattformen oder IoT-Sensoren, Dokumente in SAP erzeugen, fallen diese unter die Digital Access-Lizenzierung. Neun Dokumenttypen sind definiert, von Sales Orders und Purchase Orders bis zu Financial Documents und Material Documents (Quelle: SAP Digital Access Documentation).

Die Herausforderung liegt in der Sichtbarkeit: Drittanbieter-Integrationen, die seit Jahren in Betrieb sind, haben oft keine klare Dokumentation darüber, wie viele und welche SAP-Dokumente sie erzeugen. Eine jährliche Systembestandsaufnahme der Integrations-Landschaft und der erzeugten Dokumentvolumina ist deshalb Teil einer vollständigen Lizenz-Governance. Ausführlich behandelt wird das Thema Digital Access in Pillar 4 dieser Content-Reihe.

Nicht-lizenzierte Systeme

Sandbox-, Schulungs- und Disaster-Recovery-Systeme können Lizenzpflichten auslösen, die in der initialen Planung nicht berücksichtigt wurden. Die genauen Bedingungen, unter denen diese Systemtypen als lizenzpflichtig gelten, sind vertragsabhängig. Eine jährliche Systembestandsaufnahme, die auch Nicht-Produktivsysteme erfasst, ist deshalb Teil des Governance-Rhythmus.

9. SAP-Lizenz-Reifegradmodell: Vier Stufen, konkrete Standortbestimmung {#9-sap-lizenz-reifegradmodell-vier-stufen-konkrete-standortbestimmung}

Das Lizenz-Reifegradmodell beschreibt vier Entwicklungsstufen im SAP-Lizenzmanagement: von reaktiver Klassifizierung bis zur strategisch verankerten Lizenz-Governance. Jede Stufe ist durch konkrete, beobachtbare Merkmale definiert und gibt Orientierung, was die nächste Stufe konkret erfordert.

Zur Abgrenzung: Das allgemeine SAP Contract Governance-Reifegradmodell (beschrieben in Pillar 1) betrachtet alle vier Steuerungsmomente-Bereiche. Das Lizenz-Reifegradmodell in diesem Abschnitt vertieft die Lizenz-Dimension spezifisch: Named User, FUE, Berechtigungen, Vermessungstools und Audit-Readiness.

Stufe 1: Reaktiv

Auf Stufe 1 findet Klassifizierung initial statt, wird aber nicht laufend überprüft. USMM wird nur auf SAP-Anforderung ausgeführt, nicht als eigenständige Steuerungsmaßnahme. Eine Verbindung zwischen Rollendesign und FUE-Implikationen besteht nicht systematisch. Inaktive Accounts werden nicht regelmäßig bereinigt.

Der Steuerungsmoment Berechtigungen und der Steuerungsmoment Nutzung werden auf dieser Stufe nicht aktiv genutzt. Sie entstehen trotzdem, bleiben aber ungenutzt. Das Ergebnis ist typischerweise ein akkumulierter Bereinigungsbedarf, der erst im Audit-Kontext sichtbar wird.

Stufe 2: Dokumentiert

Auf Stufe 2 ist die Lizenzbasis dokumentiert: Lizenztypen, FUE-Kaufmenge, Kündigungsfristen und Renewal-Termine sind festgehalten. USMM wird mindestens jährlich intern durchgeführt. LAW-Konsolidierung existiert. Fehlklassifizierungen sind bekannt, aber noch nicht systematisch adressiert.

Der Übergang von Stufe 1 zu Stufe 2 ist der Schritt von keiner Dokumentation zu einer verlässlichen Dokumentation. Der Vertragscheck ist ein strukturierter Einstieg in Stufe 2: Er erfasst den Ist-Zustand der Lizenzbasis und macht Klassifizierungsabweichungen erstmals sichtbar.

Stufe 3: Aktiv gesteuert

Auf Stufe 3 sind quartalsweise Self-Audits als Betriebsstandard etabliert. SAM4U ist installiert und aktiv genutzt. Rollenoptimierung findet vor dem PCE-Metering-Zyklus statt. Inaktive Accounts werden nach der 90-Tage-Schwelle systematisch bereinigt. FUE-Verbrauch wird monatlich mit der Vertragsbasis abgeglichen. Klassifizierungsänderungen durch SAP-Upgrades werden proaktiv geprüft.

Diese Stufe bedeutet, dass die vier Steuerungsmomente-Bereiche Nutzung und Berechtigungen planbar gesteuert werden. Das PCE-Metering-Dashboard ist nicht nur ein Reporting-Instrument, sondern ein Steuerungsinstrument, das monatlich ausgewertet wird.

Stufe 4: Strategisch verankert

Auf Stufe 4 ist Lizenz-Governance Teil der IT-Strategie und Budgetplanung. FUE-Optimierung wird vor dem Renewal als Verhandlungsgrundlage systematisch aufgebaut. Szenariomodelle für Nutzungswachstum und Klassifizierungsänderungen sind verfügbar. Cross-Produkt-Lizenz-Koordination, also die Abstimmung zwischen RISE, SuccessFactors, BTP und anderen Produkttypen, ist Betriebsstandard. Die SAM4U Data API ist in eine übergreifende Reporting-Plattform integriert.

Auf dieser Stufe sind Steuerungsmomente nicht nur reaktiv sichtbar, sie werden aktiv geplant. Der Renewal-Prozess beginnt nicht 90 Tage vor dem Vertragsdatum, sondern 12 Monate vorher, mit einer sauber aufgebauten FUE-Optimierungsanalyse als Verhandlungsgrundlage.

Selbst-Check: 8 Fragen zur Standortbestimmung im Lizenzbereich

Die folgenden acht Fragen ermöglichen eine erste Einordnung der eigenen Lizenz-Governance-Reife:

Ist dokumentiert, welche Named-User-Typen oder FUE-Typen im aktuellen Vertrag lizenziert sind und zu welchem Preis?
Wird USMM mindestens einmal jährlich intern ausgeführt, unabhängig von SAP-Anforderungen?
Wird ein LAW-konsolidierter Report für alle Systeme in der Landschaft erstellt?
Sind inaktive Accounts nach einem definierten Prozess und einer definierten Schwelle (90 Tage) bereinigt?
Ist SAM4U installiert und wird es aktiv für Klassifizierungsoptimierung genutzt?
Wird der FUE-Verbrauch monatlich mit dem vertraglichen FUE-Pool abgeglichen?
Sind Rollenoptimierungen zeitlich vor dem PCE-Metering-Zyklus geplant?
Wird die Lizenz-Situation als Teil der IT-Budgetplanung und des Renewal-Vorbereitungsprozesses berücksichtigt?

1 bis 2 "Ja"-Antworten entsprechen Stufe 1. 3 bis 4 "Ja"-Antworten entsprechen Stufe 2. 5 bis 6 "Ja"-Antworten entsprechen Stufe 3. 7 bis 8 "Ja"-Antworten entsprechen Stufe 4.

10. Cross-Produkt-Lizenzsteuerung: SuccessFactors, Ariba, BTP im Portfolio {#10-cross-produkt-lizenzsteuerung-successfactors-ariba-btp-im-portfolio}

Lizenzmanagement endet nicht bei S/4HANA. Wer ein SAP-Portfolio mit mehreren Produkttypen betreibt, steuert unterschiedliche Lizenzmodelle nebeneinander, mit unterschiedlichen Metriken, unterschiedlichen Messzeitpunkten und unterschiedlichen Compliance-Anforderungen.

SuccessFactors: Per-Employee-Modell

SuccessFactors wird pro aktivem Mitarbeiter lizenziert. Jede Änderung in der Headcount-Zahl, ob durch Einstellungen, Austritte oder Umstrukturierungen, hat direkte Auswirkungen auf die monatliche Abrechnung. Anders als bei FUE gibt es kein "Aufbrauchen eines Pools", sondern eine direkte Metrik, die sich monatlich ändern kann.

Für die Governance bedeutet das: Der Steuerungsmoment Nutzung im SuccessFactors-Kontext ist monatlich relevant. Bei größeren Reorganisationen oder Stellenabbau-Programmen können Anpassungen der Lizenzzahl zeitlich relevant sein. Ab August 2026 kommen EU AI Act-Anforderungen für SuccessFactors-Funktionen hinzu, die HR-Prozesse wie Bewerber-Screening unterstützen. Diese Funktionen können als Hochrisiko-AI-Systeme eingestuft werden und erfordern eigene Dokumentations- und Governance-Maßnahmen.

Ariba: Transaktionsgebühren neben Subscription

Ariba kombiniert eine Subscription-Komponente mit Transaktionsgebühren im Ariba-Netzwerk. Netzwerk-Transaktionsgebühren entstehen pro Dokument, das über das Netzwerk ausgetauscht wird. Bei größeren Einkaufsvolumina können diese Gebühren erheblich sein.

Der Steuerungsmoment Kosten im Ariba-Kontext erfordert ein laufendes Monitoring der Transaktionsvolumina: Liegen die Volumina im Rahmen des budgetierten Niveaus? Gibt es Perioden mit unerwarteten Volumenspitzen? Sind die vertraglich vereinbarten Volumen-Tier-Grenzen bekannt?

BTP: Credit-basierte Lizenzierung

BTP (SAP Business Technology Platform) wird über Credit-Kontingente (CPEA: Cloud Platform Enterprise Agreement, BTPEA: BTP Enterprise Agreement) lizenziert. Diese Credits können für eine breite Palette von BTP-Diensten eingesetzt werden, verfallen aber am Jahresende, wenn sie nicht verbraucht werden.

AI Units für SAP Business AI-Funktionen sind ein davon getrennter Verbrauchstopf und werden nicht gegen BTP Credits verrechnet. Details zur AI-Lizenzierung und zu AI Units werden in Pillar 2 dieser Content-Reihe ausführlich behandelt; Details zur BTP FinOps-Steuerung in Pillar 3.

Portfolio-Koordination als Lizenz-Steuerungsaufgabe

Das gleichzeitige Management von S/4HANA FUE, SuccessFactors Per-Employee, Ariba Transaktionsvolumina und BTP Credits erfordert eine koordinierte Perspektive. Unterschiedliche Renewal-Zyklen, unterschiedliche Metriken und unterschiedliche Messkontexte erhöhen die Komplexität.

Co-Termination, also die Angleichung der Renewal-Termine verschiedener Produkttypen, ist eine Vereinfachungsoption, die in Vertragsverhandlungen aktiv angesprochen werden kann. Sie reduziert die Anzahl der separaten Renewal-Prozesse und schafft Möglichkeiten für Portfolio-weite Verhandlungspositionen.

Alle vier Rollen im Steuerungsmodell müssen in der Cross-Produkt-Koordination aktiv sein: Contract Manager für die produktübergreifende Vertragsstruktur, Procurement für Renewal-Koordination und Preisverhandlung, Controlling für die Kostenzuordnung und interne Verrechnung nach Produkttyp, Executive für die strategische Priorisierung und Freigaben.

11. Lizenzmanagement organisieren: Rollen, Rhythmus, Werkzeuge {#11-lizenzmanagement-organisieren-rollen-rhythmus-werkzeuge}

Lizenz-Governance funktioniert nicht als Einzelperson-Aufgabe. Vier Rollen tragen gemeinsam Verantwortung, und ein definierter Rhythmus sorgt dafür, dass Steuerungsmomente nicht verpasst werden.

Vier Rollen und ihre Lizenz-Verantwortung

Contract Manager ist die primäre Rolle für die Lizenz-Governance: Er pflegt die Lizenzbaseline, kalkuliert FUE-Bedarf, überwacht Klauseln (insbesondere Mid-Term-Reduktionsverbote und True-Up/True-Down-Optionen) und ist die erste Ansprechperson bei Audit-Benachrichtigungen. Er ist der Auftraggeber für SAM4U-Analysen und der Empfänger der konsolidierten LAW-Reports.

Procurement verantwortet die kommerzielle Dimension: Renewal-Vorbereitung mit der vom Contract Manager gelieferten FUE-Optimierungsanalyse als Grundlage, Verhandlung von True-Up/True-Down-Klauseln und Digital-Access-Kontingenten, sowie die Portfolio-Koordination bei Cross-Produkt-Renewals. Im Audit-Kontext ist Procurement die Rolle, die die kommerzielle Verhandlung über True-Up-Umfang und -Konditionen führt.

Controlling verbindet Lizenzkosten mit Finanzplanung: FUE-Kostenallokation auf Kostenstellen und Abteilungen, Budget-Forecast für das nächste Geschäftsjahr auf Basis aktueller FUE-Verbräuche, interne Verrechnung bei Multi-Unit-Organisationen. Controlling ist auch die Rolle, die Abweichungen zwischen Lizenzbudget und tatsächlicher Rechnung aufgreift und eskaliert.

Executive entscheidet und priorisiert: Freigabe von Rollenoptimierungen, die organisatorische Konsequenzen haben, strategische Entscheidungen über die FUE-Planung vor Renewal, Eskalation bei Audit-Findings mit erheblichem Exposure. Executive ist der Auftraggeber für den Vertragscheck und die erste Adresse, wenn der Steuerungsmoment Kosten Budgetabweichungen zeigt, die außerhalb des operativen Handlungsspielraums liegen.

Governance-Rhythmus für Lizenzmanagement

Ein strukturierter Governance-Rhythmus stellt sicher, dass Steuerungsmomente im Lizenzbereich nicht verpasst werden.

Monatlich: Das PCE-Metering-Dashboard in SAP for Me wird geprüft. Liegen Verbrauchsdaten im Rahmen der Erwartungen? Gibt es Ausreißer? Inaktive Accounts, die im letzten Monat identifiziert wurden, werden für die Bereinigung vorgemerkt.

Quartalsweise: Self-Audit mit USMM und SAM4U wird durchgeführt. Rollenoptimierung findet statt, bevor der nächste Metering-Zyklus beginnt. FUE-Verbrauch wird gegen das Budget und den vertraglichen FUE-Pool abgeglichen. Klassifizierungsabweichungen werden mit der aktuellen SAP-Rollendefinition verglichen.

Jährlich: LAW-Konsolidierung über alle Systeme wird durchgeführt. Eine vollständige Klassifizierungsüberprüfung findet statt. Systembestand wird validiert, inklusive Nicht-Produktivsysteme. Lizenz-Reifegradmodell wird als Standortbestimmung eingesetzt.

12 Monate vor Renewal: FUE-Optimierungsanalyse wird als Verhandlungsgrundlage aufgebaut. SAM4U-Daten werden für die Dokumentation der optimierten FUE-Basis genutzt. True-Up/True-Down-Klauseln werden evaluiert. Portfolio-Koordination mit anderen SAP-Produkttypen wird gestartet.

Werkzeuge im Überblick

SAM4U ist das zentrale Werkzeug für laufende Messung und Optimierung. Es ist kostenlos, läuft im Kundensystem und bietet mit der Authorization Simulation (ab Q4/2025) eine Funktion, die vor der Durchführung von Rollenänderungen deren FUE-Auswirkung simuliert.

LAW ist das Konsolidierungstool für Multi-System-Landschaften. Es dedupliziert Benutzerkonten über Systeme hinweg und ist im PCE-Metering-Flow das zentrale Konsolidierungselement zwischen Kundensystem und SAP.

Eine übergreifende Governance-Plattform, die SAM4U Data API konsumiert und Lizenz-Governance in den breiteren Kontext der Vertragssteuerung einbettet, ist der nächste Schritt nach Stufe 3 des Reifegradmodells. FinOptory ist als Consumer der SAM4U Data API konzipiert: Die Lizenzmessung bleibt im Kundensystem, die Governance-Schicht verbindet sie mit Vertragsparametern, Renewal-Planung und den anderen Steuerungsmomente-Bereichen.

12. HowTo: Lizenz-Governance in sechs Schritten aufbauen {#12-howto-lizenz-governance-in-sechs-schritten-aufbauen}

Der Aufbau einer strukturierten Lizenz-Governance folgt einer klaren Sequenz. Die sechs Schritte führen von der Ist-Erhebung über die Optimierung bis zur Verankerung im Betriebsrhythmus.

Schritt 1: Ist-Zustand erheben (USMM und LAW)

USMM wird in allen Systemen ausgeführt, Messdateien werden exportiert. LAW-Konsolidierung wird durchgeführt. Das Ergebnis ist eine vollständige Übersicht der aktuellen Lizenzzahlen und Klassifizierungen je Produkttyp und je Lizenztyp.

Diese Erhebung schafft die Grundlage, auf der alle weiteren Schritte aufbauen. Ohne belastbare Ist-Daten ist jede Optimierungsmaßnahme spekulativ. Der Vertragscheck, den FinOptory als strukturierten Einstieg anbietet, geht über die reine USMM/LAW-Erhebung hinaus und stellt die Lizenzbasis in den Kontext der vertraglichen Vereinbarungen.

Schritt 2: Klassifizierung mit tatsächlicher Nutzung abgleichen

SAM4U wird installiert und Enhanced Usage Tracking wird aktiviert. Die STAR-Analyse wird intern durchgeführt und die Ergebnisse werden mit tatsächlichen Nutzungslogs abgeglichen. Das Ergebnis ist eine Liste der Fehlklassifizierungen und ihrer FUE-Auswirkung: Wie viele Nutzer könnten von einem höheren auf einen niedrigeren FUE-Typ umgestuft werden, und wie viele FUE würden dabei frei?

Dieser Schritt erfordert die Zusammenarbeit zwischen dem Contract Manager (der die FUE-Auswirkung bewertet), der IT/Basis (die die technischen Nutzungsdaten liefert) und dem Controlling (das die Kostenauswirkung berechnet).

Schritt 3: Rollen bereinigen und Berechtigungen optimieren

Role Creep wird identifiziert und technisch eingeschränkt. Inaktive Accounts werden nach der 90-Tage-Schwelle bereinigt. Das Ergebnis ist eine optimierte FUE-Basis, die als Grundlage für Verhandlungen und für die laufende Planung dient.

Dieser Schritt berührt den Steuerungsmoment Berechtigungen direkt: Die Rollenbereinigung vor dem nächsten PCE-Metering-Zyklus stellt sicher, dass das nächste Metering-Ergebnis die optimierte Situation widerspiegelt.

Schritt 4: Lizenz-Governance-Rhythmus definieren

Die Verantwortung für die einzelnen Governance-Aufgaben wird den vier Rollen zugeordnet. Monatliche, quartalsweise und jährliche Checkpoints werden eingerichtet und in den bestehenden IT-Governance-Rhythmus integriert. Das PCE-Metering-Dashboard in SAP for Me wird in das monatliche Reporting eingebunden.

Dieser Schritt macht die Lizenz-Governance von Einzelinitiativen unabhängig. Eine Governance-Struktur, die nur dann funktioniert, wenn eine bestimmte Person sich darum kümmert, ist fragil. Der Rhythmus muss institutionalisiert sein.

Schritt 5: Audit-Readiness-Dokumentation aufbauen

Eine strukturierte Dokumentation wird angelegt: Welcher Nutzer nutzt welche Transaktionen und warum? Technische Rollen werden den Lizenztypen zugeordnet. Die Integrationslandschaft für Digital Access wird dokumentiert: Welche Drittsysteme erzeugen SAP-Dokumente, und in welchem Volumen? Das Audit-Response-Team wird namentlich definiert.

Diese Dokumentation ist die Grundlage für den Vier-Phasen-Audit-Prozess. Wer im Audit-Fall auf eine vorbereitete Dokumentation zurückgreift, ist erheblich besser aufgestellt als wer die Dokumentation erst nach der Audit-Benachrichtigung erstellt.

Schritt 6: Lizenz-Reifegrad im Governance-Review verankern

Das Lizenz-Reifegradmodell wird als Standortbestimmungs-Instrument im quartalsweisen Governance-Review eingesetzt. Alle vier Rollen sind beteiligt. Cross-Produkt-Koordination (S/4HANA, SuccessFactors, Ariba, BTP) ist ein fester Tagesordnungspunkt. Der Fortschritt von Stufe zu Stufe wird dokumentiert und als strategisches Ziel verankert.

Dieser letzte Schritt schließt den Kreis zwischen operativer Lizenz-Governance und strategischer Vertragssteuerung. Wer den Lizenz-Reifegrad systematisch steuert, schafft die Datengrundlage, die im Steuerungsmoment Kosten und im Renewal-Prozess konkrete Verhandlungsposition erzeugt.

13. FAQ {#13-faq}

Was ist der Unterschied zwischen Named User und FUE?

Named User ist die Lizenzmetrik für On-Premise-Systeme (ECC, S/4HANA On-Premise): Jede Person benötigt eine individuell zugeordnete Lizenz eines bestimmten Typs. FUE (Full Use Equivalent) ist die Lizenzmetrik für S/4HANA Cloud-Systeme (RISE, GROW): Verschiedene Nutzertypen werden mit unterschiedlichen Gewichten in eine einheitliche Einheit umgerechnet, und Kunden kaufen einen FUE-Pool, den sie intern verteilen können.

Wie berechne ich den FUE-Bedarf meiner Organisation?

Die Grundformel: Total FUEs = (Advanced x 1,0) + (Core x 0,2) + (Self-Service x 0,033). Das Ergebnis wird aufgerundet. Der Developer-Typ ist vertragsspezifisch gewichtet (0,5 oder 2,0 FUE pro Developer) und muss separat geprüft werden. SAM4U bietet eine Simulation, die den aktuellen FUE-Bedarf auf Basis der tatsächlichen Berechtigungsstruktur berechnet und Optimierungspotenziale ausweist.

Warum ist die Konversionsrate für Developer-User vertragsspezifisch?

SAP hat keine einheitliche Standardgewichtung für Developer-User über alle Vertragsversionen hinweg festgelegt. In der Praxis zeigen sich abweichende Gewichtungen: 0,5 FUE pro Developer in einigen Vertragsversionen, 2,0 FUE pro Developer in anderen. Der Unterschied bei 20 Developern kann bis zu 30 FUEs betragen, was im sechsstelligen Bereich liegen kann. Der konkrete Vertrag muss immer geprüft werden.

Was ist berechtigungsbasierte Klassifizierung und wie unterscheidet sie sich von nutzungsbasierter?

Berechtigungsbasierte Klassifizierung misst, was ein Nutzer tun könnte (zugewiesene Berechtigungen). Nutzungsbasierte Klassifizierung würde messen, was ein Nutzer tatsächlich tut. In S/4HANA Cloud gilt das berechtigungsbasierte Modell: Die höchste Berechtigung in den zugewiesenen Rollen bestimmt den FUE-Typ, unabhängig von der tatsächlichen Nutzung.

Was ist der Unterschied zwischen USMM und SAM4U?

USMM ist das klassische Einzelsystem-Vermessungstool: Es zählt Named User nach Lizenztyp und misst Engine-Metriken. SAM4U ist ein modernes Optimierungstool mit Dashboard, Enhanced Usage Tracking, Optimierungsempfehlungen und einer Simulationsfunktion für Berechtigungsänderungen. SAM4U ist kostenlos, läuft im Kundensystem und bietet deutlich mehr analytische Tiefe als USMM allein.

Was macht LAW und wann brauche ich es?

LAW (License Administration Workbench) konsolidiert USMM-Ergebnisse aus mehreren Systemen zu einem einzigen Report und dedupliziert Benutzerkonten, die in mehreren Systemen existieren. LAW ist notwendig, sobald mehr als ein SAP-System in der Landschaft vorhanden ist. Im PCE-Metering-Kontext ist LAW das Konsolidierungselement zwischen den Kundensystemen und SAP.

Was ist PCE Metering und was ändert sich dadurch für meine Governance?

PCE Metering ist SAPs automatisiertes monatliches Lizenzmessungssystem für die Private Cloud Edition. Im Gegensatz zum jährlichen On-Premise-Audit-Zyklus triggert SAP das Metering monatlich. Das erfordert einen monatlichen Governance-Rhythmus: PCE-Metering-Dashboard prüfen, Rollenoptimierungen vor dem nächsten Metering-Zyklus abschließen, Diskrepanzen dokumentieren.

Welche Audit-Typen gibt es und wie unterscheiden sie sich?

Basic Audit ist die jährliche Standardmessung: Selbst durchgeführt, begrenzte Prüftiefe, moderates Risiko. Enhanced Audit ist eine vertiefte Prüfung: SAP GLA involviert, tiefgehende Rollenanalyse, Transaktionsnutzung und Indirect Access werden geprüft, Laufzeit drei bis sechs Monate, hohes finanzielles Exposure. Enhanced Audits fallen häufig mit kommerziellen Events zusammen (Renewals, Migrationen, M&A).

Was sind die häufigsten SAP-Compliance-Lücken in der Praxis?

Die häufigsten Kategorien sind: misklassifizierte Named User (15 bis 25 Prozent in einem durchschnittlichen Unternehmen, so Brancheneinschätzungen), inaktive Accounts und systemübergreifende Duplikate, Engine- und Paket-Überschreitungen (oft unbemerkt), und fehlende oder unzureichende Digital Access-Lizenzierung für Drittanbieter-Integrationen.

Was ist das finanzielle Exposure bei Misklassifizierung?

Bei 100 misklassifizierten Nutzern (Limited-Lizenz, tatsächlich Professional-Transaktionen) und einer Preisdifferenz von rund 1.500 USD pro Nutzer ergibt sich ein Nachkauf von 150.000 USD, zuzüglich drei Jahre Back-Maintenance (22 Prozent per annum) von rund 99.000 USD, also ein Gesamtexposure von rund 249.000 USD. Bei Engine-Überschreitungen oder Indirect Access-Lücken kann das Exposure erheblich höher sein.

Kann ich FUEs während der Laufzeit reduzieren?

In den meisten RISE-Verträgen ist eine Mid-Term-Reduktion der FUE-Anzahl nicht möglich. Wer zu viele FUE kauft, zahlt bis zum Renewal dafür. Eine True-Up/True-Down-Klausel, die nach 18 bis 24 Monaten eine Anpassung erlaubt, ist ein verhandelbares Vertragselement, das in der Vertragsverhandlung aktiv adressiert werden sollte.

Was ist eine True-Up/True-Down-Klausel bei RISE?

Eine True-Up/True-Down-Klausel erlaubt es, die FUE-Anzahl nach einer definierten Periode (typischerweise 18 bis 24 Monate nach Vertragsstart) anzupassen. True-Up bedeutet, dass zusätzliche FUE nachgekauft werden, wenn der tatsächliche Bedarf die ursprüngliche Kalkulation überschreitet. True-Down bedeutet, dass FUE reduziert werden können, wenn der tatsächliche Bedarf niedriger ist. Das schützt vor der Situation, dass FUE bis zum Vertragsende für ungenutzte Kapazität bezahlt wird.

Was bedeutet Lizenz-Reifegrad und wo stehen die meisten Organisationen heute?

Der Lizenz-Reifegrad beschreibt, wie systematisch eine Organisation ihre Named-User- und FUE-Governance betreibt: von reaktiver Klassifizierung (Stufe 1) über dokumentierte Baseline (Stufe 2), aktiv gesteuertem Betriebsrhythmus (Stufe 3) bis zur strategischen Verankerung in der IT-Planung (Stufe 4). In der Praxis befinden sich viele Organisationen auf Stufe 1 oder am Übergang zu Stufe 2. Der Schritt von Stufe 2 zu Stufe 3 erfordert den Aufbau eines regelmäßigen Self-Audit-Rhythmus und die Installation von SAM4U als laufendes Optimierungswerkzeug.

Wie unterscheidet sich FinOptory von SAM4U?

SAM4U ist ein kostenloses SAP-eigenes Tool für Lizenzmessung und -compliance: Es misst, identifiziert Optimierungspotenziale und bietet seit Q4/2025 eine Simulationsfunktion. SAM4U ist auf die Lizenzmessung fokussiert und bietet keine BTP/AI-Credit-Steuerung, kein Vertragsmanagement, keine interne Verrechnung und kein Forecasting. FinOptory ist als Consumer der SAM4U Data API konzipiert: Die Lizenzmessung bleibt im Kundensystem über SAM4U, FinOptory stellt die übergreifende Governance-Schicht bereit, die Lizenzdaten, Vertragsparameter, Renewal-Planung und alle vier Steuerungsmomente-Bereiche verbindet.

14. Nächste Schritte {#14-nachste-schritte}

Lizenz-Governance ist eine laufende Steuerungsaufgabe, kein einmaliges Projekt. Die Steuerungsmomente im Lizenzbereich, der Steuerungsmoment Nutzung und der Steuerungsmoment Berechtigungen, entstehen monatlich. Wer sie strukturiert nutzt, steuert planbar. Wer sie nicht adressiert, zahlt mehr als nötig und verliert Verhandlungsposition beim Renewal.

Vertragscheck buchen: Der strukturierte Einstieg in Stufe 2. In vier Wochen wird der Ist-Zustand der Lizenzbasis erhoben, Klassifizierungsabweichungen werden identifiziert, und die FUE-Basis wird dokumentiert. Sie erhalten Klarheit darüber, wo Sie stehen, und eine fundierte Grundlage für die nächste Governance-Entscheidung. Festpreis, vier Wochen, unabhängig von SAP. Jetzt Erstgespräch vereinbaren

Weiterführende Inhalte:

SAP Contract Governance: Steuerungsmomente und Governance-Grundlagen (Pillar 1)
BTP und SAP Business AI: Lizenzierung und Governance (Pillar 2)
BTP FinOps: Kosten steuern und Credit-Verfall vermeiden (Pillar 3)
Digital Access und Indirect Access: Governance und Compliance (Pillar 4)

Autor: Bernhard Mändle. Letztes Update: 21. Mai 2026. Für Fragen und Feedback: bernhard@green-dopamine.at