Früh liefern. Am Nutzer lernen. Schnell verwerfen, neu bauen – mit KI ist Bauen ja billig geworden. Der Ratschlag begegnet mir in Weiterbildungen, an Konferenzen, täglich im Feed.
Ich halte dagegen – nicht weil er falsch wäre. Sondern weil er seinen Kontext verschweigt. Er stimmt in einer bestimmten Welt. Nur wird die Welt nie mitgeliefert.
Neues Produkt, kleines Team, keine Altlasten. Die Lösung steht neben dem Arbeitsprozess: Die ersten KI-Abfragen im Büroalltag waren genau das – Mehrwert ohne Abhängigkeit. Klappte es nicht, hatte der Nutzer ein paar Minuten verloren und machte es selbst. Dort darf ein Werkzeug unfertig sein. Dort ist Verwerfen billig: Kein Prozess hängt daran, niemand wird umgeschult, kein Steering muss es rechtfertigen. Ein Fehlversuch mit dem Werkzeug kostet Minuten – nicht mehr.
In dieser Welt stimmt der Ratschlag.
Meine Produkte kommen nicht in ein leeres System. Sie kommen in eine bestehende Realität – Prozesse, Umsysteme, gewachsene Arbeitsweisen – und meistens ersetzen sie etwas: ein altes System oder Stift und Papier. Brownfield. In Digitalisierungsprojekten ist das der Normalfall.
Die Nutzer sind festgelegt auf das Werkzeug, das man ihnen gibt – und ihr Job muss damit jederzeit vollständig erledigt werden können. Nicht zu siebzig Prozent, nicht «im nächsten Release dann ganz». Lernen am ausgerollten Produkt heisst hier: Mit jeder Iteration ändern sich Abläufe, ganze Abteilungen – nicht selten Hunderte von Menschen – lernen um, für dasselbe Arbeitsergebnis wie vorher. Die Kosten des Experiments tragen sie. Was danach «Widerstand gegen die Veränderung» heisst, ist häufig eine rationale Reaktion auf dieses Vorgehen.
Bei produzierenden Betrieben steht am Ende zudem ein Ergebnis, das Qualitätsansprüchen genügen muss: Ein Werkzeug, das sich laufend ändert, gefährdet nicht die Geduld der Mitarbeitenden, sondern das Produkt.
Und Verwerfen? Eine ausgerollte Lösung zu verwerfen ist kein billiger Lernschritt mehr. Da hängen Budgets dran, Verantwortungen, interne Überzeugungsarbeit – wer eine Lösung im Steering verteidigt hat, wirft sie nicht leichtfertig weg. Ein Irrtum, der erst im produktiven Einsatz sichtbar wird, ist hier teuer. Zu teuer, um ihn als Lernstrategie einzuplanen.
Nun könnte man meinen, die gelebte Brownfield-Praxis hätte darauf eine Antwort. Hat sie – aber die falsche. Der Auftrag kommt oft mit Problem und fertiger Lösung, beides gilt als gegeben, und die Analyse arbeitet die Anforderungen der gesetzten Lösung ab. Kein Lernen vor dem Bauen, kein Lernen danach: Gebaut wird, was bestellt wurde.
Die Lehre sagt: Lernt durch Ausliefern. Die Praxis sagt: Liefert, was bestellt wurde. Mein Weg liegt dazwischen – so nah wie möglich im Zielgebiet landen, bevor gebaut wird. Denn hin-iterieren kann ich im Brownfield nur mit Entwürfen und Prototypen. Nicht mit dem ausgerollten Produkt.
Denn ich verwerfe ständig. Skizzen, Varianten, Prototypen, PoCs – reihenweise. Nur nichts, was ausgerollt ist.
Die Frage ist nicht, ob verworfen wird. Die Frage ist, wann Irrtum noch billig ist. In der Konzeption kostet eine verworfene Variante Stunden. Nach dem Rollout kostet sie Releases, Umschulungen, Vertrauen. Also verlagere ich das Lernen dorthin, wo es billig ist: vor die Entwicklung. Von der Vision heruntersteigen, Stufe um Stufe, und auf jeder Stufe prüfen – über Mensch, Business und Technik hinweg. Die grossen Dinge, allen voran die Prozesse, sind vor der Umsetzung definiert, getestet, validiert. Die Details dürfen dann in der Umsetzung entstehen.
Schon die Vision ist der erste Test – als Geschichte erzählt, publiziert an Hunderte Mitarbeitende, mit gezielt kritischen Fragen: Was fehlt? Was stimmt für dich nicht? Eine gut erzählte Vision erzeugt fast immer Zustimmung; erst wenn Widerspruch zur erwünschten Antwort wird, prüft die Validierung etwas. Wir haben so Löcher gefunden, die wir nicht gesehen hatten. Wer nur Applaus erntet, hat nichts geprüft.
Am Ende steht keine perfekte Lösung, sondern eine tragfähige. Nicht alles muss von Anfang an digital sein, nicht alles gleich gut – aber jeder Zwischenzustand ist entworfen. Die Mitarbeitenden können in jedem Schritt der Transformation ihre Arbeit vollständig erledigen, idealerweise besser als vorher. Der Übergang ist Teil der Lösung, nicht ihr Restposten. Und weil es anders kommt, als man denkt, ist die Architektur auf Veränderung ausgelegt statt auf Zukunftstreffsicherheit.
«Bauen, verwerfen, neu anfangen» ist kein universeller Ratschlag. Er ist ein kontextgebundener – und wer ihn weitergibt, sollte den Kontext mitliefern.
Gelernt wird trotzdem. Und verworfen auch. Nur solange Irrtum noch billig ist.