Core Personas sind im FinOps Framework der FinOps Foundation die sechs Stakeholder-Gruppen, die eine FinOps-Praxis tragen: FinOps Practitioner, Engineering, Finance, Product, Procurement und Leadership; Allied Personas sind die fünf angrenzenden Disziplinen ITAM, ITFM, ITSM / ITIL, Security und Sustainability, die FinOps berühren, ohne es zu betreiben. Eine Persona ist nach der Foundation eine Perspektive, keine Stelle: Sie beschreibt, was eine Gruppe von Kostendaten braucht, und in einem kleinen Unternehmen deckt eine Person oft mehrere davon ab. In diesem Handbuch benennt eine Persona außerdem, welche Entscheidung sie verantwortet. Das Framework steht unter der Lizenz CC BY 4.0; die Namen bleiben hier englisch, Stand der Lektüre 2026-10-16. Für die Rechnung heißt das: Jede Persona stellt ihr eine andere Frage, und eine Frage, die niemand stellt, bleibt unbeantwortet, auch wenn die Daten vorliegen.
So funktioniert es
Die Foundation beschreibt Personas als breite Gruppen von Beteiligten, die zusammenarbeiten müssen, und ordnet jeder Ziele, Verantwortungsbereiche und Beiträge zu FinOps zu. Was eine Persona im Alltag von einer anderen unterscheidet, ist die Frage, mit der sie an die Rechnung herantritt, das Artefakt, das sie dafür liest, und die Entscheidung, die am Ende bei ihr liegt. Was FinOps als Ganzes ist, erklärt Was FinOps ist.
Die sechs Core Personas
| Persona | Ziel, sinngemäß nach der Foundation | Frage an die Rechnung | Artefakt | Entscheidung |
|---|---|---|---|---|
| FinOps Practitioner | Business, Engineering und Finance verbinden und eine Kultur faktenbasierter Entscheidungen aufbauen | Stimmen Zuordnung, Berichte und Takt, damit alle anderen entscheiden können? | Zuordnungsregel, Monatsreview | welche Einsparungschance in den Review kommt |
| Engineering | Systeme entwerfen und betreiben, die kosteneffizient, leistungsfähig, zuverlässig und sicher sind | Was kosten meine Ressourcen, und was davon läuft ohne Nutzen? | Kostenbericht je Team oder Dienst | Rightsizing, Abschalten, Architekturwahl |
| Finance | den Geschäftswert der Technologieausgaben beziffern und Prognose, Budget und Chargeback tragen | Stimmt die Rechnung mit Budget und Prognose überein, und wie buche ich sie? | Rechnung, Budgetabweichung, Zuordnung nach Kostenstelle | Budget, Showback oder Chargeback |
| Product | Anforderungen definieren, Initiativen nach Geschäftszielen priorisieren und den Wert von Technologieentscheidungen erklären | Was kostet ein Kunde, ein Feature, ein Mandant, und trägt der Preis das? | Stückkosten je Produkt | Priorisierung, Preisgestaltung |
| Procurement | Technologie einkaufen, Verträge und Anbieterbeziehungen führen und Käufe mit der Praxis zeitlich abstimmen | Welche Commitments laufen, wann enden sie, was ist verhandelbar? | Commitment-Übersicht, Vertragslaufzeiten | Commitment-Kauf, Verlängerung |
| Leadership | Geschäfts- und Technikziele setzen, FinOps-Vorhaben priorisieren und Verantwortung als Kultur fördern | Stehen die Technologieausgaben im Verhältnis zum Wachstum, und wer verantwortet Abweichungen? | Gesamtbericht, Budget je Scope, Prognose | Budgetrahmen, Investitionen, Zielkonflikte |
Der FinOps Practitioner ist dabei eine Funktion, die jemand ausfüllt, keine Stelle, die besetzt werden müsste. Die Foundation beschreibt die Persona über Analytik, Optimierung, Zusammenarbeit und Veränderungsarbeit; in einem Unternehmen mit 10 bis 200 Personen füllt sie aus, wer die Rechnung zahlt oder freigibt und zugleich den Monatsreview einberuft. Wie das ohne Team aussieht, beschreibt FinOps ohne FinOps-Team.
Die fünf Allied Personas
Die Allied Personas betreiben FinOps nicht, aber ihre Arbeit berührt dieselben Daten. ITAM, nach der Foundation die Verwaltung von IT-Assets, Lizenzen und Vertragstreue, trifft FinOps bei Lizenzen und SaaS. ITFM sammelt und berichtet die IT-Ausgaben, wo es getrennt von Finance läuft. ITSM / ITIL standardisiert den IT-Servicebetrieb und wägt Servicelevel gegen Kosten ab. Security teilt Transparenz über die Nutzung und optimiert die Sicherheitsausgaben. Sustainability nutzt Nutzungsdaten für Umweltziele. In einem kleinen Unternehmen sind das selten eigene Rollen: ITAM und ITFM fallen auf die Person zusammen, die Software-Abonnements verwaltet, Security auf die Person, die die Sicherheitswerkzeuge betreibt. Welche Capability den Kontakt zu diesen Disziplinen ordnet, zeigt Die vier Domains und ihre Capabilities.
Was es für Ihre Kosten bedeutet
In einem Unternehmen mit 10 bis 200 Personen verteilen sich die sechs Core Personas auf wenige Rollen. Die Tabelle zeigt, welche Rolle welche Persona meist trägt und was sie jeden Monat in den Berichten sehen muss, damit die Persona überhaupt besetzt ist.
| Persona | Rolle, die sie meist trägt | Muss jeden Monat sehen |
|---|---|---|
| FinOps Practitioner | die Person, die die Rechnung zahlt oder freigibt | Zuordnungsgrad, offene Einsparungschancen, Reviewtermin |
| Engineering | die Engineering-Leitung, die Teamleitungen | Kosten je Team oder Dienst, Anomalien, ungenutzte Ressourcen |
| Finance | dieselbe Person wie der Practitioner oder die externe Buchhaltung | Rechnung gegen Budget und Prognose, Zuordnung nach Kostenstelle |
| Product | Produktleitung oder Geschäftsführung | Stückkosten je Produkt oder Kunde |
| Procurement | Geschäftsführung oder Engineering-Leitung | Laufzeiten und Auslastung der Commitments |
| Leadership | Geschäftsführung | Gesamtkosten gegen Umsatz und Plan, Budget je Scope |
Die Verteilung selbst ist nicht das Problem; die Foundation sieht sie für kleine Organisationen ausdrücklich vor. Das Problem ist die Persona ohne Namen. Zwei Lücken kosten unmittelbar Geld: Procurement, denn ohne diese Persona verfolgt niemand, wann Commitments auslaufen, und sie verlängern sich oder fallen weg, ohne dass es jemand entschieden hat, und Product, denn ohne eine Person, die nach Stückkosten fragt, bleibt die Rechnung ein Betrag ohne Bezug zum Umsatz. Und wenn Finance allein liest, ist die Rechnung abgestimmt, aber ohne Engineering unerklärt. Die Entscheidung, die die Personas treiben, ist deshalb eine Zuordnung: Für jede der sechs Fragen in der ersten Tabelle gibt es eine Person, die sie jeden Monat stellt, oder die Frage bleibt offen. Wie Verantwortlichkeiten unabhängig von der Unternehmensgröße geschnitten werden, behandelt FinOps-Rollen und Verantwortlichkeiten.
Wo es schiefgeht
- Persona ohne Person. Symptom: Ein Commitment läuft aus, und erst die höhere Rechnung des Folgemonats zeigt es. Ursache: Procurement ist niemandem zugeordnet; die Frage nach Laufzeiten stellt niemand, obwohl die Daten im Abrechnungskonto stehen.
- Eine Person, alle Personas. Symptom: Die Geschäftsführung liest die Rechnung, entscheidet über Commitments, beurteilt Anomalien und erklärt Engineering die Kosten, und alles davon zu spät. Ursache: Die Perspektiven wurden nicht getrennt; Engineering braucht einen eigenen Bericht, sonst bleibt die Engineering-Persona unbesetzt, auch wenn jemand „für Kosten zuständig“ ist.
- Persona als Stellenbeschreibung. Symptom: Die erste FinOps-Maßnahme ist eine Stellenausschreibung für einen FinOps Practitioner, und bis zur Besetzung liest niemand die Rechnung. Ursache: Die Persona wurde mit einer Stelle verwechselt; die Foundation beschreibt eine Funktion, die in kleinen Organisationen eine vorhandene Person ausfüllt.
- Finance liest allein. Symptom: Die Rechnung ist monatlich abgestimmt und gebucht, aber niemand kann sagen, warum sie gestiegen ist. Ursache: Der Kostenbericht erreicht Engineering nicht; die Engineering-Persona hat kein Artefakt und darum keine Frage.
Quellen
Gelesen am 2026-10-16. FinOps Foundation: FinOps Personas, FinOps Framework.