KI Prototyp ohne Programmierung: Wie KMU erste Prototypen bauen
- 12. Jan.
- 3 Min. Lesezeit
In vielen KMU beginnt das Thema KI mit einer Ansage aus der Geschäftsführung: Es soll sichtbar werden, dass etwas passiert. In der Bereichsleitung kommt dieser Impuls als Arbeitsauftrag an – und verwandelt sich schnell in Unruhe. Fachabteilungen starten parallel, Vorschläge stapeln sich, jeder will „auch etwas machen“. Was fehlt, ist nicht Energie, sondern ein gemeinsamer Bezugsrahmen: Woran wird gearbeitet, welche Annahme soll beantwortet werden, und welche Ergebnisse müssen am Ende vergleichbar auf dem Tisch liegen?
In dieser Lage scheitern Prototypen oft nicht, weil sie technisch unmöglich wären, sondern weil sie als Technologietest angelegt sind. Der Fokus liegt auf dem Werkzeug und den Möglichkeiten, nicht auf dem Problem und der Entscheidung, die daraus folgen soll. Aus Sicht der Bereichsleitung wird das zum Engpass: Zeit wird verbrannt, Abstimmung wird zur Daueraufgabe, und selbst gute Teams liefern Ergebnisse, die sich nicht bewerten lassen.
Der Stopp-Moment der Bereichsleitung
Typisch ist ein Verlauf, in dem zwei frühe Prototypen bereits gescheitert sind – trotz A-Playern. Der Lerneffekt bleibt trotzdem gering, weil nie klar vereinbart war, welche Entscheidungskriterien präsentiert werden müssen. Die Bereichsleitung soll „Go oder No-Go“ entscheiden, bekommt aber zwei unterschiedliche Erzählungen statt zwei vergleichbare Tests. Genau hier entsteht der Stopp-Moment: Nicht als Bremsung, sondern als Rückkehr zur Systematik.
Die Funktion dieser Systematik ist schlicht: Transparenz schaffen, Doppelarbeit vermeiden, und Prototypen als Lerninstrument führen. Entscheidend wird, dass Teams nicht „etwas bauen“, sondern Hochrisiko-Annahmen testen – und die Ergebnisse so dokumentieren, dass Entscheidungen möglich werden.
Prototyping beginnt am Whiteboard
Viele verbinden Prototyping mit etwas Greifbarem: einer Oberfläche, einem installierbaren Artefakt, einer App. Das ist jedoch nur der erste digitale Prototyp – und oft nicht der erste sinnvolle Schritt. Vor dem Digitalen liegt der Paper Prototype: Ablaufskizzen, Rollen, Eingaben, Ausgaben, Übergaben, Fehlerfälle. Am Whiteboard entsteht der erste belastbare Blick darauf, ob eine Idee in den Alltag passt.
Diese Reihenfolge wirkt unspektakulär, verhindert aber den häufigsten Fehlstart: Digitalisieren, bevor klar ist, was eigentlich geprüft werden soll. Prototyping beginnt erst dann, wenn das Problem eindeutig beschrieben ist und seine Relevanz erkennbar wird – für mehrere Stakeholder, nicht nur für einen Einzelfall.
Eine praxistaugliche Abfolge sieht so aus:
Problem identifizieren und abgrenzen
Relevanz prüfen (Stakeholder, Häufigkeit, Risiko)
Hochrisiko-Annahmen formulieren
Paper Prototype (Whiteboard/Papier) inklusive Edge Cases
erst danach: digitaler Prototyp, wenn er für den Test nötig ist
Ein Beispiel aus der Angebotsphase
Im Maschinenbau bietet die Angebotsphase ein typisches Feld: Viele technische Rückfragen, lange Durchlaufzeit von Anfrage bis Versand, zahlreiche Korrekturschleifen. Gute Prototypen setzen hier nicht beim „KI-Einsatz“ an, sondern bei der Frage, welche Annahme die meiste Unsicherheit trägt. Gemessen wird dann nicht an Eindruck, sondern an Kennzahlen wie Durchlaufzeit, Erfolgsquote Angebot→Auftrag, Anzahl Korrekturschleifen oder Abweichung zwischen angebotener und tatsächlich gebauter Ausführung.
Damit die Bereichsleitung nicht erneut mit unvergleichbaren Ergebnissen konfrontiert wird, braucht es ein kleines Management-Artefakt: das Management Pitch Canvas. Es zwingt Teams, Annahme, Test, Ergebnis und Entscheidung in einer Form zu präsentieren, die vergleichbar ist – und die Diskussion von „schön gebaut“ auf „sauber gelernt“ verschiebt.
Warum dafür kein Programmieren nötig ist
Der Kern der Lösung liegt nicht in einem bestimmten Werkzeug, sondern in der Trennung von Denken und Bauen. Ein belastbarer Paper Prototype kann die entscheidenden Annahmen bereits sichtbar machen – ohne eine Zeile Code. Wenn ein digitaler Prototyp für die Validierung nötig ist, muss Programmierung nicht intern vorhanden sein. Entwicklung kann zugekauft werden, solange das Team präzise formulieren kann, was geprüft werden soll, welche Edge Cases relevant sind und welche Kriterien am Ende zählen.
No-Code- und Low-Code-Ansätze gehören in diesem Bild an das Ende: als Beschleuniger für bestimmte Tests, nicht als Standardweg. Voraussetzung bleiben klare Entscheidungskriterien aus der Fachabteilung, ein abgestimmter Rahmen mit IT-Policy – und die Disziplin, Prototyping als Validierung zu führen, nicht als vorschnellen Bau.
Kommentare