Für Scheitern gibt es eine Sprache. Wenn ein Vorhaben klar nicht funktioniert, kennt jede Organisation die Wörter: Abbruch, Neuausrichtung, Lessons Learned. Unangenehm, aber sagbar.
Für den anderen Fall fehlt die Sprache vollständig. Ein System läuft. Es wird genutzt. Die Leute sind zufrieden. Und trotzdem trägt es nicht – die Architektur ist für den Pilotbetrieb entstanden, nicht für Skalierung, die Datenhaltung war nie für den Ernstfall gedacht, die Betriebsverantwortung ist faktisch da, aber nirgends zugewiesen. Was sagt man in dieser Situation? «Es funktioniert, aber wir müssten es eigentlich neu bauen» ist ein Satz, den in einem Steering Committee niemand freiwillig ausspricht.
Also passiert das Naheliegende: Es wird weitergebaut. Nicht aus Überzeugung, sondern weil es keine Kategorie für das gibt, was hier eigentlich nötig wäre. Die Organisation hört weder auf noch setzt sie neu an – sie driftet in eine stille Phase aus Nachbesserungen, Workarounds und wachsender Komplexität, die in keinem Projektbericht auftaucht. Ein Neustart trotz laufendem System ist politisch schwieriger als ein früher Abbruch. Beim Abbruch hat man wenigstens nichts, das man verteidigen muss.
Der erste produktive Kern beantwortet eine wichtige Frage: Erzeugt er Wirkung? Er beantwortet aber nicht die zweite, ebenso wichtige: Ist seine Grundlage tragfähig genug für den nächsten Investitionsschritt? Wirkt es und trägt es sind zwei getrennte Fragen – und die zweite wird fast nie gestellt, weil die erste positiv beantwortet ist. Erfolg deckt die Fundamentfrage zu.
Dahinter steckt ein Muster, das über Software hinausreicht: Je erfolgreicher der erste Schritt ist, desto schwieriger wird es, den zweiten noch grundsätzlich infrage zu stellen. Erfolg erzeugt Bindung – und Bindung senkt die Bereitschaft, noch einmal von vorne zu denken.
Neu ist das Problem nicht. Dringend geworden ist es durch generative Entwicklung. Wenn ein Fachbereich mit KI-gestützten Werkzeugen in wenigen Wochen etwas baut, das funktioniert und im Alltag ankommt, sieht es von aussen aus wie ein Produkt – und wird auch so behandelt. Nur fehlt darunter alles, was ein Produkt tragfähig macht: Architektur, Sicherheitsprüfung, Datenstrategie, klare Ownership, Betriebsverantwortung. Weil solche Lösungen Nutzen erzeugen, wird die Prüfung nachgelagert – oder gar nicht.
Die Frage «Ist das ein Prototyp oder ein Produkt?» lässt sich dabei nicht mehr durch Hinschauen beantworten. Beides sieht gleich aus. Was den Unterschied macht, ist nicht das Artefakt, sondern die Entscheidung dahinter:
Ob etwas ein Prototyp oder ein Produkt ist, entscheidet nicht sein Erscheinungsbild – sondern der Investitionsentscheid dahinter.
Ein Prototyp hat kein Betriebsbudget, keine Betriebsverantwortung und keinen Nutzungsanspruch. Ein Produkt hat alle drei, weil jemand das entschieden hat. Diese Grenze war früher sichtbar, weil ein Prototyp wie ein Prototyp aussah. Heute ist sie unsichtbar geworden – und muss deshalb institutionell gezogen werden. Wer das nicht tut, hat irgendwann produktive Systeme im Einsatz, über deren Betrieb nie jemand entschieden hat.
Praktisch heisst das: Bevor auf einem ersten Kern weitergebaut wird, braucht es einen expliziten Entscheid mit zwei getrennten Fragen. Erzeugt das Ding die erwartete Wirkung? Und trägt seine technische und organisatorische Basis den nächsten Investitionsschritt – oder müsste sie dafür ersetzt werden? Fällt die zweite Antwort negativ aus, ist «weiterbauen» keine Option, sondern eine Verschiebung der Kosten in die Zukunft.
Der schwierigste Investitionsentscheid ist damit nicht der erste. Es ist der erste nach einem erfolgreichen Ergebnis.
Eine Frage, die mich beschäftigt und auf die ich keine saubere Antwort habe: Woran erkennt man früh genug, dass ein laufendes System nicht weitergebaut, sondern neu aufgesetzt werden müsste – bevor die Abhängigkeiten so gross sind, dass die Frage niemand mehr stellt?