PUPM bei SAP Business AI: Wie das Per-User-per-Month-Modell wirklich funktioniert
Per-User-per-Month klingt nach klassischer Lizenz, ist aber ein Verbrauchsmodell mit Monatsverfall. Bei SAP Business AI verfallen ungenutzte Requests am Monatsende, nicht am Jahresende. Was das in der Budget-Planung, im Forecasting und bei Mitarbeiterfluktuation bedeutet, und welche Steuerungsmomente sich daraus ergeben.
Wie PUPM bei SAP Business AI mechanisch funktioniert
PUPM steht für Per-User-per-Month. Im Kontext von SAP Business AI beschreibt es ein Verbrauchsmodell, bei dem jedem Nutzer monatlich ein fixes Kontingent an AI-Requests zugeteilt wird. Der Ausgangspunkt ist die technische Zuordnung: Jeder Nutzer erhält im SAP Identity Service (IAS) eine Paket-Zuweisung. Dieses Paket definiert, welche AI-Capabilities der Nutzer verwenden darf und wie viele Requests pro Monat dafür bereitstehen.
Die Pakete sind nicht produktübergreifend, sondern nach Lösungsbereichen geschnitten: Finance, Spend Management, Customer Experience, Human Capital Management. Ein Nutzer, der Joule in Finance und im Einkauf einsetzen will, benötigt zwei separate Pakete, denn paketübergreifendes Pooling ist nicht vorgesehen. Jedes Paket wird einzeln gekauft und einzeln abgerechnet.
Innerhalb eines Pakets existiert ein begrenzter Ausgleichsmechanismus: Nicht genutzte Requests eines Nutzers können im laufenden Monat von anderen Nutzern desselben Pakets genutzt werden. Das erlaubt eine gewisse Flexibilität bei ungleichmäßiger Nutzung innerhalb einer Gruppe (Quelle: SAP Learning, Analyzing the PUPM Pricing Model). Dieser Ausgleich arbeitet jedoch ausschließlich innerhalb eines Pakets. Paket A gleicht nie Paket B aus.
Wann Requests verfallen und wie viel
Der zentrale Steuerungsmoment im PUPM-Modell ist der Monatsverfall. Jedes Paket endet nach 30 Tagen. Was nicht verbraucht ist, verfällt. Es gibt keinen Übertrag auf den Folgemonat, auch nicht anteilig.
Dieser Verfall unterscheidet sich strukturell vom Verfall klassischer Jahres-AI-Units: Während AI-Unit-Kontingente am Jahresende verfallen, verliert PUPM monatlich. Für die Investitionsplanung bedeutet das: Wer die Adoption unterschätzt oder den Rollout verzögert, verliert Budget nicht einmal im Jahr, sondern jeden Monat.
In der Praxis treten diese Verluste häufig in zwei Situationen auf. Erstens in der Anlaufphase eines Rollouts: Nutzern werden Pakete zugewiesen, bevor die Schulung abgeschlossen ist oder bevor die Workflows stabil laufen. Das Paket wird bezahlt, der Request-Pool verfällt. Zweitens bei ungleichmäßiger saisonaler Nutzung: Geschäftsbereiche, die im Jahresrhythmus arbeiten, zum Beispiel mit starkem Monatsabschluss und ruhigeren Zwischenmonaten, zahlen auch für Monate, in denen die Nutzung gering ist.
Der Monatsverfall ist kein Fehler im Modell, sondern eine bewusste Strukturentscheidung. Als Steuerungsmoment bedeutet er: PUPM-Pakete müssen nicht nur einmalig beim Kauf bewertet werden, sondern laufend. Wer Adoption, Rollout-Stand und tatsächliche Nutzung nicht monatlich beobachtet, zahlt strukturell mehr als nötig. Controlling und Contract Manager brauchen dafür eine regelmäßige Sicht auf den Paket-Ausschöpfungsgrad, die aus Standard-Reporting allein nicht herstellbar ist (Quelle: SAP Help Portal, Metering and Pricing for SAP AI Core).
Pooling innerhalb des Pakets
Der Pooling-Mechanismus bei PUPM ist präzise begrenzt. Requests sind innerhalb eines Pakets poolbar: Nutzt Nutzer A sein Kontingent in einem Monat nicht vollständig, können die verbleibenden Requests von Nutzer B desselben Pakets genutzt werden. Das erlaubt einen Ausgleich innerhalb der Nutzungsgruppe.
Drei Pooling-Grenzen sind für die Steuerung relevant. Erstens funktioniert das Pooling nicht paketübergreifend: Finance-Pakete und Procurement-Pakete bleiben getrennte Töpfe, auch wenn sie demselben Unternehmen gehören. Zweitens ist Pooling auf den laufenden Monat beschränkt. Weder innerhalb eines Pakets noch paketübergreifend gibt es einen Monat-zu-Monat-Übertrag. Drittens ist die Steuerbarkeit des Poolings von außen begrenzt: SAP berichtet Verbrauch auf Paket-Ebene, nicht auf Nutzer-Ebene innerhalb eines Pakets. Wer wissen will, welcher Nutzer wie viel des Pools verbraucht hat, findet diese Information nicht im Standard-Reporting (Quelle: SAP Learning, Analyzing the PUPM Pricing Model).
Diese fehlende Granularität ist ein strukturelles Hindernis für laufende Steuerung. Controlling kann auf Paket-Ebene beobachten, ob das Kontingent genutzt wird. Wer aber steuern will, ob die richtigen Nutzer die richtigen Pakete haben, braucht eine Beobachtungsebene, die über das native SAP-Reporting hinausgeht. Das ist der Ausgangspunkt für eine eigenständige Governance-Funktion. Genau hier liegt ein zentraler Steuerungsmoment: Die Zuweisung und regelmäßige Überprüfung von PUPM-Paket-Zuordnungen ist keine einmalige Onboarding-Aufgabe, sondern eine laufende Steuerungsaufgabe.
Was bei Mitarbeiterfluktuation passiert
Mitarbeiterfluktuation ist ein häufig unterschätzter Kostentreiber bei PUPM-Modellen. Das Modell selbst hat keine automatische Bereinigungsfunktion. Wenn ein Nutzer das Unternehmen verlässt, bleibt das zugeordnete PUPM-Paket aktiv, solange es nicht manuell deaktiviert wird. Der Slot wird weiter bezahlt, das Request-Kontingent verfällt weiter monatlich.
In der Praxis entsteht daraus eine strukturelle Lücke zwischen HR-Offboarding und SAP-Lizenz-Management. Der Zeitraum zwischen dem letzten Arbeitstag eines Nutzers und der tatsächlichen Paket-Deaktivierung kann je nach Prozessreife Wochen oder Monate betragen.
Die Gegenrichtung ist ebenfalls relevant: Wenn ein neuer Mitarbeiter eine Stelle antritt, muss das PUPM-Paket aktiv zugeordnet werden. Das geschieht manuell oder über Excel-Batch-Upload, nicht automatisch aus dem HR-System. Bis die Zuordnung vorliegt, bleibt der Slot unbesetzt und das Paket-Kontingent wird gepoolt, ohne dass der vorgesehene Nutzer es aktiv einsetzen kann.
Für Contract Manager und Procurement ist dieser Steuerungsmoment operativ relevant: Für eine planbare Steuerung der PUPM-Kosten braucht es eine enge Abstimmung zwischen HR-Offboarding, IT-Zugangsverwaltung und SAP-Lizenz-Zuweisung. Wer diese drei Prozesse nicht koordiniert, zahlt für Slots, die niemand aktiv nutzt. Und wer Neueinsteiger nicht schnell in produktive Pakete einbindet, verschenkt Adoption-Potenzial in den Monaten, in denen Schulung und Onboarding am intensivsten sind.
Praktische Forecasting-Grenzen
Klassische Lizenz-Forecasts funktionieren nach einer einfachen Logik: Nutzeranzahl mal Lizenzpreis. Bei PUPM ist diese Rechnung nur der Ausgangspunkt. Wer den tatsächlichen Investitionseinsatz steuern will, braucht drei zusätzliche Größen: Adoption-Rate, Rollout-Plan und Verbrauchsprofil pro Nutzungstyp.
Die Adoption-Rate bestimmt, wie viel des bezahlten Request-Pools monatlich tatsächlich ausgeschöpft wird. Wenn ein Paket mit 100 Nutzern nur zu 40 Prozent ausgenutzt wird, verfallen 60 Prozent des Paket-Potenzials jeden Monat. Für Controlling ist das eine Budgetabweichung, die ohne monatliche Beobachtung nicht sichtbar wird. Das ist ein Steuerungsmoment, der regelmäßige Analyse erfordert.
Der Rollout-Plan beeinflusst, wann Pakete aktiviert werden sollten. Ein häufiges Muster: Lizenzen werden zum Vertragsstart zentral beschafft, aber die tatsächliche Aktivierung erfolgt gestaffelt über mehrere Monate. Wer Pakete vor dem produktiven Einsatz aktiviert, zahlt für die Vorlaufzeit. Wer sie zu spät aktiviert, verliert Adoption-Geschwindigkeit. Dieser Zielkonflikt ist ein klassischer Steuerungsmoment, der eine Entscheidung des Executive erfordert: Wann startet der Rollout, und in welcher Reihenfolge?
Das Verbrauchsprofil variiert stark je nach Nutzungstyp. Nutzer, die Joule primär für einfache Konversationsfragen einsetzen, erzeugen einen anderen Verbrauch als Nutzer, die Joule in agentischen Workflows einsetzen. Agentische Deployments können je nach Komplexität des Plans deutlich mehr Tokens und AI Units verbrauchen als einfache Skill-Aufrufe. Wer den Sprung von Copilot zu Agenten plant, sollte das beim Forecasting explizit berücksichtigen (Quelle: SAP Licensing Experts, Negotiating SAP AI Contracts).
Für belastbares PUPM-Forecasting braucht es deshalb eine Use-Case-spezifische Betrachtung, die über die SAP-eigenen Sizing-Annahmen hinausgeht. SAP-Größenabschätzungen für Copilot-Nutzung unterschätzen agentische Workloads strukturell, weil Multi-Step-Pläne deutlich mehr konsumieren als die Standard-Projektionsmodelle unterstellen. Procurement und Controlling sollten diese Lücke gemeinsam mit dem Fachbereich vor dem nächsten Renewal-Zyklus adressieren.
Was Sie laufend beobachten sollten
PUPM ist kein Set-and-forget-Modell. Folgende Steuerungsmomente erfordern regelmäßige Beobachtung:
- Monatlicher Paket-Ausschöpfungsgrad: Liegt die Nutzung systematisch unter dem bezahlten Kontingent? Wenn ja, ist eine Paket-Anpassung oder ein verzögerter Rollout-Start sinnvoll.
- Aktive Nutzer pro Paket: Werden Pakete nur formal zugeordnet oder aktiv genutzt? Abweichungen zwischen Zuordnung und Nutzung sind ein Frühindikator für Adoptions-Probleme.
- Offboarding-Lag: Wie lange bleiben ausgeschiedene Mitarbeiter in aktiven PUPM-Paketen? Ein klarer Offboarding-Prozess mit direkter Paket-Deaktivierung ist ein operativer Steuerungsmoment.
- Cross-Paket-Analyse: Gibt es Nutzer, die mehrere Pakete zugeordnet haben, obwohl ihr Nutzungsprofil das nicht rechtfertigt? Redundante Paket-Zuordnungen sind ein häufiger Kostentreiber.
- Sizing-Annahmen vor dem nächsten Renewal: Entsprechen die ursprünglichen SAP-Sizing-Annahmen dem tatsächlichen Verbrauchsprofil? Abweichungen sollten die Grundlage für das nächste Renewal-Gespräch bilden.
Diese Beobachtungsebene ist mit nativen SAP-Tools allein nicht vollständig herstellbar. SAP for Me und das BTP-Cockpit liefern Aggregat-Werte, aber keine nutzer-granulare Analyse innerhalb eines PUPM-Pakets. Eine eigenständige Governance-Funktion, die diese Lücke schließt, ist für eine Investition gezielt einzusetzen kein optionaler Zusatz, sondern strukturell notwendig (Quelle: NextLytics, DSAG Technology Days 2026).
FAQ
Was ist der Unterschied zwischen PUPM-Verfall und dem Jahres-Verfall bei AI Units?
AI-Unit-Kontingente, die im klassischen Prepaid-Modell gekauft werden, verfallen am Ende des Vertragsjahres. PUPM-Request-Kontingente verfallen monatlich. Das ist ein kürzerer Zyklus mit häufigeren Verfall-Ereignissen. Wer PUPM-Pakete kauft und die Adoption langsam hochfährt, verliert Budget nicht einmal im Jahr, sondern jeden Monat.
Kann ich Requests aus einem Finance-Paket für Spend-Management-Use-Cases nutzen?
Nein. Pakete sind lösungsbereichsspezifisch. Finance-Pakete decken Finance-Capabilities ab, Spend-Management-Pakete decken Procurement-Capabilities ab. Paketübergreifendes Pooling ist nicht vorgesehen. Ein Nutzer, der beide Bereiche benötigt, braucht zwei separate Pakete.
Was passiert, wenn ein Nutzer sein PUPM-Kontingent überschreitet?
Überverbrauch über das Paket-Kontingent hinaus wird aus dem zentralen AI-Unit-Pool des Unternehmens gezogen. Fehlt dort ausreichendes Kontingent, entstehen Overage-Kosten. Das ist ein weiterer Grund, den Paket-Ausschöpfungsgrad und den zentralen AI-Unit-Pool gemeinsam zu beobachten. Ein Steuerungsmoment, der Contract Manager und Controlling gleichermaßen betrifft.
Wie viele Nutzer kann ich einem PUPM-Paket zuordnen?
Die Zuordnung ist technisch unbegrenzt. Die kommerzielle Grenze liegt im Request-Pool: Je mehr Nutzer ein Paket teilen, desto geringer ist der durchschnittlich pro Nutzer verfügbare Anteil. Die Paket-Dimensionierung sollte deshalb auf dem erwarteten Nutzungsvolumen basieren, nicht allein auf der Anzahl potenzieller Nutzer.
Weiterführende Quellen: SAP Pricing Page | SAP Help Portal: Metering and Pricing for SAP AI Core | SAP Learning: Analyzing the PUPM Pricing Model | SAP Licensing Experts: SAP AI Units Explained | NextLytics: DSAG Technology Days 2026
Zurück zum Pillar-2-Hub: SAP Business AI: Lizenzierung, Verbrauch und Governance steuern
Verwandte Artikel: SAP Business AI: Die drei Verbrauchstöpfe und die Pooling-Frage | Was passiert mit ungenutzten BTP Credits am Jahresende
Nächste Schritte
Wenn Sie Ihren aktuellen Vertrag auf Risiken und verfügbare kommerzielle Hebel prüfen lassen möchten: Der FinOptory Vertragscheck ist ein Festpreis-Engagement, das in vier Wochen eine strukturierte Grundlage liefert.
