Der häufigste strategische Fehler in internen FinOps-Initiativen ist nicht mangelndes Engagement — es ist der Versuch, eine Reifestufe zu überspringen, für die die Voraussetzungen noch fehlen.
Jedes Unternehmen beginnt bei Crawl. Das ist kein Werturteil, sondern eine strukturelle Tatsache: Ohne Discovery, ohne Datenbasis und ohne Stakeholder-Alignment lässt sich kein präziseres Modell aufbauen. Das FinOps Maturity Model beschreibt drei Stufen, die sich über vier Dimensionen entwickeln — Discovery, Reporting, Unit Economics und Anomalie-Erkennung.
| Bereich | Crawl | Walk | Run |
|---|---|---|---|
| Discovery | Stakeholder-Interviews, Financial Records, Procurement-System | SSO-Logins, API-Connectors, Web Proxy Monitoring | CASB, Inventory Agents, Browser Plugins |
| Cost Allocation / Reporting | Kosten / Anzahl Tenants | Proxy-Metriken: API Calls, Requests, Rechenzeit je Tenant | App-seitiges Metering: Verbrauch je Tenant in eigener DB |
| Reporting-Form | Manuelle Reports aus Invoices und CSV-Exporten | Automatisierte Dashboards, Basis-KPIs | Vollintegriertes Reporting mit Unit Economics |
| Unit Economics | Keine Verbindung zu Geschäftskennzahlen | Einfaches Cost-per-User | TCO je Applikation, verknüpft mit Revenue-Metriken |
| Anomalie-Erkennung | Ad-hoc Prüfen wenn Problem auftaucht | Regelmäßige Checks, einfache Alerts | Automatisierte Erkennung, proaktive Alerts |
Auf der Crawl-Stufe ist die einzige realistische Allocation-Methode, Gesamtkosten durch die Anzahl der Tenants zu teilen. Ein konkretes Beispiel: Eine Function App kostet 100 € im Monat, 100 Kunden nutzen sie. Cost per Customer = 1 €. Diese Zahl ist ungenau, sobald die Kunden die Ressource unterschiedlich stark belasten — aber sie ist besser als keine Zahl, und sie schafft den ersten Referenzpunkt, an dem sich spätere Präzisierung messen lässt.
Reporting auf dieser Stufe ist manuell: CSV-Exporte aus der Azure-Rechnung, händisch aufbereitet. Anomalien werden nur entdeckt, wenn jemand zufällig hinschaut oder die Rechnung auffällig steigt.
Der Übergang von Crawl zu Walk ist der Schritt, an dem sich Allocation-Genauigkeit am stärksten verbessert, ohne dass bereits vollständiges Metering existiert. Statt Tenants gleich zu gewichten, fließen Proxy-Metriken ein: Anzahl API-Calls, Requests oder gemessene Rechenzeit je Tenant. Das bildet die tatsächliche Lastverteilung deutlich besser ab als ein simpler Durchschnitt.
Reporting wird auf dieser Stufe automatisiert — Basis-KPIs in einem Dashboard statt manueller CSV-Auswertung. Unit Economics beschränkt sich meist auf ein einfaches Cost-per-User, ohne tiefere Verknüpfung zu Umsatz- oder Margenkennzahlen.
Auf der Run-Stufe wird tatsächlicher Verbrauch je Tenant anwendungsseitig erfasst — typischerweise in einer eigenen Datenbank, die Engineering aufbaut und pflegt. Das ist präziser als jede Proxy-Metrik, weil es echten Ressourcenverbrauch misst statt ihn zu approximieren.
Wichtig zur Einordnung: Dieser Schritt ist kein FinOps-Capability im engeren Sinne, sondern eine Engineering-Voraussetzung. FinOps kann den Bedarf begründen und das Framework liefern, in dem die Daten später genutzt werden — implementiert wird das Metering von Engineering-Teams, nicht von einer FinOps-Funktion.
Unit Economics erreicht auf dieser Stufe seine volle Aussagekraft: Total Cost of Ownership je Applikation, direkt verknüpft mit Revenue-Metriken. Anomalie-Erkennung läuft automatisiert mit proaktiven Alerts, statt erst auf Nachfrage zu reagieren.
Eine wichtige Einschränkung gilt über alle drei Stufen: Wenn 100 Kunden auf einer einzigen Function App oder einem geteilten Datenbank-Cluster laufen, helfen klassische Resource Groups oder Azure Projects als Allocation-Grundlage nicht. Diese Konstellation ist der Grund, warum der Übergang von Crawl zu Walk zu Run in Multi-Tenant-SaaS anspruchsvoller ist als in Unternehmen mit dedizierter Infrastruktur pro Team — und warum generische Tagging-Ratgeber hier oft zu kurz greifen.
Ein Versuch, direkt bei Run zu starten — etwa durch den Kauf eines Tools mit Unit-Economics-Funktion, ohne vorherige Tagging-Disziplin und ohne Proxy-Metriken — führt regelmäßig dazu, dass die Zahlen zwar präzise aussehen, aber auf einer unvollständigen Datenbasis beruhen. Das Ergebnis ist eine Scheingenauigkeit: Eine Kennzahl mit drei Nachkommastellen, die auf 30 % Allocation-Coverage beruht, ist nicht präziser als eine grobe Schätzung — sie verschleiert nur ihre Unsicherheit besser.
Der robustere Weg ist, den eigenen Reifegrad ehrlich zu bestimmen und von dort aus systematisch zur nächsten Stufe zu arbeiten, statt eine Zielarchitektur zu kaufen, für die die Datenbasis fehlt.
Der kostenlose Health Check ordnet Ihre aktuelle Azure-Umgebung ein und zeigt den konkreten nächsten Schritt — basierend auf Ihrem eigenen Cost Export.
Health Check anfragen →Diese fünf Artikel folgen einer bewussten Reihenfolge: vom Grundverständnis von FinOps über die Geschäftslogik von Unit Economics, die strukturelle Ursache des Cost Allocation Gaps, die Grenzen von Tooling, bis zum Reifegrad-Modell, das einordnet, wo realistisch begonnen werden sollte. Wer alle fünf Schritte verstanden hat, kennt die Theorie. Die Implementierung — Tagging-Rollout, Governance, Proxy-Metriken in der eigenen Azure-Umgebung — ist der Teil, der tatsächlich Zeit kostet.