Wenn Unternehmen anfangen, über KI nachzudenken, entsteht oft eine Patt-Situation: zu viele Optionen, zu wenig Klarheit, und die Angst, in die falsche Richtung zu investieren. Das Ergebnis ist Stillstand.
Ich arbeite mit einem Rahmen, der das aufbricht: vier Wochen, ein konkreter Prozess, eine klare Entscheidung am Ende. Kein fertiges System, aber eine verlässliche Grundlage für den nächsten Schritt.
Der häufigste Fehler beim Start ist die falsche Prozessauswahl. Unternehmen wählen zu große, zu komplexe oder zu sichtbare Prozesse als ersten Testfall. Das erhöht den Druck und macht es schwerer, ehrliche Erkenntnisse zu gewinnen.
In der ersten Woche führe ich Gespräche mit vier bis sechs Mitarbeitenden aus dem Fachbereich. Nicht mit der Geschäftsführung, sondern mit den Menschen, die den Prozess täglich ausführen. Ich frage nach: Was machen Sie heute, das Ihnen viel Zeit kostet und wenig Spaß macht? Was wiederholt sich immer wieder? Wo machen Sie Fehler, weil die Aufgabe monoton ist?
Daraus entsteht eine Liste von zehn bis zwanzig Kandidaten. Ich bewerte sie nach drei Kriterien: Wiederholbarkeit, klare Ein- und Ausgaben, interne Messbarkeit. Der Prozess, der in allen drei Punkten am stärksten abschneidet, wird der Pilotkandidat.
Dann messe ich den Istzustand. Nicht schätzen, messen. Eine Woche lang, täglich: Wie lange dauert der Prozess? Wie viele Fehler passieren? Wie viel Zeit geht mit Ausnahmen und Korrekturen drauf? Diese Zahlen sind die Grundlage für alles, was danach kommt.
In Woche zwei entsteht der erste Prototyp. Nicht fertig, nicht schön, nicht für den Produktiveinsatz. Aber funktionsfähig genug, um zu zeigen, was das System kann.
Je nach Prozess und Komplexität ist das ein KI-gestützter Workflow in n8n oder Make, eine einfache Web-App oder eine Kombination aus beidem. Die technische Umsetzung dauert selten länger als zwei bis drei Tage, wenn der Scope aus Woche eins klar definiert ist.
Nach dem Bau kommt der interne Test. Die Mitarbeitenden, die den Prozess kennen, nutzen das System für eine Woche mit echten, aber nicht produktionskritischen Daten. Ich bitte sie, jeden Fehler und jede Abweichung zu dokumentieren, ohne zu werten. Was funktioniert nicht? Was fehlt? Was irritiert?
Dieser Schritt ist wichtiger als der Bau selbst. Hier lernt man, was die eigentlichen Anforderungen sind, nämlich nicht die, die im Briefing standen, sondern die, die erst durch Nutzung sichtbar werden.
In Woche drei läuft das System parallel zum bisherigen Prozess. Das bedeutet: Beide Wege werden ausgeführt, der alte und der neue. Die Ergebnisse werden verglichen.
Das ist der einzige Weg, ehrlich zu messen, ob das System hält, was es verspricht. Alle anderen Bewertungen sind Annahmen.
Ich dokumentiere jede Abweichung zwischen den Ergebnissen des Systems und dem, was ein Mensch produziert hätte. Abweichungen sind nicht automatisch Fehler. Manchmal ist die Systemversion besser, manchmal schlechter, manchmal anders, aber gleichwertig. Das muss der Fachbereich bewerten, nicht die IT.
Am Ende von Woche drei habe ich zwei Dinge: Zahlen darüber, wie oft das System korrekt gearbeitet hat, und eine qualitative Einschätzung des Teams, ob sie damit arbeiten könnten.
In der vierten Woche folgt die Auswertung. Ich vergleiche die Messwerte aus Woche eins mit den Ergebnissen des Parallelbetriebs. Wie viel Zeit hätte das System im Vergleich zum bisherigen Prozess gespart? Wie hoch war die Fehlerquote? Was musste manuell nachgebessert werden?
Dann rechne ich den wirtschaftlichen Fall durch. Wie viele Stunden spart das System pro Woche, und was kosten diese Stunden? Was kostet der Betrieb des Systems? Wie lange bis zur Amortisation?
Diese Zahlen sind selten spektakulär. Meistens liegt die Zeitersparnis zwischen 20 und 50 Prozent für den betroffenen Prozess. Das ist keine Revolution, aber bei einem Prozess, der vier Stunden pro Woche kostet, sind es zwei Stunden pro Woche, also über hundert Stunden pro Jahr pro Person.
Am Ende steht eine klare Entscheidung: Geht dieses System in den Produktiveinsatz? Wenn ja, mit welchen Bedingungen? Und welcher Prozess wird als nächstes in Angriff genommen?
Ein erfolgreicher Pilot ist kein Endpunkt. Er ist der erste Datenpunkt für eine langfristige Strategie.
Was ich nach dem Pilot empfehle: Benennen Sie einen internen Owner für das System. Jemanden, der den Prozess versteht und der das System langfristig beobachtet und pflegt. Legen Sie einen monatlichen Review-Termin fest: dreißig Minuten, dieselbe Person, dieselben Fragen. Was funktioniert? Wo gibt es Ausnahmen? Was hat sich verändert?
Und beginnen Sie nach drei Monaten produktivem Betrieb mit dem zweiten Prozess. Das Zweite geht schneller als das Erste, weil die Lernkurve schon durchlaufen ist.
Die Versprechen der KI-Anbieter sind groß. Was bleibt davon nach sechs Monaten realer Nutzung übrig? Ein nüchterner Blick auf Zahlen, Erwartungen und was tatsächlich funktioniert.
Viele Unternehmen warten auf die perfekte KI-Strategie, bevor sie anfangen. Das ist der teuerste Fehler, den Sie machen können. Warum der erste kleine Schritt mehr lehrt als jedes Konzeptpapier.
Die meisten KI-Projekte scheitern nicht an der Technologie. Sie scheitern an Entscheidungen, die lange vor dem ersten Tool getroffen werden. Was ich in der Praxis immer wieder sehe.
