BTP-Verbrauchsdaten als Verhandlungs-Input fuer SAP-Renewal

BTP-Credits stehen in jedem RISE Enterprise Agreement. Sie sind Bestandteil der vertraglich vereinbarten Guthabenstruktur, sie werden monatlich gemessen, und sie dokumentieren die tatsächliche Cloud-Plattform-Nutzung auf einer Granularitätsebene unterhalb der FUE-Vermessung. Trotzdem werden sie im Renewal selten als strukturierter Verhandlungs-Input aufbereitet.

Das ist ein verpasster Steuerungsmoment: BTP-Verbrauchsdaten sind der direkteste verfügbare Beleg für die tatsächliche Nutzung des RISE-Pakets auf Plattformebene. Wer sie für das Renewal nicht aufbereitet hat, verhandelt das Credit-Volumen der nächsten Laufzeit ohne sachliche Grundlage.

Dieser Artikel beschreibt, was BTP-Credit-Daten zeigen, wie die Zeitreihe für Renewal-Zwecke aufzubauen ist und was aus den Daten für das Credit-Volumen der neuen Laufzeit folgt.

Was BTP-Credit-Daten zeigen

BTP-Credits im RISE Enterprise Agreement werden nach Depreciation Groups abgerechnet. Group 1 umfasst Basis-Infrastrukturservices, Group 2 Advanced- und Integration-Services mit einem höheren Credit-Verbrauch je genutzter Kapazitätseinheit. Diese Unterscheidung ist für die Renewal-Datenbasis relevant, weil sie zeigt, welcher Teil des BTP-Verbrauchs auf welche Service-Kategorie entfällt, und damit, wie das Credit-Volumen bei einer veränderten Nutzungsstrategie zu kalibrieren ist.

Ein eigenständiger Datenstrang ist der Verbrauch von AI-Units, die im RISE-Kontext als PUPM (Per Use Per Month) abgerechnet werden. Wer SAP Business AI Services aktiviert hat, hat einen zusätzlichen Credit-Verbrauch, der in der Zeitreihe sichtbar sein muss, um bei einem geplanten Ausbau der AI-Nutzung nicht mit einer Fehlkalibrierung in die neue Laufzeit zu gehen.

Was BTP-Daten nicht direkt zeigen: Sie unterscheiden nicht automatisch zwischen produktiver Nutzung, Test- und Entwicklungsumgebungen und explorativen Projekten. Diese Einordnung muss der Kunde selbst vornehmen, weil sie von der jeweiligen Subaccount-Struktur abhängt. Ein Verbrauchswert ohne Zuordnung zu produktiven und nicht-produktiven Systemen ist für Renewal-Zwecke eingeschränkt verwendbar.

Ein weiterer Steuerungsmoment in der BTP-Analyse: ungenutzte Credits. Subaccounts oder Service-Instanzen, für die regelmäßig Credits reserviert werden, aber kein Verbrauch stattfindet, sind ein belastbares Belegstück für Überallokation. Diese Feststellung ist keine Kritik am Betrieb, sondern sachliche Grundlage für ein Gespräch über die Volumenplanung der nächsten Laufzeit.

Wie BTP-Daten in die Renewal-Datenbasis fließen

Zeitreihe: 12 bis 18 Monate als Minimum

Ein Stichtagswert zeigt, was am Auslesetag verbraucht wurde. Für Renewal-Zwecke brauchen Sie eine Zeitreihe, weil der Verbrauch saisonal schwanken kann: Projektphasen, Release-Zyklen und Geschäftsprozesse erzeugen Muster im BTP-Verbrauch, die ein Einzelwert nicht abbildet. Eine Zeitreihe von zwölf bis achtzehn Monaten erlaubt, Hochlast- und Niedriglastphasen zu identifizieren und das Credit-Volumen für die neue Laufzeit auf einem Niveau zu kalibrieren, das den realen Betriebsbedarf abbildet, ohne systematisch Puffer aufzubauen, der am Vertragsende verfällt.

Die monatlichen Balance Statements sind die Quelle für diese Zeitreihe. Wer sie nicht laufend archiviert hat, stellt bei der Renewal-Vorbereitung fest, dass historische Daten nicht nachträglich vollständig reproduzierbar sind. Der Steuerungsmoment Datenbasis entsteht deshalb nicht im Renewal-Jahr, sondern in der laufenden Vertragssteuerung.

Projektzuordnung: Produktiv versus Test und Entwicklung

Für eine belastbare Renewal-Datenbasis muss der BTP-Verbrauch nach Nutzungstyp aufgeschlüsselt sein. Diese Aufschlüsselung funktioniert nur dann, wenn die Subaccount-Struktur so angelegt wurde, dass produktive Systeme, Entwicklungs- und Testumgebungen und explorative Projekte in getrennten Subaccounts laufen. Ist das nicht der Fall, ist die Disaggregation nachträglich aufwendig und unter Umständen nur annäherungsweise möglich.

Für die Renewal-Verhandlung ist diese Zuordnung aus zwei Gründen relevant. Erstens: Wenn ein wesentlicher Teil des BTP-Verbrauchs auf nicht-produktive Umgebungen entfällt, lässt sich das Credit-Volumen für produktive Nutzung genauer bestimmen. Zweitens: Eine geplante Erweiterung der produktiven BTP-Nutzung, etwa durch weitere Integration-Szenarien oder den Ausbau von AI-Use-Cases, erfordert eine Baseline aus produktivem Verbrauch, nicht aus dem Gesamtverbrauch inklusive Testumgebungen.

Kostenstellenzuordnung: Grundlage für internes Reporting

BTP-Verbrauch, der Subaccounts und Projekten zugeordnet ist, lässt sich in interne Kostenstellen überführen. Diese Zuordnung ist für das Controlling relevant, aber sie ist auch eine Voraussetzung für eine valide Budgetplanung der nächsten Laufzeit. Wer dem Controlling belastbare Daten zu BTP-Verbrauch je Fachbereich oder Projekt liefern kann, gibt dem Renewal-Prozess eine interne Legitimationsbasis.

Was aus BTP-Daten für den nächsten Vertrag folgt

Credit-Volumen für die neue Laufzeit kalibrieren

Die wichtigste Schlussfolgerung aus einer vollständigen BTP-Zeitreihe ist die Empfehlung für das Credit-Volumen der nächsten Laufzeit. Diese Kalibrierung ist ein eigenständiger Steuerungsmoment im Bereich Kosten: Ein zu hoch kalibriertes Volumen erzeugt verfallende Credits am Vertragsende, ein zu niedrig kalibriertes führt zu Overages mit 15-Prozent-Aufschlag und ohne SLA-Schutz in der Übernutzungsphase.

Die Ausgangsgröße für die Kalibrierung ist der durchschnittliche monatliche Verbrauch aus der Zeitreihe, bereinigt um nicht-produktive Anteile und ergänzt um eine Wachstumsannahme für geplante Erweiterungen. Wenn die Planung eine Erweiterung der SAP Business AI-Nutzung vorsieht, ist der PUPM-Verbrauch der letzten Laufzeit die einzig belastbare Ausgangsbasis für die AI-Unit-Bedarfsplanung der nächsten Periode.

Overage-Risiko für die neue Periode quantifizieren

Neben der Kalibrierung des Regelvolumens ist die Quantifizierung des Overage-Risikos ein eigenständiger Steuerungsschritt. Welche Service-Familien haben in der Vergangenheit Spitzenlasten erzeugt? Bei welchen Nutzungsszenarien könnte das Credit-Volumen der neuen Laufzeit überschritten werden? Wer diese Szenarien aus der Zeitreihe ableiten kann, kann im Renewal-Gespräch sachlich über Puffer-Optionen sprechen, anstatt im Betrieb reaktiv auf Overages zu reagieren.

AI-Unit-Bedarf planen

Wenn SAP Business AI Services ausgebaut werden sollen, ist die BTP-Zeitreihe die Grundlage für die AI-Unit-Planung der neuen Laufzeit. PUPM-Verbrauch aus der laufenden Periode zeigt, welche Services wie intensiv genutzt werden, und erlaubt eine Hochrechnung auf geplante Szenarien. Eine detaillierte Beschreibung der SAP Business AI Lizenzstruktur und der PUPM-Mechanik bietet der [Pillar-2-Hub: SAP Business AI Lizenzierung].

Governance der BTP-Daten vor Renewal

Die Aufbereitung von BTP-Verbrauchsdaten für Renewal-Zwecke setzt drei organisatorische Voraussetzungen voraus.

Monatliches Balance Statement als Pflichtunterlage. Das Balance Statement ist die einzige vollständige Quelle für den BTP-Credit-Verbrauch je Periode. Es muss über die gesamte Laufzeit archiviert werden. Wer mit der systematischen Archivierung erst bei der Renewal-Vorbereitung beginnt, hat eine lückenhafte Zeitreihe.

Subaccount-Struktur als Reporting-Grundlage. Eine Subaccount-Struktur, die produktive, Test- und Entwicklungsumgebungen trennt, ist nicht nur eine Best Practice im BTP-Betrieb. Sie ist die Voraussetzung dafür, dass BTP-Verbrauchsdaten als Renewal-Input belastbar sind. Wenn die Struktur nicht so angelegt ist, ist das ein Hinweis für die nächste Laufzeit, nicht eine Einschränkung für das aktuelle Renewal.

Zuständigkeit für BTP-Betriebsdaten klären. BTP-Betriebsdaten liegen typischerweise beim Plattform- oder Architektur-Team, nicht beim Contract Manager oder Procurement. Renewal-Vorbereitung erfordert, dass diese Daten koordiniert geliefert werden. Die Frage, wer im Unternehmen die BTP-Verbrauchsauswertung belastbar erstellen kann, sollte spätestens achtzehn Monate vor Renewal beantwortet sein.

FAQ

Welche BTP-Daten brauche ich konkret für die Renewal-Vorbereitung?

Für eine belastbare Renewal-Datenbasis benötigen Sie: monatliche Balance Statements über zwölf bis achtzehn Monate, den Verbrauch je Depreciation Group (Group 1 und Group 2), den PUPM-Verbrauch für AI-Units, falls Business AI Services aktiv sind, und eine Aufschlüsselung nach produktiven und nicht-produktiven Subaccounts. Diese Daten liefern die Grundlage für die Credit-Volumen-Kalibrierung und die Overage-Risikoabschätzung der neuen Laufzeit.

Was passiert, wenn ich keine vollständige BTP-Zeitreihe habe?

Ohne vollständige Zeitreihe ist die Credit-Volumen-Kalibrierung nur auf Basis aktueller Stichtagswerte möglich. Das ist eine lückenhafte Grundlage, weil saisonale Schwankungen und Projektphasen nicht sichtbar sind. In diesem Fall empfiehlt sich eine konservative Hochrechnung auf Basis des verfügbaren Zeitraums, ergänzt um einen sachlich begründeten Puffer. Der strukturierte Ansatz für die nächste Laufzeit beginnt mit der laufenden Archivierung der Balance Statements ab heute.

Wie unterscheiden sich Depreciation Group 1 und Group 2 bei BTP-Credits?

Group 1 umfasst Basis-Infrastrukturservices mit einem niedrigeren Credit-Verbrauch je Kapazitätseinheit. Group 2 umfasst Advanced- und Integration-Services, die pro genutzter Einheit mehr Credits verbrauchen. Die Zusammensetzung des eigenen BTP-Verbrauchs nach diesen Gruppen zeigt, welcher Anteil auf Infrastruktur entfällt und welcher auf höherwertige Services, und beeinflusst damit die Kalibrierung des Gesamtvolumens für die neue Laufzeit.

Wie hängen BTP-Credits und das allgemeine Vertragsguthaben zusammen?

BTP-Credits sind Teil des im RISE Enterprise Agreement vereinbarten Gesamtguthabens. Sie werden aus dem Gesamtguthaben gezogen, sodass ein höherer BTP-Verbrauch das für andere Komponenten verfügbare Guthaben reduziert. Diese Wechselwirkung macht die BTP-Zeitreihe zu einem integralen Bestandteil der gesamten Verbrauchsdaten-Auswertung, nicht zu einem separaten Datenstrang.

Nächste Schritte

BTP-Zeitreihe aufbauen oder konsolidieren. Prüfen Sie, ob Ihre monatlichen Balance Statements vollständig archiviert sind und ob Ihre Subaccount-Struktur eine Zuordnung zu produktiven und nicht-produktiven Umgebungen erlaubt. Das ist der erste Steuerungsmoment in der BTP-Datenbasis-Vorbereitung.

Gesamte Renewal-Datenbasis bewerten. BTP-Verbrauchsdaten sind eine von vier Datenkategorien, die eine vollständige Renewal-Datenbasis ausmachen. Die anderen drei Kategorien, Vertragsdaten, Marktdaten und Qualitätsdaten, beschreibt [Cluster 2: Die Datenbasis für SAP-Renewal-Verhandlungen aufbauen].

Vertragscheck als strukturierter Einstieg. Der Vertragscheck von FinOptory bewertet Ihre SAP-Vertragsposition in vier Wochen: Verbrauchsdaten-Assessment, Datenbasis-Auswertung und Renewal-Readiness-Einschätzung. Festpreis 7.900 EUR. Ein Erstgespräch ist ohne Vorlaufzeit möglich.

Erstellt 2026-05-21. Version v1, Status: draft, freigegeben für Bernhard-Review. Quellen-Grundlage: SAP_RISE/02, SAP_RISE/04, SAP_RISE/07 (partner-sichtbar), FinOptory-Strategy-Brief-v2.md, Pillar-5-Outline-Renewal-Negotiation.md. SAP_RISE/08_rise_negotiation_playbook.md wurde nicht verwendet.