KPIs richtig machen
Einen KPI setzt man nicht auf, weil man etwas messen kann, sondern weil man Sichtbarkeit für etwas Bestimmtes braucht: für eine Zahl, die sich verbessern soll, oder als Wächter, der warnt, wenn eine Änderung anderswo etwas Gutes verschlechtert. Alles andere ist eine Vanity Metric. Aus diesem Zweck folgt die Form, ein Korridor mit Ziel-, Risiko- und Chancenschwelle statt einer nackten Zahl, und für den Betrieb eines Produkts genügen drei davon: Allokation, Forecast-Genauigkeit und Effizienz.
Viele Dashboards sind voll mit Zahlen, die niemand zu einer Entscheidung führt. Sie werden angezeigt, weil sie sich anzeigen lassen, doch keine von ihnen sagt, ob gerade etwas gut läuft oder ob jemand eingreifen sollte. Das ist der Kern des Problems: gemessen wird, weil es geht, nicht, weil eine bestimmte Frage beantwortet werden soll.
Vor der ersten Kennzahl lohnt sich deshalb nicht der Blick auf Formeln, sondern auf den Zweck. Was genau wollen wir sehen, warum wollen wir es sehen, und welche Entscheidung würde eine Veränderung dieser Zahl auslösen? Eine Kennzahl, die auf diese Frage keine Antwort hat, ist eine Vanity Metric, die hübsch aussieht und nichts entscheidet. Erst wenn der Zweck steht, ergibt eine Kennzahl Sinn, und erst dann lohnt es sich, über ihre Form zu reden.
Wozu ein KPI da ist
Ein KPI hat im Kern eine von zwei Rollen. In der ersten ist er ein Treiber: Es gibt eine Zahl, die besser werden soll, und der KPI macht den Fortschritt sichtbar, damit man erkennt, ob die eigenen Maßnahmen wirken. In der zweiten Rolle ist er ein Wächter. Dann geht es nicht darum, die Zahl zu verbessern, sondern darum, dass sie nicht kippt, während man woanders bewusst etwas verändert.
Gerade die Wächter-Rolle wird oft übersehen, obwohl sie im Alltag die wertvollere ist. Wer das Tempo der Auslieferung erhöht, will sicher sein, dass die Fehlerrate oder die Kosten dabei nicht heimlich davonlaufen. Wer die Kosten senkt, will merken, wenn darunter die Zuverlässigkeit leidet. Ein Wächter-KPI ist damit die Leitplanke, die eine geplante Veränderung an einer Stelle absichert, indem er an einer anderen Stelle Alarm schlägt, bevor der Schaden sichtbar wird.
Aus beiden Rollen folgt dieselbe Konsequenz: Eine Kennzahl muss nicht nur einen Wert liefern, sondern sagen können, ob dieser Wert in Ordnung ist. Ein Treiber braucht ein Ziel, auf das er zuläuft, ein Wächter eine Grenze, ab der er warnt. Eine nackte Zahl kann weder das eine noch das andere, und genau daran scheitern die meisten Dashboards.
Ein KPI ist ein Korridor
Damit eine Kennzahl treiben oder warnen kann, braucht sie einen Bereich statt eines einzelnen Punktes. Ein brauchbarer KPI besteht aus einem Zielwert, einer Risikoschwelle und einer Chancenschwelle. Der Zielwert sagt, wo man stehen will. Die Risikoschwelle ist die Grenze des Wächters, ab der man handeln muss. Die Chancenschwelle zeigt, ab wann etwas besser läuft als geplant, sodass sich ein genauerer Blick lohnt, um daraus zu lernen.
Zwei Dinge gehören zu einem brauchbaren KPI dazu. Er stützt sich auf eine deterministische Abfrage, die immer denselben Wert aus denselben Daten liefert, statt auf eine Schätzung, die jedes Mal anders ausfällt. Und er ist versioniert, weil sich Erwartungen über die Zeit ändern und man nachvollziehen können muss, welche Schwelle ab wann galt und warum. Erst damit wird aus einer Kennzahl ein Werkzeug, an dem man Entscheidungen ausrichtet, statt nur Zahlen anzuschauen.
Drei KPIs für die Cloud-Kosten
So viel zur allgemeinen Mechanik. Zweck, Treiber, Wächter und Korridor gelten für jede Kennzahl. Jetzt wird es konkret, und zwar an der Frage, bei der wir diese Mechanik am häufigsten anwenden: den Cloud-Kosten. Sie sind für ein Produktunternehmen ein laufender, beweglicher Posten, und aus der Menge möglicher Kennzahlen haben sich hier drei bewährt, die mit minimalem Aufwand den größten Einblick geben. Sie beantworten drei Fragen: Wissen wir, wofür unsere Kosten anfallen, können wir sie vorhersehen, und nutzen wir aus, was wir bereitstellen. Jede wird als Korridor gedacht, damit sie treiben oder warnen kann, statt nur eine Zahl zu zeigen.
Die erste ist die Allokation. Sie beantwortet die einfachste und zugleich unbequemste Frage, nämlich ob sich jeder Kostenposten einem Produkt, einem Dienst oder einem Bereich zuordnen lässt. In der Cloud entstehen schnell verwaiste Ressourcen, die laufen und Geld kosten, für die sich aber niemand zuständig fühlt. Der Allokations-KPI misst, welcher Anteil der Kosten eine klare Zuordnung hat. Wenn die gesamten Cloud-Kosten eines Monats bei 8.000 Euro liegen und sich davon 6.000 Euro konkreten Produkten zuordnen lassen, beträgt die Allokation 75 Prozent, während die restlichen 25 Prozent im Dunkeln bleiben. Als Korridor könnte der Zielwert bei 90 Prozent liegen und die Risikoschwelle bei 70 Prozent, unter der zu viel unzugeordnet bleibt.
Die zweite ist die Forecast-Genauigkeit. Cloud-Kosten sind nicht starr, weil sie mit der Nutzung schwanken und sich mit jedem neuen Dienst verändern, und diese Kennzahl misst, wie gut man diese Bewegung vorhersieht. Wird für ein neues Vorhaben ein zusätzlicher Aufwand von 8.000 Euro erwartet, liegen die tatsächlichen Kosten am Monatsende aber bei 7.500 Euro, dann beträgt der absolute Fehler 500 Euro. Die Genauigkeit ergibt sich, indem man diesen Fehler ins Verhältnis zur Prognose setzt und vom Ganzen abzieht, also (1 minus 500 durch 8.000) mal 100, was 93,75 Prozent entspricht. Wichtig ist, dass eine hohe Genauigkeit in beide Richtungen zählt, weil sowohl deutliches Überschreiten als auch deutliches Unterschreiten zeigt, dass man den eigenen Verbrauch noch nicht im Griff hat.
Die dritte ist die Effizienz. Die Stärke der Cloud ist ihre dynamische Skalierbarkeit, doch daraus entsteht die Frage, ob das Bereitgestellte auch ausgenutzt wird oder ob ungenutzte Kapazität still Kapital bindet. Der pragmatische Einstieg besteht darin, nicht jede Ressource exakt zu vermessen, sondern die Kosten in zwei Gruppen zu teilen: Managed Services nimmt man vorerst mit einer Effizienz von 100 Prozent an, Compute-Ressourcen mit 50 Prozent. Liegen bei 8.000 Euro Gesamtkosten etwa 3.000 Euro auf Managed Services und 5.000 Euro auf Compute, ergeben sich effiziente Kosten von 3.000 plus der Hälfte von 5.000, also 5.500 Euro, was rund 69 Prozent entspricht. Diese Startwerte sind absichtlich grob und wahrscheinlich nicht korrekt, denn ihr Zweck ist, den Status quo herauszufordern und die Teams einzuladen, genauere Werte zu liefern.
Der pragmatische Einstieg
Diese drei Kennzahlen lassen sich in wenigen Wochen auf ein brauchbares Niveau bringen, ohne dass man auf ein perfektes System wartet. Für die Allokation erfasst man die Cloud-Kosten und legt fest, welches Produkt oder welcher Bereich für welche Konten und Ressourcen verantwortlich ist. Für den Forecast genügt zu Beginn eine wöchentliche Schätzung, die man mit dem realen Verlauf abgleicht. Für die Effizienz setzt man die groben Startannahmen und verfeinert sie nach und nach.
Wichtig ist die Reihenfolge und die Haltung dahinter. Man beginnt bewusst mit einem "gut genug"-Zustand und baut darauf auf, statt sich in Feinheiten wie der Wahl zwischen einzelnen Instanztypen zu verlieren, bevor die Grundstruktur steht. Sobald die drei KPIs als Korridore hinterlegt sind, tragen sie sich am besten in einer deterministischen Abfrage, die den Wert reproduzierbar liefert, sodass aus der wiederkehrenden Zahlenschau eine echte Steuerung wird.
Für den Ort, an dem diese Korridore zusammenlaufen, gibt es mehrere Möglichkeiten, von denen sich zwei besonders lohnen anzuschauen. Die erste ist ein fertiges Werkzeug: Wir nutzen selbst unser Startup Business Cockpit, in dem man einen Indikator einträgt, während Berechnung und Grafik automatisch entstehen, und in dem man festlegt, welche Kennzahl allen Mitarbeitenden in welchem Detailgrad gezeigt wird, sodass der Zielkorridor für die sichtbar bleibt, die ihn brauchen, ohne dass jede Zahl für jeden offenliegt. Die zweite ist der Eigenbau über eine abfragbare Datenbasis, die ein Sprachmodell in natürlicher Sprache befragt, wie wir ihn im Artikel Mit den eigenen Zahlen reden beschreiben. Beide führen zum selben Ziel, nämlich einem Korridor, der reproduzierbar berechnet und passend sichtbar ist.
Was das für dich heißt
Eine Kennzahl wird nicht dadurch nützlich, dass sie existiert, sondern dadurch, dass sie einem klaren Zweck dient: etwas sichtbar zu machen, das sich verändern soll, oder etwas abzusichern, das gut bleiben muss. Aus diesem Zweck folgt die Form, nämlich ein Korridor mit Ziel, Risiko und Chance, der aus einer verlässlichen Abfrage kommt. Wer ein Produkt betreibt, braucht dafür keinen KPI-Zoo, sondern wenige Kennzahlen, die treiben oder warnen. Ob es dabei um die ersten Kennzahlen geht oder darum, ein bestehendes Reporting endlich steuerungstauglich zu machen, wir ordnen das gerne gemeinsam mit dir ein.
Häufige Fragen
Was ist ein KPI in diesem Sinn?
Kein einzelner Zielwert, sondern ein Korridor: ein Zielwert plus eine Risiko- und eine Chancenschwelle. Erst dieser Bereich macht aus einer Zahl eine Aussage, an der man Entscheidungen ausrichten kann, sei es als Treiber oder als Wächter.
Wozu überhaupt einen KPI aufsetzen?
Weil man Sichtbarkeit für etwas Bestimmtes braucht: für eine Zahl, die sich verbessern soll, oder als Wächter, der warnt, wenn eine Änderung anderswo etwas Gutes verschlechtert. Misst man ohne diese Absicht, entsteht nur eine Vanity Metric, die hübsch aussieht und nichts entscheidet.
Warum nur drei KPIs?
Weil sich für jede Situation eine Metrik erfinden lässt und der KPI-Zoo genau die Steuerung erschlägt, die er ermöglichen soll. Allokation, Forecast-Genauigkeit und Effizienz beantworten mit minimalem Aufwand die entscheidenden Fragen: Wissen wir, wofür wir zahlen, können wir es vorhersehen, und nutzen wir aus, was wir bereitstellen.
Warum eine deterministische Abfrage statt eines Dashboards?
Weil ein KPI reproduzierbar sein muss: Dieselben Daten müssen immer denselben Wert ergeben, sonst diskutiert man über die Zahl statt über die Entscheidung. Eine deterministische Abfrage, versioniert und nachvollziehbar, liefert genau das, während eine isolierte Dashboard-Kachel nur zeigt, ohne einzuordnen.
Ähnliche Themen
FinOps ist kein Tool-Problem
Einer der hartnäckigsten Mythen rund um Cloud-Kosten lautet, FinOps sei im Kern eine Tool-Frage. Ist es nicht. Fast immer laufen ausufernde Kosten auf denselben Grund hinaus, weil niemand vorher festgelegt hat, wie viel ein Produkt kosten darf. Deshalb löst kein Werkzeug das Problem für sich, sondern erst eine klare Erwartung und eine gemeinsame Datenbasis, an der Kosten, Betrieb und Organisation zusammenlaufen.
Weiterlesen →Was AWS Support wirklich kostet
Support-Kosten sind bei AWS keine feste Gebühr, sondern ein Prozentsatz des Verbrauchs, der still mitwächst, sobald die Rechnung wächst. Mit dem Umbau der Support-Pläne Ende 2025 hat sich diese Rechnung verschoben, weil Business Support+ den alten Business Support ablöst und das Enterprise-Minimum von 15.000 auf 5.000 US-Dollar fällt. Das macht die Frage, welcher Plan zu welcher Konten-Struktur passt, neu interessant, und mit dem Rechner im Artikel lässt sie sich für die eigenen Zahlen durchspielen.
Weiterlesen →