FinOps Inform, Optimize, Operate: Das Framework auf SAP BTP anwenden

Das FinOps-Framework der FinOps Foundation wurde für Public Cloud entwickelt. Drei Phasen, ein Zyklus: Inform, Optimize, Operate. Seit 2024/2025 gehört Licensing offiziell zu den definierten Scopes. SAP BTP ist ein Lehrbuch-Beispiel dafür, wie dieser Zyklus auf Enterprise-Lizenzierung übertragen wird. BTP-Credits verfallen. Overages entstehen zum Listenpreis. Beides lässt sich systematisch steuern, wenn der Zyklus konsequent umgesetzt wird.

---

Was das FinOps-Framework ist

Die FinOps Foundation ist eine Non-Profit-Organisation unter dem Dach der Linux Foundation. Sie entwickelt und pflegt das FinOps Framework als offenen Standard für Technology Cost Management. Das Framework definiert Prinzipien, Personas, Phasen und Capabilities. Seit 2019 ist es das branchenweite Referenzmodell für organisierte Cloud-Kostensteuerung.

Im Framework 2025 umfasst FinOps fünf Scopes: Public Cloud (AWS, Azure, GCP), SaaS, Data Center, AI und Licensing. Die explizite Aufnahme von Licensing in den Framework-Scope ist kein Zufall. Große Technologieanbieter wie SAP betreiben komplexe Vertragsmodelle mit variablen Verbrauchsmetriken, Verfallsregeln und Rabattstrukturen, die dieselbe betriebliche Disziplin erfordern wie Public-Cloud-Workloads. Der Unterschied: Bei Public Cloud sieht man den Verbrauch in Echtzeit. Bei SAP-Lizenzierung sieht man ihn erst dann vollständig, wenn eine Steuerungsinfrastruktur aufgebaut ist.

Die zentrale Struktur des Frameworks sind drei Phasen, die iterativ durchlaufen werden: Inform, Optimize, Operate. Kein Einmalprojekt, sondern ein kontinuierlicher Zyklus.

---

Inform: Transparenz als Voraussetzung für jeden Steuerungsmoment

Inform bedeutet: vollständige Sichtbarkeit herstellen, bevor Entscheidungen getroffen werden. Im Public-Cloud-Kontext heißt das, alle Kosten nach Ressource, Team und Produkt aufzuschlüsseln. Im BTP-Kontext bedeutet Inform das Gleiche, mit SAP-spezifischen Instrumenten.

Der Ausgangspunkt ist die Inventarisierung. Welche BTP-Entitlements sind vertraglich festgehalten? Welche Subaccounts existieren, welche Services laufen aktiv, welche Service-Plans sind aktiviert, werden aber nicht verbraucht? Shelfware im BTP-Kontext sind Service-Plans, die aktiviert, aber ohne aktive Nutzung mitlaufen und das Credit-Budget belasten, ohne Geschäftswert zu erzeugen.

Die zweite Dimension der Inform-Phase ist Cost Allocation: welche Credits werden für welche Projekte, Geschäftsbereiche oder Kostenstellen verbraucht? Das BTP Cockpit liefert Verbrauchsdaten auf Subaccount-Ebene, aber nur wenn die Subaccount-Struktur von Anfang an nach Zurechnungslogik aufgebaut wurde. Wer diese Grundstruktur nicht hat, kann in der Inform-Phase keine belastbaren Steuerungsmomente identifizieren, weil der Verbrauch nicht zugeordnet werden kann.

Vier Steuerungsmomente, die in der Inform-Phase sichtbar werden:

• Nutzung: Welche Services verbrauchen wie viele Credits? Wo driftet der tatsächliche Verbrauch vom Plan ab?
• Berechtigungen: Welche Service-Plans sind aktiviert? Welche Entitlements werden nicht genutzt? Shelfware-Erkennung auf Basis aktiver Service-Plans.
• Infrastruktur: Wie ist das System dimensioniert? Laufen Non-Production-Umgebungen im gleichen Rhythmus wie Produktivsysteme?
• Kosten: Wie verteilen sich Credits auf Projekte und Kostenstellen? Gibt es Zuordnungslücken, die eine verursachergerechte Verrechnung verhindern?

Die Inform-Phase liefert kein abschließendes Ergebnis. Sie liefert die Datenbasis, ohne die Optimize und Operate keine Grundlage haben. Dieser Steuerungsmoment, nämlich der Aufbau der Transparenzinfrastruktur selbst, ist oft der anspruchsvollste des gesamten Zyklus, weil er organisatorische Entscheidungen (Subaccount-Design, Rollenverteilung, Datenzugang) voraussetzt, die rückwirkend nicht einfach zu korrigieren sind.

---

Optimize: Aktive Eingriffe statt Beobachtung

Optimize bedeutet: auf Basis der in der Inform-Phase gewonnenen Sichtbarkeit aktiv eingreifen. Im BTP-Kontext sind vier Optimierungsfelder besonders relevant.

Rightsizing von Service-Plans und Runtime-Konfigurationen. BTP-Services wie SAP HANA Cloud, SAP Integration Suite oder SAP Build Process Automation werden in Service-Plans gebucht, die unterschiedliche Leistungsniveaus und damit unterschiedliche Credit-Verbräuche haben. Wenn die tatsächliche Auslastung dauerhaft unter dem gebuchten Plan liegt, ist Rightsizing ein direkter Steuerungsmoment, um Credits gezielter einzusetzen. Das setzt voraus, dass die Auslastungsdaten aus der Inform-Phase belastbar sind.

Non-Production-Shutdown-Strategien. Entwicklungs-, Test- und Sandboxumgebungen verbrauchen Credits auch dann, wenn sie nicht aktiv genutzt werden. HANA Cloud, Kyma und Cloud Foundry-Runtimes laufen kontinuierlich, sofern keine Shutdown-Richtlinien greifen. Nächtliche und wochenendliche Shutdowns für Non-Production-Systeme sind in der Praxis eine der direktesten Maßnahmen zur Credit-Optimierung (Quelle: Redress Compliance, SAP Community).

Hyperscaler-Overlap prüfen. Unternehmen mit paralleler Azure-, AWS- oder GCP-Nutzung zahlen in bestimmten Szenarien doppelt für ähnliche Capabilities: Integration-Middleware, Datenbanken, API-Management. Die Optimize-Phase im BTP-FinOps-Zyklus ist der Steuerungsmoment, um diese Überlappungen systematisch zu prüfen und das Investitionsportfolio gezielt auszurichten, statt es ungesteuert wachsen zu lassen.

Credit-Commitment-Kalibrierung. Ein zu großzügig dimensionierter Credit-Pool, der am Jahresende verfällt, ist eine direkte Kapitalallokationsentscheidung. Die Optimize-Phase liefert die Datengrundlage, um das Commitment beim nächsten Renewal oder beim nächsten möglichen Anpassungszeitpunkt mit dem tatsächlichen Bedarf abzugleichen. Konservative Erstdimensionierung mit vertraglich vereinbartem Nachkaufrecht ist dabei die strukturell günstigere Ausgangslage gegenüber einem von Anfang an überdimensionierten Pool.

Optimize ist kein Einmalprojekt. Jede dieser Maßnahmen verändert die Datenbasis für den nächsten Inform-Durchlauf. Der Zyklus schließt sich.

---

Operate: Kontinuierliche Steuerung als Governance-Prozess

Operate ist die Phase, in der Inform und Optimize nicht mehr als diskrete Projekte stattfinden, sondern als laufender Betrieb. Das ist der Übergang von FinOps als Initiative zu FinOps als organisatorischer Fähigkeit.

Monatlicher Steuerungsrhythmus. Die BTP-Verbrauchsdaten aus dem Cockpit und den Balance Statements werden monatlich ausgewertet. Budget-Tracking vergleicht den tatsächlichen Credit-Verbrauch mit dem geplanten Verbrauch und dem verbleibenden Jahresbudget. Anomalie-Erkennung identifiziert unerwartete Spitzen, bevor sie den Credit-Pool erschöpfen. Forecast-Updates passen die Projektion für das verbleibende Vertragsjahr an.

Dieser monatliche Steuerungsmoment ist entscheidend: Wer den Verbrauch erst bei der Jahresrechnung analysiert, hat keine Handlungsoption mehr. Wer ihn monatlich prüft, kann in der zweiten Jahreshälfte noch aktiv eingreifen, wenn der Verbrauchspfad nicht mit dem Commitment übereinstimmt.

Vier Rollen im BTP-FinOps-Prozess. Operate funktioniert nur, wenn Verantwortlichkeiten klar zugeordnet sind. Das FinOps-Framework betont, dass Teams zusammenarbeiten müssen, nicht dass eine Rolle alles verantwortet. Für BTP bedeutet das:

• Contract Manager: Vertragsstruktur im Blick, Compliance gegen die gebuchten Service-Plans, Eskalation bei Anomalien, Vorbereitung des Renewals auf Basis der Operate-Daten.
• Procurement: Einkaufsentscheidungen bei Top-Up-Bedarf, Verhandlung von Nachkaufoptionen, Einbindung bei Credit-Commitment-Anpassungen.
• Controlling: Monatliche Cost-Allocation-Reports, Kostenstellen-Verrechnung, Budgetabweichungsanalyse für BTP-Kosten.
• Executive: Freigabeentscheidungen bei größeren Verbrauchsabweichungen, Priorisierung von Optimierungsmaßnahmen mit Budgetrelevanz.

Quarterly Business Review für BTP. Einmal pro Quartal werden Verbrauch, Forecast, Optimierungsmaßnahmen und anstehende Änderungen im Service-Katalog zusammen betrachtet. Ein QBR für BTP enthält: tatsächlicher Credit-Verbrauch vs. Plan, Status der Optimierungsmaßnahmen aus dem Vorquartal, aktualisierter Forecast bis Jahresende, Deprecation-Watch für Gruppe-2-Services, Handlungsempfehlungen für das Folgequ artal.

Audit-Readiness. Operate umfasst auch die Vorbereitung auf die jährliche Compliance-Prüfung. SAP-Verträge enthalten Self-Reporting-Pflichten, insbesondere bei Overage. Wer seine BTP-Nutzungsdaten strukturiert aufbereitet hat, ist in der Auditsituation handlungsfähig, statt reaktiv.

---

Was BTP-FinOps von allgemeinem FinOps unterscheidet

Das FinOps-Framework ist prinzipiell für jeden Cloud-Scope anwendbar. Für BTP gelten drei SAP-spezifische Mechaniken, die den Zyklus in der Praxis anspruchsvoller machen als bei einem Standard-IaaS-Workload.

Credit-Verfall statt monatlicher Abrechnung. Bei Public Cloud wird monatlich abgerechnet; ungenutzte Ressourcen belasten das aktuelle Monatsbudget. Bei BTP verfallen ungenutzte Credits am Ende der Vertragsperiode vollständig. Der Steuerungsmoment für Budgetallokation und Credit-Verbrauch liegt damit am Jahresende. Wer ihn verpasst, hat keine Korrekturmöglichkeit mehr. Das erzwingt eine vorausschauende Steuerung, die im Public-Cloud-FinOps nicht in dieser Form existiert.

Overage-Mechanik ohne Volumenschutz. Bei Public Cloud gibt es meistens Budgetalerts und automatische Begrenzungen. Bei BTP werden Overages zum vollen Listenpreis abgerechnet, ohne Volumenrabatte. Der Rabatt, der im Commitment verhandelt wurde, gilt nicht für Verbrauch über dem Credit-Pool. Das macht proaktives Monitoring zu einem wirtschaftlich relevanten Steuerungsmoment, nicht zu einer operativen Nebentätigkeit.

Abgrenzung zu klassischen SAM- und ITAM-Tools. Software Asset Management-Tools messen Compliance: Sind mehr User aktiv als lizenziert? Wurden alle Lizenzen korrekt klassifiziert? BTP-FinOps steuert Budgets und Verbrauchspfade in Echtzeit. Beide Disziplinen ergänzen sich, ersetzen sich aber nicht. SAM/ITAM löst die Compliance-Frage. FinOps löst die Steuerungsfrage. Für BTP braucht es beide, weil die Credit-Mechanik gleichzeitig ein Vertragsthema (Entitlements, Self-Reporting-Pflicht) und ein Budgetsteuerungsthema (Verbrauch, Overage, Forecast) ist.

---

Fazit

Das FinOps Inform-Optimize-Operate-Modell ist kein abstraktes Framework, das auf BTP aufgesetzt wird. Es beschreibt, was systematische BTP-Steuerung in der Praxis erfordert: Sichtbarkeit zuerst, dann aktive Eingriffe, dann laufende Governance. Die drei Phasen sind kein lineares Projekt, sondern ein Zyklus. Der nächste Renewal, der nächste Quarterly Business Review, der nächste Forecast-Update lädt den Zyklus neu. Wer ihn etabliert hat, steuert BTP-Budgets aktiv. Wer ihn nicht hat, entdeckt Abweichungen, wenn die Handlungsoption bereits eingeschränkt ist.

Wenn Sie prüfen möchten, welche Steuerungsmomente in Ihrer BTP-Vertragsstruktur heute bereits adressiert sind und wo Lücken bestehen, ist ein BTP-Vertragscheck mit FinOptory ein strukturierter Einstieg. Ohne Verpflichtung, mit klarem Ergebnis in vier Wochen.

---

Häufige Fragen

Was ist der Unterschied zwischen Inform, Optimize und Operate im FinOps-Framework? Inform stellt vollständige Transparenz über Kosten und Verbrauch her. Optimize setzt aktive Maßnahmen zur Ausrichtung von Verbrauch und Commitment um. Operate verankert beide Aktivitäten als laufenden Governance-Prozess. Die drei Phasen sind kein einmaliger Ablauf, sondern ein iterativer Zyklus.

Warum ist das FinOps-Framework für SAP BTP relevant, obwohl es für Public Cloud entwickelt wurde? Die FinOps Foundation hat Licensing seit 2024/2025 als offiziellen Scope aufgenommen. BTP teilt mit Public Cloud die Grundmechanik: variables Verbrauchsmodell, Verbrauchsmetriken, Budget-Allocat ion und Optimierungspotenzial durch aktive Steuerung. SAP-spezifische Mechaniken wie Credit-Verfall und Overage-Abrechnung zum Listenpreis machen die Steuerungsdisziplin sogar anspruchsvoller als bei Standard-IaaS.

Welche Rollen müssen im BTP-FinOps-Prozess zusammenarbeiten? Contract Manager, Procurement, Controlling und Executive. Der Contract Manager verantwortet die Vertragskonformität und Renewal-Vorbereitung. Procurement steuert Nachkaufentscheidungen. Controlling verantwortet die monatliche Cost Allocation und Budgetabweichungsanalyse. Executive trifft Freigabeentscheidungen bei größeren Abweichungen.

Was unterscheidet BTP-FinOps von klassischem SAP-Lizenzmanagement? SAP-Lizenzmanagement in der klassischen Form zielt auf Compliance: sind die genutzten Lizenzen korrekt erfasst und klassifiziert? BTP-FinOps zielt auf Budgetsteuerung: werden Credits so eingesetzt, dass weder Verfall noch ungeplante Overage entsteht? Beide Disziplinen sind komplementär. Für BTP braucht es beide, weil die Credit-Mechanik gleichzeitig eine Compliance- und eine Steuerungsfrage ist.

Wie oft sollte der BTP-FinOps-Zyklus durchlaufen werden? Die Operate-Phase läuft monatlich (Budget-Tracking, Anomalie-Erkennung, Forecast-Update) und quartalsweise (Quarterly Business Review). Inform und Optimize sind keine Jahresprojekte, sondern laufende Bestandteile des Operate-Rhythmus. Wichtige Steuerungsmomente wie Credit-Commitment-Anpassungen werden vorausschauend auf den Renewal-Termin hin geplant.