Ein Kostenziel für die Cloud macht aus einer Kennzahl eine Zusage, die ein Team für einen Zeitraum trägt: welche Kennzahl, von welchem Ausgangswert, auf welchen Zielwert, bis wann, und wer das Ergebnis prüft. Die Kennzahl allein beschreibt nur; erst das Ziel sagt, ob ein Ergebnis gut ist und wer handeln muss, im Normalfall der Kostenverantwortliche des Bereichs. Für die Rechnung entscheidet die Form des Ziels, welches Verhalten belohnt wird. Ein fester Betrag bremst auch Wachstum, das Umsatz bringt, und ein Einsparziel, das Schätzungen zählt, belohnt Versprechen statt Wirkung.
So funktioniert es
AWS unterscheidet im Kostenpfeiler des Well-Architected Framework zwischen Zielen, die die Richtung vorgeben, und Zielwerten, die ihr einen messbaren Umfang und einen Termin geben. Ziele sollen Nutzung und Kosten zugleich erfassen und das Verhältnis zwischen beiden, etwa sinkende Kosten je Geschäftsergebnis. Die FinOps Foundation behandelt das Thema in der Capability KPIs & Benchmarking in der Domäne Quantify Business Value (CC BY 4.0). Ihre Aktivitäten reichen von der Auswahl von Kennzahlen, die für das Geschäft zählen, über Verbesserungsziele, die mit den Personas Leadership und Finance samt Zuständigkeit vereinbart werden, bis zur wiederkehrenden Überprüfung der Kennzahlen. Ihre KPI-Bibliothek sammelt Kennzahlen mit Definition, Formel und Datenquelle. Wie die einzelnen Kennzahlen berechnet werden, steht in Kennzahlen für Cloud-Ausgaben; diese Seite behandelt, wie daraus Ziele werden.
Wenige Kennzahlen, je eine Frage
Ein Team trägt besser zwei oder drei Ziele als zehn. Jede Kennzahl beantwortet eine Frage, gehört einer Person und hat eine typische Fehlsteuerung:
| Kennzahl | Frage | Zielform | Trägt | Falscher Anreiz |
|---|---|---|---|---|
| Stückkosten | Wird der Betrieb je Leistungseinheit günstiger? | relativ: Kosten je Einheit bis zu einem Datum | der Produktverantwortliche | eine Einheit, die mit den Kosten wächst |
| Zuordnungsgrad | Hat jeder Euro einen Verantwortlichen? | Anteil zugeordneter Kosten | wer die Zuordnung pflegt | den Rest per Schlüssel verteilen und als zugeordnet zählen |
| Budgetabweichung | Hält der Bereich seinen Plan? | Band um das Budget | der Kostenverantwortliche | großzügige Budgets, Ausgaben vor Periodenende |
| belegte Einsparungen | Wirkt, was entschieden wurde? | Betrag nach Prüfung je Quartal | der Kostenverantwortliche | Schätzungen statt Belegen zählen |
Wer Commitments kauft, trägt zusätzlich ein Ziel für die effektive Sparquote; ein zu hoch gesetzter Wert verleitet dazu, über den stabilen Bedarf hinaus zu binden.
Ausgangswert, Zielwert, Zeitraum, Prüfung
Der Ausgangswert wird festgelegt, bevor eine Maßnahme beginnt, auf derselben Kostenbasis und für denselben Bereich wie das spätere Ergebnis. In derselben Capability wertet die FinOps Foundation es als Zeichen einer reiferen Praxis, wenn der Vergleichsfall für vermiedene Kosten vor der Maßnahme schriftlich feststeht und nicht nachträglich zusammengestellt wird, und sie hält vermiedene Kosten (Ausgaben, die gekommen wären und ausbleiben) getrennt von Einsparungen, die das bereits laufende Ausgabenniveau senken. Welche Kostenbasis welche Zahl liefert, erklärt Listenpreis, berechnete, effektive und amortisierte Kosten; wer Commitments amortisiert plant, misst auch amortisiert.
Der Zielwert ist relativ, wo der Bereich wächst, und absolut, wo er stabil sein soll. AWS nennt als Beispiel für ein Ziel, dass die Nutzung einer Plattform deutlich steigt, die Kosten aber nur wenig. Für Nicht-Produktivumgebungen oder eine feste Plattform passt dagegen ein Betrag. Für die Budgetabweichung nennt die FinOps Foundation in der Capability Budgeting Referenzwerte je Reifegrad: höchstens 20 Prozent Abweichung vom Ist bei Crawl, 15 Prozent bei Walk und 12 Prozent bei Run (FinOps-Reifegrade). Das sind Orientierungswerte, keine Vorgaben; nach der Capability Unit Economics können sich die erwarteten Zielwerte je Scope unterscheiden, auch wenn die Kennzahl dieselbe ist.
Ein Quartal ist ein brauchbarer Zeitraum für ein Ziel, gelesen wird monatlich (Berichtsrhythmus). Gemessen wird auf abgeschlossenen Monaten, weil sich vorläufige Daten noch ändern (Aktualität, Nachberechnung und Finalisierung). Geprüft wird von der nächsthöheren Ebene: Der Kostenverantwortliche berichtet, Geschäftsführung oder Finance bewerten.
OKRs als ein Rahmen
Objectives and Key Results (OKRs) bilden die Unterscheidung zwischen Ziel und Zielwert ab: Das Objective beschreibt die Richtung in Worten, etwa „Der Bestelldienst wächst, ohne dass seine Kosten mitwachsen“, die Key Results machen sie messbar, etwa Stückkosten je Bestellung, Zuordnungsgrad des Dienstes und belegte Einsparungen im Quartal. Die FinOps Foundation nennt in der Capability Executive Strategy Alignment Produktteam-OKRs und Leistungsbeurteilungen als Orte, an denen Kosteneffizienz verankert werden kann, mit der Verantwortung bei Engineering und Produkt. Microsoft verlangt im Kostenpfeiler seines Well-Architected Framework ebenso, dass jedes Team an Erwartungen gemessen wird, die zu seinen eigenen Zielen passen. Wo Teams keine Rohdaten zu Kosten sehen sollen, schlägt Google vor, Summen weiterzugeben, etwa je Umgebung oder Funktion, oder relative Größen wie die durchschnittlichen Kosten je Transaktion oder Nutzer.
Was es für Ihre Kosten bedeutet
Ziele steuern die Entscheidungen, die Kostenverantwortliche jeden Monat treffen: welche Empfehlung sie annehmen, ob ein Dienst skaliert, ob eine Ausnahme beantragt wird. Ein relatives Ziel lässt einen erfolgreichen Dienst wachsen; ein absolutes zwingt ihn zu einer Kürzung oder zu einer Ausnahme. Jedes Ziel setzt außerdem Daten voraus. Stückkosten brauchen eine Geschäftsgröße neben den Kostendaten (Unit Economics und Stückkosten), belegte Einsparungen einen Ausgangswert je Maßnahme (von der geschätzten zur belegten Einsparung), der Zuordnungsgrad eine Regel für den Rest. Eine Kennzahl, für die diese Daten fehlen, taugt als Beobachtung, nicht als Ziel.
Wo es schiefgeht
- Fester Betrag für einen wachsenden Dienst. Symptom: Das Team verfehlt sein Kostenziel, obwohl die Stückkosten sinken. Ursache: Das Ziel kennt den Treiber nicht.
- Geschätzte Einsparungen gezählt. Symptom: Das Einsparziel ist erreicht, die Rechnung unverändert. Ursache: Das Ziel misst angenommene statt belegter Einsparungen.
- Geschönter Zuordnungsgrad. Symptom: Die Quote springt nach oben, ohne dass Tags oder Regeln dazukamen. Ursache: Der Rest wurde per Schlüssel verteilt und als zugeordnet gezählt.
- Ausgangswert im Nachhinein. Symptom: Jede Maßnahme sieht erfolgreich aus. Ursache: Die Basis wurde nach der Maßnahme gewählt, nicht vorher dokumentiert.
- Zwei Kostenbasen. Symptom: Das Ziel wird genau in dem Monat verfehlt, in dem ein Commitment im Voraus bezahlt wurde. Ursache: Geplant wurde mit amortisierten, gemessen wird mit berechneten Kosten.
- Unterschreitung bestraft. Symptom: Die Ausgaben steigen kurz vor Periodenende. Ursache: Nicht genutztes Budget kürzt das Budget der nächsten Periode.
Beispiel
Ein Dienst hat im Ausgangsquartal die Kosten K0 und das Volumen V0, also die Stückkosten S0 = K0 / V0. Das Ziel lautet, die Stückkosten bis zum Ende des Zielquartals um den Anteil r zu senken: S1 ≤ S0 × (1 − r). Wächst das Volumen um den Faktor g, darf der Dienst K1 ≤ K0 × g × (1 − r) kosten. Ein absolutes Ziel, das die Kosten um denselben Anteil senkt, K1 ≤ K0 × (1 − r), verlangt dagegen Stückkosten von höchstens S0 × (1 − r) / g: Je stärker das Volumen wächst, desto mehr müsste jede Einheit einsparen. Wächst das Volumen nicht (g = 1), sagen beide Ziele dasselbe, und ein Betrag ist die einfachere Form.
Quellen
Gelesen am 2026-10-16. FinOps Foundation KPIs & Benchmarking, FinOps KPIs, Budgeting, Unit Economics und Executive Strategy Alignment (CC BY 4.0); AWS COST02-BP02 Ziele und Zielwerte festlegen; Microsoft Empfehlungen für eine Kultur finanzieller Verantwortung; Google Cloud Kostenbewusstsein fördern.