Ausnahmen im IT-Portfolio brauchen eine neue Entscheidung

Eine Ausnahme im IT-Portfolio klingt oft harmlos: Dieses Tool bleibt noch kurz, dieser Dienst wird später abgelöst, dieses Altsystem braucht noch eine Schonfrist. Im Alltag entsteht daraus schnell eine zweite Steuerung neben der offiziellen Roadmap. Genau dort verliert die IT-Leitung den Überblick darüber, was wirklich gebraucht wird, was nur geduldet ist und welches Risiko längst einen Besitzer braucht.

IT-Portfolio meint hier die Gesamtsicht auf Anwendungen, Dienste, Plattformen und größeren Toolbestand, mit denen eine Organisation arbeitet. Für ITSM-Generalisten ist diese Sicht wichtig, weil sie Betrieb, Kosten, Sicherheit, Support und Veränderbarkeit verbindet. Eine Ausnahme ist deshalb keine Randnotiz. Sie ist eine Entscheidung mit Ablaufdatum, Verantwortlichem und überprüfbarer Begründung.

Ausnahmen brauchen mehr als eine gute Begründung

Fast jede Organisation hat gute Gründe für Ausnahmen. Ein Fachbereich hängt an einer alten Anwendung, ein Anbieterwechsel dauert länger, ein Spezialtool unterstützt einen kritischen Prozess oder eine Migration kollidiert mit anderen Vorhaben. Das Problem ist nicht die einzelne Ausnahme. Das Problem beginnt, wenn die Begründung nur in einem Ticket, einem Meetingprotokoll oder im Kopf einzelner Verantwortlicher liegt.

Dann kann niemand mehr sauber unterscheiden, ob eine Ausnahme noch fachlich nötig ist oder nur aus Gewohnheit fortgeführt wird. Eine belastbare Portfolio-Sicht fragt deshalb nicht nur, ob ein Dienst existiert. Sie fragt, warum er existiert, wer ihn verantwortet, welche Kosten und Risiken daran hängen und wann die nächste Entscheidung fällig ist.

Das Portfolio muss den Betriebsalltag sehen

Portfolioarbeit scheitert oft an einer zu schönen Draufsicht. Auf der Folie sieht eine Konsolidierung plausibel aus. Im Service Desk zeigt sich später, dass ein Altsystem noch Passwörter, Schnittstellen, manuelle Exporte oder Sonderprozesse auslöst. Wer diese Betriebsfolgen nicht im Portfolio sichtbar macht, plant Abschaltungen und Prioritäten mit unvollständigen Daten.

Atlassian beschreibt IT-Asset-Management als Methode, um IT-Ressourcen über ihren Lebenszyklus hinweg zu verfolgen und Kosten, Nutzung und Risiken besser zu steuern. Für das IT-Portfolio heißt das: Ein Dienst ist nicht nur ein Name in einer Liste. Er hat Nutzer, Verträge, Datenflüsse, Supportwege, Sicherheitsanforderungen und oft verdeckte Abhängigkeiten.

Der Risikoanteil darf nicht versteckt bleiben

Nicht jede Ausnahme ist gleich kritisch. Ein kleines Reporting-Tool ohne sensible Daten hat ein anderes Gewicht als ein altes System mit externem Zugriff, schwacher Authentisierung oder fehlendem Herstellersupport. Trotzdem werden beide Ausnahmen in der Praxis oft gleich behandelt: als lästige Altlast, die gerade nicht in die aktuelle Planung passt.

Die Cybersecurity and Infrastructure Security Agency führt mit dem Known Exploited Vulnerabilities Catalog öffentlich nach, welche bekannten Schwachstellen aktiv ausgenutzt werden. Diese Logik ist für Portfolioarbeit wichtig, auch wenn der Katalog nicht jedes interne System bewertet. Wer alte Dienste, ungepatchte Komponenten oder Sonderzugänge nicht mehr sauber zuordnet, kann neue Risikosignale nicht schnell auf die eigenen Ausnahmen abbilden.

Governance beginnt mit einfachen Feldern

Das NIST Cybersecurity Framework 2.0 betont Governance und das Verständnis von Organisation, Assets, Risiken und Verantwortlichkeiten. Für die Portfolio-Praxis muss daraus keine komplizierte Bürokratie werden. Oft reichen wenige Pflichtfelder, damit aus einer Ausnahme eine steuerbare Entscheidung wird.

• Was genau bleibt außerhalb des Zielbilds bestehen?
• Welcher fachliche Nutzen oder Zwang rechtfertigt die Ausnahme?
• Welche Nutzer, Daten, Schnittstellen und Supportwege hängen daran?
• Wer ist fachlich und technisch verantwortlich?
• Welche Risiken, Kosten und Betriebsaufwände werden akzeptiert?
• Wann wird die Ausnahme erneut entschieden?
• Was passiert, wenn die Ausnahme nicht verlängert wird?

Diese Felder wirken schlicht, aber sie verändern die Diskussion. Statt allgemein über Altlasten zu sprechen, sieht die IT-Leitung konkrete Entscheidungsfälle. Statt pauschal zu sparen, kann sie erkennen, welche Ausnahme wirklich noch Nutzen stiftet und welche nur Aufmerksamkeit bindet.

Ausnahmen brauchen ein Ablaufdatum

Eine Ausnahme ohne Wiedervorlage ist keine Ausnahme, sondern eine stille Dauerlösung. Genau das macht Portfolioarbeit träge. Dienste bleiben in Betrieb, weil niemand den richtigen Zeitpunkt für die erneute Frage setzt. Verträge verlängern sich, kleine Tools werden weiter genutzt, Sonderrechte bleiben aktiv und niemand fühlt sich zuständig, weil die ursprüngliche Entscheidung längst abgeschlossen wirkt.

Ein Ablaufdatum muss nicht automatisch Abschaltung bedeuten. Es bedeutet, dass die Organisation wieder bewusst entscheidet. Bleibt die Ausnahme, braucht sie eine neue Begründung. Fällt sie weg, braucht sie einen Übergangspfad. Wird sie größer, muss sie vielleicht vom Sonderfall in den regulären Portfolio-Plan wechseln.

Der Service Desk liefert frühe Warnsignale

Service Desk und Betrieb sehen oft vor dem Management, welche Ausnahme zu viel Reibung erzeugt. Wiederkehrende Passwortprobleme, manuelle Berechtigungen, unklare Besitzer, doppelte Datenpflege oder immer gleiche Rückfragen zeigen, dass ein Dienst nicht nur strategisch ungeordnet ist, sondern operativ Kosten verursacht.

Diese Signale sollten nicht als bloße Supportstatistik verschwinden. Sie gehören in die Portfolio-Bewertung. Wenn ein Dienst wenig Geschäftsnutzen hat, aber regelmäßig Tickets, Sicherheitsabstimmungen oder manuelle Arbeit auslöst, ist seine Ausnahme schwerer zu rechtfertigen. Umgekehrt kann ein scheinbar altes System weiterhin berechtigt sein, wenn es stabil läuft, klare Besitzer hat und einen nachweisbaren Fachprozess trägt.

Ein gutes Ausnahmeboard entscheidet nicht allein

Ein Ausnahmeboard oder eine Portfolio-Runde sollte keine Bühne für Bauchgefühl sein. Es braucht Vorarbeit aus Betrieb, Security, Fachbereich, Einkauf und Architektur. Die Runde entscheidet dann nicht über vage Vorlieben, sondern über sichtbare Abwägungen: Nutzen gegen Risiko, Übergangskosten gegen Daueraufwand, fachliche Pflicht gegen technische Schulden.

Wichtig ist dabei die Sprache. Eine IT-Leitung gewinnt wenig, wenn jede Ausnahme nur als technisches Detail beschrieben wird. Besser sind entscheidbare Sätze: Dieser Dienst bleibt für sechs Monate, weil ein Fachprozess noch nicht ersetzt ist. Dieses Tool verliert die Ausnahme, weil Besitzer, Nutzung und Risiko nicht mehr zusammenpassen. Dieses Altsystem wechselt in ein Ablöseprojekt, weil seine Betriebsfolgen größer werden als sein Nutzen.

Die beste Ausnahme ist sichtbar und unbequem

Ausnahmen sollen nicht hübsch klingen. Sie sollen sichtbar machen, dass eine Organisation bewusst vom Zielbild abweicht. Diese Sichtbarkeit ist unbequem, aber nützlich. Sie verhindert, dass Schatten-IT, Altsysteme und Sonderwege nur deshalb bleiben, weil niemand sie erneut aufruft.

Der praktische Test lautet: Kann die IT-Leitung innerhalb weniger Minuten erklären, welche Ausnahmen es gibt, warum sie bestehen, wer sie verantwortet und wann sie wieder entschieden werden? Wenn nicht, fehlt dem Portfolio kein weiteres Dashboard. Es fehlt eine harte, einfache Entscheidungsroutine für das, was offiziell nicht ins Zielbild passt.

Quellen und Einordnung: Atlassian zu IT-Asset-Management und Lebenszyklussteuerung, NIST Cybersecurity Framework 2.0 zu Governance, Assets und Risiken, CISA Known Exploited Vulnerabilities Catalog als Beispiel für Risikosignale zu bekannten Schwachstellen. Stand der Quellenprüfung: 04.07.2026. Bildquelle: Pexels, Foto-ID 536.