Pilot-Design: Hypothesen, KPIs, Abbruchkriterien

Lernziele

Sie formulieren eine testbare Pilot-Hypothese im Wenn-dann-Format mit expliziter Zielgröße und Zeithorizont für einen KI-Use-Case.

Sie unterscheiden Leading Indicators von Lagging Indicators und wählen für einen Piloten jeweils einen messbaren Indikator jedes Typs aus.

Sie definieren den Pilotrahmen (Scope, Teilnehmendengruppe, Zeitraum, Systemumgebung) und begründen, warum ein enger Pilot-Scope die Lerngeschwindigkeit erhöht.

Sie formulieren mindestens drei konkrete, nicht interpretationsbedürftige Abbruchkriterien und erklären, warum diese vor Pilot-Start definiert werden müssen.

Sie planen einen gestuften Pilot-Rollout (Early Adopter → Abteilung → Unternehmen) und integrieren Go/No-Go-Gates mit klaren Entscheidungsregeln.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

Stellen Sie sich vor, ein KI-Pilot läuft seit drei Monaten — und niemand ist sicher, ob er erfolgreich ist. Die Nutzungszahlen sind irgendwie „okay”, aber das Qualitätsniveau des KI-Outputs variiert stark. Einige Kolleginnen und Kollegen sind begeistert, andere nutzen das System gar nicht. Die Geschäftsführung fragt nach dem ROI — und niemand hat die Antwort, weil von Anfang an weder klare Erfolgsziele noch Messgrößen definiert wurden.

Dieses Szenario ist kein Ausnahmefall — es ist der Normalfall, wenn KI-Piloten ohne strukturiertes Design gestartet werden. Gutes Pilot-Design schützt die Organisation vor zwei gleichermaßen schädlichen Fehlern: Piloten, die zu früh abgebrochen werden, weil niemand gewartet hat, bis die Lernkurve überwunden ist. Und Piloten, die aus Sunk-Cost-Gründen weiterlaufen, obwohl sie offensichtlich nicht funktionieren.

Lerntext — Theorie und Konzepte

Die Pilot-Hypothese — testbar und präzise

Eine gute Pilot-Hypothese ist eine wenn-dann-Aussage, die falsifizierbar ist — das heißt: sie kann sich als falsch herausstellen, und man würde erkennen, wenn das passiert.

Format: „Wenn wir [KI-Lösung X] für [Nutzergruppe Y] im Prozess [Z] einsetzen, dann [erwartetes Ergebnis] um [Zielgröße] innerhalb von [Zeitraum].”

Schlechtes Beispiel: „Der KI-Assistent wird die Effizienz verbessern.” — nicht falsifizierbar.

Gutes Beispiel: „Wenn wir den RAG-Assistenten für die Meeting-Vorbereitung bei allen Beraterinnen und Beratern einsetzen, dann reduziert sich die Zeit für die Zusammenstellung relevanter Projektinformationen vor Kundenmeetings von durchschnittlich 35 auf unter 12 Minuten innerhalb von sechs Wochen nach Go-Live.”

Pilot-Hypothesen lassen sich in drei Typen unterteilen: Typ 1 — Effektivitäts-Hypothese (Output-Qualität). Typ 2 — Effizienz-Hypothese (Ressourceneinsatz). Typ 3 — Adoptions-Hypothese (Annahme durch Zielgruppe). Für einen vollständigen Piloten empfiehlt sich, alle drei Typen zu formulieren.

Merksatz

Eine Hypothese, die nicht falsifiziert werden kann, ist eine Hoffnung — kein Experiment. Die stärkste Probe für eine gute Hypothese: Wenn das Ergebnis nach sechs Wochen eindeutig entschieden werden kann, ob die Hypothese wahr oder falsch ist, ist sie gut formuliert.

KPI-Typen: Leading vs. Lagging

Leading Indicators (Frühindikatoren) messen Verhaltensänderungen, die dem eigentlichen Ergebnis vorausgehen. Bereits wenige Tage nach Pilot-Start messbar: - Anzahl aktiver Nutzerinnen und Nutzer pro Woche (Adoptionsrate) - Durchschnittliche Anzahl von Assistenten-Anfragen pro aktiver Person - Wöchentliche Zufriedenheits-Kurzumfrage (1–5-Skala) - Anzahl gemeldeter Fehler pro Woche

Lagging Indicators (Ergebnisindikatoren) messen das eigentliche Geschäftsergebnis. Erst nach 4–8 Wochen zuverlässig messbar: - Durchschnittliche Zeit für einen definierten Prozessschritt (in Minuten) - Fehlerrate im Prozess-Output (in %) - Qualitätsbewertung des Outputs durch Endnutzerinnen und -nutzer - Bearbeitungsvolumen pro Person und Woche

Abb. 91.1 — Pilot-Phasen von der Vorbereitung bis zur Go/No-Go-Entscheidung

Pilot-Scope: Enger ist besser

Ein guter Pilot hat einen engen, klar definierten Scope: - Nutzergruppe: 3–8 Personen, freiwillig, technikaffin (Early Adopters) - Prozessbereich: Ein einziger, klar abgegrenzter Prozessschritt - Zeitraum: 4–8 Wochen - Systemumgebung: Falls möglich, eine dedizierte Test-Instanz

Warum eng besser ist: In einem engen Pilot können Abweichungen von der Hypothese eindeutig auf die KI-Lösung zurückgeführt werden. Das beschleunigt das Lernen und erhöht die Qualität der Go/No-Go-Entscheidung.

Abbruchkriterien — der unterschätzte Kernbaustein

Abbruchkriterien müssen vor Pilot-Start definiert sein, weil die Entscheidung zum Abbruch emotionalen und sozialen Widerstand erzeugt, wenn der Pilot erst einmal läuft.

Typische Abbruchkriterien: - Fehlerrate überschreitet X % (konkret: „Wenn mehr als 15 % der KI-Outputs nachweislich falsche Informationen enthalten”) - Aktive Nutzung fällt unter X % nach Y Wochen (konkret: „Wenn nach zwei Wochen weniger als 50 % der Pilotgruppe den Assistenten mindestens dreimal pro Woche nutzen”) - DSGVO-Vorfall (konkret: „Wenn personenbezogene Daten das System unkontrolliert verlassen haben”) - Nutzerzufriedenheit dauerhaft unter X (konkret: „Wenn die wöchentliche Umfrage drei Wochen in Folge unter 2,5 von 5 liegt”)

Wichtig: Abbruchkriterien müssen quantitativ und unmissverständlich formuliert sein. „Zu wenig Akzeptanz” ist kein Abbruchkriterium.

Merksatz

Abbruchkriterien, die erst während des Pilots formuliert werden, sind wertlos — emotionale Sunk-Cost-Verzerrung macht eine rationale Entscheidung unmöglich. Schreiben Sie die Kriterien auf, bevor die erste Person den Assistenten öffnet.

Gestufter Rollout: Early Adopter → Abteilung → Unternehmen

Ein erfolgreicher Pilot endet nicht mit dem Go/No-Go — er endet mit einem klaren Rollout-Plan für die nächste Wachstumsstufe. Drei Rollout-Stufen:

Stufe 1 — Early Adopter (Pilot): 3–8 Personen, freiwillig, technikaffin. Dauer 4–8 Wochen. Zweck: Hypothese testen, Abbruchkriterien prüfen, erste Learnings sammeln.

Stufe 2 — Abteilung: Rollout auf die gesamte erste Abteilung (15–30 Personen) auf Basis der validierten Pilot-Erkenntnisse. Dauer ca. 6–8 Wochen. Anpassungen aus dem Pilot eingebaut, Change-Management-Plan aktiv.

Stufe 3 — Unternehmen: Vollständiger Rollout für alle Zielgruppen. Governance-Handbuch ist gepflegt, Multiplikatoren aktiv, alle Schulungsgruppen abgeschlossen.

Zwischen jeder Stufe gibt es ein formales Go/No-Go-Gate: Sind die KPIs der vorherigen Stufe erreicht? Sind die Abbruchkriterien nicht ausgelöst worden? Wenn ja: weiter. Wenn nein: Analyse, Anpassung, erneuter Mini-Pilot.

Merksatz

Ein Pilot, der direkt zum unternehmensweiten Rollout skaliert, ohne Go/No-Go-Gate, ist kein Pilot — er ist eine unkontrollierte Einführung mit Pilot-Label. Die Gate-Entscheidungen schützen die Organisation und die KI-Initiative.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

Ein mittelständisches IT-Beratungsunternehmen (ca. 80 MA, Projektgeschäft) startet einen Piloten für einen KI-Assistenten zur Meeting-Vorbereitung. Das Pilot-Design: Nutzergruppe sind fünf Berater aus dem Application-Management-Bereich (freiwillig). Pilot-Dauer: sechs Wochen. Hypothese (Effizienz-Typ): „Wenn der Assistent für die Meeting-Vorbereitung genutzt wird, reduziert sich die Vorbereitungszeit von durchschnittlich 35 auf unter 15 Minuten innerhalb von vier Wochen.” Leading Indicator: wöchentliche Nutzungsrate (Ziel: > 80 % in Woche 2). Lagging Indicator: gemessene Vorbereitungszeit (Stoppuhr-Stichproben). Abbruchkriterium: Wenn nach zwei Wochen weniger als drei der fünf Berater den Assistenten mindestens dreimal pro Woche nutzen. Rollout-Planung: Bei Go werden in Q2 alle Berater des Projektbereichs (20 Personen) einbezogen.

Industrie & Fertigung

Ein Maschinenbauunternehmen (ca. 500 MA, Standort Deutschland) testet einen KI-Assistenten für die technische Dokumentation von Serviceeinsätzen. Das Pilot-Design: Nutzergruppe sind vier Servicetechniker einer Niederlassung. Pilot-Dauer: acht Wochen. Hypothese (Effektivitäts-Typ): „Wenn der Assistent die Servicebericht-Erstellung unterstützt, reduzieren sich Tippfehler und fehlende Pflichtfelder um mehr als 60 %.” Leading Indicator: Nutzungsrate pro Einsatztag. Lagging Indicator: Vollständigkeitsquote der Serviceberichte (automatisch messbar via ERP-Pflichtfelder). Abbruchkriterium: Wenn die Fehlerrate höher als im Kontrollzeitraum ohne KI liegt. Besonderheit: Rollout erfolgt Niederlassung für Niederlassung — kein simultaner Gesamtrollout wegen technischer Heterogenität der Außenlager.

Finanzdienstleistung & Versicherung

Ein regionaler Versicherungsdienstleister (ca. 200 MA) pilotiert einen KI-Assistenten für die Vorbereitung von Kundengesprächen (Zusammenfassung der Vertragshistorie aus dem CRM). Pilot-Design: Nutzergruppe sind sechs Kundenberater einer Filiale. Pilot-Dauer: sechs Wochen. Hypothese (Adoptions-Typ): „Wenn der Assistent für alle neuen Kundengespräche genutzt wird, nutzen nach vier Wochen mindestens 80 % der Pilotgruppe den Assistenten täglich.” DSGVO-Besonderheit: Personenbezogene Kundendaten dürfen den Unternehmensperimeter nicht verlassen — der Assistent läuft auf einem Self-Hosted-Modell. Abbruchkriterium: DSGVO-Vorfall (kein Grenzwert — jeder Vorfall löst sofortigen Pilot-Stopp aus). Go/No-Go-Gate vor Filial-Rollout (Stufe 2): monatlich, mit Compliance-Officer im Entscheidungsgremium.

Öffentliche Verwaltung

Eine Stadtverwaltung (ca. 1.200 MA, Bayern) testet einen KI-Assistenten für die Beantwortung interner Mitarbeiterfragen zur Urlaubsregelung und Stellenbeschreibungen (Read-only-RAG auf interne Dokumente). Pilot-Design: Nutzergruppe sind acht Mitarbeitende des Personalamts. Pilot-Dauer: acht Wochen. Hypothese: „Wenn der Assistent intern eingesetzt wird, reduziert sich die Anzahl der Rückfragen an die Personalabteilung um mindestens 30 % innerhalb von sechs Wochen.” Besonderheit öffentliche Verwaltung: Der Betriebsrat / Personalrat wird formell eingebunden (bayerisches Personalvertretungsgesetz, analog § 87 BetrVG). Abbruchkriterium: Wenn mehr als 10 % der Antworten als irreführend oder falsch gemeldet werden. Rollout-Planung: bei Erfolg zuerst auf weitere Ämter, nicht Gesamtstadtverwaltung in einem Schritt.

Vertiefung — Haeufige Fehler beim Pilot-Design und wie sie vermieden werden

Schlecht konzipierte Piloten liefern kein valides Ergebnis — weder ein positives noch ein negatives. Das ist das eigentlich Gefährliche: Man weiß nach dem Pilot genauso wenig wie vorher, weil das Design keine klaren Aussagen erlaubt.

Fehler 1 — Zu grosse Pilotgruppe: Eine Pilotgruppe von 50 Personen klingt repräsentativer als eine mit 8 Personen — ist aber in den ersten Wochen schwerer zu betreuen, führt zu mehr Streuung und macht die Ursachenanalyse bei Problemen deutlich schwieriger. Die optimale Pilotgruppe für einen ersten KI-Piloten liegt bei 5 bis 12 Personen: klein genug für intensive Betreuung, groß genug für valide erste Erkenntnisse.

Fehler 2 — Fehlende Kontrollgruppe: Wenn alle 20 Mitarbeitenden im Piloten das neue Tool nutzen, ist es schwer zu beurteilen, ob die KPIs sich aufgrund des Tools verbessert haben — oder aufgrund anderer Faktoren (Saisonalität, andere Änderungen im Prozess). Eine einfache Kontrollgruppe (5 Personen ohne Tool) oder ein Pre-Post-Design (Messung vor und nach Einführung) schafft Vergleichbarkeit.

Fehler 3 — Abbruchkriterien ohne Zahl: „Wenn die Akzeptanz gering ist” ist kein Abbruchkriterium — es ist eine Absichtserklärung. Ein operationalisierbares Abbruchkriterium lautet: „Wenn nach drei Wochen weniger als 50 % der Pilotgruppe das Tool an mindestens drei Tagen pro Woche aktiv genutzt hat (nutzungsbasiert gemessen via Tool-Logs).” Diese Formulierung lässt sich eindeutig prüfen.

Fehler 4 — Baseline fehlt: Der Pilot soll zeigen, ob sich eine KPI verbessert. Aber verbessert gegenüber was? Wenn die Baseline-Messung (der Ausgangswert vor Pilot-Start) fehlt, kann keine Verbesserung nachgewiesen werden. Die Baseline-Erhebung ist Teil der Pilot-Vorbereitung — nicht des laufenden Piloten.

Fehler 5 — Zu lange Pilot-Phase: Piloten, die sechs Monate laufen, verlieren das Momentum. Nach sechs Wochen haben die meisten Pilotpersonen genug Erfahrung für eine erste valide Einschätzung. Einen acht-Wochen-Pilot zu verlängern, weil man sich nicht sicher ist, ist kein Zeichen von Gründlichkeit — es ist ein Signal, dass die KPIs und Abbruchkriterien nicht klar genug formuliert waren.

Goldene Regel des Pilot-Designs: Ein Pilot, dessen Ergebnis vorab feststeht, ist kein Pilot — es ist eine Inszenierung. Ein echter Pilot ist so konzipiert, dass er scheitern kann. Die Möglichkeit eines negativen Ergebnisses macht das positive Ergebnis glaubwürdig.

Vertiefung — Drei Pilot-Design-Beispiele aus der Praxis

Beispiel 1 — Pilot Wissens-RAG-Assistent in einer Anwaltskanzlei: Hypothese: Wenn Mitarbeitende auf einen RAG-Assistenten mit den letzten 200 Vertragsdokumenten zugreifen können, sinkt die Zeit für die manuelle Dokumentenrecherche von durchschnittlich 22 auf unter 8 Minuten je Vorgang. Pilotgruppe: 6 Junioranwältinnen und Junioranwälte (hohe Dokumentenrecherche-Frequenz, Tech-affin). Pilotdauer: 6 Wochen. KPIs: (1) Durchschnittliche Recherchezeit je Vorgang (Baseline + Woche 6), (2) Anzahl der Systemnutzungen je Person je Woche, (3) Qualitätsbewertung der Antworten durch Senior-Anwältinnen (Skala 1–5, wöchentlich). Abbruchkriterien: (a) Weniger als 40 % der Pilotgruppe nutzen das System nach Woche 3 aktiv. (b) Qualitätsbewertung unter 3,0 im Schnitt nach Woche 4. (c) Datenschutzverletzung (auch geringfügige).

Beispiel 2 — Pilot Meeting-Transkription in einem Beratungshaus: Hypothese: Wenn die automatische Meeting-Transkription und -Zusammenfassung für alle Kundenprojekt-Meetings eingesetzt wird, reduziert sich der Zeitaufwand für Protokollerstellung von 30 auf unter 8 Minuten je Meeting. Pilotgruppe: 8 Projektmanagerinnen und Projektmanager aus zwei verschiedenen Teams. Pilotdauer: 4 Wochen. KPIs: (1) Zeitaufwand für Protokollerstellung je Meeting (Pre-Post), (2) Qualitätsbewertung der automatischen Zusammenfassungen durch Teilnehmende (Skala 1–5), (3) Anzahl der Meetings, bei denen das Protokoll innerhalb von 24 Stunden versandt wurde. Abbruchkriterien: (a) Qualitätsbewertung unter 2,5 nach Woche 2. (b) Technische Ausfälle in mehr als 20 % der Meetings.

Beispiel 3 — Pilot Angebots-KI-Assistent in einem Industrieunternehmen: Hypothese: Wenn ein KI-Assistent den Entwurf für Standardangebote (unter 50.000 Euro) auf Basis des Produkt-Datenblatts und der Kundenhistorie generiert, reduziert sich die Entwurfszeit von 90 auf unter 25 Minuten. Pilotgruppe: 4 Vertriebsmitarbeitende mit mind. 10 Standardangeboten pro Monat. Pilotdauer: 8 Wochen (zwei Monate Angebotszyklus). KPIs: (1) Durchschnittliche Entwurfszeit je Angebot, (2) Überarbeitungsrate (Anteil der KI-Entwürfe, die ohne wesentliche Änderung akzeptiert wurden), (3) Kundenzufriedenheit mit Angebotsqualität (bestehende NPS-Messung). Abbruchkriterien: (a) Überarbeitungsrate unter 30 % nach Woche 4. (b) Kundenbeschwerden über Angebotsqualität in der Pilotgruppe. (c) Mehr als 3 DSGVO-relevante Dateneingaben durch Mitarbeitende trotz Schulung.

Übung 1 — Pilot-Hypothese formulieren

Übung 1 — Pilot-Hypothese im Wenn-dann-Format

Aufgabe: Formulieren Sie für einen KI-Use-Case aus Ihrer Organisation eine vollständige Pilot-Hypothese im Wenn-dann-Format. Ergänzen Sie je einen Leading und einen Lagging Indicator und definieren Sie zwei quantitative Abbruchkriterien.

Schritt-für-Schritt: 1. Wählen Sie einen Use Case, den Sie aus UE 87 kennen oder neu entwickeln. 2. Formulieren Sie die Hypothese: „Wenn wir [Lösung X] für [Gruppe Y] im Prozess [Z] einsetzen, dann [Ergebnis] um [Zielgröße] innerhalb von [Zeitraum].” 3. Bestimmen Sie einen Leading Indicator (bereits in Woche 1–2 messbar). 4. Bestimmen Sie einen Lagging Indicator (erst nach 4–8 Wochen zuverlässig). 5. Formulieren Sie zwei quantitative Abbruchkriterien.

Bearbeitungszeit: 15 Minuten, dann Austausch in Zweiergruppen.

Musterlösung: Hypothese: „Wenn wir den RAG-Assistenten für die Erstellung von Kunden-Zusammenfassungen bei den fünf Beraterinnen im Key-Account-Team einsetzen, dann reduziert sich die Zeit für die Erstellung der Zusammenfassung von 45 auf unter 12 Minuten innerhalb von fünf Wochen nach Go-Live.” Leading Indicator: Wöchentliche Nutzungsrate (Ziel: ≥ 80 % der Berater nutzen den Assistenten in Woche 2 mindestens dreimal). Lagging Indicator: Gemessene Durchschnittszeit für Kundenzusammenfassung (Stoppuhr-Stichproben, 10 Messungen je Woche). Abbruchkriterium 1: Wenn in Woche 3 weniger als 60 % der Pilotgruppe den Assistenten mindestens dreimal pro Woche nutzen. Abbruchkriterium 2: Wenn in Woche 4 mehr als 20 % der KI-Zusammenfassungen vom Berater komplett neu verfasst werden müssen (Qualitätsprüfung per Stichprobe).

Merksatz

Ein Pilot ist ein Lernprojekt, kein Erfolgsprojekt. Das Ziel ist nicht “den Pilot zum Erfolg bringen” — das Ziel ist “so schnell wie möglich lernen, ob und unter welchen Bedingungen der Use Case funktioniert”. Dieser Perspektivwechsel verändert, wie Abbruchkriterien, KPIs und Pilotzeiträume designed werden.

Anwendungshinweis — Die Pre-Mortem-Methode für Piloten

Die Pre-Mortem-Methode (Gary Klein, 1989) ist eine leistungsstarke Ergänzung zum Pilot-Design: Stellen Sie sich vor, der Pilot ist nach sechs Wochen gescheitert. Was ist schiefgelaufen? Diese Vorwärtsprojektion ins Scheitern erzeugt systematisch bessere Risikoidentifikation als die Frage “Was könnte schiefgehen?” — weil sie die kognitive Hemmung überwindet, negative Szenarien zu benennen.

Durchführung (15 Minuten in einer Gruppe): 1. Alle Beteiligten schreiben individuell auf: Wenn der Pilot in sechs Wochen gescheitert ist, was waren die drei Hauptgründe? 2. Antworten werden gesammelt und geclustert. 3. Die häufigsten Scheitern-Szenarien werden in Abbruchkriterien oder Risikomitigationsmaßnahmen übersetzt.

Typisch identifizierte Scheitern-Gründe in KI-Piloten: Pilotgruppe hatte keine Zeit für das Tool (Adoption-Problem), Daten waren nicht wie angenommen zugänglich (Datenproblem), KI-Ausgaben waren zu häufig falsch für produktiven Einsatz (Qualitätsproblem), Datenschutz-Bedenken führten zu Abbruch (Governance-Problem), Management-Interesse ließ nach (Sponsor-Problem).

Übung 2 — Pilot-Scope-Entscheidung

Übung 2 — Pilot-Scope-Entscheidung begründen

Aufgabe: Sie haben einen Use Case mit zwei Scope-Optionen. Option A: Pilot mit 4 Early Adoptern in einer Abteilung, 6 Wochen. Option B: Pilot mit 25 Personen aus drei Abteilungen, 12 Wochen. Welche Option wählen Sie — und warum?

Schritt-für-Schritt: 1. Identifizieren Sie die Vor- und Nachteile beider Optionen. 2. Überlegen Sie: Bei welchem Scope kann die Hypothese eindeutiger getestet werden? 3. Überlegen Sie: Welcher Scope erlaubt schnellere Korrekturen? 4. Formulieren Sie eine Empfehlung mit drei Begründungssätzen.

Bearbeitungszeit: 10 Minuten.

Musterlösung: Option A (enger Scope) ist die richtige Wahl für den ersten Pilot. Begründung 1: Bei 4 Personen können Abweichungen von der Hypothese eindeutig auf die KI-Lösung zurückgeführt werden — bei 25 Personen aus drei Abteilungen gibt es zu viele Störvariablen (unterschiedliche Nutzungsgewohnheiten, verschiedene Prozess-Kontexte). Begründung 2: Wenn Abbruchkriterien in Woche 3 ausgelöst werden, ist der Schaden bei 4 Pilotnutzenden minimal — organisatorisch, politisch und ressourcentechnisch. Begründung 3: Der enge Pilot liefert in 6 Wochen belastbare Erkenntnisse — Option B braucht 12 Wochen für das gleiche Lernziel, bietet aber keine höhere Erkenntnisqualität in der ersten Runde.

Cheatsheet — Pilot-Design: Die wichtigsten Punkte

Hypothesen-Format: Wenn [Lösung X] für [Gruppe Y] in [Prozess Z], dann [Ergebnis] um [Zielgröße] in [Zeitraum].

Drei Hypothesen-Typen: - Typ 1 — Effektivität: Qualität des Outputs - Typ 2 — Effizienz: Ressourceneinsatz / Zeit - Typ 3 — Adoption: Nutzungsrate der Zielgruppe

Pilot-Scope: 3–8 Personen / ein Prozessschritt / 4–8 Wochen / enger Scope = bessere Erkenntnisse

KPI-Typen: - Leading (ab Woche 1): Nutzungsrate, Umfragezufriedenheit, Fehleranzahl - Lagging (ab Woche 4–8): Prozesszeit, Qualitätsquote, Bearbeitungsvolumen

Abbruchkriterien müssen: - Quantitativ sein (Prozentzahl, Schwellenwert) - Vor Pilot-Start fixiert sein - Automatisch auslösen (ohne Interpretationsspielraum)

Drei Rollout-Stufen: Early Adopter → Abteilung → Unternehmen, je mit Go/No-Go-Gate

Reflexionsfragen

Welche ADKAR-Stufe ist für Ihre Organisation vermutlich die kritischste — und wie beeinflusst das Ihr Pilot-Design?

Was passiert konkret, wenn das erste Abbruchkriterium in Woche 3 ausgelöst wird — wer trifft die Entscheidung, und nach welchem Prozess?

Wie verhindert ein enger Pilot-Scope, dass die Ergebnisse von Faktoren beeinflusst werden, die nichts mit der KI-Lösung zu tun haben?

Welche Gefahr birgt es, wenn Leading Indicators und Lagging Indicators beide erst nach acht Wochen messbar sind?

Prompt-Vorlage — Pilot-Design für einen KI-Use-Case vollständig entwerfen

Prompt für einen KI-Assistenten:

Ich möchte einen strukturierten KI-Piloten entwerfen. Use Case: [Use Case beschreiben]. Haupthypothese: Wenn [KI-Intervention] eingesetzt wird, dann [erwartetes messbares Ergebnis] in [Zeitraum] bei [Pilotgruppe]. Konkretisiere das Pilot-Design mit folgenden Elementen: (1) Drei messbare KPIs (Erfolgskennzahlen mit Zielwerten), (2) Drei quantitative Abbruchkriterien (Wann sollte der Pilot gestoppt werden?), (3) Empfohlene Pilotgruppe (Größe, Auswahlkriterien), (4) Realistische Pilotdauer (4–8 Wochen) mit Meilensteinplan, (5) Drei Risiken mit je einer konkreten Mitigationsmaßnahme, (6) Benötigte Ressourcen (Personentage, Lizenzkosten, IT-Aufwand).”

Erwartetes Ergebnis: Ein vollständiges Pilot-Design-Dokument mit Hypothese, KPIs, Abbruchkriterien, Meilensteinplan und Risikoanalyse — direkt als Vorlage für die Freigabe-Präsentation verwendbar. Hinweis: Abbruchkriterien müssen quantitativ formuliert sein: nicht wenn die Akzeptanz gering ist, sondern wenn weniger als 50 Prozent der Pilotgruppe das Tool nach zwei Wochen täglich nutzen.

Quellen & Weiterlesen

Trainer-Hinweise

Übung 3 — KPI-Operationalisierung: Vom Wunsch zur Messung

Übung 3 — KPI-Operationalisierung

Aufgabe: Überprüfen Sie die KPIs Ihres Pilot-Designs aus Übung 1 und operationalisieren Sie sie vollständig — von der Idee bis zur Messmethode.

Hintergrund: Ein KPI ist erst dann wirklich messbar, wenn die Messmethode geklärt ist: Wer misst? Wann wird gemessen? Welches Werkzeug wird für die Messung genutzt? Ohne diese Klärung bleiben KPIs Absichtserklärungen.

Schritt-für-Schritt: 1. Nehmen Sie Ihre drei KPIs aus Übung 1. 2. Füllen Sie für jeden KPI eine Operationalisierungstabelle aus: KPI-Name | Ausgangswert (Baseline, vor Pilot) | Zielwert (nach Pilot) | Messmethode (wie wird gemessen?) | Messfrequenz (täglich / wöchentlich / am Ende) | Verantwortliche Person. 3. Identifizieren Sie für jeden KPI einen potenziellen Messbarkeits-Stolperstein (Was könnte die Messung erschweren oder verfälschen?). 4. Formulieren Sie für jeden Stolperstein eine Gegenmaßnahme.

Erwartetes Ergebnis: Eine vollständig operationalisierte KPI-Tabelle für alle drei Piloten-KPIs — direkt als Mess-Protokoll für den Piloten verwendbar.

Hinweise für AI Champions — So vermitteln Sie das Thema — UE 91

Timing (45 Min): 12 Min Input Pilot-Hypothese + KPI-Typen, 5 Min Abbruchkriterien (interaktive Diskussion), 8 Min Rollout-Konzept, 15 Min Übung 1 + Austausch, 5 Min Reflexion und Übergang.

Methodische Empfehlung: Starten Sie mit dem „Schlechtes Beispiel”-Satz aus dem Lerntext: „Der KI-Assistent wird die Effizienz verbessern.” — Fragen Sie die Gruppe: Was ist daran schlecht? Die Antworten der Gruppe führen organisch zum Wenn-dann-Format. Lassen Sie die Gruppe die Hypothese entwickeln, bevor Sie das Format vorgeben.

Häufige Stolpersteine: Teilnehmende formulieren Hypothesen ohne Zeitangabe oder ohne Zielgröße. Insistieren Sie: Eine Hypothese ohne „um X % innerhalb von Y Wochen” ist keine testbare Hypothese. Abbruchkriterien werden zu weich formuliert: „wenn die Nutzung zu gering ist” ist kein Kriterium — auf die Zahl drängen.

Diskussionsfragen für Plenum: „Was passiert, wenn Ihr Pilot nach vier Wochen alle KPIs erreicht, aber die Geschäftsführung trotzdem den Rollout stoppen will — weil Budget fehlt?” (Antwort: Dann haben Sie das Governance-Problem, das durch den Business Case aus UE 95 adressiert wird.) „Was ist das Risiko, wenn man keine Abbruchkriterien hat?” (Antwort: Sunk-Cost-Verzerrung und politischer Druck, einen Pilot trotz schlechter Ergebnisse weiterlaufen zu lassen.)

Tafelbild-Vorschlag: Zwei Spalten: Links „Schlechte Hypothese” vs. rechts „Gute Hypothese”. Drei Beispiele je Spalte aus verschiedenen Branchen. Darunter: Leading vs. Lagging — zwei Zeilen mit je 2–3 Beispiel-KPIs.

Differenzierung Power-User ↔ Einsteiger: Einsteiger: Fokus auf Hypothesen-Format und einen KPI-Typ. Power-User: Statistisches Signifikanzproblem bei kleinen Pilotgruppen (n=5 reicht nicht für statistische Signifikanz — aber Pilot zielt auf Plausibilisierung, nicht auf Beweis).

Materialliste: Pilot-Design-Vorlage (Hypothese + KPIs + Abbruchkriterien + Rollout-Plan), A3-Vorlage für Tafelbild, ggf. Stoppuhr-Protokoll-Template für Lagging-Messung.

Übergang zur nächsten UE: „Ihr Pilot hat die Abbruchkriterien nicht ausgelöst — Go-Entscheidung. Jetzt kommen die 70 % der Menschen, die den Assistenten noch nicht kennen. Was passiert, wenn diese nicht mitmachen wollen? Genau das ist das Thema von UE 92: Change Management.”

Tipp zur Branchenauswahl: Bei Fertigungskunden ist das Abbruchkriterium zur Fehlerrate besonders wichtig — Dokumentationsfehler haben dort direkte Qualitäts- und Haftungskonsequenzen. Bei IT-Dienstleistern ist das Adoptions-Abbruchkriterium oft das kritischste — Berater können das Tool schlicht ignorieren, wenn sie nicht überzeugt sind.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.