Ein Unternehmen mit 10 bis 200 Beschäftigten betreibt FinOps, indem es die Capabilities des Frameworks auf drei Rollen verteilt, die es ohnehin hat: eine Engineering-Leitung, die Person, die die Cloud-Rechnung bezahlt, und die Geschäftsführung. Eine eigene FinOps-Funktion ist dafür keine Voraussetzung; die FinOps Foundation, deren Framework unter CC BY 4.0 steht, beschreibt die Praxis ausdrücklich als etwas, das nicht eine Person oder ein Team erledigt, sondern das die Zusammenarbeit bestehender Teams verändert. Für die Rechnung zählt das, weil Cloud-Kosten in einem wachsenden Unternehmen mit dem Produkt wachsen und ohne benannte Verantwortung niemand sagen kann, welcher Teil des Anstiegs Produkt ist und welcher Teil Verschwendung.
So funktioniert es
Das Framework unterscheidet sechs Core Personas: FinOps Practitioner, Engineering, Finance, Product, Procurement und Leadership. Es stellt klar, dass Personas Stakeholder-Gruppen sind und dass in kleinen Organisationen eine Person mehrere davon vertritt. Die Verteilung auf drei Rollen folgt aus dem, was jede Rolle ohnehin weiß:
| Rolle im Unternehmen | Personas des Frameworks | Bringt mit | Entscheidet |
|---|---|---|---|
| Engineering-Leitung | Engineering, Product, meist auch FinOps Practitioner | Nutzung, Architektur, Mengentreiber wie Kunden oder Anfragen | Zuordnungsstruktur, technische Maßnahmen und ihre Reihenfolge |
| Die Person, die die Rechnung bezahlt | Finance | Rechnung, Kostenbasis, Währung, Budgetvergleich | Kostendefinition, Datenstand, Behandlung im Monatsabschluss |
| Geschäftsführung | Leadership, Procurement | Ziele, Budgetrahmen, Verträge | Commitments, Freigabegrenzen, hingenommene Abweichungen |
Die Persona FinOps Practitioner ist in dieser Verteilung eine Rolle, keine Stelle: Jemand bereitet die Zahlen vor, hält den Takt und bündelt Commitment-Entscheidungen. In den meisten kleinen Unternehmen ist das die Engineering-Leitung, weil sie den Zugang zu den Abrechnungsdaten und zu den Ursachen hat; es kann ebenso die Person aus Finance sein, wenn sie die Nutzungsfragen an Engineering weiterreicht.
Der monatliche Durchlauf als Minimum
Die Phasen Inform, Optimize und Operate laufen laut Foundation iterativ, und der kleinste Takt, in dem alle drei Rollen zusammenkommen, ist der Monat, weil die Rechnung monatlich kommt. Ein Durchlauf stimmt die Summe gegen die Rechnung ab, erklärt die Veränderungen zum Vormonat, vergleicht mit Budget und Prognose, entscheidet über wenige Maßnahmen und prüft, ob die Maßnahmen des Vormonats in den Daten sichtbar sind. Agenda und Vorlagen dafür liefert Monatliches Cloud-Kostenreview: Agenda und Vorlagen. Alles, was häufiger geschieht, etwa die Prüfung einer Anomalie, bleibt bei einer Rolle und wird im Durchlauf nur berichtet.
Welche Capabilities auf Crawl-Stufe zählen
Die Foundation sagt, dass jede Capability auf einer eigenen Reifestufe stehen kann und dass Run nicht überall das Ziel ist. Für ein Unternehmen ohne FinOps-Team heißt Crawl: wenig Werkzeug, einfache Kennzahlen und der Fokus auf das, was leicht zu holen ist. Dafür tragen neun Capabilities die Praxis: Data Ingestion und Allocation, weil ohne vollständigen Export und Zuordnung nichts weiter folgt; Reporting & Analytics und Anomaly Management, damit Veränderungen bei einem Verantwortlichen ankommen; Budgeting, damit eine Summe zur Abweichung wird; Usage Optimization und Rate Optimization, als kurzer Backlog und eine dokumentierte Commitment-Entscheidung; FinOps Practice Operations, also der monatliche Durchlauf selbst; und Invoicing & Chargeback, zumindest als bewusste Entscheidung für Showback.
Die übrigen Capabilities bleiben liegen, bis eine Entscheidung sie verlangt. KPIs & Benchmarking, FinOps Assessment, FinOps Education & Enablement und Intersecting Disciplines setzen eine Organisation voraus, die es bei dieser Größe nicht gibt. Forecasting und Planning & Estimating lohnen sich, sobald Budgets deutlich wachsen oder ein großes Vorhaben ansteht. Executive Strategy Alignment ist bei dieser Größe erfüllt, wenn die Geschäftsführung im Durchlauf sitzt. Sustainability und Architecting & Workload Placement folgen dem Produkt, nicht der Praxis.
Was es für Ihre Kosten bedeutet
Die Praxis lebt in drei Artefakten, und jedes ist in den Abrechnungsdaten sichtbar.
Das erste ist eine Kostenzuordnung, die die ganze Rechnung abdeckt. Sie beginnt mit den Strukturen, die die Provider ohnehin liefern, Konto, Subscription und Projekt, und ergänzt sie um Tags erst dort, wo eine Struktur mehrere Verantwortliche enthält. Der Zuordnungsgrad ist die erste Kennzahl der Praxis, und nicht zugeordnete Kosten bleiben als eigener Posten sichtbar, statt proportional verteilt zu werden.
Das zweite ist ein Kostenbericht je Verantwortlichem. Er zeigt die zugeordneten Kosten, die Veränderung zum Vormonat und die größten Positionen, in der Kostendefinition, die Finance festgelegt hat, und er geht an die Person, die die Ressourcen anlegt. Ein Bericht für die Geschäftsführung fasst diese Berichte zusammen; er ersetzt sie nicht.
Das dritte ist ein Budget je Scope. Ein Scope ist im Framework ein Segment der Ausgaben, das aus dem Geschäftskontext heraus definiert wird, bei dieser Größe meist das Produkt, eine Umgebung oder die Public Cloud insgesamt. Das Budget ist die Grenze, an der die Geschäftsführung entscheidet, und die Abweichung dazu ist der Gegenstand des monatlichen Durchlaufs. Ob zugeordnete Kosten den Teams gezeigt oder intern belastet werden, ist die Wahl zwischen Showback und Chargeback. Chargeback setzt eine Kostenstellenstruktur voraus; wo sie fehlt, bleibt Showback.
Wo es schiefgeht
- Eine Person verantwortet alles. Symptom: Die Engineering-Leitung bereitet die Zahlen vor, erklärt sie, entscheidet über Maßnahmen und setzt sie um, und sobald sie im Urlaub ist, fällt der Durchlauf aus. Ursache: Die Personas wurden auf eine Rolle zusammengelegt statt auf drei verteilt; Datenprüfung, Empfehlung und Freigabe sind unbemerkt ein Schritt geworden.
- Tagging vor Zuordnung. Symptom: ein Tagging-Standard mit mehr Schlüsseln, als jemand pflegt, ein niedriger Zuordnungsgrad und Diskussionen darüber, wer die Tags nachträgt. Ursache: Die Zuordnung begann bei den Tags statt bei Konto, Subscription und Projekt, die ohne ein einziges Tag schon den größten Teil der Rechnung abdecken.
- Optimieren vor Sehen. Symptom: ein Commitment, das Geld an eine Last bindet, die kurz darauf kleiner ist, oder ein Rightsizing, dessen Wirkung niemand nachweisen kann. Ursache: Die Phase Optimize begann, bevor Inform eine Zuordnung und einen Bericht je Verantwortlichem geliefert hatte; es gab keinen Vergleichswert.
- Berichte, die niemand liest. Symptom: ein monatlicher Gesamtbericht an die Geschäftsführung, auf den keine Entscheidung folgt. Ursache: Der Bericht geht an die Rolle, die den Rahmen setzt, nicht an die Rolle, die die Ressourcen anlegt, und er stellt keine Frage, die jemand beantworten müsste.
Quellen
Gelesen am 2026-10-15. FinOps Foundation: FinOps Framework, What is FinOps?, FinOps Personas, FinOps Maturity Model, FinOps Domains, FinOps Phases, FinOps Scopes.