TBM-gestützte Transformation On-Prem
Teil 2: Ausgangssituation analysieren – Transparenz schaffen trotz unvollständiger Daten
In der ersten Phase einer TBM-gestützten Transformation steht die Erkenntnis im Vordergrund: Kosten entstehen, aber sie sind oft nicht oder nur teilweise zuordenbar. In vielen Rechenzentren und IT-Abteilungen fehlt es an durchgängiger Transparenz, weil historische Prozesse, gewachsene Strukturen und unvollständige Daten die direkte Zuordnung zu Services oder Verbrauchern verhindern. Und trotzdem: Der Weg in Richtung Serviceorientierung beginnt genau hier – mit einer pragmatischen Analyse der vorhandenen Daten.
Der Realitätscheck: Was ist wirklich da?
Oft liegen nur fragmentierte Informationen über die IT-Kosten vor. Typische Herausforderungen:
- Betriebskosten werden als Sammelbuchung in der GuV erfasst.
- Technische Inventare (z. B. in der CMDB) enthalten veraltete oder unvollständige Einträge.
- Eine Trennung zwischen Investitions- und Betriebskosten fehlt.
- IT-Services werden noch nicht als solche verstanden oder benannt.
Ziel dieser Phase: Eine belastbare Datengrundlage schaffen – auch wenn sie unvollständig ist.
Erhebung: Bottom-up und Top-down kombinieren
Eine rein technische Sicht reicht nicht aus. TBM setzt auf die Kombination von:
- Bottom-up-Ansätzen: Ausgehend von vorhandenen Infrastrukturdaten (z. B. Server, Storage, Netz) werden erste Kostenträger abgeleitet.
- Top-down-Ansätzen: Aus Gesamtkosten (z. B. aus SAP FI/CO oder einer Kostenstellenrechnung) werden die zentralen IT-Tower oder Cost Pools definiert.
Diese Perspektiven müssen zusammengeführt werden – auch wenn es anfangs nur grob möglich ist.
Hilfreiche Prinzipien bei Datenlücken
Wenn Daten fehlen, hilft ein strukturiertes Vorgehen:
- Kostenallokation über Schätzungen: Wenn genaue Daten fehlen, können Interviews mit Betriebsteams oder Erfahrungswerte genutzt werden, um Zuordnungen zu treffen.
- Technisches Mapping über CMDB: Auch wenn die Daten nicht vollständig sind, liefern sie oft einen Startpunkt für eine Grobstruktur.
- “Service-Vermutung”: Technische Komponenten lassen sich häufig zu vermuteten Services aggregieren (z. B. mehrere Windows-VMs = ein Applikations-Stack für einen Fachbereich).
- Clusterbildung: Mehrere ähnliche Systeme können vorerst als ein Cluster betrachtet und gemeinsam bewertet werden.
Quick Wins durch Visualisierung
Ein sehr wirksamer Hebel in dieser Phase ist das Visualisieren der vorhandenen Transparenzlücken:
- Welche Kosten sind bereits eindeutig einem technischen Service zugeordnet?
- Welche Systeme verursachen hohe Kosten, ohne bekannten Zweck?
- Welche Services sind besonders teuer im Verhältnis zu ihrer Nutzeranzahl?
Solche Visualisierungen schaffen Aufmerksamkeit und sind der erste Schritt in Richtung Governance.
Ergebnis: Erste TBM-Kostenzuordnung trotz Datenlücken
Am Ende dieser Phase liegt keine perfekte Transparenz vor – aber ein belastbarer Startpunkt:
- Erste IT-Tower wie Compute, Storage, Network, Facilities oder Apps sind definiert.
- Ein initiales Mapping der Kosten auf Cost Pools und ggf. Applikationsgruppen existiert.
- Es wird klar, wo dringend Handlungsbedarf besteht (z. B. Schatten-IT oder verwaiste Systeme).
Fazit: Es geht nicht um Perfektion, sondern um Bewegung
Die Ausgangssituation ist nie ideal. Wichtig ist, überhaupt zu starten und ein kontinuierliches Modell zu etablieren. TBM erlaubt genau das – mit einem iterativen Ansatz, der sich über die nächsten Phasen hinweg verfeinert. Die Transparenz wächst mit jeder Iteration.
Im nächsten Teil der Serie geht es darum, wie du aus dieser ersten Kostenstruktur konkrete Services ableitest und mit Nutzenaspekten verknüpfst.
