Vom Schlagwort zur begründeten Empfehlung

Worum es geht

Dienstagmorgen bei der Holzbau Zürcher AG in Sursee. Die Geschäftsführerin kommt mit einem Zeitungsartikel ins Büro: «Andere Firmen lassen ihre Rapporte schon von der KI schreiben. Können wir das auch?» Solche Fragen landen früher oder später bei dir. Mal geht es um KI, mal um eine App, die man ohne Programmieren zusammenklickt, mal um Sensoren, die selbstständig Daten liefern.

Zwei Antworten sind bequem, und beide sind schlecht. «Klar, machen wir!» führt oft zu einem teuren Projekt, das niemand wirklich braucht. «Brauchen wir nicht, das ist nur ein Hype» verschenkt vielleicht eine echte Verbesserung. Dazwischen liegt die Antwort, die ein Betrieb von einer Fachperson erwartet: «Ich prüfe es. In sechs Wochen wissen wir, ob es sich lohnt, und zwar mit Zahlen.»

Genau dieses Prüfen lernst du in diesem Kurs. Es ist ein Handwerk mit klaren Schritten, und es funktioniert für jede Technologie, egal ob sie heute oder in fünf Jahren gerade aktuell ist.

Warum Bauchgefühl nicht reicht

Stell dir vor, du kaufst ein gebrauchtes Auto. Das Inserat verspricht «sparsam, zuverlässig, top gepflegt». Würdest du es ohne Probefahrt kaufen? Wohl kaum. Du fährst deine eigene Strecke, prüfst, ob deine Sporttasche in den Kofferraum passt, und rechnest Versicherung und Service dazu. Bei einer neuen Technologie ist es genauso: Herstellerseiten, Konferenzvorträge und Zeitungsartikel zeigen den besten Fall. Ob die Technologie in deinem Betrieb funktioniert, zeigt nur ein Test auf deiner eigenen «Strecke».

In der Praxis tauchen drei Denkfehler immer wieder auf:

Der Ausweg ist ein systematisches Vorgehen: Du beginnst beim Problem, legst vorher fest, woran du Erfolg erkennst, und testest mit realistischen Daten in begrenzter Zeit. So entsteht eine Entscheidung, die du begründen kannst, auch wenn sie «nein» lautet.

Der Weg in sechs Etappen

Jede Technologie-Evaluation, ob für einen Chatbot, eine Low-Code-App oder einen Temperatursensor, folgt demselben Grundmuster:

Die gestrichelten Pfeile zurück sind wichtig: Eine Evaluation ist keine Einbahnstrasse. Merkst du im Gespräch mit Betroffenen, dass das Problem ein ganz anderes ist, gehst du zurück und prüfst vielleicht eine andere Technologie. Und stellst du beim Bauen fest, dass sich ein Erfolgskriterium gar nicht messen lässt, schärfst du den Anwendungsfall nach. Das ist kein Scheitern, sondern genau der Zweck des Vorgehens: früh und günstig lernen statt spät und teuer.

Prototyp, Proof of Concept, MVP und Pilot

Vier Begriffe werden im Alltag oft durcheinandergeworfen. Eine Analogie aus der Küche hilft: Ein Restaurant will ein neues Gericht einführen.

• Der Koch kocht eine kleine Menge, um zu sehen, ob die Sauce mit der neuen Zutat überhaupt bindet. Das ist ein Proof of Concept (PoC): Er zeigt, dass etwas grundsätzlich machbar ist.
• Er richtet einen Teller so an, wie er später aussehen soll, und lässt das Team probieren. Das ist ein Prototyp: ein vorläufiges Modell, an dem man etwas ausprobiert und daraus lernt.
• Das Gericht kommt in einer einfachen Version auf die Karte, und man schaut, ob Gäste es bestellen. Das ist ein Minimum Viable Product (MVP): die kleinste Version, die echten Nutzen stiftet und echte Rückmeldungen liefert.
• Einen Monat lang gibt es das Gericht nur in einer von drei Filialen, mit klaren Messgrössen. Das ist ein Pilot: ein begrenzter Echtbetrieb vor der breiten Einführung.

In diesem Modul baust du einen Prototyp, der gleichzeitig als Proof of Concept dient: Er soll zeigen, ob die Idee technisch geht und ob sie den erhofften Nutzen bringt. Darum spricht man in der Praxis oft einfach vom «PoC».

Der wichtigste Unterschied liegt zwischen Prototyp und Produkt. Ein Prototyp beantwortet eine Frage mit möglichst wenig Aufwand. Er darf Lücken haben: keine Benutzerverwaltung, kein ausgefeiltes Design, keine Fehlerbehandlung für Sonderfälle. Ein Produkt dagegen muss stabil, sicher, dokumentiert und wartbar sein. Der Weg vom Prototyp zum Produkt kostet oft ein Mehrfaches dessen, was der Prototyp gekostet hat.

Vier ehrliche Ergebnisse

Am Ende jeder Evaluation steht eine von vier Empfehlungen:

Schritt für Schritt: Aus einer vagen Bitte wird ein Evaluationsauftrag

Die Geschäftsführerin hat Noah nur gesagt: «Schau doch mal, ob es für die Rapporte etwas Modernes gibt.» Damit kann man nicht arbeiten. Noah macht daraus einen klaren Auftrag.

Schritt 1: Ausgangslage festhalten. Noah schreibt auf, was er weiss: 40 Monteure und Poliere, Rapporte auf Papier, rund sechs Stunden Abtippen pro Woche im Büro, häufige Rückfragen bei unleserlichen oder unvollständigen Rapporten.

Schritt 2: Leitfrage formulieren. Eine gute Leitfrage ist offen für das Ergebnis und nennt kein Produkt: «Kann eine aktuelle Technologie die Erfassung der Tagesrapporte so verbessern, dass der Büroaufwand deutlich sinkt, ohne die Monteure zusätzlich zu belasten?» Eine schlechte Leitfrage wäre: «Wie führen wir eine KI-App ein?» Sie setzt das Ergebnis schon voraus.

Schritt 3: Kandidaten sammeln. Nach einer ersten Recherche notiert Noah drei Kandidaten: eine Progressive Web App mit Offline-Speicher, eine KI-Spracherkennung zum Diktieren und eine Low-Code-App mit Power Apps. Als Vergleich nimmt er die heutige Lösung (Papier) und eine fertige Branchensoftware dazu.

Schritt 4: Zeitrahmen festlegen. Noah plant zehn Arbeitstage, verteilt auf sechs Wochen:

Schritt 5: Ergebnisform vereinbaren. Die Geschäftsleitung bekommt eine 15-minütige Präsentation mit Demo und einen Bericht von höchstens acht Seiten.

Schritt 6: Auftrag bestätigen lassen. Noah fasst alles zusammen und lässt es von seiner Berufsbildnerin Frau Arnold und von der Geschäftsführerin abzeichnen:

Evaluationsauftrag Tagesrapporte (Version 1.0)

Leitfrage:   Kann eine aktuelle Technologie die Erfassung der Tagesrapporte
             so verbessern, dass der Büroaufwand deutlich sinkt, ohne die
             Monteure zusätzlich zu belasten?
Kandidaten:  PWA mit Offline-Speicher, KI-Spracherkennung, Power Apps;
             Vergleich mit Papier (heute) und einer Branchensoftware
Rahmen:      10 Arbeitstage in 6 Wochen, davon 5 Tage Prototyp
Ergebnis:    Präsentation 15 Min. mit Demo, Bericht max. 8 Seiten,
             Empfehlung: einführen, Pilot, beobachten oder verwerfen
Nicht Teil:  Lohnabrechnung, Anbindung an die Buchhaltung

Auftraggeberin: S. Zürcher, Geschäftsführerin
Betreuung:      M. Arnold, Berufsbildnerin

Mit diesem Auftrag weiss jede beteiligte Person, was geprüft wird, wie lange es dauert und was am Ende herauskommt. Und Noah hat einen Massstab, an dem er seine eigene Arbeit messen kann. Wenn die Geschäftsführerin in drei Wochen fragt «Kannst du nicht auch gleich die Ferienplanung digitalisieren?», zeigt er freundlich auf den Auftrag.

Typische Fehler

• Mit der Technologie statt mit dem Problem beginnen. «Wir machen jetzt etwas mit KI» ist kein Auftrag. Korrektur: Frag zuerst, welcher Ablauf heute Zeit, Geld oder Nerven kostet.
• Keine Zeitgrenze setzen. Ohne Rahmen wird aus einer Evaluation ein Dauerprojekt. Korrektur: Plane die Etappen in Arbeitstagen und lass den Rahmen bestätigen.
• Prototyp und Produkt verwechseln. Wer einen Prototyp ohne Weiteres in Betrieb nimmt, übernimmt alle seine Lücken. Korrektur: Nenne die Lücken in der Präsentation ausdrücklich.
• Nur die neue Technologie anschauen. Ohne Vergleich mit der heutigen Lösung oder einer Standardsoftware weisst du nicht, ob die Neuerung besser ist. Korrektur: Nimm immer mindestens eine klassische Variante in den Vergleich.
• Das Ergebnis vorwegnehmen. Wer schon vor dem Test «einführen» empfehlen will, sieht nur noch Bestätigungen. Korrektur: Leitfrage offen formulieren und Erfolgskriterien vorab festlegen.

Zusammenfassung

• Neue Technologien prüfst du systematisch: weder Hype noch Reflex-Nein, sondern ein Test mit eigenen Daten.
• Das Vorgehen hat sechs Etappen: einordnen, Anwendungsfall schärfen, Varianten bewerten, Prototyp in der Timebox, Risiken und Kosten, Empfehlung.
• PoC prüft die Machbarkeit, Prototyp macht eine Idee erlebbar, MVP bringt kleinsten echten Nutzen, Pilot testet im Alltag eines Teams.
• Ein Prototyp beantwortet eine Frage und darf Lücken haben. Ein Produkt muss stabil, sicher und wartbar sein.
• Mögliche Empfehlungen: einführen, Pilot, beobachten, verwerfen. Alle vier sind gültige Ergebnisse.
• Aus einer vagen Bitte machst du einen Evaluationsauftrag mit Leitfrage, Kandidaten, Zeitrahmen, Ergebnisform und Abgrenzung.