Was sind Capacity Units?

Capacity Units sind das universelle Abrechnungsmass ueber alle BTP-Services. Jeder Service definiert eigene technische Verbrauchsmetriken, die ueber Credit-Rates in Capacity Units umgerechnet werden.

Was ist der Unterschied zwischen Depreciation Group 1 und 2?

Gruppe-1-Services werden bis zum Ende der aktuellen Vertragslaufzeit unterstuetzt. Gruppe-2-Services koennen nach einer Vorankuendigungsfrist von mindestens 6 Monaten entfernt werden.

Capacity Units und Depreciation Groups: Wie BTP-Verbrauch wirklich gemessen wird

SAP BTP wird in Credits bezahlt, aber nicht in Credits gemessen. Wer einen Alert-Schwellenwert für den Credit-Pool setzen oder einen belastbaren Forecast für die nächste Vertragsperiode erstellen will, braucht ein Verständnis der Schicht darunter: Capacity Units, service-spezifische Metriken und die Depreciation-Logik, die bestimmt, wie stabil der genutzte Servicekatalog überhaupt ist.

Dieser Artikel erklärt beide Konzepte so, dass sie für den Steuerungsmoment im Bereich Nutzung und Kosten unmittelbar nutzbar werden.

Capacity Units: Das Abrechnungsmaß, das hinter den Credits steht

Was eine Capacity Unit ist

Capacity Units (CU) sind das universelle Abrechnungsmaß über alle BTP-Services hinweg. Die Grundlogik: Jeder BTP-Service misst Verbrauch in einer technischen Einheit, die für diesen Service sinnvoll ist. Cloud-Foundry-Runtime misst in GB RAM pro Stunde. Die Integration Suite zählt Nachrichten. SAP HANA Cloud kombiniert Arbeitsspeicher, Speichervolumen und Compute. SAP AI Core rechnet in Token.

Diese unterschiedlichen Einheiten werden über service-spezifische Credit-Rates in Capacity Units umgerechnet, und die Summe aller Capacity Units aller aktiven Services ergibt den monatlichen Verbrauch aus dem Credit-Pool.

Die Faustregel: Ein Credit entspricht grob einem US-Dollar Verbrauch zum Listenpreis. Die genaue Konversion ist vertragsabhängig und im Order Form festgelegt (Quelle: SAP Discovery Center). Entscheidend für die Steuerung ist nicht die Euro-Größe allein, sondern die Umrechnungslogik je Service: Zwei Services mit identischem Euro-Äquivalent können völlig unterschiedliche Verbrauchsdynamiken haben.

Der monatliche Abrechnungsprozess

SAP misst den technischen Verbrauch je Service und Subaccount, multipliziert ihn mit der service-spezifischen Rate, summiert die Capacity Units aller Services auf und zieht das Ergebnis vom Credit-Pool ab. Das Resultat wird in monatlichen Balance Statements dokumentiert, die nach Service und Subaccount aufgeschlüsselt sind (Quelle: SAP Help Portal, Monitoring Usage and Consumption Costs).

Diese Balance Statements sind die primäre Datengrundlage für jeden Steuerungsmoment im Bereich Kosten: Sie zeigen nicht nur, wie viel verbraucht wurde, sondern welcher Service in welchem Subaccount wie viel beigetragen hat. Wer die Subaccount-Struktur sinnvoll nach Projekten oder Organisationseinheiten organisiert hat, kann diese Daten direkt für die interne Kostenverrechnung nutzen.

Service-spezifische Metriken im Vergleich

Die Bandbreite der Verbrauchsmetriken ist erheblich, und dieser Unterschied ist der Hauptgrund, warum BTP-Forecasting ohne fundiertes CU-Verständnis systematisch ungenau bleibt.

Cloud Foundry Runtime wird nach GB RAM pro Stunde gemessen. Als Orientierungswert gilt etwa 0,1 CU pro GB RAM und Stunde (Community Knowledge: Redress Compliance). Bei 24/7-Betrieb einer Anwendung mit 1 GB RAM ergibt das rund 72 Credits pro Monat. Das klingt überschaubar, aber produktive Anwendungen laufen selten mit einem einzigen GB. Eine typische Java-Anwendung mit 4 GB über drei Instanzen kommt auf über 800 Credits pro Monat.

Kyma Runtime, die Kubernetes-native Laufzeitumgebung, liegt bei etwa 0,24 CU pro Node-Stunde. Ein Drei-Node-Cluster im Dauerbetrieb ergibt rund 518 Credits pro Monat (Community Knowledge: Redress Compliance). Der Steuerungsmoment im Bereich Infrastruktur: Kyma-Cluster werden häufig für ein Projekt aufgebaut und laufen danach weiter, auch wenn das Projekt abgeschlossen ist.

SAP Integration Suite verwendet Nachrichtenzählungen als Metrik. Das Modell ist progressiv: Bei niedrigen Volumina von 200.000 Nachrichten pro Monat liegen die Kosten bei etwa 6 Credits pro 10.000 Nachrichten. Bei 5 Millionen Nachrichten monatlich sinken sie auf 2 bis 3 Credits je 10.000 Nachrichten (Community Knowledge: Redress Compliance). Was dabei leicht übersehen wird: Ein Batch-File, das in der Integration Suite gesplittet wird, kann hunderte Einzelnachrichten erzeugen. Retry-Logik bei Fehlern multipliziert das Volumen zusätzlich. Integrations-Volumen-Monitoring ist deshalb einer der kritischsten Steuerungsmomente in jedem BTP-Setup mit aktiver Integration Suite.

SAP HANA Cloud ist in vielen BTP-Setups der größte Einzelposten im Credit-Budget. Die Abrechnung kombiniert Arbeitsspeicher, Speichervolumen, Native Storage Extension und Compute. Eine Produktionsinstanz mit signifikantem Arbeitsspeicher kann mehrere tausend Credits pro Monat verbrauchen (Community Knowledge: Redress Compliance, SAP HANA Cloud CU Estimator). Der Unterschied zwischen einer HANA-Cloud-Instanz als Subscription und einer Nutzung über den Credit-Pool ist deshalb oft eine der wichtigsten Einzelentscheidungen in der BTP-Kostensteuerung.

SAP AI Core rechnet nach Token-Verbrauch, wobei Input-Token günstiger als Output-Token sind. AI-Workloads haben von allen BTP-Services die schwierigsten Verbrauchsmuster zu prognostizieren, weil Token-Verbrauch stark von Use Case, Modellauswahl, Prompt-Länge und Nutzungsintensität abhängt. Der Steuerungsmoment: AI-Piloten skalieren häufig schneller als geplant, wenn die Nutzerakzeptanz hoch ist.

Wo aktuelle Rates zu finden sind

Die verbindlichen, aktuellen Rates sind im SAP Discovery Center Service Catalog verfügbar (https://discovery-center.cloud.sap/), der alle Services mit Pricing je Commercial Model auflistet. Der Discovery Center Estimator (https://discovery-center.cloud.sap/estimator) ermöglicht interaktive Kostenabschätzungen. Für spezifische Services existieren eigene Estimatoren, darunter der SAP HANA Cloud CU Estimator und der SAP AI Core Cost Calculator.

Alle Richtwerte in diesem Artikel stammen aus Community-Quellen (Redress Compliance, Rizing) und können sich bei SAP-Preisanpassungen ändern. Für verbindliche Planungsgrundlagen immer den Discovery Center als primäre Quelle nutzen und die verwendeten Rates im Forecast mit Stand und Quelle dokumentieren.

Warum Forecasting ohne CU-Verständnis systematisch ungenau bleibt

Ein Forecast, der nur in Euro rechnet und nicht die Credit-Rate-Struktur der genutzten Services berücksichtigt, führt zu zwei strukturellen Fehlern.

Erstens bleibt die Verbrauchsdynamik unsichtbar: Ein Integrations-Use-Case mit wachsendem Nachrichtenvolumen erschöpft den Credit-Pool in einem anderen Zeitraum als ein stabiler HANA-Cloud-Produktionsbetrieb, auch wenn beide im Moment der Planung denselben Credit-Betrag haben. Der Steuerungsmoment im Bereich Kosten setzt voraus, dass nicht nur das Volumen, sondern auch die Wachstumsrate des Verbrauchs je Service bekannt ist.

Zweitens werden Service-Kombinationen unterschätzt: Wenn AI-Workloads sowohl BTP Capacity Units als auch separate AI Units verbrauchen (letztere werden im Pillar zu SAP Business AI Units behandelt), müssen beide Töpfe getrennt geplant und überwacht werden. Wer nur den einen Topf kennt, hat keinen vollständigen Steuerungsüberblick.

Depreciation Groups: Wie stabil ist der genutzte Servicekatalog?

Das Zwei-Gruppen-Modell in BTPEA

BTPEA, das strategische Nachfolgemodell von CPEA und für Neukunden das heute empfohlene BTP-Vertragsmodell, führt eine strukturierte Deprecation Policy ein, die CPEA nicht kennt. Services werden in zwei Gruppen eingeteilt, die unterschiedliche Stabilitätszusagen tragen.

Dieses Modell ist kein Risikosignal, das gegen BTPEA spricht, sondern eine transparentere Behandlung einer Realität, die bei CPEA implizit vorhanden war: Servicekataloge verändern sich. Der Unterschied ist, dass BTPEA diese Veränderungen mit einem klaren Rahmen versieht.

Gruppe 1 (Core Services): Schutz bis Vertragsende

Gruppe-1-Services sind BTP-Services, die SAP bis zum Ende der aktuellen Vertragslaufzeit unterstützt. Kunden können diese Services produktiv einsetzen, ohne während der Laufzeit eine erzwungene Migration befürchten zu müssen. Dieser Schutz entspricht der Zusage, die CPEA-Kunden grundsätzlich für ihren gesamten Servicekatalog haben.

Zu den Services, die als stabile Gruppe-1-Services gelten, zählen Integration Suite-Kerndienste, SAP HANA Cloud, Cloud Foundry Runtime und ABAP Environment. Diese Services sind das Rückgrat produktiver BTP-Landschaften. Der Steuerungsmoment im Bereich Infrastruktur: Geschäftskritische Workloads sollten grundsätzlich auf Gruppe-1-Services aufgebaut sein.

Gruppe 2 (Innovation Services): 6 Monate Vorlauf bei Abkündigung

Gruppe-2-Services können von SAP mit einer Vorankündigungsfrist von mindestens 6 Monaten aus dem BTPEA-Katalog entfernt oder in Gruppe 1 überführt werden. Die 6 Monate sind kein komfortabler Puffer, der entspanntes Abwarten erlaubt, sondern ein Zeitfenster, in dem Migrationsplanung, Ressourcenplanung und Tests abgeschlossen sein müssen.

Für produktive Deployments auf Gruppe-2-Services folgt daraus eine klare Governance-Anforderung: Alle Abhängigkeiten auf Gruppe-2-Services müssen dokumentiert sein. Das Deprecation-Monitoring muss so eingestellt werden, dass eine Abkündigung nicht erst nach Ablauf der Ankündigungsfrist in der eigenen Systemlandschaft ankommt (Quelle: ASUG, SAP Experts Detail New BTPEA).

Wie man prüft, welche Services in welche Gruppe fallen

Der SAP Discovery Center Service Catalog weist für jeden Service im BTPEA-Modell die Gruppen-Zugehörigkeit aus. Der praktisch sinnvolle Prozess: Bei der Einführung eines neuen BTPEA-Deployments wird die Gruppe des genutzten Services dokumentiert. Diese Dokumentation ist Teil des Steuerungsmoments im Bereich Infrastruktur und sollte bei jedem neuen Projekt-Setup als Pflichtschritt in die interne Governance aufgenommen werden.

Für bestehende Deployments empfiehlt sich eine einmalige Inventarisierung aller aktiven Services mit ihrer Gruppen-Zugehörigkeit, gefolgt von einer quartalsweisen Prüfung auf Veränderungen.

Aktuell betroffene Services: Datasphere und SAP Analytics Cloud

Zwei Services, die für viele BTP-Kunden relevant sind, standen unter Deprecation-Druck, der in BTP Cockpit-Instanzen als Warnung sichtbar wurde. SAP Datasphere und SAP Analytics Cloud zeigten Deprecation-Warnungen mit Bezugsdatum 31. Dezember 2025 (SAP KBA 3630656, SAP KBA 3632353). Der Migrationspfad für Datasphere führt in Richtung SAP Business Data Cloud.

Kunden, die Datasphere oder SAP Analytics Cloud produktiv nutzen, sollten ihren Migrationsstatus und den aktuellen Stand dieser Ankündigungen prüfen. SAP-Migrationspläne entwickeln sich weiter, weshalb der aktuelle Stand direkt beim SAP Help Portal und im BTP Release Navigator verifiziert werden sollte.

Für CPEA-Kunden gilt: Der Service-Scope ist für die Laufzeit gesichert, aber neue Weiterentwicklungen dieser Services finden in den Nachfolgelösungen statt. Eine vorausschauende Planung für das nächste Renewal sollte diese Entwicklung einbeziehen.

Deprecation-Monitoring als laufende Aufgabe

Deprecation-Monitoring ist keine einmalige Einrichtungsaufgabe, sondern ein struktureller Bestandteil der BTP-Governance. SAP veröffentlicht Service-Änderungen im BTP Release Navigator (https://help.sap.com/whats-new/cf0cb2cb149647329b5d02aa96303f56). Die quartalsweise Prüfung dieses Kanals ist die praktisch wirksamste Maßnahme, um frühzeitig auf Veränderungen im genutzten Servicekatalog reagieren zu können.

Der Steuerungsmoment im Bereich Infrastruktur umfasst damit drei Ebenen: die Gruppen-Zugehörigkeit bei Einführung prüfen, aktive Gruppe-2-Deployments dokumentieren, und den Release Navigator quartalsweise auswerten.

Drei Prüffragen für den Steuerungsmoment

Wer Capacity Units und Depreciation Groups als aktive Steuerungswerkzeuge nutzen will, kann sich an drei Fragen orientieren:

Zur Nutzung: Welche Services verbrauchen wie viele Credits, und mit welcher Rate wächst dieser Verbrauch? Ein monatliches Balance Statement beantwortet die Vergangenheit, ein CU-basierter Forecast beantwortet die Zukunft.

Zu den Kosten: Welche Services haben das größte Überraschungspotenzial? Integration Suite bei wachsenden Volumina und HANA Cloud bei neu aktivierten Instanzen sind die häufigsten Treiber ungeplanter Credit-Verbräuche.

Zur Infrastruktur: Welche produktiven Workloads laufen auf Gruppe-2-Services? Eine aktuelle Dokumentation dieser Abhängigkeiten ist die Grundlage dafür, dass ein Deprecation-Signal nicht erst dann wahrgenommen wird, wenn die Frist bereits begonnen hat.

Fazit

Capacity Units sind die Schicht, die zwischen dem Credit-Pool und dem tatsächlichen Serviceverbrauch liegt. Wer sie kennt, kann Forecasts erstellen, Alert-Schwellen sinnvoll setzen und die monatlichen Balance Statements als Steuerungsinstrument nutzen. Wer sie nicht kennt, beobachtet nur das Ergebnis, nicht die Ursache.

Depreciation Groups sind das Risikomanagement-Instrument für den Servicekatalog. Gruppe 1 gibt Planungssicherheit. Gruppe 2 erfordert aktives Monitoring. Das Zwei-Gruppen-Modell macht eine Realität transparent, die bei jedem BTP-Vertrag besteht: Services entwickeln sich weiter, und einige dieser Entwicklungen betreffen die eigene Systemlandschaft.

Beide Konzepte zusammen bilden den Steuerungsmoment im Bereich Infrastruktur und Nutzung: Es geht nicht darum, Verbrauch zu minimieren, sondern ihn zu verstehen, zuzuordnen und planbar zu machen.

Weiterführend:

BTP FinOps: Credits steuern, Overages vermeiden, Kosten verursachergerecht verrechnen (Pillar-Hub Pillar 3)
CPEA und BTPEA: Zwei Vertragsmodelle, eine Plattform (Cluster 1)
BTP Credit-Verfall und Overage-Mechanik (Cluster 3)

Bernhard Mändle ist Managing Consultant bei FinOptory und begleitet Unternehmen bei der laufenden Steuerung ihrer SAP-Verträge nach der Unterschrift. Auf LinkedIn vernetzen

Möchten Sie wissen, wie Ihre BTP-Vertragsstruktur aufgestellt ist? Vereinbaren Sie ein Erstgespräch.