KI-Projekte scheitern früh und leise

Das Unangenehme an einer Projektobduktion ist, wie banal die Ursache meistens ist. Man geht hinein und erwartet ein hartes technisches Problem: eine Suche, die nicht sauber rankt, ein Modell, das die Fachsprache nicht hält, Antwortzeiten, die niemand in den Griff bekommt. Was man findet, ist eine Zuschnitts-Entscheidung aus Woche eins, getroffen in vierzig Minuten von drei Personen, die noch nie neben demjenigen gesessen haben, der die Arbeit tatsächlich macht. Die Technik hat geliefert, was man von ihr verlangt hat. Gescheitert ist das Projekt trotzdem.

Genau das macht das Scheitern teuer und nicht bloß ärgerlich. Ein Projekt, das technisch scheitert, scheitert laut: Es funktioniert nicht, Sie merken es in Woche drei, Sie hören auf, Sie haben drei Wochen verloren. Ein Projekt, das an einer Entscheidung aus Woche eins scheitert, scheitert überhaupt nicht laut. Es liefert eine Demo, die die Geschäftsführung beeindruckt, einen Bau, der seine Termine hält, alle zwei Wochen einen Statusbericht — alles echte, sauber gemachte Arbeit, nur auf das falsche Ziel gerichtet. Sie merken es zum Go-live, nachdem Sie alles bezahlt haben.

Die nützlichere Frage ist deshalb nicht „Warum scheitern KI-Projekte?“, sondern „Warum dauert es sechs Monate, bis es jemand merkt?“. Die Antwort: Jedes Symptom des echten Scheiterns sieht bis zuletzt exakt wie ein gesundes Projekt aus.

Woche 1 Zuschnitt im Meeting Woche 6 Demo beeindruckt Monat 3 Bau hält die Termine Monat 6 Go-live, still beerdigt scheitert hier fällt hier auf fünf Monate, in denen alles nach Fortschritt aussieht
Der Abstand zwischen der Stelle, an der ein KI-Projekt scheitert, und der Stelle, an der es jemand merkt. Nichts dazwischen ist ein Warnsignal — das ist das Problem.

Die Fehler, die nach Fortschritt aussehen

Das sind die Muster, über die ich immer wieder stolpere. Keines hat mit der Modellauswahl zu tun, und jedes ist angelegt, bevor die erste Zeile Code entsteht.

Sie haben den Teil automatisiert, der ohnehin billig war

Nehmen wir einen Zulieferer, dessen Vertriebsinnendienst eingehende Bestellungen als PDF und E-Mail-Text bearbeitet. Das naheliegende Projekt: Felder auslesen, ins ERP schieben, den Sachbearbeitern Zeit zurückgeben. Der Pilot funktioniert — Auslesequote im hohen Neunzigerbereich bei sauberen Bestellungen — und alle nennen ihn einen Erfolg.

Dann geht er live und spart fast nichts. Der Grund lag in Zahlen, die niemand gezählt hat. Sagen wir 200 Bestellungen pro Woche. Vielleicht 140 davon waren ohnehin sauber: Der Sachbearbeiter hat draufgeschaut und sie in unter zwei Minuten erfasst. Macht keine vier Stunden pro Woche. Die anderen 60 waren die eigentliche Arbeit — eine ausgelaufene Artikelnummer, eine Menge, die dem Rahmenvertrag widerspricht, ein Liefertermin, den die Fertigung unmöglich hält, ein Kunde, der „wie immer“ ins Bemerkungsfeld schreibt. Fünfzehn Minuten pro Stück, und jemand, der diesen Kunden kennt. Macht fünfzehn Stunden pro Woche.

Automatisiert wurden die vier Stunden.

Die Arbeit, die Sie beschreiben können, war ohnehin die billige. Routinefälle gehen schnell, weil sie Routine sind — und dieselbe Eigenschaft macht sie leicht automatisierbar. Die Stunden stecken in den Ausnahmen, und die Ausnahmen sind der schwere Teil. Zählen Sie nach, wohin die Zeit tatsächlich fließt, bevor Sie irgendetwas zuschneiden.

Es gibt hier einen Folgeeffekt, der die meisten überrascht, und er erklärt, warum solche Projekte still beerdigt statt bloß mittelmäßig werden: Automatisierung verdichtet die Schwierigkeit. Der Sachbearbeiter hatte vorher eine Mischung, und eine Serie einfacher Bestellungen war die Verschnaufpause zwischen den harten. Jetzt sind die einfachen weg, und der Tag besteht nur noch aus Ausnahmen, am Stück, bei gleicher Besetzung und gleicher Arbeitszeit. Anstrengendere Arbeit — und ein System, dem man die Schuld geben kann. So bekommen Sie ein technisch erfolgreiches Projekt, das die Abteilung binnen eines Quartals nicht mehr benutzt.

Die ehrliche Fassung dieses Projekts ist entweder deutlich kleiner — vier Stunden pro Woche sind vier Stunden pro Woche, nehmen Sie sie mit und nennen Sie es keine Transformation — oder deutlich schwerer: auf die Ausnahmen zielen, was heißt, dass das System den Rahmenvertrag, die Eigenheiten des Kunden und den Fertigungskalender kennen muss. Das ist ein echtes Projekt, womöglich ein gutes. Es ist nur nicht das Projekt, das in Woche eins zugeschnitten wurde.

Es gibt einen Auftraggeber, aber keinen Eigentümer

Fast jedes steckengebliebene Projekt hat einen Auftraggeber: den Geschäftsführer, der etwas Überzeugendes gelesen hat, oder den IT-Leiter, dem gesagt wurde, er solle etwas mit KI machen. Was fehlt, ist ein Eigentümer — jemand, dessen eigene Zahlen besser werden, wenn das hier funktioniert, und der deshalb dafür kämpft, wenn es zu achtzig Prozent fertig und immer noch lästig ist.

Diese Lücke hat im Mittelstand eine sehr bestimmte Form. Die Geschäftsführung will es. Die IT baut oder kauft es. Der Vertriebsinnendienst oder die Serviceleitung — also die Leute, deren Prozess sich tatsächlich ändert — erfahren davon, wenn es zum Testen bereitsteht. Sie haben nicht darum gebeten, es gehört ihnen nicht, und sie sind diejenigen, die die Umstellung auffangen. Also sabotieren sie es nicht. Es passiert etwas Schlimmeres: Sie sind ausgesprochen höflich damit, benutzen es, wenn jemand zuschaut, und es stirbt an Gleichgültigkeit. Es gibt nie eine Sitzung, in der es abgebrochen wird. Es wird nur irgendwann nicht mehr erwähnt.

Ein KI-Projekt ist eine Prozessänderung mit angehängter Software. Wenn niemand, dem der Prozess gehört, auch das Projekt besitzt, haben Sie Software für eine Änderung gekauft, die ohnehin nicht stattgefunden hätte.

Das Modell funktioniert, und niemand hat entschieden, was passiert, wenn nicht

Nehmen wir einen Regionalversicherer, der eingehende Post klassifiziert und weiterleitet: Schäden, Vertragsänderungen, Beschwerden. Der Pilot landet bei 85 % Trefferquote, alle sind sich einig, dass das die Aushilfe vom August schlägt, und er geht in Betrieb.

Die Frage, die die Demo nie gestellt hat: Was passiert mit den anderen 15 %? Eine falsch geroutete Beschwerde meldet sich nicht von selbst. Sie liegt drei Wochen in der falschen Warteschlange und kommt als verärgerter Anruf zurück — oder als versäumte Frist. Der manuelle Prozess war nicht treffsicherer. Aber er hatte etwas, das dem Modell fehlt: einen Menschen, der sich unsicher fühlte und den seltsamen Umschlag zu jemand anderem hinübertrug.

Das ist der Teil, den man mitnehmen sollte. Überall dort, wo ein Mensch in der Nähe der Schleife sitzt, gilt: Ein System, das weiß, wann es etwas nicht weiß, ist mehr wert als ein System, das schlicht treffsicherer ist. Ein Klassifikator, der 80 % sicher zuordnet und 20 % in eine Prüfliste legt, ist das bessere Produktivsystem als einer, der 100 % zuordnet und dabei zu 85 % richtig liegt — denn die Fehler des ersten sind eingehegt, die des zweiten laufen frei durch Ihren Prozess und werden dabei älter. Treffsicherheit zeigt man in der Demo. Betreiben muss man Kalibrierung.

Die Daten waren da. Reingeschaut hat niemand.

Der klassische Datenfehler sind nicht schmutzige Daten oder zu wenige davon. Die sind wenigstens sichtbar, und sie sind das Thema von Daten für KI vorbereiten. Der Fehler, der Projekte umbringt, ist subtiler: Die Daten existieren, also nimmt jeder an, sie seien brauchbar — und niemand schaut hinein, bis Monat drei angebrochen ist.

Sagen wir, ein Maschinenbauer möchte vorhersagen, welcher Serviceeinsatz welches Ersatzteil braucht. Im ERP hängt an jedem Serviceauftrag ein Feld Fehlerursache, neun Jahre zurück, Zehntausende Zeilen. Das sieht nach einem Datensatz aus.

Dann öffnet man es. Sechzig Prozent der Zeilen sagen „Sonstiges“, weil das der erste Eintrag im Dropdown ist und der Monteur das Formular um halb sieben auf dem Handy auf einem Parkplatz ausfüllt. Ein guter Teil des Rests ist Freitext in einer Kurzschrift, die zwei langgediente Monteure lesen können und sonst niemand. Die eigentliche Diagnose stand nie in diesem Feld. Sie war im Kopf des Monteurs, vielleicht noch auf dem Durchschlag.

Das Feld war dafür gebaut, den Serviceauftrag zu schließen, nicht ihn zu beschreiben. Daten, die zum Abschließen eines Prozesses erhoben wurden, beschreiben den Prozess nicht — und praktisch jeder interne Datenbestand in einem mittelständischen Unternehmen wurde erhoben, um irgendetwas abzuschließen. Das zu prüfen kostet in Woche eins einen Nachmittag; es in Monat drei zu entdecken kostet das halbe Budget. Öffnen Sie die Tabelle. Schauen Sie sich die Werte an. Zählen Sie die verschiedenen.

Wie Sie das alles in Woche eins erkennen

Jeder Fehler oben ist billig zu erkennen und teuer zu entdecken. Für das Erkennen brauchen Sie keinen Data Scientist und kein Architekturdiagramm, sondern fünf Fragen — von denen keine einzige von KI handelt:

  • Wer macht diese Arbeit heute, und darf ich einen Tag danebensitzen?
  • Nehmen Sie die letzten 200 Fälle: Wie lange hat jeder gedauert? Stecken die Stunden in den Routinefällen oder in den unbequemen?
  • Wessen Zahlen werden besser, wenn das funktioniert — und weiß diese Person, dass es das Projekt gibt?
  • Wenn das System falsch liegt: Wer merkt es, wie lange dauert das, und was kostet der Fehler?
  • Zeigen Sie mir das Feld, aus dem das Modell lernen soll. Nicht das Schema. Die Werte.

Wenn Sie darauf keine geraden Antworten bekommen, ist das die Antwort — und sie ist mehr wert als ein weiterer Workshop. Das ist auch der Unterschied zwischen einem Piloten, der ein Urteil liefert, und einem, der eine Demo liefert; wie Sie zu einem echten Go/No-Go kommen, steht in Ein KI-Pilotprojekt richtig aufsetzen.

Was ich nicht mache. Ich übernehme kein Projekt, bei dem ich nicht direkt mit der Person gesprochen habe, die die Arbeit heute erledigt. Nicht aus Prinzip, sondern aus einem praktischen Grund: Jedes Muster auf dieser Seite ist von der Führungsebene aus unsichtbar und vom Schreibtisch aus offensichtlich. Das Zählen der Ausnahmen, das „Sonstiges“-Problem, der fehlende Eigentümer. In einem Lastenheft finden Sie nichts davon — denn geschrieben hat es jemand, dem der Prozess erzählt wurde, nicht jemand, der ihn macht.

Wovor Sie das nicht schützt

Zwei ehrliche Einschränkungen, denn eine Checkliste, die jedes Scheitern verhindern will, ist auch nur eine andere Form von Verkaufsversprechen.

Erstens rettet Sie nichts davon vor einem wirklich harten technischen Problem. Manches ist schlicht nicht so weit, und kein noch so guter Zuschnitt ändert daran etwas — verlässliches Auslesen aus handschriftlich ergänzten Werkstattzeichnungen aus den Achtzigern verbrennt Ihr Budget, so sorgfältig Sie es auch aufsetzen. Das ist eine eigene Einschätzung, und dafür holt man sich einen Engineer statt eines Workshops.

Zweitens sind diese Fehler nicht gleich tödlich. Ein fehlender Eigentümer lässt sich mitten im Projekt heilen, wenn die Geschäftsführung tatsächlich abgeben will und es nicht nur sagt. Fehlende Wahrheitsdaten lassen sich manchmal heilen, indem man ab jetzt sauber erfasst und nächstes Jahr baut. Das Ausnahmeproblem lässt sich meist nicht heilen: Wenn die Stunden im langen Ende liegen und das Projekt auf den Kopf zielt, rettet keine noch so gute Technik die Rechnung. Das muss vor dem Start auffallen — genau deshalb ist ein Nachmittag Zählen die Arbeit mit der höchsten Rendite im ganzen Projekt. Das ist übrigens eine andere Frage als die nach dem Preis (Was kostet ein KI-Projekt wirklich?): Ein gut gezieltes Projekt kann trotzdem teuer sein — und ein günstiges, das ins Leere zielt, ist trotzdem verschwendet.

Wo Tippel ins Spiel kommt

Nichts davon spricht gegen KI-Projekte. Es spricht dafür, die erste Woche mit Fragen zu verbringen statt mit Architektur — und bereit zu sein, ein Nein zu hören.

Genau das ist der KI-Readiness-Check: ein bezahltes, zeitlich begrenztes Fenster von ein bis zwei Wochen, in dem diese Fragen gegen Ihren echten Prozess und Ihre echten Daten laufen und das mit einem ehrlichen Go/No-Go endet statt mit einem Angebot. Manchmal ist das nützliche Ergebnis: „Nicht dieser Anwendungsfall — die Stunden liegen in dem daneben.“ Diese Antwort kostet einen Bruchteil dessen, was es kostet, sie in Monat sechs zu bekommen, und die Gebühr wird bei Beauftragung angerechnet. Wenn Sie es lieber erst besprechen möchten, nehmen Sie Kontakt auf.