5 Fragen, die vor jedem KI-Projekt beantwortet sein müssen
- pascalluellemann
- 11. Apr.
- 6 Min. Lesezeit
Aktualisiert: vor 5 Tagen

Genau da wird es meistens ungenau.
Denn bevor man über Lösungen spricht, sollte erstmal klar sein, worüber man überhaupt spricht. Ein KI-Projekt braucht keinen großen Zauber am Anfang. Es braucht ein sauberes Verständnis davon, was eigentlich gelöst werden soll, für wen das gedacht ist und woran man später erkennt, ob die Sache etwas bringt.
Hier sind fünf Fragen, die aus meiner Sicht vor jedem KI-Projekt auf den Tisch gehören.
1. Welches Problem soll eigentlich gelöst werden?
Das ist die zentrale Frage. Und gleichzeitig die, die am häufigsten zu weich formuliert wird, oder sogar ganz vergessen.
Dann heißt es schnell, man wolle sich mal mit KI beschäftigen. Oder man sehe da Potenziale. Oder man wolle Prozesse effizienter machen. Das klingt erstmal vernünftig, ist aber noch keine brauchbare Grundlage.
Ein Projekt wird erst dann greifbar, wenn klar ist, wo im Alltag etwas hakt. Also konkret. Wo geht Zeit drauf?
Wo entstehen Schleifen?
Wo müssen Leute immer wieder dieselben Dinge tun?
Wo fehlt Struktur?
Wo dauert etwas zu lange?
Wo wird Arbeit doppelt gemacht?
Erst wenn das bekannt ist, wird aus dem Thema ein echter Anwendungsfall.
Ein einfaches Beispiel:Wenn eingehende Anfragen in einem Unternehmen jeden Tag manuell gelesen, sortiert und weitergeleitet werden, dann ist das ein klarer Ausgangspunkt. Dann kann man über eine Unterstützung bei der Vorsortierung sprechen. Das ist etwas anderes als einfach nur zu sagen, man wolle jetzt mal KI im Vertrieb einsetzen.
Je klarer das Problem, desto sauberer wird später alles, was darauf folgt.
2. Was soll danach besser laufen?
Auch diese Frage klingt simpel. Sie ist trotzdem entscheidend.
Viele Projekte starten mit einer allgemeinen Erwartung. Es soll schneller, besser, günstiger, effizienter werden. Das ist gut und richtig, allerdings unspezifisch. Am Ende sitzt man dann mit einem Tool da und merkt, dass eigentlich niemand sauber beschrieben hat, was sich konkret verbessern soll.
Es braucht ein klares Bild davon, was nach dem Projekt anders laufen soll als heute.
Zum Beispiel:
Sollen Anfragen schneller bearbeitet werden?
Sollen Texte schneller entstehen?
Soll Wissen leichter auffindbar sein?
Sollen Reports früher vorliegen?
Sollen Teams weniger Zeit in manuelle Routine stecken?
Es geht nicht um eine akademische Definition von Erfolg. Es geht darum, dass am Ende jemand sagen kann, ob sich der Aufwand gelohnt hat oder nicht.
Ein Projekt ohne sauberes Ziel läuft schnell in alle Richtungen gleichzeitig. Dann wird viel besprochen, aber wenig entschieden.
3. Worauf soll das Ganze eigentlich aufbauen?
Viele KI-Projekte klingen auf einer Folie erstmal stark. Interessant wird es in dem Moment, in dem man prüft, womit die Lösung später eigentlich arbeiten soll.
Denn jedes Projekt braucht eine Grundlage. Mal sind das Daten. Mal bestehende Dokumente. Mal Prozesse, Kategorien, Vorlagen oder historische Beispiele. Mal einfach eine Struktur, die heute schon vorhanden ist.
Die entscheidende Frage lautet also: Was ist schon da und in welchem Zustand ist es?
Sind relevante Informationen vorhanden?
Liegen sie halbwegs geordnet vor?
Gibt es wiederkehrende Muster?
Sind Zuständigkeiten klar?
Gibt es Material, mit dem sich arbeiten lässt?
Ein Beispiel aus dem Alltag:
Wenn ein Unternehmen Anfragen automatisch clustern will, dann braucht es dafür typische Anfragearten, Zuständigkeiten und bestenfalls ein paar saubere Beispiele aus der Vergangenheit. Sonst arbeitet man auf Zuruf und hofft, dass am Ende etwas Sinnvolles herauskommt.
Hier zeigt sich oft ziemlich schnell, ob ein Projekt direkt startklar ist oder ob erstmal die Basis aufgeräumt werden sollte. Beides ist okay. Hauptsache, man sieht es früh.
4. Wer arbeitet später wirklich damit?
Ein KI-Projekt ist nie nur eine technische Frage.
Es verändert fast immer einen Arbeitsablauf. Und damit betrifft es automatisch die Leute, die mit den Ergebnissen arbeiten, sie prüfen oder darauf Entscheidungen aufbauen.
Genau deshalb reicht es auch nicht, so ein Thema im kleinen Kreis vorzudenken und dann irgendwann fertig ins Team zu kippen. Wenn ein neuer Ablauf später funktionieren soll, muss man mit den Leuten arbeiten, die davon im Alltag betroffen sind. Nicht über ihre Köpfe hinweg, sondern gemeinsam mit ihnen.
Denn genau diese Menschen wissen meist ziemlich genau, wo es heute hakt, wo unnötige Schleifen entstehen, welche Ausnahmen ständig auftauchen und was in der
Theorie gut klingt, im echten Betrieb aber sofort auseinanderfällt.
Deshalb gehört früh die Frage auf den Tisch: Für wen ist das gedacht und wie muss es im Alltag funktionieren?
Es macht einen Unterschied, ob etwas für Marketing gebaut wird, für Vertrieb, Kundenservice, Operations oder Geschäftsführung. Jede Rolle braucht etwas anderes. Die einen wollen Tempo. Die anderen wollen Nachvollziehbarkeit. Wieder andere brauchen klare Freigaben oder verlässliche Grundlagen für Entscheidungen.
Viele Projekte scheitern nicht an der Idee, sondern an der Einführung. Dann ist die Lösung theoretisch sinnvoll, praktisch aber sperrig. Oder sie passt schlicht nicht in den Ablauf der Leute, die später damit arbeiten sollen.
Darum muss früh klar sein:
Wer nutzt das später wirklich?
Wer spart damit Zeit?
Wer prüft Ergebnisse?
Wer pflegt Grundlagen nach?
Wer trägt Verantwortung im Alltag?
Und genauso wichtig: Diese Menschen müssen aktiv eingebunden sein. Nicht als Alibi im letzten Termin, sondern von Anfang an. Wer Prozesse verändern will, braucht Mitarbeit. Sonst baut man an der Realität vorbei.
5. Wie lässt sich der Nutzen testen?
Das ist für mich einer der wichtigsten Punkte überhaupt.
Sobald KI im Raum steht, wird oft direkt groß gedacht. Dann geht es schnell um Skalierung, Automatisierung, Plattformen und Roll-out. Dabei wäre der sinnvollere erste Schritt oft viel kleiner.
Die eigentliche Frage lautet: Wie kann man den Nutzen so testen, dass man schnell etwas lernt?
Ein guter Pilot braucht keinen riesigen Rahmen. Er braucht einen klar begrenzten Anwendungsfall, einen überschaubaren Zeitraum und ein paar verständliche Kriterien, anhand derer man das Ergebnis beurteilen kann.
Und genau diese Kriterien müssen von Anfang an feststehen. Man muss zu Beginn definieren, wie Erfolg überhaupt messbar wird. Sonst läuft ein Projekt los, es wird viel gebaut, viel diskutiert und am Ende kann trotzdem niemand sauber sagen, ob es wirklich etwas gebracht hat.
Dazu gehört vor allem zweierlei: ein sauberer Ausgangswert und ein Zielwert, den man erreichen will.
Also zum Beispiel:
Wie lange dauert ein Prozess heute?
Wie viele Anfragen werden aktuell pro Stunde bearbeitet?
Wie hoch ist die Fehlerquote?
Wie viel Zeit braucht ein Team für bestimmte Routinen?
Wie schnell liegt ein Report im Moment vor?
Erst wenn dieser Ausgangspunkt klar ist, lässt sich später beurteilen, ob der Pilot etwas verbessert hat. Und genauso wichtig ist die zweite Frage: Welcher Wert wäre gut genug, damit man sagen kann, der Test war erfolgreich?
So entsteht ein Rahmen, der belastbar ist. Man sieht, ob der Nutzen da ist. Man erkennt, wo es hakt. Und man bekommt ein Gefühl dafür, was vor einem größeren Schritt noch sauberer gebaut werden muss.
Genau so wird aus einer Idee ein Projekt, das Hand und Fuß hat.
Woran man früh merkt, dass etwas noch nicht sauber
genug ist
Woran man früh merkt, dass etwas noch nicht sauber genug ist
Es gibt Momente in Projekten, die man kennen sollte.
Das erste Signal: Das Problem lässt sich nur in Schlagworten beschreiben. Wenn jemand sagt, man wolle "KI im Marketing einsetzen" oder "Prozesse automatisieren", aber nicht benennen kann, welcher konkrete Ablauf heute zu viel Zeit kostet, dann fehlt die Grundlage.
Das zweite Signal: Es gibt Erwartungen, aber keine Messlatte. Wenn am Ende eines Projekts niemand sagen kann, ob es etwas gebracht hat, weil vorher nie definiert wurde, woran man das erkennen würde, war der Start zu unscharf.
Das dritte Signal: Der Roll-out steht schon im Raum, bevor der erste kleine Test gemacht wurde. Das ist kein Zeichen von Ambition. Es zeigt, dass wichtige Schritte übersprungen werden.
Keines dieser Signale bedeutet, dass ein Projekt scheitern muss. Aber sie zeigen, dass vorher noch etwas zu klären ist. Ein ehrliches Gespräch an dieser Stelle kostet einen Tag. Dasselbe Gespräch nach drei Monaten Projektarbeit kostet deutlich mehr.
Fazit
Ein KI-Projekt, das im Alltag etwas verändert, fängt mit einer klaren Beschreibung des Problems an. Mit einem realistischen Bild davon, was danach besser laufen soll. Mit einem ehrlichen Blick auf die Datenlage. Mit den Menschen, die später damit arbeiten. Und mit einem Pilotrahmen, der zeigt, ob die Sache tatsächlich funktioniert.
Das ist Grundlagenarbeit. Und genau diese Grundlage entscheidet darüber, ob aus einer Idee ein Projekt wird das funktioniert..
Wenn du ein KI-Projekt planst und merkst, dass einer dieser Punkte noch offen ist: genau dort kann ich ansetzen. Mit den richtigen Fragen und dem Handwerk, daraus etwas Belastbares zu bauen.





Kommentare