C1. Vorgehensmodell
Das Vorgehensmodell in fünf Phasen: Assess, Strategize, Pilot, Scale und Operate mit Entscheidungspunkten und Anti-Mustern.
Die Einführung von KI ist kein einmaliges Projekt, sondern ein langfristiger Transformationsprozess.
Was dieses Kapitel liefert: das durchgängige Vorgehensmodell in fünf Phasen (Assess, Strategize, Pilot, Scale, Operate) mit klaren Entscheidungspunkten zwischen den Phasen, je Phase mit Aktivitäten, Ergebnissen, Beteiligten und dem häufigsten Fehler. Es beantwortet, wie vorgegangen wird; die konkrete, priorisierte Umsetzungsplanung folgt in Kapitel C2, der kritische Übergang in den Regelbetrieb in Kapitel C3.
Die fünf Phasen im Überblick
Jede Phase hat ein klares Ziel und definierte Aktivitäten. Die Phasen bauen aufeinander auf und werden über die Entscheidungspunkte im nächsten Abschnitt verbunden. Verschiedene Geschäftsbereiche können sich gleichzeitig in unterschiedlichen Phasen befinden.
| Phase | Ziel | Wichtigste Aktivitäten |
|---|---|---|
| 1. Assess | Ausgangslage und Reifegrad kennen | Reifegrad je Dimension bestimmen (siehe Kapitel A3), Datenlandschaft sichten, erste Chancen und Risiken einordnen |
| 2. Strategize | Strategische Leitplanken setzen | KI-Strategie im Management verankern, Governance-Struktur aufsetzen, Datenquellen klassifizieren, Zielbild formulieren (siehe Kapitel B1) |
| 3. Pilot | Nutzen nachweisen, Lernkurve aufbauen | Priorisierte Anwendungsfälle in einzelnen Bereichen umsetzen, FinOps-Mechanismen von Anfang an etablieren, erste Wiederverwendungsbausteine (Feature Store, Prompt-Bibliothek) schaffen |
| 4. Scale | Breite Implementierung | KI in Kernsysteme integrieren, Entwicklungs- und Betriebsprozesse standardisieren (MLOps/LLMOps), unternehmensweite Metriken einführen |
| 5. Operate | Kontinuierlicher Betrieb und Optimierung | KI als integraler Bestandteil von Prozessen und Produkten, vollständig etablierte Governance, Fokus verschiebt sich von Projekten zu laufender Verbesserung |
Die Phasen im Detail
Jede Phase wird mit denselben sechs Feldern beschrieben. Die Zeitangaben sind Erfahrungswerte für mittelgroße Organisationen; sie skalieren mit Unternehmensgröße und Ambitionsniveau.
Phase 1: Assess
| Feld | Beschreibung |
|---|---|
| Ziel | Ehrliches Bild der Ausgangslage: Reifegrad, Datenlage, erste Chancen und Risiken |
| Kernaktivitäten | Reifegradanalyse in fünf Schritten durchführen, Datenlandschaft und Systeme sichten (siehe Kapitel B4), laufende und gescheiterte KI-Initiativen inventarisieren (inkl. Shadow AI, siehe Kapitel A1), erste Anwendungsfall-Ideen sammeln, ohne sie schon zu bewerten |
| Ergebnisse | Reifegradprofil je Dimension mit benannten Lücken, Datenquellen-Inventar, Inventar bestehender Initiativen, ungefilterte Ideenliste |
| Typische Dauer | 4 bis 8 Wochen; länger ist meist ein Zeichen für zu viel Detailtiefe am falschen Ort |
| Federführung | AI-Programmleitung oder externe Begleitung; Geschäftsführung und IT-Leitung liefern aktiv zu (siehe Kapitel B7) |
| Häufigster Fehler | Die Analyse wird zur Selbstbeschäftigung: monatelange Erhebung, statt mit einem belastbaren 80-Prozent-Bild in die Strategiearbeit zu gehen |
Umgang mit gefundener Shadow AI: Die Inventarisierung deckt fast immer nicht freigegebene Werkzeuge auf (siehe Kapitel A1). Jeder Fund wird bewertet und einer von drei Konsequenzen zugeordnet, statt ihn nur zu notieren:
| Befund | Konsequenz | Vorgehen |
|---|---|---|
| Deckt einen echten Bedarf, vertretbares Risiko | Legalisieren | In den offiziellen Weg überführen: freigegebene Variante bereitstellen, in Register und Governance aufnehmen |
| Echter Bedarf, aber untragbares Risiko (Datenabfluss, Compliance) | Ersetzen | Sichere Alternative bereitstellen und den Umstieg begleiten, bevor der alte Weg geschlossen wird |
| Kein echter Bedarf oder nicht vertretbar | Abschalten | Zugang unterbinden, Begründung und, wo möglich, eine Alternative kommunizieren |
Der häufigste Fehler ist das reine Verbieten ohne Alternative: Es verlagert die Nutzung nur weiter in den Untergrund.
Phase 2: Strategize
| Feld | Beschreibung |
|---|---|
| Ziel | Beschlossene Strategie mit Governance, priorisiertem Portfolio und Zielbild |
| Kernaktivitäten | Vision und Ambitionsniveau festlegen (siehe Kapitel B1), Anwendungsfälle systematisch erheben und priorisieren (siehe Kapitel B2), Build-Buy-Partner-Grundsatz je Feld klären (siehe Kapitel B3), Betriebsmodell und Rollen aufsetzen (siehe Kapitel B6 und B7), Regulatorik-Rahmen und Ethik-Leitplanken definieren (siehe Kapitel B8 und B10), Roadmap erstellen |
| Ergebnisse | Verabschiedete KI-Strategie mit Budget, priorisiertes Portfolio, Roadmap mit erster Welle, arbeitsfähige Governance (KI-Register, Freigabeprozess), benannte Rollen |
| Typische Dauer | 2 bis 4 Monate; parallel dazu können erste risikoarme Werkzeuge bereits erprobt werden |
| Federführung | Chief AI Officer / CIO mit KI-Mandat; Beschluss durch Geschäftsführung bzw. Vorstand mit Vorstandspat:in |
| Häufigster Fehler | Die Strategie bleibt ein Papier: kein Budgetbeschluss, keine benannten Personen, keine erste Welle mit Terminen. Woran man es erkennt: Drei Monate nach dem Beschluss hat noch kein Anwendungsfall begonnen |
Phase 3: Pilot
| Feld | Beschreibung |
|---|---|
| Ziel | Nachgewiesener Nutzen an realen Anwendungsfällen und eine wachsende Lernkurve der Organisation |
| Kernaktivitäten | 2 bis 4 priorisierte Anwendungsfälle umsetzen (nicht mehr, siehe Anti-Muster unten), je Pilot vorab Erfolgskriterien und Baseline festlegen (siehe Kapitel D1), mit Produktivdaten arbeiten, FinOps-Mechanismen von Anfang an mitführen (siehe Kapitel D2), Sicherheits- und Ethikprüfung je Pilot durchlaufen (siehe Kapitel B9 und B10), Wiederverwendungsbausteine aufbauen (Modellzugänge, Prompt-Bibliothek, Evaluations-Suite) |
| Ergebnisse | Piloten mit gemessenem Ergebnis gegen Baseline, ausgefüllte Go/No-Go-Checklisten, erste Plattformbausteine, dokumentierte Lernerfahrungen |
| Typische Dauer | 3 bis 6 Monate je Pilot; Piloten ohne Enddatum sind keine Piloten, sondern Dauerprovisorien |
| Federführung | Product Owner KI je Anwendungsfall; AI-Programmleitung koordiniert übergreifend |
| Häufigster Fehler | Der Pilot wird als Demo gebaut statt als Vorstufe der Produktion: kuratierte Daten, keine Integration, keine Kostenmessung. Die Folge ist das Scheitern am Übergang (ausführlich in Kapitel C3) |
Phase 4: Scale
| Feld | Beschreibung |
|---|---|
| Ziel | Erfolgreiche Piloten werden breit verankerte, in Kernsysteme integrierte Lösungen |
| Kernaktivitäten | Rollout nach definierter Strategie (stufenweise nach Bereichen oder Nutzergruppen), Integration in Kernsysteme und Prozesse (siehe Kapitel B5), Standardisierung von Entwicklung und Betrieb (MLOps/LLMOps), Befähigung der Fläche (siehe Kapitel B11), unternehmensweites Metrik- und Kosten-Reporting (siehe Kapitel D4) |
| Ergebnisse | Produktive Lösungen mit Service Owner und Support, standardisierte Delivery-Pipeline, Reporting an Management und Gremien, wachsender Anteil wiederverwendeter Bausteine |
| Typische Dauer | 6 bis 18 Monate je nach Integrationstiefe und Flächengröße |
| Federführung | Service Owner je Lösung, Plattform-Engineering für die gemeinsamen Bausteine, Portfolio Board steuert die Reihenfolge |
| Häufigster Fehler | Skalieren durch Kopieren: Der Pilot wird unverändert hochgefahren, statt auf die produktionsreife Plattform überführt zu werden. Technische Schulden aus der Pilotphase wachsen mit |
Phase 5: Operate
| Feld | Beschreibung |
|---|---|
| Ziel | KI ist Regelbetrieb: verlässlich, wirtschaftlich, kontinuierlich verbessert |
| Kernaktivitäten | Laufendes Monitoring von Qualität, Drift, Kosten und Fairness (siehe Kapitel D1 und B10), regelmäßige Re-Evaluierung gegen die Erfolgskriterien, Lebenszyklus-Management (Modellwechsel, Stilllegung), kontinuierliche Aufnahme neuer Anwendungsfälle über den etablierten Intake, jährliche Wirksamkeitsprüfung der Governance (siehe Kapitel B7) |
| Ergebnisse | Stabile Serviceziele, belastbares Kosten-Nutzen-Reporting, gepflegtes KI-Register, planvolle Modernisierung statt Feuerwehr |
| Typische Dauer | Laufend; der Aufwand verschiebt sich von Projektarbeit zu Produktpflege |
| Federführung | Service Owner und Betriebsorganisation; Portfolio Board für das Gesamtportfolio |
| Häufigster Fehler | Der Betrieb wird zum blinden Fleck: Nach dem Rollout schaut niemand mehr auf Qualität und Kosten, bis ein Vorfall oder eine Rechnung es erzwingt |
Entscheidungspunkte zwischen den Phasen
Jede Phase endet mit einem expliziten Gate. Der Sinn eines Gates: Es zwingt zu einer bewussten Entscheidung, bevor mehr Geld und Kapazität gebunden werden. Ohne erfüllte Kriterien wird nicht in die nächste Phase gewechselt, sondern nachgebessert.
| Gate | Zentrale Frage | Warum diese Frage entscheidet | Bei Nein |
|---|---|---|---|
| Assess → Strategize | Ist der Reifegrad je Dimension bekannt und sind die größten Lücken benannt? | Ohne Kenntnis des Reifegrads wird die Strategie an den echten Engpässen vorbei geplant. | Reifegradanalyse vertiefen, bevor Ressourcen gebunden werden |
| Strategize → Pilot | Liegen Governance, Datenbasis und priorisierte Anwendungsfälle mit Business Case vor? | Piloten ohne Rahmen erzeugen genau die Shadow-AI- und PoC-Probleme aus Kapitel A1. | Strategiearbeit fortsetzen, keine Piloten ohne Rahmen starten |
| Pilot → Scale | Erfüllt der Pilot die vorab definierten Skalierungskriterien (siehe Kapitel C3)? | Skalieren ist der teuerste Schritt; ein schwacher Pilot wird durch Skalierung nicht besser, nur teurer. | Pilot nachschärfen oder bewusst beenden, nicht unreflektiert verlängern |
| Scale → Operate | Sind Betrieb, Governance und Kennzahlen so weit standardisiert, dass neue Anwendungsfälle ohne Sonderaufwand aufgenommen werden können? | Sonst bleibt jede neue Lösung ein Einzelprojekt und die Organisation skaliert nie. | Standardisierung vertiefen, bevor die Fläche weiter wächst |
Gate-Governance: wie eine Gate-Entscheidung abläuft
Gates wirken nur, wenn sie ernsthaft betrieben werden. Vier Festlegungen machen den Unterschied zwischen echtem Gate und Gate-Theater:
| Festlegung | Empfehlung |
|---|---|
| Wer entscheidet | Das Portfolio Board (siehe Kapitel B7); bei kleinen Organisationen die Geschäftsführung. Nie das Team, das am Weiterlaufen des Vorhabens interessiert ist |
| Auf welcher Grundlage | Vorab definierte Kriterien mit Nachweisen (bei Pilot → Scale: die Go/No-Go-Checkliste), keine Folienprosa. Die Unterlagen liegen vor der Sitzung vor |
| Welche Ergebnisse möglich sind | Vier Ausgänge, alle legitim: Go (weiter), Go mit Auflagen (weiter, benannte Punkte mit Termin nachliefern), Nachbessern (Gate in definierter Frist wiederholen), Stopp (beenden, Lernerfahrungen sichern) |
| Was ein Stopp bedeutet | Ein sauber begründeter Stopp ist ein Erfolg der Steuerung, kein Scheitern des Teams. Wird das nicht kulturell verankert, schleusen Teams schwache Vorhaben an den Gates vorbei |
Nicht streng linear: Rücksprünge und parallele Stränge
Das Modell liest sich sequenziell, wird aber nicht so gelebt. Drei Klarstellungen:
- Bereiche laufen phasenversetzt. Der Kundenservice kann skalieren, während die Produktion noch pilotiert und ein neu erschlossenes Feld im Assess steckt. Gesteuert wird je Bereich bzw. je Anwendungsfall, nicht pauschal für das ganze Unternehmen.
- Rücksprünge sind vorgesehen. Ein gescheitertes Gate führt zurück in die vorherige Phase; ein Modellwechsel im Betrieb kann einen neuen Pilotdurchlauf auslösen; eine wesentliche Strategieänderung (Zukauf, neue Regulatorik) kann einzelne Anwendungsfälle zurück in Strategize schicken. Rückstufung ist eine legitime Option, kein Scheitern.
- Zwei Stränge laufen dauerhaft parallel. Neben dem Anwendungsfall-Strang (der die Phasen durchläuft) gibt es den Befähigungs-Strang: Plattformbausteine, Daten-Governance, Schulungsprogramm und Governance-Prozesse wachsen kontinuierlich und phasenunabhängig. Die Roadmap plant beide Stränge gemeinsam (siehe Kapitel C2).
Verzahnung mit dem Reifegradmodell
Vorgehensphasen und Reifegrad gehören zusammen: Die Phasen beschreiben die geplanten Schritte, das Reifegradmodell (siehe Kapitel A3) zeigt, wie weit sie tatsächlich verankert sind. Dieses Werk verwendet bewusst ein einziges Reifegradmodell mit den fünf Stufen Erkundung, Pilotierung, Teilintegration, Breite Verankerung und Kontinuierliche Optimierung. Die Phasen ordnen sich darin ein:
| Vorgehensphase | Entspricht Reifestufe |
|---|---|
| Assess | Stufe 1 (Erkundung) |
| Strategize | Stufe 1 bis 2 (Erkundung → Pilotierung) |
| Pilot | Stufe 2 bis 3 (Pilotierung → Teilintegration) |
| Scale | Stufe 3 bis 4 (Teilintegration → Breite Verankerung) |
| Operate | Stufe 4 bis 5 (Breite Verankerung → Kontinuierliche Optimierung) |
So dient das Reifegradmodell als Diagnose- und Monitoring-Werkzeug, um zu erkennen, ob die Organisation auf Kurs ist und wann der Übergang in die nächste Phase möglich wird.
Typische Anti-Muster
Die fünf häufigsten Fehlformen des Vorgehens, jeweils mit dem Signal, an dem man sie erkennt:
| Anti-Muster | Woran man es erkennt | Gegenmittel |
|---|---|---|
| Analyse-Lähmung | Die Bestandsaufnahme (Phase Assess) zieht sich deutlich über die vorgesehenen vier bis acht Wochen hinaus, es entstehen immer neue Erhebungen statt einer Entscheidung | Zeitbox setzen; mit dem 80-Prozent-Bild in die nächste Phase (Strategize) gehen |
| Strategie ohne Umsetzung | Beschlossenes Papier, aber drei Monate später kein gestarteter Anwendungsfall | Strategiebeschluss nur zusammen mit erster Roadmap-Welle und Budget fassen |
| Pilot-Wildwuchs | Mehr als die empfohlenen zwei bis vier parallelen Piloten, keiner erreicht die Produktion | Portfolio Board begrenzt aktive Piloten; Gates konsequent betreiben |
| Plattform-zuerst-Falle | Jahrelanger Plattformaufbau ohne produktiven Anwendungsfall | Plattform nur im Befähigungs-Strang parallel zu realen Anwendungsfällen wachsen lassen |
| Gate-Theater | Gates existieren formal, aber es gab noch nie ein Nachbessern oder einen Stopp | Gate-Governance ernsthaft aufsetzen (Abschnitt Gate-Governance); Stopp-Quote beobachten: null Stopps über Jahre ist kein Qualitätsbeweis |
Checkliste: Vorgehensmodell verankert
Die Checkliste prüft, ob das Vorgehensmodell in der Organisation verankert ist statt nur beschrieben:
- Aktuelle Phase je Geschäftsbereich bestimmt (Bereiche laufen oft phasenversetzt)
- Gate-Kriterien für den nächsten Übergang definiert und bekannt
- Verantwortliche für jede Gate-Entscheidung benannt; vier Ergebnisoptionen etabliert
- Ergebnisse und Federführung je Phase geklärt (Tabellen oben)
- Befähigungs-Strang (Plattform, Daten, Schulung) parallel zum Anwendungsfall-Strang eingeplant
- Regelmäßiger Abgleich zwischen Phase und tatsächlicher Reife eingeplant
- Rückstufung oder Wiederholung einer Phase als legitime Option akzeptiert, nicht als Scheitern gewertet
- Anti-Muster-Signale bekannt und im Portfolio-Review beobachtet