Named User und FUE: Die zwei Welten der SAP-Lizenzierung verstehen

SAP lizenziert On-Premise-Systeme und Cloud-Systeme nach unterschiedlichen Metriken. On-Premise gilt das Named-User-Prinzip: Jede Person mit SAP-Zugang benötigt eine individuell zugeordnete Lizenz eines bestimmten Typs. In der Cloud, konkret in RISE with SAP und GROW with SAP, gilt das FUE-Modell: Kunden kaufen einen Pool aus Full Use Equivalents und verteilen ihn intern auf Nutzertypen. Wer beide Welten im Portfolio hat, braucht ein Verständnis beider Mechaniken, und ein klares Bild davon, was der Übergang von Named User auf FUE für die laufende Steuerung bedeutet.

1. Named User: Grundprinzip und Lizenztypen im Überblick

Das Named-User-Prinzip ist eindeutig: Jede natürliche Person, die auf SAP zugreift, benötigt eine namentlich zugeordnete Lizenz. Concurrent-User-Modelle, bei denen eine bestimmte Anzahl gleichzeitiger Nutzer lizenziert wird, existieren bei SAP nicht.

Die Lizenztypen unterscheiden sich in Zugriffsumfang und Preis erheblich. Für ECC-Systeme gelten fünf primäre Typen:

Professional User 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, zuzüglich jährlicher Maintenance von rund 22 Prozent (Quelle: Redress Compliance, SAP Product and Pricing Definitions).

Limited Professional User erlaubt eingeschränkten Zugriff auf definierte Module oder Funktionen. 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, Einblick in HR-Stammdaten. Dieser Typ wird in der Regel in Bulk-Paketen bezogen.

Developer User ermöglicht Zugriff auf ABAP Workbench und Entwicklungstools. Wichtig: Developer User dürfen ausschließlich für Entwicklungszwecke genutzt werden, nicht für produktive Geschäftsprozesse.

Test User ist vertragsabhängig geregelt und für QA-Teams und Testautomatisierung in Test- und QA-Systemen vorgesehen.

Mit S/4HANA On-Premise hat SAP die Nomenklatur angepasst. Die fünf Kategorien heißen dort: Professional User, Functional User (entspricht dem früheren Limited Professional), Productivity User, Self-Service User und Developer User. Die inhaltliche Logik bleibt dieselbe, die Zuordnung bestimmter Transaktionen zu Nutzertypen hat SAP jedoch 2025 an einigen Stellen verändert. Bei Migrationen und Vertragsreviews ist ein direkter Vergleich der aktuellen Rollen-Nutzertyp-Zuordnung mit der vorherigen Version sinnvoll.

Die Compliance-Anforderung beim Named-User-Modell ist klar: Jeder Nutzertyp muss einzeln compliant sein. Wer einen Limited-Typ hat, aber Professional-Transaktionen ausführt, ist unterlizenziert, unabhängig davon, wie viele ungenutzte Professional-Lizenzen im selben System existieren.

2. FUE: Poolbasiertes Modell und Konversionsgewichte

Das FUE-Modell (Full Use Equivalent) funktioniert nach einem anderen Grundprinzip: Kunden kaufen einen Pool aus FUE-Einheiten und verteilen diesen intern auf Nutzertypen. Solange die gewichtete Summe aller Nutzer innerhalb des gekauften FUE-Pools bleibt, ist die Organisation compliant. Interne Rollenverschiebungen, etwa von Advanced auf Core, erfordern keine Neuverhandlung mit SAP, sofern der FUE-Headroom vorhanden ist (Quelle: SAP Community, RISE with SAP FUE Concept).

Die vier FUE-Nutzertypen und ihre Gewichte:

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 macht die Klassifizierung zum entscheidenden Planungsparameter: Ein Advanced User entspricht 5 Core Usern oder rund 30 Self-Service Usern in FUE-Gewichtung. Anders formuliert: 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).

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

Die Berechnungsformel 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: 50 Advanced User, 100 Core User und 300 Self-Service User ergeben 80 FUE. Würde dieselbe Organisation alle 450 Nutzer als Advanced lizenzieren, wären 450 FUE erforderlich. 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).

3. Kostenrelation: Warum die Klassifizierung der wichtigste Steuerungsmoment ist

Das größte Optimierungspotenzial im FUE-Modell liegt in der Klassifizierungsqualität. Wenn ein Nutzer als Advanced lizenziert ist, aber tatsächlich nur Core-Funktionalität nutzt, werden 0,8 FUE pro Nutzer verbraucht, ohne dass dieser Mehrbedarf durch tatsächliche Nutzung gerechtfertigt ist.

Korrekte Klassifizierung nach tatsächlichem Funktionsumfang ist laut SAP Service Description Guide verpflichtend. Advanced-Klassifizierung tritt als Default ein, wenn keine explizite Klassifizierung vorliegt. 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 (Quellen: RISE SDG v11-2024, SAP Community Blog by SAP).

Das FUE-Modell bietet gegenüber dem Named-User-Modell einen strukturellen Vorteil: Ein Überschuss bei einem Typ kann einen Mehrbedarf bei einem anderen Typ kompensieren, solange der Gesamtpool nicht überschritten wird. Diese Flexibilität ist ein Steuerungsmoment im Bereich Nutzung, der planbar genutzt werden kann. Voraussetzung ist, dass der FUE-Verbrauch laufend mit dem vertraglichen FUE-Pool abgeglichen wird, nicht nur einmal jährlich.

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 eine der folgenreichsten Entscheidungen im Vertragskontext. 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.

4. Hybridlandschaften: On-Prem und RISE gleichzeitig

Viele Organisationen betreiben On-Premise-Systeme und Cloud-Systeme parallel. In dieser Konstellation laufen Named-User-Lizenzierung und FUE-Lizenzierung gleichzeitig. Das erfordert eine getrennte Governance für beide Dimensionen.

Für die On-Premise-Seite gilt: USMM misst Named User je System, LAW konsolidiert und dedupliziert systemübergreifend. Der Compliance-Check erfolgt auf Typ-Ebene: Ist jeder Nutzertyp einzeln compliant?

Für die Cloud-Seite gilt: PCE Metering erfasst monatlich automatisiert die FUE-Nutzung auf Basis der zugewiesenen Berechtigungen. Der Compliance-Check erfolgt auf Pool-Ebene: Bleibt die gewichtete Summe aller Nutzer innerhalb des gekauften FUE-Pools?

Die Herausforderung in Hybridlandschaften liegt in der koordinierten Steuerung beider Metriken. Wer einen Named User in ein RISE-System migriert, ändert damit auch die Lizenzmetrik für diesen Nutzer. Was in ECC als Limited Professional zählte, kann in RISE als Core oder Advanced FUE zählen, abhängig von der tatsächlichen Rollenzuordnung im neuen System. Eine Migrationsanalyse, die die FUE-Implikation jeder geplanten Nutzer-Übertragung bewertet, ist Teil einer strukturierten Migrations-Governance.

5. Was sich beim Wechsel von Named User auf FUE ändert

Der Wechsel vom Named-User-Modell auf das FUE-Modell verändert nicht nur die Lizenzmetrik, sondern auch die Anforderungen an die laufende Steuerung.

Beim Named-User-Modell steht die korrekte Typ-Zuordnung im Mittelpunkt: Welcher Nutzer hat welchen Typ, und ist dieser Typ durch die ausgeführten Transaktionen gerechtfertigt? Der Steuerungsmoment liegt in der Klassifizierungsqualität und in der Bereinigung inaktiver Accounts.

Beim FUE-Modell kommt die Berechtigungsdimension hinzu: In S/4HANA Cloud wird der Nutzertyp nicht durch tatsächliche Nutzung bestimmt, sondern durch die zugewiesene Berechtigung. Wer eine Rolle mit Advanced-Berechtigungen zugewiesen hat, wird als Advanced User gezählt, unabhängig davon, ob er diese Berechtigung tatsächlich nutzt. Rollendesign ist damit ein direkter Lizenzkostenhebel, der im Named-User-Modell in dieser Form nicht existiert.

Der monatliche PCE-Metering-Rhythmus verschärft die zeitliche Anforderung: Compliance-Fehler werden im FUE-Modell mit Cloud-Metering potenziell 12-mal schneller sichtbar als im On-Premise-Kontext, wo eine Vermessung einmal jährlich erfolgt. Das erfordert einen monatlichen Governance-Rhythmus, der im Named-User-Kontext jährlich ausreichend war.

6. Drei häufige Klassifizierungsfehler und wie sie entstehen

Die meisten Klassifizierungsfehler entstehen nicht durch vorsätzliche Falschdeklaration, sondern durch strukturelle Ursachen: fehlende Lifecycle-Prozesse, schleichende Berechtigungserweiterungen und unzureichende Dokumentation. Die Herausforderung liegt in der Systemkomplexität, nicht bei den Personen, die damit arbeiten.

Fehler 1: Pauschal-Advanced ist das häufigste und kostspieligste Muster. Organisationen ohne strukturierte Nutzeranalyse weisen allen Nutzern Advanced- oder Professional-Berechtigungen zu, weil die genaue Abgrenzung aufwendig erscheint. Das Ergebnis ist eine systematisch überhöhte FUE-Basis. Da Mid-Term-Reduktionen in RISE-Verträgen in der Regel nicht möglich sind, wird dieser Fehler bis zum nächsten Renewal festgeschrieben.

Fehler 2: Role Creep beschreibt die schleichende Erweiterung von Berechtigungen über das lizenzierte Niveau hinaus. Ein Self-Service User erhält zusätzliche Rollen für einen spezifischen Prozessschritt, die de facto Core-Berechtigungen enthalten. Im FUE-Modell wird er ab diesem Zeitpunkt als Core User gezählt, obwohl nur ein Small-Scale-Bedarf besteht. Ohne laufende Überwachung akkumuliert sich Role Creep über Monate, bevor er im Metering-Ergebnis sichtbar wird.

Fehler 3: Inaktive Accounts werden im Named-User-Modell von USMM mitgezählt, unabhängig davon, ob der Nutzer das System in den letzten zwei Jahren verwendet hat. In Organisationen ohne strukturiertes Offboarding-Prozedere sind 10 Prozent und mehr der zählbaren Accounts inaktiv. Die etablierte Praxisschwelle für die Bereinigung ist 90 Tage ohne Login (Quelle: SAP-Named-User-License-Types, Governance-Empfehlungen).

Alle drei Fehler lassen sich durch einen strukturierten Governance-Rhythmus adressieren: quartalsweise Self-Audits, laufendes Monitoring des FUE-Verbrauchs und eine definierte Schwelle für die Bereinigung inaktiver Accounts. Das Lizenz-Reifegradmodell in Pillar 6 beschreibt, was auf jeder Stufe konkret erforderlich ist, um von reaktiver Klassifizierung zu aktiver Steuerung zu kommen.

FAQ

Was ist der Unterschied zwischen Named User und FUE?

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

Welche FUE-Typen gibt es und wie sind sie gewichtet?

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

Kann ich FUEs während der Laufzeit reduzieren?

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

Was passiert beim Wechsel von ECC auf S/4HANA mit meiner Lizenzbasis?

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

Wie viele Nutzer benötigen tatsächlich Advanced-Zugriff?

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

Nächste Schritte

Wer Named User und FUE im eigenen SAP-Portfolio strukturiert bewerten möchte, findet im Vertragscheck einen strukturierten Einstieg: Ist-Zustand der Lizenzbasis erfassen, Klassifizierungsabweichungen identifizieren, Optimierungspotenzial bewerten. Vier Wochen, Festpreis.

Weiterführende Artikel in dieser Reihe: