Drei Annahmen vernichten die meisten vertikalen KI-Projekte vor dem dritten Monat. Keine von ihnen wird überprüft, bevor die Architektur gewählt, das Engineering begonnen und das Budget freigegeben wurde.
Die erste Annahme: Die Daten existieren und sind sauber genug für den Einsatz. Die zweite: Der Prozess ist stabil genug für die Automatisierung. Die dritte: Es gibt einen Entscheidungsverantwortlichen, der auf KI-Output handeln wird. Alle drei sind häufig falsch. Die Kosten, im achten Monat herauszufinden, dass sie falsch sind, sind nicht dieselben wie im zweiten Monat.
Ein Discovery-Sprint ist der Mechanismus, um diese Annahmen zu validieren oder zu widerlegen, bevor sie teuer werden. Er kostet vier Wochen strukturierter Arbeit. Er spart den Rest.
Die drei Annahmen, die vertikale KI-Projekte töten
Daten existieren und sind zugänglich. Die meisten Enterprise-Daten sind siloisiert, inkonsistent, undokumentiert oder zugangsbeschränkt auf Weisen, die den beabsichtigten Anwendungsfall blockieren. Der Datensatz, der im Kick-off-Meeting als “leicht verfügbar” beschrieben wurde, erfordert die Genehmigung von drei Abteilungen, die Extraktion aus einem System ohne dokumentierte API und Bereinigungsarbeit, die auf zwei Wochen geschätzt wurde und vier Monate dauert.
Das KI-System, das um diese Daten herum konzipiert wurde, kann nicht wie geplant gebaut werden. Die Optionen im sechsten Monat sind: die Datenpipeline neu aufbauen (was den Zeitplan ändert), den Umfang reduzieren (was den Wert ändert) oder abbrechen. Alle drei sind teurer als ein zweiwöchiges Dateninventar in der Discovery-Phase.
Der Prozess ist stabil genug für die Automatisierung. Der dokumentierte Prozess und der praktizierte Prozess unterscheiden sich. Sie unterscheiden sich in jeder Organisation, die länger als fünf Jahre existiert. Das KI-System, das auf dokumentierten Verfahren trainiert wurde, trifft auf reale Operatoren, die Workarounds, informelle Taxonomien und Ausnahmebehandlungen entwickelt haben, die nirgendwo schriftlich existieren.
Das Ergebnis ist ein System, das in kontrollierten Tests gut funktioniert und in den Händen tatsächlicher Nutzer versagt. Nicht weil das Modell falsch ist. Weil das Modell auf einem Prozess trainiert wurde, dem die Nutzer nicht folgen.
Es gibt einen Entscheidungsverantwortlichen, der auf KI-Output handeln wird. Ein KI-System ohne Entscheidungsverantwortlichen ist ein Forschungsprojekt. Das System kann hervorragende Empfehlungen produzieren, und nichts ändert sich, weil niemand befähigt oder verantwortlich ist, darauf zu handeln. Ghost-Deployments häufen sich in Unternehmen auf diese Weise an: Systeme, die guten Output erzeugt haben, den niemand strukturell nutzen konnte.
Was ein Discovery-Sprint tatsächlich produziert
Ein Discovery-Sprint produziert keine Slideware-Roadmap mit Phasen und Meilensteinen. Er produziert eine Reihe validierter oder widerlegter Hypothesen über einen spezifischen Anwendungsfall.
Die fünf Outputs sind konkrete Lieferergebnisse, keine Analysen:
Prozesskarte. Was tatsächlich geschieht, dokumentiert aus der Beobachtung, nicht aus der Prozessdokumentation. Das schließt Ausnahmen, Workarounds und undokumentierte Ermessensentscheidungen ein. Sie wird durch Gespräche mit den tatsächlichen Operatoren aufgebaut, nicht mit den Prozessverantwortlichen.
Dateninventar. Was existiert, wo es sich befindet, wer den Zugang kontrolliert, welche Qualitätsprobleme vorhanden sind und welche Transformationen erforderlich wären, um es nutzbar zu machen. Jede Datenannahme wird gegen die Realität getestet, nicht gegen das, was jemand für wahr hält.
Karte der Entscheidungsverantwortlichen. Für jeden vorgeschlagenen KI-Output: Wer trifft diese Entscheidung heute, wer wird sie nach der Einführung von KI treffen, wer ist verantwortlich, wenn die KI falsch liegt, und was ist der Eskalationspfad für Outputs mit geringem Vertrauen. Das ist ein People- und Governance-Lieferergebnis, kein technisches.
Wertschätzung. Was kostet das Problem heute in Mitarbeiterstunden, Fehlern, verpassten Chancen oder externen Dienstleistungen? Das ist die Grundlage für ein realistisches ROI-Gespräch und eine Realitätsprüfung, ob der Anwendungsfall die Investition wert ist.
Risikoinventar. Regulatorische Einschränkungen, Datenschutzanforderungen, Integrationskomplexität, Rollback-Anforderungen und die Fehlermodi, die vor dem Deployment behandelt werden müssen.
Die Sprint-Dauer beträgt typischerweise zwei bis vier Wochen. Sie erfordert Domänenexpertise, einen KI-Architekten, der Ergebnisse in Systemanforderungen übersetzen kann, und Zugang zu den Entscheidungsträgern, die den Prozess verantworten. Sie kann nicht vollständig an die IT delegiert werden.
Der Daten-Realitätscheck
Die häufigste Discovery-Erkenntnis: Die Daten, die den beabsichtigten Anwendungsfall antreiben sollen, existieren nicht in verwendbarer Form.
Die spezifischen Formen, in denen das vorkommt, sind für die Abgrenzung des Weiteren entscheidend. Daten existieren in PDFs ohne zuverlässige Textextraktion. Daten erfordern die Verknüpfung von drei Systemen ohne dokumentiertes Schema. Daten existieren, aber der Genehmigungsprozess für den Zugang dauert länger als der Projektzeitplan. Daten existieren, sind aber in der relevanten Domäne zu spärlich, um den beabsichtigten Einsatz zu unterstützen.
Jedes dieser Probleme ist anders und erfordert eine andere Lösung. Zu wissen, welche Form die Lücke hat, bevor man sich auf ein Systemdesign festlegt, ist der Unterschied zwischen einem machbaren Umfang und einem nicht einlösbaren Versprechen.
Der Datenmaturitätsgradient gilt für die meisten Enterprise-Umgebungen. Manche Organisationen haben strukturierte, zugängliche Daten, bei denen KI-Projekte schnell vorankommen können. Die meisten haben strukturierte, aber siloisierte Daten, die Integrationsarbeit erfordern, bevor eine Retrieval-Schicht nützlich ist. Viele haben unstrukturierte, verteilte Daten, die eine Ingestion-Pipeline als Voraussetzung für alles andere erfordern.
Den ersten Projektumfang auf die tatsächlich verfügbaren Daten zu begrenzen, nicht auf theoretisch vorhandene, ist die Datendisziplin, die Discovery erzwingt.
Das Prozesstreue-Problem
Standardprozessdokumentation beschreibt den idealen Prozess. Darauf trainierte KI lernt eine Version des Prozesses, die Mitarbeiter erkennen, aber nicht befolgen.
Die Discovery-Technik, die den realen Prozess aufdeckt, ist Process Shadowing: das Beobachten oder Befragen der tatsächlichen Operatoren, nicht der Prozessverantwortlichen. Das Ziel ist es, die Ausnahmen, die Workarounds und die undokumentierten Heuristiken zu erfassen, die unterscheiden, wie Arbeit tatsächlich erledigt wird, von der dokumentierten Form.
Ein Dokumentklassifizierungssystem, das auf der formalen Taxonomie trainiert wurde, klassifiziert Dokumente falsch, die Praktiker mit informellen Kurzformen beschriften. Eine Kundensupport-KI, die auf der Wissensdatenbank trainiert wurde, versagt bei Anfragen, die erfahrene Agenten mit Informationen handhaben, die in der Praxis, aber nicht in einer dokumentierten Quelle existieren.
Das Prozesstreue-Lieferergebnis eines Discovery-Sprints ist eine Karte, die zeigt, wo dokumentierter Prozess und tatsächliche Praxis auseinandergehen. Diese Karte treibt die wichtigste Entscheidung vor Beginn des Engineerings an: Welche Version des Prozesses soll das System lernen zu befolgen?
Die Voraussetzung des Entscheidungsverantwortlichen
Ein KI-System ohne Entscheidungsverantwortlichen ist ein Forschungsprojekt. Das ist keine Kritik. Es ist eine strukturelle Eigenschaft.
Der Entscheidungsverantwortliche ist die Person oder definierte Rolle, die auf KI-Output handelt, Randfälle überprüft, hochriskante Empfehlungen genehmigt und verantwortlich ist, wenn das System falsch liegt. Ohne diese Rolle, die vor dem Deployment definiert und besetzt ist, folgen mehrere vorhersehbare Ausfälle.
Das System wird inkonsistent genutzt, weil verschiedene Personen unterschiedliche Schwellenwerte dafür anwenden, wann sie dem Output vertrauen. Randfälle häufen sich ohne Feedback an, weil niemand für ihre Überprüfung zuständig ist. Das System degradiert still und leise, bis ein Ausfall eine Abschaltung erzwingt.
Minimale Governance vor dem Launch: ein namentlich genannter Entscheidungsverantwortlicher, ein definierter Review-Rhythmus für Outputs mit geringem Vertrauen und ein dokumentierter Eskalationspfad. Das ist keine Compliance-Übung. Es ist die strukturelle Bedingung für ein System, das sich im Laufe der Zeit verbessert, anstatt in Richtung Irrelevanz zu driften.
Discovery als bezahltes Produkt
Der Discovery-Sprint ist kein Loss-Leader oder kostenloser Beratungsservice vor dem eigentlichen Engagement. Er ist ein bezahltes Produkt mit einem definierten Lieferergebnis.
Das Fünf-Output-Paket aus Prozesskarte, Dateninventar, Karte der Entscheidungsverantwortlichen, Wertschätzung und Risikoinventar ist wertvoll, unabhängig davon, ob ein KI-Projekt folgt. Ein Unternehmen, das einen Prozess automatisieren wollte und in Woche zwei herausfindet, dass die Daten unzureichend sind, hat ein Zwölf-Monats-Projektbudget gespart. Das ist ein konkretes Ergebnis, keine Vorbereitung.
Discovery nach Prozess statt nach Tagessatz zu begrenzen, richtet Anreize aus: Das Lieferergebnis ist der Output, nicht die aufgewendete Zeit. Das Folgeengagement, wenn es stattfindet, wird aus den Discovery-Ergebnissen heraus abgegrenzt, nicht aus den ursprünglichen Annahmen, die sich als teilweise falsch erwiesen haben.
Die fünf Outputs eines Discovery-Sprints sind vor dem Build-Start mehr wert als dieselben Informationen nach dem sechsten Monat. Umfang definiert, was Discovery abdeckt; die Prozesskarte ist der Ort, an dem die meisten Überraschungen stecken.
Weiterführend: Vertikale KI gewinnt dort, wo generische KI scheitert und Ihre Branche braucht keine KI-Plattform