Ein FinOps-Scope ist der Teil der Technologieausgaben, auf den eine Praxis FinOps gezielt anwendet; im Framework der FinOps Foundation, lizenziert unter CC BY 4.0, wird er entlang geschäftlicher Einheiten wie Produkt, Kostenstelle oder Umgebung geschnitten und kann mehrere Technology Categories umspannen. Der Scope legt fest, welche Ausgaben die Praxis abdeckt und mit welcher Intensität; die Technology Category sagt, aus welcher Art von Technologie sie stammen. Für die Rechnung zählt die Unterscheidung: Ein Scope, der stillschweigend nur die Public Cloud umfasst, lässt die SaaS-Abonnements, Softwarelizenzen und KI-Anbieter hinter demselben Produkt aus und beantwortet nur zum Teil, was dieses Produkt kostet.
So funktioniert es
Scopes
Für die Foundation ist ein Scope der Rahmen für Entscheidungen: Er legt fest, wer beteiligt ist, an welchen Capabilities gearbeitet wird und was als Erfolg gilt; eine Praxis hat meist mehrere. Capabilities wie Allocation oder Forecasting behalten in jedem Scope ihren Zweck; was der Scope ändert, ist, wie oft sie laufen, wie streng die Governance ist, welche Zielwerte für Kennzahlen gelten und welche Reife verlangt wird.
Scopes folgen laut Foundation dem Entscheidungskontext, nicht der Infrastruktur: Ein Scope kann alles umfassen, was eine Entscheidung berührt, auch über mehrere Produkte oder Umgebungen hinweg, und Ausgaben eines Bereichs lassen sich auf getrennte Scopes aufteilen, wenn Teile davon anderen Zielen dienen oder unter anderen Rahmenbedingungen stehen. Ein neuer Scope lohnt sich nur, wenn er eine Entscheidung verändert; jeder kostet Pflege, deshalb rät die Foundation zur Sparsamkeit. Scopes sind zudem situativ: Sie beginnen meist mit einer Frage der Geschäftsführung, etwa was das Unternehmen für KI ausgibt, werden erst definiert, wenn klar ist, welche Entscheidung die Antwort stützen soll, und enden mit diesem Ergebnis.
Nach der Darstellung der Foundation beginnt eine Praxis häufig mit der Cloud-Nutzung als erstem Scope, der Arbeit, die oft Cloud FinOps genannt wird; auch dieser Scope bestimmt sich eher danach, was sich das Unternehmen vom Umstieg in die Cloud verspricht, etwa geringere Kosten oder schnellere Auslieferung, als nach der Cloud als Technologie. Später kamen Scopes über die Public Cloud hinaus dazu; bei KI zieht die Foundation den Scope um die Investition und ihren Zweck, nicht um die Plattform.
Technology Categories
Eine Technology Category ist eine Art von Technologie, aus der Ausgaben stammen; jede wird auf eigene Weise eingekauft und abgerechnet, und das bestimmt, wer die Rechnung stellt, in welcher Einheit abgerechnet wird und wie detailliert die Kostendaten sind, wie die Tabelle unten zeigt. Am 2026-10-16 führt die Foundation fünf, eine je Tabellenzeile. Jede Kategorieseite wendet das Framework auf diese Art von Ausgaben an und enthält einen Abschnitt dazu, wie weit sich ihre Abrechnungsdaten in FOCUS abbilden lassen. Den Abschnitt zu den Kategorien hat die Foundation mit der Überarbeitung des Frameworks 2026 eingeführt, und sie stellt die Liste nicht als vollständig dar.
Lizenzen sind keine eigene Kategorie, auch wenn die Übersicht des Frameworks sie noch neben Cloud, SaaS und Data Center führt; sie gehören zur Capability Licensing & SaaS in der Domain Optimize Usage & Cost. Wo ihre Kosten erscheinen, hängt laut Foundation vom Kaufweg ab: Lizenzen, die in einer Cloud-Ressource enthalten sind oder über einen Cloud-Marketplace gekauft wurden, stehen in den Abrechnungsdaten des Cloud-Anbieters, die übrigen in der Abrechnung des Herstellers. Berechnet wird je Sitz, Nutzer, Prozessorkern oder nach einer anderen Einheit; die Bindung läuft meist über mehrere Jahre oder unbefristet, und während der Laufzeit lassen sich oft Lizenzen nachkaufen (True-up), aber keine zurückgeben.
Was jede Kategorie mitbringt
| Kategorie | Wer stellt in Rechnung | Abrechnungseinheit | Datenquelle | Zuordnungsschlüssel | Übliche Lücke |
|---|---|---|---|---|---|
| Public Cloud | AWS, Microsoft, Google Cloud | Nutzungsmenge je SKU: Stunde, GB, Anfrage | Nutzungsexport mit täglichen Posten, FOCUS | Konto, Subscription, Projekt; Tags und Labels | Geteilte Kosten, etwa ein Kubernetes-Cluster als eine Zeile für viele Teams |
| SaaS | Der Softwareanbieter, direkt, über Reseller oder Marketplace | Sitz oder Nutzer je Abonnement, dazu Nutzungsmeter | Rechnung, CSV-Export, Admin-API, Vertrag | Nutzerliste zu Abteilung oder Kostenstelle | Einkauf per Kreditkarte, Jahresabonnement neben Monatsnutzung, selten Ressourcenebene |
| Data Cloud Platforms | Die Plattform, etwa Snowflake oder Databricks, oder der Cloud-Anbieter | Verbrauchseinheiten der Plattform, die FOCUS als virtuelle Währung abbilden kann | Telemetrie zu Abfragen, Jobs und Pipelines, dazu die Rechnung | Warehouse, Workspace oder Job zu Team | Rechenleistung, die mehrere Teams teilen |
| Data Center | Hardwarehersteller, Facility- und Wartungsverträge, Versorger | Abschreibung, Miete der Flächen, Strom und Kühlung, Personal | Asset-Datenbank oder CMDB, Strommessung, Buchhaltung oder ERP | Feste Umlage, Verbrauch oder definierte Verrechnungseinheiten zu Team | Keine Verbrauchsrechnung eines Anbieters; die Gesamtkosten müssen aus Kosten zusammengesetzt werden, die IT und Facility Management getrennt buchen |
| AI | Der Cloud-Anbieter (Amazon Bedrock, Microsoft Foundry, Gemini Enterprise Agent Platform), der Modellanbieter (OpenAI, Anthropic) oder ein SaaS-Produkt | Token, API-Aufrufe, GPU-Stunden, Kapazitätsreservierungen | Cloud-Abrechnungsdaten, Nutzungsberichte, Dashboards und Logs der Anbieter | Projekt, Schlüssel oder Tag zu Team oder Feature | Unklar, wer die Modellausgabe nutzt; unvollständige Abrechnungsdaten der Anbieter |
Was es für Ihre Kosten bedeutet
Die Kategorie entscheidet, was der monatliche Durchlauf mit den Daten tun kann. Für die Public Cloud und KI-Dienste in der Cloud-Rechnung trägt ein Export jeden Posten mit Tag, Konto und Ressource, sodass der Durchlauf die Summe gegen die Rechnung abgleichen, Veränderungen bis zur Ressource erklären und Anomalien täglich sehen kann. SaaS- und Lizenzkosten erreichen das Unternehmen meist als Rechnung des Herstellers, als CSV-Export oder über eine Admin-API; wie die SaaS-Seite der Foundation festhält, sind diese Daten grob und reichen selten bis zur Ressource; in die Berichte gelangen solche Daten deshalb in der Regel per Dateiimport, und den Zuordnungsschlüssel liefert das Unternehmen selbst, etwa eine Nutzerliste, weil die Rechnung keinen enthält. Der Durchlauf prüft hier Rechnung gegen Vertrag und bezahlte gegen aktive Sitze, erkennt aber keine Tagesanomalie; was ein Dateiimport leistet, beschreibt CSV- und Dateiimporte. Bei KI-Anbietern mit eigener Rechnung hängt es davon ab, ob ein täglicher Nutzungsexport existiert; siehe Nutzungsexporte der KI-Anbieter und Abrechnung der KI-Anbieter. Welche Daten eine Kubernetes-Zeile auf Verantwortliche aufteilen, behandelt Kubernetes-Kostendaten.
Die Entscheidung, die der Scope erzwingt, ist die Abgrenzung selbst. Die Frage, was ein Produkt kostet, kann in einem Unternehmen mit 10 bis 200 Beschäftigten einen Scope über Cloud-Rechnung, KI-Anbieter und SaaS-Werkzeuge ziehen, die das Produkt tragen; alles andere bleibt bewusst außerhalb und wird benannt. Welcher Scope zuerst kommt, folgt aus der anstehenden Entscheidung, nicht aus der größten Kategorie. Wie der Scope zu Phasen, Personas und Capabilities steht, zeigt Was FinOps ist.
Wo es schiefgeht
- Scope gleich Kategorie. Symptom: Der Scope Cloud FinOps umfasst die AWS-Rechnung, während die Rechnung des KI-Anbieters für dasselbe Produkt per Kreditkarte bezahlt wird und in keinem Bericht erscheint. Ursache: Der Scope wurde an der Technologiegrenze gezogen statt um die Entscheidung.
- Ein Scope für alles. Symptom: Produktion, Experimente und ein KI-Pilot werden an einer Budgetabweichung gemessen, und die Spitzen des Piloten lösen Alarme der Produktion aus. Ursache: Unterschiedliche Toleranzen können laut Foundation eigene Scopes innerhalb eines Ausgabenbereichs rechtfertigen.
- Scopes ohne Ende. Symptom: ein Scope je Team, Werkzeug und Initiative, und niemand liest die Berichte mehr. Ursache: Klassifikation wurde mit Entscheidungskontext verwechselt.
- Dateidaten wie Exportdaten behandelt. Symptom: Eine SaaS-Rechnung wird als eine Monatszeile importiert, und für sie wird eine Anomalieerkennung erwartet. Ursache: Eine Monatszeile hat keine Tagesgranularität.
Quellen
Gelesen am 2026-10-16. FinOps Foundation: FinOps Scopes, Technology Categories, FinOps for SaaS, FinOps for Data Cloud Platforms, FinOps for Data Center, FinOps for AI, Licensing & SaaS, FinOps Framework, FinOps Framework 2026: Executive Strategy, Technology Categories, and Converging Disciplines.