David Kruizenga
Alle Use-Cases

KI-Bedarfsanalyse und Use-Case-Priorisierung

Prototyp-Demo

Vom konkreten Arbeitsproblem zum bewerteten KI-Anwendungsfall. Ich habe ein Konzept mit funktionsfähigem Browser-Prototyp entwickelt, das Bedarfserfassung, Analyse, Clustering und Priorisierung verbindet.

Rolle
Konzeption, UX, Prompt Design, Prototyping
Schwerpunkte
GenAI, Prozessanalyse, Governance, Automatisierung
Prototyp
Lokale Browser-Anwendung ohne Cloud-Abhängigkeit
Methoden
Structured Output, regelbasiertes Clustering, Use-Case Assessment

Ausgangspunkt

Viele KI-Initiativen beginnen mit der Frage, wo sich KI einsetzen lässt. Dieser Use Case dreht die Perspektive um: Ausgangspunkt ist ein konkreter Bedarf aus dem Arbeitsalltag. Erst nach der strukturierten Erfassung wird geprüft, welche Lösung sinnvoll ist und ob dafür überhaupt KI nötig ist.

Nicht am Anfang

Wo können wir KI einsetzen?

Sondern

Wo besteht ein konkreter Bedarf und welche Lösung passt dazu?

So läuft es ab

Neun Schritte führen vom Arbeitsproblem zum bewerteten Use Case. Die Abschnitte danach zeigen Beispiele und Ergebnisse.

  1. Erfassen

    Bedarf erfassen

    Mitarbeitende beschreiben ihr Arbeitsproblem in einem geführten Dialog mit 15 Fragen. Der Assistent schlägt noch keine Lösung vor.

  2. Strukturieren

    Die Antworten werden in ein einheitliches Datenmodell überführt.

  3. Prüfen und freigeben

    Die Person prüft und bearbeitet die Zusammenfassung und gibt den Bedarf selbst frei.

  4. Analysieren

    Zusammenführen

    Freigegebene Bedarfe aller Fachbereiche laufen im Dashboard zusammen.

  5. Muster erkennen

    Ähnliche Herausforderungen werden zu Prozessmustern gebündelt.

  6. Bewerten

    Ein transparenter Rahmen bewertet jeden Kandidaten, auch auf KI-Eignung und Governance-Risiko.

  7. Priorisieren

    Die Kandidaten werden verglichen und nach Punktzahl sortiert. Die Entscheidung bleibt beim Menschen.

  8. Weiterentwickeln

    Pilotieren

    Deep Dive, Use-Case Design und ein begrenzter Pilot prüfen Wirkung, Qualität und Risiken.

  9. Weiterentwickeln

    Auf Basis der Pilotdaten wird bewusst über Skalierung, Anpassung oder Abbruch entschieden.

Beispiel: Erfassung

Ausschnitt aus einem synthetischen Gespräch und der strukturierten Zusammenfassung, die daraus entsteht. Jeder freigegebene Bedarf folgt demselben Datenmodell, deshalb sind Bedarfe verschiedener Fachbereiche vergleichbar.

In welchem Fachbereich arbeitest du?

Redaktion

Welchen konkreten Arbeitsschritt möchtest du betrachten?

Informationen aus mehreren Quellen zusammenführen

Wie stark ist der Painpoint auf einer Skala von 1 bis 5?

4

Beispieldialog, gekürzt.
{
  "fachbereich": "Redaktion",
  "prozess": "Quellen bündeln",
  "haeufigkeit": "täglich",
  "zeitaufwand": "45–60 Min.",
  "painpoint": "4",
  "systeme": "CMS, E-Mail, Teams",
  "sensible_daten": "ja"
}
Daraus entsteht der strukturierte Datensatz, Ausschnitt.

Das Dashboard

Freigegebene Bedarfe laufen in einem Cockpit mit drei Ansichten zusammen: Bedarfe, Muster und Priorisierung, Weiterbearbeitung. Hier die Kernansichten mit synthetischen Beispieldaten.

  • Bedarfe gesamt4
  • Fachbereiche4
  • Ø Painpoint4,0
  • Mit sensiblen Daten4

Erkannte Prozessmuster

Ähnliche Arbeitsschritte werden regelbasiert gebündelt, auch über Fachbereiche hinweg.

  • Informationsaufbereitung & SyntheseInformationen aus mehreren Quellen zusammenführen
    1 Bedarf · 1 Bereich · Ø Pain 4,0
  • Klassifikation & ÜbergabeWiederkehrende Anfragen einordnen
    2 Bedarfe · 2 Bereiche · Ø Pain 3,5
  • Datenkonsolidierung & ReportingKennzahlen zusammenführen und aufbereiten
    1 Bedarf · 1 Bereich · Ø Pain 5,0

Priorisierte Use-Case-Kandidaten

  • KI-gestützte InformationsaufbereitungVertiefen66
  • Assistierte AnfrageklassifikationVertiefen62
  • Automatisierte Reporting-KonsolidierungAutomation prüfen56

Pain, Häufigkeit und Reichweite stammen aus der Erfassung. Machbarkeit, Wiederverwendbarkeit, KI-Eignung und Governance-Risiko ergänzt das Assessment. Die Bewertung ist Entscheidungshilfe und keine automatische Freigabe.

Woran ich einen Anwendungsfall messe

  • Painpoint
  • Häufigkeit
  • Reichweite
  • Technische Machbarkeit
  • Wiederverwendbarkeit
  • KI-Eignung
  • Governance-Risiko

KI ist nicht immer die beste Lösung

Das Assessment soll auch das erkennen. Ein Bedarf kann gezielt in Richtung Prozessoptimierung oder klassische Automatisierung weitergeführt werden. Im Prototyp führt ein niedriger KI-Fit deshalb zum Ergebnis „Automation prüfen“.

Nächste Ausbaustufe

Für eine produktive Version sieht das Konzept eine strukturierte Übergabe per API oder Webhook, eine Orchestrierung zum Beispiel mit n8n und eine zentrale Ablage der freigegebenen Bedarfe vor. Der konkrete Aufbau hängt von Systemlandschaft, Berechtigungen, Datenschutz und Governance der jeweiligen Organisation ab.

Das Ergebnis

Aus losen KI-Ideen wird ein nachvollziehbarer Prozess vom Arbeitsbedarf bis zum bewerteten Anwendungsfall. Mitarbeitende haben einen niedrigschwelligen Einstieg, die Organisation eine strukturierte Entscheidungsgrundlage.

Vorher
  • KI-Ideen als Freitext
  • Einzelne Zurufe
  • Lösungen vorweggenommen
Mit dem Prototyp
  • Ein einheitlicher Datensatz
  • Vergleichbare Bedarfe
  • Bewerteter Kandidat mit Begründung

Konzeptionelle Arbeitsprobe mit synthetischen Beispieldaten, entstanden ohne interne Daten, Systeme oder Prozesse eines Unternehmens.