FUE (Full Use Equivalent)

Wenn du in einem Unternehmen SAP Cloud ERP Private (z. B. Private Edition/RISE-Kontext) planst, stolperst du früher oder später über drei Buchstaben, die erstaunlich viel bewegen: FUE. Viele behandeln FUE am Anfang als reine „Lizenzkennzahl“ – bis sie im Projekt plötzlich zur Leitwährung wird: für Budget, Rollout-Planung, Verhandlung und Governance.

FUE steht für Full Use Equivalent. Vereinfacht gesagt ist FUE ein Umrechnungsmodell, das unterschiedliche Nutzungsprofile (Personas) in eine vergleichbare Einheit überführt. Damit wird Lizenzierung und Kostenplanung deutlich skalierbarer, als wenn du jede Rolle einzeln lizenzlogisch betrachten würdest.

Ja, FUE ist „nur eine Zahl“. Aber in der Praxis ist FUE der Unterschied zwischen planbarer Transformation und Kosten-Diskussionen kurz vor Go-live.

Jetzt Kontakt aufnehmen!

Was ist FUE?

FUE bedeutet Full Use Equivalent. In der SAP-Lizenzlogik (besonders rund um Private-Cloud-/Private-Edition-Modelle) ist FUE eine Standardgröße, mit der du verschiedene Nutzungsprofile vergleichbar machst.

Statt „wir haben 3.000 Nutzer“ sagst du:
„Wir haben X FUE – verteilt auf definierte Personas mit klarer Berechtigungstiefe.“

FUE ist damit die Brücke zwischen:

Business-Realität: Wer nutzt was wirklich – und in welcher Tiefe?
IT-Realität: Welche Rollen/Berechtigungen sind dafür notwendig?
Finance-Realität: Wie budgetieren, forecasten und verhandeln wir belastbar?

Definition:
FUE (Full Use Equivalent) ist eine Umrechnungsgröße, mit der SAP-Nutzungsprofile (Personas) in eine vergleichbare Einheit überführt werden, um Lizenzierung, Budget und Skalierung planbar zu machen.

FUE ist nicht gleich „User“

Ein häufiger Denkfehler: FUE wird mit „Anzahl User“ verwechselt. Das führt fast automatisch zu falschen Entscheidungen.

User = Person im System
FUE = Äquivalenzwert für Nutzungsumfang/Berechtigungstiefe

Warum das wichtig ist:

Zwei Personen können beide „User“ sein – aber sehr unterschiedliche Aufgaben und Rechte haben.
FUE versucht, diese Unterschiede in eine steuerbare Einheit zu übersetzen, damit du nicht 50 Rollendefinitionen einzeln lizenzieren musst.

Merksatz:
FUE zählt nicht Menschen. FUE bewertet Nutzung.

Warum ist FUE wichtig für Kosten und Compliance?

Weil FUE genau dort wirkt, wo SAP-Programme teuer werden: bei Skalierung.

1) FUE macht Wachstum forecastbar

Rollouts, neue Werke, neue Länder, M&A: Wenn du FUE sauber modellierst, steuerst du Wachstum kommerziell – statt später hektisch nachzukaufen.

2) FUE zwingt dich zu klaren Personas (und begrenzt Role Creep)

FUE funktioniert nur mit Personas. Und Personas funktionieren nur mit klaren Rollenpaketen. Das bremst typische Berechtigungsinflation: „Gib mir auch noch das…“.

3) FUE wird zur Verhandlungsbasis

Wenn FUE nur Bauchgefühl ist, verhandelst du reaktiv. Wenn FUE aus Persona-Logik + Forecast kommt, verhandelst du strukturiert: mit Szenarien, Wachstumspfaden und belastbaren Zahlen.

4) FUE hilft bei Audit- und Nachweisfähigkeit (indirekt)

FUE ist kein Audit-Tool. Aber ein sauberes FUE-Setup erzeugt bessere Nachweise: Persona → Rollenpaket → Berechtigungstiefe → FUE-Zuordnung. Genau diese Kette lieben Compliance und interne Revision.

Typische FUE-Stolperfallen

„Wir rechnen FUE einmal – dann ist es erledigt.“

FUE ist kein Einmal-Excel. Rollen ändern sich, Organisationen ändern sich, Prozesse ändern sich. Wenn du FUE nicht pflegst, driftet das Modell weg.

„Wir nehmen lieber zu viel, sicher ist sicher.“

Klingt risikoarm, ist aber die häufigste Ursache für Überlizenzierung – besonders in Phase 1.

„Alle Key User bekommen automatisch das höchste Profil.“

Key User ist eine Projektrolle, kein Lizenztyp. Wenn du Key User pauschal hochstufst, explodiert dein FUE-Forecast.

„Wir definieren 40 Personas.“

Zu viele Personas zerstören den Sinn von FUE. Ziel sind 10–15 robuste Personas, die 80–90% der Nutzung abdecken.

Wie setzt du FUE pragmatisch auf?

Ein Setup, das im DACH-Raum schnell funktioniert und trotzdem belastbar bleibt:

Personas definieren (10–15)
Beispiele: AP Clerk, Approver, Planner, Warehouse User, Sales Ops, Finance Controller, Developer, Admin.
Berechtigungstiefe je Persona fachlich beschreiben
Nicht „welche Transaktionen“, sondern: Was muss die Persona wirklich können?
FUE-Zuordnung je Persona dokumentieren
Persona → FUE-Wert → Rollenpaket → Owner → Gültigkeitsregeln.
Forecast aufbauen (12–36 Monate)
Rollout-Wellen (Land/Standort/BU), Headcount, Saison, M&A-Option.
Governance-Regel: „Neue Rolle ⇒ FUE-Check“
Jede Berechtigungserweiterung triggert eine kurze Prüfung.
Review-Rhythmus etablieren
Quartalsweise: Joiner/Mover/Leaver, High-Privilege-Ausreißer, Forecast-Abweichungen, Maßnahmen.

Praxisbeispiel: FUE-Mapping in einem Rollout

Stell dir ein mittelständisch geprägtes Unternehmen mit 2.400 Mitarbeitenden vor, davon 650 direkte SAP-Nutzer in Finance, Procurement, Warehouse und Sales Ops. Es soll eine Private-Edition-Einführung in drei Wellen geben: Deutschland → Österreich → Schweiz.

Schritt 1: Personas

Das Projektteam definiert 12 Personas, u. a.:

AP Clerk (Kreditorenbuchhaltung)
Approver
Warehouse User
Planner
Controller
Key User (fachlich)
Developer
Admin

Wichtig: „Key User“ wird nicht automatisch als „höchstes Profil“ gesetzt, sondern als Persona mit klarer fachlicher Aufgabenbeschreibung (z. B. Tests, Freigaben, Prozess-Coaching).

Schritt 2: FUE-Zuordnung + Rollenpakete

Für jede Persona wird ein Rollenpaket definiert und ein FUE-Wert zugeordnet (Beispielhaft, zur Illustration):

AP Clerk: 0,5 FUE
Approver: 0,2 FUE
Warehouse User: 0,2 FUE
Controller: 0,5 FUE
Key User (fachlich): 0,7 FUE
Developer: 1,0 FUE
Admin: 1,0 FUE

Schritt 3: Forecast über Rollout-Wellen

Jetzt wird nicht „650 User“ geplant, sondern:

Welle 1 (DE): 380 Nutzer → 210 FUE
Welle 2 (AT): 160 Nutzer → 85 FUE
Welle 3 (CH): 110 Nutzer → 55 FUE

Zusätzlich wird ein Wachstumsszenario modelliert: +10% Nutzer in 24 Monaten (neue Standorte + Shared Services). Ergebnis: ein belastbarer FUE-Korridor statt Bauchgefühl.

Schritt 4: Governance-Regel verhindert Role Creep

Das Unternehmen führt eine Regel ein:
Jede neue Berechtigung außerhalb des Rollenpakets = FUE-Check im Architektur-/Security-Board.
Das klingt streng, spart aber real Geld: Das Team verhindert, dass 80 Approver „aus Komfort“ in ein Controller- oder Key-User-Profil hochrutschen.

Take-away aus dem Beispiel:
FUE wird steuerbar, wenn du Personas klein hältst, Rollenpakete standardisierst und Wachstum als Szenario modellierst – nicht als Überraschung.

Best Practice: FUE als Operating Model managen

Wenn FUE skalieren soll (und nicht jedes Jahr neu diskutiert wird), brauchst du Wiederholbarkeit:

Persona Catalog: Approved Personas + FUE-Zuordnung
Approved Role Sets: pro Persona ein Standard-Rollenpaket
Change Control: Berechtigungsänderungen mit FUE-Impact prüfen
Cost Attribution: Persona/Team → Kostenstelle (Showback/Chargeback light)
Quarterly Review: FUE Baseline vs. Ist, Ausreißer, Maßnahmen

Warum das im DACH-Raum besonders gut funktioniert: Weil es Governance und Nachweise liefert – ohne Innovationsbremse.

Fazit

FUE (Full Use Equivalent) ist mehr als eine Kennzahl. FUE ist ein Steuerungsmodell, mit dem du unterschiedliche Nutzungsprofile in eine planbare Einheit überführst. Wenn du FUE über klare Personas, saubere Rollenpakete und einen festen Review-Rhythmus führst, wird Lizenzierung planbar, Kosten werden forecastbar und Compliance wird einfacher – genau das, was du für skalierbare SAP-Programme im deutschsprachigen Raum brauchst.