Use-Case-Discovery-Workshop: priorisierte KI-Use-Cases
Ein strukturierter Workshop, der Kandidaten für KI-Automatisierung erhebt, bewertet und nach Machbarkeit und Geschäftswert zu einer Shortlist priorisiert.
Ein strukturierter Workshop, der Kandidaten für KI-Automatisierung erhebt, bewertet und nach Machbarkeit und Geschäftswert zu einer Shortlist priorisiert.
Die meisten KI-Use-Case-Listen scheitern aus einem unglamourösen Grund: Niemand hat die Datenlage geprüft, bevor sich alle in eine Idee verliebt haben. Ein Whiteboard voller Klebezettel, sortiert in Cluster wie "Kundenerlebnis" und "Effizienz", bei allgemeinem Kopfnicken im Raum, erzeugt Energie, aber keine Shortlist, und Energie hält der ersten Nachfrage des CFO nicht stand, welche der vierzig Ideen tatsächlich verwertbare Daten dahinter hat. Genau diesen Ausgang soll der Use-Case-Discovery-Workshop verhindern. Er ist kein Ideenfindungs-Meeting im klassischen Sinn, sondern ein strukturierter Erhebungs- und Bewertungsprozess mit einem klar definierten Output: eine kurze, begründete Rangliste von Prozessen, die sich für KI-gestützte Automatisierung eignen, sortiert nach Umsetzbarkeit und Wirkung auf das Geschäft, nicht nach Begeisterung im Raum.
Dieser Workshop ist eine von vier konkreten Workshop-Formaten, die zusammen mit der strategischen Beratungsarbeit ein durchgängiges Vorgehen ergeben. Wo der Executive-Alignment-Workshop die Führungsebene auf ein gemeinsames Zielbild und Mandat einschwört, und der Team-Enablement-Workshop die operative Ebene auf den Umgang mit neuen Werkzeugen vorbereitet, liegt die Aufgabe der Use-Case-Discovery dazwischen: Sie übersetzt eine grobe strategische Ambition ("Wir wollen KI produktiv einsetzen") in eine Liste konkreter, geprüfter Kandidaten, mit denen tatsächlich gearbeitet werden kann. Wer noch keine Strategiearbeit geleistet hat, sollte zuerst einen Blick auf die Beratungsleistungen unter /beratung werfen oder mit dem AI-Readiness-Check den eigenen Ausgangspunkt klären. Ein Discovery-Workshop ohne vorherige Readiness-Einschätzung läuft Gefahr, Use Cases zu priorisieren, die an der Datenlage oder der organisatorischen Reife scheitern, bevor sie überhaupt starten.
Der Workshop selbst ist bewusst kein Trainingsformat. Es geht nicht darum, Teilnehmenden zu erklären, was ein Sprachmodell ist oder wie Prompting funktioniert (dafür gibt es den Agent-Prompt-Design-Workshop). Es geht darum, mit den Menschen, die die Prozesse eines Unternehmens tatsächlich kennen, systematisch durch das Prozessportfolio zu gehen und herauszuarbeiten, wo Automatisierung durch KI heute schon plausibel machbar ist und wo sie einen messbaren Unterschied machen würde. Das ist eine analytische Aufgabe, die Moderation, Struktur und Fachwissen braucht, keine Schulung.
Ein guter Discovery-Workshop beginnt nicht am Workshoptag, sondern zwei bis drei Wochen davor. Drei Elemente sind dabei entscheidend.
Erstens die Prozesslandkarte. Bevor im Raum diskutiert wird, sollte eine grobe Übersicht der relevanten Geschäftsprozesse vorliegen, meist aus Interviews mit Abteilungsleitungen oder aus vorhandener Prozessdokumentation. Diese Landkarte muss nicht vollständig sein, aber sie sollte die Bereiche abdecken, in denen die größten Freiheitsgrade oder die größten Schmerzpunkte vermutet werden: Kundenservice, Angebotserstellung, Dokumentenprüfung, interne Reportings, Recruiting, Content-Produktion, technischer Support und ähnliche wiederkehrende, arbeitsintensive Abläufe. Ohne diese Vorarbeit verbringt der Workshop wertvolle Zeit damit, überhaupt erst zu klären, welche Prozesse es gibt, statt sie zu bewerten.
Zweitens die Auswahl der Teilnehmenden. Das ist die Stellschraube, die über Erfolg oder Misserfolg des Formats am stärksten entscheidet. Der Raum braucht eine Mischung aus drei Rollen: Menschen, die den Prozess im Detail ausführen und seine Ausnahmen, Umwege und Frustpunkte kennen; eine Führungskraft mit Budget- und Entscheidungsbefugnis für den jeweiligen Bereich, die im Nachgang auch tatsächlich etwas bewegen kann; und mindestens eine Person mit technischem Verständnis, die realistisch einschätzen kann, ob eine Idee an Datenzugriff, Systemlandschaft oder Governance-Vorgaben scheitert. Fehlt die erste Gruppe, bleiben die Use Cases oberflächlich und praxisfern. Fehlt die zweite, bleibt jede Priorisierung folgenlos, weil niemand im Raum sitzt, der hinterher ein Budget freigibt. Fehlt die dritte, entstehen Ranglisten, die technisch naiv sind und in der Pilotphase an der Realität zerschellen. Sechs bis zehn Teilnehmende sind in der Regel die praktikable Obergrenze für eine Sitzung, die noch echte Diskussion statt Frontalpräsentation erlaubt; bei größeren Organisationen empfiehlt sich eher eine Serie kleinerer, bereichsspezifischer Sessions mit einer gemeinsamen Konsolidierung am Ende.
Drittens ein kurzer Fragebogen oder ein Vorgespräch mit den wichtigsten Teilnehmenden, um bereits im Vorfeld eine erste, ungefilterte Liste von Prozess-Kandidaten und Frustpunkten einzusammeln. Das hat zwei Effekte: Es verhindert, dass der Workshop selbst zur ersten Ideensammlung verkommt, und es liefert der Moderation ein Gefühl dafür, wo im Unternehmen bereits Konsens oder Uneinigkeit über naheliegende Kandidaten besteht.
Die meisten Discovery-Workshops lassen sich in einem vollen Tag oder in zwei kompakten Halbtagen mit etwas Abstand dazwischen durchführen. Ein Tagesformat mit Pause zwischen Sammlung und Bewertung hat sich in der Praxis oft bewährt, weil es den Teilnehmenden erlaubt, über Mittag mental von der reinen Erhebung in den kritischeren Bewertungsmodus zu wechseln.
Der Vormittag beginnt mit einem kurzen Rahmen: zehn bis fünfzehn Minuten, in denen Zielsetzung, Spielregeln und der geplante Output des Tages klargestellt werden. Wichtig ist hier die explizite Ansage, dass am Ende des Tages eine kurze Liste steht, nicht eine lange, und dass "Nicht jetzt" eine legitime und häufige Antwort für einen Use Case ist. Diese Erwartungssteuerung zu Beginn erspart später Enttäuschung und Verteidigungshaltung.
Danach folgt die Erhebungsphase, typischerweise als strukturierter Prozess-Walkthrough. Statt frei zu brainstormen, arbeitet die Gruppe Bereich für Bereich durch die vorbereitete Prozesslandkarte und beantwortet für jeden relevanten Prozess eine feste Reihe von Fragen: Wie oft läuft dieser Prozess, mit wie viel manuellem Aufwand pro Durchlauf? Wo entstehen Wartezeiten, Fehler oder Rückfragen? Welche Entscheidungen darin sind heute stark regelbasiert und welche erfordern echtes Ermessen? Welche Daten und Dokumente fließen hinein, und in welchem Format liegen sie vor? Diese Fragen zwingen die Diskussion weg von "Das wäre doch cool mit KI" hin zu einer nüchternen Beschreibung des Ist-Zustands, aus der sich Automatisierungspotenzial ableiten lässt statt nur behauptet wird.
Nach der Mittagspause folgt die Bewertungsphase. Jeder gesammelte Kandidat wird entlang von zwei Achsen eingeordnet: Geschäftswert und Machbarkeit. Geschäftswert setzt sich zusammen aus eingesparter Zeit, reduziertem Fehlerrisiko, schnellerer Durchlaufzeit oder direktem Umsatzeffekt, je nachdem, was im jeweiligen Prozess relevant ist. Machbarkeit setzt sich zusammen aus Datenverfügbarkeit und Datenqualität, Klarheit der Aufgabe (ist die gewünschte Ausgabe eindeutig beschreibbar, oder hängt sie von unausgesprochenem Erfahrungswissen ab), Integrationsaufwand in bestehende Systeme, sowie regulatorischen und Governance-Anforderungen, etwa wenn personenbezogene Daten, vertragsrelevante Entscheidungen oder Kundenkommunikation betroffen sind. Diese Bewertung erfolgt nicht durch Zuruf, sondern durch ein strukturiertes Verfahren, das im nächsten Abschnitt beschrieben wird.
Der späte Nachmittag ist der Konsolidierung vorbehalten: die zehn bis fünfzehn am besten bewerteten Kandidaten werden gemeinsam diskutiert, offene Fragen benannt, Verantwortliche für die nächsten Schritte festgelegt, und die finale Shortlist von in der Regel drei bis fünf Kandidaten verabschiedet, die als Grundlage für die Pilotplanung dienen. Ein Workshoptag, der ohne eine solche verdichtete Liste endet, hat sein Ziel verfehlt, unabhängig davon, wie angeregt die Diskussion war.
Die Qualität des Ergebnisses hängt weniger von der Agenda als von der Art ab, wie die Moderation Diskussion und Bewertung strukturiert. Einige Techniken haben sich als besonders wirksam erwiesen.
Stille Ideensammlung vor lauter Diskussion: Bevor über einen Prozessbereich gesprochen wird, schreiben alle Teilnehmenden für fünf Minuten unabhängig voneinander ihre Beobachtungen auf, etwa auf Karten oder in ein geteiltes Dokument. Erst danach wird laut diskutiert. Das verhindert, dass die ersten geäußerten Meinungen die gesamte Diskussion verankern, ein Effekt, der in Gruppen mit ausgeprägter Hierarchie besonders stark ist.
Die Verwendung eines festen Use-Case-Canvas pro Kandidat: eine einseitige Vorlage mit festen Feldern (Prozessbeschreibung, heutiger Aufwand, gewünschtes Ergebnis, Datenquellen, Risiken, geschätzter Wert) zwingt dazu, jeden Kandidaten mit derselben Tiefe zu beschreiben, statt manche Ideen ausführlich zu diskutieren und andere im Vorbeigehen abzunicken.
Eine explizite Bewertungsmatrix statt Bauchgefühl: Geschäftswert und Machbarkeit werden auf einfachen Skalen, etwa von eins bis fünf, von der Gruppe eingeschätzt und in einer Vier-Felder-Matrix visualisiert. Kandidaten mit hohem Wert und hoher Machbarkeit sind die naheliegenden ersten Piloten. Kandidaten mit hohem Wert, aber niedriger Machbarkeit sind wichtig zu kennen, weil sie oft anzeigen, wo im nächsten halben Jahr an Datengrundlagen oder Systemzugängen gearbeitet werden sollte. Kandidaten mit niedrigem Wert werden unabhängig von der Machbarkeit konsequent verworfen oder zurückgestellt, so charmant die Idee auch klingen mag.
Ein bewusstes Rollenspiel der Gegenposition: Für jeden aussichtsreichen Kandidaten wird eine Person explizit gebeten, die Gegenposition einzunehmen und die stärksten Einwände zu formulieren, warum dieser Use Case scheitern könnte. Das entkoppelt kritisches Denken von Personen, die sich sonst scheuen, den Favoriten eines Kollegen offen infrage zu stellen, und macht Risiken sichtbar, bevor Budget dafür gebunden wird.
Zeitboxen statt offener Diskussion: Jeder Prozessbereich bekommt ein festes Zeitfenster, meist fünfzehn bis zwanzig Minuten. Läuft die Diskussion länger, wird sie bewusst abgebrochen und der Punkt in eine Parkliste für die Nachbereitung verschoben. Ohne diese Disziplin frisst ein einziger kontroverser Prozess leicht die Hälfte des Tages und verdrängt die Betrachtung anderer, möglicherweise wertvollerer Kandidaten.
Der häufigste Fehler in unmoderierten Ideenfindungsrunden ist die Verwechslung von Sichtbarkeit mit Wert. Prozesse, über die im Unternehmen viel geredet wird, etwa weil eine Führungskraft sich kürzlich darüber geärgert hat, bekommen in offenen Diskussionen überproportional viel Gewicht, unabhängig davon, ob sie tatsächlich das größte Automatisierungspotenzial bergen. Die feste Struktur aus Prozess-Walkthrough und Bewertungsmatrix wirkt diesem Effekt entgegen, weil jeder Kandidat dieselbe Prüfung durchläuft.
Ein zweiter Fehler ist die Bevorzugung technisch beeindruckender, aber geschäftlich nebensächlicher Ideen. Ein komplexes Multi-Agent-System für einen Prozess, der zweimal im Quartal läuft, ist intellektuell reizvoll, aber selten die richtige erste Priorität. Der Workshop hält dagegen, indem er Häufigkeit und tatsächlichen Aufwand des Prozesses als harte Bewertungskriterien einführt, nicht als Nebensache.
Ein dritter Fehler ist es, Machbarkeit erst in der Pilotphase zu prüfen statt im Discovery-Workshop selbst. Wenn die Frage nach Datenqualität, Systemzugängen und regulatorischen Einschränkungen erst gestellt wird, nachdem ein Business Case geschrieben und Erwartungen geweckt wurden, ist der Rückzug politisch viel teurer, als wenn ein Kandidat schon im Workshop mit der Einschätzung "aktuell nicht machbar, aus diesem konkreten Grund" versehen wird. Deshalb sitzt die technische Perspektive von Anfang an mit im Raum, statt erst nachgelagert konsultiert zu werden.
Ein vierter, subtilerer Fehler ist Konsens um jeden Preis. Wird jeder vorgebrachte Use Case am Ende irgendwie auf die Liste gehievt, um niemanden zu enttäuschen, verliert die Shortlist ihre Funktion. Eine gute Moderation macht das explizite Verwerfen von Kandidaten zu einem normalen, erwarteten Teil des Prozesses und nicht zu einer persönlichen Zurückweisung. Das gelingt am besten, wenn die Bewertungskriterien vorab transparent gemacht wurden und die Entscheidung nachvollziehbar aus der Matrix folgt, statt einer Einzelperson zugeschrieben zu werden.
Das zentrale Ergebnis ist die priorisierte Shortlist, aber der eigentliche Wert entsteht erst in der Übersetzung dieser Liste in handlungsfähige nächste Schritte. Für jeden Kandidaten auf der Shortlist sollte am Ende des Workshops mindestens Folgendes dokumentiert sein: eine knappe Prozessbeschreibung samt heutigem Aufwand, die geschätzte Wirkung bei erfolgreicher Automatisierung, die identifizierten Machbarkeitsrisiken samt der Frage, wer sie klären muss, und eine benannte verantwortliche Person aus dem Fachbereich, die für die weitere Ausarbeitung zur Verfügung steht.
Diese Dokumentation ist die Brücke zur Pilotphase. Statt aus einem Workshop mit vager Euphorie herauszugehen, verlässt die Gruppe den Raum mit einem konkreten, kurzen Katalog an Kandidaten, der sich direkt in eine Pilotplanung überführen lässt: welcher Anwendungsfall wird zuerst angegangen, welche Erfolgskriterien gelten, welche Daten und Zugänge müssen vorab organisiert werden. Wo im Workshop bereits Kandidaten mit hohem Wert, aber unklarer Machbarkeit aufgetaucht sind, liefert das zugleich eine Agenda für parallele Arbeit an Datenzugängen oder Governance-Fragen, die nicht auf den ersten Piloten warten muss.
Ebenso wichtig ist die Rückkopplung zur strategischen Ebene. Die Shortlist sollte der Geschäftsführung oder dem verantwortlichen Steuerungsgremium vorgelegt werden, nicht zur erneuten Diskussion jedes einzelnen Kandidaten, sondern zur Bestätigung von Ressourcenfreigabe und Zeitrahmen. Das schließt den Kreis zur Ausrichtung, die im gelegt wurde: Dort wurde entschieden, warum und in welchem Rahmen KI-Automatisierung verfolgt wird, hier wird konkretisiert, woran das zuerst geschieht.
Ein gelungener Discovery-Workshop lässt sich an mehreren Merkmalen erkennen, die über die reine Existenz einer Liste hinausgehen. Erstens: Die Shortlist ist kurz. Wenn am Ende zwanzig gleichrangige Kandidaten übrig sind, hat die Priorisierung nicht funktioniert, unabhängig davon, wie viel diskutiert wurde. Zweitens: Für jeden Kandidaten auf der Liste kann jede Person im Raum in einem Satz erklären, warum er dort steht und ein anderer, scheinbar naheliegender Kandidat nicht. Diese Nachvollziehbarkeit ist wichtiger als die Liste selbst, weil sie später Rückfragen und Widerstand vorbeugt. Drittens: Mindestens ein Kandidat wurde im Lauf des Tages bewusst verworfen, obwohl er zu Beginn Favorit war. Das ist ein starkes Indiz dafür, dass die Bewertung tatsächlich kritisch war und nicht nur eine Bestätigung vorgefasster Meinungen.
Viertens, und das wird häufig übersehen: Die Teilnehmenden aus den Fachbereichen verlassen den Raum mit dem Gefühl, gehört worden zu sein, auch wenn ihr eigener Vorschlag nicht auf der finalen Liste steht. Das gelingt, wenn Ablehnung immer mit einer konkreten, sachlichen Begründung verbunden ist, etwa fehlender Datenzugang oder zu geringe Prozesshäufigkeit, statt mit einem pauschalen "später vielleicht". Fünftens schließlich: Es existiert am Ende ein klarer nächster Termin oder Verantwortlicher für jeden Kandidaten der Shortlist. Ein Workshop, dessen Ergebnisse in der Woche danach in einer Schublade verschwinden, war unabhängig von der Qualität der Diskussion im Raum keine gute Investition der gebundenen Führungszeit.
Der Use-Case-Discovery-Workshop passt am besten in Organisationen, die eine grundsätzliche strategische Ausrichtung zu KI bereits geklärt haben, sei es durch eigene Vorarbeit oder durch ein vorgelagertes Format wie den , aber noch keine belastbare, priorisierte Antwort auf die Frage haben, womit konkret begonnen werden soll. Er eignet sich weniger für Unternehmen, die noch grundsätzlich klären müssen, ob und wofür sie überhaupt in KI-Automatisierung investieren wollen; dafür ist die Beratungsarbeit unter oder eine erste Standortbestimmung über den der passendere Einstieg. Er eignet sich auch weniger als Ersatz für die technische Detailarbeit, die anschließend in einem Pilotprojekt folgt: Der Workshop liefert die begründete Auswahl und die grobe Machbarkeitseinschätzung, nicht die technische Umsetzungsplanung selbst.
In der Praxis ist dieses Format am wirkungsvollsten als klar abgegrenzter, ein- bis zweitägiger Baustein innerhalb eines größeren Programms: Ausrichtung schaffen, Kandidaten systematisch erheben und priorisieren, dann gezielt in Piloten überführen, während parallel die Teams im Umgang mit den neuen Werkzeugen befähigt werden. Jeder dieser Bausteine funktioniert eigenständig, entfaltet seine volle Wirkung aber im Zusammenspiel mit den anderen. Eine Übersicht aller Workshop-Formate findet sich unter .
Wenn Sie einschätzen möchten, ob ein Use-Case-Discovery-Workshop für Ihre Organisation der richtige nächste Schritt ist, oder wenn Sie einen bestehenden Anwendungsfall-Katalog kritisch gegenprüfen lassen möchten, sprechen Sie uns über an. Wir klären im Vorgespräch, welche Vorarbeit bereits vorliegt, wer im Raum sitzen sollte und wie der Workshop in Ihr laufendes KI-Programm eingebettet werden kann.