Drei Fragen auseinanderhalten

Die erste Frage lautet: Lässt sich die gewünschte Aufgabe mit den vorhandenen Daten und technischen Mitteln grundsätzlich bearbeiten? Die zweite lautet: Können die vorgesehenen Menschen damit einen sinnvoll begrenzten Arbeitsablauf erledigen?

Die dritte Frage betrifft den Betrieb: Funktioniert die Lösung unter den vorgesehenen Bedingungen mit Zuständigkeiten, Schutzmassnahmen und einer Möglichkeit zur Fehlerbehandlung? Diese Fragen hängen zusammen, werden aber nicht durch denselben Nachweis beantwortet.

Begriffe wie Proof of Concept, Prototyp, Pilot und MVP werden von Anbietern unterschiedlich verwendet. Vereinbaren Sie deshalb die Bedeutung im konkreten Auftrag. Die Bezeichnung allein ist noch keine Leistungsbeschreibung.

Ein Proof of Concept prüft eine wichtige Annahme

In diesem Beitrag bezeichnet Proof of Concept einen begrenzten Machbarkeitstest. Beispielsweise wird untersucht, ob bestimmte Angaben aus einer geeigneten Dokumentstichprobe ausreichend zuverlässig erkannt werden können.

Das Ergebnis kann ein Testbericht mit Beispielen, Grenzen und einer Empfehlung sein. Eine ansprechende Oberfläche ist dafür nicht zwingend erforderlich. Ebenso sollten Sie nicht stillschweigend einen wartbaren Produktionsbetrieb erwarten.

Das GOV.UK-Handbuch zur Alpha-Phase beschreibt frühe Prototypen als Mittel, riskante Annahmen zu untersuchen. Übertragen auf Ihr Vorhaben heisst das: Wählen Sie den Test danach aus, welche Unsicherheit die nächste Entscheidung wirklich beeinflusst.

Ein MVP ermöglicht einen begrenzten nutzbaren Ablauf

Als MVP verstehen wir hier eine bewusst kleine Anwendung, mit der die vorgesehene Nutzergruppe eine vollständige, eingegrenzte Aufgabe erledigen kann. Welche Betriebsanforderungen dafür gelten, muss im Auftrag zusätzlich beschrieben werden.

«Klein» bedeutet nicht, dass notwendige Zugriffsregeln oder Fehlerbehandlung entfallen. Es bedeutet, dass weniger Aufgaben unterstützt werden. Eine Anwendung für eine Produktgruppe kann sinnvoll begrenzt sein; eine Anwendung ohne geklärte Verantwortung ist dadurch noch nicht einsatzbereit.

Das MVP sollte eine konkrete Nutzungsfrage beantworten: Bringt der Ablauf im Alltag ausreichend Nutzen, wenn Prüfung und Nacharbeit berücksichtigt werden?

Ein fiktiver Fall zur Anfrageklassifikation

Ein Unternehmen erhält Anfragen zu Lieferungen, Reklamationen und anderen Anliegen. Vor einer Umsetzung weiss es nicht, ob die bisherigen Beispiele eine brauchbare Grundlage für eine automatische Kategorieempfehlung bieten.

Der Proof of Concept untersucht eine freigegebene Stichprobe. Fachpersonen legen erwartete Kategorien fest; die Ergebnisse zeigen Fehler und mehrdeutige Fälle. Es werden keine Nachrichten verschoben oder beantwortet.

Ein späteres MVP kann Vorschläge in einer internen Arbeitsliste anzeigen. Eine Person bestätigt oder korrigiert die Kategorie. Der automatische Versand bleibt ausgeschlossen. Damit lässt sich beobachten, ob der unterstützte Ablauf tatsächlich hilfreich ist.

Erst ein weiterer Schritt verbindet diesen Ablauf gegebenenfalls dauerhaft mit dem produktiven Posteingang und ergänzt die dafür vereinbarten Betriebsprüfungen. Die drei Schritte liefern unterschiedliche Nachweise.

Den Auftrag mit einer Entscheidungsfrage schreiben

Verwenden Sie für den ersten Auftrag vier Sätze: «Wir möchten wissen, ob …», «Dafür untersuchen wir …», «Als Ergebnis erhalten wir …» und «Danach entscheiden wir über …».

Ein fiktives Beispiel lautet: «Wir möchten wissen, ob unsere freigegebenen Nachrichten in die vereinbarten Kategorien eingeordnet werden können. Wir untersuchen eine repräsentative Stichprobe mit dokumentierten Sonderfällen. Das Ergebnis ist ein fachlich geprüftes Fehlerbild. Danach entscheiden wir, ob eine interne Vorschlagsliste aufgebaut wird.»

Ergänzen Sie, welche Aussagen der Auftrag ausdrücklich nicht ermöglicht. Eine kleine Stichprobe beweist beispielsweise keine unveränderte Qualität bei jeder zukünftigen Nachricht.

Voraussetzungen vor der Entwicklung prüfen

Auch ein kleiner Versuch braucht passende Daten, eine verantwortliche Fachperson und einen zulässigen Arbeitsrahmen. Fehlt eine notwendige Voraussetzung, kann die erste Leistung ihre Klärung sein.

Das GOV.UK-Handbuch zur Discovery-Phase stellt Problem und Einschränkungen vor die Festlegung auf eine Lösung. Unser KI-Readiness-Check für KMU hilft, diese Voraussetzungen für ein konkretes Vorhaben sichtbar zu machen.

Vermeiden Sie, bereits in der ersten Phase alle später denkbaren Funktionen einzubauen. Jede zusätzliche Funktion kann Aufwand erzeugen, ohne die aktuelle Entscheidungsfrage besser zu beantworten.

Ein negatives Ergebnis verwertbar machen

Definieren Sie vorab, was ein begründetes Nein ausmacht. Vielleicht sind Kategorien fachlich nicht eindeutig, vielleicht fehlen wichtige Daten oder die notwendige Kontrolle ist aufwendiger als der bisherige Ablauf.

Ein solches Ergebnis ist dann brauchbar, wenn Ursachen und Belege dokumentiert sind. Es sollte eine Entscheidung ermöglichen: Aufgabe enger fassen, Daten verbessern, andere Technik prüfen oder vorerst stoppen.

Die nächste Phase bewusst freigeben

Behandeln Sie den Folgeauftrag als neue Entscheidung mit aktualisierten Annahmen. Übernehmen Sie geeignete Ergebnisse und dokumentieren Sie, was noch fehlt. Nicht jeder Testcode muss zum Kern einer späteren Anwendung werden.

Mit einclick als KI-Agentur in der Schweiz können Sie das erste Lieferobjekt so begrenzen, dass es eine echte geschäftliche Frage beantwortet und einen nachvollziehbaren nächsten Schritt ermöglicht.