Der Abschalttermin gehört schon in die erste Portfolioentscheidung

Neue IT-Dienste bekommen fast immer einen Starttermin. Ein Ende wird dagegen oft erst gesucht, wenn die Kosten schon laufen, Zuständigkeiten doppelt sind oder niemand mehr sicher sagen kann, wofür der Dienst noch gebraucht wird.

Für ITSM- und IT-Management-Generalisten ist das kein abstraktes Portfolio-Thema. Jeder neue Dienst bindet Betrieb, Support, Sicherheit, Dokumentation, Monitoring, Verträge und Budget. Wenn der Abschalttermin erst nach dem Go-live diskutiert wird, entsteht ein Portfolio, das zwar wächst, aber kaum sauber ausmistet.

Portfolio Management soll nach ITIL 4 helfen, Investitionen, Risiken und Nutzen über mehrere Vorhaben hinweg zu steuern. Es geht nicht nur darum, neue Projekte zu priorisieren. Es geht auch darum, alte, doppelte oder überholte Leistungen aus dem aktiven Betrieb herauszuführen. Genau deshalb gehört die Frage nach dem Ende in die erste Entscheidung, nicht in ein spätes Aufräumprojekt.

Der Go-live ist nur die halbe Portfolioentscheidung

Ein neuer Service wirkt beim Start meistens logisch. Ein Fachbereich braucht eine Lösung, ein Tool ersetzt eine manuelle Arbeit, eine Cloud-Ressource beschleunigt ein Projekt oder ein Pilot soll eine Idee beweisen. Der Business Case beschreibt dann Nutzen, Aufwand und Startpfad. Was häufig fehlt, ist die Bedingung, unter der der Dienst wieder verschwindet.

Diese Lücke ist praktisch relevant. Ohne Endkriterium bleibt ein Pilot als Dauerlösung liegen. Ein altes Tool läuft neben dem neuen weiter, weil noch ein Fachbereich daran hängt. Eine Datenbank bleibt aktiv, weil niemand die letzte Abhängigkeit nachweist. Ein Vertrag verlängert sich, weil die Kündigungsfrist nicht in die technische Roadmap passt. So entstehen stille Kosten, obwohl keine neue Entscheidung getroffen wurde.

Abschalten braucht früher Verantwortung

Ein Abschalttermin bedeutet nicht, dass ein Dienst beliebig kurz leben soll. Er bedeutet, dass das Portfolio von Anfang an weiß, wer die Lebensdauer prüft, welche Bedingungen gelten und wann erneut entschieden wird. Das kann ein fixes Datum sein, ein Review nach sechs Monaten, ein Nutzungswert, ein Kostenlimit oder die Bedingung, dass ein Altverfahren erfolgreich abgelöst wurde.

Wichtig ist die Verantwortung. Wer darf sagen, dass ein Dienst weiterläuft? Wer bestätigt, dass er ersetzt wurde? Wer informiert Nutzer, Service Desk und Provider? Wer trägt das Risiko, wenn ein Dienst zwar technisch noch funktioniert, aber fachlich keinen klaren Zweck mehr erfüllt? Ohne diese Rollen wird Abschalten zur Nebenaufgabe, die niemand priorisiert.

Kosten entstehen auch ohne neue Rechnung

Cloud-Plattformen machen laufende Kosten besonders sichtbar, aber das Grundproblem betrifft nicht nur Cloud. Google beschreibt Cost Optimization als dauerhafte Disziplin aus Messung, Steuerung und Verbesserung. Microsoft verankert Kostensteuerung ebenfalls als Teil von Governance. Für den ITSM-Alltag heißt das, Kosten nicht erst über Monatsberichte zu suchen, sondern schon im Portfolio-Design zu begrenzen.

Ein Dienst kostet mehr als seine Lizenz oder Infrastruktur. Er braucht Berechtigungen, Monitoring, Sicherheitsprüfungen, Backups, Dokumentation, Supportwissen, Release-Fenster und Eskalationskontakte. Wenn ein Service kaum genutzt wird, aber all diese Betriebspflichten weiterlaufen, wird er zum stillen Portfolio-Ballast. Der Abschalttermin macht diese Belastung sichtbar, bevor sie selbstverständlich wirkt.

Der Service Desk merkt Altlasten oft zuerst

Atlassian beschreibt IT Asset Management als Überblick über IT-Ressourcen, ihren Lebenszyklus und ihren Nutzen. In der Praxis landet fehlende Lebenszyklussteuerung oft beim Service Desk. Nutzer fragen nach einem alten Zugang, ein Fachbereich meldet eine Störung in einem kaum gepflegten Tool oder eine Fachgruppe weiß nicht mehr, ob ein Altsystem noch produktiv ist.

Solche Fälle sind Warnsignale. Wenn der Service Desk erst im Ticket klären muss, ob ein Dienst überhaupt noch strategisch gewollt ist, fehlt dem Portfolio eine klare Entscheidung. Ein guter Abschaltpfad nimmt diese Unsicherheit heraus. Er dokumentiert Nutzergruppen, Abhängigkeiten, Ersatzweg, Kommunikationsfrist und letzten Betriebstag.

Ein einfacher Prüfrahmen reicht oft aus

Für neue Dienste kann eine kurze Portfoliofrage viel verhindern. Welche bestehende Lösung wird ersetzt? Welcher Nutzen muss bis zum Review sichtbar sein? Welche Kosten dürfen bis dahin entstehen? Wer ist Service Owner? Welche Betriebsdaten zeigen Nutzung und Wert? Was passiert, wenn der Nutzen ausbleibt? Welche Kommunikation braucht der Service Desk vor dem Abschalten?

Diese Fragen gehören nicht in ein separates Aufräumdokument, sondern in die erste Freigabe. Dadurch wird der Go-live nicht gebremst, sondern vollständiger. Das Team startet mit klarerem Zielbild, und der Betrieb weiß, wann ein Dienst überprüft, verlängert, ersetzt oder beendet wird.

Portfoliohygiene ist ein Betriebsrisiko

Ein unaufgeräumtes Portfolio ist nicht nur teuer. Es macht Zuständigkeiten unscharf, erschwert Sicherheitsprüfungen und verlangsamt Änderungen. Je mehr Dienste ohne klares Ende existieren, desto häufiger müssen Teams vor jeder Änderung fragen, ob ein System noch relevant ist, wer es verantwortet und welche Abhängigkeit dahintersteht.

Der Abschalttermin ist deshalb keine pessimistische Fußnote zum Projektstart. Er ist ein Schutzmechanismus für Budget, Transparenz und Betriebsfähigkeit. Wer das Ende früh mitentscheidet, verhindert nicht Innovation. Er sorgt dafür, dass neue Dienste Platz schaffen, statt dauerhaft zusätzlichen Schatten im Portfolio zu werfen.

Quellen und Einordnung: AXELOS zu ITIL 4 Portfolio Management, Google Cloud Architecture Framework zu Cost Optimization, Microsoft Cloud Adoption Framework zu Governance und Kostensteuerung, Atlassian zu IT Asset Management. Stand der Quellenprüfung: 19.07.2026. Bildquelle: Pexels, Foto-ID 590022, C00 Lizenz.