Use-Case-Canvas und Steckbriefe

Lernziele

Sie füllen für einen ausgewählten Prozess einen vollständigen Use-Case-Canvas mit allen zehn Pflichtfeldern aus und erklären, welche Funktion jedes Feld für die spätere Implementierung hat.

Sie formulieren ein Problem-Statement aus der Nutzerperspektive, das präzise, spürbar und von „Prozess ineffizient”-Generalisierungen klar unterschieden ist.

Sie definieren Erfolgskriterien, die messbar, zeitgebunden und von subjektiven Empfindungen unabhängig sind.

Sie identifizieren die drei relevantesten Risiken für einen Use Case und formulieren für jeden eine konkrete Mitigationsmaßnahme.

Sie setzen den Canvas als Kommunikationsdokument für Stakeholder-Gespräche ein und erläutern, welche Felder für die IT-Abteilung, welche für die Geschäftsführung und welche für den Betriebsrat besonders relevant sind.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

Sie haben aus UE 86 eine priorisierte Liste von zwei bis drei Use-Case-Kandidaten. Jetzt kommt der entscheidende Schritt: Bevor irgendeine Technologie berührt wird, muss der Use Case so sauber beschrieben sein, dass drei verschiedene Personen — eine Beraterin, ein IT-Mitarbeiter und die Geschäftsführung — nach dem Lesen dieselbe Vorstellung davon haben, was gebaut werden soll, warum es gebaut wird und wie Erfolg aussieht.

Das klingt selbstverständlich. In der Praxis ist es das nicht. Die häufigste Ursache für scheiternde KI-Projekte in Organisationen ist nicht fehlerhafte Technologie — es ist eine diffuse, unterschiedlich interpretierte Vorstellung davon, was der Use Case eigentlich leisten soll. Der Use-Case-Canvas behebt dieses Problem, indem er alle relevanten Dimensionen auf einer einzigen Seite explizit macht.

Der Canvas ist dabei kein bürokratisches Formular, das nach dem Ausfüllen in einer Schublade verschwindet. Er ist ein lebendiges Dokument — der Ausgangspunkt für Gespräche mit der IT-Abteilung, die Grundlage für den Business Case in UE 95, das Briefing-Dokument für externe Dienstleister und der Input für die Projektarbeit in Modul 10.

Lerntext — Theorie und Konzepte

Die zehn Felder des Use-Case-Canvas

Der Use-Case-Canvas strukturiert einen KI-Use-Case in zehn Pflichtfelder, die vier inhaltlichen Clustern entsprechen:

Cluster 1 — Problem und Kontext:

Feld 1 — Problem-Statement: Max. drei Sätze, aus Nutzerperspektive formuliert. Das Problem-Statement ist fertig, wenn eine Person, die die Organisation nicht kennt, sofort versteht: Was geht schief? Wer ist betroffen? Was kostet das? Beispiel für ein schlechtes Problem-Statement: „Die Angebotserstellung ist ineffizient.” Gut: „Beraterinnen und Berater verbringen durchschnittlich 90 Minuten für die Erstellung eines Angebots, davon 55 Minuten für die manuelle Zusammenführung von Kundendaten aus CRM, Projekthistorie aus SharePoint und Preisliste aus Excel. Diese Zeit fehlt täglich für die eigentliche Beratungsarbeit.”

Feld 2 — Betroffene Prozessschritte: Welche Schritte aus dem SIPOC (UE 85) sind betroffen? Nicht der gesamte Prozess wird durch KI ersetzt — nur spezifische Schritte.

Cluster 2 — Lösung und Technologie:

Feld 3 — Vorgeschlagene KI-Lösung: Assistent, Workflow oder Agent (aus UE 75)? Welche Plattform kommt infrage? In welchem Modus (Configure / Buy / Build — aus UE 89)?

Feld 4 — Benötigte Datenbasis: Welche Daten braucht die KI? Wo liegen sie heute? In welchem Format? Sind sie zugänglich?

Feld 5 — Technische Abhängigkeiten: Welche Systeme müssen angebunden werden? Gibt es API-Zugang?

Cluster 3 — Menschen und Governance:

Feld 6 — Stakeholder: Wer profitiert vom Use Case? Wer muss in die Entscheidung einbezogen werden? Wer hat möglicherweise Bedenken?

Feld 7 — Governance-Klasse: Ampelklasse nach dem Drei-Stufen-Freigabemodell (Grün = vollständig automatisierbar, kein externer Impact; Gelb = Mensch reviewt vor externem Output; Rot = jeder Output erfordert Freigabe).

Cluster 4 — Erfolgsmessung und Risiken:

Feld 8 — Erfolgskriterien (KPIs): Mindestens zwei messbare KPIs. Je ein Leading Indicator und ein Lagging Indicator. KPIs müssen quantifiziert sein: nicht „Zeitersparnis”, sondern „Reduktion der Angebots-Vorbereitungszeit von 90 auf unter 30 Minuten innerhalb von 8 Wochen”.

Feld 9 — Risiken: Die drei Top-Risiken des Use Cases — technisch, datenschutzrechtlich und Akzeptanz.

Feld 10 — Nächste Schritte: Wer macht was bis wann? Mindestens drei konkrete Aktionen mit Verantwortlichen und Terminen.

Merksatz

Der Canvas ist kein einmaliges Dokument — er ist ein lebendes Kommunikationsmittel. IT liest Felder 4 und 5, Geschäftsführung liest Felder 1, 8 und 10, Betriebsrat liest Felder 6, 7 und 9. Ein Canvas, der nicht geteilt wird, ist wertlos.

Qualitätskriterien für einen guten Canvas

Ein fertiggestellter Canvas muss drei Qualitätsprüfungen bestehen:

Klarheitstest: Kann eine Person ohne Vorwissen über den Prozess das Problem-Statement lesen und sofort verstehen, worum es geht? Wenn ja: Bestanden.

Messbarkeitstest: Sind die KPIs so formuliert, dass in sechs Monaten eindeutig entschieden werden kann, ob das Ziel erreicht wurde? Wenn ja: Bestanden.

Ehrlichkeitstest: Wurden die Risiken so benannt, wie sie wirklich sind — oder wurden sie kleingeschrieben? Wenn Feld 9 nur Standardrisiken enthält, ohne spezifischen Bezug zum konkreten Use Case, ist dieser Test nicht bestanden.

Abb. 87.1 — Zehn-Felder-Struktur des Use-Case-Canvas mit vier inhaltlichen Clustern

Vertiefung — Problem-Statement, Canvas-Feld 7 und häufige Fehler

Vertiefung — Das Problem-Statement als Herzstück des Canvas

Canvas-Feld 1 — das Problem-Statement — entscheidet darüber, ob ein KI-Projekt von Anfang an auf dem richtigen Fundament steht oder auf einem vagen Wunsch. Das Problem-Statement ist das am häufigsten falsch ausgefüllte Canvas-Feld.

Was ein gutes Problem-Statement auszeichnet:

Erstens: Es ist aus der Nutzerperspektive formuliert, nicht aus der Technologieperspektive. Schlecht: „Wir wollen KI einsetzen, um unsere Prozesse zu optimieren.” Gut: „Unsere Sachbearbeitenden verbringen täglich durchschnittlich 45 Minuten damit, Informationen aus fünf verschiedenen Systemen manuell zusammenzusuchen, bevor sie eine Kundenanfrage beantworten können.”

Zweitens: Es ist mit einer Zahl verbunden. „Zu lange” ist kein messbares Problem. „45 Minuten täglich bei 30 Sachbearbeitenden = 225 Stunden Gesamtverlust pro Woche” ist ein messbares Problem — und der Ausgangspunkt für eine ROI-Berechnung.

Drittens: Es beschreibt die Konsequenz des Problems, nicht nur das Problem selbst. „Weil die Informationsbeschaffung so aufwändig ist, dauert die durchschnittliche Erstantwortzeit auf Kundenanfragen 3,2 Arbeitstage — 40 % über dem Branchen-Benchmark.”

Der Jobs-to-be-Done-Test: Ein bewährter Qualitätstest für Problem-Statements ist das Jobs-to-be-Done-Framework (Clayton Christensen): Welchen „Job” versucht der Nutzende mit dem bestehenden Prozess zu erledigen? Was hindert ihn daran, diesen Job gut zu erledigen? Die KI-Lösung sollte direkt auf dieses Hindernis abzielen — nicht auf einen abstrakten Effizienz-Wunsch.

Typisches Muster in Workshops: Teams neigen dazu, Problem-Statements als Lösungs-Statements zu formulieren: „Wir brauchen einen KI-Assistenten für die Angebotserstellung.” Das ist keine Problembeschreibung — das ist eine Lösungsidee. Schritt zurück: Was genau ist an der aktuellen Angebotserstellung problematisch? Für wen? Mit welcher Konsequenz? Erst wenn diese Fragen beantwortet sind, ist das Problem-Statement vollständig.

Das Problem-Statement in Feld 1 ist die wichtigste Investition im gesamten Use-Case-Erarbeitungsprozess. Der Prozess folgt dem Prinzip der „5-Warum-Fragen” (Five Whys), die ursprünglich aus dem Toyota Production System stammen. Sie bohren so lange in die Kausalität eines Problems, bis die echte Ursache sichtbar wird.

Beispiel-Iteration: Problem (Oberflächenebene): „Angebote dauern zu lange.” Warum? „Weil die Mitarbeitenden zu viel Zeit für die Informationsbeschaffung brauchen.” Warum? „Weil die Informationen in vier verschiedenen Systemen verteilt sind.” Warum? „Weil keine zentrale Ablage existiert, die alle relevanten Informationen bündelt.” Warum? „Weil die Systemlandschaft historisch gewachsen ist und nie aus Anwender-Sicht optimiert wurde.” Das echte Problem: „Es gibt keine integrierte Informationsquelle, die alle für die Angebotserstellung relevanten Daten bündelt — das führt zu 55 Minuten manuellem Rechercheaufwand pro Angebot.”

Das Drei-Stufen-Freigabemodell in Canvas-Feld 7 hat direkte Konsequenzen für die Pilot-Ausgestaltung. Grün — vollständig automatisierbar: Interne Konsequenzen, jederzeit korrigierbar. Gelb — Mensch reviewt vor externem Output: Review-Touchpoint und zuständige Person müssen explizit benannt sein. Der Review muss echter Review sein — nicht bloßes Durchklicken. Rot — explizite Freigabe mit Dokumentation: Namentliche Freigabe mit dokumentierter Begründung. Häufiger Fehler: Use Cases werden reflexartig als Gelb klassifiziert, ohne zu prüfen, ob Grün ausreicht. Überklassifikation erzeugt unnötigen Overhead. Faustregel: Klassifizieren Sie so niedrig wie das Risiko es zulässt.

Sieben typische Canvas-Fehler: (1) Lösungsorientiertes Problem-Statement — das ist keine Problembeschreibung. (2) Fehlende Quantifizierung. (3) Zu viele generische Risiken statt drei spezifischer. (4) Nur Befürworter als Stakeholder. (5) Vage nächste Schritte. (6) Datenbasis als Checkbox ohne tatsächliche Zugänglichkeitsprüfung. (7) Canvas als Einmalprodukt — nach jedem Pilot-Zwischenstand aktualisieren.

Merksatz

Ein Canvas, den Sie in zehn Minuten ausgefüllt haben, hat wahrscheinlich die unbequemen Fragen weggelassen. Ein vollständiger Canvas braucht 60–90 Minuten — und diese Zeit ist die wertvollste im gesamten KI-Projekt.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

Als Muster-Canvas für ein IT-Beratungshaus dient der Use Case „Angebots-KI-Assistent”: Feld 1: Beraterinnen und Berater verbringen durchschnittlich 90 Minuten mit der Vorbereitung eines Angebots, davon 55 Minuten mit der manuellen Zusammenführung von Kundendaten aus CRM, Projekthistorie aus SharePoint und aktueller Preisliste aus dem Intranet. Diese 55 Minuten sind nicht wertschöpfend und stehen täglich nicht für Kundengespräche zur Verfügung. Feld 3: RAG-basierter Assistent (Configure), der auf CRM-Kundendaten, SharePoint-Projektdokumentation und Preisliste zugreift. Governance-Klasse: Gelb (Berater reviewt vor Versand). Feld 8: Leading KPI — Anzahl der wöchentlichen Assistent-Nutzungen (Ziel: mind. 80 % der Berater nach vier Wochen). Lagging KPI — Angebots-Vorbereitungszeit (Ziel: unter 40 Minuten nach acht Wochen). Feld 9: Risiken: API-Zugang zu CRM nicht vorhanden → IT-Anfrage für API-Token; Kundendaten im RAG-System → EU-konforme Plattform; Berater vertrauen KI-Entwurf nicht → Transparenz über Quellen, Gelb-Klassifikation.

Industrie & Fertigung

Im Fertigungsumfeld ist der Canvas für einen Wartungsassistenten ein gutes Beispiel: Feld 1: Wartungstechniker verbringen durchschnittlich 25 Minuten pro Wartungsauftrag damit, die relevante Wartungsanleitung in verschiedenen Dokumentenordnern zu suchen und die zugehörigen Ersatzteilnummern zu identifizieren. Dies verzögert den Wartungsstart um bis zu 30 % der gesamten Wartezeit. Feld 3: RAG-basiertes System, das Wartungsanleitungen, Fehlercodes und Ersatzteilkataloge durchsuchbar macht — Zugang via Tablet am Arbeitsplatz. Governance-Klasse: Grün für Informationsabruf. Feld 9: Technisches Risiko: veraltete Wartungsanleitungen → viertelj​ährliches Datenbank-Review; Sicherheitsrisiko: falsche Wartungsanleitung könnte zu Maschinenschaden führen → Quellenangabe bei jedem Abruf, Experten-Review für kritische Anlagen.

Finanzdienstleistung & Versicherung

Im Finanzdienstleistungskontext ist der Canvas für einen Dokumentenprüfungs-Assistenten besonders relevant: Feld 1: Sachbearbeitende verbringen bei der Kreditantragsbearbeitung durchschnittlich 35 Minuten damit, eingehende Dokumente (Einkommensnachweise, Kontoauszüge, Ausweiskopien) manuell auf Vollständigkeit zu prüfen und in das Kernsystem einzutragen. Bei 40 Anträgen pro Tag ergibt das 1.400 Minuten gebundene Kapazität. Feld 7: Governance-Klasse Gelb — die KI prüft auf Vollständigkeit und kennzeichnet Lücken, aber die finale Einschätzung verbleibt beim Sachbearbeitenden. Feld 9: DSGVO-Risiko: Einkommensnachweise enthalten sensible personenbezogene Daten → ausschließlich EU-konforme Plattform, kein Training auf Kundendaten; Diskriminierungsrisiko: Bias in Mustererkennungsmodellen → regelmäßiges Fairness-Audit.

Öffentliche Verwaltung

Im Verwaltungskontext steht Datenschutz im Mittelpunkt jedes Canvas: Feld 1: Sachbearbeitende im Einwohnermeldeamt beantworten täglich durchschnittlich 80 Bürgeranfragen zu Standardleistungen (Meldebestätigung, Ummeldung, Passverlängerung). 60 % dieser Anfragen sind identische Fragen, die 4–6 Minuten Bearbeitungszeit pro Anruf binden. Feld 7: Governance-Klasse Grün für reine Informationsauskünfte — keine persönlichen Daten abgefragt. Feld 9: Datenschutz-Risiko: Bürger könnten aus Gewohnheit persönliche Daten in die KI-Anfrage eingeben → explizite Hinweistexte; Akzeptanzrisiko: ältere Bürger bevorzugen menschliche Ansprechperson → hybrider Ansatz mit KI-Unterstützung, nicht KI-Ersatz.

Übung 1 — Canvas ausfüllen: Ihr Top-Use-Case

Übung 1 — Canvas ausfüllen

Aufgabe: Füllen Sie alle zehn Felder des Use-Case-Canvas für Ihren Top-1-Prozess aus UE 86 aus.

Material: Canvas-Vorlage (A3-Format oder Miro-Template), Ergebnisse aus UE 85 (SIPOC) und UE 86 (Potenzialmatrix).

Schritt-für-Schritt: 1. Feld 1 (Problem-Statement): Schreiben Sie drei präzise Sätze aus Nutzerperspektive — wer ist betroffen, was kostet das Problem? 2. Feld 2: Übertragen Sie die betroffenen Prozessschritte aus Ihrem SIPOC. 3. Feld 3: Schreiben Sie eine Arbeitshypothese für die KI-Lösung. 4. Feld 4: Listen Sie auf, welche Daten benötigt werden. Wo liegt sie? Welches Format? Ist sie zugänglich? 5. Feld 5: Identifizieren Sie die Systeme, die integriert werden müssen. 6. Feld 6: Nennen Sie alle betroffenen Stakeholder — explizit auch potenzielle Skeptiker. 7. Feld 7: Klassifizieren Sie nach dem Drei-Stufen-Freigabemodell. Begründen Sie die Wahl. 8. Feld 8: Formulieren Sie je einen Leading und einen Lagging KPI mit konkreten Zielwerten. 9. Feld 9: Nennen Sie die drei realistischsten Risiken mit je einer Mitigationsmaßnahme. 10. Feld 10: Definieren Sie drei konkrete nächste Schritte mit Verantwortlichen und Datum.

Erwartetes Ergebnis: Vollständig ausgefüllter Canvas mit allen zehn Feldern, messbaren KPIs und konkreten nächsten Schritten.

Musterlösung: Alle zehn Felder sind befüllt. Problem-Statement benennt konkrete Zahlen (55 Minuten). KPIs sind messbar (Zielwert + Zeithorizont). Risiken umfassen technisches Risiko (API-Zugang nicht vorhanden → IT-Anfrage), Datenschutzrisiko (Kundendaten im RAG-System → EU-konforme Plattform), Akzeptanzrisiko (Vertrauen in KI-Entwurf fehlt → Transparenz, Gelb-Klassifikation).

Merksatz

Ein Canvas, das nach dem Workshop in der Schublade landet, hat seinen Zweck nicht erfüllt. Das Canvas ist ein lebendiges Arbeitsdokument — es wird mit jedem Gespräch mit IT, Datenschutz oder Geschäftsführung aktualisiert. Die Version nach dem ersten IT-Gespräch ist wertvoller als die Originalversion.

Anwendungshinweis — Canvas als Gesprächsleitfaden

Das Use-Case-Canvas hat neben seiner Dokumentationsfunktion eine oft unterschätzte Gesprächsfunktion. Wenn Sie das Canvas einer Person zeigen, die den Use Case nicht kennt, und sie bittet, es still zu lesen und dann drei Fragen zu stellen — bekommen Sie präzise Hinweise auf unvollständige oder unklare Felder. Nutzen Sie das Canvas als Gesprächsleitfaden für:

IT-Gespräch: Fokus auf Feld 5 (Datenbasis), Feld 6 (technische Anforderungen) und Feld 10 (nächster Schritt).

Datenschutz-Gespräch: Fokus auf Feld 5 (DSGVO-Prüfung), Feld 8 (Risiken: Datenschutz-Risiken).

Betriebsrat-Gespräch: Fokus auf Feld 2 (Zielgruppe: betrifft es Mitarbeitende?), Feld 8 (Risiken: Mitbestimmung), Feld 7 (Erfolgskriterien: keine Überwachungsfunktion).

Geschäftsführungs-Gespräch: Fokus auf Feld 1 (Problem: messbar?), Feld 7 (KPIs: quantifizierbar?), eine Zeile Business-Case-Schätzung.

Übung 2 — Partner-Review: Canvas-Qualitätsprüfung

Übung 2 — Partner-Review

Aufgabe: Tauschen Sie Ihren Canvas mit einer anderen teilnehmenden Person aus und führen Sie einen strukturierten Qualitäts-Review durch (Klarheitstest, Messbarkeitstest, Ehrlichkeitstest).

Schritt-für-Schritt: 1. Lesen Sie den Canvas Ihrer Partnerin / Ihres Partners vollständig durch. 2. Führen Sie die drei Tests durch und notieren Sie Ihr Ergebnis (bestanden / nicht bestanden) mit Begründung. 3. Formulieren Sie für jedes „nicht bestanden” einen konkreten Verbesserungsvorschlag. 4. Geben Sie das Feedback mündlich in fünf Minuten — konstruktiv und präzise. 5. Überarbeiten Sie Ihren eigenen Canvas auf Basis des erhaltenen Feedbacks.

Erwartetes Ergebnis: Überarbeiteter Canvas mit einer schriftlichen Notiz, welche drei Punkte durch das Partner-Feedback verbessert wurden.

Musterlösung: Typische Review-Ergebnisse: Klarheitstest — Problem-Statement enthält noch kein quantifiziertes Beispiel. Messbarkeitstest — Lagging KPI lautet „weniger Zeit” anstatt „unter X Minuten innerhalb Y Wochen”. Ehrlichkeitstest — Risiko-Feld enthält nur generische „Datenschutzrisiken”, ohne Bezug auf spezifische Datenkategorien.

Cheatsheet — Die wichtigsten Punkte

Canvas-Reihenfolge: Mit Problem-Statement beginnen — nicht mit der Lösung

Problem-Statement-Test: Drei Sätze, Nutzerperspektive, konkrete Zahl oder Beispiel

KPI-Regel: Mindestens ein Leading + ein Lagging Indicator

Governance-Pflicht: Jeder Canvas braucht eine Ampelklasse

Datenbasis-Ehrlichkeit: Feld 4 zeigt, ob das Projekt machbar ist — nicht schönreden

Canvas-Tiefe: Eine Seite — kein Bericht. Präzision, keine Vollständigkeit

Risiko-Pflicht: Drei echte, use-case-spezifische Risiken

Stakeholder-Pflicht: Auch Skeptiker explizit benennen

Lebendes Dokument: Canvas nach dem Pilot updaten

IT liest F4+F5, Geschäftsführung F1+F8+F10, Betriebsrat F6+F7+F9

Reflexionsfragen

Welches der zehn Felder fiel Ihnen beim Ausfüllen am schwersten — und was sagt das über den Reifegrad des Use Cases aus?

Wie unterscheidet sich Ihr Canvas von einer Präsentationsfolie über denselben Use Case?

Wann wäre es sinnvoll, einen Canvas nicht auszufüllen — und stattdessen einen Use Case direkt zu verwerfen?

Wie stellen Sie sicher, dass Feld 10 (Nächste Schritte) nach der UE wirklich ausgeführt wird?

Prompt-Vorlage — Use-Case-Canvas für einen KI-Anwendungsfall entwickeln

Prompt für einen KI-Assistenten:

Ich möchte einen Use-Case-Canvas für folgenden KI-Anwendungsfall erstellen: [Use-Case-Titel, z. B. KI-gestütztes Erstangebot für Beratungsprojekte”]. Die Zielgruppe ist [Nutzergruppe]. Das Hauptproblem ist [Problem in einem Satz]. Hilf mir, alle zehn Canvas-Felder auszufüllen: (1) Problem-Statement aus Nutzerperspektive, (2) Zielgruppe und Nutzungskontext, (3) Aktueller Prozess (Ist-Zustand), (4) KI-Lösungsansatz, (5) Benötigte Datenbasis, (6) Technische Anforderungen, (7) Messbare Erfolgskriterien (KPIs), (8) Risiken und Mitigationsmaßnahmen, (9) Relevante Stakeholder, (10) Nächster konkreter Schritt im Pilot.”

Erwartetes Ergebnis: Ein vollständig ausgefüllter Use-Case-Canvas, der direkt als Kommunikationsdokument für IT-Abteilung, Geschäftsführung und Betriebsrat eingesetzt werden kann. Hinweis: Überprüfen Sie das generierte Ergebnis kritisch: Erfolgskriterien (Feld 7) müssen messbar und zeitgebunden sein. Vage Formulierungen wie Effizienz verbessern sind kein messbares Erfolgskriterium.

Quellen & Weiterlesen

Übung 3 — Stakeholder-Analyse für den Use Case

Übung 3 — Stakeholder-Analyse: Wer muss überzeugt werden?

Aufgabe: Identifizieren Sie alle relevanten Stakeholder für Ihren Use Case und analysieren Sie ihre erwartete Haltung (supportiv, neutral, skeptisch) sowie ihren Einfluss auf die Implementierungsentscheidung.

Schritt-für-Schritt: 1. Erstellen Sie eine Stakeholder-Tabelle mit vier Spalten: Name / Rolle | Einfluss (hoch / mittel / gering) | Erwartete Haltung (supportiv / neutral / skeptisch) | Schlüsselbedenken. 2. Tragen Sie mindestens sechs Stakeholder ein: Direkte Nutzer, Teamleitung, IT-Leitung, Datenschutzbeauftragte/r, Betriebsrat (falls vorhanden), Geschäftsführung. 3. Identifizieren Sie für jeden skeptischen Stakeholder das Hauptbedenken und formulieren Sie ein sachliches Gegenargument. 4. Markieren Sie den Stakeholder mit dem höchsten Einfluss und skeptischer Haltung — das ist Ihre wichtigste Überzeugungsaufgabe.

Erwartetes Ergebnis: Eine vollständige Stakeholder-Tabelle mit konkreten Gegenargumenten für die Top-3-Bedenken — als Vorbereitung für das nächste Abstimmungsgespräch.

Musterlösung — Use Case Wissens-RAG-Assistent:

Wichtigste Überzeugungsaufgabe: Betriebsrat (hoher Einfluss, skeptisch). Schlüsselargument: Explizite Zusicherung in der Betriebsvereinbarung, dass keine Nutzungsdaten je Mitarbeitendem erhoben werden.

Hinweise für AI Champions — So vermitteln Sie das Thema — UE 87

Timing (45 Min): 5 Min Einstieg (Warum Canvas vs. „mal schnell starten”), 15 Min Lerntext (10 Felder + Qualitätstests), 18 Min Übung 1 (Canvas ausfüllen), 5 Min Reflexion / Peer-Review-Vorbereitung, 2 Min Puffer.

Methodische Empfehlung: Verteilen Sie die Canvas-Vorlage vorab (idealerweise bereits in der letzten UE als Hausaufgabe). Teilnehmende, die mit einem halbfertigen Canvas in die UE kommen, erzielen deutlich bessere Ergebnisse als Teilnehmende, die von Null beginnen. Betonen Sie, dass der Canvas eine Arbeitshypothese ist — kein finales Dokument. Das reduziert Perfektionismus und beschleunigt das Ausfüllen.

Häufige Stolpersteine: (a) Feld 1 wird als Lösungsbeschreibung formuliert — aktiv eingreifen und den „Problem-first”-Ansatz einfordern. (b) Feld 8 enthält keine konkreten Zielwerte — auf die Formel „unter X Einheiten innerhalb Y Wochen” bestehen. (c) Feld 9 enthält Standardfloskeln — nachfragen: „Welches spezifische Datenschutzrisiko gilt für Ihre Daten?”

Diskussionsfragen für Plenum: (1) „Welches Feld hat in Ihrem Canvas am längsten gedauert — und warum?” (2) „Wo mussten Sie sich eingestehen, dass Ihr Use Case doch nicht so klar ist, wie Sie dachten?”

Tafelbild-Vorschlag: Die zehn Canvas-Felder als Rasterdiagramm (2×5 oder 3×3+1), farblich nach den vier Clustern (Problem/Kontext, Lösung/Technologie, Menschen/Governance, Messung/Risiken) eingeteilt.

Differenzierung Power-User ↔ Einsteiger: Power-User führen zusätzlich die Five-Whys-Methode für Feld 1 durch und dokumentieren die Iterations-Kette. Einsteiger konzentrieren sich auf vollständiges Ausfüllen aller Felder.

Materialliste: Canvas-Vorlage (A3, ausgedruckt oder Miro), Ergebnisse aus UE 85/86 (SIPOC, Potenzialmatrix), Stifte für Präsenz-Workshop.

Übergang zur nächsten UE: „Ihr Canvas beschreibt den Use Case. In UE 88 entscheiden wir, in welcher Reihenfolge mehrere Use Cases angegangen werden — mit drei Priorisierungsmethoden aus dem Product Management.”

Tipp zur Branchenauswahl: Die IT-Dienstleistungs-Vignette (Angebots-KI-Assistent) funktioniert als vollständig ausgefülltes Muster-Canvas besonders gut für alle Branchen, weil die Logik (Zeitersparnis bei Informationszusammenführung) universell nachvollziehbar ist. Ergänzen Sie die branchenspezifische Vignette für Ihr konkretes Kunden-Publikum als zweites Beispiel.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.