Unit Economics und Stückkosten

Unit Economics setzen die Cloud-Kosten ins Verhältnis zu dem, was das Unternehmen damit hervorbringt: Kosten je Kunde, je Anfrage, je Bestellung, je gespeichertem Gigabyte oder je aktivem Nutzer. Die Gesamtrechnung sagt nur, ob die Kosten steigen; die Stückkosten sagen, ob sie schneller steigen als das Geschäft. Das ist die Zahl, mit der Engineering und Finance über denselben Sachverhalt sprechen können, und die Zahl, die entscheidet, ob eine wachsende Rechnung ein Problem ist oder ein Erfolg.

So funktioniert es

Das FinOps Framework der FinOps Foundation führt Unit Economics als eigene Capability in der Domäne Quantify Business Value. Die Capability beschreibt, wie eine Organisation ihre Technologieausgaben mit dem Wert verbindet, den diese Ausgaben schaffen. Als Beispiele nennt sie Einheiten der Ressourceneffizienz wie Kosten je gespeichertem GB, je vCPU, je Token oder je API-Aufruf, und geschäftliche Einheiten wie Kosten je Mandant, je Transaktion oder Kosten des Bedienens. In ihrem Reifemodell beginnen Teams mit technischen, direkt variablen Kennzahlen und kommen erst später zu voll beladenen Kosten und zu Einheiten, die Architektur- und Preisentscheidungen prägen.

Jede Stückkostenzahl hat genau zwei Eingaben. Die erste ist der zugeordnete Kostenanteil: der Teil der Rechnung, der der gemessenen Einheit zuzurechnen ist, über Konto, Tag oder Zuordnungsregel. Die zweite ist eine gezählte Größe aus dem Geschäft: Kunden, Anfragen, Bestellungen, gespeicherte Gigabyte, aktive Nutzer. Stückkosten sind der Quotient aus beiden, und sie sind nur dann eine Aussage, wenn beide Eingaben denselben Zeitraum und denselben Umfang haben: die Kosten des Monats durch die Anfragen desselben Monats, die Kosten eines Produkts durch die Nutzer desselben Produkts. Ein Zähler aus der Rechnung und ein Nenner aus einem Dashboard mit anderer Zeitzone oder anderem Stichtag ergeben eine Zahl, die niemand reproduzieren kann.

Die Wahl der Einheit entscheidet, wer mit der Zahl etwas anfangen kann. Eine Einheit nah am Geschäft, Kosten je Kunde oder je Bestellung, versteht die Geschäftsführung, aber ein Engineering-Team kann sie nur mittelbar beeinflussen. Eine Einheit nah an der Technik, Kosten je Anfrage oder je Gigabyte, kann ein Team direkt bewegen, sagt dem Vertrieb aber wenig. In der Praxis braucht es meist eine von jeder Sorte, und für jede einen Verantwortlichen, der die Zählgröße liefert und ihre Definition festhält.

Für ein Softwareunternehmen ist die wichtigste Form der Stückkosten die technische Bruttomarge. Sie setzt die Cloud-Kosten, die das Bedienen der Kunden verursacht, gegen den Umsatz, den diese Kunden bringen: Kosten des Bedienens geteilt durch Umsatz ist der Anteil jedes Umsatz-Euros, den die Infrastruktur verbraucht, und der Rest ist die Marge. Dafür müssen die Kosten vorher getrennt werden in solche, die mit den Kunden wachsen (Produktion, Datenhaltung, Datentransfer), und solche, die es nicht tun (Entwicklung, Test, interne Werkzeuge). Nur die erste Gruppe gehört in die Marge. Wie sie in der Finanzbuchhaltung ausgewiesen wird, ist eine Frage an den Steuerberater oder Wirtschaftsprüfer; die Cloud-Daten liefern nur den Zähler.

Was es für Ihre Kosten bedeutet

Stückkosten verhalten sich anders als die Gesamtrechnung, und drei Effekte muss man kennen, bevor man eine Zahl liest.

Sie fallen mit der Skalierung. Ein Teil der Kosten ist fix oder wächst in Stufen: eine Datenbank, ein Cluster mit Mindestgröße, ein Load Balancer. Verteilt auf mehr Einheiten sinken die Stückkosten, ohne dass jemand etwas optimiert hat; bei schrumpfender Nutzung steigen sie, ohne dass jemand etwas falsch gemacht hat. Der Trend ist deshalb immer gegen das Volumen zu lesen, nie allein.

Sie springen mit Commitments. Reservierungen und Savings Plans werden im Voraus oder monatlich bezahlt. In den berechneten Kosten erscheint der Kauf als Spitze am Kauftag: Cost Explorer zeigt Reservierungsgebühren standardmäßig so, und die Azure-Kostenanalyse weist unter Actual cost eine vorab bezahlte Reservierung vollständig im Kaufmonat aus. Die amortisierte Sicht verteilt den Betrag auf die Laufzeit: Cost Explorer rechnet Vorab- und Monatsgebühren in einen effektiven Tagessatz um, Azure teilt den Kaufpreis durch die Tage der Laufzeit, rechnet den Tagesbetrag den Ressourcen zu, die die Reservierung genutzt haben, und weist den ungenutzten Rest als eigene Position aus. Stückkosten brauchen die amortisierte Sicht, sonst springen sie im Kaufmonat nach oben und liegen danach unter dem wahren Wert. FOCUS trennt die beiden Sichten als BilledCost und EffectiveCost.

Geteilte Kosten müssen vorher verteilt sein. Netzwerk, Monitoring, Support, ein Kubernetes-Cluster mit mehreren Mandanten: Diese geteilten Kosten gehören keiner Einheit allein. Bleiben sie unverteilt, sind die Stückkosten zu niedrig und werden mit jeder neuen geteilten Komponente etwas falscher. Die Regel, nach der sie verteilt werden, gleichmäßig, proportional zum direkten Anteil oder nach einer gemessenen Größe, ist Teil der Definition der Stückkosten und wird mit ihr festgehalten.

Im Kostenbericht ist eine Stückkostenzahl deshalb nie eine Zelle, sondern eine Reihe: Zähler, Nenner, Zuordnungsregel und der Verlauf über mindestens ein Jahr. Erst die Reihe zeigt, ob die Kosten je Einheit mit dem Wachstum fallen, wie es Skaleneffekte erwarten lassen, oder ob sie steigen, weil eine Architekturentscheidung je Kunde mehr kostet als die vorherige.

Wo es schiefgeht

• Eine Zählgröße ohne Verantwortlichen. Die Kosten liefert die Rechnung jeden Monat; die Anzahl aktiver Nutzer oder Bestellungen liefert jemand aus dem Produkt, und wenn niemand dafür benannt ist, bricht die Reihe nach zwei Monaten ab.
• Kosten und Zählgröße aus verschiedenen Zeiträumen. Die Rechnung des Kalendermonats durch die Anfragen eines gleitenden 30-Tage-Fensters, oder Kosten in UTC durch Ereignisse in Ortszeit: Die Zahl sieht plausibel aus und ist in jedem Monat anders falsch.
• Berechnete und effektive Kosten gemischt. Der Zähler kommt in einem Monat aus der Rechnung und im nächsten aus der amortisierten Sicht; der Sprung im Kaufmonat einer Reservierung wird dann als Kostenexplosion gelesen.
• Eine Einheit, die Engineering nicht beeinflussen kann. Kosten je Umsatz-Euro hängen am Preis, nicht an der Architektur; ein Team, das daran gemessen wird, kann nichts tun. Die technische Einheit daneben ist die, an der es arbeiten kann.
• Die Zahl ohne den Trend. Ein Wert für diesen Monat sagt nichts, solange niemand weiß, was er vor sechs Monaten war und wie das Volumen sich inzwischen verändert hat.

Quellen

Gelesen am 2026-10-15. FinOps Foundation Capability Unit Economics und FinOps Framework (CC BY 4.0); AWS Erweiterte Optionen in Cost Explorer: amortisierte Kosten; Microsoft Amortisierte Kosten von Reservierungen und Savings Plans anzeigen; FOCUS Spaltenbibliothek.