Use Cases sammeln ist keine KI-Strategie

Die Ausgangslage: Dringlichkeit ohne Richtung

Viele Geschäftsführer und Unternehmer spüren, dass KI ein ernstzunehmendes Thema ist. Die Dringlichkeit, Resultate zu sehen, ist real. Also wird gehandelt. Aber wie?

In den meisten Fällen beginnt es mit der Aufforderung: "Bringt mir Use Cases." Das klingt pragmatisch und handlungsorientiert. In der Praxis führt es fast immer in eine Sackgasse, weil die eigentliche Frage übersprungen wird: Was muss von oben kommen, damit KI im Unternehmen wirklich wirkt? Und was nicht?

Dieser Artikel beschreibt, warum die gängige Vorgehensweise scheitert, was stattdessen Chefsache sein muss und wie Entscheider die richtigen Prioritäten setzen.

Das Fake-Top-Down-Prinzip

Der Unternehmer oder Bereichsleiter will Mehrwerte durch KI. Er will keine langen Planungsphasen oder Analyseschleifen. Also wird nach Use Cases gefragt.

Die Botschaft lautet oft: "Seid mutig, traut euch an ein großes Thema, ihr habt meinen Support." Grundsätzlich genau richtig. KI zur Chefsache zu machen, ist wichtig. Die Frage ist nur: Was sollte der Chef vorgeben, und was nicht?

In der Praxis passiert Folgendes: Der Unternehmer will Use Cases sehen. Seine Abteilungsleiter bekommen den Auftrag, diese zu identifizieren. Die fragen ihre Teamleiter, die Teamleiter fragen ihre Mitarbeiter. Die Mitarbeiter liefern eine Mischung aus dem, was sie in den Medien über KI gehört haben, und dem, was ihre persönlichen Probleme auf der Arbeit sind. Das wird in eine Liste geschrieben, priorisiert und nach oben durchgereicht.

Das Problem: Das sind oft nicht die Themen, die Chefsache sein sollten.

Das heißt ausdrücklich nicht, dass Ideen von Mitarbeitern schlecht sind. Im Gegenteil: Manchmal ist es genau das Fachwissen desjenigen, der einen Prozess täglich bearbeitet, das den entscheidenden Hebel sichtbar macht. Ein Manager, der diesen Prozess nur aus Berichten kennt, kann dieses Problem gar nicht sehen. Großartige KI-Initiativen sind genau so entstanden.

Das eigentliche Problem ist ein anderes: Wenn Bottom-up der einzige Mechanismus ist und das Ergebnis ungefiltert als strategische Prioritätenliste beim Chef landet, passieren zwei Dinge.

Erstens: Die Mehrheit der genannten Use Cases betrifft wiederkehrende Alltagsprobleme, für die keine Eigenentwicklung nötig ist. Microsoft Copilot, in Apps integrierte KI-Funktionen oder einfache Automationstools decken diese Fälle ab.

Zweitens: Die wirklich transformativen Themen, also diejenigen, die Prozesse grundlegend verändern und echte strategische Hebel darstellen, tauchen in solchen Listen selten auf. Kein einzelner Mitarbeiter hat den Auftrag oder die Perspektive, seinen eigenen Prozess infrage zu stellen.

Merke: Bottom-up allein liefert keine strategischen Prioritäten. Die Perlen gehen im Rauschen unter.

Ein konkretes Beispiel

Ein mittelständischer Fertiger mit 800 Mitarbeitern sammelt Use Cases über alle Abteilungen. Es kommen 53 Vorschläge zusammen. Die Geschäftsführung lässt priorisieren. Ergebnis: Die Top-10-Liste enthält Themen wie "KI-gestützte Zusammenfassung von Meeting-Protokollen", "automatische Kategorisierung von Eingangsrechnungen" und "Chatbot für interne IT-Fragen". Alles sinnvoll, alles lösbar mit Standardwerkzeugen, keines davon ein strategischer Hebel.

Was nicht auf der Liste steht: Der Qualitätssicherungsprozess, in dem 12 Mitarbeiter manuell Prüfprotokolle mit Produktionsdaten abgleichen. Fehler dort führen zu Reklamationen im sechsstelligen Bereich pro Jahr. Das Thema taucht nicht auf, weil die Mitarbeiter in der QS ihren Prozess als gegeben betrachten und niemand sie gefragt hat, ob der Prozess selbst das Problem ist.

Was wirklich Chefsache ist

Bei der aktuellen Geschwindigkeit in der Technologieentwicklung sind es nicht die konkreten Tools oder Anwendungen, die vorgegeben werden müssen. Es sind strategische Grundlagen, die es dem Unternehmen ermöglichen, KI-Systeme der Zukunft zu integrieren und davon zu profitieren.

1. Daten

Was immer noch massiv unterschätzt wird. Es wird zwar oft von Datenqualität gesprochen, aber kaum jemand definiert konkret, was das bedeutet: Welche Anforderungen gibt es an Zugriffsmöglichkeiten, an die Beschreibung der Daten, an das Zurückschreiben von Ergebnissen?

Die entscheidende Frage ist nicht nur, ob Daten vorhanden und sauber sind. Die entscheidende Frage ist: Können KI-Systeme sie lesen, schreiben und auf ihrer Basis Aktionen ausführen? Das betrifft IT-Systeme und Datenbanken genauso wie unstrukturierte Daten aus Dokumenten, E-Mails oder Protokollen.

Dazu kommt eine Dimension, die in der Datenqualitätsdiskussion fast nie auftaucht: der Mensch als Datenquelle. In den meisten mittelständischen Unternehmen steckt ein erheblicher Teil des operativen Wissens in Köpfen und informellen Prozessen. Der erfahrene Meister, der weiß, wie eine Maschine klingt, bevor sie ausfällt. Die Disponentin, die Lieferengpässe antizipiert, bevor sie im System sichtbar werden. Dieses implizite Wissen muss strukturiert und maschinenlesbar gemacht werden, bevor es mit den Menschen verschwindet, die es tragen. Für KI-Systeme, die eigenständig handeln sollen, ist das keine Kür, sondern Voraussetzung.

Es ist bereits absehbar, dass neben den klassischen Benutzeroberflächen für Menschen eine neue Art von Schnittstelle entsteht: Interfaces, die speziell für KI-Agenten gebaut sind. In der Praxis sind das heute Protokolle wie MCP-Server oder Kommandozeilen-Interfaces. Die Unternehmen, die ihre internen Systeme frühzeitig für diese Zugriffsart öffnen, schaffen die Grundlage dafür, dass KI-Agenten Prozesse nicht nur analysieren, sondern tatsächlich ausführen können.

2. Enablement

Der durchschnittliche Mitarbeiter und die durchschnittliche Führungskraft sind noch nicht ernsthaft für das KI-Zeitalter ausgebildet. Viele denken, sie verstehen KI, weil sie mit ChatGPT arbeiten. Aber der skalierbare Einsatz von KI im Unternehmen, das Neudenken von Prozessen und echte Produktivitätssprünge erfordern weitaus mehr Wissen und Erfahrung als der Umgang mit Chatbots.

Führungskräfte nehmen dabei eine gesonderte Rolle ein. Sie verantworten Prozesse und führen die Menschen, die in diesen Prozessen arbeiten. Ohne ihr Verständnis bleibt jede KI-Initiative oberflächlich. Führungskräfte müssen KI-Vorhaben realistisch einschätzen können: welche Probleme mit der aktuellen Technologie lösbar sind, welche Komplexität damit verbunden ist und wie Vorhaben angesichts der eigenen Daten, Strukturen und IT-Systeme umsetzbar sind. Ohne diese Urteilsfähigkeit werden der IT die falschen Themen herangetragen. Nicht aus mangelndem Willen, sondern aus fehlendem Überblick. Das Ergebnis: Ressourcen fließen in Vorhaben mit begrenztem Hebel, während die wirklich relevanten Potenziale unentdeckt bleiben.

Darüber hinaus fehlt in den meisten Unternehmen eine entscheidende Brückenfunktion: Personen, die Prozesse aus dem Fachbereich heraus kennen und gleichzeitig über KI-Kompetenz verfügen. Ohne diese Übersetzungsleistung bleibt die Lücke zwischen technischer Möglichkeit und operativem Bedarf bestehen. Diese Rolle muss bewusst geschaffen werden, ob intern aufgebaut oder extern besetzt.

3. Change Management

Enablement allein reicht nicht. Prozesse neu zu denken bedeutet, dass Menschen ihre Arbeitsweise ändern und teilweise ihre bisherige Relevanz infrage gestellt sehen. Das erzeugt Widerstand, der sich selten offen zeigt, aber Initiativen zuverlässig ausbremst.

Jeder Beteiligte, der einen Transformationsprozess anstößt, geht ein persönliches Risiko ein. Besonders dort, wo Initiativen über Abteilungsgrenzen hinausgehen und bestehende Zuständigkeiten in Bewegung bringen. Dieses Risiko wird nur eingegangen, wenn die Führungsebene unmissverständlich signalisiert: Veränderungsbereitschaft wird nicht nur erwartet, sondern aktiv unterstützt, sichtbar gemacht und anerkannt. Change Management bei KI-Transformationen ist deshalb nicht nur ein HR-Thema, sondern Chefsache.

4. Governance

Governance ist kein Hindernis, sondern Voraussetzung. Gerade in Europa, mit dem seit August 2024 in Kraft getretenen EU AI Act, kann ein glaubwürdiger, nachweisbarer Umgang mit KI-Sicherheit sogar zum Wettbewerbsvorteil werden, weil Kunden, Partner und Beschaffungsstellen zunehmend Vertrauen und Nachweisbarkeit einfordern.

Das Problem ist in der Praxis selten die Regulierung selbst, sondern ihre interne Ausgestaltung. In vielen Unternehmen durchläuft ein einfaches KI-Experiment dieselben Freigabewege wie eine vollständige Systemeinführung. Das verhindert die schnelle Iteration, die KI-Entwicklung braucht.

Was gebraucht wird, ist differenzierte Governance: volle Compliance im produktiven Betrieb, aber ein schlanker, regelkonformer Pfad für POC-Umgebungen. Mit klaren Leitplanken, definierten Datenklassen und dem Vertrauen in ausgebildete Teams, sauber zu arbeiten. Schnellere Entscheidungswege für Experimente sind keine Aufweichung von Governance. Sie sind die Voraussetzung dafür, dass überhaupt Erkenntnisse entstehen, auf deren Basis gute Entscheidungen getroffen werden können.

Grundlegende Infrastrukturentscheidungen wie die Wahl der Cloud-Plattform oder der Aufbau der Datenschicht sind bewusst langfristig angelegt, und das ist auch richtig so.

5. Technologie-Architektur

In vielen Unternehmen entsteht gerade ein Flickenteppich aus KI-Tools: hier eine Plattform für Prozessautomatisierung, dort ein spezialisiertes KI-Tool, dazu eine weitere Lösung für Dokumentenverarbeitung. Jedes für sich mag sinnvoll erscheinen. Aber in der Summe entsteht ein Architekturproblem, das sich mit der Zeit verschärft.

Ein häufiges Muster: Ein Unternehmen baut seine KI-gestützten Abläufe auf einer spezialisierten Plattform auf. Die Prozesslogik, die Verknüpfungen zu bestehenden Systemen und das Geschäftswissen werden in dieses Tool eingebaut. Wenn sich die zugrundeliegende KI-Technologie weiterentwickelt, kann die Plattform oft nicht mithalten. Ein Wechsel ist dann teuer, weil die gesamte Logik in diesem einen System steckt.

Von strategischer Bedeutung ist dabei, die Datenschicht und die Logik der einzelnen Anwendungsfälle sauber zu trennen. Wer das tut, behält die Flexibilität, einzelne Komponenten später auszutauschen, ohne die gesamte Architektur neu aufbauen zu müssen.

Klare Architekturvorgaben schaffen darüber hinaus Synergien, die über den einzelnen Use Case hinausgehen: wiederverwendbare Integrationsmuster, ein definierter Partnerkreis, der wiederholte Onboarding-Kosten vermeidet, und die Möglichkeit, erfolgreich implementierte Lösungen von einem Bereich oder Standort auf andere zu übertragen, ohne jedes Mal von vorne anzufangen. Ohne diesen Rahmen entsteht ein Flickenteppich, der mittelfristig mehr kostet als er spart.

Wie die großen Hebel identifiziert werden

Die Diagnose ist klar: Bottom-up allein liefert keine strategischen Prioritäten. Aber woher weiß der Geschäftsführer, welche Prozesse die wirklich großen Hebel sind?

Die Antwort: durch eine strukturierte Kombination beider Perspektiven.

Von oben kommt die Prozesslandkarte. Der Geschäftsführer und seine Bereichsleiter kennen die Wertschöpfungskette, die Kostenstrukturen und die strategischen Engpässe. Sie können benennen, welche Prozesse den größten Einfluss auf Marge, Qualität, Lieferfähigkeit oder Kundenzufriedenheit haben.

Von unten kommt das Detailwissen. Die Mitarbeiter, die täglich in diesen Prozessen arbeiten, kennen die realen Bruchstellen: Wo wird manuell nachgearbeitet? Wo gehen Informationen verloren? Wo wird Zeit in Abstimmungsschleifen verbrannt?

Die entscheidende Aufgabe ist, beides zusammenzubringen. Das erfordert jemanden, der sowohl die strategische Perspektive versteht als auch in der Lage ist, operative Prozesse auf ihr KI-Potenzial zu bewerten. In den meisten mittelständischen Unternehmen gibt es diese Rolle heute noch nicht.

Use Cases richtig einordnen

Chefsache ist, die großen Hebel zu identifizieren und deren Umsetzung aktiv zu unterstützen: relevante Geschäftsprozesse benennen, diese grundlegend neu denken und echte Transformationen durchführen.

Nicht Chefsache, aber trotzdem wichtig: die Alltagsverbesserungen, die aus Bottom-up-Analysen entstehen. Diese Use Cases gehören in die Verantwortung der IT oder eines zentralen KI-Teams, das Standardwerkzeuge evaluiert, bereitstellt und die Organisation befähigt, diese eigenständig zu nutzen.

Prozesse priorisieren: Personalbindung als Startpunkt

Personalkosten sind aktuell ein großes Thema. Der naheliegende Ansatz, zuerst die Prozesse mit der größten Personalbindung anzugehen, ist in vielen Fällen genau richtig.

Aber Personalbindung allein kann in die Irre führen. Ein Vertriebsteam mit 30 Mitarbeitern, das pro Kopf hohe Margen erwirtschaftet, ist kein Kostenproblem. Eine Abteilung mit 10 Mitarbeitern, die einen fehleranfälligen Qualitätsprozess manuell absichert, kann dagegen ein massiver Hebel sein, wenn Fehler zu Reklamationen, Ausschuss oder Lieferverzug führen.

Die stärkste Priorisierung entsteht, wenn beide Perspektiven zusammenkommen: Wo bindet ein Prozess viel Personal und beeinflusst gleichzeitig kritische Kennzahlen, dort liegen die größten Potenziale.

Piloten richtig aufsetzen: Hypothese, Abbruch, Skalierung

Viele Piloten scheitern nicht an der Technologie. Sie scheitern daran, dass Skalierbarkeit nie mitgedacht wurde. Ein Pilot ohne definierten Pfad in den produktiven Betrieb ist kein Erkenntnisgewinn, sondern verschwendetes Budget.

Was einen guten Piloten von einem teuren Experiment unterscheidet, sind drei Dinge: eine klare Hypothese, definierte Abbruchkriterien und ein Skalierungspfad, der vor dem Start steht und nicht erst als Nachgedanke entsteht.

Hypothesenbasiert bedeutet: Bevor Ressourcen fließen, wird formuliert, was genau geprüft werden soll und woran der Erfolg messbar ist. Nicht "Wir probieren mal KI im Einkauf", sondern "Wir prüfen, ob eine automatisierte Angebotsvorprüfung die Bearbeitungszeit pro Vorgang um mindestens 40 % reduziert, bei gleichbleibender Fehlerquote."

Die Abbruchkriterien gehören dazu. Sie verhindern, dass Piloten zum Dauerzustand werden, ein Muster, das überraschend häufig vorkommt. Go/No-Go-Entscheidungen müssen anhand der vorab definierten Kriterien getroffen werden, nicht auf Basis von bereits investiertem Geld. Die Sunk-Cost-Falle ist in KI-Projekten besonders tückisch, weil die Technologie komplex ist und es immer Gründe gibt, "noch einen Sprint" dranzuhängen.

Der Skalierungspfad klärt vor dem Start, was passiert, wenn der Pilot erfolgreich ist: Welche Systeme müssen angebunden werden? Welche Datenqualität muss gewährleistet sein? Wer übernimmt den produktiven Betrieb? Ohne diese Antworten kann ein Pilot seine Hypothese bestätigen und trotzdem nie in Produktion gehen.

Merke: Initiativen, die ihre Hypothesen nicht bestätigen, werden gestoppt. Initiativen, die sie bestätigen, werden skaliert. Beides erfordert Disziplin.

Erfolgsmessung: Woran KI-Initiativen gemessen werden müssen

Ein Business Case vor dem Start ist notwendig, aber nicht hinreichend. Ohne regelmäßige Überprüfung gegen vorab definierte Kriterien wird aus einem Piloten kein Ergebnis, sondern ein Dauerzustand.

Jede Initiative braucht klare Erfolgskriterien, die über reine Kosteneinsparungen hinausgehen. Produktivitätszuwachs, Fehlerreduktion, Durchlaufzeiten, Qualitätskennzahlen: je nach Prozess sind unterschiedliche Metriken relevant. Entscheidend ist: Diese Kriterien werden vor dem Start definiert und konsequent als Grundlage für Go/No-Go-Entscheidungen genutzt. Nicht im Nachhinein konstruiert, um bereits getätigte Investitionen zu rechtfertigen.

Das klingt selbstverständlich, ist es in der Praxis nicht. Erstaunlich viele KI-Projekte laufen ohne definiertes Ende und ohne klare Messung weiter. Die Gründe dafür sind menschlich nachvollziehbar: Die Technologie ist komplex, Teilerfolge gibt es immer, und niemand will das Projekt stoppen, in das bereits investiert wurde. Genau deshalb gehört Erfolgsmessung nicht in die Projektteams, sondern in die Führungsentscheidung.

Merke: Wer vor dem Start keine Erfolgskriterien definiert, kann hinterher nicht bewerten, ob sich die Investition gelohnt hat.

In welchen Zeiträumen denken?

Die strategischen Grundlagen (Daten, Enablement, Governance, Architektur) sind keine Projekte mit Enddatum, sondern laufende Aufgaben, die sofort beginnen sollten. Erste schnelle Erfolge über Standardwerkzeuge lassen sich in Wochen realisieren. Echte Prozesstransformationen brauchen typischerweise 6 bis 18 Monate, abhängig von der Komplexität des Prozesses und der Veränderungsbereitschaft der Organisation.

Der entscheidende Punkt: Die strategischen Grundlagen und die ersten Transformationsprojekte sollten parallel laufen, nicht nacheinander. Wer wartet, bis die Datenstrategie "fertig" ist, wird nie anfangen.

Was der Geschäftsführer morgen tun kann

Der Weg heraus ist kein Mammutprojekt. Er beginnt mit Klarheit darüber, was von oben kommen muss und was nicht.

Die Use-Case-Liste ist nicht das Problem. Das Problem ist, wenn sie der einzige Plan ist.