IT-Kostensteuerung braucht ein gemeinsames Kostenmodell

In vielen Unternehmen ist IT-Kostensteuerung organisatorisch verteilt. Cloud-Kosten liegen häufig nahe am Engineering oder an Plattformteams. SaaS-Verträge werden von Fachbereichen, Einkauf oder zentralem Vendor Management verantwortet. Rechenzentrum, Netzwerk und Workplace liegen in der klassischen Infrastruktur. Datenplattformen, KI-Services und PaaS-Angebote kommen als weitere Kostenblöcke hinzu.

Auf den ersten Blick ist diese Verteilung nachvollziehbar. Jede Einheit kennt ihren technischen oder kommerziellen Ausschnitt und kann dort Optimierungen anstoßen. In der Praxis entsteht daraus jedoch ein Steuerungsproblem: Jeder besitzt ein Stück der Wahrheit, aber niemand besitzt das Ganze. Genau an dieser Stelle scheitert IT-Kostensteuerung nicht an fehlenden Daten, sondern an fehlender Zusammenführung.

Warum Einzeloptimierung nicht ausreicht

Cloud-Teams können Instanzen abschalten, Reservierungen prüfen oder Speicherklassen optimieren. Procurement kann SaaS-Verträge nachverhandeln. Infrastruktur kann Kapazitäten im Rechenzentrum konsolidieren. All das ist sinnvoll, aber es beantwortet nicht die entscheidende Managementfrage: Welche Kosten gehören zu welchem Produkt, welchem Service oder welchem Geschäftsprozess?

Ohne diese Sicht bleibt IT-Kostensteuerung fragmentiert. Ein Fachbereich sieht seine Lizenzrechnung, aber nicht die zugrunde liegenden Plattformkosten. Ein Produktteam sieht Cloud-Verbräuche, aber nicht die Kosten für Betrieb, Support, Security oder Datenhaltung. Der CFO sieht Kostenstellen und Sachkonten, aber nicht zwingend den wirtschaftlichen Zusammenhang zwischen Technologieeinsatz und Business Value. Der CIO wiederum sieht technische Plattformen und Liefermodelle, aber häufig keine belastbare, managementfähige Kostensicht entlang von Services.

Die Folge sind parallele Wahrheiten. Finance arbeitet mit Budgetpositionen, IT mit technischen Verbrauchsdaten, Einkauf mit Vertragsinformationen und Fachbereiche mit eigenen Business-Cases. Diese Perspektiven widersprechen sich nicht zwingend, sie sind aber oft nicht miteinander verbunden. Dadurch wird Steuerung schwierig: Wo genau entsteht Kostenwachstum? Ist es volumengetrieben, preisgetrieben, architekturbedingt oder organisatorisch verursacht? Welche Kosten sind direkt einem Produkt zuordenbar, welche sind Plattform- oder Gemeinkosten? Und wer kann sie tatsächlich beeinflussen?

FinOps und ITFM gehören zusammen

Die FinOps-Diskussion hat in vielen Unternehmen geholfen, Cloud-Kosten näher an die verursachenden Teams zu bringen. Sie hat Transparenz über Verbräuche geschaffen, Verantwortlichkeiten geschärft und technische Optimierung mit kaufmännischer Steuerung verbunden. Das ist ein wichtiger Fortschritt. Gleichzeitig greift ein reines Cloud-Kostenmanagement heute zu kurz.

Technologiekosten entstehen längst nicht mehr nur in der Public Cloud. Sie entstehen in SaaS-Portfolios, Datenplattformen, KI-Services, PaaS-Angeboten, klassischen Rechenzentren, Netzwerken, Security-Services, Lizenzmodellen und Integrationsarchitekturen. Viele Geschäftsprozesse nutzen mehrere dieser Bausteine gleichzeitig. Ein digitaler Vertriebsprozess kann beispielsweise CRM-Lizenzen, Datenintegrationen, Cloud-Ressourcen, Reporting-Tools, Schnittstellenbetrieb und Supportleistungen enthalten. Wer nur einen Teil davon betrachtet, optimiert unter Umständen an der falschen Stelle.

Deshalb ist die Verbindung von FinOps und IT Financial Management aus meiner Sicht konsequent. FinOps bringt die Nähe zu Verbrauch, Engineering und Produktteams. ITFM bringt die Struktur für Kostenmodelle, Servicekataloge, Verrechnung, Planung und Management-Reporting. Erst zusammen entsteht eine Sicht, die für CIO und CFO gleichermaßen nutzbar ist.

In der Beratungspraxis zeigt sich regelmäßig: Das Tool ist nicht der eigentliche Engpass. Werkzeuge für IT-Kostentransparenz, Reporting oder Cost Modelling können viel leisten. Sie ersetzen aber nicht die fachliche Entscheidung, wie Kosten, Mengen, Services und Verantwortlichkeiten modelliert werden sollen. Ohne diese Entscheidung bleibt auch das beste System eine weitere Datenablage.

Der IT-Servicekatalog als Steuerungsgrundlage

Der zentrale Hebel ist ein belastbarer IT-Servicekatalog. Er beschreibt nicht nur technische Leistungen, sondern bildet die Brücke zwischen IT-Produktion und kaufmännischer Steuerung. Ein guter Servicekatalog beantwortet Fragen wie: Welche Services bietet die IT an? Welche technischen Komponenten fließen in diese Services ein? Welche Mengen- oder Werttreiber erklären die Kosten? Wer konsumiert den Service? Und wer kann Nachfrage, Qualität oder Verbrauch beeinflussen?

Dabei geht es nicht um maximale Detailtiefe. Ein Servicekatalog, der jeden technischen Kleinstbestandteil abbildet, wird schnell unsteuerbar. Entscheidend ist die richtige Granularität für Managemententscheidungen. Für manche Leistungen reicht eine Zuordnung nach Nutzern. Bei anderen sind Transaktionen, Speicher, Compute-Verbrauch, Applikationen, Schnittstellen, Tickets oder Lizenzen die besseren Treiber. Bei Plattformleistungen kann eine Kombination aus Grundlast, Verbrauch und Service-Level sinnvoll sein.

Ein Beispiel aus der Praxis: Eine SaaS-Anwendung erscheint im Kostenstellenbericht zunächst als Lizenzkostenblock. Für die Steuerung reicht das aber nicht aus. Relevant ist, welche Nutzergruppen die Anwendung einsetzen, welche Module aktiv sind, welche Integrationen betrieben werden, welche Datenmengen verarbeitet werden und ob zusätzliche Support- oder Plattformkosten entstehen. Erst dann lässt sich beurteilen, ob die Kostenentwicklung aus wachsender Nutzung, unpassenden Lizenzmodellen, redundanten Funktionen oder fehlender Governance entsteht.

Ähnlich verhält es sich bei Cloud- und Plattformkosten. Eine reine Provider-Rechnung zeigt Verbrauch, aber nicht zwangsläufig Zweck und Verantwortlichkeit. Wenn Ressourcen keinem Produkt, Service oder Projekt zugeordnet sind, entsteht zwar Transparenz über Kosten, aber keine Steuerbarkeit. Tags, Kostenstellen oder Projektcodes helfen nur dann, wenn sie in ein übergreifendes Modell eingebettet sind und konsequent gepflegt werden.

Ownership entsteht durch ein gemeinsames Modell

Kostensteuerung funktioniert nur, wenn Ownership klar ist. Ownership bedeutet dabei nicht, Kosten einfach an Fachbereiche weiterzureichen. Es bedeutet, die wirtschaftliche Verantwortung dort sichtbar zu machen, wo Entscheidungen über Nachfrage, Architektur, Service-Level und Nutzung getroffen werden.

Ein gemeinsames Kostenmodell schafft diese Grundlage. Es verbindet Finanzdaten mit technischen Verbrauchsdaten, Vertragsinformationen und Service-Strukturen. Es macht sichtbar, welche Kosten variabel oder fix sind, welche durch Nutzung beeinflusst werden können und welche als Plattform- oder Gemeinkosten bewusst getragen werden müssen. Damit verändert sich die Diskussion zwischen CFO, CIO und Fachbereichen grundlegend.

Statt über pauschale IT-Umlagen zu sprechen, kann über konkrete Services gesprochen werden. Statt Budgetabweichungen nur zu erklären, lassen sich Treiber analysieren. Statt kurzfristig Kosten zu kürzen, kann entschieden werden, welche Nachfrage, welche Architektur oder welches Service-Level wirtschaftlich sinnvoll ist. Das ist der Unterschied zwischen Reporting und Steuerung.

Für den CFO entsteht eine belastbarere Sicht auf Technologie als Wert- und Kostentreiber. Für den CIO entsteht ein Instrument, um IT-Leistungen wirtschaftlich zu erklären und Investitionsentscheidungen besser zu begründen. Für Fachbereiche wird nachvollziehbarer, welche digitalen Leistungen sie konsumieren und welche Entscheidungen Kosten auslösen.

Der praktische Einstieg

Der Einstieg muss nicht mit einem großen Transformationsprogramm beginnen. Sinnvoll ist häufig ein klar abgegrenzter Startpunkt: ein wesentlicher Service, ein relevantes Produktportfolio, ein größerer Cloud-Bereich oder ein SaaS-Cluster mit hoher Managementaufmerksamkeit. Entscheidend ist, von Beginn an die Perspektiven von Finance, IT, Einkauf und Fachbereichen zusammenzuführen.

In einem ersten Schritt werden Kostenquellen, Verträge, technische Verbräuche und bestehende Reportingstrukturen aufgenommen. Danach wird definiert, welche Services oder Business Capabilities gesteuert werden sollen und welche Kostentreiber dafür geeignet sind. Erst auf dieser Basis sollte entschieden werden, wie ein Tool, ein ITFM-System oder ein FinOps-Reporting ausgestaltet wird.

Damit wird IT-Kostentransparenz nicht zum Selbstzweck. Sie wird zu einem Steuerungsinstrument. Der Unterschied ist wesentlich: Transparenz zeigt, wo Kosten stehen. Steuerung zeigt, wer sie beeinflussen kann, warum sie entstehen und welche Entscheidung daraus folgt.

CFO und CIO brauchen dafür keine drei getrennten Wahrheiten. Sie brauchen ein gemeinsames Kostenmodell, das Cloud, SaaS, Lizenzen, Infrastruktur, Daten- und Plattformleistungen in einen nachvollziehbaren Zusammenhang bringt. Erst dann wird aus IT-Kostenmanagement eine echte Steuerung von Technology Value.