Stell Dir eine Fahrschule vor, die so arbeitet: Der Fahrlehrer setzt sich ans Steuer, dreht eine Runde über den Verkehrsübungsplatz, steigt aus und verkündet: „Funktioniert. Das Auto fährt.“ Du stehst daneben, hast keinen Meter selbst gelenkt, und einen Führerschein hast Du hinterher auch nicht. Aber immerhin ist jetzt bewiesen, dass Autofahren technisch möglich ist.
Klingt absurd? Genau so starten erstaunlich viele Data & AI Vorhaben.
Im letzten Beitrag haben wir aus einer Wand voller Klebezettel Use Case Streams gemacht: Cluster verwandter Use Cases, die sich ihre Umsetzungsvoraussetzungen teilen. Damit stehen zwei Fragen im Raum. Welcher Stream fährt zuerst? Und wie sieht die allererste Fahrstunde aus? Um beide geht es heute, und bei der zweiten habe ich eine klare Empfehlung: ein Proof of Value (PoV), und zwar bewusst nicht ein Proof of Concept.
Welcher Stream fährt zuerst? Priorisieren, bis es verbindlich wird
Hier trennt sich saubere Methodik von Wunschkonzert, und der Mechanismus ist wichtiger als jede Scoring-Formel.
Bei der Use-Case-Analyse wird der Mehrwert strukturiert aufgenommen: Welcher Effekt entsteht, in welcher Größenordnung, woran wird er gemessen? Und zwar nicht vom Berater geschätzt, sondern von den Business Leadern selbst bewertet, jeweils für ihre eigenen Use Cases. Konkret heißt das: Der Vertriebsleiter beziffert, was ihm das Kundenwert-Scoring bringt, und die Leiterin Rechnungswesen, was die automatische Belegprüfung spart. Jeder bewertet das, wofür er später geradestehen muss. Das ist der eigentliche Trick an diesem Requirements-Engineering- und Priorisierungsprozess: Er erzeugt Verbindlichkeit. Wer den Nutzen seines Use Cases selbst beziffert hat, kann später schlecht behaupten, das Projekt sei ihm aufgedrängt worden. Ownership entsteht beim Bewerten, nicht beim Kickoff.
Die Kostenseite muss das Business dafür nicht alleine stemmen: Die Aufwände der Use Cases selbst und die umgelegten Kosten der Enabler (Plattform, Datenanbindung, Governance) steuert der Beratungspartner oder das umsetzende Data Team bei. Zusammen ergibt das für jeden Use Case ein ehrliches Nutzen-Kosten-Paar, und aus der Landkarte wird ein ROI-sortiertes Portfolio. Meist ergibt sich daraus ein Staffelstart: ein bis zwei Streams sofort, die übrigen in späteren Horizonten, wenn das Fundament trägt.
Übungsplatz oder Straße: der Unterschied zwischen PoC und PoV
Womit also beginnen die Start-Streams? Und hier kommt die Fahrschule zurück. Ein Proof of Concept ist die Runde des Fahrlehrers über den Übungsplatz. Er beantwortet die Frage: „Geht das technisch?“ Die Antwort ist heute fast immer ja. Ob ein Sprachmodell Rechnungspositionen extrahieren oder Vertragsklauseln finden kann, ist 2026 selten die spannende Frage, das haben andere längst bewiesen.
Ein Proof of Value stellt zwei härtere Fragen: „Schafft das bei uns messbaren Wert?“ Und: „Können wir es danach selbst?“ Das ist der Unterschied zwischen dem Beweis, dass Autos fahren, und dem Beweis, dass Du fährst – im echten Verkehr, auf Deinen Straßen, zu Deinem Ziel. An diesen beiden Fragen hängen Budgets, Vertrauen und letztlich die ganze Data & AI Journey.
Die drei Ziele eines guten Proof of Value
Ein guter PoV nimmt sich ein bis zwei priorisierte Use Cases aus den Start-Streams vor und verfolgt drei Ziele gleichzeitig.
Wert belegen. Der Use Case geht produktiv und wird an harten Größen gemessen, etwa Prüfzeit pro Beleg von Minuten auf Sekunden, Fehlerquote runter, Zusatzumsatz pro Segment rauf. Kein Demo-Video, sondern Tagesgeschäft. Ein halb fertiges Modell spart exakt null Euro.
Fähigkeiten wiederverwendbar aufbauen. Plattformkomponenten, Data Products und Standards werden so gebaut, dass der zweite und dritte Use Case auf ihnen aufsetzen kann: Die Factory entsteht mit, nicht danach.
Enablement: die Fähigkeit im Haus verankern. Für mich der unterschätzteste Teil, und der Grund, warum das Bild der Fahrstunde so gut passt. Fahrschulautos haben Doppelpedale: Am Anfang bremst der Lehrer mit, am Ende fährst Du allein. Ein PoV, nach dem der Dienstleister geht und das Wissen mitnimmt, war dagegen teuer gemietete Kompetenz, ein Chauffeur auf Zeit. Ein guter PoV arbeitet von Anfang an im Tandem: gemeinsame Umsetzung, Pairing, Trainings, saubere Übergabe. Am Ende steht ein Team mit Führerschein, und ein Partner, der sich auf die nächsten schweren Strecken konzentriert, statt die leichten zu chauffieren.
Und jetzt die Sternchen: wann ein PoC doch sein darf
Damit das nicht zum Dogma wird: Es gibt Fälle, in denen ein Proof of Concept sein Geld wert ist. Nämlich überall dort, wo die technische Frage wirklich offen ist: ein Use Case an der Grenze des Machbaren, eine Datenquelle, von der niemand weiß, ob ihre Qualität trägt, ein Autonomiegrad, bei dem die AI erstmals selbst entscheiden soll statt nur vorzuschlagen. Dann ist „Geht das?“ eine ehrliche Frage, und man beantwortet sie am besten klein und schnell, bevor man einen PoV darauf baut.
Und auch ein PoV hat Voraussetzungen. Er braucht echten Datenzugang statt einer Exportdatei von vorletzter Woche, einen Prozess-Owner mit Zeit und Messgrößen, die vor dem Start definiert sind. Wer erst nach dem Projekt zu messen beginnt, misst am Ende das, was gerade gut aussieht.
Der Übungsplatz beweist das Auto
Der Punkt der Fahrschul-Geschichte ist am Ende ganz einfach: Niemand bezweifelt, dass Autos fahren. Die Frage ist, ob Du ankommst, wo Du hinwillst, und ob Du danach selbst am Steuer sitzt. Genau das beweist ein Proof of Value: messbaren Wert im Tagesgeschäft, gebaut auf Fähigkeiten, die im Haus bleiben.
Der Übungsplatz beweist das Auto. Die Fahrstunde beweist Dich.