Man könnte das Update des FinOps Frameworks für 2026 als längere Checkliste lesen. Es steckt aber etwas mehr dahinter. Die FinOps Foundation rückt vom reinen Blick auf Public-Cloud-Kosten ab und hin zum Geschäftswert von Technologie insgesamt, schärft den Begriff des FinOps Scopes und nimmt Executive Strategy Alignment als eigene Capability auf.
Kleine Teams reagieren darauf gern mit mehr Meetings, Rollen und Dashboards. Besser ist es, einen klar umrissenen Entscheidungsbereich zu wählen und ihm bessere Daten, einen verantwortlichen Owner und einen Review-Rhythmus zu geben, den man auch durchhält.
Die relevanten Änderungen von 2026
Die FinOps Foundation beschreibt vier Schwerpunkte: eine aktualisierte Definition, stärkere strategische Ausrichtung, präzisere Scopes und eine breitere Anwendung auf Technology Categories und angrenzende Disziplinen.
| Änderung | Bedeutung | Praktische Reaktion eines kleinen Teams |
|---|---|---|
| Technologie statt nur Cloud | FinOps kann Public Cloud, SaaS, Lizenzen, Data Platforms, Private Cloud und Datacenter einschließen | Nicht alles gleichzeitig aufnehmen; nur Kategorien ergänzen, die dieselbe Entscheidung beeinflussen |
| Präzisere Scopes | Ein Scope folgt einem Entscheidungs- und Geschäftskontext, nicht zwingend einer Providergrenze | Mit einem Produkt, einer Kostenstelle oder einer Managemententscheidung starten |
| Executive Strategy Alignment | Strategie wird eine ausdrückliche Capability | Jede Kennzahl an eine Entscheidung, einen Owner und einen Review-Takt binden |
| Intersecting Disciplines | Berührungspunkte zu Procurement, ITFM, ITAM, Sustainability, Security und anderen Funktionen werden sichtbarer | Übergaben und Quellen klären, keine parallele Organisation bauen |
Die Framework-Übersicht bleibt modular und bewusst nicht präskriptiv. Für kleine Teams ist das eine gute Nachricht: Niemand erwartet, dass alle Capabilities gleichzeitig denselben Reifegrad erreichen.
Ein Scope ist eine Entscheidungsgrenze
Die Foundation definiert einen FinOps Scope als abgegrenzten Teil der Technologieausgaben, der an ein Geschäftskonstrukt wie Produkt, Kostenstelle oder Umgebung gebunden ist. Die hilfreiche Frage lautet also, welche Entscheidung eine gemeinsame Sicht auf die Zahlen braucht. Woher die Rechnung kommt, ist zweitrangig.
Es hilft, einen Scope in fünf Feldern aufzuschreiben:
- Entscheidung: Was soll regelmäßig entschieden werden?
- Ausgaben: Welche Kosten gehören dafür hinein und welche ausdrücklich nicht?
- Owner: Wer kann handeln oder eine Abweichung akzeptieren?
- Leser: Engineering, Finance, Product oder Leadership – wer braucht welche Sicht?
- Takt: Wie oft ändern sich Daten und Entscheidung sinnvoll?
Ein Produkt-Scope kann zum Beispiel AWS-Nutzung, eine Azure-Komponente und direkt zuordenbare SaaS-Lizenzen enthalten, wenn der Product Owner über die gemeinsame Unit Cost entscheidet. Ein „AWS-Scope“ wäre dafür zu eng, ein globaler „Technology-Scope“ zu breit.
Nur dann einen neuen Scope anlegen
Die Scopes-Guidance warnt selbst vor dem Aufwand, zu viele Scopes zu pflegen. Ein neuer lohnt sich nur, wenn mindestens einer dieser Punkte zutrifft:
- Es gibt eine andere verantwortliche Entscheidung.
- Kosten benötigen eine andere Allokations- oder Bewertungsmethode.
- Risiko, Takt oder Datenqualität unterscheiden sich wesentlich.
- Eine gemeinsame Sicht würde eine relevante Abweichung verstecken.
Eine neue Subscription, ein neuer Account oder ein weiterer Provider allein sind kein Grund. Infrastrukturgrenzen können als Dimensionen im bestehenden Scope bleiben.
Executive Strategy Alignment klein umsetzen
Strategieausrichtung klingt nach einer weiteren Managementebene. In einem kleinen Team genügt oft eine kurze Vereinbarung zwischen einer Kennzahl und der Entscheidung, die sie stützt:
| Feld | Frage |
|---|---|
| Geschäftsziel | Welches Ergebnis soll die Technologieausgabe unterstützen? |
| Entscheidungskennzahl | Welche Kennzahl verändert eine echte Entscheidung? |
| Guardrail | Welches Budget, Risiko oder Qualitätsniveau darf nicht unbemerkt überschritten werden? |
| Owner | Wer entscheidet, wenn Ziel und Guardrail kollidieren? |
| Review | Wann wird entschieden und welche Daten müssen dann geschlossen sein? |
Ein Dashboard ohne diese Felder kann trotzdem gutes Reporting sein, mit Strategieausrichtung hat es aber wenig zu tun. Und eine Kennzahl, auf die niemand reagieren darf, beobachtet man nur.
Die vier Domains als Monatszyklus verwenden
Das Framework ordnet seine Capabilities vier ergebnisorientierten Domains zu. Statt vier Programme aufzusetzen, kann ein kleines Team sie einmal im Monat der Reihe nach durchgehen:
- Nutzung und Kosten verstehen: Daten abstimmen, größte Veränderungen erklären, unzugeordnete Kosten zeigen.
- Geschäftswert quantifizieren: Budget, Forecast, Unit Cost oder einen anderen entscheidungsrelevanten Nenner aktualisieren.
- Nutzung und Kosten optimieren: wenige priorisierte Maßnahmen mit Owner, erwartetem Effekt und Status führen.
- FinOps-Praxis steuern: Datenlücken, Policy-Entscheidungen und blockierte Übergaben sichtbar machen.
Die Reihenfolge ist eine Tagesordnung, keine Reifegradtreppe. In den meisten Monaten sind alle vier Domains dabei, und das ist in Ordnung, solange sie denselben Scope und dieselbe Frage bedienen.
Eine Person kann mehrere Personas abdecken
Das Framework nennt Core Personas: Engineering, Finance, Leadership, Procurement, Product und FinOps Practitioner. In einem kleinen Unternehmen sind das eher Blickwinkel als Stellen, und oft vertritt eine Person gleich mehrere davon.
Statt eines Rollenmodells sollten Sie deshalb festhalten, wer was entscheidet:
- Wer bestätigt die Rechnungsbasis?
- Wer erklärt technische Veränderungen?
- Wer akzeptiert Budgetabweichungen?
- Wer priorisiert Optimierungsarbeit?
- Wer entscheidet über Commitments und Verträge?
Die Fragen bleiben wichtig, auch wenn derselbe Name mehrmals auftaucht. Getrennt gestellt verhindern sie, dass Datenprüfung, Empfehlung und Freigabe unbemerkt zu einem einzigen Schritt werden.
Ein minimales 2026-Profil
Für den ersten Scope reicht eine Seite:
| Element | Minimaler Inhalt |
|---|---|
| Scope | Geschäftskontext, enthaltene Kosten, Ausschlüsse |
| Ergebnis | Eine konkrete wiederkehrende Entscheidung |
| Daten | Quellen, Kostendefinition, Währung, Aktualität, bekannte Lücken |
| Ownership | Entscheider und Action Owner |
| Review | Fester Takt und geschlossenes Datenfenster |
| Maßnahmen | Kleine priorisierte Liste mit Status und Verifikation |
| Reife | Ein nächster Engpass, nicht eine Bewertung aller Capabilities |
Erweitern Sie das Profil erst, wenn eine echte Entscheidung an einem fehlenden Scope, Datenfeld oder Prozess scheitert. So bleibt das Framework ein Werkzeug und wird nicht selbst zur Arbeit.
Die vier Domains als ein Zyklus sind im monatlichen Cloud-Kostenreview Schritt für Schritt ausgeführt. In Costfluent entspricht ein Scope Segmenten für Teams, Produkte, Kunden, Umgebungen und Kostenstellen.
Quellen und Prüfgrenze
Geprüft am 6. September 2026: FinOps Foundation Framework 2026 update, Framework overview, FinOps Scopes und Domains. Das Framework steht unter CC BY 4.0; dieser Beitrag fasst die Änderungen mit Quellenangabe zusammen und übersetzt sie in eine Empfehlung für kleine Teams.