FinOps wird oft mit einem Dashboard verwechselt. Tatsächlich ist es eine Betriebsdisziplin, die Engineering, Finance und Leadership zusammenbringt — mit dem Ziel, jede Cloud-Investition an einen messbaren Geschäftswert zu koppeln.
Wenn Sie als CTO oder VP Engineering zum ersten Mal mit FinOps konfrontiert werden, klingt es vermutlich nach einem weiteren Tool, das Ihnen jemand verkaufen will. Das ist die häufigste Fehleinschätzung im Markt — und sie kostet Unternehmen Zeit, weil sie nach einem Produkt suchen, wo eigentlich eine Praxis fehlt.
Die FinOps Foundation definiert FinOps als die Disziplin, die Engineering, Finance, Technology und Business Teams zusammenbringt, um datengetriebene Entscheidungen über Cloud-Ausgaben zu treffen. Der Kern dieser Definition ist nicht "Cloud-Ausgaben", sondern "zusammenbringen". FinOps löst ein Kommunikationsproblem zwischen drei Gruppen, die traditionell getrennt arbeiten:
Ein Tool kann diese drei Gruppen nicht zusammenbringen. Das kann nur ein Prozess, der Verantwortlichkeiten klärt und Daten in der Sprache jeder Gruppe verfügbar macht.
Das FinOps Foundation Framework strukturiert die Praxis in drei wiederkehrende Phasen, die kontinuierlich durchlaufen werden — nicht einmalig:
Sichtbarkeit herstellen. Wer gibt wie viel aus, wofür, und wie verhält sich das zu Budget und Forecast? Ohne diese Phase basiert jede spätere Optimierung auf Vermutungen statt Daten.
Mit der Sichtbarkeit aus Phase 1 werden konkrete Hebel gezogen: Rightsizing, Reserved Instances, Savings Plans, Architekturentscheidungen. Diese Phase ist technisch am sichtbarsten, aber ohne Inform-Phase ungerichtet.
Governance, Automatisierung und kontinuierliche Verbesserung. FinOps ist kein Projekt mit Enddatum — diese Phase stellt sicher, dass die Praxis nach der Einführung weiterläuft, statt nach drei Monaten wieder einzuschlafen.
Für ein klassisches Unternehmen mit eigener Infrastruktur ist Cost Allocation relativ direkt: Eine Abteilung nutzt eine Ressource, die Kosten werden ihr zugeordnet. Für ein SaaS-Unternehmen mit Multi-Tenant-Architektur ist das fundamental anders. Wenn 100 Kunden auf derselben Function App oder demselben Datenbank-Cluster laufen, hilft klassisches Tagging auf Resource-Group-Ebene nicht weiter — die Kosten sind geteilt, aber die Frage „Was kostet uns Kunde X?" bleibt trotzdem bestehen, weil Finance und Leadership sie stellen werden.
Das ist der Punkt, an dem viele interne FinOps-Versuche scheitern: Sie wenden Standard-Tagging-Strategien auf eine Architektur an, für die sie nicht gebaut wurden, und wundern sich, warum die Allocation Rate bei 20–30 % stagniert.
Eine verbreitete Annahme: FinOps braucht ein eigenes Team. In den allermeisten Mittelstands-SaaS-Unternehmen ist das weder realistisch noch nötig. FinOps ist als Cross-Functional-Practice gedacht — verteilt auf bestehende Rollen:
Eine FinOps Practitioner-Rolle koordiniert diese Gruppen, trifft aber nicht für sie die operativen Entscheidungen. Das ist ein wichtiger Unterschied zu klassischem IT-Controlling: FinOps moderiert, statt anzuweisen.
Zur Abgrenzung lohnt sich ein kurzer Blick auf drei verbreitete Missverständnisse:
Der kostenlose Cloud Cost Health Check zeigt Ihnen Tagging-Coverage, Cost Allocation Gap und konkrete Quick Wins — basierend auf Ihrem eigenen Azure Cost Export.
Health Check anfragen →Sobald die Grundbegriffe von FinOps stehen, wird die nächste Frage unausweichlich: Wie übersetzt man Cloud-Kosten in geschäftsrelevante Kennzahlen wie Cost per Customer oder Cost per Transaction? Genau damit beschäftigt sich der nächste Artikel in dieser Reihe.