Bildquelle: Pexels | Foto: Budget Bizar | https://www.pexels.com/photo/solar-panels-installed-on-roofs-12224996/
GreenOps im Regelbetrieb: Welche 5 Kennzahlen IT-Leitungen wirklich steuern sollten
Viele Unternehmen berichten heute über Nachhaltigkeit, aber im IT-Betrieb endet das Thema oft noch bei einem groben Jahreswert für Rechenzentren oder Cloud-Nutzung. Für die operative Steuerung ist das zu wenig. Wer GreenOps ernst nimmt, braucht keine Image-Kennzahl für den Nachhaltigkeitsbericht, sondern wenige, belastbare Metriken, die im Tagesgeschäft Entscheidungen verbessern: bei Architektur, Auslastung, Kapazitätsplanung, Lieferantengesprächen und Service-Reviews.
Die gute Nachricht ist: Die Datenlage wird besser. Google Cloud stellt Emissionsdaten für abgedeckte Dienste auf Ebene des Billing Accounts bereit und unterscheidet zwischen marktbasierter und standortbasierter Betrachtung. AWS zeigt Emissionen nach Region und Service und liefert historische Werte über mehrere Jahre. Die Green Software Foundation wiederum betont mit der SCI-Spezifikation, dass nicht bloß absolute Emissionsmengen zählen, sondern die Emissionsintensität eines Softwaresystems, also die Frage, wie effizient ein digitaler Dienst seine Wirkung erzielt. Genau daraus lässt sich ein praxistauglicher GreenOps-Ansatz für IT-Leitungen ableiten.
Entscheidend sind dabei fünf Kennzahlen, die nicht nur „grün“ klingen, sondern tatsächlich in Betriebsmodelle passen.
1. CO2e pro kritischem Service oder pro Geschäftstransaktion
Die wichtigste Abkehr vom Greenwashing ist simpel: Nicht nur den gesamten IT-Fußabdruck betrachten, sondern den Ausstoß in Relation zur erbrachten Leistung setzen. Die SCI-Spezifikation beschreibt genau dieses Denken als Rate statt als bloße Gesamtsumme. Für den Betrieb ist das extrem wertvoll. Denn ein absoluter Monatswert sagt wenig darüber aus, ob ein Service effizienter geworden ist, ob nur die Nutzung gestiegen ist oder ob eine technische Änderung echten Fortschritt gebracht hat.
In der Praxis heißt das: Ein Kundenportal, ein Service-Desk-System oder eine Integrationsplattform bekommt eine Bezugsgröße. Das kann CO2e pro 1.000 Tickets, pro Deployment, pro API-Aufruf oder pro verarbeitetem Auftrag sein. Erst damit lassen sich Architekturentscheidungen seriös vergleichen. Wenn ein neuer Workflow die Bearbeitungszeit senkt, aber die Emissionsintensität verdoppelt, ist das keine Nebensache mehr, sondern ein Steuerungssignal. Für IT-Leitungen ist diese Kennzahl deshalb die Brücke zwischen Nachhaltigkeit und Serviceverantwortung.
2. Kosten und Emissionen immer gemeinsam je Workload betrachten
Ein häufiger Fehler in der Praxis ist die Trennung von FinOps und GreenOps. Teams optimieren Kosten in einem Dashboard und Emissionen in einem anderen. Das führt regelmäßig zu widersprüchlichen Entscheidungen. Google Cloud verknüpft Emissionsdaten bereits mit Empfehlungen zur Stilllegung unbeaufsichtigter Projekte. Genau darin steckt eine wichtige operative Logik: Viele Maßnahmen verbessern Kosten und Emissionen gleichzeitig, aber nicht alle. Manche Einsparung verlagert nur Lasten, manche Nachhaltigkeitsmaßnahme erhöht Budgetbedarf.
Deshalb sollte jede größere Workload mindestens als Doppelkennzahl geführt werden: Euro pro Monat und kgCO2e pro Monat, jeweils ergänzt um eine Bezugsgröße wie Nutzer, Transaktionen oder Business Value. So wird sichtbar, welche Systeme teuer und emissionsintensiv sind, welche nur aus Kostensicht auffallen und welche scheinbar effizient sind, obwohl sie für den Geschäftswert wenig leisten. In CABs, Architekturboards und QBRs gehört diese gemeinsame Sicht auf die Standardagenda. Wer Kosten und CO2 getrennt steuert, priorisiert oft das Falsche.
3. Anteil ungenutzter oder schlecht ausgelasteter Ressourcen
GreenOps scheitert selten an fehlenden Visionen, sondern meistens an Leerlauf. Dauerhaft laufende Testumgebungen, verwaiste Projekte, überdimensionierte Instanzen, Datenkopien ohne Verwendungszweck oder Batch-Jobs zu ungünstigen Zeiten verursachen vermeidbare Kosten und vermeidbare Emissionen. Google verweist explizit auf Empfehlungen zu unbeaufsichtigten Projekten. Auch AWS macht Emissionen nach Service und Region sichtbar, was Überprovisionierung deutlich schneller erkennbar macht.
Für die Steuerung reicht deshalb keine diffuse Forderung nach „mehr Effizienz“. Sinnvoll ist eine Kennzahl wie: Anteil der Compute-, Storage- oder Projektkosten ohne nachweisbaren Servicebezug, alternativ der Anteil von Ressourcen mit dauerhaft niedriger Auslastung über einen definierten Zeitraum. Diese Kennzahl ist unangenehm, aber wirksam. Sie zwingt Teams, Besitzverhältnisse zu klären, Abschaltregeln festzuziehen und Nicht-Produktivlandschaften sauber zu terminieren. Gerade im ITSM-Umfeld ist das relevant, weil hier Service Ownership, Change-Fenster und Betriebsverantwortung bereits organisatorisch verankert sind. GreenOps braucht oft weniger neue Tools als mehr Disziplin im vorhandenen Betriebsmodell.
4. Emissionen nach Region, Plattform und Architekturklasse
Wer nur einen Gesamtwert betrachtet, übersieht die eigentlichen Hebel. AWS differenziert Emissionen nach Regionen und Services, Google zwischen marktbasierter und standortbasierter Methodik. Das ist mehr als Reporting-Feinheit. Für IT-Leitungen eröffnet es eine konkrete Steuerungsfrage: Welche Plattform- oder Regionalentscheidung verursacht bei gleichem Servicebedarf unnötige Emissionen?
Praktisch kann daraus eine Kennzahl oder zumindest ein regelmäßiger Review entstehen, der Workloads nach Region, Plattformtyp und Architekturklasse vergleicht, zum Beispiel virtuelle Maschinen versus serverlose Dienste, stark ausgelastete Plattformen versus verteilte Schattenlandschaften oder datenintensive Batch-Verarbeitung in unterschiedlichen Regionen. Nicht jede Anwendung lässt sich frei verschieben, etwa wegen Latenz, Regulierung oder Datenresidenz. Aber viele Entscheidungen werden heute immer noch historisch statt bewusst getroffen. Genau hier hilft GreenOps: nicht mit moralischem Druck, sondern mit einer nachvollziehbaren Faktenbasis für Architektur- und Sourcing-Entscheidungen.
5. Datenaktualität und Abdeckungsgrad der Messung
Die vielleicht am meisten unterschätzte Kennzahl ist die Qualität der eigenen Messung. Google weist darauf hin, dass Carbon-Footprint-Daten erst mit Verzögerung verfügbar sein können. AWS veröffentlicht neue Daten in der Regel im Folgemonat und deckt bestimmte Sichten standardisiert ab. Wer daraus tagesaktuelle Betriebssteuerung erwartet, plant am Realitätsmodell vorbei. GreenOps funktioniert nur, wenn klar ist, wie aktuell die Daten sind, welche Services überhaupt erfasst werden und wo Schätzungen oder Modellannahmen vorliegen.
IT-Leitungen sollten deshalb aktiv messen, welcher Anteil der relevanten Workloads in die Emissionssicht einfließt, mit welcher zeitlichen Verzögerung die Daten vorliegen und welche Owner für Interpretation und Maßnahmen zuständig sind. Eine formal schöne CO2-Zahl mit 60 Prozent Abdeckung ist als Steuerungsgröße gefährlicher als hilfreich. Besser ist ein ehrliches Reifegradbild: Was sehen wir sicher, was nur näherungsweise, und wo fehlen uns Lieferantendaten komplett? Die SCI-Spezifikation fordert bewusst mehr Granularität und bessere Realweltdaten. Genau daraus folgt ein Management-Auftrag an Provider, Plattformteams und Lieferanten.
Was IT-Leitungen jetzt konkret tun sollten
- Eine Kernmenge definieren: Nicht 20 Nachhaltigkeitsmetriken starten, sondern fünf Kennzahlen verbindlich in Betriebsreviews aufnehmen.
- Servicebezug erzwingen: Jede relevante Emissionszahl einem Service, Owner und Geschäftskontext zuordnen.
- FinOps und GreenOps zusammenführen: Kosten- und Emissionssicht in denselben Review-Zyklus bringen.
- Leerlauf angreifen: Abschaltfenster, Projekt-Hygiene und Rechte zum Stilllegen ungenutzter Ressourcen organisatorisch absichern.
- Datenqualität offenlegen: Abdeckung, Verzögerung und Methodik nicht verstecken, sondern als Teil der Steuerung ausweisen.
2026 wird GreenOps für viele Unternehmen vom freiwilligen Zusatzthema zum Führungsinstrument. Nicht, weil jede IT sofort perfekte Carbon-Daten hätte, sondern weil Kosten-, Effizienz- und Nachhaltigkeitsdruck zusammenlaufen. Die zentrale Frage lautet deshalb nicht mehr, ob die IT einen Emissionswert ausweisen kann. Die bessere Frage ist: Welche Entscheidungen werden durch diese Kennzahlen im Betrieb tatsächlich anders getroffen? Erst wenn darauf eine klare Antwort möglich ist, wird aus Nachhaltigkeitskommunikation echte Steuerung.
