Inhalt und Aufbau des Artikels

In diesem Artikel möchte ich auf folgende Punkte eingehen:

1. Fragenkatalog zur Identifizierung und Dokumentation von KI Uses Cases
2. Priorisierung von Use- oder Business Cases (Portfoliomanagement)
3. Fazit

1. To-do: Problemstellung oder Use Case ermitteln (Pain)

Was und Warum: Einer der wichtigsten Schritte ist das Verständnis für die Problemstellung oder den Use Case. In vielen Fällen haben Kunden eine klare Problemstellung oder Use Case, für welche Sie sich eine Lösung wünschen oder von dem Sie sich einen Mehrwert erhoffen. In diesem Schritt geht es darum, die Problemstellung oder den Use Case so genau und detailliert wie möglich zu verstehen, um bereits abschätzen zu können, ob eine datengetriebene (KI) Lösung überhaupt möglich oder zielführend ist und welche Anforderungen und Daten für die Umsetzung benötigt werden.

INFO: Die Problemstellung(en) bzw. Use Cases sind sehr hilfreich, um bereits abschätzen zu können, um welche Risikoklasse es sich bei einem möglichen KI-System nach EU-AI-Act handelt. Der AI-Act definiert bestimmte Risikokategorien, welche sich unter anderem nach der Branche und dem Anwendungszweck richten.

Ziele: Ziel dieses To-dos sind Antworten auf folgende Fragen:

1.1 – Was ist der Hintergrund bzw. die Ausgangslage?

Der Hintergrund beschreibt die aktuelle Ausgangssituation der Problemstellung und beschreibt im Optimalfall, wer, wie und warum von einer Problemstellung betroffen bzw. wie der Rahmen aussieht. Häufig beschreibt die Problemstellung / Use Case später z. B. einen Teil eines Prozesses. So würde im Rahmen der Hintergrundbeschreibung bzw. Ausgangslage beschrieben werden, wie dieser Prozess oder dessen Umfeld aussieht.

1.2 — Was ist die Problemstellung / Use Case?

Beschreibung aus Kundensicht, was die aktuelle Problemstellung bzw. der Use Case ist. Dabei ist es wichtig, die Problemstellung aus Kundensicht aufzunehmen und zu unterscheiden, ob es sich um die Lösung eines bestehenden Problems handelt oder es um die Entwicklung eines neuen Produktes oder neuer Features geht. Dies hat unter anderem Einfluss darauf, welche Mittel zur Problem- und Lösungsfindung genutzt werden sollen oder können. Erfahrungsgemäß ist bei der Entwicklung von neuen Features oder einem neuen Produkt insbesondere die Analyse und Evaluierung des tatsächlichen Bedarfs und Business Cases deutlich schwieriger. Hier eignet sich dann besonders der Einsatz von Werkzeugen wie dem Business Model Canvas oder dem Value Proposition Canvas (siehe Unten).

1.3 — Welche Abteilung / Bereich / Person ist von der Problemstellung betroffen oder soll mit der späteren Lösung arbeiten?

Dieser Schritt ist wichtig, um herauszufinden, wer die eigentliche Zielgruppe ist, welche von der Problemstellung / Use Case betroffen ist und wie groß diese ist (Anzahl MA). Häufig werden die eigentlichen Nutzer bei der Planung und Entwicklung außen vor gelassen, was schnell dazu führt, dass Lösungen an den eigentlichen Problemen oder Bedürfnissen der Endnutzer vorbeientwickelt werden. Die späteren Nutzer sollten aktiv in die Entwicklung als z. B. Tester oder SMEs (Subject Matter Experts) mit eingebunden werden. Genauso ist die Anzahl der späteren Nutzer für die Planung der Lösung (z. B. Anzahl Lizenzen) wichtig.

2. To-do: Mehrwerte, Ziele und Nutzen ermitteln (Business Value / Goals)

Was und Warum: Hier geht es darum zu verstehen, warum die Problemstellung oder der Use Case aus Kundensicht relevant ist, was mit dieser erreicht werden soll und welcher Business Value sich von der Lösung der Problemstellung versprochen wird. Wenn möglich können bereits konkrete KPIs oder Mehrwerte durch Lösung der Problemstellung / Bereitstellung des Use Cases genannt werden, um bereits ein Gefühl für die Kosten/Nutzen-Rechnung zu haben. Diese Informationen können später als Bewertungsgrundlage und Zielsetzung eines Projektes dienen.

Ziele: Ziel dieses To-dos sind Antworten auf folgende Fragen:

2.1 — Welche Mehrwerte / Ziele sollen mit der Lösung der Problemstellung oder dem Use Case erreicht werden?

Z. B. Von einer Lösung der Problemstellung wird sich eine Reduzierung der Durchlaufzeiten von XX Prozent erhofft, welche in einer Kosteneinsparung von XX Euro resultiert (…).

2.2 — Wie kann oder soll der Erfolg / Mehrwert / Ziele gemessen werden?

Wenn klar ist, was erreicht werden soll, ist es wichtig ebenfalls zu bestimmen, was genau die Kriterien sind, anhand derer ein „Erfolg“ gemessen oder bewertet werden soll. Häufig gibt es unterschiedliche Vorstellungen oder Erwartungshaltungen an einen „Erfolg“, weshalb eine genaue Definition der Erfolgskriterien Klarheit und Transparenz schafft.

2.3 — Gibt es messbare Kriterien (KPIs) für den Erfolg / Mehrwert / Ziele?

Wenn möglich, sollte man direkt Kennzahlen zur Erfolgsmessung bestimmten.

2.4 — Was soll mit KI gelöst werden bzw. was ist die Erwartungshaltung an KI?

Für viele auf den ersten Blick eine komische Frage, aber in der Praxis tatsächlich sehr wichtig. Die Erwartungshaltung der Initiatoren an KI. Häufig ist es so, dass Verantwortliche ein falsches Bild von den Funktionen und Fähigkeiten von KI haben und sich vorstellen, dass KI ein Allheilmittel darstellt. Ein typisches Beispiel ist die Annahme, dass KI selbstständig lernt und automatisch immer besser wird, umso länger diese im Einsatz ist. Das dahinter ein manueller Trainingsprozess steckt, welcher regelmäßig angestoßen werden muss, ist unbekannt. Deshalb ist es wichtig, direkt am Anfang zu hinterfragen, was die Erwartungshaltung an die KI ist oder warum der Kunde denkt, dass die Problemstellung damit gelöst werden kann, damit keine falschen Erwartungen entstehen.

3. To-do: Erwartete Ergebnisse ermitteln (Pain Reliever)

Was und Warum: Wenn die eigentliche Problemstellung bekannt ist, ist es in der Regel hilfreich zu verstehen, wie oder was eine potenzielle Lösung aus Sicht des Kunden aussehen, können oder erreichen müsste. Dies ist ein guter Punkt um festzustellen, was die kritischen bzw. Kernanforderungen an eine Lösung sind.

Ziele: Ziel dieses To-dos sind Antworten auf folgende Fragen:

3.1 — Wie könnte / soll eine potenzielle Lösung aussehen (Ideale Lösung)?

Mit Blick auf die Problemstellung bzw. dem Use Case haben Stakeholder in der Regel bereits eine Vorstellung davon, wie eine optimale Lösung aussehen müsste, bzw. wie dessen Funktionsumfang sein könnte. Es ist häufig hilfreich, wenn zu beginn in “eigenen” Worten beschrieben wird, wie eine optimale Lösung für die jeweiligen Problemstellung(en) aus Sicht der jeweiligen Stakeholder aussehen könnte. Aus dieser können dann später die einzelnen Funktionen leichter abgeleitet werden (siehe Punkt 3.2).

3.2 — Was soll die Lösung auf jeden Fall können oder beinhalten (Akzeptanzkriterien)?

Beim Funktionsumfang geht es um die genaue Beschreibung der gewünschten Funktionen bzw. Aufgaben. Diese können z. B. auf Basis der optimalen Lösung abgeleitet werden. Wichtigt is, dass die einzelnen Funktionen / Tätigkeiten möglichst präzise beschrieben werden und nach Möglichkeit auch direkt Abnahmekriterien zur Überprüfung haben.

3.3 — Gibt es eine favorisierte Lösung (falls es mehrere bekannte Alternativen gibt)?

Für den Fall das mehrere Optionen bekannt sind.

4. To-do: Bisherige Lösungsansätze oder Vorschläge ermitteln

Was und Warum: Um nicht unnötig das Rad neu zu erfinden ist es oft hilfreich zu ermitteln, welche Lösungsansätze oder Vorschläge bereits für das Problem existieren – sei es intern entwickelt oder extern bekannt. So kann geprüft werden, ob bestimmte Lösungsansätze bereits ausprobiert wurden und warum diese ggf. nicht funktioniert haben, um doppelte Arbeit zu vermeiden.

Ziele: Ziel dieses To-dos sind Antworten auf folgende Fragen:

4.1 — Was wurde bereits zur Lösung der Problemstellung(en) ausprobiert?

Häufig wurden intern bereits Maßnahmen oder Projekte durchgeführt, um die Problemstellung zu lösen und der Gedanke KI- oder Data Science zu nutzen ist das “letzte” Mittel. Da bei der Konzeption einer möglichen Lösung immer der “warum komplex, wenn es auch einfach geht” Ansatz gilt, ist es extrem wichtig, darüber Bescheid zu wissen, welche Lösungsansätze bereits ausprobiert wurden und aus welchen Gründen diese gescheitert sind. Damit verhindert man, dass man die gleichen Fehler oder Lösungsansätze wiederholt und kann auch zielgerichtete bei der Lösungskonzeption sein.

4.2 — Warum ist die aktuelle Lösung nicht ausreichend oder erfolgreich?

Wenn der aktuelle Prozess / Lösungsansatz klar ist, geht es darum zu verstehen, warum dieser nicht ausreichend ist oder warum dieser verbessert werden soll. Dazu nutze ich gerne das bereits fertige Prozess-Diagramm oder den Entwurf, um anhand der Prozess-Schritte oder Systeme die Probleme zu benennen. Damit wird bereits klar, an welchen Prozess-Stellen es hakt.

Beispiel: Z. B. sind typische Probleme häufig, das Daten in vielen Systemen verteilt sind, Informationen zwischen den Systemen manuell ausgetauscht / eingetragen werden müssen, Systeme langsam sind oder Informationen fehlen und unvollständig sind.

4.3 — Gibt es KPIs / Kennzahlen, über welche die Performance der aktuellen Lösung gemessen wird?

Falls es bereits Kennzahlen gibt, können diese als Ausgangspunkt zur Bestimmung von Verbesserungspotenzialen nutzen und können später zur Definition der Projektziele- und Erfolgskriterien genutzt werden. Über die KPIs ist darüber hinaus bereits grob ableitbar, ob die Erwartungshaltung zur Verbesserung aus Kunden / Stakeholdersicht mit Techniken der Data Science oder KI realistisch ist oder nicht.

4.4 — Welche bisherigen Initiativen oder sonstigen Projekte haben mit dieser Thematik zu tun?

In vielen Fällen ist es so, dass es intern bereits laufende Projekte oder Initiativen gibt, welche sich möglicherweise indirekt oder parallel ebenfalls mit der Problemstellung befassen. Z. B. wenn eine Problemstellung mehrere Abteilungen betrifft und diese jedoch unabhängig von einander eine Lösung herbeiführen wollen oder eine globale IT bereits übergeordnet an einer Lösung arbeitet, von welcher die Abteilungen noch nichts wissen. Dies passiert erstaunlich oft in größeren Unternehmen oder komplexen Firmenstrukturen ohne globales Portfoliomanagement. Aus diesem Grund ist es hilfreich, bereits zu Beginn zu wissen, welchen anderen Initiativen möglicherweise vorhanden sind, um nicht “unter die Räder zu kommen”.

4.5 — Welche bekannten Lösungsalternativen gibt es?

Gerade in großen Branchen gibt es für viele Problemstellungen bereits eine Vielzahl an Best-Practices oder fertig entwickelter Branchenlösungen. Es sollte nachgefragt werden, welche Lösungsansätze dem Kunden bereits bekannt sind oder zur Wahl stehen und was die Pro / Cons sind bzw. warum diese nicht direkt genutzt werden (z. B. zu hohe Kosten etc.). Nicht immer ist KI oder eine datengetriebene Individual-Lösung die sinnvollste oder kostengünstigste Alternative. Es ist hilfreich zu verstehen (auch wenn es letztendlich die Entscheidung des Kunden ist), welche Alternativen es gibt und ob es nicht direkt einfacherer oder kostengünstigere Alternativen gibt.

5. To-do: (Optional) Prozessdokumentation zur Problemstellung erstellen

Was und Warum: Als Ergänzung der Problemstellung (nicht bei der Entwicklung neuer Features oder Produkte) ist es hilfreich, sich über aktuelle Lösungen zu informieren und zeigen zu lassen, wie aktuelle Lösungen oder Workarounds aussehen (falls vorhanden). Häufig werden diese bereits bei der Beschreibung der Problemstellung beschrieben. Dies hilft dabei, die Problemstellung nachzuvollziehen und weitergehendes Verständnis für die Hintergründe aufzubauen.

Ein wichtiger Output ist ein Prozessdiagramm, anhand dessen die Arbeitsschritte, der Output und auch die beteiligten Systeme möglichst detailliert aufgeführt sind. Dadurch wird bereits schnell klar, welche Datenquellen vorhanden sind und wie komplex der Prozess tatsächlich ist. Häufig beschreiben Kunden einen Prozess nur aus ihrer Sicht und sehr grob, wodurch es passiert, dass viele Schritte ausgelassen werden, weil diese für den MA entweder selbstverständlich oder nicht für die Problemstellung als relevant eingestuft werden, was es schwierig macht, einen ganzheitlichen Blick auf die Komplexität und den Umfang der Problemstellung zu bekommen.

Aus diesem Grund ist dieser Schritt aus meiner Sicht sogar der wichtigste. Das Prozessdiagramm hilft ungemein und ist immer wieder ein Ausgangspunkt für die Kommunikation mit den Stakeholdern.

Ziele: Ziel dieses To-dos sind Antworten auf folgende Fragen:

5.1 — Gibt es einen Prozess zur Problemstellung / Hintergrund und wie sieht dieser aus?

Da einer Problemstellung häufig ein Prozess zugrunde liegt, welcher den Hintergrund bildet, sollte dieser nach Möglichkeit so genau wie möglich dokumentiert und ebenfalls grafisch skizziert werden. Dabei sollte darauf geachtet werden, dass möglichst jeder Schritt berücksichtigt wird. Häufig werden viele Schritte “händisch” durchgeführt (“… dann schaue ich in Liste XYZ, bevor ich die Werte in System ABC eintrage”).

Sehr relevant im Rahmen der Prozessdokumentation (mit Blick auf die Problemstellung):

• Wer ist an dem Prozess beteiligt / führt einen Schritt aus?

• Welche Systeme sind an einem Prozess beteiligt / führen einen Schritt aus?

• Welche Daten / Objekte werden zwischen den Prozessschritten / Systemen generiert und ausgetauscht?

• Welche Kriterien und Regeln gelten für die Ausführung einzelner Schritte /

• Welche Probleme / Pains sind bei den Prozessschritten bekannt / vorhanden? (Häufig werden so weitere Probleme herausgearbeitet / bekannt oder es stellt sich raus, dass ein Problem ggf. doch kein großer Pain Point ist)

5.2 — Welche Personen, Abteilungen, Bereiche sind am Prozess beteiligt?

Beschreibung der Entitäten, welche bei der Ausführung des Prozesse beteiligt sind. Die Information ist wichtig, um zu wissen, welche Enitäten bei der Lösungskonzeption mit berücksichtigt oder angebunden werden müssen. Ich nutze diese Information gerne im Rahmen der Erstellung eines ER-Diagramms.

5.3 — Welche Systeme sind an der Ausführung des Prozess beteiligt?

Beschreibung der beteiligten Systeme oder Anwendungen im Prozess, falls welche beteiligt sind. Die Information ist wichtig, um zu wissen, welche Systeme bei der Lösungskonzeption mit berücksichtigt oder angebunden werden müssen. Ich nutze diese Information gerne im Rahmen der Erstellung eines ER-Diagramms.

5.4 — Welche Daten / Objekte werden zwischen den einzelnen Prozess-Schritten / Systemen ausgetauscht?

Die Daten und Informationen, welche zwischen den Prozessschritten oder den Systemen ausgetauscht werden, falls Daten ausgetauscht werden. Hier muss nicht das Datenformat etc. berücksichtigt werden, sondern erst mal nur die einzelne Information, damit man den Datenflow nachvollziehen kann. Ich nutze diese Information gerne im Rahmen der Erstellung eines ER-Diagramms.

5.5 — Werden im Rahmen der Problemstellung / aktuellen Lösung personenbezogene Daten verarbeitet?

Die Fragestellung ist für mich sehr relevant, um direkt abschätzen zu können, welche Anforderungen voraussichtlich im Rahmen von DSGVO (und zukünftig AI-Act) berücksichtigt werden müssen. Sobald personenbezogene Daten an einer Stelle im Problem- oder Lösungsprozess verarbeitet werden, gelten gesteigerte Anforderungen an Sicherheit, Dokumentation und die allgemeine Komplexität der späteren Lösungskonzeption.

5.6 — Werden im Rahmen der Problemstellung / aktuellen Lösung nicht-personenbezogene aber schützenswerte Daten verarbeitet?

Wenn es sich nicht um personenbezeogene Daten handelt, können Daten totzdem Schützenswert sein, da diese z. B. Geschäftsgeheimnisse beinhalten oder auf andere Art bei Veröffentlichung Schäden oder Konsequenzen für eine Firma verursachen kann. Aus diesem Grund macht es Sinn zusätzlich abzufragen, welche anderen Datenkategorien bei der Problemstellung verarbeitet oder betroffen sein können.

• Öffentliche Daten (Informationen, die ohne Einschränkungen öffentlich zugänglich gemacht werden können.)

• Interne Daten (Informationen, die für die interne Nutzung innerhalb der Organisation bestimmt sind.)

• Vertrauliche Daten (Sensible Geschäftsinformationen, deren unbefugte Offenlegung der Organisation schaden könnte.)

• Streng vertrauliche Daten (Hochsensible Informationen, deren Offenlegung schwerwiegende Schäden verursachen könnte.)

Priorisierung von Use- oder Business Cases (Portfoliomanagement)

Nicht selten ist es der Fall, dass während der Analyse einer Problemstellung mehrere Use oder Business Cases gefunden werden oder es möglich ist, eine „große“ Problemstellung und mehrere kleinere Use Cases aufzusplitten. Meist ist dies sogar eine wünschenswerte Vorgehensweise, da dadurch schneller Ergebnisse geliefert werden können. Da man in der Regel nicht mit mehreren Use oder Business Cases gleichzeitig anfängt und Ressourcen meist auch begrenzt sind, müssen diese zuerst priorisiert werden. Dabei spricht man häufig auch von Portfoliomanagement, wenn man mehrere mögliche Initiativen (in diesem Fall Use oder Business Cases) hat und diese nun unter Berücksichtigung verschiedener Kriterien bewerten und priorisieren muss. In der Regel priorisiert man nach Business Value, aber es gibt viele verschiedene Möglichkeiten.

Folgend eine Übersicht zu verbreiteten Möglichkeiten der Priorisierung:

Priorisierung nach Geschäftswert / Business Value: Wie bereits angesprochen, stellt eine Priorisierung nach Geschäftswert sicher, dass an den Use Cases gearbeitet wird, die den größten Geschäftswert liefern. Dies kann sich in Form von erhöhten Einnahmen, reduzierten Kosten, verbesserter Kundenzufriedenheit oder einem Wettbewerbsvorteil äußern. Dabei muss immer berücksichtigt werden, dass zur Messung auch KPIs bzw. Kriterien vorhanden sein müssen.

Priorisierung nach Machbarkeit und Umsetzungsaufwand: Bei der Priorisierung nach Machbarkeit und Umsetzungsaufwand werden für jeden Use Case die technologische Komplexität der Umsetzung bewertet und welcher voraussichtliche Aufwand notwendig ist. Ebenso wichtig ist die Berücksichtigung der benötigten Ressourcen (Personal, Finanzen, Infrastruktur – z. B. ist häufig die IT bereits für Monate ausgebucht) und ob es Abhängigkeiten zu anderen Projekten oder Systemen gibt. Die Datenverfügbarkeit und -qualität sind ebenfalls wichtige Kriterien.

Priorisierung nach Wirtschaftlichkeit / Finanziellen Nutzen: Bei einer Priorisierung nach Wirtschaftlichkeit wird der erwartete finanzielle Ertrag ins Verhältnis zu den Investitionskosten (ROI) und der Amortisationszeit gesetzt. Eine Kosten-Nutzen-Analyse prüft, ob die erwarteten Vorteile die anfallenden Kosten übersteigen. Auch das Potenzial zur Kostenreduktion (z. B. durch Prozessoptimierung) und zur Umsatzsteigerung (z. B. durch neue Produkte) spielt hier eine Rolle.

Priorisierung nach Dringlichkeit oder Zeit: Häufig ist der Zeitfaktor ein entscheidender Faktor. Muss ein Use Case oder eine Problemstellung beispielsweise aufgrund gesetzlicher oder interner Vorgaben bis zu einem bestimmten Zeitpunkt umgesetzt werden? Wie hoch ist der Markt- oder Wettbewerbsdruck (insbesondere bei KI-Produkten ist der Zeitfaktor extrem wichtig)? Ist der Use Case eine Voraussetzung für andere wichtige Initiativen? Und wie schnell kann der Use Case realisiert werden, um schnell Wert zu generieren („Quick Wins“)?

Natürlich sind noch viele weitere Priorisierungskriterien möglich, aber dies sind meiner Erfahrung nach die häufigsten Kriterien, nach denen entschieden wird.

Fazit

Für mich ist die Identifizierung und Dokumentation von Use- und Business-Case im Rahmen einer Problemanalyse immer der erste und einer der wichtigsten Schritte bei der Planung und Konzeption von KI-Systemen. Nur wenn die Problemstellung oder der Use Case wirklich verstanden wurde, kann abgeschätzt werden, was der Einsatzzweck und die Einsatzumgebung eines KI-Systems sein wird und welche Anforderungen dabei berücksichtigt werden müssen. Dies sind Grundvoraussetzungen für die Entwicklung von vertrauenswürdigen und auditierbaren KI-Systemen. Erfahrungsgemäß ist dabei insbesondere die Prozessmodellierung einer Problemstellung eine zeitintensive Aufgabe, welche ggf. als eigenständiger Task in eine anschließende IST-Analyse ausgelagert werden sollte.

Ich hoffe, der Artikel ist eine Hilfe und freue mich über Feedback, Kritik oder Anregungen.