Warum diese Phase über den Erfolg entscheidet

In den meisten Unternehmen, die KI ernsthaft einsetzen wollen, ist die Frage nach den ersten Vorhaben unterschätzt. Sie wirkt wie ein Workshop-Thema, das man in wenigen Stunden abschließt: Ideen sammeln, bewerten, eine Liste erstellen. In Wahrheit entscheidet hier mehr als an jedem späteren Schritt.

Wer mit den falschen Use Cases startet, verschiebt nicht nur die ersten Erfolge, sondern verbrennt das, was am wertvollsten ist: das Vertrauen der eigenen Organisation in die neue Technologie. Ein gescheiterter Pilot wirkt drei Quartale lang nach. Ein überzeugender erster Use Case macht den zweiten und dritten leichter zu bekommen.

Die gute Nachricht: Use-Case-Identifikation lässt sich strukturieren. Sie ist keine kreative Übung, in der die spannendste Idee gewinnt, sondern ein Auswahlprozess entlang weniger, klar benannter Kriterien.

Wo gute Use Cases tatsächlich herkommen

Die schlechteste Quelle für Use Cases ist die Suche nach „KI-Anwendungen" als abstrakte Kategorie. Sie führt zu Listen, die in jedem Unternehmen gleich aussehen und in keinem zur konkreten Wertschöpfung passen.

Die beste Quelle ist die eigene Organisation, wenn man sie an drei Stellen ehrlich zuhört. Erstens dort, wo Teams regelmäßig über zu viel manuelle Arbeit klagen — meist in Backoffice, Service, Vertriebsunterstützung oder Fachbereichs-Reporting. Zweitens dort, wo Wissen verteilt liegt und das Auffinden Zeit kostet. Drittens dort, wo Antworten auf Routinefragen in unterschiedlichen Teams unterschiedlich ausfallen, weil niemand die Quelle der Wahrheit nutzt.

Die zweitbeste Quelle sind anstehende geschäftliche Entscheidungen, in denen besseres oder schnelleres Verständnis von Daten den Unterschied macht. Hier landet man oft im Bereich von Conversational Analytics oder bei strukturierten Dokumenten- und Prozessfragen — Themen, die wir in unseren Projekten häufig sehen.

Was sich in dieser Phase nicht lohnt: Use-Case-Listen aus Marktstudien zu übernehmen. Sie zeigen, was möglich ist, aber nicht, was im eigenen Unternehmen tatsächlich trägt.

Vier Dimensionen, die einen Use Case bewertbar machen

Sobald eine Liste an Kandidaten steht, beginnt die eigentliche Arbeit: die Bewertung. Vier Dimensionen reichen in den meisten Fällen aus, um aus einer Sammlung von Ideen eine belastbare Reihenfolge zu machen.

Die erste Dimension ist geschäftlicher Wert. Was ändert sich messbar, wenn der Use Case läuft? Eingesparte Zeit, schnellere Antworten, geringere Fehlerquoten, höhere Abschlussraten. Wer den Wert nicht in einer Größenordnung beziffern kann, sollte den Use Case nicht oben einsortieren.

Die zweite Dimension ist Datenlage und technische Voraussetzung. Welche Datenquellen werden gebraucht, in welcher Qualität liegen sie vor, sind sie zugänglich, sind sie aktuell? Ein Use Case mit hohem Wert und schlechter Datenlage ist nicht falsch — er ist nur deutlich teurer als er aussieht. Welche Qualitätsdimensionen für KI wirklich zählen und welche Mängel im Betrieb am meisten wehtun, haben wir im Beitrag zur Datenqualität für KI-Projekte ausführlich aufgeschlüsselt.

Die dritte Dimension ist organisatorische Bereitschaft. Gibt es ein Team oder eine Person, die den Use Case fachlich verantworten kann? Sind die Stakeholder im Fachbereich offen für Veränderung des Arbeitsmodells, oder wird das Vorhaben als Bedrohung wahrgenommen? Auch der beste Use Case scheitert, wenn niemand ihn betreuen will.

Die vierte Dimension ist Anschlussfähigkeit. Was lernen wir aus diesem Use Case für den nächsten? Welche Daten, Schnittstellen oder Plattformteile entstehen nebenbei und können später wiederverwendet werden? Diese Dimension wird häufig vergessen — und ist genau das, was eine Use-Case-Liste von einer Pipeline unterscheidet.

Welche Use Cases sich für den Einstieg eignen — und welche nicht

Aus diesen vier Dimensionen lässt sich ein einfaches Profil für gute Einstiegs-Use-Cases ableiten. Sie haben einen sichtbaren, gut benennbaren Wert, eine zumindest brauchbare Datenlage, einen klaren fachlichen Owner und schaffen Bausteine, die später nochmal gebraucht werden.

Konkret eignen sich für den Einstieg häufig: assistierende Anwendungen, in denen ein Mensch die Verantwortung behält, etwa Recherche- und Wissensassistenten auf einem klar umrissenen Inhaltsbereich; Klassifikations- oder Extraktionsaufgaben mit reproduzierbarem Output, etwa in der Dokumentenverarbeitung; sowie unterstützende Werkzeuge in Service- oder Fachbereichs-Teams, die einen wiederkehrenden Engpass adressieren.

Weniger geeignet für den Einstieg sind autonome Agenten in geschäftskritischen Prozessen, große strategische Plattformprojekte mit langer Vorlaufzeit oder Use Cases, die intern politisch unklar sind. Diese Vorhaben können später richtig sein — als erstes Projekt sind sie meistens zu groß, um schnell zu lernen.

Wer früh über den Schritt KI-Agenten und Automatisierung nachdenkt, sollte sich bewusst entscheiden, ob ein erster Use Case wirklich agentisch sein muss oder ob ein klar strukturierter Workflow mit punktueller KI-Unterstützung schneller Wirkung zeigt — diese Abwägung haben wir im Beitrag KI-Agent oder fester Workflow ausgeführt.

Wie aus einer Bewertung eine Pipeline wird

Eine bewertete Liste ist noch keine Pipeline. Eine Pipeline entsteht erst, wenn die ausgewählten Use Cases zueinander in Beziehung gesetzt werden — zeitlich, thematisch und in Bezug auf die Bausteine, die sie schaffen.

Drei Punkte machen aus einer Liste eine echte Pipeline. Erstens eine bewusste Reihenfolge, in der frühe Use Cases die Voraussetzungen für spätere mit aufbauen (Datenanbindungen, Wissensbasis, Berechtigungsstrukturen). Zweitens eine ehrliche Kapazitätsplanung, in der nicht alle Vorhaben parallel beginnen, sondern in einem Tempo, das die Organisation tragen kann. Drittens explizit benannte Lernfragen pro Use Case: Was wollen wir aus diesem Vorhaben über uns als KI-Organisation herausfinden, unabhängig vom konkreten Ergebnis?

Diese Pipeline ist kein statischer Plan. Sie verändert sich, sobald die ersten Vorhaben in den Betrieb gehen — denn der Schritt vom Pilot zur Produktion verändert oft die Annahmen, mit denen die Liste ursprünglich gebaut wurde. Eine gute Pipeline ist deshalb so geschnitten, dass sie quartalsweise nachgeschärft werden kann.

Wirtschaftlichkeit ehrlich rechnen

Auswahl und Priorisierung müssen früh mit einer realistischen Wirtschaftlichkeitsrechnung verknüpft werden — nicht für eine perfekte Business-Case-Tabelle, sondern um Größenordnungen klarzustellen.

Drei Kostenblöcke werden in dieser Phase regelmäßig unterschätzt: die Vorbereitung und laufende Pflege der Daten, die Qualitätssicherung im Betrieb und die organisatorische Begleitung der Veränderung. Wer diese Blöcke nicht einpreist, erzeugt Use Cases, die im Pitch überzeugen und im Folgequartal politisch in Erklärungs- not geraten. Den Rahmen einer ehrlichen Bewertung haben wir im Artikel zum KI-ROI im Unternehmen ausgeführt — die dort beschriebenen Ebenen sind genau die, die in der Use-Case-Phase gegenseitig sortiert werden müssen.

Typische Fehler in dieser Phase

Der häufigste Fehler ist, zu viele Use Cases parallel zu starten. Eine Roadmap mit zwölf Vorhaben sieht ambitioniert aus und verpufft regelmäßig in Halbfertigem. Drei ernsthaft begleitete Use Cases im ersten halben Jahr sind in fast allen Fällen wertvoller als ein Dutzend Pilotprojekte, die nicht über ein Demo hinauskommen.

Der zweite Fehler ist, Use Cases nach Begeisterung statt nach Bewertung zu wählen. Was im Workshop für Aufregung sorgt, ist nicht zwingend das Vorhaben, das im Tagesgeschäft den größten Unterschied macht. Eine sachliche Punktbewertung entlang der vier Dimensionen schützt vor diesem Reflex.

Der dritte Fehler ist, die Auswahl rein technisch zu treffen. Use Cases ohne fachlichen Owner sind in Wahrheit keine Use Cases, sondern Demos. Vor dem Start sollte klar sein, wer den Vorgang nach Go-live verantwortet, in welcher Rolle und mit welchem Mandat.

Der vierte Fehler ist, sich zu früh auf eine Build-vs.-Buy-Entscheidung festzulegen. Diese Frage gehört nach die Use-Case-Auswahl, nicht davor — sonst entscheidet die Beschaffungsform den Inhalt. Wann welche Variante sinnvoll ist, beschreiben wir im Artikel zu Build vs. Buy bei KI-Assistenten.

Wann externe Unterstützung sinnvoll ist

Eine erste Use-Case-Liste lässt sich in jedem Unternehmen intern erarbeiten. Schwierig wird es bei der Bewertung über Bereichsgrenzen hinweg, bei der ehrlichen Einschätzung der Datenlage und beim Schneiden einer Pipeline, die mehr ist als eine Wunschliste. Genau dort lohnt sich ein Blick von außen.

Wir begleiten diesen Schritt im Rahmen unseres AI Consulting und gehen ihn bewusst nicht als reinen Workshop an. Ergebnis ist nicht eine Liste, sondern eine begründete Reihenfolge, eine erste belastbare Architekturidee und eine Klarheit darüber, welche Vorhaben sich besser intern, gemeinsam mit uns oder hybrid umsetzen lassen.