Eine IT-Roadmap ohne Entscheidungslogik wird zur Wunschliste

Viele IT-Roadmaps sehen auf den ersten Blick ordentlich aus. Projekte stehen in Zeilen, Quartale in Spalten, farbige Balken zeigen Start und Ende. ERP-Schnittstelle, Firewall-Erneuerung, Self-Service, Datenplattform und Telefonieprojekt besitzen jeweils einen Termin.

Sobald zwei Vorhaben dieselbe Schlüsselperson benötigen oder ein unerwarteter Pflicht-Change dazukommt, verliert die Darstellung ihren Wert. Niemand kann begründet sagen, was warten soll. Die Balken werden verschoben, ohne dass sich an der zugrunde liegenden Entscheidung etwas ändert.

Das Problem ist nicht die Visualisierung. Es fehlt die Logik, nach der Vorhaben aufgenommen, geordnet, begonnen, unterbrochen oder beendet werden.

Eine belastbare IT-Roadmap ist deshalb kein Kalender aller Wünsche, sondern ein sichtbares System für Portfolioentscheidungen.

Eine Projektliste beantwortet noch keine Prioritätsfrage

Eine Liste zeigt, dass ein Vorhaben vorgeschlagen wurde. Eine Roadmap muss zusätzlich erklären:

• welches geschäftliche Problem gelöst werden soll,
• welche Wirkung erwartet und später überprüft wird,
• wer die fachliche Entscheidung verantwortet,
• welche Voraussetzungen und Abhängigkeiten bestehen,
• welche knappe Kapazität benötigt wird,
• welche Folgekosten und Betriebsaufgaben entstehen,
• welche Entscheidung als Nächstes fällig ist.

Fehlen diese Angaben, wirken alle Einträge ähnlich wichtig. Ein regulatorisch notwendiger Austausch steht dann neben einer Komfortfunktion. Ein bereits beschlossenes Vorhaben steht neben einer Idee, die noch nicht einmal fachlich geklärt ist. Das erzeugt Scheingenauigkeit.

ISO/IEC 38500:2024 richtet die Governance von IT auf ihre wirksame, effiziente und angemessene gegenwärtige und zukünftige Nutzung aus. Für eine mittelständische Roadmap folgt daraus keine Pflicht zu einem großen Governance-Modell. Es folgt aber die Notwendigkeit, Zukunftsvorhaben als Führungsentscheidungen zu behandeln – nicht als Sammlung technischer Termine.

Zuerst unterschiedliche Vorhaben unterscheidbar machen

Nicht jedes Vorhaben konkurriert aus demselben Grund um Priorität. Eine einfache Einteilung hilft, ohne eine komplizierte Bewertungsmethode einzuführen:

Klasse	Leitfrage	Beispiele
verpflichtend	Was müssen wir wegen Recht, Vertrag, Sicherheit oder Supportende tun?	regulatorische Anpassung, Hersteller-Supportende
stabilisieren	Was reduziert ein wesentliches Betriebs- oder Ausfallrisiko?	Restore-Fähigkeit, Ablösung instabiler Infrastruktur
verbessern	Was verbessert messbar Kosten, Qualität oder Durchlaufzeit?	automatisierter Onboarding-Ablauf
erkunden	Welche Annahme wollen wir mit begrenztem Aufwand prüfen?	Prototyp für einen neuen KI-Anwendungsfall

Die Klassen ersetzen keine Entscheidung. Sie verhindern aber, dass ein Experiment denselben Verbindlichkeitsgrad wie eine beschlossene Pflichtmaßnahme erhält.

Auch innerhalb einer Klasse bleibt Priorisierung nötig. Zwei Sicherheitsvorhaben können dieselbe Person benötigen. Zwei Verbesserungen können unterschiedlich viel Nutzen oder Risiko besitzen. Entscheidend ist, dass die Diskussion mit vergleichbaren Informationen beginnt.

Sieben Felder machen eine Initiative entscheidungsfähig

1. Problem und gewünschte Wirkung

„Neues Ticketsystem“ beschreibt eine Lösung. „Anfragen gehen über Mail, Telefon und Zuruf verloren; Eingang, Status und Bearbeitungsaufwand sollen nachvollziehbar werden“ beschreibt das Problem und die gewünschte Wirkung.

Diese Trennung verhindert, dass ein Produktname bereits als Entscheidung behandelt wird. Sie öffnet den Raum für andere Lösungen und macht später prüfbar, ob das Ergebnis erreicht wurde.

Der Technology Code of Practice der britischen Regierung betont die Ausrichtung von Technologie- und Geschäftsstrategie sowie die Betrachtung des gesamten Lebenszyklus. Der Leitfaden richtet sich an den öffentlichen Sektor. Die übertragbare Frage ist schlicht: Welches Geschäftsziel rechtfertigt das Technologievorhaben – und was entsteht nach seiner Einführung?

2. Nutzen-Owner und Entscheidungsträger

Der Projektleiter organisiert die Umsetzung. Er ist nicht automatisch Eigentümer der geschäftlichen Wirkung.

Eine Initiative braucht mindestens:

• einen fachlichen Nutzen-Owner,
• einen technischen Verantwortlichen,
• eine Rolle mit Priorisierungs- und Budgetentscheidung,
• eine benannte Eskalation bei Zielkonflikten.

Der Nutzen-Owner bestätigt beispielsweise, ob ein neuer Onboarding-Prozess tatsächlich schneller und verlässlicher geworden ist. Die IT kann die technische Bereitstellung verantworten, aber nicht allein die Wirkung im Personalprozess.

Der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ trennt Aufgabe, Verantwortung, Entscheidungsrecht und technische Berechtigung. Diese Trennung gehört auch in die Roadmap.

3. Ausgangslage und Prüfkriterium

Ohne Ausgangslage bleibt Nutzen eine Erzählung. Die Messung muss nicht aufwendig sein. Sie muss zur behaupteten Wirkung passen.

Mögliche Fragen sind:

• Wie häufig tritt das Problem heute auf?
• Wie lange dauert der betroffene Ablauf?
• Welche manuellen Übergaben oder Fehler werden beobachtet?
• Welche Betriebs- oder Lizenzkosten bestehen?
• Woran erkennt der Nutzen-Owner eine ausreichende Verbesserung?

Das Digital and Data Benefits Framework beschreibt die systematische Definition, Planung und Messung von Nutzen. Für ein kleines Portfolio reicht oft eine deutlich schlankere Form. Der Grundsatz bleibt: Ein erwarteter Nutzen braucht eine Definition, eine Ausgangslage und jemanden, der ihn beurteilt.

4. Voraussetzungen und Abhängigkeiten

Viele Roadmaps planen die sichtbare Umsetzung, aber nicht ihre Voraussetzungen. Ein ERP-Reporting benötigt vielleicht bereinigte Stammdaten. Ein Self-Service benötigt geklärte Rollen. Eine Cloud-Migration benötigt Netz-, Identitäts- und Backupentscheidungen.

Jede Initiative sollte deshalb beantworten:

• Was muss vorher entschieden oder geliefert sein?
• Welche anderen Vorhaben verändern dieselben Systeme oder Prozesse?
• Welche Fachbereiche und Dienstleister müssen mitwirken?
• Welche technische oder organisatorische Schuld wird berührt?
• Was blockiert den Start?

Abhängigkeiten gehören nicht in eine Fußnote. Sie bestimmen die Reihenfolge.

5. Engpasskapazität statt nur Projektbudget

Ein genehmigtes Budget schafft noch keine verfügbare interne Zeit. Im Mittelstand konkurrieren Projekte häufig um dieselben Administratoren, Prozess-Owner oder Key User, die gleichzeitig den Betrieb sicherstellen.

Für die Roadmap genügt zunächst eine grobe Kapazitätsaussage:

• Welche Schlüsselrollen werden benötigt?
• In welchem Zeitraum?
• Welche Betriebsaufgaben haben Vorrang?
• Welche Parallelität ist realistisch?
• Welche Arbeit fällt nach dem Go-live dauerhaft an?

Der Artikel zu IT-Kosten zeigt, warum interne Arbeitskosten in die Steuerung gehören. Für eine Roadmap ist der noch wichtigere Punkt: Interne Arbeitszeit ist nicht nur ein Kostenwert, sondern oft der tatsächliche Engpass.

6. Lebenszyklus und Ausstieg

Die Roadmap endet nicht beim Go-live. Neue Anwendungen benötigen Betrieb, Support, Lizenzen, Updates, Schulung, Datenpflege und irgendwann Ablösung.

Vor der Freigabe sollten deshalb zumindest bekannt sein:

• künftiger Service- und System-Owner,
• erwarteter interner Betriebsaufwand,
• wiederkehrende externe Kosten,
• notwendige Fähigkeiten und Vertretung,
• Rückfall- oder Ausstiegsmöglichkeit.

Eine Initiative, deren Einführung finanziert ist, deren Betrieb aber niemand übernimmt, ist nicht entscheidungsreif.

7. Nächster Entscheidungspunkt

Nicht jedes Vorhaben benötigt sofort eine endgültige Freigabe. Eine Roadmap kann bewusst stufenweise entscheiden:

• Problem untersuchen,
• Lösungsmöglichkeiten vergleichen,
• begrenzten Pilot durchführen,
• Umsetzung freigeben,
• Nutzen überprüfen,
• fortführen, anpassen oder beenden.

Jeder Eintrag erhält deshalb einen nächsten Entscheidungspunkt mit benötigter Evidenz und entscheidungsbefugter Rolle. Das macht Unsicherheit sichtbar, ohne Ideen vorschnell zu Projekten zu erklären.

Konstruiertes Beispiel: Vier Balken, eine Schlüsselperson

Das folgende Beispiel ist konstruiert.

Eine IT-Roadmap enthält im selben Halbjahr eine Firewall-Erneuerung, eine ERP-Schnittstelle, ein Self-Service-Portal und den Aufbau einer Datenplattform. Alle Vorhaben besitzen Sponsoren und gewünschte Termine. Für drei davon wird jedoch derselbe interne Administrator benötigt. Die ERP-Schnittstelle hängt zusätzlich von einer noch ungeklärten Datenverantwortung ab.

In der bisherigen Darstellung werden die Balken lediglich enger geschoben. Nach Ergänzung der Entscheidungslogik ändert sich das Bild:

• Die Firewall-Erneuerung wird wegen eines verbindlichen Supportendes als Pflichtvorhaben behandelt.
• Die ERP-Schnittstelle erhält zunächst einen Entscheidungspunkt für Daten-Owner und Zielprozess.
• Das Self-Service-Portal wird auf einen eng begrenzten Ablauf reduziert.
• Die Datenplattform bleibt als Erkundungsvorhaben bestehen, startet aber erst nach Klärung von Nutzen und Kapazität.

Das Beispiel behauptet keinen Projekterfolg. Es zeigt, dass eine Roadmap nicht mehr Arbeit gleichzeitig möglich macht. Sie macht den notwendigen Verzicht und die Voraussetzungen sichtbar.

Verbindliche Termine heben Zielkonflikte nicht auf

Ein Einwand lautet häufig: „Wir können nicht priorisieren, der Termin steht fest.“ Das kann bei Regulierung, Vertrag, Supportende oder einer verbindlichen Geschäftsentscheidung stimmen.

Der feste Termin beseitigt aber weder Abhängigkeiten noch Kapazitätsgrenzen. Er verändert die Entscheidung:

• Welche anderen Vorhaben werden verschoben?
• Welche zusätzliche Fähigkeit wird eingekauft?
• Welcher Umfang wird reduziert?
• Welches Betriebsrisiko wird vorübergehend akzeptiert?
• Wer genehmigt diese Konsequenz?

Ein Pflichttermin ist damit ein starkes Prioritätskriterium, kein Ersatz für Portfoliosteuerung.

Ein schlankes Portfolio-Board

Für ein mittelständisches Portfolio genügt häufig eine Tabelle:

Feld	Inhalt
Initiative	verständlicher Name ohne Produktzwang
Problem und Wirkung	heutige Einschränkung und gewünschtes Ergebnis
Klasse	verpflichten, stabilisieren, verbessern oder erkunden
Nutzen-Owner	Rolle, die die fachliche Wirkung verantwortet
Entscheidung	freigegeben, zu prüfen, blockiert, pausiert oder beendet
Abhängigkeiten	notwendige Entscheidungen, Daten, Systeme und Vorhaben
Engpasskapazität	benötigte Schlüsselrollen und Zeitraum
Lebenszyklus	erwarteter Betrieb, Folgekosten und Ausstieg
nächster Prüfpunkt	Datum, notwendige Evidenz und Entscheider

Das Board wird regelmäßig mit den entscheidungsbefugten Rollen geprüft. Der Zweck ist nicht, jede Woche Balken zu pflegen. Es soll Entscheidungen auslösen: starten, stoppen, verkleinern, verschieben oder eine Voraussetzung schaffen.

Woran eine Roadmap ihren Nutzen zeigt

Die reine Zahl abgeschlossener Projekte ist ein schwacher Maßstab. Sie belohnt kleine Vorhaben und sagt nichts über Wirkung.

Bessere Nutzensignale sind:

• Kapazitätskonflikte werden vor dem Projektstart sichtbar.
• Blockierte Vorhaben besitzen einen konkreten Entscheidungsbedarf.
• Vorhaben ohne tragfähige Wirkung werden beendet oder verkleinert.
• Betriebs- und Folgekosten erscheinen vor der Freigabe.
• Nutzen-Owner überprüfen Ergebnisse nach der Einführung.
• Geschäftsführung und IT können begründen, warum etwas jetzt, später oder gar nicht geschieht.

Der erste sinnvolle Schritt ist keine neue Roadmap-Software. Nehmen Sie die laufenden und geplanten Vorhaben und ergänzen Sie für jedes genau fünf Angaben: Problem, Wirkung, Owner, Engpass und nächste Entscheidung. Wo diese Angaben fehlen, fehlt nicht Dokumentation – dort fehlt eine Führungsentscheidung.