Die sechs FinOps-Prinzipien sind die Grundsätze, die die FinOps Foundation ihrem Framework zugrunde legt: Teams need to collaborate, Business value drives technology decisions, Everyone takes ownership for their technology usage, FinOps data should be accessible, timely, and accurate, FinOps should be enabled centrally und Take advantage of the variable cost model of the cloud. Das Framework steht unter der Lizenz CC BY 4.0; dieses Handbuch übernimmt die Namen der Foundation und gibt ihre Bedeutung sinngemäß wieder, Stand 2026-10-16. Für die Rechnung legt jedes Prinzip fest, wer einen Posten sehen muss, wie schnell, und welche Entscheidung daraus folgt. Was FinOps im Ganzen ist, erklärt Was FinOps ist.
So funktioniert es
Die Foundation stellt die sechs Prinzipien ausdrücklich ohne Rangfolge nebeneinander und nennt jedes wichtig für den Erfolg von FinOps. Eine Checkliste sind sie damit nicht: Sie legen fest, nach welchen Maßstäben eine Organisation über Technologieausgaben entscheidet, bevor Phasen, Capabilities und Reifegrade das Wie beschreiben.
Die sechs Prinzipien
Teams need to collaborate. Die Foundation versteht darunter, dass Finance, Engineering, Produkt und Geschäftsführung Technologieausgaben gemeinsam steuern, und zwar in dem Takt und in der Tiefe, die die jeweilige Technologie verlangt. Mit einer Handvoll Konten heißt das: Die Person, die zahlt, und die Person, die die Ressourcen betreibt, sehen dieselben Zahlen im selben Monat.
Business value drives technology decisions. Nach der Foundation zählt das Verhältnis von Kosten zu dem, was sie erzeugen: Stückkosten und wertbezogene Kennzahlen sagen mehr als der Gesamtbetrag, und Abwägungen zwischen Kosten, Qualität und Geschwindigkeit werden bewusst getroffen. Für ein kleines Unternehmen kommen damit die Kosten eines Kunden, eines Mandanten oder eines Auftrags vor der Frage, wo sich sparen lässt.
Everyone takes ownership for their technology usage. Die Foundation legt die Verantwortung für Nutzung und Kosten bei denen, die Systeme entwerfen und betreiben, von der Architektur bis zum Betrieb, innerhalb von Budgets, an denen sie mitwirken. Ohne FinOps-Funktion bewegen sich Kosten genau hier: Wer eine Instanz startet, sieht in den Kostendaten, was sie kostet.
FinOps data should be accessible, timely, and accurate. Kostendaten sollen nach der Foundation geteilt werden, sobald sie vorliegen, auf allen Ebenen der Organisation konsistent sein und Prognose, Abweichungsanalyse und internen Vergleich tragen; für Konsistenz verweist die Foundation auf FOCUS. Für die Rechnung heißt das: ein Export der Abrechnungsdaten, den jemand tatsächlich liest, nicht eine PDF-Rechnung, die einmal im Monat abgelegt wird.
FinOps should be enabled centrally. Eine zentrale Stelle setzt nach der Foundation Standards, bündelt Entscheidungen über Preise, Commitments und Rabatte, um Skaleneffekte zu nutzen, und hält die Kommunikation mit der Geschäftsführung zusammen, damit Engineering sich auf die eigene Nutzung konzentrieren kann.
Take advantage of the variable cost model of the cloud. Die Foundation sieht in jedem Kostenmodell, dem variablen der Cloud, dem festen des Rechenzentrums und anderen, Vor- und Nachteile und eine Chance auf mehr Wert; Entscheidungen sollen das Kostenmodell neben den technischen Anforderungen berücksichtigen, Kapazität bedarfsgerecht beschaffen, wo es sich lohnt, iterativ planen und die Architektur laufend anpassen, statt selten aufzuräumen. Für die Rechnung heißt das, dass jeder Posten monatlich neu entsteht und deshalb monatlich neu entschieden werden kann.
Zentral ermöglichen ohne zentrales Team
In einem Unternehmen mit 10 bis 200 Personen gibt es selten eine FinOps-Funktion. Das Prinzip spricht von einer zentralen FinOps-Funktion oder einem zentralen Team; dass sie eine eigene Abteilung sein muss, sagt es nicht. In einem Unternehmen dieser Größe kann sie eine Stelle sein, an der drei Dinge zusammenlaufen: der Standard für die Kostenzuordnung, also welche Konten, Projekte und Tags es gibt und was sie bedeuten, die Entscheidung über Commitments, und der Takt, in dem Berichte gelesen werden. Diese Stelle ist in der Praxis die Person, die die Rechnung bezahlt oder freigibt, zusammen mit der Engineering-Leitung. Wie Rollen eine Praxis ohne Team tragen, beschreibt FinOps ohne FinOps-Team; wie „Everyone takes ownership“ als Rollenentwurf aussieht, FinOps-Rollen und Verantwortlichkeiten.
Variables Kostenmodell und Commitments
Das sechste Prinzip erwähnt Commitments nicht. Aus ihm folgt, dass ein Commitment eine Entscheidung über das Kostenmodell ist: bewusst gewählt für eine Nutzung, die stabil genug ist, und die Flexibilität des variablen Modells bleibt erhalten, wo die Nutzung schwankt. Die Instrumente und wie sie in der Rechnung erscheinen, behandeln AWS Savings Plans und das Kapitel Preismodelle und Commitments.
Was es für Ihre Kosten bedeutet
In einem kleinen Unternehmen trägt jedes Prinzip ein Artefakt, an dem sich prüfen lässt, ob es gelebt wird. Die Tabelle ordnet jedem Prinzip sein Artefakt und das Kapitel zu, das es behandelt.
| Prinzip | Artefakt im kleinen Unternehmen | Kapitel |
|---|---|---|
| Teams need to collaborate | ein monatliches Kostenreview mit Finance und Engineering | Reporting und Analyse |
| Business value drives technology decisions | eine Stückkostenkennzahl je Produkt oder Kunde | Zuordnung und Verantwortung |
| Everyone takes ownership for their technology usage | ein benannter Verantwortlicher je Konto, Projekt oder Tag-Wert und ein Kostenbericht je Verantwortlichem | Governance und Betriebsmodell |
| FinOps data should be accessible, timely, and accurate | ein Export der Abrechnungsdaten und Berichte, die alle lesen können | Abrechnungsdaten und Standards |
| FinOps should be enabled centrally | eine Zuordnungsregel (Kontostruktur, Pflicht-Tags) und eine Stelle für Commitment-Entscheidungen | Zuordnung und Verantwortung |
| Take advantage of the variable cost model of the cloud | ein Budget je Scope und eine dokumentierte Commitment-Entscheidung | Budgets, Prognosen und Finanzen |
In den Abrechnungsdaten zeigen sich die Prinzipien an drei Stellen: Der nicht zugeordnete Rest misst, wie weit Ownership und zentraler Standard reichen, die Zahl der Personen, die den Monatsbericht öffnen, ob Daten zugänglich sind, und das Verhältnis von Commitments zu variabler Nutzung, ob das sechste Prinzip bewusst umgesetzt ist. Eine Reifegradbewertung liefern die Prinzipien nicht; Capabilities misst das Framework an anderer Stelle. Wie die Prinzipien in den drei Phasen zur Arbeit werden, beschreibt Inform, Optimize, Operate: die drei FinOps-Phasen; was die Fassung 2026 für kleine Teams ändert, FinOps Framework 2026: was kleine Teams wirklich ändern sollten.
Wo es schiefgeht
- Prinzipien als Checkliste. Symptom: Ein Dokument hakt alle sechs Prinzipien ab, aber die Rechnung wird weiterhin von einer Person allein gelesen. Ursache: Die Prinzipien wurden als Zustand verstanden, nicht als Maßstab, an dem jede Entscheidung über eine Ausgabe gemessen wird.
- Ownership ohne Daten. Symptom: Engineering soll Kosten verantworten, bekommt aber keinen Bericht, der die eigenen Ressourcen zeigt. Ursache: Das dritte Prinzip wurde eingeführt, bevor das vierte erfüllt war; Verantwortung ohne zugängliche Daten bleibt eine Zuweisung auf dem Papier.
- „Zentral“ heißt „Finance allein“. Symptom: Finance stimmt die Rechnung ab und entscheidet über Commitments, Engineering erfährt davon aus der Rechnung. Ursache: Die zentrale Stelle wurde mit einer Abteilung verwechselt; das Prinzip meint Standards und gebündelte Entscheidungen, die alle Beteiligten kennen.
- Variables Modell ohne Entscheidung. Symptom: Entweder läuft alles zum Listenpreis, oder alles ist über Jahre gebunden. Ursache: Niemand hat die stabile Grundlast von der schwankenden Nutzung getrennt, also fiel die Commitment-Entscheidung nie bewusst.
Quellen
Gelesen am 2026-10-16. FinOps Foundation: FinOps Principles, FinOps Framework, What is FinOps?. FOCUS: FinOps Open Cost and Usage Specification.