FinOps ist ein operatives Framework und zugleich eine kulturelle Praxis, mit der Engineering, Finance und Fachbereiche gemeinsam dafür sorgen, dass Technologieausgaben Geschäftswert erzeugen; so definiert es die FinOps Foundation, deren Framework unter der Lizenz CC BY 4.0 steht und dessen Begriffe dieses Handbuch übernimmt. Für die Cloud-Rechnung bedeutet das: Nicht die Rechnung ändert sich, sondern wer sie liest, wie schnell, und welche Entscheidung daraus folgt. Der Name verbindet „Finance“ und „DevOps“ und meint die Zusammenarbeit beider Seiten, nicht eine Abteilung dazwischen.

So funktioniert es

Die Definition der Foundation hat drei Teile, die zusammengehören. Erstens zielt FinOps auf den Wert, den eine Ausgabe erzeugt, nicht auf die niedrigste Summe; die Foundation schreibt ausdrücklich, dass es nicht in erster Linie ums Sparen geht, sondern um effizientes Wachstum. Zweitens verlangt sie zeitnahe, datenbasierte Entscheidungen, also Kostendaten in einem Takt, in dem ein Team noch reagieren kann. Drittens entsteht finanzielle Verantwortung durch Zusammenarbeit: Finance kennt Budget und Kostenbasis, Engineering kennt Nutzung und Alternativen, Produkt und Geschäftsführung bewerten, was eine Ausgabe wert ist.

Sechs Prinzipien

Die Foundation nennt sechs Prinzipien ohne Rangfolge: Teams need to collaborate; Business value drives technology decisions; Everyone takes ownership for their technology usage; FinOps data should be accessible, timely, and accurate; FinOps should be enabled centrally; Take advantage of the variable cost model of the cloud. „Zentral“ im fünften Prinzip heißt: Eine Stelle setzt Standards und bündelt Commitment-Entscheidungen, sie trägt nicht allein die Kosten.

Drei Phasen im Kreislauf

Das Framework beschreibt die Praxis als Kreislauf aus Inform, Optimize und Operate. Inform macht Kosten, Nutzung und Effizienz sichtbar und ordnet sie zu. Optimize findet und dokumentiert Möglichkeiten, Nutzung oder Preis zu verbessern. Operate setzt die gewählten Maßnahmen um und verbessert den Prozess selbst. Die Phasen werden laut Foundation iterativ durchlaufen, und verschiedene Teams können zugleich in verschiedenen Phasen und in unterschiedlichem Takt arbeiten.

Personas

Personas sind im Framework Stakeholder-Gruppen, keine Stellen. Die sechs Core Personas sind FinOps Practitioner, Engineering, Finance, Product, Procurement und Leadership; die Allied Personas ITAM, ITFM, ITSM / ITIL, Security und Sustainability berühren FinOps aus angrenzenden Disziplinen. In einem kleinen Unternehmen trägt eine Person oft mehrere Personas; wie das in der Praxis aussieht, beschreibt FinOps ohne FinOps-Team.

Domains und Capabilities

Vier Domains beschreiben die Ergebnisse einer FinOps-Praxis, und jede Domain bündelt Capabilities, also Dinge, die eine Organisation tun kann, um das Ergebnis zu erreichen. Understand Usage & Cost hält Data Ingestion, Allocation, Reporting & Analytics und Anomaly Management. Quantify Business Value hält Planning & Estimating, Forecasting, Budgeting, KPIs & Benchmarking und Unit Economics. Optimize Usage & Cost hält Architecting & Workload Placement, Rate Optimization, Usage Optimization, Licensing & SaaS und Sustainability. Manage the FinOps Practice hält FinOps Practice Operations, Governance, Policy & Risk, FinOps Assessment, Automation, Tools & Services, FinOps Education & Enablement, Invoicing & Chargeback, Intersecting Disciplines und, als jüngste Ergänzung, Executive Strategy Alignment. Was diese Ergänzung und die vertiefte Anleitung zu Scopes für ein kleines Team ändern, ordnet FinOps Framework 2026: was kleine Teams wirklich ändern sollten ein.

Reifegrade

Jede Capability kann auf einer anderen Stufe stehen: Crawl, Walk oder Run. Crawl bedeutet wenig Reporting und Werkzeug, einfache Kennzahlen und einen Fokus auf das, was leicht zu holen ist; Walk, dass die Capability in der Organisation verstanden und befolgt wird und die schwierigen Fälle benannt sind; Run, dass alle Teams sie befolgen und Automatisierung der bevorzugte Weg ist. Die Foundation sagt ausdrücklich, dass Run nicht überall das Ziel ist: Reife folgt dem Geschäftswert einer Capability.

Scopes und Technology Categories

Ein Scope ist im Framework ein abgegrenztes Segment der Ausgaben, das sich über Technologiekategorien hinweg erstreckt und aus dem Geschäftskontext heraus definiert wird: ein Produkt, eine Kostenstelle, eine Umgebung, eine Initiative. Viele Praktiken beginnen mit einem Standard-Scope, der sich an der Cloud-Nutzung orientiert und oft „Cloud FinOps“ genannt wird; die Foundation ergänzt, dass auch dieser Scope selten die Technologie selbst meint. Die Technology Categories, aus denen ein Scope sich zusammensetzen kann, nennt die Foundation als Public Cloud, SaaS, Data Cloud Platforms, Rechenzentrum und KI.

Was es für Ihre Kosten bedeutet

An der Rechnung ändert FinOps nichts. Was sich ändert, ist der Weg von der Rechnung zur Entscheidung, und dieser Weg hinterlässt vier Spuren in den Abrechnungsdaten. Eine Kostenzuordnung ordnet jede Position einem Verantwortlichen zu, über Konto, Subscription, Projekt und Tags; ihr Rest, die nicht zugeordneten Kosten, ist die ehrlichste Kennzahl der Phase Inform. Ein Kostenbericht je Verantwortlichem bringt die zugeordneten Kosten zu der Person, die sie beeinflussen kann. Ein Budget je Scope macht aus der Summe eine Abweichung, über die jemand entscheiden muss. Und eine Anomalie ist der Anstieg außerhalb der erwarteten Bandbreite, der erklärt werden muss, bevor er zur neuen Grundlinie wird.

Wohin das Geld geht, entscheiden zwei Größen: Nutzung und Preis. Die Phase Optimize trennt deshalb Nutzungsoptimierung, also weniger oder passendere Ressourcen für dasselbe Ergebnis, von Preisoptimierung, also Commitments und Rabatte für die Ressourcen, die ohnehin laufen. Eine Einsparungschance ist in beiden Fällen zuerst eine dokumentierte Option mit Schätzung; eine belegte Einsparung ist sie erst, wenn der nächste Bericht sie zeigt. Ob zugeordnete Kosten den Teams nur gezeigt oder tatsächlich belastet werden, ist die Entscheidung zwischen Showback und Chargeback, und sie gehört zur Capability Invoicing & Chargeback, nicht in die Buchhaltung allein.

FinOps ist kein Werkzeug: Software normalisiert Daten, verteilt Berichte und verfolgt Maßnahmen, legt aber nicht fest, wer eine Budgetüberschreitung hinnehmen darf. FinOps ist kein Sparprojekt: Die Antwort auf eine Kostenfrage kann auch lauten, mehr auszugeben, wenn der Wert es trägt. Und FinOps ist nicht Finance allein: Ohne die Engineering-Persona bleibt die Rechnung abgestimmt, aber unerklärt. Die Foundation führt Cloud Financial Management, Cloud Cost Management, Cloud Optimization, Cloud Financial Optimization und Cloud Financial Engineering als andere Namen derselben Praxis; den Begriff Cloud Financial Operations hält sie für missverständlich, weil er mit der gleichnamigen Funktion im Finanzbereich kollidiert. Im Sprachgebrauch meint Cloud-Kostenmanagement meist den engeren Teil, der sich auf Public Cloud, Sichtbarkeit und Optimierung beschränkt; FinOps schließt Personas, Governance und die anderen Technology Categories ein.

Wo es schiefgeht

  • FinOps wird als Werkzeug eingekauft. Symptom: Dashboards, die niemand öffnet, und Empfehlungen, die niemand umsetzt. Ursache: kein Verantwortlicher je Scope und kein Takt, in dem jemand auf die Zahlen reagieren muss.
  • FinOps wird als Sparprojekt aufgesetzt. Symptom: ein pauschales Kürzungsziel, danach Ruhe, bis die Kosten wieder steigen. Ursache: Der Wert der Ausgaben wurde nie bewertet, und für den nächsten Anstieg gibt es niemanden, der ihn beurteilt.
  • Finance macht es allein. Symptom: Die Rechnung ist abgestimmt, aber die Frage nach dem Warum bleibt monatelang offen. Ursache: Die Engineering-Persona fehlt, und ohne sie gibt es keine Nutzungsdaten, nur Beträge.

Quellen

Gelesen am 2026-10-15. FinOps Foundation: FinOps Framework, What is FinOps?, FinOps Principles, FinOps Phases, FinOps Personas, FinOps Domains, FinOps Maturity Model, FinOps Scopes, Technology Categories, Das FinOps Framework 2026.