Warum KI-Pilotprojekte im Mittelstand versanden – und was die erfolgreichen anders machen

Fast jedes mittelständische Unternehmen hat inzwischen etwas mit künstlicher Intelligenz gemacht. Ein Workshop, ein Test mit einem Chatbot, eine Abteilung, die eine Lizenz bekommen hat. Auffällig ist, was danach passiert: oft nichts. Das Thema verschwindet aus den Führungsrunden, die Lizenz läuft weiter, genutzt wird sie von drei Leuten. Der Grund dafür ist fast nie die Technik. Er liegt in der Art, wie das Projekt aufgesetzt wurde.

Die fünf typischen Abbruchstellen

1. Das Pilotprojekt hatte kein Problem

Der häufigste Fehler ist der Start ohne konkreten Anlass. Man führt KI ein, „weil man da etwas machen muss“. Das Ergebnis ist ein Werkzeug, das zur Verfügung steht, aber keine Aufgabe hat. Mitarbeiter probieren es zwei Wochen aus, finden es beeindruckend und kehren dann zu ihrem gewohnten Weg zurück, weil der gewohnte Weg funktioniert.

Erfolgreiche Einführungen beginnen umgekehrt: mit einer Tätigkeit, die messbar Zeit kostet und die niemand gern macht. Die Angebotserstellung, die jedes Mal drei Stunden dauert, weil Textbausteine aus fünf alten Dokumenten zusammengesucht werden. Die Rechnungsprüfung, bei der jemand Positionen mit dem Bestellschein abgleicht. Der Bericht, der monatlich aus denselben Quellen entsteht. Wer mit einer solchen Aufgabe startet, kann nach vier Wochen sagen, ob sich etwas verändert hat.

2. Das Modell kannte das Unternehmen nicht

Ein allgemeines Sprachmodell weiß viel über die Welt und nichts über Ihr Unternehmen. Es kennt Ihre Preisliste nicht, Ihre Lieferbedingungen nicht, die Historie mit einem bestimmten Kunden nicht. Wer damit ein Angebot schreiben lässt, bekommt einen gut formulierten Text mit erfundenen Details.

Nutzer merken das sofort und ziehen daraus meistens den falschen Schluss: „KI erfindet Dinge, das können wir nicht gebrauchen.“ Richtig wäre: Dieses Modell hatte keinen Zugriff auf die Informationen, die es für die Aufgabe gebraucht hätte. Die technische Antwort darauf ist die Anbindung an die eigenen Dokumente und Daten. Erst dann arbeitet das System mit Ihrem Wissen statt mit einer plausiblen Vermutung.

3. Es gab keinen Verantwortlichen mit Zeit

KI-Projekte werden oft nebenbei betreut – von der IT, die schon ausgelastet ist, oder von einem interessierten Kollegen aus der Fachabteilung. Beide haben kein Mandat, Prozesse zu verändern. Genau das wäre aber die Aufgabe: Ein Werkzeug, das eine Tätigkeit von drei Stunden auf zwanzig Minuten verkürzt, verändert die Reihenfolge der Arbeitsschritte, die Zuständigkeiten und die Freigabewege.

Es braucht deshalb eine Person, die für die Einführung verantwortlich ist, dafür Zeit im Kalender hat und Entscheidungen treffen darf. In Unternehmen mit 30 bis 250 Mitarbeitern ist das oft ein Teamleiter aus dem Bereich, in dem der erste Anwendungsfall liegt – nicht die IT.

4. Die Rechtsfragen kamen zu spät

Ein Pilot läuft, die Ergebnisse überzeugen, und dann fragt jemand: Dürfen wir hier eigentlich Bewerberdaten hineingeben? Was ist mit dem Betriebsrat? Wo liegen die Daten? An dieser Stelle stoppen viele Projekte für Monate – nicht weil die Antworten schwierig wären, sondern weil sie niemand vorbereitet hat.

Diese Fragen sind beantwortbar, und sie sind schneller beantwortet, wenn man sie am Anfang stellt. Wer Hosting-Standort, Auftragsverarbeitungsvertrag, Umgang mit personenbezogenen Daten und die Beteiligung der Mitarbeitervertretung vor dem ersten Test klärt, verliert später keine Zeit.

5. Niemand hat den Umgang gelernt

Der Umgang mit einem Sprachmodell ist eine Fähigkeit. Wer nur schreibt „Erstelle mir ein Angebot“, bekommt ein mittelmäßiges Ergebnis und schließt daraus, das Werkzeug tauge nichts. Wer gelernt hat, Kontext mitzugeben, Zwischenergebnisse zu prüfen und in Schritten zu arbeiten, kommt zu brauchbaren Resultaten.

Diese Fähigkeit entsteht nicht von allein. Zwei Stunden Einführung mit den echten Aufgaben des Teams bringen mehr als jede allgemeine Schulung – und sie sind seit Februar 2025 auch rechtlich relevant: Artikel 4 des EU AI Act verpflichtet Unternehmen, für ausreichende KI-Kompetenz der Personen zu sorgen, die solche Systeme in ihrem Auftrag einsetzen.

Was die erfolgreichen Einführungen gemeinsam haben

Wenn man Projekte vergleicht, die nach einem Jahr noch laufen, fallen vier Muster auf.

Sie haben klein angefangen, aber tief. Nicht fünf Abteilungen gleichzeitig oberflächlich, sondern eine Abteilung richtig. Ein Anwendungsfall, der vollständig durchdacht ist – inklusive der Frage, was mit dem Ergebnis passiert, wer es prüft und wo es abgelegt wird.

Sie haben das System an die vorhandenen Daten angebunden. Dokumente in SharePoint, Ablagen auf dem Fileserver, E-Mails, das ERP. Der Unterschied zwischen „KI, die allgemein antwortet“ und „KI, die unsere Unterlagen kennt“ ist der Unterschied zwischen Spielzeug und Werkzeug.

Sie haben Berechtigungen ernst genommen. Ein Assistent, der auf Unternehmensdaten zugreift, darf einem Mitarbeiter nur zeigen, was dieser Mitarbeiter ohnehin sehen darf. Das klingt selbstverständlich, ist aber der Punkt, an dem viele Eigenbauten scheitern.

Sie haben den Nutzen sichtbar gemacht. Nicht als Prozentzahl in einer Präsentation, sondern konkret: Die Angebotserstellung dauert jetzt eine statt drei Stunden. Die Ausschreibungsbeantwortung ist an einem Tag statt in einer Woche fertig. Solche Sätze überzeugen die nächste Abteilung, Präsentationen tun das nicht.

Ein Vorgehen, das funktioniert

Aus diesen Beobachtungen lässt sich ein einfacher Ablauf ableiten, der sich in mittelständischen Strukturen bewährt hat.

Woche 1 bis 2 – Auswahl. Sammeln Sie mit drei bis fünf Führungskräften Tätigkeiten, die viel Zeit kosten, häufig vorkommen und stark auf Text und Dokumenten beruhen. Bewerten Sie diese nach Aufwand und Wirkung. Wählen Sie genau eine aus.

Woche 3 bis 4 – Rahmen klären. Welche Daten werden gebraucht? Wo liegen sie? Sind personenbezogene Daten dabei? Wer muss beteiligt werden? Welche Berechtigungen gelten? Das Ergebnis ist eine Seite, kein Konzeptpapier.

Woche 5 bis 8 – Aufbau und Test mit echten Fällen. Nicht mit Beispieldaten, sondern mit den Vorgängen der letzten Wochen. Nur so zeigt sich, ob das System die Sonderfälle beherrscht, die in jedem Unternehmen die Mehrheit ausmachen.

Woche 9 bis 12 – Einführung im Team und Messung. Alle Beteiligten arbeiten damit, es gibt eine feste Ansprechperson für Rückfragen, und nach vier Wochen wird ausgewertet, ob sich die Bearbeitungszeit verändert hat.

Nach diesen zwölf Wochen wissen Sie, ob der Fall trägt. Wenn ja, ist der nächste einfacher, weil Anbindung, Rechtevergabe und Betriebsmodell bereits stehen. Wenn nein, haben Sie ein Quartal investiert und nicht ein Jahr.

Die Frage, die am Anfang steht

Bevor Sie über Modelle, Anbieter und Lizenzen nachdenken, beantworten Sie eine Frage: Welche Tätigkeit in Ihrem Unternehmen kostet regelmäßig Zeit, beruht auf vorhandenen Informationen und ärgert die Beteiligten? Diese Tätigkeit ist Ihr erster Anwendungsfall. Alles andere folgt daraus.

Wenn Sie dabei einen Blick von außen möchten: Wir schauen uns solche Abläufe im Erstgespräch gemeinsam an und sagen Ihnen ehrlich, ob sich der Einsatz von KI an dieser Stelle lohnt – oder ob eine einfachere Lösung schneller ans Ziel führt.

Drei Muster, an denen man ein gefährdetes Projekt früh erkennt

Es gibt Warnzeichen, die lange vor dem eigentlichen Abbruch sichtbar sind. Wer sie kennt, kann gegensteuern, solange es noch billig ist.

Das Projekt hat keinen Termin, an dem entschieden wird. Solange niemand sagt, wann bewertet wird und woran, läuft ein Vorhaben ohne Bremse und ohne Gas. Es endet nicht mit einer Entscheidung, sondern mit Desinteresse. Setzen Sie deshalb von Anfang an einen festen Termin, an dem über Ausweiten, Nachbessern oder Beenden entschieden wird.

Die Begeisterung liegt bei denen, die nicht damit arbeiten. Wenn Geschäftsführung und IT überzeugt sind, die Fachabteilung aber höflich schweigt, fehlt die Grundlage. Der Nutzen muss dort spürbar sein, wo die Arbeit anfällt, sonst entsteht keine Nutzung.

Es wird über Werkzeuge gesprochen, nicht über Vorgänge. Sobald sich Diskussionen um Anbieter, Modelle und Funktionen drehen, ohne dass ein konkreter Ablauf genannt wird, ist die Reihenfolge verrutscht. Die Rückkehr zur Frage „Welche Tätigkeit soll besser werden?“ ist dann die wirksamste Kurskorrektur.

Was Sie messen sollten – und was nicht

Der häufigste Messfehler ist die Nutzungsquote. Sie lässt sich leicht erheben, sagt aber wenig aus und verleitet dazu, Nutzung zu erzwingen. Aussagekräftiger sind drei andere Größen.

• Durchlaufzeit des Vorgangs. Vom Eingang bis zum Abschluss, gemessen vor dem Start und drei Monate danach.
• Anzahl der Rückfragen. Ein guter Indikator dafür, ob Ergebnisse tatsächlich brauchbar sind.
• Freiwillige Weiternutzung. Würden die Beteiligten es vermissen, wenn man es ihnen wieder wegnähme? Diese Frage lässt sich in zwei Minuten stellen und ist ehrlicher als jede Statistik.

Häufige Fragen

Wir haben schon ein gescheitertes Projekt hinter uns. Wie fangen wir noch einmal an?

Benennen Sie offen, woran es lag – meist ist es einer der fünf Punkte oben. Wählen Sie dann bewusst einen kleineren, klar abgegrenzten Fall und setzen Sie einen Entscheidungstermin. Ein zweiter Anlauf mit engem Zuschnitt und sichtbarem Ergebnis stellt Vertrauen schneller wieder her als eine große Neuauflage.

Sollte die IT oder die Fachabteilung führen?

Die Fachabteilung führt, die IT begleitet. Der Grund ist einfach: Die zu treffenden Entscheidungen sind fachlich – welcher Vorgang, welche Dokumente gelten, wer prüft was. Die IT liefert Anbindung, Rechte und Betrieb.

Wie groß darf der erste Anwendungsfall sein?

So klein, dass er in zwölf Wochen vollständig durchlaufen werden kann, und so groß, dass sein Wegfall auffiele. Ein Vorgang, der ein- bis mehrmals täglich vorkommt und heute spürbar Zeit kostet, trifft diese Beschreibung meistens.

Was, wenn die Dokumentenlage schlecht ist?

Das ist der Normalfall, kein Ausschlusskriterium. Räumen Sie nicht alles auf, sondern nur den Bereich, den der erste Fall braucht. Die Erfahrung aus diesem Aufräumen ist zugleich die beste Grundlage für die Entscheidung, wo es sich als Nächstes lohnt.

Ein durchgerechnetes Beispiel

Wie der Ablauf konkret aussieht, lässt sich an einem typischen Fall zeigen. Nehmen wir einen technischen Dienstleister mit rund achtzig Mitarbeitern, der Angebote weitgehend aus früheren Angeboten zusammensetzt. Die Zahlen sind Platzhalter – das Muster ist übertragbar.

Woche 1 bis 2. In der Runde mit drei Führungskräften kommen fünf Kandidaten auf den Tisch: Angebotserstellung, Rechnungsprüfung, Serviceberichte, Bewerbermanagement, interne Auskünfte. Bewerbet wird nach Häufigkeit und mechanischem Anteil. Bewerbermanagement fliegt sofort raus – Hochrisikobereich, kein Einstiegsfall. Die Angebotserstellung gewinnt: vierzig Vorgänge im Monat, hoher Textanteil, klare Unzufriedenheit im Team.

Woche 3 bis 4. Die Datenquellen sind schnell benannt: Angebotsarchiv auf SharePoint, Preisliste im ERP, Referenztexte in einem Marketingordner. Personenbezug gering. Der Betriebsrat wird informiert, weil protokolliert wird. Parallel entsteht die Testliste: fünfundzwanzig echte Anfragen der letzten Monate, samt der Angebote, die daraus wurden.

Woche 5 bis 6. Beim Sichten des Angebotsarchivs zeigt sich das übliche Bild: drei Preislisten ohne erkennbares Gültigkeitsdatum, Ordner mit Direktberechtigungen für längst gewechselte Kollegen, Entwürfe neben Endfassungen. Das Aufräumen kostet zwei Wochen – und wird von allen als überfällig empfunden.

Woche 7 bis 9. Der Test mit den fünfundzwanzig Fällen läuft zunächst enttäuschend: Acht Antworten sind unbrauchbar. Die Auswertung zeigt, dass sechs davon auf fehlende oder veraltete Dokumente zurückgehen und nur zwei auf schwache Antworten. Nach dem Nachziehen liegt die Quote bei zweiundzwanzig von fünfundzwanzig.

Woche 10 bis 11. Vier Personen im Vertriebsinnendienst arbeiten damit. Zwei Stunden Einweisung an echten Anfragen, acht Vorlagen für die häufigsten Fälle, eine benannte Ansprechperson.

Woche 12 bis 13. Die Bearbeitungszeit je Angebot ist von rund drei auf knapp zwei Stunden gesunken – weniger als erhofft, aber belastbar gemessen. Auffälliger ist etwas anderes: Zwei Ausschreibungen, die im Vorjahr aus Zeitmangel abgesagt worden wären, wurden bearbeitet.

Die Entscheidung fällt auf Ausweiten. Der zweite Fall – Serviceberichte – startet in Woche 17 und ist in acht statt dreizehn Wochen produktiv, weil Anbindung, Rechtelogik und Betriebsmodell bereits stehen.

Woran man in diesem Beispiel den Unterschied sieht

Drei Details in diesem Ablauf sind es, die über Erfolg entscheiden, und alle drei wirken unspektakulär.

Der Fall wurde nach Häufigkeit gewählt, nicht nach Begeisterung. Vierzig Vorgänge im Monat erzeugen Routine; zwölf im Jahr erzeugen keine.

Die enttäuschende erste Testrunde führte nicht zum Abbruch, sondern zur Ursachenanalyse. Hätte man nach acht Fehlschlägen aufgegeben, wäre das Urteil „funktioniert nicht“ gewesen – obwohl das Problem in der eigenen Ablage lag.

Die Ausgangswerte wurden vorher erhoben. Ohne die gemessenen drei Stunden hätte am Ende jeder ein anderes Gefühl gehabt, und die Diskussion wäre nicht zu entscheiden gewesen.