Erweiterte Vertiefungen — Modul 8: Methoden, Konzepte und Transferwissen

Vertiefung UE 85 — Prozessaufnahme: Methoden, Fallstricke und Meisterklasse

Warum scheitern 40 % aller KI-Projekte an der Prozessaufnahme?

Die McKinsey-Analyse aus dem Jahr 2024 zeigt konsistent: Der häufigste Scheiterpunkt bei KI-Implementierungen liegt nicht in der Modellauswahl oder der Technologie, sondern in unzureichendem Prozessverständnis vor dem Projektstart. Teams versuchen, einen schlecht dokumentierten, variablen, oder stillschweigend von Expertenwissen abhängigen Prozess mit KI zu automatisieren — und scheitern, weil kein Modell lernen kann, was der Prozess selbst nicht konsistent tut.

Das führt zu einem fundamentalen Lernziel für dieses Modul: Prozessaufnahme ist keine administrative Pflichtübung vor dem eigentlichen KI-Projekt. Prozessaufnahme ist ein substanzieller Teil des KI-Projekts selbst. Wer sorgfältig aufnimmt, legt das Fundament für einen Piloten, der funktioniert.

Die drei Schichten der Prozessaufnahme:

Schicht 1 — Der dokumentierte Prozess: Was ist schriftlich festgelegt? Arbeitsanweisungen, SOPs, Handbücher. Diese Schicht ist die einfachste zu erfassen — aber erfahrungsgemäß am weitesten von der Realität entfernt.

Schicht 2 — Der gelebte Prozess: Was machen die Mitarbeitenden wirklich? Wo weichen sie vom dokumentierten Prozess ab, und warum? Diese Schicht erfordert Beobachtung und Interview. Sie ist die relevanteste Schicht für die KI-Aufgabendefinition.

Schicht 3 — Das implizite Expertenwissen: Welche Entscheidungen treffen erfahrene Mitarbeitende intuitiv, ohne sie explizit verbalisieren zu können? Diese Schicht ist die schwierigste zu erfassen — und sie ist genau das, was bei komplexeren Automatisierungsvorhaben den Unterschied macht. Structured Knowledge Elicitation (SKE) ist der Fachbegriff für die Methodik, dieses Wissen explizit zu machen.

SIPOC erweitert: Die 5-W-SIPOC-Methode

Das klassische SIPOC-Modell (Suppliers → Inputs → Process → Outputs → Customers) kann durch die 5-W-Fragen erheblich angereichert werden, um den Digitalisierungsreifegrad und das KI-Potenzial eines Prozesses schärfer zu bewerten:

Die Antworten auf diese Fragen führen direkt in die KI-Potenzialmatrix (UE 86): Häufigkeit (H), Regelbasiertheit (R) und Wert (W) lassen sich aus einem guten SIPOC-Interview ableiten.

Value Stream Mapping: Die digitale Erweiterung

Das klassische VSM aus dem Lean-Management wurde für physische Produktionsprozesse entwickelt. Bei der Anwendung auf digitale Informationsprozesse (Sachbearbeitung, Datenverarbeitung, Kommunikations-Workflows) gelten ergänzende Konventionen:

Digitale Symbole im VSM: - Datenspeicher (Datenbank, SharePoint, ERP-System) werden als Zylinder dargestellt - Automatisierte Übergaben (API, ETL, RPA) werden als Blitz-Pfeil markiert - Manuelle Medienbrüche (Copy-Paste, PDF-Druck-Scan) werden explizit als Warteschlange mit Taktzeit markiert - KI-Kandidatenprozesse werden mit einem KI-Symbol markiert (optional: Ampelfarben nach Potenzial)

Die erweiterte VSM-Analyse für KI-Projekte: Neben den klassischen Lean-Metriken (Prozesszeit, Wartezeit, Durchlaufzeit) werden drei zusätzliche Dimensionen erhoben: 1. Fehlerrate — In welchem Schritt entstehen die meisten Fehler? (KI-Korrekturkandidaten) 2. Expertenwissen-Abhängigkeit — Welche Schritte hängen von einzelnen Personen ab? (Wissensrisiko = Kandidat für KI-Augmentation) 3. Ausnahmeanteil — Wie groß ist der Anteil der Fälle, die vom Standardprozess abweichen? (>30 % Ausnahmen = warnsignal)

Merksatz

Ein VSM, das nur die Standardfälle zeigt, ist unvollständig. Die KI-relevante Frage lautet immer auch: Was passiert bei Ausnahmen? Wenn 30 % aller Fälle außerhalb des Standardpfads behandelt werden müssen, liegt der tatsächliche Automatisierungsgrad des Prozesses nicht bei 80 %, sondern bei maximal 70 %. Diese Differenz entscheidet über Projektrisiko und Pilotdesign.

Branchen-Vertiefung Prozessaufnahme

IT-Dienstleistung & Beratung — Wissensdokumentation als Prozess: In Beratungsunternehmen ist das Asset nicht das Produkt, sondern das Wissen. Die Prozessaufnahme konzentriert sich auf Wissensprozesse: Wie entsteht ein Angebot? Wie wird Projektlernen dokumentiert? Wie funktioniert die Qualitätsprüfung einer Analyse? Der häufigste Befund: Wissen existiert in siloisierten Köpfen und wird nicht systematisch übertragen. VSM zeigt, wie viel Zeit für die Suche nach vorhandenem Wissen aufgewendet wird — ein klassischer KI-Kandidat für RAG-basierte Wissenssysteme.

Industrie & Fertigung — Linien-Audit und OEE-Analyse: In der Fertigung ist die Prozessaufnahme oft bereits durch OEE-Tracking (Overall Equipment Effectiveness) und Shopfloor-Management strukturiert. Die Herausforderung liegt im Übergang von aggregierten KPIs zu granularen Ereignisdaten. VSM wird durch Maschinenlog-Analyse ergänzt: Welche Events im Maschinenlog korrespondieren mit welchen VSM-Schritten? Diese Verbindung ist die Grundlage für Predictive-Maintenance-KI.

Finanzdienstleistung & Versicherung — Regulierte Prozesse und Audit-Trails: In regulierten Finanzprozessen ist die Prozessaufnahme durch Compliance-Anforderungen anspruchsvoller: Jeder Prozessschritt muss nicht nur beschrieben, sondern auch hinsichtlich seiner regulatorischen Anforderungen annotiert werden (MaRisk, IDD, DSGVO). Das SIPOC wird um eine Compliance-Spalte erweitert. VSM zeigt häufig, dass ein erheblicher Teil der Durchlaufzeit in Compliance-Checks fließt — ein Bereich, in dem KI-gestützte Regulatory-Technology-Lösungen (RegTech) erhebliche Effizienzgewinne bringen.

Öffentliche Verwaltung — Geschäftsprozessmanagement nach E-Government-Standards: Verwaltungen haben oft formalisierte Prozessdokumentationen (PICTURE-Notation, BPMN) — aber diese sind häufig veraltet und spiegeln den tatsächlichen gelebten Prozess nicht wider. Die besondere Herausforderung: Verwaltungsprozesse sind durch Gesetze und Verwaltungsvorschriften stark reglementiert. Die Prozessaufnahme muss zeigen, welche Prozessschritte durch Rechtsvorschriften vorgeschrieben sind (nicht automatisierbar) und welche Schritte lediglich Konvention oder historisch gewachsene Praxis sind (Automatisierungskandidaten).

Vertiefung UE 86 — KI-Potenzialmatrix: Dimensionen, Skalierung und Validierung

Die Validierungsproblematik bei der H×R×W-Bewertung

Die größte Herausforderung bei der Anwendung der KI-Potenzialmatrix ist die Interrater-Reliabilität: Verschiedene Personen aus demselben Team bewerten dieselben Dimensionen oft erheblich unterschiedlich. Studien aus dem Operations-Research-Bereich zeigen, dass Abweichungen von 2–3 Punkten auf einer 5-Punkte-Skala bei subjektiven Bewertungen ohne Kalibrierung normal sind. Das macht unkalibrierten Matrixbewertungen unbrauchbar.

Kalibrierungsmethode für Teams:

Schritt 1 — Referenzprozesse festlegen: Vor dem eigentlichen Bewertungs-Workshop werden 2–3 bekannte Referenzprozesse benannt und bewertet, über die alle Beteiligten gut informiert sind. Diese dienen als Kalibrierungsanker.

Schritt 2 — Bewertungskriterien operationalisieren: Die drei Dimensionen H, R und W werden nicht abstrakt bewertet, sondern anhand konkreter Messkriterien:

Schritt 3 — Divergenz-Protokoll: Bei Bewertungsabweichungen von mehr als 2 Punkten auf einer Dimension wird eine 5-Minuten-Diskussion strukturiert nach dem Format: „Welche Information hat Person A, die Person B nicht hat?” Diese Frage verhindert Dominanz durch Hierarchie und fördert echten Wissensaustausch.

Erweiterte Matrixdimension: KI-Bereitschaft (Readiness, R2)

Neben den drei klassischen Dimensionen H×R×W empfiehlt die aktuelle Literatur eine vierte Dimension: KI-Bereitschaft (Readiness, R2), die die Daten- und Infrastrukturvoraussetzungen bewertet.

KI-Bereitschaft-Score (R2) — Bewertungskriterien:

Ein Prozess mit hohem H×R×W-Score aber niedrigem R2-Score (schlechte Datenlage) ist ein risikoreicher Use Case — er ist attraktiv, aber noch nicht reif für die Implementierung. Die R2-Dimension trennt kurzfristige von mittelfristigen Use Cases im Portfolio.

Merksatz

Die H×R×W-Matrix zeigt, wo KI Wert schafft. Die R2-Dimension zeigt, ob Sie heute starten können. Projekte mit hohem H×R×W und niedrigem R2 landen auf der Roadmap — nicht im Pilot. Projekte mit hohem H×R×W und hohem R2 sind Ihre Quick-Wins. Dieser Unterschied ist entscheidend für eine realistische Portfolio-Steuerung.

Von der Matrix zur Portfolio-Entscheidung: Das Use-Case-Portfolio-Quadrantenmodell

Die H×R×W-Matrix liefert einen Einzelprozess-Score. Für ein Portfolio von 10–20 Use Cases ist eine Portfolio-Visualisierung nötig. Das Use-Case-Portfolio-Quadrantenmodell überträgt den Matrix-Score in eine 2×2-Matrix mit den Achsen:

X-Achse: Implementierungsaufwand (niedrig bis hoch)

Y-Achse: Strategischer Wert (niedrig bis hoch)

Die vier Quadranten:

Quadrant 1 — Quick Wins (niedrig/hoch): Hoher Wert, geringer Aufwand. Sofort starten. Signalwirkung für das Programm.

Quadrant 2 — Strategische Investitionen (hoch/hoch): Hoher Wert, hoher Aufwand. Mittelfristig planen. Gründliches Pilot-Design.

Quadrant 3 — Füller (niedrig/niedrig): Niedriger Wert, geringer Aufwand. Nur wenn Kapazität vorhanden. Nicht priorisieren.

Quadrant 4 — Vermeiden (hoch/niedrig): Hoher Aufwand, geringer Wert. Ablehnen oder auf später verschieben.

Vertiefung UE 87 — Use-Case-Canvas: Vollständigkeit, Qualitätssicherung und Pitching

Der Canvas als Kommunikationsinstrument

Ein Use-Case-Canvas erfüllt drei verschiedene Kommunikationsfunktionen, je nach Zielgruppe:

Funktion 1 — Interne Strukturierung (Projektteam): Der Canvas zwingt das Team, alle relevanten Aspekte zu durchdenken, bevor mit der Umsetzung begonnen wird. Er verhindert den häufigen Fehler, Details in der Umsetzungsphase zu klären, die besser in der Konzeptionsphase geklärt werden sollten.

Funktion 2 — Stakeholder-Kommunikation (Fachbereich, IT): Der Canvas ist ein strukturiertes Kommunikationsdokument, das es ermöglicht, einen Use Case in einem 10-Minuten-Meeting vollständig zu präsentieren. Jedes Canvas-Feld entspricht einer typischen Stakeholder-Frage.

Funktion 3 — Entscheidungsvorlage (Management, KI-Ausschuss): Der Canvas ist die Vorlage für die Entscheidung über die Aufnahme in das Pilot-Portfolio. Er muss ausreichend detailliert sein, dass Entscheidende das Risiko-Nutzen-Verhältnis beurteilen können, ohne den Canvas-Erstellern detaillierte Fragen stellen zu müssen.

Qualitäts-Checkliste für Canvas-Vollständigkeit (7 Felder, 14 Kriterien):

Die häufigsten Canvas-Fehler (und wie man sie verhindert)

Fehler 1 — Zu breites Problem-Statement: „Wir möchten unsere Effizienz steigern” ist kein Problem-Statement. Ein gutes Problem-Statement ist: „Die manuelle Rechnungsprüfung belegt 3,5 VZÄ und erzeugt 12 % Fehlerquote mit durchschnittlichen Korrekturen von 8 Stunden je Fall.”

Fehler 2 — Technologie vor Problem: Teams beschreiben die Lösung, ohne das Problem klar artikuliert zu haben. Der Canvas verhindert das durch seine Reihenfolge — aber nur, wenn der Trainer die Einhaltung der Reihenfolge moderiert.

Fehler 3 — Unrealistische Nutzenschätzungen: Nutzenangaben ohne methodische Herleitung (Benchmarks, interne Zeitstudien) werden im Management-Review abgelehnt. Best Practice: Konservative, mittlere und optimistische Schätzung als Bandbreite angeben.

Fehler 4 — Governance-Feld wird ausgelassen: Unter Zeitdruck wird das Governance-Feld als nachrangig behandelt. Das ist ein kritischer Fehler — Governance-Klasse Rot (verbotene KI-Anwendung) kann die gesamte Investition gefährden.

Merksatz

Der Canvas ist nur so gut wie sein schwächstes Feld. Ein exzellentes Problem-Statement mit leerem Governance-Feld ist kein vollständiger Canvas — es ist ein halbfertiges Konzept mit verstecktem Compliance-Risiko. Behandeln Sie alle 7 Felder mit gleicher Sorgfalt.

Vertiefung UE 88 — Priorisierung: Methoden-Vergleich und Entscheidungsarchitektur

ICE vs. RICE vs. Nutzwertanalyse: Wann welche Methode?

Die Wahl der Priorisierungsmethode ist keine rein methodische, sondern auch eine organisatorische Entscheidung. Verschiedene Methoden passen zu verschiedenen Reifegraden und Entscheidungskulturen:

ICE-Score (Impact × Confidence × Ease): - Anwendungskontext: Frühe Phasen, hohe Unsicherheit, schnelle erste Priorisierung nötig - Stärken: Schnell, einfach, ausreichend für erste Triage - Schwächen: Confidence als Dimension lädt zur Selbstüberschätzung ein; Bias toward confident assessors - Empfehlung: Erste Screening-Runde mit 15–20 Use-Case-Kandidaten

RICE-Score (Reach × Impact × Confidence ÷ Effort): - Anwendungskontext: Produkt-Teams, mittlerer Reifegrad, erste Datenbasis vorhanden - Stärken: Berücksichtigt Reichweite (Nutzerzahl), was bei Mitarbeiter-Tools wichtig ist - Schwächen: Effort in der Nennerposition kann große Projekte mit hohem Reach systematisch benachteiligen - Empfehlung: Zweite Bewertungsrunde nach ICE-Vorfilter für Top-10 Kandidaten

Nutzwertanalyse (Weighted Scoring): - Anwendungskontext: Reifere Organisationen, mehrere Stakeholder-Gruppen mit verschiedenen Präferenzen, formale Entscheidungsdokumentation nötig - Stärken: Transparent, reproduzierbar, auditierbar; Gewichtungen machen organisationale Prioritäten explizit - Schwächen: Aufwändiger; Gewichtungsent scheidungen können politisch umkämpft sein - Empfehlung: Finale Entscheidungsrunde für Top-5 Use Cases, die in den Pilot aufgenommen werden sollen

Entscheidungsarchitektur für KI-Use-Case-Portfolios

Eine vollständige Entscheidungsarchitektur kombiniert die drei Methoden sequenziell:

Phase 1 — Generierung: Brainstorming und Canvas-Erstellung für 15–25 Use-Case-Kandidaten (UE 87)

Phase 2 — Grobbewertung: ICE-Score für alle Kandidaten (45 Minuten im Team) → Selektion: Top 10 nach ICE-Score

Phase 3 — Feinbewertung: RICE-Score für Top-10 Kandidaten mit Datenbasis (90 Minuten) → Selektion: Top 5 nach RICE-Score

Phase 4 — Finale Priorisierung: Nutzwertanalyse mit gewichteten Organisationspräferenzen → Entscheidung: Pilot-Portfolio (3–5 Use Cases)

Diese sequenzielle Architektur reduziert den Gesamtaufwand erheblich, da aufwändigere Methoden nur auf eine kleine Kandidatenzahl angewendet werden — während gleichzeitig methodische Robustheit für die finale Entscheidung gewährleistet ist.

Merksatz

Priorisierung ist eine Entscheidung über Ressourcen unter Unsicherheit. Keine Methode eliminiert diese Unsicherheit — jede Methode macht sie sichtbarer und handhabbarer. Der Wert von ICE, RICE und Nutzwertanalyse liegt nicht darin, die „richtige” Antwort zu geben, sondern darin, die Diskussion über die richtigen Fragen zu strukturieren. Die Entscheidung selbst bleibt beim Team — die Methode unterstützt, ersetzt aber nicht das Urteilsvermögen.

Vertiefung UE 89 — Build vs. Buy vs. Configure: Strategische Tiefe

Die Total-Cost-of-Ownership-Analyse für alle drei Optionen

Der häufigste Fehler bei der Build-vs.-Buy-Entscheidung ist der Vergleich von direkten Kosten (Lizenzpreis vs. Entwicklungsbudget), ohne die Gesamtbetriebskosten über den vollen Lebenszyklus zu berücksichtigen. Eine vollständige TCO-Analyse über 3 Jahre muss folgende Kostenblöcke einschließen:

TCO-Struktur Build (Eigenentwicklung):

TCO-Struktur Buy (SaaS-Kauf):

Beobachtung: Buy hat höhere Jahr-1-Kosten (Implementierung und Schulung) — ist aber langfristig oft günstiger, weil keine laufende Wartungs- und Weiterentwicklungsbelastung entsteht. Build wird langfristig teuer, weil technische Schulden und Wartungsaufwand mit der Zeit exponentiell steigen.

Die fünf strategischen Kriterien jenseits von TCO

TCO-Analyse allein ist für die Build-vs.-Buy-Entscheidung unzureichend. Fünf strategische Kriterien müssen zusätzlich bewertet werden:

1. Differenzierungspotenzial: Ist der zu lösende Prozess ein Wettbewerbsvorteil (→ Build/Configure) oder eine Commodity-Funktion (→ Buy)?

2. Datenkontrolle: Wie sensitiv sind die verarbeiteten Daten? Buy bedeutet oft, Daten an externe Anbieter zu übergeben. Für kritische Unternehmens- oder Kundendaten kann das ein Ausschlusskriterium sein.

3. Time-to-Value: Wie schnell muss die Lösung produktiv sein? Buy-Lösungen sind oft in 4–8 Wochen implementierbar. Build dauert selten unter 6 Monate.

4. Interne Entwicklungskapazität: Verfügen Sie über interne Entwickler mit KI-Kompetenz? Ohne diese Kapazität ist Build-Entscheidungen illusorisch.

5. Strategische Flexibilität: Wie stark verändert sich Ihr Anforderungsprofil voraussichtlich? Sehr veränderliche Anforderungen sprechen für konfigurierbare Plattformen (Configure-Option) — da spezifische Build-Lösungen schnell veralten.

Merksatz

Build ist fast immer teurer als gedacht, Buy ist fast immer weniger flexibel als erhofft, und Configure ist fast immer die robusteste Wahl für den Mittelstand und die öffentliche Verwaltung — wenn die Plattformwahl sorgfältig erfolgt. Die Entscheidung ist keine technische, sondern eine strategische.

Vertiefung UE 90 — Datenqualität: Messverfahren, Governance und Lösungsstrategien

Der Data-Quality-Score: Sechs Dimensionen systematisch messen

Datenqualität ist kein binäres Attribut (gut/schlecht), sondern ein mehrdimensionales Konstrukt. Der international anerkannte DAMA-Standard definiert sechs Kerndimensionen der Datenqualität, die für KI-Projekte besonders relevant sind:

Data-Quality-Score-Berechnung: Jede Dimension wird auf 0–100 skaliert. Der Gesamtscore ist der gewichtete Durchschnitt (Gewichtung nach KI-Use-Case-Spezifik). Ein Score ≥85 gilt als KI-bereit; Score 70–84 als bedingt bereit (Bereinigung nötig); Score <70 als nicht bereit (fundamentale Aufbereitung erforderlich).

Daten-Governance als Enabler für KI-Skalierung

Einmalige Datenbereinigung für einen Piloten ist kein nachhaltiger Ansatz. Ohne Daten-Governance-Strukturen verschlechtert sich die Datenqualität nach der Bereinigung systematisch wieder. Die drei Säulen einer KI-enabling Daten-Governance sind:

Säule 1 — Data Ownership: Für jede datenhaltende Anwendung (ERP, CRM, DMS) gibt es einen benannten Data Owner (Fachbereichs-Verantwortlichen, kein IT-Mitarbeiter). Der Data Owner ist zuständig für die Qualität der Daten in seinem Bereich und hat Entscheidungsrecht über Daten-Schema-Änderungen.

Säule 2 — Datenqualitäts-Monitoring: Automatisierte Quality-Checks laufen täglich/wöchentlich und berichten an Data Owners. Qualitätsprobleme werden nicht manuell eskaliert, sondern durch Dashboards sichtbar gemacht. Qualitätsrückgänge unter einen definierten Schwellenwert lösen automatisch Tickets im Helpdesk-System aus.

Säule 3 — Daten-Catalog: Ein Metadaten-Katalog dokumentiert alle relevanten Datenquellen (Felder, Bedeutungen, Qualitäts-Scores, Zugriffsrechte, Datenschutzklassifizierung). Dieser Katalog ist die Grundlage für jede neue KI-Use-Case-Bewertung und erspart wiederholte Datenerhebungs-Workshops.

Merksatz

KI skaliert nur so schnell wie die Daten-Governance wächst. Organisationen, die jeden KI-Use-Case mit einer neuen Datenbereinigungskampagne starten müssen, werden KI nie über den Pilot-Status hinausführen. Nachhaltige KI-Skalierung erfordert Daten-Governance als strategische Infrastruktur — nicht als Projektzubehör.

Vertiefung UE 91 — Pilot-Design: Wissenschaftliche Grundlagen und Praxisdesign

Das Hypothesen-Framework für KI-Piloten

Ein wissenschaftlich fundiertes Pilot-Design basiert auf expliziten, falsifizierbaren Hypothesen. Die Formulierungsqualität der Hypothese entscheidet über die Auswertbarkeit des Piloten.

Hypothesen-Template (empfohlen):

„Wenn [KI-Intervention X] auf [Zielgruppe Y] in [Kontext Z] angewendet wird, dann verbessert sich [KPI M] von [Baseline-Wert] auf [Zielwert] innerhalb von [Zeitraum T], gemessen durch [Messmethode].”

Beispiel-Hypothesen nach Branche:

IT-Dienstleistung: „Wenn Berater ein RAG-basiertes Wissenssystem für Angebotserstellung nutzen, dann reduziert sich die Angebotserstellungszeit von durchschnittlich 4,2 Stunden auf unter 2,5 Stunden innerhalb von 6 Wochen, gemessen durch Zeitstempel im CRM-System.”

Industrie & Fertigung: „Wenn das Predictive-Maintenance-Modell auf Produktionslinie 3 angewendet wird, dann reduzieren sich ungeplante Stillstände von 12 Ereignissen/Quartal auf unter 6 Ereignisse/Quartal innerhalb von 3 Monaten, gemessen durch das Produktions-MES.”

Finanzdienstleistung: „Wenn KI-gestützte Prüfassistenz in der Kreditantragsprüfung eingesetzt wird, dann sinkt die mittlere Prüfzeit je Antrag von 47 Minuten auf unter 25 Minuten innerhalb von 8 Wochen, gemessen durch das Workflow-Management-System.”

Öffentliche Verwaltung: „Wenn KI-Assistenz bei der Bearbeitung von Fördermittelanträgen eingesetzt wird, dann reduziert sich die Bearbeitungszeit je Antrag von 3,2 Arbeitstagen auf unter 1,8 Arbeitstagen innerhalb von 12 Wochen, gemessen durch das Vorgangsbearbeitungssystem.”

KPI-Design für KI-Piloten: Die Dreischicht-Architektur

KI-Pilot-KPIs sollten in drei Schichten strukturiert werden, um sowohl operative als auch strategische Erfolgsmessungen zu gewährleisten:

Schicht 1 — Aktivitäts-KPIs (Leading Indicators): Messen, ob die KI-Lösung genutzt wird. - Nutzungsrate (% der Zielgruppe, die das Tool nutzt) - Sitzungsfrequenz (Nutzungen pro Person pro Woche) - Aufgabenabschlussrate (% der gestarteten Aufgaben, die abgeschlossen werden)

Schicht 2 — Output-KPIs (Hypothesen-KPIs): Messen, ob der definierte Nutzen eintritt. - Zeitersparnis (gemessen, nicht geschätzt) - Fehlerrate (vor vs. nach KI-Unterstützung) - Bearbeitungsgeschwindigkeit (Throughput)

Schicht 3 — Outcome-KPIs (Strategische Wirkung): Messen, ob die organisationale Wirkung eintritt. - Kundenzufriedenheit (NPS, CSAT) in betroffenen Bereichen - Mitarbeiterzufriedenheit (eNPS) der Pilotgruppe - Weiterempfehlungsrate der Pilotgruppe (Would use again? Would recommend?)

Abbruchkriterien-Design: Abbruchkriterien müssen vor dem Pilot definiert werden — nicht während. Die drei Standard-Abbruchkriterien für KI-Piloten:

Nutzungs-Abbruch: Nutzungsrate sinkt nach Woche 3 unter 30 % der Zielgruppe → Sofortiger Stopp und Ursachenanalyse

Qualitäts-Abbruch: Fehlerrate durch KI-Output überschreitet Fehlerrate ohne KI → Sofortiger Stopp

Zeit-Abbruch: Nach 60 % der geplanten Pilotdauer kein messbarer Effekt bei einem einzigen Output-KPI → Strukturierte Entscheidung über Fortsetzung oder Abbruch

Merksatz

Ein Pilot ohne vorab definierte Abbruchkriterien ist kein Pilot — es ist ein Projekt ohne Exitstrategie. Abbruchkriterien machen den Mut sichtbar, in der Mitte aufzuhören, wenn die Evidenz das verlangt. Diese Bereitschaft ist das stärkste Signal für eine lernende Organisation.

Vertiefung UE 92 — Change-Management: Tiefe Theorie und Praxisinstrumente

Kotter vs. Prosci: Die zwei dominanten Change-Frameworks im Vergleich

Für KI-Transformationen sind zwei Frameworks besonders relevant:

Kotter’s 8-Stufen-Modell ist ein sequenzielles Top-Down-Modell, das besonders für Organisationsveränderungen mit starkem Führungsimpuls geeignet ist. Die 8 Stufen (Dringlichkeit erzeugen → Führungskoalition aufbauen → Vision entwickeln → Vision kommunizieren → Hindernisse beseitigen → Kurzfristige Erfolge generieren → Erfolge konsolidieren → Veränderung verankern) entsprechen dem klassischen KI-Programm-Zyklus über 12–18 Monate.

Prosci ADKAR-Modell ist ein individuumszentriertes Modell, das Veränderung als persönlichen Lernprozess jedes einzelnen Mitarbeitenden betrachtet. ADKAR steht für: Awareness (Bewusstsein für die Notwendigkeit) → Desire (Wunsch, mitzumachen) → Knowledge (Wissen, wie man es tut) → Ability (Fähigkeit, es umzusetzen) → Reinforcement (Verstärkung zur Nachhaltigkeit).

Für KI-Projekte empfohlene Kombination: - Kotter für die Programm-Ebene (organisationale Dynamik, Leadership, Kommunikation) - ADKAR für die Mitarbeiter-Ebene (individuelle Change-Readiness, Schulungsdesign, Coaching)

Diese Kombination macht Change-Management messbar: Für jede Pilotgruppe kann ein ADKAR-Score erhoben werden, der zeigt, auf welchem Stufe die meisten Personen stecken — und welche Intervention (mehr Kommunikation? mehr Schulung? mehr Übungszeit?) nötig ist.

Das Widerstandskreis-Modell für KI-spezifische Einwände

KI-Change-Management hat gegenüber klassischem Change-Management eine Besonderheit: Die Einwände der Beteiligten sind oft nicht gegen die Veränderung als solche gerichtet, sondern gegen spezifische KI-Ängste, die eigener Adressierung bedürfen.

Das Widerstandskreis-Modell unterscheidet vier Typen von KI-Einwänden:

Typ 1 — Kompetenzangst: „Ich kann das nicht bedienen. Die Technologie ist zu komplex.” → Intervention: Niedrigschwellige Einstiegsschulung, Hands-on-Demos, Peer-Lernen mit Early Adopters.

Typ 2 — Relevanzangst: „Wenn KI das macht, braucht das Unternehmen mich nicht mehr.” → Intervention: Ehrliche Kommunikation über Rollenentwicklung; Fokus auf Aufwertung, nicht Ersatz; Erfolgsgeschichten von Augmentation statt Substitution.

Typ 3 — Qualitätsangst: „Die KI macht Fehler. Ich kann den Outputs nicht vertrauen.” → Intervention: Transparenz über Modell-Limitierungen; Human-in-the-Loop-Design zeigen; Fehleranalyse aus dem Piloten teilen.

Typ 4 — Datenschutzangst: „Was passiert mit meinen Daten und den Kundendaten?” → Intervention: DSGVO-Compliance-Nachweis; Datenverarbeitungsvereinbarungen zeigen; klare Kommunikation, welche Daten wie verarbeitet werden.

Merksatz

KI-Widerstand ist oft kein Widerstand gegen KI als Technologie, sondern gegen Unsicherheit über persönliche Konsequenzen. Wer die vier Widerstandstypen kennt, kann sie adressieren, bevor sie zu Projektsaboteuren werden. Die beste KI-Technologie scheitert an unbehandeltem Typ-2-Widerstand.

Vertiefung UE 93 — KI-Governance: Regulatorische Tiefe und Praxis-Frameworks

EU AI Act 2025: Vollständige Risikotypologie und Umsetzungsfristen

Der EU AI Act (in Kraft seit August 2024, schrittweise Anwendung bis 2027) definiert vier Risikoklassen mit unterschiedlichen Anforderungen:

Klasse 1 — Verbotene KI (Artikel 5): Diese Anwendungen sind ab Februar 2025 vollständig verboten. Dazu gehören: Social Scoring durch öffentliche Behörden, biometrische Echtzeitüberwachung im öffentlichen Raum (mit engen Ausnahmen), Manipulation durch unbewusste Subliminal-Techniken, Ausnutzung von Vulnerabilitäten (Alter, Behinderung), Emotionserkennung am Arbeitsplatz und in Bildungseinrichtungen.

Klasse 2 — Hochrisiko-KI (Anhang III): Diese Anwendungen erfordern ab August 2026 (Deployer) und früher (Provider) umfangreiche Compliance-Maßnahmen: Risikobewertungs-System, Qualitätssicherungs-System, technische Dokumentation, Konformitätsbewertung, EU-Datenbankregistrierung, Transparenzpflichten. Hochrisiko-Anwendungen umfassen u.a.: KI in kritischer Infrastruktur, Bildung/Berufsausbildung, Beschäftigung/Personalmanagement, wesentliche private und öffentliche Dienstleistungen, Strafverfolgung, Asyl/Migration, Rechtspflege.

Klasse 3 — Begrenzte Risiken (Artikel 50): Transparenzpflichten gelten ab August 2025. KI-Systeme, die mit Personen interagieren (Chatbots), müssen deren KI-Natur offenlegen. Deepfake-Inhalte müssen als KI-generiert gekennzeichnet werden.

Klasse 4 — Minimales Risiko: Keine spezifischen Anforderungen. Die meisten B2B-internen KI-Anwendungen (Prozessoptimierung, interne Wissenssysteme) fallen in diese Kategorie.

Praktische Umsetzungsschritte für Deployer (Unternehmen, die KI einsetzen):

KI-Inventar: Alle eingesetzten KI-Systeme katalogisieren (Anbieter, Systemtyp, Einsatzzweck, verarbeitete Daten)

Risikobewertung: Risikoklassifizierung nach EU AI Act für jedes System

Hochrisiko-Compliance: Für Hochrisiko-KI: Dokumentation, Human-Oversight-Mechanismen, Mitarbeiterschulung

Vertragsgestaltung: Sicherstellen, dass KI-Anbieterverträge die nötigen Transparenz- und Compliance-Informationen enthalten

Governance-Struktur: KI-Beauftragten benennen (intern oder extern), Governance-Handbuch erstellen

Merksatz

Der EU AI Act unterscheidet zwischen Providern (die KI entwickeln) und Deployern (die KI einsetzen). Als Deployer tragen Unternehmen eigene Compliance-Pflichten — auch wenn sie KI nur einkaufen. Das Motto „Der Anbieter ist verantwortlich” ist rechtlich falsch. Wer entscheidet, KI in einem Hochrisiko-Kontext einzusetzen, übernimmt Deployer-Pflichten.

Das KI-Governance-Handbuch: Struktur und Inhalte

Ein KI-Governance-Handbuch ist das zentrale Steuerungsdokument für den verantwortungsvollen KI-Einsatz in der Organisation. Es enthält:

Kapitel 1 — Grundsätze und Werte: Organisationale KI-Ethikprinzipien (z.B. Human-Oversight, Fairness, Transparenz, Datenschutz), abgeleitet aus EU AI Act und unternehmenseigenen Werten.

Kapitel 2 — Governance-Struktur: KI-Ausschuss (Zusammensetzung, Entscheidungsbefugnisse), KI-Beauftragter (Rolle, Verantwortlichkeiten), KI-Prüfprozess (wer prüft was vor Go-Live).

Kapitel 3 — Risikoklassifizierung: Drei-Stufen-Freigabemodell (Grün/Gelb/Rot) mit konkreten Kriterien für jede Stufe und zugehörigen Freigabeprozessen.

Kapitel 4 — Use-Case-Prüfprozess: Checkliste für jeden neuen KI-Use Case: DSGVO-Prüfung, EU-AI-Act-Klassifizierung, Datensicherheits-Assessment, Human-Oversight-Design, Audit-Trail-Anforderungen.

Kapitel 5 — Monitoring und Review: Wie wird laufend überprüft, dass KI-Systeme wie gewünscht funktionieren? KPI-Monitoring, Bias-Checks, periodische Reviews.

Kapitel 6 — Schulung und Kompetenz: Welche Schulungspflichten gelten für welche Rollen? Wer muss was wissen?

Vertiefung UE 94 — KI-Roadmap: Planung, Steuerung und Anpassung

Die 12-Monats-Roadmap als Rolling-Wave-Plan

Die klassische Projekt-Roadmap ist ein lineares Dokument, das am Anfang des Jahres geschrieben und am Ende überprüft wird. Für KI-Programme ist dieser Ansatz ungeeignet, weil:

Technologieentwicklung zu schnell ist (neue Modelle, neue Plattformfunktionen)

Pilotlernen die Prioritäten verändert

Organisatorische Kapazitäten schwanken

Regulatorische Anforderungen sich weiterentwickeln

Das Rolling-Wave-Modell ist der geeignetere Ansatz: Die Roadmap wird quartalsweise in drei Detailierungsstufen geführt:

Quartal 1 (aktuell): Vollständig geplant, Woche für Woche. Alle Ressourcen zugeordnet, alle Meilensteine definiert.

Quartal 2–3: Auf Monatsbasis geplant. Hauptmeilensteine bekannt, Detailplanung erfolgt jeweils am Anfang des Quartals.

Quartal 4: Auf Quartalsebene geplant. Strategische Ziele bekannt, aber Implementierungsdetails folgen der Lernkurve aus Q1–Q3.

Der Rolling-Wave-Ansatz reduziert den Planungsaufwand für unsichere Zukunftszeiträume und konzentriert Detailplanung dort, wo Handlungssicherheit besteht.

Roadmap-Steuerung: Monatliche OKR-Check-ins für KI-Programme

OKR (Objectives and Key Results) ist das Steuerungsrahmenwerk, das für KI-Programme am besten zu Rolling-Wave-Planung passt. Die monatliche OKR-Review-Struktur für KI-Programme:

Objective: Was ist das strategische Ziel im nächsten Quartal? (Beispiel: „KI-Assistenz in zwei Kernprozessen live bringen, Mitarbeitende befähigen und erste Nutzenbasisdaten gewinnen”)

Key Result 1 (Umsetzung): Pilot in Prozess A läuft; Nutzungsrate >50 % der Zielgruppe nach 4 Wochen.

Key Result 2 (Lernen): Erste Nutzen-KPIs gemessen und dokumentiert; Abweichung von Hypothese <20 %.

Key Result 3 (Befähigung): 80 % der Pilotgruppe hat Basis-KI-Schulung abgeschlossen; Kompetenzcheck bestanden.

Monthly Review-Agenda (60 Minuten): - 15 min: KR-Status (Ampel für jedes KR) - 20 min: Lernpunkte aus Piloten (was hat überrascht?) - 15 min: Priorisierungs-Entscheidungen (was ändert sich am Plan?) - 10 min: Action Items (nächste 30 Tage, Verantwortliche)

Merksatz

Eine Roadmap, die im Januar geschrieben und im Dezember beurteilt wird, ohne monatliche Anpassung, ist ein Wunschzettel. Eine Rolling-Wave-Roadmap mit monatlichen OKR-Check-ins ist ein Steuerungsinstrument. Der Unterschied ist nicht das Dokument — der Unterschied ist die Disziplin der regelmäßigen Überprüfung und Anpassung.

Vertiefung UE 95 — Business Case: Finanzmathematik und Präsentationslogik

Die drei Szenarien-Methodik für KI-Business-Cases

Einen Business Case mit einem einzigen Szenario zu präsentieren, ist sowohl methodisch schwach als auch strategisch unklug: Methodisch schwach, weil Prognosen unter Unsicherheit immer Bandbreiten haben. Strategisch unklug, weil ein zu optimistischer Business Case das Vertrauen der Entscheider zerstört, wenn er nicht eintrifft — und ein zu konservativer Business Case gute Projekte verhindert.

Die Drei-Szenarien-Methodik ist die professionelle Alternative:

Szenario 1 — Pessimistisch (Conservative Base): - Adoption Rate: 40 % der Zielgruppe - Zeitersparnis: 50 % der prognostizierten Einsparung - Implementierungskosten: 150 % des Budgets - Ergebnis: Minimal-ROI, Break-Even erst nach 24–30 Monaten

Szenario 2 — Realistisch (Central Case): - Adoption Rate: 65 % der Zielgruppe - Zeitersparnis: 80 % der prognostizierten Einsparung - Implementierungskosten: 110 % des Budgets - Ergebnis: Positiver ROI, Break-Even nach 12–18 Monaten

Szenario 3 — Optimistisch (Upside Case): - Adoption Rate: 85 % der Zielgruppe - Zeitersparnis: 100 % der prognostizierten Einsparung - Implementierungskosten: 100 % des Budgets - Ergebnis: Starker ROI, Break-Even nach 8–12 Monaten

Die Entscheidungs-Frage bei Drei-Szenarien: Das Management trifft die Investitionsentscheidung auf Basis des pessimistischen Szenarios — ist der ROI auch im Worst Case noch akzeptabel? Diese Fragestellung ist die professionellste Investitionsrationalität für KI-Programme.

Vom Business Case zur Investitionsvorlage: Aufbaulogik

Eine Management-Investitionsvorlage für KI-Projekte (typisch: 4–6 Folien oder 2–3 Seiten) folgt dieser Aufbaulogik:

Folie 1 — Executive Summary: Problem (1 Zahl), Lösung (1 Satz), ROI-Bandbreite (pessimistisch bis optimistisch), nächste Entscheidung (Was wird heute beschlossen?).

Folie 2 — Problem und Opportunity: Quantifizierter Schmerzpunkt, Vergleich mit Wettbewerbern oder Benchmarks, strategische Relevanz.

Folie 3 — Lösung und Implementierungsplan: Kurze Technologiebeschreibung (keine Details), Implementierungsphasen, wichtigste Abhängigkeiten.

Folie 4 — Finanzielle Projektion: TCO-Struktur, Drei-Szenarien-Übersicht, Break-Even-Tabelle, Sensitivitätsanalyse (Tornado-Diagramm).

Folie 5 — Risiken und Mitigationen: Top-3-Risiken mit Eintrittswahrscheinlichkeit und Mitigationsmaßnahmen.

Folie 6 — Entscheidungsvorlage: Was wird entschieden? Welches Budget wird freigegeben? Welche nächsten Schritte werden autorisiert?

Merksatz

Ein Business Case wird nicht mit dem besten Szenario beschlossen — er wird mit dem schlechtesten gerechtfertigt. Wenn der pessimistische ROI noch positiv ist und der Break-Even innerhalb des strategischen Planungshorizonts liegt, ist das Projekt investitionswürdig. Die optimistischen Szenarien zeigen das Upside-Potenzial — sie entscheiden nicht.

Vertiefung UE 96 — Workshop-Design: Facilitierung, Qualitätssicherung und Transfer

Die vollständige Facilitierungsmethodik für den 3-Use-Case-Workshop

Ein gut facilitierter 3-Use-Case-Workshop folgt einer präzisen Dramaturgie, die Kreativität (Ideengenerierung) mit Struktur (Canvas-Ausfüllung) und Konvergenz (Priorisierung) verbindet:

Phase 0 — Warm-up (5 Minuten): Jede Person nennt einen Prozess aus ihrem Alltag, der sie nervt — und erklärt in einem Satz, warum. Diese Runde erzeugt Aktivierung, löst Denkhemmungen und liefert oft die besten Use-Case-Rohentwürfe. Der Trainer notiert alle genannten Prozesse auf einer sichtbaren Fläche.

Phase 1 — Generierung (15 Minuten): Stille Einzelarbeit: Jede Person füllt einen Canvas-Entwurf aus. Der Trainer gibt nach 8 Minuten ein Signal: „Stellen Sie sicher, dass Ihr Problem-Statement eine Zahl enthält.” Nach 15 Minuten: Kurze Plenums-Runde, jede Person stellt ihren Canvas in 60 Sekunden vor (kein Feedback in dieser Phase).

Phase 2 — Clustering und Konsolidierung (10 Minuten): Ähnliche Use Cases werden zusammengeführt oder priorisiert. Bei 10 Teilnehmenden entstehen typischerweise 10–15 Canvas-Entwürfe, die zu 5–8 Clustern konsolidiert werden. Das Clustering erfolgt durch den Trainer mit kurzer Abstimmung in der Gruppe oder allein.

Phase 3 — ICE-Abstimmung (10 Minuten): Simultane ICE-Bewertung für alle Cluster (1–5 je Dimension, schriftlich auf Karte oder digital). Aggregation durch den Trainer. Kurze Diskussion nur bei Abweichungen >2 Punkte. Ergebnis: Ranking der Top-5 Use Cases.

Phase 4 — Canvas-Vertiefung für Top 3 (30 Minuten): Kleingruppen (2–3 Personen) vertiefen je einen der Top-3-Canvase. Fokus auf die schwächsten Felder (Datenbasis, Governance, Risiken). Trainer rotiert durch die Gruppen und gibt 5-Minuten-Feedback pro Gruppe.

Phase 5 — Präsentation und Konsolidierung (10 Minuten): Jede Kleingruppe präsentiert ihren vertieften Canvas in 3 Minuten. Plenum gibt in 2 Minuten Verbesserungs-Feedback. Trainer dokumentiert alle Canvase.

Phase 6 — Next Steps (5 Minuten): Jeder Use Case erhält einen Verantwortlichen und einen konkreten nächsten Schritt mit Datum innerhalb von 48 Stunden. Diese Commitments werden in der Gruppe oder allein ausgesprochen und dokumentiert.

Qualitäts-Standards für die drei abschließenden Steckbriefe

Die drei Use-Case-Steckbriefe, die aus dem Workshop hervorgehen, müssen folgende Qualitätsschwellen erfüllen, um als Transfer-ready zu gelten:

Steckbriefe, die diese Schwellen nicht erfüllen, sind nicht als Workshop-Output abgeschlossen — sie sind Arbeitsentwürfe, die nachgearbeitet werden müssen. Der Trainer kommuniziert diese Qualitätsschwellen zu Beginn des Workshops, damit alle Teilnehmenden die Ziellinie kennen.

Merksatz

Ein Workshop endet nicht, wenn die Zeit abläuft — er endet, wenn drei vollständige Steckbriefe mit Verantwortlichen und nächsten Schritten vorliegen. Wenn die Zeit ausläuft, bevor diese Schwelle erreicht ist, hat der Trainer die Zeitplanung falsch kalibriert. Die Qualitätsschwelle ist unverhandelbar — der Zeitplan ist anpassbar.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung als PDF anfordern.