Warum KI-Prototypen schneller zu brauchbarem Feedback führen

Viele Digitalprojekte beginnen mit Workshops, Prozesslandkarten und detaillierten Designs. Das ist verständlich: Niemand möchte ein System bauen, das am Geschäft vorbeigeht. Trotzdem entsteht in dieser Phase oft ein trügerisches Gefühl von Sicherheit. Auf einem Diagramm wirkt fast jeder Prozess logisch. Erst wenn Menschen mit einer konkreten Anwendung arbeiten, werden die fehlenden Felder, unklaren Zustände, Sonderfälle und Medienbrüche sichtbar.

KI-gestützte Entwicklung verändert deshalb die Reihenfolge guter Produktarbeit. Statt wochenlang zu modellieren, kann ein Team früh einen einfachen Prototyp bauen. Er kann echte Formulare, Listen, erste Rollen, Beispielreports und sogar eine grobe Integration zu vorhandenen Daten enthalten. Der Prototyp darf unfertig aussehen und muss noch nicht produktionsreif sein. Er muss nur konkret genug sein, damit Benutzer reagieren können.

Eine empirische Modellstudie zum Software-Prototyping fasst 33 Primärstudien, eine Fokusgruppe und Interviews aus zwölf Unternehmen zusammen. Sie trennt fünf Entscheidungen: Zweck, Umfang, Medium, Verwendung und Art der Erkundung. Prototypen können Anforderungen, Machbarkeit und Bedienbarkeit klären. Die Autoren warnen aber auch, dass sie einen falschen Eindruck vom Fertigstellungsgrad erzeugen können. Die Studie belegt nicht, dass KI jeden Prototyp schneller macht; sie stützt, dass der Prototyp auf eine konkrete Lernfrage zugeschnitten sein sollte.

Ein Beispiel: Bestand einem Projekt zuordnen

Bei MAFU-SHERPA lief die Bestandsverwaltung über eine ausgeklügelte Excel-Datei, und vom Shopfloor aus wurde die Inventur damit zunehmend fehleranfällig. Auf einem Ablaufdiagramm steht in so einem Fall ein einziger Kasten, „Bestand einem Projekt zuordnen“, und er wirkt vollständig. Am Regal entscheidet sich dann, ob dafür der Artikel, der Lagerplatz oder der Auftrag gescannt wird, was bei einer falschen Zuordnung passiert und wer den Fehler bemerkt. Diese Fragen beantwortet erst die Benutzung. Die erste Version war deshalb eine schmale Barcode-App, die Artikel am Regal las, Bestand einem Projekt zuordnete und die Änderung in die vorhandenen Tabellen zurückschrieb. In den Wochen danach kam weitere Funktionalität dazu, während die App bereits im Einsatz war. Die Fallstudie zur Bestandsverwaltung mit Power Apps hält den Weg fest, und wie sich eine solche Wahl zwischen Standard, Eigenentwicklung und Tabelle einordnet, zeigt Individualsoftware vs. Standardsoftware.

Warum abstraktes Feedback schwach ist

Wenn Benutzer ein Prozessmodell sehen, kommentieren sie meist das, was sie bereits kennen. Sie sagen, ob die Kästchen grundsätzlich richtig angeordnet sind und ob ein Schritt fehlt. Das hilft, aber es bleibt abstrakt. Niemand spürt, ob ein Formular zu lang ist oder ob die Suche im Alltag funktioniert. Auch missverständliche Statusnamen und häufige Systemwechsel bleiben auf dem Diagramm unsichtbar.

Ein Prototyp erzeugt anderes Feedback. Benutzer klicken durch einen Auftrag, erfassen eine Reklamation, prüfen einen Lagerbestand oder genehmigen eine Bestellung. Sie merken sofort, wo die Software den Arbeitsfluss unterstützt und wo sie im Weg steht. Dieses Feedback ist präziser, weil es aus Nutzung entsteht, nicht aus Vorstellungskraft.

KI senkt die Kosten der ersten Version

Früher war ein Prototyp oft teuer genug, dass Teams ihn ebenfalls stark planen mussten. KI verschiebt diese Kostenkurve. Layouts, Datenmodelle, einfache Abläufe, Validierungen und erste Testdaten lassen sich schneller erstellen. Dadurch wird es wirtschaftlich sinnvoll, mehrere Varianten auszuprobieren, bevor große Entscheidungen getroffen werden.

Das bedeutet nicht, dass Architektur, Sicherheit und Prozessverständnis unwichtig werden. Im Gegenteil: Gerade weil KI schnell viel Code erzeugen kann, braucht das Team klare technische Leitplanken. Der Unterschied liegt im Zeitpunkt. Anstatt den gesamten Prozess vorab perfekt zu beschreiben, baut man eine schmale Version, testet sie mit echten Nutzern und modelliert danach mit besseren Informationen weiter.

Ein guter Prototyp beantwortet konkrete Fragen

Ein Prototyp ist kein Selbstzweck. Er sollte auf wenige Entscheidungen ausgerichtet sein. Zum Beispiel: Reicht eine einfache Aufgabenliste oder braucht der Prozess Statuswechsel mit Verantwortlichkeiten? Kann ein Standardformular die Daten erfassen oder sind mehrere Rollen beteiligt? Muss eine Integration sofort gebaut werden oder genügt für die erste Version ein Import?

• Bauen Sie nur den kleinsten Ablauf, der eine echte Entscheidung ermöglicht.
• Nutzen Sie realistische Beispieldaten, damit Fachbereiche typische Fälle erkennen.
• Beobachten Sie Benutzer beim Klicken, statt nur Meinungen einzusammeln.
• Trennen Sie Feedback zu Fachlogik von Feedback zu Oberfläche und Bedienung.
• Entscheiden Sie nach jeder Feedbackrunde, was entfernt, vereinfacht oder vertieft wird.

Prozessmodellierung bleibt wichtig

Schnelles Prototyping ersetzt keine saubere Prozessarbeit. Es macht sie besser. Nach zwei oder drei Feedbackrunden ist klarer, welche Prozessschritte wirklich relevant sind. Ebenso wird sichtbar, welche Sonderfälle selten genug für manuelle Behandlung bleiben und welche Regeln im System verbindlich abgebildet werden müssen. Das spätere Prozessmodell basiert dann auf beobachtetem Verhalten statt allein auf Workshop-Erinnerungen.

Bei der Inventur-App war das genau so. Das vollständige ERP folgte später als eigener Schritt; die App wurde in den Wochen nach der Einführung um weitere funktionale Anforderungen erweitert.

Gerade bei ERP-, CRM- und internen Business-Apps ist das entscheidend. Der Nutzen entsteht nicht dadurch, dass ein Prozess besonders detailliert dokumentiert wurde. Der Nutzen entsteht, wenn Mitarbeiter schneller entscheiden, weniger doppelt erfassen und Management verlässliche Informationen erhält.

Eine Regel für den Start

Bei der MAFU-SHERPA-App hat sich eine Regel bewährt, die wir seither jedem Prototyp mitgeben: Benennen Sie vor dem Bau genau eine Entscheidung, die der Prototyp ermöglichen soll, und beenden Sie die Lernrunde, sobald diese Frage beantwortet ist. Alles, was diese Frage nicht beantwortet, gehört in eine spätere Runde; woran ein Ergebnis später erkennbar sein muss, steht in Akzeptanzkriterien für KI-Aufgaben.

Mit dem Tempo der Entwicklung verschiebt sich außerdem der Engpass innerhalb der Lernrunde. Wenn die erste funktionierende Version in Tagen entsteht, ist selten der Code der langsamste Teil, sondern die Entscheidung darüber. Feedback, das drei Wochen liegen bleibt, macht den schnellsten Prototyp wieder langsam; dann entsteht nur schneller mehr Oberfläche, ohne dass der Ablauf besser wird. Planen Sie deshalb die Entscheiderrunde gleich mit: Wer sieht den Prototyp wann an, und wer entscheidet innerhalb weniger Tage über die nächste Runde?

Erst mit benannter Lernfrage und fester Entscheiderrunde lohnt sich das Tempo der KI-Entwicklung.