Die vier Stellen, an denen AI-Pilotprojekte still sterben, und niemand spricht darüber.

AI-Pilotprojekte sterben nicht in einem großen, dramatischen Moment. Deshalb geben die meisten Teams den falschen Dingen die Schuld: Das Modell sei nicht gut genug gewesen, der Use Case falsch, das Team nicht bereit. Dort gehen Pilotprojekte so gut wie nie wirklich verloren. Stattdessen verliert man sie in aller Stille, in der Lücke zwischen der Demo, die alle beeindruckt hat, und dem Produktionsbudget, das nie genehmigt wurde.

Im Pilotprojekt, das sechs Wochen nach dem Start still und leise keine Updates mehr bekam. Beim Champion, der das Team gewechselt hat und das einzige funktionierende Wissen darüber, wie es gebaut wurde, mitgenommen hat. Und im Tool, das live ging, funktionierte, und bei dem nie jemand gemessen hat, ob es überhaupt noch jemand nutzt. Das sind die vier Stellen, an denen AI-Pilotprojekte sterben, und in jeder Organisation mit einer AI-Initiative tauchen dieselben vier auf: leise, wiederholt, fast immer unbemerkt.

Wie ein stiller AI-Tod tatsächlich aussieht

Ein Pilotprojekt scheitert normalerweise nicht in einem einzigen Moment. Es hört auf, sich zu verstärken, leise, ohne dass es in Echtzeit jemand bemerkt. Die Demo läuft gut, also verschiebt sich das Follow-up-Meeting um eine Woche, dann um einen Monat, dann steht es einfach bei niemandem mehr im Kalender. Niemand hat es abgesagt. Es hat einfach aufgehört, die Aufgabe von irgendjemandem zu sein.

Leck eins: kein Owner nach der Demo

Ein Pilotprojekt hat während des Baus einen Owner. Nach der Demo hat es selten einen. Die Person, die sich dafür eingesetzt hat, wendet sich der nächsten Priorität zu, die Anerkennung für eine gute Demo wurde bereits eingeheimst, und es gibt keine ausdrückliche Übergabe an denjenigen, der es eigentlich in die Produktion tragen soll. Ohne Owner wird ein Pilotprojekt nicht beendet. Es hört einfach auf, sich zu bewegen.

Leck zwei: keine Budgetlinie für „nach dem Pilotprojekt“

Pilotbudgets lassen sich leicht genehmigen, weil die Summe klein ist und das Risiko überschaubar erscheint. Produktionsbudgets sind ein anderes Gespräch, eines, das einen Business Case braucht, einen Champion, der bereit ist, ihn zu verteidigen, und eine Zahl, die das Pilotprojekt nie geliefert hat, weil es nie daran gemessen wurde. Also liegt das Pilotprojekt dauerhaft in einem Ordner mit der Aufschrift „vielversprechend“, weil niemand den Case für den nächsten Schritt gebaut hat, solange die Begeisterung noch frisch war.

Leck drei: das Wissen verschwindet mit der Person

Die meisten Pilotprojekte werden von einer einzigen begeisterten Person gebaut, in welchem Tool auch immer sie zuerst gefunden hat, nirgendwo dokumentiert. Wechselt diese Person die Rolle, wird auf etwas Dringendes abgezogen oder geht einfach weiter, wird das Pilotprojekt nicht gepflegt. Es wird achtzehn Monate später von jemandem wiederentdeckt, der von vorn anfangen muss, weil nichts davon, wie es funktionierte, die Person überlebt hat, die es gebaut hat.

Leck vier: niemand misst die Nutzung

Ein Tool kann live gehen, korrekt funktionieren und trotzdem scheitern, wenn niemand prüft, ob die Leute es nach der ersten Woche weiter genutzt haben. Nutzung ohne Messung sieht genau wie Erfolg aus, bis jemand in einem Budget-Review eine unbequeme Frage stellt und niemand eine Antwort hat. Das Tool ist technisch gesehen noch live. Ob es noch etwas bewirkt, ist eine andere Frage, die nie gestellt wurde.

AI einzuführen ist nur die halbe Aufgabe. Die andere Hälfte ist der Widerstand, und Widerstand kündigt sich nicht an. Er gewinnt einfach leise.

Warum sich das aufschaukelt, statt klein zu bleiben

Ein totes Pilotprojekt ist ein Rundungsfehler. Vier oder fünf tote Pilotprojekte über zwei Jahre sind ein Muster, das den nächsten Vorschlag im Stillen vergiftet, weil sich der Raum viel klarer an „das haben wir schon mal versucht“ erinnert als daran, warum der vorherige Versuch eigentlich ins Stocken geraten ist. Die Technologie bekommt die Schuld für etwas, das in Wirklichkeit eine Ownership-Lücke war, und die nächste wirklich gute Idee bekommt eine härtere Prüfung, als sie verdient.

The ODB Way

Bei ODB Growth ist ein Pilotprojekt nicht das Ergebnis. Funktionierende Software in Produktion, gemessen an der Zahl, die sie bewegen sollte, das ist das Ergebnis. Das bedeutet: Ein Owner wird benannt, bevor der Bau beginnt, nicht nach der Demo. Es bedeutet, dass der Business Case für die Produktion von Anfang an schriftlich festgehalten wird, nicht später unter Druck rekonstruiert. Und es bedeutet, dass die Nutzung ab Woche eins gemessen wird, damit die Antwort auf „nutzt das überhaupt noch jemand“ eine Zahl ist, keine Vermutung.

Wenn es keine Zahl bewegt, ist es eine Demo. Die vier oben genannten Lecks zu schließen ist der Weg, wie aus einer Demo etwas wird, auf das sich das Geschäft tatsächlich verlassen kann.