Was ist das – und warum PUPM in SAP Public-Cloud-Projekten über Kosten und Steuerbarkeit entscheidet

Wenn du SAP Public Cloud planst (zum Beispiel SAP S/4HANA Cloud, Public Edition), begegnet dir ziemlich schnell ein Begriff, der nach „Abrechnung“ klingt – aber in Wahrheit dein ganzes Operating Model prägt: PUPM.

PUPM steht für Per User Per Month. Klingt simpel: Du zahlst pro Nutzer und Monat. In der Praxis ist PUPM aber mehr als eine Preismetrik. Es ist ein Steuerungsmodell, das direkt beeinflusst, wie du Personas definierst, Rollen vergibst, Berechtigungen kontrollierst und Kosten forecastest.

Und genau deshalb entscheiden Public-Cloud-Programme nicht selten an PUPM früher über Erfolg oder Reibung als an der Technik: Wenn dein User-Modell nicht sauber ist, bekommst du Role Creep, zu viele High-Tier-User und am Ende Kosten, die niemand erklären will.

Jetzt Kontakt aufnehmen!

Was ist PUPM?

PUPM bedeutet Per User Per Month – also ein Abrechnungsmodell, bei dem du Nutzungsrechte in der Public Cloud als monatliche Nutzergebühr planst und kaufst.

Wichtig ist: In Public-Cloud-Umgebungen hängen Nutzerpreise typischerweise an User-Kategorien / User-Typen (z. B. „Standard“, „Advanced“, „Self-Service/Light“ – je nach Produkt und Vertrag). PUPM ist dann die Abrechnungseinheit, aber die eigentliche Steuerung passiert über:

User-Typ / Zugriffstiefe
Rollen- und Berechtigungspakete
Governance für Änderungen (Upgrades, Sonderrollen)

Definition :
PUPM (Per User Per Month) ist ein nutzerbasiertes Abrechnungsmodell in SAP Public-Cloud-Angeboten, bei dem Kosten pro Nutzer und Monat entstehen – gesteuert über User-Typen, Rollenpakete und Governance.

PUPM ist nicht gleich „User Count“

Ein häufiger Irrtum: „Wir haben 1.000 Nutzer, also zahlen wir 1.000×PUPM.“ So einfach ist es selten.

User Count = Anzahl der Personen mit Zugriff
PUPM-Kosten = Anzahl pro User-Typ × Preis pro Monat × Laufzeit

Der Hebel ist nicht nur „wie viele Nutzer“, sondern vor allem:

welche Nutzer bekommen welchen User-Typ
wie stabil bleibt das Rollenmodell über die Zeit

Merksatz:
PUPM zählt nicht nur Menschen. PUPM bewertet Zugriffstiefe – und die wächst ohne Regeln gern automatisch.

Warum ist PUPM wichtig für Kosten und Compliance?

Weil PUPM in der Public Cloud dein Äquivalent zu „Berechtigungs- und Kostensteuerung“ ist.

1) PUPM macht Kosten grundsätzlich planbar – wenn dein User-Mix stabil ist

Wenn du weißt, wie viele Nutzer welche Zugriffstiefe brauchen, kannst du sauber forecasten. Wenn nicht, wird PUPM zur Dauer-Diskussion.

2) PUPM zwingt dich zu Personas (und das ist gut)

Ein belastbares PUPM-Setup basiert nicht auf Stellenbezeichnungen, sondern auf Personas, z. B.:

AP Clerk
Approver
Warehouse User
Planner
Controller
Key User (fachlich)
Admin/IT Ops

Personas sind der Mechanismus, der Business-Realität und Berechtigungen zusammenbringt.

3) PUPM ist ein Governance-Thema (nicht nur Pricing)

Jede Berechtigungserweiterung kann implizit bedeuten: „Dieser User braucht einen höheren User-Typ.“ Ohne Regeln entsteht Role Creep – und damit Kostenwachstum ohne Business-Mehrwert.

4) PUPM unterstützt Audit- und Nachweisfähigkeit

Public-Cloud-Organisationen müssen häufig erklären können:

Wer hat welche Berechtigungen?
Warum ist dieser User-Typ erforderlich?
Wer hat genehmigt, dass jemand hochgestuft wurde?

PUPM zwingt dich, diese Fragen früh zu operationalisieren.

PUPM vs. FUE vs. Named User: die klare Abgrenzung

Wenn du PUPM, FUE und Named User nicht sauber trennst, passieren zwei Dinge: Forecasts werden ungenau – und Berechtigungen wachsen, ohne dass jemand den Kostenimpact steuert.

1) PUPM (Per User Per Month) – Public Cloud Abrechnung

PUPM ist ein Preismodell: du zahlst pro Nutzer und Monat, typischerweise je User-Typ / Zugriffstiefe.

Typischer Einsatz: SAP Public Cloud
Steuerungshebel: User-Typen + Rollenpakete + Upgrade-Governance
Hauptrisiko: zu viele High-Tier-User („lieber höher, dann gibt’s keine Tickets“)

Merksatz: PUPM = monatlicher Preis pro User (nach Zugriffstiefe).

2) FUE (Full Use Equivalent) – Private Cloud Steuerungsgröße

FUE ist ein Äquivalenz-/Gewichtungsmodell, das Personas in eine vergleichbare Einheit übersetzt.

Typischer Einsatz: SAP Private Cloud / Private Edition
Steuerungshebel: Persona-Katalog + Rollenpakete + 12–36 Monate Forecast
Hauptrisiko: Drift (einmal gerechnet, nie gepflegt) → Nachkaufdruck

Merksatz: FUE = gewichtete Nutzung als Standardgröße für Planung/Verhandlung.

3) Named User – klassisches On-Prem Lizenzprinzip

Named User ist ein Nutzungsrecht pro Person (häufig in On-Prem/Perpetual-Welten) mit Kategorien nach Berechtigungstiefe.

Typischer Einsatz: SAP On-Premise (klassisch Perpetual) und Hybrid
Steuerungshebel: Identity-Prozess (Joiner/Mover/Leaver) + Rollen-Compliance
Hauptrisiko: Role Creep + fehlender Nachweis → Audit-Risiko

Merksatz: Named User = personenbezogenes Nutzungsrecht.

Der Kernunterschied auf einen Blick

Modell	Was es ist	Typischer Einsatz	Steuerung	Haupt-Risiko
PUPM	Preis pro User/Monat	Public Cloud	User-Typen & Rollenpakete	High-Tier-Inflation
FUE	Äquivalenz-/Gewichtung	Private Cloud	Personas → FUE → Forecast	Forecast-Drift
Named User	Nutzungsrecht pro Person	On-Prem (Perpetual)	Identity & Rollen	Role Creep/Audit

Typische PUPM-Stolperfallen

„Alle bekommen erstmal den höheren User-Typ.“

Kurzfristig bequem, langfristig teuer. Das ist der häufigste Kostentreiber in PUPM-Setups.

„Key User = High-Tier-User.“

Key User ist eine Projektrolle, kein dauerhaftes Lizenzprofil. Ohne Rückstufung nach Go-live zahlst du dauerhaft zu viel.

„Wir definieren 50 Personas.“

Zu viele Personas bedeuten: zu viele Ausnahmen, zu wenig Steuerbarkeit. Ziel: 10–15 Personas, die 80–90% abdecken.

„Berechtigungen wachsen, aber niemand trackt den User-Mix.“

Wenn du den Mix nicht regelmäßig prüfst, merkst du erst beim Renewal, dass du schleichend hochgerutscht bist.

Wie setzt du PUPM pragmatisch auf?

Ein Setup, das in DACH-Unternehmen schnell funktioniert:

10–15 Personas definieren
Fokus auf Prozesse, nicht Org-Chart.
Pro Persona ein Rollenpaket (Approved Role Set)
Standardrollenpaket je Persona – keine 20 individuellen Varianten.
Pro Persona ein Ziel-User-Typ
Das ist dein Standardprofil, nicht dein „Maximum“.
Regel: „Neue Rolle ⇒ PUPM-Check“
Jede Berechtigung außerhalb des Standards triggert: Muss der User-Typ angepasst werden? Wer genehmigt?
Forecast: 12–36 Monate
Rollout-Wellen, Wachstum/M&A-Szenario, saisonale Peaks.
Review-Rhythmus
Monatlich (wenn dynamisch) oder quartalsweise (wenn stabil):
- User-Mix
- Ausreißer
- Maßnahmen (Downgrade, Cleanup, Schulung)

Praxisbeispiel: PUPM-Setup im DACH-Rollout

Ein Unternehmen startet mit SAP S/4HANA Cloud, Public Edition für Finance & Procurement in Deutschland, später AT/CH. Es gibt 600 geplante Nutzer.

Schritt 1: Personas statt Jobtitel

Das Team definiert 12 Personas, u. a.:

AP Clerk (200)
Approver (180)
Procurement Specialist (90)
Controller (60)
Warehouse User (40)
Key User (fachlich) (20)
Admin/IT Ops (10)

Schritt 2: Standard-User-Typ je Persona

AP Clerk: Standard
Approver: Self-Service/Light (wenn möglich)
Procurement Specialist: Standard/Advanced (je nach Prozess)
Controller: Advanced
Key User: temporär Advanced, nach Go-live Rückstufung verpflichtend prüfen
Admin: Advanced

Schritt 3: Governance spart Geld

Nach 3 Monaten zeigt das Review:

45 Approver wurden aus „Komfort“ in Standard hochgestuft
12 Key User sind nach Go-live nicht zurückgestuft worden

Maßnahmen:

Approver zurück auf Light-Profil + saubere Rollenpakete
Key-User-Profil befristet („Projektrolle“) + Rückbau-Termin

Take-away:
PUPM bleibt planbar, wenn Upgrades Ausnahmen sind – nicht Standard.

Best Practice: PUPM als Operating Model managen

Wenn PUPM skalieren soll (ohne Kostenexplosion), brauchst du Wiederholbarkeit:

Persona Catalog: Approved Personas + Ziel-User-Typ
Approved Role Sets: Rollenpakete pro Persona
Change Control: Upgrades nur mit kurzer Freigabe (Owner + Grund + Befristung)
Cost Attribution: Persona/Team → Kostenstelle (Showback light)
Review Cadence: User-Mix, Ausreißer, Maßnahmen

Damit wird PUPM nicht „Lizenzstress“, sondern ein steuerbares Modell.

FAQ

Was bedeutet PUPM bei SAP?

PUPM steht für Per User Per Month und beschreibt ein nutzerbasiertes Abrechnungsmodell (monatliche Kosten pro Nutzer), oft gesteuert über User-Typen.

Ist PUPM nur ein Preismodell?

Nein. PUPM ist auch ein Governance-Modell, weil Berechtigungen/Upgrades den User-Mix verändern und damit Kosten.

Was ist der Unterschied zwischen PUPM und FUE?

PUPM ist ein Public-Cloud-Preismodell pro Nutzer/Monat und User-Typ. FUE ist eine Private-Cloud-Steuerungsgröße, die Personas in eine gewichtete Einheit übersetzt, um Forecast und Verhandlung zu vereinfachen.

Was ist der Unterschied zwischen PUPM und Named User?

Named User ist das klassische Nutzungsrecht pro Person (häufig On-Prem/Perpetual), während PUPM eine monatliche Abrechnung in der Public Cloud ist – typischerweise entlang von User-Typen.

Wie verhindere ich PUPM-Kostensteigerungen?

Mit Personas, standardisierten Rollenpaketen, der Regel „Neue Rolle ⇒ PUPM-Check“ und einem festen Review-Rhythmus.

Wie viele Personas braucht man für ein PUPM-Setup?

Meist reichen 10–15 Personas, die 80–90% der Nutzung abdecken. Mehr erhöht Komplexität ohne Mehrwert.

Fazit

PUPM (Per User Per Month) klingt nach einfacher Abrechnung – ist aber in der SAP Public Cloud ein zentrales Steuerungsmodell. Wenn du Personas sauber definierst, Rollenpakete standardisierst und Upgrades als genehmigungspflichtige Ausnahme behandelst, bleibt dein User-Mix stabil – und PUPM damit planbar. Und wenn du PUPM sauber von FUE (Private Cloud Gewichtungsmodell) und Named User (On-Prem Lizenzprinzip) abgrenzt, bekommst du Forecasts, die Finance versteht – und Governance, die IT nicht ausbremst.