Zwischen FinOps und TBM fehlt oft nur ein gemeinsames Servicemodell

FinOps ist eine Betriebs- und Entscheidungsdisziplin für variable Technologiekosten, vor allem aus Cloud, SaaS und zunehmend auch aus Rechenzentrum und KI. Technology Business Management, kurz TBM, ist ein Management- und Steuerungsrahmen, der Technologieausgaben mit Services, Verbrauchern und Geschäftswert verbindet. Relevant sind beide Ansätze deshalb, weil viele Unternehmen zwar immer mehr Technologie einkaufen und verbrauchen, aber Kosten, Nutzung und Nutzen noch immer in getrennten Sprachen berichten.

In der Praxis sieht das Problem fast immer ähnlich aus: Das FinOps-Team kann sehr genau zeigen, welche Cloud-Services gestern teurer geworden sind, welche Workloads aus dem Ruder laufen oder wo Reserved-Commitments schlecht genutzt werden. Das TBM- oder IT-Finance-Umfeld wiederum kann erklären, wie Gesamtbudget, Kostenstellen, Serviceportfolios und Business-Verantwortung zusammenhängen. Trotzdem enden beide Sichtweisen oft in derselben Sackgasse: Die eine ist zu granular für strategische Steuerung, die andere zu abstrakt für tägliche Entscheidungen.

Genau hier wird ein gemeinsames Servicemodell wichtig. Denn ohne dieses Zwischenstück reden alle Beteiligten zwar über Kosten, aber nicht über denselben Gegenstand. Die Cloud-Abrechnung kennt Accounts, Subscriptions, Regionen und Services. Das Controlling kennt Hauptbuchkonten, Abschreibungen, Verträge und Kostenstellen. Produkt- und Plattformteams sprechen über Plattformen, Kundenerlebnisse, interne Produkte oder Betriebsservices. Solange diese Ebenen nicht sauber verbunden sind, bleiben Reports zwar formal richtig, aber operativ schwach.

FinOps und TBM verfolgen kein Konkurrenzmodell

Der gemeinsame Leitfaden von FinOps Foundation und TBM-Community macht den Punkt sehr klar: FinOps und TBM sind komplementär, nicht austauschbar. FinOps arbeitet eher bottom-up und mit hoher Taktung. Es verarbeitet feingranulare Nutzungs- und Kostendaten, damit Teams in kurzen Zyklen reagieren können. TBM denkt stärker top-down, ordnet den gesamten Technologieaufwand ein und verbindet ihn mit Services, Konsumenten und Geschäftswert.

Diese Unterscheidung ist nicht nur methodisch interessant, sondern operativ entscheidend. Wer versucht, TBM mit reinen Cloud-Dashboards zu ersetzen, verliert den Blick auf den voll belasteten Service mit Personal, Plattform, Vertrags- und Gemeinkosten. Wer umgekehrt glaubt, ein monatlicher IT-Finance-Bericht reiche zur Cloud-Steuerung aus, sieht die Dynamik verbrauchsabhängiger Modelle zu spät. Die eigentliche Reife entsteht deshalb nicht durch die Entscheidung für eines der beiden Lager, sondern durch ihre saubere Kopplung.

Der eigentliche Bruch verläuft zwischen Rechnungssicht und Servicesicht

Viele Organisationen haben heute mehr Kostentransparenz als vor drei Jahren und trotzdem zu wenig Steuerungsfähigkeit. Der Grund ist banal: Transparenz auf Rechnungszeilenebene ist noch keine Servicesicht. Ein CFO sieht vielleicht steigende Plattformkosten. Ein Engineering-Leiter sieht höhere Kubernetes-, Datenbank- oder Inference-Kosten. Ein Service-Owner wiederum muss wissen, welche internen oder externen Leistungen dadurch teurer werden und welche Entscheidungen überhaupt realistisch sind.

Wenn diese Übersetzung fehlt, entstehen typische Fehlmuster. Plattformen werden pauschal als Overhead gebucht. Produktteams bekommen nur Cloud-Deltas, aber keinen belastbaren Anteil an gemeinsam genutzten Plattformdiensten. Rechenzentrumskosten laufen in einem separaten Modell, sodass Vergleiche zwischen On-Prem-, SaaS- und Cloud-Varianten schief werden. Und AI-Ausgaben tauchen als Sonderfall auf, obwohl sie eigentlich ebenfalls an Services, Konsumenten und Nachfrage gekoppelt werden müssten.

Der TBM Council beschreibt genau für diese Lücke eine standardisierte Sprache über Kosten, Ressourcen, Lösungen und Consumer. Das ist für IT-Management wichtiger, als es zunächst klingt. Denn erst diese Struktur erlaubt es, eine technische Ressource nicht nur als Rechnungsposten, sondern als Bestandteil eines geschäftsrelevanten Servicebildes zu führen.

Warum FOCUS für die Brücke wichtiger wird

Die FinOps Open Cost & Usage Specification, kurz FOCUS, adressiert ein anderes, aber eng verwandtes Problem: Unterschiedliche Anbieter liefern Kosten- und Nutzungsdaten in unterschiedlichen Formaten, Begriffen und Granularitäten. Wer Cloud, SaaS und perspektivisch weitere Technologiebereiche gemeinsam auswerten will, muss diese Daten erst vereinheitlichen. Genau darin liegt der operative Wert von FOCUS.

Besonders interessant ist dabei, dass die FinOps Foundation das Thema inzwischen ausdrücklich über Public Cloud hinaus zieht. Im Papier zu FinOps for Data Center wird beschrieben, wie sich selbst Rechenzentrumskosten in konsumierbare Einheiten wie vCPU-Stunden oder Storage-GB-Monate übersetzen lassen und damit in dieselbe Entscheidungssprache wie Cloud-Kosten rücken. Für hybride IT-Organisationen ist das ein großer Schritt. Denn damit wird es realistischer, Workload-Platzierung, Kapazitätsplanung und interne Verrechnung nicht länger in getrennten Tabellenwelten zu behandeln.

FOCUS löst allerdings nicht automatisch das Managementproblem. Die Spezifikation vereinheitlicht Daten, aber sie entscheidet nicht, wie ein Unternehmen Services definiert, Ownership vergibt oder Geschäftswert zuordnet. Genau deshalb brauchen FinOps und TBM ein gemeinsames Servicemodell zwischen Datennormalisierung und Managementsteuerung.

Ein gutes Servicemodell übersetzt Kosten in Entscheidungen

Ein belastbares Servicemodell beantwortet nicht nur die Frage, was etwas kostet. Es beantwortet auch, für wen der Service da ist, welche Leistungsbestandteile dazugehören, welche Abhängigkeiten existieren und welche Nachfrage den Verbrauch treibt. Erst dann wird aus einem Kostenanstieg eine steuerbare Managementfrage.

Praktisch heißt das: Unternehmen sollten nicht bei Provider- oder Rechnungskategorien stehenbleiben. Sie brauchen eine Zwischenebene aus internen Plattformservices, Produktservices oder Business-fähigen Leistungsbündeln. Diese Ebene muss stabil genug sein, um mit Finance und Führung zu sprechen, aber konkret genug, um Engineering- und Betriebsentscheidungen auszulösen.

Genau dort treffen sich FinOps und TBM produktiv. FinOps liefert die zeitnahe Verbrauchs- und Effizienzsicht. TBM liefert die Portfolio-, Budget- und Wertsicht. Das Servicemodell verbindet beides so, dass aus „mehr Datenbankkosten in Region X“ die Managementfrage wird, ob ein Kundenservice falsch skaliert, ein internes Plattformprodukt unterpreist, eine Architektur ineffizient oder ein Geschäftsmodell besonders erfolgreich ist.

AI, Daten und Plattformen verschärfen die Lücke

Die neueren TBM-Taxonomie-Weiterentwicklungen zeigen bereits, wohin die Reise geht: Cloud-Services, Daten und AI-Modelle brauchen eigene Sichtbarkeit, weil ihre Kostenstrukturen anders wirken als klassische Infrastruktur. Gerade Generative AI bringt variable Inference-Kosten, Modellnutzung, Datenzugriffe und Plattformverbrauch in einer Form zusammen, die in alten IT-Budgetmodellen schlecht sichtbar ist.

Wenn Unternehmen diese Aufwände nur als neues Cloud-Unterkonto behandeln, fehlt schnell der Zusammenhang zwischen Experiment, Produktfunktion, Nutzergruppe und Wertbeitrag. Wenn sie sie nur als Strategiethema behandeln, fehlt die Fähigkeit zur zeitnahen Korrektur. Auch hier hilft kein zusätzlicher Einzelreport, sondern wieder nur die Verbindung aus granularen Verbrauchsdaten, normalisierten Datenmodellen und einer stabilen Service- beziehungsweise Lösungslogik.

Worauf IT-Management jetzt konkret achten sollte

• FinOps und TBM nicht organisatorisch gegeneinander stellen: Unterschiedliche Taktungen sind normal; widersprüchliche Begriffe sind das eigentliche Problem.
• Ein gemeinsames Servicemodell definieren: Zwischen Providerdaten und CFO-Reporting braucht es belastbare interne Services oder Lösungsbausteine.
• FOCUS dort nutzen, wo Datenquellen auseinanderlaufen: Vor allem bei Cloud, SaaS und Rechenzentrum verbessert die Normalisierung die Vergleichbarkeit deutlich.
• Hybrid- und Plattformkosten nicht separat verstecken: Gemeinsame Plattformen, Daten- und AI-Kosten müssen in derselben Logik wie andere Services sichtbar werden.
• Ownership festlegen: Jeder steuerungsrelevante Service braucht verantwortliche Rollen für Verbrauch, Preislogik und Nutzenargumentation.
• Berichte an Entscheidungen rückkoppeln: Gute Transparenz zeigt nicht nur Abweichungen, sondern macht Optionen für Priorisierung, Architektur, Nachfrage oder Verrechnung sichtbar.

Fazit

Zwischen FinOps und TBM liegt seltener ein Methodenstreit als ein Übersetzungsproblem. Solange Cloud-Kosten, Rechenzentrumsaufwände, Plattformleistungen und Business-Services nicht in einem gemeinsamen Servicemodell zusammenfinden, bleibt viel Transparenz folgenlos. Die Teams sehen dann zwar mehr Zahlen, aber noch nicht denselben Service.

Für CIOs, IT-Finance, Plattformverantwortliche und Produktbereiche ist deshalb nicht der nächste Einzeldashboard-Ausbau der wichtigste Schritt. Entscheidend ist eine gemeinsame Sprache, die normale Finanzsicht, technische Nutzungsdaten und Serviceverantwortung verbindet. Erst dann werden FinOps-Daten strategisch belastbar und TBM-Berichte operativ handlungsfähig.

Quellen

• FinOps Foundation: FinOps & TBM – Navigating Co-Existing Disciplines
• FinOps Foundation: FinOps for Data Center – Practical Cost Modeling & FOCUS Alignment
• FinOps Foundation: FinOps Open Cost & Usage Specification (FOCUS)
• TBM Council: Technology Business Management Taxonomy
• TBM Council: The CIO’s Guide to the TBM Taxonomy