Niemand verkündet das Scheitern. Der Pilot läuft, die Demo geht gut, ein Bericht wird geschrieben — und das Projekt hört still auf, erwähnt zu werden. Zwölf Monate später ist das Budget woanders, und niemand kann genau sagen, was passiert ist.
Dieses Muster wiederholt sich in genug Organisationen, um es ernst zu nehmen — und die Ursachen sind konsistent genug, um vermeidbar zu sein.
Die Projekte starten am falschen Ende
Der häufigste Fehler ist strukturell und passiert, bevor Code geschrieben wird: Das Projekt startet bei der Technologie statt beim Problem.
Jemand sieht eine Fähigkeit, stellt sich eine Anwendung vor und beauftragt einen Piloten. Der Pilot ist technisch erfolgreich — das Modell tut das Ding — und dann findet niemand heraus, wie man ihn in Produktion bringt, weil er nie an einen Prozess gebunden war, den jemand besitzt, oder an Kosten, die jemand senken wollte.
Die Umkehrung funktioniert. Beginnen Sie mit einem konkreten, teuren, repetitiven Prozess. Stellen Sie fest, was er heute in Stunden und Fehlern kostet. Fragen Sie dann, ob diese Technologie die Zahl senkt. So gerahmte Projekte überleben tendenziell — weil es eine Person gibt, deren Job besser wird, und eine Zahl, die sich bewegt.
Ein unverblümter Test: Können Sie nicht benennen, wer es täglich nutzen wird und was diese Person heute stattdessen tut, ist das Projekt eine Demo mit Budget.
Pilot-Erfolg ist kein Beleg
Der zweite Fehler ist, einen guten Piloten mit einem funktionierenden System zu verwechseln.
Piloten laufen auf kuratierten Daten, mit der Aufmerksamkeit des Teams, auf Fällen, die jemand ausgewählt hat. Produktion läuft auf allem, was eintrifft — unbeaufsichtigt, inklusive des Missgebildeten, des Mehrdeutigen und des aktiv Feindseligen. In der Lücke dazwischen sterben die meisten Projekte — und es ist keine Modellierungslücke.
Ein nützliches Pilot-Design ist absichtlich unschmeichelhaft: auf einer Zufallsstichprobe echter Eingaben laufen lassen, inklusive der unordentlichen, unbeaufsichtigt — und messen, wie oft ein Mensch gebraucht wird. Diese Zahl sind Ihre tatsächlichen Betriebskosten, und sie ist meist höher, als die Demo nahelegte.
Abb. — Ein Pilot, der nicht scheitern kann, misst nichts.
Die Kosten, die nach der Demo erscheinen
Business Cases zählen routinemässig Modell- oder Lizenzkosten und hören dort auf. Die Kosten, die sich wirklich ansammeln:
Integration. Die Anbindung an echte Systeme, mit echter Authentifizierung und echter Fehlerbehandlung, ist meist der grösste Posten — und selten der geschätzte.
Datenaufbereitung. Fast jedes Projekt entdeckt, dass seine Daten schlechter sind als angenommen — dupliziert, inkonsistent, ohne das Feld, von dem der ganze Ansatz abhing. Das ist kein Umweg; für viele Projekte ist es der Grossteil der Arbeit.
Menschliche Prüfung. Alles mit Konsequenzen braucht jemanden, der einen Anteil der Ausgaben kontrolliert. Das ist eine dauerhafte Rolle, keine Launch-Aufgabe — und der Posten, der am ehesten ganz fehlt.
Wartung. Eingaben driften, vorgelagerte Systeme ändern sich, Modelle werden abgekündigt. Ein produktives System braucht jemanden, dem es gehört — und der Tag, an dem das niemand mehr tut, ist der Tag, an dem es still zu degradieren beginnt.
Die Projekte, die sich auszahlen, sind tendenziell die, in denen diese Posten ehrlich bepreist wurden — und die Antwort trotzdem Ja war.
Die Akzeptanz entscheidet über den Wert
Ein technisch exzellentes System, um das Menschen herumarbeiten, bringt nichts zurück — und das ist häufiger als technisches Versagen.
Die Muster sind vorhersehbar. Die Belegschaft wurde nicht einbezogen und vermutet eine Bedrohung ihrer Jobs. Das Werkzeug fügt einen Schritt hinzu, statt einen zu entfernen. Niemand hat erklärt, worin es schlecht ist — also zerstört der erste selbstbewusste Fehler das Vertrauen dauerhaft. Es gibt keinen offensichtlichen Weg, es zu korrigieren, wenn es falsch liegt — also hören die Leute auf, es zu versuchen.
Der Fix ist unglamourös: die Menschen, die die Arbeit tun, beim Entwerfen einbeziehen; konkret über Grenzen sprechen; Korrektur zu einem Klick machen; und Akzeptanz messen statt annehmen. Eine wöchentliche Zahl, wie oft das Werkzeug genutzt versus umgangen wird, sagt mehr als jede Genauigkeitsmetrik.
Bauen, kaufen oder warten
Eine leisere Ursache verschwendeten Budgets: etwas bauen, das sechs Monate später in einem Produkt ankam.
Die Fähigkeitslandschaft bewegt sich schnell genug, dass ein Eigenbau für ein allgemeines Problem — Dokumente zusammenfassen, Antworten entwerfen, Tickets klassifizieren — oft von einem Feature in Software überholt wird, die Sie bereits bezahlen. Teams, die zwei Quartale hineingesteckt haben, pflegen am Ende eine schlechtere Version von etwas, das jetzt in ihrer Lizenz enthalten ist.
Die Unterscheidung, die sich lohnt: Bauen, wo der Wert aus Ihren eigenen Daten, Ihrem eigenen Prozess oder Ihrem eigenen Fachwissen kommt. Kaufen, wo das Problem allgemein ist. Warten, wo das Problem allgemein ist und es noch niemand gut ausgeliefert hat — denn das wird jemand.
Diese letzte Option ist legitim und wird selten gewählt, weil «wir haben entschieden, das noch nicht zu bauen» eine schlechte Folie abgibt. Sie ist häufig die renditestärkste verfügbare Entscheidung.
Was die Erfolgreichen gemeinsam haben
Sie sind enger als erwartet. Ein Prozess, ein Team, eine klare Definition von fertig. Breite Transformationsprogramme haben eine deutlich schlechtere Bilanz als langweilige Abteilungsautomatisierungen.
Sie haben einen benannten Owner mit der Befugnis, den Prozess zu ändern — nicht nur die Software. Der Grossteil des Werts beim Automatisieren eines Ablaufs kommt aus seiner Neugestaltung, und die braucht jemanden, der darf.
Sie messen gegen eine Basislinie, die vor dem Projekt existierte. Teams, die nicht festgehalten haben, was der Prozess vorher kostete, können hinterher keine Verbesserung nachweisen — und so werden auch erfolgreiche Projekte gestrichen.
Und sie behandeln die erste Version als bewusst begrenzt — unterstützend statt entscheidend, mit einem Menschen in der Schleife — und weiten die Autonomie aus, wenn sich Belege ansammeln. Die, die voll autonom starteten, ruderten fast alle nach einem Vorfall zurück — zu einem Glaubwürdigkeitspreis, der die technische Korrektur überdauerte.
Die unbequeme Frage, die sich früh lohnt
Bevor Budget fliesst: Wenn das exakt wie beabsichtigt funktioniert — was ändert sich konkret?
Ist die Antwort eine Zahl — gesparte Stunden, vermiedene Fehler, eine geleerte Warteschlange, Umsatz, der heute versickert —, haben Sie ein Projekt. Ist die Antwort eine Fähigkeit, eine Effizienz oder eine Modernisierung, haben Sie eine Ambition — und Ambitionen sind, wo KI-Budgets verschwinden.
Eine verwandte Disziplin lohnt die Übernahme: Entscheiden Sie vorab, was Sie stoppen liesse. Ein Pilot ohne Abbruchkriterien läuft, bis jemand die Geduld verliert — und dann machen die versunkenen Kosten das Streichen politisch teuer. Vorab zu vereinbaren, dass eine Eingriffsquote über einer Schwelle das Ende des Ansatzes bedeutet, verwandelt ein Scheitern in eine billige, frühe Antwort statt in eine langsame, unangenehme.
Die Organisationen mit echten Erträgen sind selten die mit den ambitioniertesten Programmen. Es sind die, die etwas Mühsames gewählt, es gemessen — und fertiggemacht haben.
Etwas Mühsames wählen, messen, fertigmachen — das ist die Form unserer KI-Projekte, und deshalb rechnen sie sich. Nennen Sie uns Ihren mühsamsten Prozess.
