Vertiefungsanhang — Ergänzende Lernmaterialien für Modul 8

Dieser Anhang enthält zusätzliche Vertiefungstexte, erweiterte Praxisbeispiele und weiterführende Übungsaufgaben für alle 12 UEs von Modul 8. Er richtet sich an Trainer, die in 90-minütigen Sitzungen arbeiten, sowie an Teilnehmende, die einzelne Themen vertiefen möchten.

UE 85 — Vertiefung: Remote-Prozess-Mapping und digitale Kollaboration

Digitale Werkzeuge für Remote-SIPOC und VSM-Sessions

Die Pandemie hat das Prozess-Mapping in Remote-Formate gezwungen — und dabei sich gezeigt, dass Remote-Workshops für Prozessaufnahmen bei richtiger Vorbereitung genauso effektiv sein können wie Präsenz-Sessions. Entscheidend sind drei Faktoren: das richtige Tool, eine klare Vorab-Struktur und eine aktive Moderationsrolle.

Miro: Das meistgenutzte digitale Whiteboard für Prozess-Workshops. Vorteile: Kostenlose Grundversion für kleine Teams, mobile Nutzung möglich, viele vorgefertigte SIPOC- und VSM-Templates. Nachteile: Benötigt eine kurze Eingewöhnung; Gruppen ohne vorherige Miro-Erfahrung verlieren in den ersten 10 Minuten wertvolle Zeit. Empfehlung: Schicken Sie den Teilnehmenden vorab einen 3-minütigen Walkthrough-Link.

Microsoft Whiteboard: In Microsoft-365-Organisationen die naheliegende Wahl. Direkte Integration in Teams-Meetings, keine separate Anmeldung erforderlich. Für SIPOC-Workshops ausreichend — für komplexe VSM-Visualisierungen sind die Template-Möglichkeiten im Vergleich zu Miro begrenzt.

FigJam (Figma): Für visuell anspruchsvolle Prozess-Diagramme geeignet. Besonders attraktiv, wenn das Ergebnis des Workshops in Präsentationen oder Berichte übernommen werden soll.

Entscheidungsregel für die Tool-Wahl: Wenn alle Teilnehmenden bereits Microsoft 365 nutzen → Microsoft Whiteboard. Wenn das Team visuell orientiert ist und Zeit für Tool-Einführung vorhanden ist → Miro. Wenn das Prozessdiagramm später in offiziellen Dokumenten genutzt werden soll → FigJam.

Merksatz

Das beste Tool für einen Prozess-Workshop ist das Tool, das die Teilnehmenden bereits kennen. Eine 30-minütige Tool-Einführung vor dem Workshop ist 30 Minuten weniger für den eigentlichen Inhalt — und erhöht die Frustration. Bei Remote-Workshops gilt: Simplicity first.

Die sieben Lean-Verschwendungsarten in der Wissensarbeit

Die klassischen sieben Verschwendungsarten nach Taiichi Ohno (Transport, Überproduktion, Wartezeit, Überbearbeitung, Bestände, Bewegung, Defekte) wurden für Fertigungsprozesse entwickelt. In der Wissensarbeit sind sie trotzdem anwendbar — aber die Beispiele sehen anders aus.

Transport in der Wissensarbeit: Informationen müssen von System A nach System B manuell übertragen werden, weil keine direkte Integration besteht. Beispiel: Kundendaten aus dem CRM werden manuell in eine Excel-Tabelle kopiert, von dort in ein Angebots-Template eingefügt und schließlich in das ERP-System übertragen. Jeder dieser Schritt ist Informations-Transport ohne Wertschöpfung.

Überproduktion in der Wissensarbeit: Ein Team erstellt wöchentlich einen detaillierten Statusbericht, den niemand liest. Oder: Ein Angebot wird auf 40 Seiten ausgearbeitet, obwohl der Kunde eine 5-seitige Executive Summary bevorzugen würde. Das Gegenmittel: Klärung, wer das Dokument wofür nutzt — bevor es erstellt wird.

Wartezeit in der Wissensarbeit: Ein Dokument liegt drei Tage in der Genehmigungsqueue, weil die verantwortliche Person auf einer Konferenz ist. Oder: Eine Anfrage wartet auf Antwort, weil niemand weiß, wer zuständig ist. Wartezeiten sind in der VSM als Lücken zwischen Prozessschritten sichtbar — oft erschreckend lang.

Überbearbeitung in der Wissensarbeit: Ein Bericht wird viermal von verschiedenen Personen überarbeitet, ohne dass jede Überarbeitung eine klar definierte Verbesserung einbringt. Oder: Präsentationen werden stundenlang poliert, bevor inhaltliche Rückmeldung von der Zielgruppe eingeholt wurde.

Bestände in der Wissensarbeit: Unbearbeitete E-Mails, aufgeschobene Aufgaben, halbfertige Dokumente in geteilten Laufwerken — das sind die Bestände der Wissensarbeit. Jedes unerledigte Arbeitselement bindet mentale Kapazität und erhöht das Risiko, vergessen zu werden.

Defekte in der Wissensarbeit: Falsche Annahmen im Angebot, die erst beim Kunden auffallen. Fehlerhafte Dateneingaben, die zwei Prozessschritte später zu Korrekturen zwingen. Defekte in der Wissensarbeit sind oft unsichtbar — sie werden erst dann sichtbar, wenn der Schaden bereits entstanden ist.

Merksatz

Eine KI kann Informations-Transport automatisieren (API-Integrationen), Wartezeiten reduzieren (asynchrone Bearbeitung), und Defekte verringern (strukturierte Output-Prüfung). Aber eine KI kann keine schlecht definierten Prozesse sinnvoll automatisieren. Die sieben Verschwendungsarten sind der Filter, der zeigt, was zu tun ist, bevor KI eingeführt wird.

SIPOC-Workshop: Typische Dynamiken und Moderationstipps

Ein SIPOC-Workshop mit einer gemischten Gruppe (Fachbereich + IT + Führungskraft) erzeugt regelmäßig bestimmte Dynamiken, die erfahrene Moderatorinnen und Moderatoren vorausahnen und steuern können.

Dynamik 1 — Der Detail-Sog: Sobald Prozessschritte notiert werden, beginnen Teilnehmende, jede Ausnahme und jeden Sonderfall zu ergänzen. Das SIPOC wird zur vollständigen Prozessdokumentation. Gegenmaßnahme: Einführen der „Häufigkeits-Regel”: Nur Schritte, die in mehr als 80 % der Fälle auftreten, kommen ins SIPOC.

Dynamik 2 — Der Supplier-Customer-Konflikt: Wer ist Supplier und wer ist Customer? In vielen Prozessen ist eine Abteilung gleichzeitig Customer des vorherigen Schritts und Supplier des nächsten. Das erzeugt Verwirrung. Gegenmaßnahme: Den Prozess aus der Perspektive des finalen Customers definieren — das gibt die Richtung vor.

Dynamik 3 — Die ungeklärte Zuständigkeit: Wenn das SIPOC eine Aufgabe aufdeckt, für die offensichtlich niemand zuständig ist (oder mehrere Personen gleichzeitig), entsteht Unbehagen. Gegenmaßnahme: Das SIPOC ist kein Ziel-Dokument — es beschreibt den Ist-Zustand. Die Zuständigkeitsfrage wird dokumentiert, aber nicht im Workshop gelöst.

Dynamik 4 — Der Silent Expert: Eine Person im Workshop kennt den Prozess am besten, spricht aber wenig. Gegenmaßnahme: Direkte Ansprache („Wie läuft das bei Ihnen konkret ab?“), und sicherstellen, dass diese Person die fertige SIPOC-Karte reviewt, bevor der Workshop endet.

UE 86 — Vertiefung: Kalibrierung der Potenzialmatrix und Risiko-Overlay

Warum die Potenzialmatrix kalibriert werden muss

Eine nicht kalibrierte Potenzialmatrix erzeugt systematische Verzerrungen. Die häufigste Verzerrung ist der „Enthusiasmus-Bias”: Teams, die gerade eine beeindruckende KI-Demo gesehen haben, bewerten Häufigkeit, Regelbasiertheit und Wert für alle Prozesse zu hoch. Das Ergebnis: Alle Use Cases landen in der oberen rechten Ecke der Matrix — und die Priorisierung ist nichts wert.

Kalibrierungsregel 1 — Externe Referenzwerte für Häufigkeit: Nutzen Sie echte Daten aus Ihren Systemen. Ein Prozess, der laut Einschätzung „täglich” vorkommt, wird in den Systemlogs vielleicht nur dreimal pro Woche ausgeführt. CRM-Auswertungen, Ticket-Systeme und ERP-Logs liefern objektive Häufigkeitsdaten.

Kalibrierungsregel 2 — Regelbasiertheit prüfen mit der Beschreibbarkeits-Frage: „Könnten Sie jemandem ohne Fachkenntnis in zwei Seiten genau beschreiben, wie dieser Prozessschritt entschieden wird?” Wenn die Antwort nein ist, ist der Prozess vermutlich nicht regelbasiert genug für vollständige KI-Automatisierung.

Kalibrierungsregel 3 — Wertschätzung durch externe Perspektive: Bitten Sie eine Person aus einem anderen Bereich, den eingeschätzten Wert eines Use Cases zu validieren. Insider-Teams überschätzen den Wert eigener Prozesse regelmäßig.

Die vierte Dimension — Strategische Passung: Neben den drei Grundachsen (Häufigkeit × Regelbasiertheit × Wert) empfiehlt sich eine vierte Bewertungsdimension: Strategische Passung. Passt dieser Use Case zur langfristigen Entwicklungsrichtung der Organisation? Schafft er Kompetenz in einem strategisch wichtigen Bereich — oder löst er ein isoliertes, kurzfristiges Problem? Use Cases mit hoher strategischer Passung erhalten einen Bonus-Punkt in der Gesamtbewertung.

Merksatz

Eine Potenzialmatrix, die auf Gruppeneinschätzung ohne externe Kalibrierung basiert, misst Enthusiasmus — nicht Potenzial. Mindestens eine Achse (vorzugsweise Häufigkeit) sollte durch objektive Daten aus Systemen untermauert werden, bevor der Matrix-Score als Priorisierungsgrundlage dient.

Das Risiko-Overlay: Wenn hoher Score nicht genug ist

Ein Use Case kann eine hohe Bewertung in allen drei Potenzialmatrix-Dimensionen haben — und trotzdem aus strategischen oder operativen Gründen nicht der richtige Startpunkt sein. Das Risiko-Overlay ergänzt die Potenzialmatrix um vier Risikodimensionen:

Risiko-Dimension 1 — Datenverfügbarkeit: Wie gut und zugänglich sind die benötigten Daten? Ein Use Case mit Score 75 und schlechter Datenbasis ist weniger vielversprechend als ein Use Case mit Score 55 und ausgezeichneter Datenbasis. Das Datenqualitäts-Audit aus UE 90 liefert die notwendige Information.

Risiko-Dimension 2 — Organisatorische Bereitschaft: Ist der betroffene Bereich Change-ready? Ein Bereich mit bekanntem Kulturwiderstand gegen Digitalisierung erhöht das Implementierungsrisiko — unabhängig vom technischen Potenzial.

Risiko-Dimension 3 — Technische Komplexität: Wie aufwändig ist die Integration? Ein Use Case, der sechs verschiedene Systemintegrationen erfordert, trägt ein erheblich höheres Implementierungsrisiko als ein Use Case auf einem bestehenden SaaS-Tool.

Risiko-Dimension 4 — Regulatorische Sensitivität: Gilt für den betroffenen Prozess besonderer Datenschutz, Compliance-Anforderungen oder Mitbestimmungsrechte? Regulatorisch sensible Use Cases erfordern längere Vorlaufzeiten und erhöhten Governance-Aufwand.

Jede Risiko-Dimension wird auf einer 1–3-Skala bewertet (1 = niedriges Risiko, 3 = hohes Risiko). Use Cases mit niedrigem Potenzial-Score, aber sehr niedrigem Risiko-Score, können als „Quick Wins” attraktiv sein, auch wenn sie in der Potenzialmatrix nicht führen.

UE 87 — Vertiefung: Use-Case-Canvas in der Praxis

Die häufigsten Canvas-Fehler und wie man sie vermeidet

Der Use-Case-Canvas ist das zentrale Spezifikationsdokument eines KI-Projekts. Aber ein Canvas, der schlecht ausgefüllt ist, ist gefährlicher als gar kein Canvas — er erzeugt falsche Sicherheit. Die fünf häufigsten Canvas-Fehler:

Fehler 1 — Problem-Statement ohne Zahl: „Der Angebotsprozess dauert zu lange” ist kein Problem-Statement. „Der Angebotsprozess dauert im Durchschnitt 4,5 Stunden — davon werden 2,8 Stunden für Routinerecherche aufgewendet, die automatisiert werden könnte” ist eines. Jedes Problem-Statement braucht mindestens eine Zahl.

Fehler 2 — Datenbasis-Feld zu vage: „Wir nutzen unsere internen Dokumente” ist keine ausreichende Datenbasis-Beschreibung. Die Datenbasis muss konkret sein: Welche Systeme? Welche Formate? Welche Aktualität? Wer ist für die Pflege verantwortlich?

Fehler 3 — KPI ohne Messbarkeit: Ein KPI, der nur nach dem Pilot qualitativ eingeschätzt werden kann, ist kein KPI. „Die Angebots-Qualität wird besser” ist kein messbarer KPI. „Die Angebots-Revisions-Rate (Anteil der Angebote, die nach Kundenfeedback überarbeitet werden müssen) sinkt von 35 % auf unter 20 %” ist einer.

Fehler 4 — Governance-Feld leer oder pauschal: „Wir halten uns an DSGVO” ist kein ausgefülltes Governance-Feld. Das Governance-Feld muss die Freigabeklasse (Grün/Gelb/Rot), den Review-Touchpoint, den Skill-Owner und den Eskalationsweg enthalten.

Fehler 5 — Risiken-Feld nur technisch: Risiken sind nicht nur technisch (was, wenn die KI falsche Informationen generiert?), sondern auch menschlich (was, wenn das Team den Assistenten nicht nutzt?) und organisatorisch (was, wenn die Datenbasis nicht gepflegt wird?). Alle drei Risikoebenen müssen im Canvas adressiert sein.

Merksatz

Ein Canvas mit zehn gut ausgefüllten Feldern ist wertvoller als ein Canvas mit zehn oberflächlich ausgefüllten Feldern. Lieber ein Feld als „noch ungeklärt” markieren als es mit einer Scheinaussage füllen. „Noch ungeklärt” ist ehrlich — und zeigt, wo vor Pilot-Start noch Arbeit zu leisten ist.

Der Drei-Qualitäts-Test für Use-Case-Steckbriefe

Bevor ein Use-Case-Steckbrief als „Ready for Pilot” eingestuft wird, sollte er drei Qualitätstests bestehen:

Test 1 — Der 5-Minuten-Test: Kann eine Person, die an der Canvas-Erstellung nicht beteiligt war, den Canvas in 5 Minuten lesen und danach die fünf wichtigsten Aspekte des Use Cases korrekt wiedergeben? Wenn nicht: Die Beschreibungen sind zu technisch, zu vage oder zu unstrukturiert.

Test 2 — Der Entscheidungs-Test: Enthält der Canvas alle Informationen, die eine Geschäftsführung für eine Budget-Entscheidung braucht? Wenn für die Entscheidung noch weitere Informationen benötigt werden, fehlen Felder im Canvas.

Test 3 — Der Risiko-Test: Kann das Team für jeden Risikopunkt im Canvas benennen, welche Maßnahme vor Pilot-Start ergriffen wird? Risiken ohne Gegenmaßnahme sind keine dokumentierten Risiken — sie sind unbearbeitete Probleme.

UE 88 — Vertiefung: Sensitivitätsanalyse und Kalibrierung bei Priorisierungsmethoden

ICE-Score: Stärken und Grenzen

Der ICE-Score (Impact × Confidence × Ease) ist die einfachste aller Priorisierungsmethoden — und hat deshalb sowohl eine breite Anwendungsbasis als auch charakteristische Schwächen, die jede nutzende Person kennen sollte.

Stärke 1 — Geschwindigkeit: Ein ICE-Score kann in 5–10 Minuten für 10 Use Cases vergeben werden. Das ermöglicht schnelle Erst-Priorisierungen, bevor tiefere Analysen (Canvas, Business Case) folgen.

Stärke 2 — Erzwungene Explizitheit: Durch die Notwendigkeit, drei separate Scores zu vergeben, werden Annahmen explizit gemacht, die bei intuitiven Priorisierungen im Verborgenen bleiben.

Schwäche 1 — Multiplikations-Verzerrung: Ein Use Case mit Score I=5, C=5, E=5 erhält den gleichen Gesamtscore wie I=9, C=1, E=… (wenn das Produkt ähnlich ist). Die Multiplikation begünstigt gleichmäßig bewertete Use Cases gegenüber asymmetrisch bewerteten.

Schwäche 2 — Skalen-Willkür: Ohne vorherige Kalibrierung erhält ein Score von „7 für Impact” eine andere Bedeutung bei verschiedenen Bewerterinnen und Bewertern. Abhilfe: Ankerpunkte definieren (z. B.: Impact 9 = Use Case erspart > 20 Stunden/Woche im Team; Impact 5 = 5–10 Stunden/Woche; Impact 2 = < 2 Stunden/Woche).

Schwäche 3 — Strategische Dimension fehlt: ICE misst Aufwand-Ertrag-Verhältnis, aber nicht strategische Passung. Ein Use Case, der einfach umzusetzen ist und schnelle Wins bringt, kann strategisch weniger relevant sein als ein aufwändigerer Use Case, der langfristig größere Kompetenz aufbaut.

Merksatz

ICE ist ein Starter-Tool, kein Abschluss-Tool. Nutzen Sie ICE für die Erst-Filterung (Shortlist von 10 auf 3–5 Kandidaten). Nutzen Sie dann RICE oder die Nutzwertanalyse für die finale Priorisierung, bei der strategische Faktoren explizit gewichtet werden.

Dokumentation von Priorisierungsentscheidungen

Ein oft unterschätzter Aspekt der Priorisierungsarbeit ist die Dokumentation — nicht nur der Ergebnisse, sondern der Entscheidungslogik. Warum ist Use Case A gegenüber Use Case B priorisiert worden? Welche Annahmen lagen dem Score zugrunde? Wer hat an der Entscheidung teilgenommen?

Diese Dokumentation hat drei praktische Vorteile: (1) Wenn die Priorisierung später in Frage gestellt wird (weil sich Umstände geändert haben), kann nachvollzogen werden, warum die Entscheidung zum damaligen Zeitpunkt sinnvoll war. (2) Wenn neue Team-Mitglieder das Projekt übernehmen, verstehen sie die Ausgangslage ohne vollständige Einarbeitung. (3) Wenn ein zurückgestellter Use Case später reaktiviert werden soll, sind die ursprünglichen Bewertungsparameter dokumentiert und können aktualisiert werden.

Empfohlene Dokumentationsstruktur: Eine Tabelle mit allen Use Cases, ihrer Bewertung auf jeder Dimension, dem Gesamtscore, der finalen Priorisierungsentscheidung und einem kurzen (3 Sätze) Begründungstext. Diese Tabelle wird im Governance-Handbuch als Teil des Freigabe-Registers gespeichert.

UE 89 — Vertiefung: Vendor-Lock-in, TCO und hybride Strategien

Vendor-Lock-in verstehen: Eintritt, Ausprägung, Ausstieg

Warnung — Vendor-Lock-in: Strategisches Risiko bei KI-Plattformentscheidungen

Vendor-Lock-in entsteht, wenn eine Organisation so tief in die Plattform eines einzelnen Anbieters integriert ist, dass ein Anbieterwechsel prohibitiv teuer oder technisch kaum machbar wäre. Im KI-Kontext sind die Lock-in-Dimensionen besonders ausgeprägt: proprietäre Modellarchitekturen, plattformspezifische Fein-Tuning-Daten, nicht exportierbare Systemanweisungen und RAG-Wissensdatenbanken, die tief in proprietäre Indizierungsformate integriert sind. Vor jeder längerfristigen KI-Plattformentscheidung sollte die Lock-in-Strategie explizit bewertet werden: Was sind die Exit-Kosten in 2 Jahren? Was in 4 Jahren? Wenn diese Fragen nicht beantwortbar sind, ist die Plattformwahl noch nicht entscheidungsreif.

Lock-in-Typen im KI-Kontext:

Daten-Lock-in: Die wichtigste Lock-in-Dimension. Wenn Ihre Wissensdaten (RAG-Datenbank, Fine-Tuning-Datensätze, Systemanweisungen) nur in proprietären Formaten vorliegen, ist der Plattformwechsel mit erheblichem Datenmigrations-Aufwand verbunden. Gegenmaßnahme: Alle Daten in offenen Formaten (JSON, Markdown, PDF) speichern — unabhängig davon, in welchem Format sie in die Plattform hochgeladen werden.

Integrations-Lock-in: Je mehr interne Systeme direkt mit einer KI-Plattform integriert sind (via proprietärer APIs), desto aufwändiger ist ein Anbieterwechsel. Gegenmaßnahme: Abstraktionsschicht zwischen KI-Plattform und internen Systemen (z. B. via Middleware wie n8n oder Make), die plattformagnostisch ist.

Kompetenz-Lock-in: Wenn Ihr Team ausschließlich auf der Plattform A ausgebildet ist, erhöht ein Wechsel zu Plattform B den Schulungsaufwand erheblich. Gegenmaßnahme: Prompt-Engineering-Grundlagen (plattformübergreifend) stärken, nicht nur platform-spezifische Features.

Merksatz

Vendor-Lock-in ist keine binäre Frage (Lock-in ja oder nein), sondern eine Skala. Jede Plattformentscheidung erhöht den Lock-in — die Frage ist: Wie schnell, in welchem Bereich, und was ist der Exit-Preis? Diese Frage muss vor der Entscheidung beantwortet werden, nicht danach.

Hybridstrategie: Configure + Buy + Build als komplementäre Ansätze

Die Build-vs-Buy-vs-Configure-Entscheidung wird in der Praxis selten binär getroffen. Die meisten erfolgreichen KI-Implementierungen nutzen eine Hybridstrategie, bei der verschiedene Schichten der KI-Architektur unterschiedliche Beschaffungsstrategien nutzen.

Typische Hybridkonfiguration: - Grundmodell (Foundation Model): Buy/API — kein Unternehmen außer den großen Tech-Konzernen entwickelt eigene Foundation Models. GPT-4-Klasse oder vergleichbare Modelle werden via API bezogen. - Orchestrierung und Workflow: Configure — Plattformen wie Copilot Studio, n8n, Make oder ähnliche werden konfiguriert, nicht von Grund auf entwickelt. - Domänenspezifische Wissensbasis (RAG): Build — die Wissensdatenbank (welche Dokumente, wie indiziert, welche Metadaten) ist organisationsspezifisch und muss intern aufgebaut werden. - Systemanweisungen und Prompts: Build — diese sind das intellektuelle Kapital der KI-Implementation und werden intern entwickelt und gepflegt. - UI/UX-Integration: Configure oder Build — je nachdem, ob eine bestehende Plattform (Teams, SharePoint, Intranet) genutzt oder eine neue Schnittstelle entwickelt wird.

Diese Hybridstrategie minimiert Build-Aufwand (die teuerste Variante) bei gleichzeitiger Sicherung der organisationsspezifischen Wertschöpfungsschichten.

UE 90 — Vertiefung: Datenqualitäts-Dimensionen und Metriken

Das Datenqualitäts-Audit: Praktische Durchführung

Ein Datenqualitäts-Audit für einen KI-Use-Case muss nicht aufwändig sein. Ein gut strukturierter 2-Stunden-Workshop mit den datenhaltenden Systemen und den datenverantwortlichen Personen reicht in der ersten Phase aus — das Ziel ist eine belastbare Ampelbewertung, keine vollständige Datendokumentation.

Audit-Ablauf (2 Stunden):

Phase 1 — Datenkatalog (30 Min.): Welche Datenquellen sind für den Use Case relevant? Liste aller Systeme, Dokumente und Datenbanken. Verantwortliche Person für jede Quelle benennen. Format und Zugangsmodus notieren.

Phase 2 — Qualitätsbewertung (60 Min.): Für jede Datenquelle: Vollständigkeit (Wie viele Felder sind ausgefüllt — Stichprobe 20 Datensätze), Aktualität (Wann war das letzte Update?), Konsistenz (Gibt es widersprüchliche Einträge zwischen Systemen?), Zugänglichkeit (Kann ein KI-System rechtlich und technisch auf diese Daten zugreifen?).

Phase 3 — Ampelbewertung (30 Min.): Für jede Datenquelle und jede Dimension: Grün (ausreichend, kein Handlungsbedarf), Gelb (Mängel vorhanden, Bereinigung möglich), Rot (grundlegende Datenprobleme, Pilot nicht empfohlen bis Bereinigung). Gesamtbewertung: Welche Ampelklasse hat der Use Case aus Datenperspektive?

Merksatz

Ein Datenqualitäts-Audit, der zeigt, dass die Datenbasis Rot-klassifiziert ist, ist kein Scheitern — es ist ein Erfolg. Der Audit hat verhindernt, dass Zeit und Ressourcen in einen Pilot mit schlechter Datenbasis investiert werden. Rote Ampeln sind nicht das Ende — sie sind der Beginn des Daten-Bereinigungsplans.

DSGVO als sechste Datenqualitätsdimension

Neben den fünf technischen Datenqualitätsdimensionen (Vollständigkeit, Aktualität, Konsistenz, Genauigkeit, Zugänglichkeit) tritt für KI-Systeme eine sechste Dimension hinzu: DSGVO-Konformität.

Die DSGVO-Dimension bewertet: (1) Liegt eine Rechtsgrundlage für die Verarbeitung der Daten durch das KI-System vor? (Art. 6 DSGVO — Einwilligung, berechtigtes Interesse, Vertragserfüllung, gesetzliche Verpflichtung). (2) Wurden die betroffenen Personen über die KI-basierte Datenverarbeitung informiert? (Transparenzpflicht). (3) Ist ein Auftragsverarbeitungsvertrag (AVV) mit dem KI-Anbieter geschlossen? (4) Verlassen die Daten den EU/EWR-Raum — und wenn ja, ist der Transfer rechtlich abgesichert?

Bei personenbezogenen Daten (Kundendaten, Bewerberdaten, Mitarbeiterdaten) muss diese Dimension Grün sein, bevor der Pilot startet. Eine Gelb-Bewertung (AVV fehlt noch, Rechtsgrundlage unklar) muss vor Go-Live auf Grün gebracht werden. Eine Rot-Bewertung bedeutet: kein Pilot-Start, bis die rechtliche Situation geklärt ist.

UE 91 — Vertiefung: Gestufter Rollout und Go/No-Go-Gate-Qualität

Was macht ein gutes Go/No-Go-Gate aus?

Das Go/No-Go-Gate am Ende jeder Pilot-Stufe ist eine strategische Entscheidung, keine administrative Formalität. Ein gutes Gate hat fünf Merkmale:

Merkmal 1 — Definierte Entscheidungsträger: Wer trifft die Go/No-Go-Entscheidung? Ein einzelner KI-Beauftragter? Das Führungsteam? Eine definierte Entscheidungsgruppe aus KI-Beauftragtem + Skill-Owner + Geschäftsführung? Die Entscheidungsgruppe muss vor Pilot-Start feststehen.

Merkmal 2 — Klare Entscheidungsgrundlage: Welche Daten liegen zur Go/No-Go-Entscheidung vor? KPI-Auswertung (Leading und Lagging), Abbruchkriterien-Status (wurden sie ausgelöst?), qualitative Rückmeldungen aus der Pilotgruppe, Governance-Status (alle Compliance-Anforderungen erfüllt?).

Merkmal 3 — Zeitliche Klarheit: Das Go/No-Go-Datum ist vor Pilot-Start fixiert. Kein „Wir schauen, wie es läuft” — sondern „In Woche 7 fällt die Entscheidung”. Diese Fixierung verhindert das Hinauszögern von schwierigen No-Go-Entscheidungen.

Merkmal 4 — Definierte Konsequenzen: Was passiert bei einem Go? (Rollout-Plan Stufe 2 wird aktiviert.) Was passiert bei einem No-Go? (Pilot-Stopp, Lessons-Learned-Dokumentation, Entscheidung ob modifizierter Pilot sinnvoll ist.)

Merkmal 5 — Dokumentation: Die Go/No-Go-Entscheidung wird dokumentiert — mit Begründung. Diese Dokumentation ist Teil des Governance-Handbuchs und dient als Referenz für ähnliche Entscheidungen in der Zukunft.

Merksatz

Das No-Go ist keine Niederlage — es ist der wertvollste Ausgang eines Pilot-Experiments, wenn die Erkenntnisse dokumentiert werden. Ein Pilot, der die Hypothese widerlegt hat, hat bewiesen, dass das Design funktioniert. Die Organisation hat gelernt, was nicht funktioniert — und das hat einen realen Wert.

UE 92 — Vertiefung: ADKAR-Messbarkeit und Führungskräfte als Change-Agenten

ADKAR quantifizieren: Die fünf-Fragen-Umfrage

ADKAR ist nur dann steuerbar, wenn es messbar ist. Eine monatliche 5-Fragen-Umfrage (je eine Frage pro ADKAR-Stufe, 1–5-Skala) gibt der Organisation ein objektives Bild des Change-Fortschritts:

Frage 1 (Awareness): „Ich verstehe, warum meine Organisation KI einführt und welche Konsequenzen es hätte, wenn wir das nicht täten.” (1 = stimme gar nicht zu, 5 = stimme vollständig zu)

Frage 2 (Desire): „Ich möchte aktiv zur KI-Einführung in meiner Organisation beitragen.” (1–5)

Frage 3 (Knowledge): „Ich weiß, wie ich den KI-Assistenten für meine tägliche Arbeit konkret einsetzen kann.” (1–5)

Frage 4 (Ability): „Ich setze den KI-Assistenten regelmäßig in meiner täglichen Arbeit ein.” (1–5)

Frage 5 (Reinforcement): „Die Nutzung des KI-Assistenten ist in meiner täglichen Arbeit zur Routine geworden.” (1–5)

Auswertung: Der Durchschnitt je Stufe zeigt, wo die Organisation steht. Wenn Frage 3 (Knowledge) hohe Scores zeigt, aber Frage 4 (Ability) niedrig bleibt, ist die Schlussfolgerung eindeutig: Schulung hat stattgefunden, aber kein begleitetes Üben im Alltag. Die Maßnahme ist klar: Ability-Fokus in der nächsten Phase.

Merksatz

Change Management ohne Messung ist Glaube statt Wissen. Die fünf-Fragen-Umfrage kostet die Teilnehmenden 90 Sekunden und gibt der Organisation 5 messbare Steuerungsgrößen. Das ist ein Return on Measurement-Invest, der selten so günstig ist.

UE 93 — Vertiefung: Governance-Operationalisierung und EU AI Act für Deployer

Freigabeprozess im Detail: Wie eine KI-Anwendung ins Register kommt

Jede neue KI-Anwendung, bevor sie produktiv eingesetzt wird, durchläuft einen definierten Freigabeprozess. Dieser Prozess sollte so schlank wie möglich, aber so robust wie nötig sein.

Schritt 1 — Bedarfsmeldung (5 Min.): Der Skill-Owner aus dem Fachbereich meldet dem KI-Beauftragten: Anwendungsname, Zweck, Plattform, geschätzte Nutzungsfrequenz, betroffene Nutzergruppe.

Schritt 2 — Risiko-Ersteinschätzung (15 Min.): KI-Beauftragter bewertet anhand der Drei-Stufen-Klassifikation: Grün, Gelb oder Rot? Für Grün: direkte Freigabe nach Schritt 4. Für Gelb/Rot: weiter zu Schritt 3.

Schritt 3 — DSGVO-Prüfung (30–60 Min. je nach Komplexität): Datenschutzbeauftragter / Compliance prüft: Rechtsgrundlage, AVV-Status, Datentransfer-Frage. Bei Klärungsbedarf: Schritt 3 verlängert sich, Pilot-Start wird verschoben bis zur Klärung.

Schritt 4 — Register-Eintrag und Dokumentation (10 Min.): Neue Zeile im Freigabe-Register, alle Pflichtfelder ausgefüllt, Skill-Owner namentlich eingetragen, Review-Touchpoint definiert.

Schritt 5 — Kommunikation (5 Min.): Skill-Owner und nutzende Mitarbeitende werden über die Freigabeklasse und den Review-Touchpoint informiert — schriftlich, kurz, klar.

Für Grün-Klasse-Anwendungen: Gesamtdauer des Freigabeprozesses ca. 30 Minuten. Für Gelb-Klasse: 1–3 Stunden. Für Rot-Klasse: 1–3 Tage (inklusive Compliance-Prüfung und ggf. Betriebsrats-Einbindung).

Merksatz

Ein Governance-Freigabeprozess, der für Grün-Klasse-Anwendungen 30 Minuten dauert, ist kein Innovationshemmer. Er ist ein Enabler: Er legitimiert die schnelle Freigabe kleiner Tools, während er bei riskanten Anwendungen die notwendige Sorgfalt gewährleistet. Die Alternative — alles oder nichts — funktioniert in der Praxis nicht.

UE 94 — Vertiefung: Roadmap-Kommunikation für verschiedene Stakeholder

Drei Roadmap-Formate für drei Zielgruppen

Eine gut erstellte 12-Monats-KI-Roadmap existiert in drei Formaten gleichzeitig — jedes für eine andere Zielgruppe:

Format 1 — Management-Kachel (für Geschäftsführung und Vorstand): Vier Kacheln (Q1–Q4), je mit drei bis fünf Bulletpoints. Keine Balken, keine Gantt-Logik. Sprache: geschäftlich, ergebnisorientiert. Inhalte: Welche Meilensteine werden in welchem Quartal erreicht? Was kostet es (grob)? Wann fließt der erste messbarer Nutzen? Ein A4-Blatt genügt. Dieses Format eignet sich für das monatliche Management-Meeting und für die Budget-Freigabe.

Format 2 — Swimlane-Gantt (für KI-Beauftragten und Skill-Owner): Horizontale Balken für jede Initiative über einen Zeitstrahl, gruppiert in drei Swimlanes (Use Cases, Governance, Schulungen). Abhängigkeiten explizit mit Pfeilen dargestellt. Dieses Format dient der operativen Steuerung: Wer ist wann für was verantwortlich? Welche Voraussetzungen müssen erfüllt sein, bevor der nächste Schritt startet?

Format 3 — Meilenstein-Timeline (für alle Mitarbeitenden): Eine einfache Zeitlinie mit fünf bis acht wichtigen Meilensteinen. Keine technischen Details, keine Ressourcenangaben. Inhalte: Was erleben die Mitarbeitenden wann? „Q1: Pilot Meeting-Protokoll startet. Q2: Alle Berater haben Zugang. Q3: Zweites Tool live.” Dieses Format ist für Intranet-Updates und All-Hands-Meetings geeignet — es reduziert Unsicherheit und schafft Orientierung.

Merksatz

Die falsche Roadmap für die falsche Zielgruppe ist schlimmer als keine Roadmap. Eine Swimlane-Gantt-Chart vor der Geschäftsführung signalisiert Überdetailliertheit und erzeugt Misstrauen statt Vertrauen. Die Quartals-Kachel für die IT-Abteilung ist zu dünn für operative Steuerung. Format und Zielgruppe müssen zusammenpassen.

UE 95 — Vertiefung: Fortgeschrittene Business-Case-Instrumente

Tornado-Diagramm: Die einflussreichsten Variablen identifizieren

Das Tornado-Diagramm ist ein einfaches, aber wirkungsvolles Instrument der Sensitivitätsanalyse, das zeigt, welche Variablen den größten Einfluss auf den NPV haben.

Methode: Jede wichtige Input-Variable (Adoption Rate, Zeitersparnis pro Person, API-Kosten, Schulungsdauer etc.) wird einzeln um ±20 % variiert, während alle anderen Variablen konstant gehalten werden. Das Ergebnis ist ein Balkendiagramm, bei dem jede Variable durch einen horizontalen Balken dargestellt wird — der linke Teil des Balkens zeigt die Auswirkung bei -20 %, der rechte bei +20 %.

Typische Ergebnisse für KI-Business-Cases: Die Variablen mit dem stärksten Einfluss auf den NPV sind erfahrungsgemäß: (1) Adoption Rate — wenn 20 % weniger Mitarbeitende das Tool nutzen als prognostiziert, sinkt der NPV erheblich. (2) Nutzungskonversion — welcher Anteil der gesparten Zeit wird tatsächlich produktiv eingesetzt? (3) API-Kosten — bei hohem Nutzungsvolumen der wichtigste Kostentreiber.

Praktischer Wert: Das Tornado-Diagramm zeigt in zwei Minuten, wo Validierungsaufwand am meisten lohnt: Die Variable mit dem höchsten Einfluss auf den NPV ist die Variable, deren Annahme vor der Investitionsentscheidung am sorgfältigsten validiert werden sollte.

Merksatz

Die drei kritischsten Annahmen im KI-Business-Case sind fast immer dieselben: Adoption Rate, Nutzungskonversion und API-Kosten bei Skalierung. Wer diese drei Annahmen sorgfältig aus dem Pilot ableitet (statt zu schätzen), erhält einen Business Case, der bei der Geschäftsführung Vertrauen erzeugt — weil er auf Daten basiert, nicht auf Hoffnung.

Break-Even-Sensitivität und Investitions-Entscheidungsrahmen

Neben der NPV-Sensitivität ist die Break-Even-Sensitivität entscheidend: Wie lang darf der Break-Even maximal dauern, damit die Investition für Ihre Organisation noch sinnvoll ist?

Faustregel für verschiedene Organisationstypen: - Wachstumsstarke Startups und scale-ups: Break-Even 6–12 Monate (hohes Tempo, wenig Geduld für lange Amortisationszeiten) - Mittelständische Unternehmen: Break-Even 12–24 Monate (realistisch für interne Produktivitätsinvestitionen) - Öffentliche Verwaltung: Break-Even kann länger sein — häufig wird Servicequalität höher gewichtet als monetäre Amortisation - Regulierte Branchen (Finanzen, Pharma): Compliance-Investitionen haben kein Break-Even-Kriterium — sie sind Pflichtinvestitionen

Der Break-Even-Zeitraum sollte in Relation zur technologischen Lebensdauer der Lösung bewertet werden: Wenn eine KI-Plattform in drei Jahren möglicherweise durch eine bessere ersetzt wird, sollte der Break-Even deutlich unter 24 Monaten liegen.

UE 96 — Vertiefung: Workshopqualität und Transfer-Sicherung

Die vier Facilitierungs-Techniken für qualitativ hochwertige Use-Case-Steckbriefe

Die Qualität der drei Use-Case-Steckbriefe aus dem Abschlussworkshop hängt stark von der Facilitierungsqualität ab:

Technik 1 — Vorabstruktur schaffen: Alle Teilnehmenden bringen vor dem Workshop bereits einen teilweise ausgefüllten Canvas mit. Ein Workshop, bei dem der Canvas erst während des Workshops von Null erstellt wird, ist nicht produktiv. Die Workshop-Zeit ist für kollektive Verbesserung bereits vorhandener Entwürfe.

Technik 2 — Simultane ICE-Abstimmung: In Phase 2 neigen Gruppen dazu, Diskussionen über Bewertungen zu führen statt zu bewerten. Empfehlung: Simultanes Bewerten (alle gleichzeitig, ohne vorherige Diskussion), dann Ergebnisse aggregieren, dann kurze Diskussion nur bei Bewertungsabweichungen von mehr als 3 Punkten.

Technik 3 — Aktive Zeitwächterrolle: In einem 45-Minuten-Workshop sind die Zeitbudgets eng. Eine Person übernimmt explizit die Zeitwächterrolle und gibt nach 10, 25 und 40 Minuten ein Signal. Ohne aktive Zeitkontrolle landen Workshops regelmäßig nach Phase 2 mit kaum Zeit für Phase 3 und 4.

Technik 4 — Checklisten-Druck vor Abschluss: Bevor der Workshop endet, führt jede Gruppe in 3 Minuten einen 7-Punkte-Checklisten-Check durch. Fehlende Punkte werden als explizite To-Dos festgehalten — nicht als Versagen, sondern als Nacharbeits-Plan.

Merksatz

Die 48-Stunden-Regel für Transfer: Jeder Use Case, der am Ende des Workshops keinen konkreten nächsten Schritt mit Termin innerhalb von 48 Stunden hat, wird mit hoher Wahrscheinlichkeit nicht umgesetzt. Die 48 Stunden sind die Brücke zwischen der Energie der Schulung und der Trägheit des Alltags. Bauen Sie diese Brücke — explizit, in der Gruppe oder allein, bevor die Teilnehmenden den Raum verlassen.

Projektabschluss: Use Cases in die Organisation tragen

Drei notwendige Nacharbeitsschritte nach dem Workshop:

Schritt 1 — Digitale Ablage: Die Steckbriefe werden in einem gemeinsam zugänglichen System abgelegt (Notion, SharePoint, Confluence). Alle relevanten Stakeholder (KI-Beauftragter, IT-Leitung, betroffene Fachbereiche) erhalten Lesezugang. Die Steckbriefe sind Unternehmens-Assets, nicht der persönliche Besitz der Erstellenden.

Schritt 2 — Management-Briefing (Executive Summaries): Für jeden Use Case wird eine halbseitige Executive Summary erstellt: Problem (eine Zahl), Lösung (ein Satz), Break-Even (ein Datum), nächste Maßnahme (ein Satz). Diese Executive Summaries werden im nächsten Management-Meeting oder per E-Mail an die Geschäftsführung kommuniziert.

Schritt 3 — Ressourcen sichern: Bevor der erste Pilot startet, müssen die nötigsten Ressourcen gesichert sein: IT-Zeitkontingent für die Konfiguration, Budget für Lizenzen, und die Bereitschaft der Pilotgruppen-Mitglieder. Das Sichern dieser Ressourcen ist keine administrative Formalität — es ist die kritische Transferhürde zwischen Planung und Umsetzung.

Die Verbindung zur nächsten Projektphase: Die drei Use-Case-Steckbriefe sind die direkte Eingabe für die nachfolgende Projektarbeit. Die Anforderungen einer typischen Projektdokumentation korrespondieren direkt mit den Steckbrief-Bestandteilen:

Wer den Steckbrief im Workshop vollständig ausgefüllt hat, hat die Hälfte der Projektdokumentation bereits erledigt. Die restliche Hälfte ist die Ausarbeitung, Validierung und Präsentation dieser Inhalte.

Ende von Modul 8 — Use-Case-Discovery und KI-Strategie (UE 85–96)

Dieses Handout ist kundenneutral und für den Einsatz in verschiedenen Organisationen und Branchen konzipiert. Alle Branchen-Vignetten (IT-Dienstleistung & Beratung, Industrie & Fertigung, Finanzdienstleistung & Versicherung, Öffentliche Verwaltung) sind als Beispielrahmen zu verstehen. Trainer wählen die für ihre Gruppe relevanteste Branche aus und passen die Beispiele bei Bedarf an den spezifischen Kundenkontext an.

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