C2. Roadmap und Einführung
Kapitel C1 legt fest, welche Phasen mit welchen Gates durchlaufen werden.
Was dieses Kapitel liefert: die Übersetzung in eine konkrete, priorisierte Umsetzungsplanung mit Meilensteinen: welcher Anwendungsfall wann startet, in welcher Reihenfolge, mit welchem Ressourceneinsatz und welche Befähigungsarbeit parallel laufen muss. Das Kapitel beschreibt, wie die Roadmap konstruiert, kommuniziert und lebendig gehalten wird.
Woher die Roadmap ihre Vorgaben bekommt
Die Roadmap erfindet kein neues Ziel, sie plant die Umsetzung eines bereits beschlossenen. Vier Vorgaben müssen feststehen, bevor die erste Welle geplant wird; jede wurde in einem eigenen Kapitel erarbeitet. Wer hier eine Lücke findet, schließt sie zuerst: Eine Roadmap auf ungeklärten Vorgaben ist auf Sand gebaut.
| Vorgabe | Was feststehen muss | Erarbeitet in |
|---|---|---|
| Geschäftlicher Nutzen | Welche Bereiche besonders profitieren sollen und welches Ambitionsniveau gilt | Kapitel B1 |
| Technologische Basis | Skalierbare Architektur mit Datenplattform, MLOps- und LLMOps-Fähigkeiten, Sicherheit und klaren Integrationspfaden | Kapitel B5 |
| Organisation und Kompetenzen | Betriebsmodell, klare Rollen und Governance für Ethik, Compliance und Sicherheit | Kapitel B6 und B7 |
| Kultur und Akzeptanz | KI als Unterstützung statt Bedrohung; befähigte Mitarbeitende, aktive Einbindung | Kapitel B11 |
Priorisierte Umsetzungsplanung: Quick Wins vs. strategische Wetten
Die Priorisierungsmatrix aus Kapitel B2 (Wert × Machbarkeit) bestimmt nicht nur, was umgesetzt wird, sondern auch in welcher Reihenfolge. Für die Roadmap gilt eine einfache Sequenzierungsregel:
| Roadmap-Horizont | Enthält | Zweck |
|---|---|---|
| Kurzfristig (Quick Wins) | Leuchttürme zuerst: hoher Wert, hohe Machbarkeit | Sichtbare Erfolge, Vertrauen und Budget für die nächste Welle sichern |
| Mittelfristig (Auffüller) | Hoher Machbarkeits-, geringerer Wert-Score | Kapazität auslasten, Plattformbausteine durch Wiederverwendung reifen lassen |
| Langfristig (strategische Wetten) | Hoher Wert, geringe Machbarkeit | Gezielt vorbereiten (Daten, Kompetenz, Architektur), erst starten, wenn Hürden abgebaut sind |
Regel: Jede Roadmap-Welle kombiniert überwiegend Quick Wins mit höchstens einer sorgfältig vorbereiteten strategischen Wette. Nie mehrere strategische Wetten parallel, da sie Kapazität und Aufmerksamkeit überproportional binden.
Von der Priorisierung zur Roadmap: fünf Schritte
Die häufigste Schwäche von KI-Roadmaps ist nicht die Auswahl der Anwendungsfälle, sondern die fehlende Logik dahinter, wie sie zusammengestellt werden: Geplant wird, was wünschenswert ist, nicht, was die vorhandene Kapazität wirklich hergibt. Die fünf Schritte verhindern das.
Schritt 1: Kapazität ehrlich ermitteln. Bevor irgendetwas eingeplant wird: Wie viele Vorhaben kann die Organisation parallel tragen? Begrenzend sind meist nicht Ideen oder Budget, sondern Schlüsselpersonen (Data Engineers, Product Owner mit Fachwissen, Freigabe-Instanzen) und die Aufnahmefähigkeit der Fachbereiche. Faustregel für den Einstieg: 2 bis 4 parallele Piloten, nicht mehr. Wer die Kapazitätsfrage überspringt, baut eine Wunschliste, keine Roadmap.
Schritt 2: Anwendungsfälle in Wellen schneiden. Die priorisierten Anwendungsfälle werden in Wellen aufgeteilt (empfohlen: eine Welle je Quartal), in der Reihenfolge aus dem vorigen Abschnitt: Quick Wins zuerst, höchstens eine strategische Wette je Welle. In jede Welle kommen nur so viele Vorhaben, wie die Kapazität aus Schritt 1 zulässt. Was nicht mehr hineinpasst, wandert in die nächste Welle, statt die aktuelle zu überladen.
Schritt 3: Befähigungs-Strang aus den Reifegrad-Lücken ableiten. Parallel zum Anwendungsfall-Strang läuft der Befähigungs-Strang (siehe Kapitel C1): Plattformbausteine, Daten-Governance, Schulungsprogramm, Governance-Prozesse. Seine Inhalte kommen aus zwei Quellen: den Lücken der Reifegradanalyse (siehe Kapitel A3) und den Abhängigkeiten der geplanten Anwendungsfälle (wenn Welle 2 ein RAG-System enthält, muss die Wissensbasis-Infrastruktur in Welle 1 entstehen). Befähigungsarbeit, die kein geplanter Anwendungsfall braucht und keine Reifegrad-Lücke schließt, fliegt raus: Sie ist die häufigste Quelle der Plattform-zuerst-Falle.
Schritt 4: Abhängigkeiten und Meilensteine terminieren. Für jede Welle werden Meilensteine festgelegt, jeweils mit Termin, Gate-Punkt und verantwortlicher Person (Felder je Welle im Abschnitt Roadmap-Struktur). Abhängigkeiten zwischen den beiden Strängen werden ausdrücklich benannt. Jede Abhängigkeit ohne festen Liefertermin ist ein Risiko und gehört ins Register (siehe Kapitel D3).
Schritt 5: Beschluss mit Budget und Kommunikation. Die Roadmap wird zusammen mit dem Budget beschlossen (siehe Anti-Muster “Strategie ohne Umsetzung” in Kapitel C1) und zielgruppengerecht kommuniziert: Vorstand (Wellen, Investment, erwarteter Nutzen), Fachbereiche (was kommt wann auf sie zu, was wird von ihnen gebraucht), Mitarbeitende (was sich ändert, welche Unterstützung es gibt, siehe Kapitel B11).
Roadmap-Struktur
Für jede Welle (empfohlen: quartalsweise) werden festgehalten:
| Feld | Inhalt | Beispiel |
|---|---|---|
| Anwendungsfälle | Aus der Priorisierungsmatrix übernommen, mit Verweis auf den Steckbrief | „Antwortvorschläge Kundenservice" (Leuchtturm) |
| Phase im Vorgehensmodell | Assess, Strategize, Pilot, Scale oder Operate je Anwendungsfall | Pilot |
| Befähigungs-Elemente | Plattform-, Daten-, Governance- und Schulungsarbeit der Welle | Anbindung Tickethistorie, Prompt-Bibliothek v1, Schulung Kundenservice |
| Meilensteine | Konkrete, terminierte Ergebnisse inkl. Gate-Termine | Pilotstart 1. März, Go/No-Go-Entscheidung 30. Juni |
| Abhängigkeiten | Zu Plattform, Daten, anderen Initiativen, mit Liefertermin | Benötigt Anbindung der Tickethistorie bis 15. Februar (siehe Kapitel B4) |
| Verantwortlich | Wer liefert den Meilenstein? | Product Owner Service |
| Ressourcen | Budget und Kapazität je Welle | 120.000 Euro, 1,5 Vollzeitäquivalente |
Beispiel: erstes Roadmap-Jahr (verdichtet)
Das Beispiel zeigt die Verzahnung der beiden Stränge über vier Wellen. Es ist bewusst klein gehalten: ein mittelständisches Unternehmen, Einstiegsphase, begrenzte Kapazität.
| Welle | Anwendungsfall-Strang | Befähigungs-Strang | Gate am Wellenende |
|---|---|---|---|
| Q1 | Pilot 1: Antwortvorschläge Kundenservice; Pilot 2: interne Dokumentensuche | Modellzugang mit Protokollierung, KI-Register, KI-Richtlinie, Basisschulung Pilotbereiche | Go/No-Go Pilot 1 und 2 |
| Q2 | Pilot 1 → Rollout Kundenservice; Pilot 3: Angebotserstellung Vertrieb | Wissensbasis-Infrastruktur (für Pilot 2/3), Evaluations-Suite, Support-Struktur Stufe 1 | Go/No-Go Pilot 3; Review Rollout 1 |
| Q3 | Rollout Dokumentensuche unternehmensweit; Vorbereitung strategische Wette (Schadenprognose): Datenqualität | Kostenreporting je Anwendungsfall, Fairness-Prüfprozess, Schulungswelle 2 | Reifegrad-Zwischenmessung (A3) |
| Q4 | Start strategische Wette als Pilot; Betriebsübergabe Rollouts an Service Owner | MLOps-Standardisierung, jährliche Governance-Prüfung | Go/No-Go strategische Wette; Jahresreview mit Vorstand |
Nutzen einer Roadmap: Orientierung für Führungskräfte (wo wird investiert, was ist zu erwarten), Transparenz für Mitarbeitende, ein gemeinsames Steuerungsinstrument zwischen IT, Fachbereich und Finanzen und Kontinuität, die verhindert, dass KI als kurzfristiger Trend behandelt wird.
Die Roadmap lebendig halten
Eine KI-Roadmap ist kein Fixplan: Modelle, Anbieter und Regulatorik ändern sich schneller als jede Jahresplanung. Der Umgang damit wird geregelt, nicht dem Zufall überlassen.
- Fester Review-Rhythmus: Das Portfolio Board prüft die Roadmap quartalsweise im Portfolio-Review (siehe Kapitel D4): Was wurde geliefert, was verschiebt sich, was fliegt raus, was kommt neu hinzu.
- Definierte Re-Priorisierungs-Auslöser zwischen den Reviews: ein gescheitertes oder verschobenes Gate, eine wesentliche Modell- oder Anbieteränderung, neue regulatorische Fristen (siehe Kapitel B8), eine veränderte Geschäftspriorität. Tritt ein Auslöser ein, wird die betroffene Welle neu geschnitten, nicht die gesamte Roadmap umgeworfen.
- Verzögerungen wellenweise auffangen: Verzögert sich ein Vorhaben, wird es in die nächste Welle verschoben und die frei werdende Kapazität mit einem Auffüller besetzt. Nicht alle Termine nachziehen: Das erzeugt die Dauerbaustellen-Roadmap, der niemand mehr glaubt.
- Versionierung: Jede beschlossene Roadmap-Fassung wird datiert abgelegt. So bleibt nachvollziehbar, was wann warum geändert wurde, und das Jahresreview kann Plan und Ist ehrlich vergleichen.
Typische Roadmap-Fehler
Auch eine sauber geplante Roadmap scheitert an wiederkehrenden Mustern. Die Tabelle nennt je Fehler die Folge und das Gegenmittel:
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Überladene erste Welle | Alles startet gleichzeitig, nichts wird fertig, das Programm verliert in sechs Monaten seine Glaubwürdigkeit | Kapazitätsgrenze aus Schritt 1 respektieren; lieber eine Welle sauber liefern |
| Roadmap ohne Befähigungs-Strang | Piloten gelingen, Skalierung scheitert an fehlender Plattform, Governance und Kompetenz | Befähigungs-Elemente je Welle einplanen (Schritt 3) |
| Wunschtermine statt Abhängigkeiten | Meilensteine platzen, weil Datenanbindungen und Freigaben länger dauern als gehofft | Abhängigkeiten mit Lieferterminen erfassen; Puffer an Gates legen |
| Roadmap als Wasserfall-Fixplan | Jede Änderung wirkt wie ein Scheitern; das Programm versteift sich gegen Lernen | Review-Rhythmus und Re-Priorisierungs-Auslöser etablieren (oben) |
| Roadmap ohne Budgetbeschluss | Schöne Folien, keine Umsetzung | Roadmap und Budget gemeinsam beschließen |
| Roadmap bleibt intern | Fachbereiche werden überrascht, Gerüchte füllen die Lücke, Akzeptanz sinkt | Zielgruppengerechte Kommunikation ab Beschluss (Schritt 5) |
Checkliste: Roadmap startklar
Die Checkliste prüft, ob die Roadmap beschlussreif ist, von der Kapazität bis zur Kommunikation:
- Alle vier Vorgaben geklärt: geschäftlicher Nutzen, technologische Basis, Organisation und Kompetenzen, Kultur und Akzeptanz
- Kapazität ermittelt: parallele Vorhaben begrenzt, Schlüsselpersonen benannt
- Anwendungsfälle aus der Priorisierungsmatrix in Wellen eingeteilt (Quick Wins, Auffüller, strategische Wetten)
- Höchstens eine strategische Wette je Welle eingeplant
- Befähigungs-Strang aus Reifegrad-Lücken und Abhängigkeiten abgeleitet und je Welle eingeplant
- Aktuelle Phase im Vorgehensmodell je Anwendungsfall bestimmt
- Meilensteine mit Terminen, Gate-Punkten und Verantwortlichen hinterlegt
- Abhängigkeiten zwischen Initiativen mit Lieferterminen sichtbar gemacht
- Budget und Kapazität je Welle hinterlegt
- Roadmap zusammen mit Budget beschlossen
- Kommunikation je Zielgruppe geplant (Vorstand, Fachbereiche, Mitarbeitende)
- Review-Rhythmus und Re-Priorisierungs-Auslöser festgelegt
- Umgang mit Verzögerungen geregelt: Vorhaben rückt in die nächste Welle, frei werdende Kapazität wird mit einem Auffüller besetzt
- Jede beschlossene Roadmap-Fassung datiert abgelegt, damit Plan und Ist vergleichbar bleiben
- Regelmäßiger Abgleich zwischen Roadmap und tatsächlicher Reife eingeplant