Was passiert mit ungenutzten AI Units am Monatsende?

Q: Verfallen alle ungenutzten AI Units am Monatsende?

Nein. Die Verfallsregel gilt spezifisch für das monatliche Request-Kontingent in PUPM-Paketen. Das zentrale AI-Unit-Jahreskontingent läuft zum Jahresende ab.

Q: Kann ich nicht verbrauchte PUPM-Requests in den nächsten Monat übertragen?

Nein. Ein Rollover von PUPM-Requests über Monatsgrenzen ist im Standard nicht vorgesehen. Am Monatsende verfällt nicht genutztes Volumen unwiderruflich.

PUPM-Pakete bei SAP Business AI funktionieren anders als klassische Lizenzen. Ungenutzte Requests verfallen am Monatsende, nicht am Jahresende. Was Pooling möglich macht, wie laufende Beobachtung Verschwendung verhindert und welche Steuerungsmomente Director SAP Plattform jeden Monat ableiten sollten.

Wie der Monatsverfall mechanisch funktioniert

SAP Business AI kennt zwei verschiedene Verfallslogiken, die in der Praxis häufig durcheinandergebracht werden.

Das eine ist das klassische AI-Unit-Kontingent: Prepaid-Volumen, das ein Unternehmen pro Vertragsjahr kauft. Dieses Kontingent läuft zum Jahresende ab, sofern keine Rollover-Klausel im Order Form vereinbart wurde. (Dass SAP einen solchen Rollover standardmäßig nicht vorsieht, ist ein eigenes Thema und wird im Zusammenhang mit jährlicher Steuerungsplanung separat behandelt.)

Das andere ist die PUPM-Mechanik. PUPM steht für Per-User-Per-Month: Statt auf einem zentralen Pay-per-Use-Topf zu arbeiten, kauft ein Unternehmen für definierte Nutzergruppen ein monatliches Paket mit einem festen Request-Kontingent. Diese Pakete sind nach Line-of-Business geschnitten: Finance, Spend Management, Customer Experience, Human Capital Management.

Der entscheidende Mechanismus: Requests aus einem PUPM-Paket verfallen am letzten Tag des Monats. Es gibt keinen Übertrag in den Folgemonat. Was im Februar nicht verbraucht wurde, existiert im März nicht mehr.

Das klingt auf den ersten Blick nach einem Randdetail der SAP-Lizenzarchitektur. Es ist keines. Ein Unternehmen mit 200 lizenzierten Nutzern im PUPM-Paket Finance, das im März nur 60% der Requests ausschöpft, hat 40% des monatlichen Paketvolumens unwiderruflich verloren. Hochgerechnet auf ein Jahr und mehrere Pakete entsteht hier eine strukturelle Budgetabweichung, die im Jahresabschluss nirgendwo sichtbar wird, weil sie kein Kostenereignis erzeugt, sondern schlicht ungenutztes Investment darstellt.

Diese Asymmetrie ist der Ausgangspunkt für alle weiteren Steuerungsmomente rund um PUPM-Pakete.

Quelle: SAP Help Portal, Metering and Pricing for SAP AI Core; SAP Learning, Analyzing the SAP Per-User-Per-Month Pricing Model.

Was Pooling im PUPM-Paket erlaubt

Innerhalb eines PUPM-Pakets gibt es einen Ausgleichsmechanismus: Pooling auf Kundenebene.

Das bedeutet: Nicht jeder einzelne Nutzer hat ein starres Monatskontingent, das nur ihm zusteht. Wenn Nutzer A in einem Monat deutlich weniger Requests absetzt als sein Paketanteil, können diese ungenutzten Requests von anderen Nutzern desselben Pakets genutzt werden. Der Pool wird auf Ebene des gesamten Pakets gezogen, nicht pro Kopf.

Das ist eine wichtige Einschränkung der zuvor beschriebenen Verlustsituation. Wer ein gut dimensioniertes Paket mit einer ausreichend großen Nutzergruppe hat, kann durch natürliche Nutzungsschwankungen Verluste abfedern. In einer Abteilung mit 50 Finance-Nutzern kompensiert der Vielnutzer im Quartalsabschluss den Gelegenheitsnutzer in ruhigen Wochen.

Allerdings gibt es eine harte Grenze: Das Pooling funktioniert ausschließlich innerhalb eines Pakets. Cross-Package-Pooling ist nicht vorgesehen. Wer drei PUPM-Pakete hält (Finance, Spend Management, HCM) und in einem Paket Überverbrauch hat, kann das nicht durch Restvolumen aus einem anderen Paket decken. Überverbrauch zieht stattdessen zusätzliche AI Units aus dem zentralen Jahreskontingent, sofern dieses noch ausreichend gefüllt ist.

Umgekehrt verfällt monatliches Pooling-Volumen, das kein Nutzer des Pakets abgerufen hat, trotzdem zum Monatsende. Die Pooling-Logik verteilt verfügbare Requests effizient innerhalb des Pakets, hebt die grundlegende Verfallsregel aber nicht auf.

Dieser Mechanismus definiert die erste praktische Konsequenz für die Steuerung: Die Frage ist nicht nur, ob genug Paketvolumen vorhanden ist, sondern ob das Paket auf die tatsächlich aktive Nutzergruppe dimensioniert ist. Ein zu klein dimensioniertes Paket erzeugt Overage-Kosten. Ein zu großes Paket erzeugt monatliche Verluste.

Wo Investments typischerweise verschenkt werden

Drei Verbrauchsmuster treten in der Praxis immer wieder auf und führen zu strukturell ungenutztem PUPM-Volumen.

Zu viele Nutzer im Paket, zu wenig tatsächliche Nutzung. Der Fehler liegt nicht selten in der initialen Dimensionierung. Während Verhandlungen wird das PUPM-Paket häufig auf Basis von Headcount-Prognosen oder Lizenzrollen bestellt, nicht auf Basis von gemessenem Nutzungsverhalten. Wer IT-seitig alle potenziellen Joule-Nutzer lizenziert, hat ein anderes Aktivierungsprofil als tatsächliche Nutzungsdaten zeigen würden. Gerade in den ersten zwölf bis achtzehn Monaten nach Einführung bleibt die Aktivierungsquote häufig hinter den Erwartungen zurück. Das PUPM-Volumen läuft trotzdem monatlich ab.

Saisonale Nutzungsmuster ohne Adjustierung. Quartalsabschlüsse, Jahresabschlüsse, Audit-Phasen und Projektphasen erzeugen spürbare Nutzungsspitzen. In ruhigen Perioden ist die Nachfrage nach AI-gestützten Workflows entsprechend geringer. Eine statische PUPM-Dimensionierung, die auf Spitzenlast ausgelegt ist, verschenkt in den Zwischenphasen monatlich Volumen. Das Modell sieht keine Anpassung im Monatstakt vor, aber laufende Beobachtung ermöglicht zumindest eine Planung für die nächste Verlängerungsperiode.

Parallel laufende Pakete für überlappende Nutzergruppen. Wer einen Nutzer in mehreren PUPM-Paketen führt, zahlt für jedes Paket separat, ohne dass Cross-Package-Pooling diese Kosten abfedert. In der Praxis entsteht das, wenn Nutzerrollen über Fachbereichsgrenzen hinweg definiert werden oder wenn bei einer Vertragsänderung alte Paket-Zuordnungen nicht bereinigt werden. Die Folge: doppeltes Paketvolumen für einen Nutzer, von dem nur einer der Töpfe wirklich ausgeschöpft wird.

Wie laufende Beobachtung den Verfall verhindert

Laufende Beobachtung des PUPM-Verbrauchs ist keine einmalige Aufgabe. Sie ist ein monatlicher Steuerungsmoment, der aktiv ausgelöst werden muss. Die folgenden Schritte bilden einen praxistauglichen Rhythmus.

Schritt 1: Monatlicher Verbrauchsabgleich je Paket. SAP for Me zeigt aggregierten AI-Unit-Verbrauch. Für PUPM-Pakete ist entscheidend, wie viel des monatlichen Request-Kontingents je Paket tatsächlich abgerufen wurde. Dieser Wert sollte monatlich dokumentiert werden, nicht nur zum Jahresende. Erst eine Zeitreihe über mehrere Monate macht Muster sichtbar.

Schritt 2: Ausschöpfungsquote als Steuerungsgröße definieren. Eine Ausschöpfungsquote unter 60% über drei aufeinanderfolgende Monate ist ein Hinweis, dass das Paket entweder überdimensioniert ist oder die Nutzerakzeptanz ausbaufähig ist. Beide Ursachen haben unterschiedliche Konsequenzen für die nächste Vertragsperiode und sollten separat bewertet werden.

Schritt 3: Nutzerzuordnungen quartalsweise prüfen. Jeder Nutzer, der einem PUPM-Paket zugeordnet ist, sollte quartalsweise validiert werden: Ist diese Person tatsächlich aktiv? Hat sich die Rolle geändert? Haben Umstrukturierungen die Fachbereichszugehörigkeit verschoben? Dieser Steuerungsmoment ist eng mit dem Onboarding- und Offboarding-Prozess verbunden (dazu mehr in der nächsten Sektion).

Schritt 4: Overage-Ereignisse auswerten. Wenn in einzelnen Monaten das Paketvolumen überschritten wird und zusätzliche AI Units aus dem Jahreskontingent gezogen werden, ist das ein Signal, dass das Paket für diese Nutzergruppe zu knapp dimensioniert ist. Wiederholte Overage-Ereignisse über zwei bis drei Monate rechtfertigen eine Paketerweiterung vor der nächsten Verlängerungsperiode.

Schritt 5: Dimensionierungsempfehlung für die nächste Vertragsperiode vorbereiten. Steuerungsmomente im laufenden Betrieb sind nur dann wertvoll, wenn sie in die nächste Verhandlung fließen. Die Beobachtungsdaten der laufenden Periode bilden die Grundlage für eine belegte Verhandlungsposition: weder Überdimensionierung zu akzeptieren noch Underdimensionierung durch unnötige Overage-Kosten zu bezahlen.

Alle fünf Schritte greifen auf Daten zurück, die SAP-Standard-Reporting teilweise liefert und teilweise nicht. Granularität auf Nutzerebene innerhalb eines Pakets ist im Standard nicht verfügbar. Wer wissen will, welche Nutzer ein Paket wirklich treiben und welche es strukturell unterauslasten, braucht eine zusätzliche Beobachtungsschicht.

Was bei Mitarbeiterfluktuation passiert

Mitarbeiterfluktuation ist ein unterschätzter Steuerungsmoment in der PUPM-Verwaltung.

Wenn ein Mitarbeiter das Unternehmen verlässt, bleibt seine PUPM-Paket-Zuordnung im SAP Identity Service (IAS) bestehen, bis jemand sie aktiv entfernt. Das hat zwei Konsequenzen: Das Paketvolumen läuft für einen Nutzer weiter, der keine Requests mehr absetzt. Und wenn Nachfolger oder neue Mitarbeiter eingestellt werden, entstehen neue Zuordnungen, die mit veralteten Zuordnungen kollidieren können.

In Organisationen mit regelmäßigen Umstrukturierungen oder hoher Fluktuation in bestimmten Bereichen addiert sich dieser Effekt. Ein Paket mit 20 zugeordneten Nutzern, von denen fünf das Unternehmen verlassen haben und drei seit dem letzten Quartal in anderen Bereichen tätig sind, nutzt das Pooling-Volumen ineffizient.

Die Empfehlung aus der Praxis: Die Bereinigung von PUPM-Zuordnungen sollte an den HR-Offboarding-Prozess angebunden sein, nicht als manuelle IT-Aufgabe behandelt werden. Je früher eine ausgeschiedene Person aus dem Paket entfernt wird, desto früher kann der Slot für einen aktiven Nutzer genutzt werden, ohne den Paketumfang zu erweitern.

Gleiches gilt für interne Wechsel: Ein Nutzer, der vom Finance- in den Spend-Management-Bereich wechselt, sollte aus dem Finance-Paket entfernt und im Spend-Management-Paket zugeordnet werden. Andernfalls entstehen Doppelzuordnungen mit entsprechenden Doppelkosten.

FAQ

Verfallen alle ungenutzten AI Units am Monatsende?

Nein, die Verfallsregel gilt spezifisch für das monatliche Request-Kontingent in PUPM-Paketen. Das zentrale AI-Unit-Jahreskontingent (das Prepaid-Volumen aus dem Vertrag) läuft zum Jahresende ab, nicht monatlich. Beide Töpfe folgen eigenen Regeln und sollten getrennt beobachtet werden. Quelle: SAP Help Portal, Metering and Pricing for SAP AI Core.

Kann ich nicht verbrauchte PUPM-Requests in den nächsten Monat übertragen?

Nein. Ein Rollover von PUPM-Requests über Monatsgrenzen hinweg ist im Standard nicht vorgesehen. Innerhalb des laufenden Monats ist Pooling innerhalb eines Pakets möglich, also können aktive Nutzer Requests nutzen, die anderen Paketmitgliedern zugeordnet, aber noch nicht abgerufen wurden. Am Monatsende verfällt nicht genutztes Volumen unwiderruflich.

Welche Steuerungsmomente sind für Director SAP Plattform monatlich relevant?

Der erste Steuerungsmoment ist der Verbrauchsabgleich: Wie viel des PUPM-Paketvolumens wurde je Paket ausgeschöpft? Der zweite Steuerungsmoment ist die Nutzerzuordnung: Sind alle zugeordneten Nutzer noch aktiv und korrekt den richtigen Paketen zugeordnet? Der dritte Steuerungsmoment ist die Overage-Prüfung: Hat ein Paket das monatliche Kontingent überschritten und zusätzliche AI Units aus dem Jahreskontingent gezogen? Diese drei Prüfpunkte lassen sich in einer monatlichen Routine zusammenfassen und bilden die Grundlage für eine belegte Dimensionierungsentscheidung in der nächsten Vertragsperiode. Quelle: SAP Learning, Analyzing the SAP Per-User-Per-Month Pricing Model.

Weiterführend

Pillar 2 Hub: SAP Business AI: Lizenzierung, Verbrauch und Governance steuern
Cluster 3 PUPM: PUPM bei SAP Business AI verstehen
Pillar 1 SP-2 (BTP-Verfall): BTP Credits und Jahresende-Verfall

Autor: Bernhard Mändle, FinOptory. Quellen: SAP Help Portal (help.sap.com/docs/sap-ai-core), SAP Learning (learning.sap.com), SAP Pricing (sap.com/products/artificial-intelligence/pricing.html), saplicensingexperts.com.