BTP-Monitoring-Strategie: Welche Datenpunkte Sie laufend brauchen
BTP-Kosten werden im Cockpit sichtbar, aber nicht automatisch steuerbar. Wer monatliche Balance Statements liest, sieht was verbraucht wurde. Wer steuern will, braucht eine Ebene darunter: strukturierte Datenpunkte, klare Alert-Schwellen und eine Verknüpfung mit dem internen Reporting. Dieser Artikel beschreibt, welche Monitoring-Bestandteile ein funktionierendes BTP-Setup benötigt und wo die Grenzen der SAP-eigenen Werkzeuge liegen.
Was das BTP Cockpit zeigt und was nicht
Die Leistung des BTP Cockpit
Das BTP Cockpit ist die zentrale Benutzeroberfläche für die Verwaltung von Global Accounts, Subaccounts, Entitlements und Services. Es bietet einen strukturierten Überblick über aktive Service-Plans, deren Konfiguration und den aktuellen Status laufender Instanzen. Für viele Steuerungsaufgaben ist das Cockpit die einzige direkte Schnittstelle zum laufenden BTP-Betrieb.
Für das Monitoring stellt das Cockpit zwei Hauptquellen bereit: die laufende Ansicht aktiver Services und Entitlements je Subaccount sowie die monatlichen Balance Statements, die nach Service und Subaccount aufgeschlüsselten Verbrauch dokumentieren. Wer wissen will, welcher Service in welchem Subaccount im vergangenen Monat wie viele Credits verbraucht hat, findet diese Daten in den Balance Statements.
Die strukturellen Grenzen
Das BTP Cockpit ist kein vollständiges Steuerungswerkzeug. Es berichtet Verbrauch pro Subaccount und Service in der Rückschau, bietet aber keine konsolidierte Sicht über mehrere Vertragsstrukturen gleichzeitig. Wer parallel ein CPEA-Commitment und Subscription-Services verwaltet, sieht diese in getrennten Ansichten ohne automatische Zusammenführung.
Historische Verbrauchstrends über mehrere Vertragsjahre lassen sich im Cockpit nicht in vergleichbarer Form auswerten. Ebenso gibt es keine automatische Verbindung zu internen Kostenstellen oder Budgetstrukturen. Der Steuerungsmoment im Bereich Kosten erfordert deshalb eine Ergänzung des Cockpit-eigenen Monitorings durch externe Prozesse und Werkzeuge.
Balance Statements als primäre Steuerungsgrundlage
Warum monatliche Auswertung nicht optional ist
Balance Statements sind rückwirkende Berichte, keine Echtzeit-Daten. Das bedeutet: Sie zeigen, was in einem abgeschlossenen Monat verbraucht wurde. Sie sind damit die zuverlässigste und vollständigste Datenquelle für die Verbrauchsanalyse, aber nicht für die proaktive Steuerung.
Die praktische Konsequenz lautet: Balance Statements sollten unmittelbar nach Verfügbarkeit ausgewertet werden, nicht erst im Quartalsreview. Wer erst im Quartalsrhythmus auf Balance-Statement-Daten schaut, hat bei einem unerwarteten Verbrauchsanstieg im Zweifel zwei bis drei Monate verloren, bevor ein Steuerungsmoment erkannt und adressiert werden kann.
Was eine strukturierte Auswertung zeigt
Eine monatliche Balance-Statement-Auswertung liefert vier Steuerungsgrößen, die für die laufende BTP-Governance relevant sind.
Erstens zeigt sie den kumulierten Verbrauch im Verhältnis zum Jahresbudget. Liegt der Verbrauch nach vier Monaten bei 40 Prozent des jährlichen Credit-Pools, entspricht das dem geplanten Verbrauchspfad. Liegt er bei 55 Prozent, ist ein Steuerungseingriff notwendig.
Zweitens zeigt die Aufschlüsselung nach Services, wo der Verbrauch konzentriert ist. Drei bis vier Services verursachen in der Regel 80 Prozent des monatlichen Verbrauchs. Wer diese kennt, kennt die relevanten Steuerungsmomente im Bereich Nutzung.
Drittens macht die Subaccount-Aufschlüsselung sichtbar, welche organisatorischen Einheiten oder Projekte wie viel verbrauchen. Das ist die Datengrundlage für interne Verrechnung und für die Frage, ob die Subaccount-Struktur noch die tatsächliche Nutzung widerspiegelt.
Viertens signalisiert eine monatliche Betrachtung Anomalien: ein Service, der im Vormonat kaum Verbrauch hatte und jetzt erheblich zieht, deutet auf eine neue Nutzungsphase hin, die nicht geplant war und geprüft werden sollte.
Subaccount-Struktur als Voraussetzung für Transparenz
Warum Strukturentscheidungen Monitoring-Entscheidungen sind
Die Qualität der Balance-Statement-Daten hängt direkt von der Subaccount-Struktur des Global Accounts ab. Wer alle Projekte, Entwicklungsumgebungen und Produktivsysteme in einen gemeinsamen Subaccount legt, erhält aggregierte Zahlen, aber keine Zuordnung.
Eine Subaccount-Struktur, die nach organisatorischen Einheiten, Projekten oder Umgebungstypen gliedert (Entwicklung, Test, Produktion), liefert Monitoring-Daten, die unmittelbar steuerbar sind. Der Steuerungsmoment im Bereich Berechtigungen und der Steuerungsmoment im Bereich Kosten hängen direkt von dieser Strukturentscheidung ab.
Praktische Gliederungsprinzipien
In der Praxis haben sich zwei Gliederungsansätze bewährt, die auch kombiniert werden können.
Die umgebungsbasierte Gliederung trennt Entwicklungs-, Test- und Produktivsubaccounts. Das ermöglicht gezielte Non-Production-Shutdown-Strategien, weil Kosten der Non-Prod-Umgebungen separat sichtbar sind und gezielt beeinflusst werden können.
Die projektbasierte Gliederung weist jedem relevanten BTP-Projekt einen eigenen Subaccount zu. Das schafft die Grundlage für verursachergerechte interne Verrechnung und macht den Beitrag jedes Projekts zum Credit-Verbrauch transparent.
Für viele Unternehmen ist eine Kombination beider Ansätze sinnvoll: projektbasierte Gliederung für die erste Ebene, umgebungsbasierte Gliederung innerhalb relevanter Projekte. Diese Entscheidung sollte am Anfang eines BTP-Projekts getroffen werden, da eine nachträgliche Restrukturierung zwar technisch möglich, aber operativ aufwendig ist.
Alert-Schwellen konfigurieren
Zwei Schwellen, zwei Steuerungsmomente
Ein funktionierendes Alert-System für BTP arbeitet mit zwei Schwellenwerten, die unterschiedliche Steuerungsmomente auslösen.
Die erste Benachrichtigung bei 70 bis 80 Prozent Credit-Verbrauch ist der Einleitungspunkt für proaktive Maßnahmen: Verbrauchsentwicklung analysieren, Forecast aktualisieren, prüfen ob ungeplante Workloads das Budget belasten, und bei Bedarf ein Gespräch mit SAP über einen Top-Up zu Vertragsbedingungen vorbereiten.
Die zweite Benachrichtigung bei 90 Prozent Verbrauch ist der späteste Moment, um ein Top-Up zu initiieren. Wer bei 90 Prozent handelt, vermeidet den Listenpreis-Aufschlag bei Overage noch. Wer das Kontingent ohne vorherige Maßnahme überschreitet, zahlt alle Credits über das Kontingent hinaus zum vollen Listenpreis, ohne die verhandelten Volumenrabatte.
Konfiguration im BTP Cockpit
Das BTP Cockpit erlaubt die Einrichtung von Benachrichtigungen für die Subaccount-Nutzung. Diese Alerts sollten als Standard-Konfiguration in jedem produktiven BTP-Setup eingerichtet sein. Für technische Details der Alert-Konfiguration verweist der SAP Help Portal auf die aktuelle Anleitung unter Monitoring Usage and Consumption Costs (https://help.sap.com/docs/btp).
Ein Alert ohne definierten Prozess ist wirkungslos. Neben der technischen Einrichtung braucht jede Alert-Schwelle eine klare Antwort auf die Frage: Wer bekommt die Benachrichtigung, und was ist die erwartete Reaktion?
Discovery Center Estimator als Forecast-Instrument
Mehr als ein Einmalwerkzeug bei Vertragsabschluss
Der SAP Discovery Center Estimator (https://discovery-center.cloud.sap/estimator) wird häufig nur bei der initialen Vertragsdimensionierung genutzt. Sein Wert als laufendes Monitoring-Werkzeug ist in der Praxis weniger bekannt.
Wenn sich die Service-Nutzung im laufenden Vertrag verändert, durch neue Projekte, wachsendes Integrationsvolumen oder den Einstieg in AI-Workloads, erlaubt der Estimator eine aktualisierte Abschätzung des Credit-Bedarfs für die restliche Vertragsperiode. Diese aktualisierte Schätzung ist belastbarer als ein Forecast, der nur auf dem initialen Sizing basiert und die tatsächliche Verbrauchsentwicklung nicht berücksichtigt.
Quartalsweise Forecast-Aktualisierung als Steuerungsroutine
Der Steuerungsmoment eines regelmäßigen Forecasts liegt nicht in der Genauigkeit einer einzelnen Abschätzung, sondern in der Regelmäßigkeit der Aktualisierung. Ein Forecast, der quartalsweise auf Basis tatsächlicher Balance-Statement-Daten aktualisiert wird, ist strukturell besser geeignet als eine einmalige Jahresplanung, die danach nicht mehr angefasst wird.
Die Kombination aus monatlicher Balance-Statement-Auswertung und quartalsweiser Forecast-Aktualisierung mit dem Discovery Center Estimator schafft den Informationsstand, der für fundierte Steuerungsentscheidungen notwendig ist, insbesondere dann, wenn ein Top-Up erwogen oder ein Overage-Risiko bewertet werden muss.
Grenzen des SAP-eigenen Monitorings
Vier strukturelle Lücken
Wer BTP-Kosten vollständig mit SAP-nativen Werkzeugen steuern möchte, stößt an vier strukturelle Grenzen, die relevant werden, sobald die Vertragsstruktur komplex ist oder eine verursachergerechte interne Verrechnung erforderlich ist.
Keine konsolidierte Multi-Vertrags-Sicht: Wenn ein Unternehmen gleichzeitig ein BTPEA-Commitment, Subscription-Services und einzelne PAYG-Services betreibt, zeigt das BTP Cockpit diese Verbrauchsströme getrennt, nicht in einer konsolidierten Budget-Übersicht. Für die Gesamtsteuerung muss diese Konsolidierung manuell erfolgen.
Keine historischen Mehrypothesen-Trends: Das Cockpit zeigt Verbrauch innerhalb der aktuellen Vertragsperiode, aber keine Vergleichsdaten zur Vorperiode in vergleichbarer Form. Wer Verbrauchsentwicklungen über mehrere Vertragsjahre analysieren will, um ein Renewal-Commitment belastbar zu begründen, benötigt eine eigene Datenhistorie.
Keine automatische Verbindung zu internen Systemen: Die Brücke zwischen BTP-Verbrauchsdaten und internen Kostenstellen, Budgetstrukturen oder SAP-Rechnungswesen-Systemen baut das Cockpit nicht. Diese Verbindung erfordert einen eigenen Prozess, der Balance-Statement-Daten in das interne Reporting überführt.
Keine rollenspezifische Sicht: Das Cockpit ist eine technische Verwaltungsoberfläche. Es bietet keine aufbereiteten Sichten für Controlling, Procurement oder Executive-Entscheidungsträger, die unterschiedliche Steuerungsfragen haben und unterschiedliche Datenformate benötigen.
Was diese Grenzen für die Governance-Entscheidung bedeuten
Diese Grenzen sind nicht als Kritik an SAP-Werkzeugen zu verstehen, sondern als strukturelle Eigenschaft eines Plattform-Betriebsmodells: BTP ist eine technische Plattform, das Cockpit ist deren Verwaltungsoberfläche. Finanzielle Steuerung, verursachergerechte Verrechnung und Multi-Perioden-Analysen liegen außerhalb dieses Zwecks.
Für Unternehmen mit komplexen BTP-Vertragsstrukturen ergibt sich daraus der Bedarf an einer eigenständigen BTP-Governance-Funktion, die die Cockpit-Daten aufnimmt und in steuerungsrelevante Formate überführt. Dieser Steuerungsmoment im Bereich Kosten ist der Ausgangspunkt, an dem laufende Vertragssteuerung beginnt.
Verknüpfung mit internen Systemen
Zwei Schritte zur verursachergerechten Verrechnung
Eine vollständige BTP-Kostensteuerung verbindet die Subaccount-Verbrauchsdaten aus den monatlichen Balance Statements mit den internen Kostenstellenstrukturen des Unternehmens. Diese Verbindung herzustellen ist kein technisches Problem, sondern ein Governance-Problem: Es braucht eine Entscheidung darüber, wie BTP-Kosten intern zugeordnet werden.
Der erste Schritt ist die Subaccount-Gestaltung: Nur wenn Subaccounts organisatorische Einheiten oder Projekte widerspiegeln, liefern Balance Statements Daten, die eine Zuordnung erlauben.
Der zweite Schritt ist der Prozess: Monatlich werden die Balance-Statement-Daten in die interne Kostenrechnung überführt. Wie dieser Prozess aussieht, ob als manueller Export und Aufbereitung oder als stärker automatisierte Integration, hängt von der Komplexität der BTP-Landschaft und den Anforderungen des Controllings ab.
Monitoring als Grundlage, nicht als Ziel
Monitoring ist kein Selbstzweck. Der Wert eines gut eingerichteten BTP-Monitorings liegt darin, dass er jeden Steuerungsmoment rechtzeitig sichtbar macht: den Verbrauchsanstieg, der einen Top-Up erfordert, den ungenutzten Service-Plan, der Shelfware-Kosten verursacht, und die Verbrauchskonzentration, die eine interne Verrechnung erst sinnvoll macht.
Wer diese Datenpunkte laufend im Blick hat, entscheidet mit vollständiger Information. Wer sie erst auf Anfrage zusammenstellt, entscheidet mit dem Informationsstand von gestern.
Fazit: Was ein funktionierendes Monitoring-Setup braucht
Vier Bestandteile zusammen ergeben ein BTP-Monitoring, das tatsächlich steuerbar ist.
Erstens eine Subaccount-Struktur, die organisatorische Einheiten oder Projekte widerspiegelt, damit Balance-Statement-Daten verursachergerecht lesbar sind.
Zweitens eine monatliche Auswertungsroutine für Balance Statements, die Verbrauchsentwicklung, Service-Konzentration und Subaccount-Zuordnung systematisch auswertet.
Drittens konfigurierte Alert-Schwellen bei 70 bis 80 Prozent und 90 Prozent Credit-Verbrauch, mit klarer Zuordnung, wer auf welchen Alert wie reagiert.
Viertens eine quartalsweise Forecast-Aktualisierung mit dem Discovery Center Estimator, die auf tatsächlichen Verbrauchsdaten basiert und nicht auf der initialen Vertragsdimensionierung stehenbleibt.
Diese vier Bestandteile sind keine komplexe Infrastruktur. Sie sind ein strukturierter Prozess, der auf den Daten aufbaut, die SAP ohnehin bereitstellt, und der die SAP-eigenen Grenzen mit bewussten Governance-Entscheidungen überbrückt.
Weiterführende Artikel:
- BTP Credit-Verfall und Overage-Mechanik erklärt die finanziellen Konsequenzen, die ein unzureichendes Monitoring erst sichtbar macht, wenn es zu spät ist.
- FinOps Inform-Optimize-Operate für SAP BTP zeigt, wie das Monitoring in einen vollständigen FinOps-Prozess eingebettet wird.
- BTP FinOps: Credits steuern, Overages vermeiden gibt den vollständigen Überblick über alle BTP-Governance-Themen.
Autor: Bernhard Mändle, FinOptory. Fragen zur BTP-Vertragssteuerung beantworte ich im Erstgespräch.
Naechste Schritte
Wenn Sie Ihren aktuellen Vertrag auf Risiken und verfuegbare kommerzielle Hebel pruefen lassen moechten: Der FinOptory Vertragscheck ist ein Festpreis-Engagement, das in vier Wochen eine strukturierte Grundlage liefert.
Dieser Beitrag gehört zum Themen-Hub BTP FinOps und Credit-Steuerung. Für die Bewertung eines konkreten Vertrags liefert der FinOptory Vertragscheck in vier Wochen eine strukturierte Grundlage.
Zuletzt aktualisiert: Juli 2026