Es gibt einen Moment, den ich in fast jedem Data & AI Workshop erlebe. Nach zwei Stunden hängen dreißig, vierzig Use-Case-Ideen an der Wand, vom integrierten Unternehmensreporting über Lieferkettenprognosen bis zur Live-Bestandssicht. Die Stimmung ist großartig. Und dann stellt jemand die Frage, die die Stimmung kippen kann: „Schön. Und womit fangen wir jetzt an?“
Genau an dieser Frage entscheidet sich, ob aus einem energiegeladenen Workshop eine Data & AI Journey wird – oder eine Fotodokumentation von Klebezetteln. Heute zeige ich dir, wie aus der Ideenwolke eine sortierte Landkarte wird: über eine Potential Map und über Cluster zu Streams, die dein ganzes Portfolio tragen. Die Küche hat dafür ein Wort: Mise en place, alles an seinem Platz, bevor gekocht wird.
Schritt 1: Alle Ideen auf der Potential Map verorten
Der erste Fehler, den man vermeiden sollte: Use Cases als flache Liste behandeln. Eine Liste kann man nur der Reihe nach abstimmen, und dann gewinnt, wer am lautesten war. Denn eine Liste beantwortet nur eine Frage: Wer gewinnt? Die bessere Frage lautet: Was gehört zusammen? Und die beantwortet eine Landkarte mit zwei Achsen, die Potential Map.
Im Bild der Küche: Die Speisekarte ist das Business, sie bestimmt, was du deinen Gästen servieren willst, also deine Potenziale und Use Cases. Die Küche mit ihren Köchen und Geräten liefert die Enabler, die People- und die Technology-Seite. Eine Speisekarte voller Desserts ohne Pâtissier ist ein Versprechen ohne Küche; ein teurer Ofen ohne Gericht, das ihn braucht, ist Technik ohne Auftrag. Business führt, People und Technology befähigen: Beides muss von Anfang an zusammengeführt werden, und genau dafür ist die Potential Map das Werkzeug.
Die Potential Map trägt auf der einen Achse den Reifegrad des Potenzials, von Descriptive Analytics („Was ist passiert?“) über Diagnostic („Warum ist es passiert?“), Predictive („Was wird passieren?“), Process Automation („Wie automatisieren wir den Prozess?“, heute meist ein Fall für Agentic AI) und Data as Selling Point („Was können wir dank unserer Daten anbieten?“) bis zu Monetizing Data („Wie verdienen wir mit unseren Daten Geld?“). Auf der anderen Achse die Datenmobilisierung: Braucht der Use Case strukturierte Daten aus ERP und CRM oder unstrukturierte Dokumente, Bilder, E-Mails? Und reicht der nächtliche Batch-Lauf, oder muss es Echtzeit sein?
Warum der Aufwand? Wegen einer unscheinbaren, aber mächtigen Eigenschaft dieser Karte: Use Cases, die im selben Bereich der Map liegen, teilen sich ihre Umsetzungsvoraussetzungen. Zwei Dashboards auf strukturierten ERP-Daten brauchen dieselbe Datenanbindung, dieselben Stammdaten, dieselbe Plattformbasis. Ein Live-Bestand und eine Maschinenauslastung teilen sich dieselbe Event-Anbindung. Die Karte macht sichtbar, was die Liste versteckt: Synergien.
Schritt 2: Aus 30 Ideen werden 4 Themen
Jetzt passiert der eigentliche Zaubertrick, und er ist verblüffend einfach: Man schaut auf die belegte Map und zieht Kreise um Nachbarschaften.
Wie mächtig dieses Prinzip ist, zeigt jede Profiküche, und sie verdankt es einem Mann: Auguste Escoffier organisierte um 1900 die Küchen des Savoy und des Ritz nach dem Vorbild seiner Zeit als Armeekoch. Vorher kochte jeder Koch ganze Gerichte allein; Escoffier zerlegte die Arbeit in Posten. Ein Restaurant mit vierzig Gerichten auf der Karte kocht seitdem nicht vierzig Einzelprojekte: Der Saucier führt Fleisch und Saucen, der Entremétier die Beilagen, der Pâtissier die Desserts. Jeder Posten bündelt Geräte, Handgriffe und Mise en place, die sich alle Gerichte seiner Nachbarschaft teilen.
Genau solche Posten suchst du auf deiner Map, denn sie zeigen, welche Enabler deine Speisekarte wirklich verlangt. In der Praxis kristallisieren sich fast immer wenige natürliche Cluster heraus, zum Beispiel:
Analyse & Diagnose: alle Reporting- und Controlling-Cases auf strukturierten Daten, etwa Unternehmensreporting, Vertriebsperformance und Einkaufs-Dashboards. Gemeinsamer Nenner: integrierte, verlässliche Datenbasis über Systemgrenzen hinweg.
Prognose & Potenzialanalyse: Forecasting, Kundenwert-Scoring, Lieferkettenprognosen. Baut auf dem ersten Cluster auf. Gemeinsamer Nenner: dieselbe integrierte Datenbasis, ergänzt um Predictive-Analytics-Fähigkeit, also Modelle bauen, trainieren und im Alltag überwachen.
Echtzeit-Transparenz: Live-Bestände, Maschinenauslastung, Frühwarnungen aus der Lieferkette. Gemeinsamer Nenner: Ereignisse in Echtzeit anbinden, statt auf den nächtlichen Batch-Lauf zu warten.
Daten als Produkt: aufbereitete Reports für das Händlernetz, Benchmarks für Kunden, eine Daten-API für Partner. Gemeinsamer Nenner: Data Products mit stabilen Schnittstellen und Qualität, für die man geradestehen kann.
Aus dreißig konkurrierenden Einzelideen sind vier strategische Themen geworden. Das verändert die Diskussion fundamental: Statt „Welcher Use Case gewinnt?“ fragt man „Welche Fähigkeit bauen wir zuerst auf, und welche Use Cases schaltet sie alle frei?“
Zwei ehrliche Einschränkungen gehören dazu. Erstens: Die Kreise folgen den geteilten Voraussetzungen, nicht dem Organigramm. Wer jeder Abteilung ihren eigenen Cluster zeichnet, hat die Liste nur hübscher aufgemalt. Zweitens: Ein Kreis auf der Karte ist noch kein Posten in der Küche. Die geteilte Voraussetzung ist damit gefunden, nicht gebaut: Die erste integrierte Datenbasis bleibt ein ordentliches Stück Arbeit.
Schritt 3: Von Clustern zu Streams
Jedes Cluster wird nun zu einem Use Case Stream: einem Arbeitsstrang mit einem konkreten ersten Use Case, klarem Fokus und benannten Stakeholdern. Und hier steckt die entscheidende Denkfigur, die ich dir ans Herz legen möchte: Ein Stream liefert nicht nur seinen ersten Use Case. Ein Stream eröffnet eine Fähigkeit, die alle Folge-Use-Cases desselben Clusters befähigt.
In der Küche ist das selbstverständlich: Steht der Pâtissier-Posten einmal, kostet das nächste Dessert auf der Karte fast nichts mehr. Es erbt Ofen, Handwerk und eingespielte Routine. Niemand käme auf die Idee, für jedes neue Dessert eine eigene Backstube zu bauen.
Wenn der Stream „Analyse & Diagnose“ die ersten integrierten Dashboards baut, entstehen nebenbei die Datenanbindungen, die Stammdatenlogik und die Governance, von denen jede spätere Auswertung profitiert. Wenn der Echtzeit-Stream die ersten Live-Bestände anbindet, entsteht die Event-Anbindung, die jeder weitere Echtzeit-Case fast geschenkt bekommt. Deshalb lohnt es sich, Streams bewusst über die Potential Map zu verteilen: Jeder erschließt eine andere Region, und gemeinsam spannen sie das Fundament für das gesamte Portfolio auf.
Das Ganze in einem Satz
Wenn ich den Weg von der Wand voller Klebezettel bis hierher zusammenfassen müsste: Sammeln, verorten, clustern und in Streams übersetzen, die mehr aufbauen als ihren ersten Use Case. Oder in Küchensprache: Posten einrichten, statt Gerichte einzeln zu kochen.
Die Ideenwolke ist bei alldem übrigens nie das Problem. Sie ist der Rohstoff. Das Problem ist, sie unsortiert zu lassen, denn dann entscheidet der Zufall, womit du startest. Und der Zufall hat erfahrungsgemäß ein schlechtes Händchen für Business Cases.
Damit bleiben zwei Fragen offen: Welcher Stream startet zuerst, und wie sieht der allererste Schritt aus? Kurze Antwort: verbindlich priorisieren und mit einem Proof of Value starten, nicht mit einem Proof of Concept. Die lange Antwort bekommt einen eigenen Beitrag.
In der Küche heißt dieser Moment: Die Mise en place steht. Zeit, den Herd anzuzünden.