Der FinOps-Reifegrad ist die Stufe, auf der ein Team eine einzelne FinOps-Capability betreibt; das Framework der FinOps Foundation, lizenziert unter CC BY 4.0, beschreibt diese Stufen als Crawl, Walk und Run. Beurteilt wird je Capability, nicht je Unternehmen: Dieselbe Organisation kann ihre Kostenzuordnung auf Walk betreiben und ihre Prognose auf Crawl, und die Foundation sagt ausdrücklich, dass Run nicht überall das Ziel ist. Für die Rechnung zählt der Reifegrad, weil er festlegt, wie viel Aufwand in welche Capability fließt: Eine zu niedrige Stufe lässt Kosten ohne Verantwortlichen und Abweichungen ohne Erklärung, eine zu hohe bindet Arbeitszeit an Automatisierung, die keine anstehende Entscheidung braucht.
So funktioniert es
Die Foundation versteht FinOps als iterative Arbeit, die mit jeder Wiederholung reifer wird. Crawl, Walk, Run heißt, mit einem schnellen, engen Schritt zu beginnen, zu prüfen, was er gebracht hat, und den Umfang nur dort auszuweiten, wo der Ertrag den zusätzlichen Aufwand rechtfertigt.
Die drei Stufen
Die Foundation beschreibt jede Stufe anhand von vier Merkmalen: wie weit die Capability befolgt wird, wie mit Randfällen umgegangen wird, wie anspruchsvoll die Kennzahlen sind und wie viel auf Werkzeugen und Automatisierung ruht. Auf Crawl sind Reporting und Werkzeuge dünn, Kennzahlen und Prozesse einfach, nicht jedes wesentliche Team befolgt die Capability, und die Arbeit zielt auf leichte Gewinne. Auf Walk befolgt die Organisation sie, ihre Kennzahlen liegen auf mittlerem bis hohem Niveau, die schwierigen Randfälle sind bekannt und die Kosten ihrer Behebung geschätzt, einige werden bewusst beiseitegelassen („informed ignoring“, wie die Foundation es nennt), und Prozesse oder Automatisierung tragen den größten Teil. Auf Run befolgt jedes Team sie, die schwierigen Randfälle werden bearbeitet, die Kennzahlen sind ehrgeizig, und Automatisierung hat Vorrang.
Reife je Capability, nicht je Unternehmen
Laut Foundation wird die Stufe je Capability bestimmt, und selbst Tätigkeiten innerhalb einer Capability können auf unterschiedlichen Stufen stehen. Als Kurzform für den eigenen Stand bietet die Foundation ein FinOps Assessment und eine Bewertungstabelle an und ergänzt je Stufe Beispielziele aus ihrer Community zum zugeordneten Anteil der Kosten, zur Abdeckung durch Commitments und zur Prognosegenauigkeit. Diese Beispiele sind Orientierung, keine Schwellen.
Im Kern der Beschreibung warnt die Foundation davor, Run für jede Capability als Ziel zu behandeln. Als Beispiel nennt sie eine Anomalieerkennung auf Walk, die die wenigen bisherigen Kostenspitzen zuverlässig gefunden hat; weitere Reifung hebt dort die Stufe, ohne die Erfolgskennzahl zu verbessern, und der Aufwand fehlt bei einer Capability, die sofort Nutzen brächte. Reifen soll, was den höchsten Geschäftswert liefert.
Für ein Unternehmen mit 10 bis 200 Beschäftigten lässt sich jede Stufe an beobachtbaren Artefakten festmachen; die Tabelle beschreibt, was sichtbar ist, nicht, welche Werte erreicht werden müssen:
| Capability | Crawl | Walk | Run |
|---|---|---|---|
| Allocation | Zuordnung über Konto, Subscription und Projekt; nicht zugeordnete Kosten bleiben ein eigener Posten; der Zuordnungsgrad wird monatlich abgelesen | Ein Tag-Standard mit wenigen Pflichtschlüsseln, eine dokumentierte Regel für geteilte Kosten, benannte und hingenommene Lücken | Jede neue Ressource trägt ihre Zuordnung ab der Anlage; eine Richtlinie prüft das und meldet Verstöße an den Verantwortlichen |
| Reporting & Analytics | Ein Kostenbericht je Verantwortlichem, monatlich aus Konsole oder Export gezogen | Berichte je Scope erreichen die Verantwortlichen ohne Zutun, mit Vormonat und Budget, in einer Kostendefinition, die Finance und Engineering teilen | Teams fragen ihre Kosten selbst ab, Stückkosten stehen neben den Beträgen |
| Budgeting | Ein Budget je Scope, die Abweichung wird im monatlichen Durchlauf besprochen | Budgets mit Schwellen und Benachrichtigung an den Verantwortlichen, eine Prognose daneben | Prognosebasierte Warnungen mit hinterlegter Maßnahme; der Abgleich mit der Planung gehört zum Monatsabschluss |
| Anomaly Management | Die Anomalieerkennung des Anbieters ist eingeschaltet, Meldungen landen bei einer Person | Anomalien erreichen den Verantwortlichen des Scopes und enden mit einer festgehaltenen Entscheidung: erklärt, akzeptiert oder behoben | Schwellen je Scope, eine Anomalie löst automatisch einen Vorgang aus, die Reaktionszeit ist eine Kennzahl |
| Rate Optimization | Eine dokumentierte Commitment-Entscheidung; Abdeckung und Auslastung werden monatlich angesehen | Abdeckung und Auslastung sind Kennzahlen im Durchlauf, Käufe folgen einer festgelegten Regel | Käufe laufen nach Regel und teils automatisiert, ihre Wirkung wird in den amortisierten Kosten nachgewiesen |
Den eigenen Stand bestimmen
Die Einordnung braucht keinen Fragebogen, sondern je Capability drei Fragen und ein Artefakt als Beleg. Wird die Capability ausgeführt, und von wem? Folgen ihr alle Teams oder nur das, das sie eingeführt hat? Was geschieht bei einem Randfall, etwa einer Ressource ohne Verantwortlichen, und wurde das entschieden oder passiert es einfach? Der Beleg ist das Artefakt selbst: der Bericht, der verschickt wurde, die Regel, die aufgeschrieben ist, das Protokoll der Entscheidung.
Dass die meisten Capabilities bei dieser Größe auf Crawl bleiben, ist eine Entscheidung, keine Schwäche: Wenige Konten, wenige Teams und eine monatliche Rechnung lassen sich in einem manuellen Durchlauf erfassen, und der Geschäftswert rechtfertigt ihre Automatisierung selten. Die Ausnahmen sind Allocation und Reporting & Analytics, weil jede andere Capability aus ihnen liest. Welche Capabilities bei dieser Größe zählen, beschreibt FinOps ohne FinOps-Team; die vollständige Liste ordnet Die vier Domains und ihre Capabilities.
Was es für Ihre Kosten bedeutet
Der Reifegrad steht nicht in den Abrechnungsdaten, aber er ist aus ihnen ablesbar: Der Anteil nicht zugeordneter Kosten zeigt die Stufe der Allocation, die Zahl der Berichte, auf die eine Entscheidung folgte, die Stufe des Reportings, und die Zahl der am Monatsende erklärten gegenüber den offenen Abweichungen die von Budgeting und Anomaly Management. Diese drei Werte, monatlich festgehalten, sind eine Reifebeurteilung mit Vormonatsvergleich.
Die Entscheidung, die daraus folgt, lautet nicht „höher“, sondern „wo zuerst“. Eine Capability steigt eine Stufe, wenn eine konkrete Entscheidung sie braucht: Chargeback setzt Allocation auf Walk voraus, weil interne Belastung ohne dokumentierte Regel für geteilte Kosten Streit erzeugt; ein größeres Commitment setzt Reporting auf Walk voraus, weil die Wirkung sonst niemand nachweisen kann; Tagging-Richtlinien, wie sie Tags und Labels beschreibt, gehören zu Run und lohnen erst, wenn Konto, Subscription und Projekt nicht mehr ausreichen. Wie die Stufen in das Framework eingebettet sind, zeigt Was FinOps ist.
Wo es schiefgeht
- Reife als Gesamtnote. Symptom: Das Unternehmen bezeichnet sich als „auf Walk“, ohne sagen zu können, in welcher Capability. Ursache: Die Stufe wurde je Unternehmen vergeben statt je Capability.
- Run als Ziel. Symptom: Ein Automatisierungsvorhaben für Anomalien oder Tagging läuft, während der Zuordnungsgrad nicht gemessen wird. Ursache: Der Aufwand folgte der Stufe statt dem Geschäftswert; die Foundation warnt genau davor.
- Einschätzung statt Artefakt. Symptom: Die Selbsteinschätzung nennt Walk, der Bericht entsteht aber von Hand bei einer Person und fällt in deren Urlaub aus. Ursache: Die Reife wurde an der Absicht bemessen, nicht am Artefakt und daran, ob alle Teams ihm folgen.
- Eine Stufe für alle Scopes. Symptom: Die Produktion ist sauber zugeordnet, die Entwicklungsumgebungen gar nicht, und doch gilt eine Stufe für alles. Ursache: Kennzahlen und Reife einer Capability dürfen laut Foundation je Scope variieren; die Einordnung hat die Scopes nicht getrennt.
Quellen
Gelesen am 2026-10-16. FinOps Foundation: FinOps Maturity Model, FinOps Framework, FinOps Scopes.