AI-Pilotprojekte: Einen Proof of Value in 30 bis 90 Tagen anlegen

Ein AI Proof of Value ist ein zeitlich begrenztes Experiment, üblicherweise 30 bis 90 Tage, das eine einzige Entscheidung herbeiführen soll: ob ein System in Produktion geht. Er unterscheidet sich vom Proof of Concept in dem, was er belegen muss. Ein Proof of Concept zeigt, dass die Technik funktionieren kann. Ein Proof of Value zeigt, dass die Technik eine Kennzahl bewegt, die das Unternehmen ohnehin verfolgt, unter den Bedingungen, unter denen das Unternehmen tatsächlich arbeitet, zu einem Aufwand, den jemand zu tragen bereit ist. Das erste ist eine Demo. Das zweite ist ein Beleg.

In der Lücke zwischen beidem verschwinden die meisten KI-Budgets still und leise. Ein Pilot endet, alle finden ihn interessant, und nichts ändert sich. Das ist selten ein technisches Versagen. Es ist ein Konstruktionsfehler, und er ist fast immer schon am ersten Tag zu erkennen, wenn man weiß, worauf zu achten ist. In diesem Artikel geht es darum, den Piloten so anzulegen, dass am Ende eine Entscheidung steht und keine Präsentation.

Was ist Prototypentheater und woran erkennen Sie es?

Prototypentheater ist ein Pilot, der nicht scheitern kann. Er läuft auf einem handverlesenen Datenausschnitt, wird von denen bewertet, die ihn gebaut haben, und an einem Maßstab gemessen, den niemand vorher aufgeschrieben hat. Am Ende wird er zum Erfolg erklärt, weil es keine Erfolgsdefinition gab, die zu einer anderen Antwort fähig gewesen wäre.

Erkennbar ist das nicht an der Qualität der Demo. Prototypentheater sieht in der Regel hervorragend aus, das ist ja sein Zweck. Die Anzeichen sind struktureller Natur, und es sind vier:

• Kein vorab vereinbarter Schwellenwert. Wenn niemand die Zahl aufgeschrieben hat, die eine Produktionsentscheidung auslösen würde, wird das Ergebnis im Nachhinein von demjenigen ausgelegt, der die festeste Meinung hat.
• Keine Baseline. Der Pilot meldet, das Modell sei zu 91% genau. Niemand hat gemessen, was der bestehende Prozess leistet, also steht diese Zahl ohne Bezug da. Sie kann eine deutliche Verbesserung sein oder ein spürbarer Rückschritt.
• Von Hand zusammengestellte Daten. Jemand in der IT hat einen einmaligen Export für den Piloten erzeugt. Der Pilot belegt, dass sich auf diesem Export ein Modell trainieren lässt. Er belegt nichts darüber, ob die Daten an einem Dienstag zu bekommen sind, an jedem Dienstag, im Produktivbetrieb.
• Kein benannter Verantwortlicher für danach. Wenn niemand dafür geradesteht, das System im vierten Monat zu betreiben, ist der Pilot von Beginn an eine Waise, wie immer seine Ergebnisse ausfallen.

Alle vier Punkte sind vor dem Start günstig zu beheben und danach gar nicht mehr. Dieses Missverhältnis ist das ganze Argument dafür, Piloten bewusst zu entwerfen.

Was muss vor dem Start des Piloten schriftlich festliegen?

Drei Dinge, auf einer Seite, freigegeben von der Person, die über das Produktionsbudget entscheidet. Wenn Sie diese Seite nicht erstellen können, sind Sie nicht startbereit, und die Zeit für ihre Erstellung ist kein Verwaltungsaufwand. Sie ist der günstigste Teil des Projekts.

Die Entscheidung, der der Pilot dient

Formulieren Sie sie als Bedingung: Zeigt der Pilot X, tun wir Y; zeigt er es nicht, tun wir Z. Prüfen Sie dann, ob Y und Z sich wirklich unterscheiden. Überraschend oft tun sie das nicht. Lautet die Antwort "wir würden es ohnehin bauen" oder "wir würden so oder so weiter erkunden", dient der Pilot keiner Entscheidung, und sein Budget gehört woandershin.

Damit ist auch der Umfang geklärt. Ein Pilot muss die Unsicherheit nur so weit verringern, dass sich diese eine Entscheidung sicher treffen lässt. Er muss nicht jeden Sonderfall abdecken, nicht jede Produktlinie erfassen und nicht fertig aussehen. Ausufernder Umfang bei Piloten bedeutet fast immer, dass jemand stillschweigend eine andere, größere Entscheidung untergeschoben hat.

Die Erfolgskennzahl und ihr Schwellenwert

Die Kennzahl muss etwas sein, das das Unternehmen bereits misst oder ohne ein neues Reportingprojekt messen könnte: Ausschussquote, Stunden je Vorgang, Erstlösungsquote, Außenstandsdauer, Durchsatz je Schicht. Modellkennzahlen wie F1, Precision und Recall sind Messinstrumente. Sie sagen Ihren Entwicklern, ob das Modell funktioniert. Sie sagen Ihrem Sponsor nicht, ob er in Produktion gehen soll.

Der Schwellenwert ist die schwierigere Hälfte, und er entsteht aus einer sehr konkreten Frage an den Sponsor: Welches Ergebnis würde Sie ohne weitere Diskussion zum Rollout bewegen? Schreiben Sie diese Zahl auf, bevor Sie irgendein Ergebnis sehen. Ein im Nachhinein vereinbarter Schwellenwert ist kein Schwellenwert, sondern eine Rechtfertigung. Wie sich solche Zahlen ehrlich halten lassen, samt Baseline und Zurechnung, haben wir in der Validierung von KI-ROI vor dem Bauen durchgearbeitet.

Messen Sie zuerst die Baseline, mit derselben Definition, die Sie am Ende verwenden werden. Das klingt selbstverständlich und wird ständig übersprungen. Wurde der bestehende Prozess nie gemessen, ist seine Messung die erste Woche des Piloten und kein nachgelagerter Gedanke.

Die Abbruchkriterien

Abbruchkriterien sind das Spiegelbild des Erfolgsschwellenwerts, und sie sind der Teil, gegen den sich Teams sträuben. Sie sollen benennen, welches Ergebnis oder welche Erkenntnis das Projekt vorzeitig beendet. Brauchbare Kriterien sind konkret: Die Daten sind im Produktivbetrieb nicht zugänglich, ohne dass eine neue Schnittstelle finanziert wird; das Modell erreicht den Schwellenwert auch unter wohlwollenden Annahmen nicht; die Prozessänderung erfordert Personal, das es nicht gibt; das Latenzbudget lässt sich auf der verfügbaren Infrastruktur nicht einhalten.

Benennen Sie, wer den Abbruch aussprechen darf, und legen Sie ein Datum für die Prüfung fest. Ein Abbruchkriterium, das niemand auslösen darf, ist Dekoration. Es geht nicht um Pessimismus, sondern darum, dass ein in Woche fünf gestoppter Pilot einen Bruchteil dessen kostet, was ein Pilot kostet, der sich bis Woche zwölf schleppt und dann still eingemottet wird. Ein früher Abbruch ist der Pilot, der korrekt arbeitet, und genau so sollte er dem Team vorab beschrieben werden, damit niemand ihn als Misserfolg liest.

Wie schneiden Sie 30, 60 oder 90 Tage zu?

Die Dauer sollte sich aus dem ergeben, was unsicher ist, nicht aus einer Kalendervorliebe. Drei Zuschnitte decken die meisten Fälle ab.

Etwa 30 Tage

Passend, wenn die Daten bereits in einem abfragbaren System liegen, die Aufgabe nahe an einem gelösten Problem liegt und eine einzige entscheidungsbefugte Person das Ergebnis verantwortet. Typischer Zuschnitt: Baseline messen, ein fertiges oder leicht angepasstes Modell gegen einen zurückgehaltenen Satz echter Fälle bewerten und die Ausgabe denjenigen vorlegen, die sie nutzen würden. Das Ergebnis ist ein Ja oder Nein zu einer eng gefassten Frage. Dreißig Tage reichen nicht aus, um Produktionsreife zu belegen, und ein 30-Tage-Pilot sollte das auch nicht behaupten.

Etwa 60 Tage

Der Normalfall. Genug, um das Obige zu tun und das System an einen echten Arbeitsablauf anzubinden, mit echten Nutzern, für einige Wochen im Livebetrieb. Das ist das kürzeste Fenster, das Belege über die Akzeptanz liefert, und die ist meist die bindende Beschränkung. Ein Modell, das niemand nutzt, hat eine effektive Genauigkeit von null, und das lässt sich aus einer Offline-Bewertung nicht erfahren.

Etwa 90 Tage

Angebracht, wenn erst Datenwege gebaut werden müssen, bevor sich überhaupt etwas bewerten lässt, wenn das Umfeld reguliert ist und der Entwurf von Aufsicht und Dokumentation selbst Teil des Erprobten ist, oder wenn mehrere Interessengruppen sich einigen müssen. Neunzig Tage sind auch der richtige Zuschnitt, wenn die ehrliche Antwort auf "kommen wir verlässlich an diese Daten?" lautet: "wir glauben schon". Im ersten Monat eines 90-Tage-Piloten herauszufinden, dass die Antwort Nein lautet, ist ein gutes Ergebnis. Es im siebten Monat eines Entwicklungsprojekts herauszufinden, nicht.

Jenseits von 90 Tagen pilotieren Sie nicht mehr. Sie bauen, ohne sich dafür entschieden zu haben, und das ist ein Steuerungsproblem und kein Terminproblem.

Welche Datenreife braucht ein Pilot wirklich?

Weniger als befürchtet für das Modell, mehr als erwartet für die Datenstrecke. Ein Pilot braucht selten das gesamte historische Archiv. Er braucht genügend repräsentative Beispiele für eine ehrliche Bewertung, und er braucht den Nachweis, dass sich die Daten wiederholt beschaffen lassen.

Das sind zwei verschiedene Fragen, und Piloten beantworten routinemäßig nur die erste. Der praktische Test lautet, ob die Daten des Piloten über einen Weg kamen, der Bestand haben könnte: eine echte Abfrage gegen ein echtes System, mehr als einmal ausgeführt, von jemandem, der nicht die eine Person ist, die weiß, wie es geht. Lautet die Antwort "eine Tabelle, die eine Kollegin im März exportiert hat", hat der Pilot die Datenreife überhaupt nicht geprüft. Machen Sie das erneute Ausführen des Exports zu einer ausdrücklichen Aufgabe in Woche eins und behandeln Sie ein Scheitern dort als Befund, nicht als Ärgernis. Unsere Bewertung der Dateninfrastruktur geht tiefer darauf ein, was eine Quelle wirklich erreichbar macht.

Repräsentativität zählt mehr als Menge. Tausend Fälle, die Ihre echte Streuung abbilden, über Standorte, Schichten, Produktlinien, Jahreszeiten und die unangenehmen Ausnahmen hinweg, sagen mehr aus als hunderttausend Datensätze aus einem sauberen Quartal. Ziehen Sie Ihre Stichprobe gezielt für die Bedingungen, unter denen Sie ein Versagen erwarten, und halten Sie einen Satz zurück, den bis zum Schluss niemand ansieht.

Labels sind der übliche Engpass. Braucht die Aufgabe eine Ground Truth, die es noch nicht gibt, ist das Labeln ein echter Posten mit echter Expertenzeit und gehört in den Plan, statt still von demjenigen aufgefangen zu werden, der am hilfsbereitesten ist.

Welche Einsatzbedingungen müssen während des Piloten geprüft werden?

Diejenigen, die einen Rollout verhindern könnten. Das darf man deutlich sagen: Ein Pilot, der in einem Notebook auf dem Laptop einer Entwicklerin läuft, hat ein Modell belegt, kein System, und im Abstand zwischen beidem sterben Projekte. Prüfen Sie diese Punkte innerhalb des Pilotfensters, und sei es grob:

• Wo es laufen wird und wer es betreut. Cloud, on-premise, an der Edge, innerhalb einer bestehenden Anwendung. Jede Variante zieht andere Sicherheitsprüfungen, Kosten und Betreuungsfolgen nach sich, und die Prüfschlange ist oft länger als der Pilot.
• Das Budget für Latenz und Durchsatz. Eine Antwort, die acht Sekunden braucht, mag für einen Stapellauf genügen und am Arbeitsplatz unbrauchbar sein. Leiten Sie die echte Anforderung aus dem Arbeitsablauf ab, nicht aus einer Vermutung.
• Die Anbindungsfläche. In welchem System landet die Ausgabe? Muss ein Mensch ein Ergebnis von einem Bildschirm in einen anderen übertragen, sinkt die Nutzung unabhängig von der Qualität gegen null.
• Sicherheit, Datenschutz und Datenhaltung. Wohin die Daten fließen dürfen, welche Anbieter zulässig sind, wie die DSGVO-Position aussieht. Beginnen Sie dieses Gespräch in Woche eins; es ist häufig der längste Weg und vollständig vorhersehbar.
• Der Fehlerpfad. Was geschieht, wenn das System nicht verfügbar oder unsicher ist. Gibt es keinen definierten Rückfall, wurde der Pilot nicht für den Produktivbetrieb entworfen.

Nichts davon muss während eines Piloten sauber ausgebaut werden. Alles davon muss angetastet werden, damit die Kosten für den sauberen Ausbau in der Abschlussempfehlung eine bekannte Zahl sind und keine Überraschung im fünften Monat. Mehrere der wiederkehrenden Integrationsfehler sind in fünf Fehlern bei der KI-Integration zusammengetragen.

Wer muss sich einig sein, und worüber?

Fünf Rollen, und der Pilot sollte mit keiner unbesetzten starten.

• Der Sponsor verfügt über das Produktionsbudget und verantwortet die Entscheidung. Er muss dem Schwellenwert persönlich zustimmen. Wer den Schwellenwert delegiert, hat das Ergebnis delegiert.
• Der Prozessverantwortliche führt den Arbeitsablauf, der sich ändert. Er kennt die Ausnahmen, die Ihre Annahmen zerlegen werden, und kann still dafür sorgen, dass der Pilot nie echte Arbeit berührt, wenn er nicht einbezogen wurde.
• Der Datenverantwortliche kann Zugriff gewähren. Finden Sie ihn in Woche eins, denn Beschaffungs- und Freigabewege lassen sich nicht zusammenstauchen.
• Die Anwender müssen das Ding benutzen. Beziehen Sie einige früh ein und lassen Sie sie skeptisch sein; Skepsis während eines Piloten ist Information, Skepsis nach dem Rollout ist Widerstand.
• Der spätere Verantwortliche betreibt das System im sechsten Monat, überwacht es und entscheidet, wann es neu trainiert werden muss. Gibt es diese Person nicht, ist das der Befund, und er wiegt schwerer als jede Modellkennzahl.

Worauf es bei der Abstimmung ankommt, ist nicht Begeisterung, sondern Einigkeit über Schwellenwert und Abbruchkriterien. Begeisterung ist beim Kickoff reichlich vorhanden und beim Review unzuverlässig. Ein unterzeichneter Schwellenwert übersteht jene Sitzung, in der die Ergebnisse sich als mehrdeutig erweisen, und diese Sitzung entscheidet darüber, ob der Pilot etwas bewirkt hat.

Was sollte ein Proof of Value liefern?

Eine Entscheidung und die Belege dafür. Konkret fünf Ergebnisse:

• Das gemessene Ergebnis gegen die Baseline, auf zurückgehaltenen echten Fällen, mit erneut genanntem Schwellenwert und der Feststellung, ob er erreicht wurde. Ohne Adjektive.
• Eine ehrliche Aufstellung dessen, was gebrochen ist, einschließlich Datenlücken, Reibung bei der Anbindung und Fällen, die das System schlecht behandelt hat. Der Nutzen dieses Abschnitts wächst mit seiner Unbequemlichkeit.
• Eine Schätzung der Kosten bis zur Produktion, die Bau, Anbindung und den laufenden Betrieb samt Pflege umfasst, also jene Zahl, die in Businesscases am häufigsten fehlt. Die Lebenszyklusbetrachtung behandelt die ROI-Berechnung für Machine-Learning-Projekte.
• Eine Empfehlung mit einer echten Abbruchoption. Weitermachen, mit verengtem Umfang weitermachen, nach einer bestimmten Voraussetzung erneut prüfen, oder aufhören. Ein Pilotprozess, der noch nie einen Abbruch empfohlen hat, ist kein Pilotprozess.
• Die wiederverwendbaren Bausteine, also die Evaluationsumgebung, der gelabelte Satz und der dokumentierte Datenweg. Sie überdauern die Entscheidung und machen den nächsten Piloten günstiger, selbst wenn dieser hier endet.

Wann ist ein Pilot das falsche Instrument?

In vier Fällen, und diese zu erkennen spart mehr Geld als alles andere hier.

Wenn die Antwort schon feststeht. Ist das Vorgehen für Ihre exakte Aufgabe gut etabliert und lautet die eigentliche Frage nach den Anbindungskosten, brauchen Sie einen Umsetzungsplan und kein Experiment.

Wenn die Beschränkung organisatorisch ist. Ist der Prozess undefiniert, die Zuständigkeit umstritten oder sind die Daten aus politischen statt technischen Gründen unerreichbar, wird ein Pilot das teuer zutage fördern. Ein AI Readiness Audit fördert es in einem Bruchteil der Zeit zutage, weshalb das Audit in der Abfolge vor dem Piloten steht und nicht danach. Das größere Fehlermuster und die Prüfpunkte, die es abfangen, stehen in wie Sie das Scheitern von KI-Projekten vermeiden.

Wenn es keine Baseline gibt und keine Bereitschaft, eine zu erheben. Ohne ein Vorher gibt es kein Nachher, und der Pilot endet in einem Streit über Auslegung.

Wenn niemand das Ergebnis verantworten wird. Das gehört dem Sponsor vor dem Start deutlich gesagt, denn es ist die eine Bedingung, die Verschwendung garantiert, wie gut der Pilot auch ausgeführt wird.

Die ehrliche Zusammenfassung

Ein guter Pilot ist eine kleine, gut instrumentierte Beweisführung. Er benennt die Entscheidung, der er dient, misst gegen eine Baseline, die vor ihm existierte, hält sich an einen Schwellenwert, den jemand unterschrieben hat, prüft die Bedingungen, die einen Rollout wirklich blockieren könnten, und darf vorzeitig enden. Nichts davon ist technisch anspruchsvoll. Alles davon ist organisatorisch unbequem, weshalb es übersprungen wird und weshalb dieses Überspringen der zuverlässigste Vorbote eines Piloten ist, der Bewunderung erzeugt und keine Veränderung.

Wenn Sie überlegen, wo Sie anfangen, ist die Abfolge, die funktioniert, meist dieselbe: zuerst den Businesscase validieren, dann einen eng gefassten Proof of Value gegen einen Schwellenwert fahren, und sobald etwas in Produktion ist und dauerhaft betreut werden muss, erfahrene Hände darauf setzen. So sind unsere Service-Pakete geschnitten, vom Readiness Assessment bis zum abgegrenzten Proof of Concept, und deshalb ist ein Fractional AI Lead der Schritt nach einem erfolgreichen Piloten und kein Ersatz dafür. Das Audit sagt Ihnen, was zu bauen ist, der Pilot sagt Ihnen, ob es funktioniert, und die Verantwortung entscheidet, ob es Bestand hat.

Häufige Fragen

Wie viele Daten braucht ein KI-Pilot?

Weniger, als die meisten Teams annehmen. Ein Pilot braucht genügend repräsentative Fälle für eine ehrliche Bewertung, meist Hunderte statt Millionen, plus den Nachweis, dass dieselben Daten erneut zu beschaffen sind. Tausend Fälle über Ihre echte Streuung schlagen hunderttausend aus einem sauberen Quartal.

Kann ein Pilot laufen, ohne das Produktivsystem anzufassen?

Ja, und beim ersten Piloten sollte er das meist. Lassen Sie das Modell parallel zum bestehenden Prozess laufen und vergleichen Sie die Ausgaben, statt etwas zu ersetzen. Sie lernen trotzdem Genauigkeit und Akzeptanz und vermeiden das Change Management, das einen gescheiterten Piloten teuer macht.

Wer sollte den Piloten durchführen, ein internes Team oder ein externer Partner?

Wer ihn im Zeitfenster abschließen kann. Interne Teams kennen die Daten und die Ausnahmen, externe bringen die Bewertungsdisziplin und werden nicht vom Tagesgeschäft abgelenkt. Entscheidend ist, wer das System danach verantwortet, denn diese Person sollte in jedem Fall beteiligt sein.

Was, wenn der Pilot gelingt, aber niemand ausrollen will?

Dann zeigt sich ein Zuschnittfehler spät. Entweder war die Entscheidung nie wirklich offen, oder der budgetverantwortliche Sponsor hat dem Schwellenwert nicht zugestimmt. Beides lässt sich vor dem nächsten Piloten beheben, indem die bedingte Entscheidung schriftlich festgehalten und vom Sponsor unterzeichnet wird.