Was ein KMU an einem Tag mit KI bauen kann

Donnerstag, 9 Uhr, in Bozen.

Auf dem Tisch liegen Methodenunterlagen, PowerPoint-Master, Sprachmemos, Screenshots und Prozesse, die über mehrere Werkzeuge und Ablagen verteilt sind. Dazu eine Website, die nur mit Aufwand aktualisiert wird, und eine Zeiterfassung, deren Monatsabschluss viel Handarbeit verlangt.

Um 16 Uhr hat das Team von Dockyard Ventures vier eigene KI-Skills getestet und als wiederverwendbare Pakete gesichert. In zwei Vibe-Coding-Sessions sind ausserdem klickbare Prototypen für eine neue Website und eine mobile Zeiterfassung entstanden. Für jedes Ergebnis sind Eigentümer und nächster Praxiseinsatz festgelegt.

Das klingt nach einer dieser Geschichten, in denen KI angeblich eine Woche Arbeit in wenigen Stunden erledigt.

So war es nicht.

Das Ergebnis war möglich, weil Julian Thuile und sein Team ihr Geschäft, ihre Methoden und ihre Qualitätsansprüche kennen. Ausserdem begann der Tag nicht bei null. Methodenunterlagen, Vorlagen, Arbeitsproben und die technische Umgebung waren vorbereitet. Die KI hat dieses Wissen nicht ersetzt. Sie hat geholfen, es in Werkzeuge zu übersetzen.

Genau darin liegt die eigentliche Wirkung.

Der Tag war zugleich der Abschluss unseres gemeinsamen MMIND Erasmus+ Projekts. Für uns war er mehr als ein schöner Schlusspunkt. Er hat gezeigt, wie ein kleines Unternehmen die Wirkung von KI an einem einzigen Arbeitstag tatsächlich spüren kann.

Viele KI-Workshops beginnen mit Funktionen.

Man zeigt einen Chatbot, generiert ein Bild, fasst ein Dokument zusammen und baut vielleicht noch eine kleine Demo. Am Ende sind die Teilnehmenden beeindruckt. Am Montag beginnt jedoch wieder derselbe Arbeitsalltag.

Wir haben die Reihenfolge in Bozen umgedreht.

Die erste Frage lautete nicht: «Was kann Claude?» oder «Was können wir mit Lovable bauen?»

Sie lautete: «Welche wiederkehrende Arbeit kostet euch heute Zeit, und woran erkennt ihr ein gutes Ergebnis?»

Die Antworten waren sehr konkret.

Eine Workshop-Präsentation beginnt bei Dockyard häufig mit Notizen, Post-its oder einem Sprachbriefing. Daraus entstehen Dramaturgie, Folienplan und schliesslich ein Deck im richtigen Master. Inhalt, Gestaltung und Qualitätskontrolle beanspruchen zusammen schnell einen Arbeitstag.

Wissen liegt in Notion, SharePoint, persönlichen Sammlungen, Screenshots und Sprachmemos. Vieles ist vorhanden, aber nicht immer dort auffindbar, wo das Team es beim nächsten Auftrag braucht.

Beiträge sollen nach Dockyard klingen, auf echten Beobachtungen beruhen und keine vertraulichen Projektdetails verraten. Gerade in vollen Wochen bleibt diese Arbeit liegen.

Auch die beiden Prototypen hatten einen klaren geschäftlichen Ausgangspunkt. Das Team berichtete, dass die bestehende Website in vier Jahren nur eine ernsthafte Anfrage gebracht habe. Beim Monatsabschluss der Zeiterfassung entstehen durch Nachträge, Prüfungen, Exporte und eine separate Excel erhebliche interne Aufwände.

Das sind keine abstrakten «AI Use Cases». Es sind bekannte Reibungen im eigenen Betrieb.

Ein KI-Skill ist für uns kein besonders langer Prompt.

Er ist ein kleines, verpacktes Arbeitssystem. Darin stehen der Auslöser, die benötigten Unterlagen, der Ablauf, die Qualitätsregeln, die Grenzen und das gewünschte Ergebnis. Wenn die Aufgabe wiederkommt, muss das Team diese Logik nicht jedes Mal neu erklären.

In der KI-Werft entstanden vier Dockyard-Skills:

Der Skill bildet Dockyards Methode ab, mit der ein Team von einem Suchfeld über Zielkunde, Nutzenversprechen und Geschäftsmodell zu Prototyp und Validierungsplan kommt.

Das Entscheidende war nicht, möglichst viel Methode in eine Datei zu schreiben. Der Skill durfte keine erfundenen Marktannahmen als Dockyard-Wissen ausgeben. Er musste fehlende Angaben erkennen, gezielt nachfragen und klar trennen, was das Team entschieden hat und was nur ein KI-Vorschlag ist.

Aus Notizen, Sprachbriefings oder Workshopmaterial soll ein brauchbarer PowerPoint-Erstentwurf im richtigen Master entstehen.

Der Skill kennt deshalb nicht nur den Ablauf. Er kennt auch das Qualitätsurteil: eine klare Geschichte, korrekte Logos und Schriften, keine doppelten Folien, keine technischen Überläufe und Sprache, die nach der präsentierenden Person klingt. Die menschliche Schlusskontrolle bleibt ausdrücklich Teil des Prozesses.

Lose Notizen, Links, Screenshots, Sprachmemos und Projekterkenntnisse werden zu standardisierten Wissenskarten mit Quelle, Datum, Schlagworten und Freigabestatus.

Wichtig ist die Rangfolge. Dockyards eigener Goldstandard kommt zuerst. Danach folgen bewusst kuratierte Referenzen. Externe Recherche steht an dritter Stelle und darf die eigene Methode nicht still überschreiben.

Aus einer realen Beobachtung, einem freigegebenen Foto oder einer Veranstaltung entsteht ein veröffentlichungsnaher Beitrag.

Der Skill prüft dabei nicht nur Stil und Fakten. Er fragt auch, ob ein Kundenfall genannt werden darf, ob das Thema zum Profil passt und ob aus einem Text ein relevantes Gespräch entstehen kann. Automatisch veröffentlicht wird nichts.

Jeder Skill wurde im Team gebaut, getestet und korrigiert. Das ist ein wichtiger Unterschied. Eine Anleitung, die nur ihre Autorin oder ihr Autor versteht, ist noch kein gemeinsames Werkzeug.

Am Nachmittag wechselte die Aufgabe.

Für manche Abläufe reicht ein Skill. Wenn eine Person mit Claude an einer Datei arbeitet und dabei eine wiederkehrende Methode befolgt, kann ein gut gebauter Skill bereits viel Vorarbeit übernehmen.

Sobald mehrere Menschen dieselben Daten sehen müssen, Rollen und Rechte wichtig werden oder ein Ablauf auch ohne Claude funktionieren soll, braucht es eher eine Anwendung.

Diese Unterscheidung hat zwei unnötige Extreme verhindert: aus jedem Problem sofort ein Softwareprojekt zu machen oder jeden Teamprozess in einen Chat zu pressen.

Für Dockyard waren zwei Anwendungen sinnvoll genug, um sie sofort als Prototyp zu testen.

Der Website-Prototyp sollte auf Mobilgeräten funktionieren, das Angebot in wenigen Sekunden verständlich machen und Änderungen ohne Agentur ermöglichen. Der Prototyp zeigt bereits die Grundstruktur mit Nutzen, Leistungen, Methode, Team und Kontakt. Finale Positionierung, Inhalte, Datenschutz, Weiterleitungen und Tracking bleiben vor einer Veröffentlichung zu klären.

Der zweite Prototyp bildet eine einfache mobile Zeiterfassung ab. Zeiten werden Kunde, Projekt und Aufgabe zugeordnet, als verrechenbar oder nicht verrechenbar markiert und für den Monatsabschluss prüfbar gemacht. Die komplexe Vergütungsberechnung wurde bewusst nicht gebaut, weil ihre Regeln zuerst mit anonymisierten Daten und Testfällen geprüft werden müssen. Auch Rollen, reale Daten, Authentifizierung und Exportlogik gehören in spätere, kontrollierte Schritte.

Beide Prototypen wurden mit Lovable aus den zuvor definierten Anforderungen gebaut. Vibe Coding war damit nicht der Anfang des Denkens. Es war die Übersetzung eines bereits geklärten Problems in eine sichtbare, diskutierbare Oberfläche.

Vier Skills und zwei Prototypen sind ein starkes Ergebnis. Für andere Teams ist jedoch nicht die Zahl entscheidend. Entscheidend ist die Abfolge. Und: Der sichtbare Arbeitstag braucht Vorbereitung. Ohne echte Unterlagen, geklärte Zugänge und passende Testfälle würde ein erheblicher Teil der Zeit mit Suchen und Einrichten verloren gehen.

Dieser Ablauf verhindert, dass ein Workshop mit sechs schönen Demos und null Veränderung endet.

Natürlich ist nach einem Tag nicht alles fertig. Ein klickbarer Prototyp ist noch keine produktive Anwendung. Ein Skill ist erst dann wertvoll, wenn er im nächsten echten Auftrag ein gutes Ergebnis liefert. Datenschutz, Zugriffsrechte, Datenqualität und fachliche Freigaben verschwinden nicht, nur weil die Oberfläche schnell gebaut wurde.

Aber nach einem solchen Tag diskutiert ein Team nicht mehr abstrakt über KI.

Es hat eigene Werkzeuge vor sich. Es kann sie öffnen, testen, verwerfen und verbessern. Und es weiss, welcher nächste Schritt sinnvoll ist.

Um 16 Uhr war die Begeisterung im Raum deutlich spürbar. Sie kam nicht von einer spektakulären KI-Demo. Sie kam daher, dass aus vertrauten Problemen in wenigen Stunden etwas Eigenes entstanden war.

Genau so sollte sich die Einführung von KI in einem KMU anfühlen.

Eine KI-Werft lässt sich auf andere Unternehmen und Teams übertragen. Jedes Team arbeitet dabei mit den eigenen Abläufen, Unterlagen und Qualitätsregeln. Die Ergebnisse müssen deshalb nicht dieselben vier Skills und zwei Prototypen sein.

Wenn du wissen möchtest, wie wir einen solchen Arbeitstag mit deinem Team durchführen können, antworte einfach auf diese E-Mail.

Schreib uns in ein bis zwei Sätzen, welcher wiederkehrende Ablauf euch heute am meisten Zeit kostet. Wir melden uns persönlich und schauen gemeinsam, was sich an einem Tag sinnvoll bauen und testen lässt.

Das Team von MMIND.ai