AI-first-Prozessdesign: Vom Soll her denken, früh am Machbaren prüfen

Wer einen Prozess von den Möglichkeiten der AI her neu entwirft, arbeitet anders als in klassischen Prozessprojekten: gröber am Anfang, konkreter in der Mitte, und mit Machbarkeitsfragen deutlich früher, als man es aus klassischen Projekten gewohnt ist. Was sich in unserer Projektarbeit über Kern- und Unterstützungsprozesse hinweg bewährt hat.

Warum Greenfield bei AI besonders wichtig und schwer zugleich ist

Der Ausgangspunkt ist eine einfache Frage: Wie sähe dieser Prozess aus, wenn AI ihn steuert und Menschen nur dort eingreifen, wo fachliches Urteil gefragt ist? Die Antwort soll vom Soll her entstehen, nicht vom Ist. Das klingt vertraut, ist bei AI aber aus drei Gründen schwerer als bei früheren Prozessprojekten.

Erstens fehlt die Vorstellung davon, was AI heute kann und was in einem Jahr. Auch wer sich täglich damit beschäftigt, kann hier nicht jede Frage beantworten, weil sich die Möglichkeiten schneller verschieben als die Erfahrung damit. Zweitens hält der heutige Prozess die Beteiligten gedanklich fest. Rollen, Freigaben und Dokumente sind so selbstverständlich, dass sie im Zielbild wieder auftauchen, obwohl sie dort keine Funktion mehr haben. Die erste Skizze eines AI-first-Prozesses entsteht meist schnell. Bis ein Team sie wirklich verinnerlicht hat, dauert es deutlich länger. Drittens spannt sich zwischen Ambition und Realität ein weiter Bogen: Wie groß denken, wenn Teile der Basis-Infrastruktur noch nicht stabil laufen? Ambitioniert, aber realistisch heißt für uns: Das Zielbild darf groß sein, der erste Umsetzungsschritt muss auf der bestehenden Systemlandschaft funktionieren.

Schritt 1: Den heutigen Prozess nur grob aufnehmen

Für die Aufnahme des Ist-Prozesses genügt am Anfang meist eine SIPOC-Logik: Lieferanten, Inputs, Prozessschritte, Outputs, Kunden, auf einer Seite. Das ist deutlich leichter als eine vollständige Prozessmodellierung, und genau das ist der Punkt. Wer jeden Schritt detailliert modelliert, investiert viel Zeit in Abläufe, die es im Zielprozess womöglich nicht mehr gibt, und verankert sie nebenbei tiefer in den Köpfen. In der Greenfield-Diskussion zahlt sich die grobe Aufnahme aus unserer Erfahrung aus: Das Team spricht über das, was der Prozess leisten soll, statt über das, was er heute tut.

Die Details braucht es später trotzdem, aber nur für die Prozessschritte, die im Zielbild übrig bleiben. Dort, wo ein Agent künftig eigenständig ausführt, muss das Kontextwissen vollständig sein: Welche Sonderfälle gibt es, welche Regeln gelten, welche Daten liegen wo? Gründlichkeit ist also nicht abgeschafft, sondern verschoben: von der Ist-Aufnahme in die Validierung.

Schritt 2: Zukunft erlebbar machen

Der Zielprozess entsteht vom Ergebnis her: Was soll am Ende für Kundinnen, Kunden oder interne Auftraggeber herauskommen, und welchen Weg dorthin würde man wählen, wenn AI der Standard ist? Übergaben, Rückfragen und Prüfschleifen, die heute zwischen Rollen und Abteilungen liegen, stehen dabei grundsätzlich zur Disposition. Menschen kommen dort in den Prozess, wo fachliches Urteil, Verantwortung oder der persönliche Kontakt gefragt sind. Das Ergebnis ist selten ein vollautomatischer Prozess, aber fast immer einer mit deutlich weniger Schritten und Beteiligten als heute.

Damit ein Team den Zielprozess nicht nur zeichnet, sondern versteht, hat sich Folgendes bewährt:

• Inspiration und Impulse vor dem Ausarbeiten des eigenen Beispiels. Was AI in vergleichbaren Prozessen schon leistet, öffnet den Möglichkeitsraum schneller als jede Methodenfolie.
• Prototypen statt Präsentationen. Ein klickbarer Dummy, in dem die Fachkraft ihren künftigen Arbeitstag durchspielt, löst Diskussionen aus, die auf Folien nicht entstehen.
• Klare Arbeitsteilung mit der AI-Einheit. Gemeinsames Programmieren von Fachleuten und Entwicklerinnen und Entwicklern in einem Raum klingt gut, hat sich in unserer Erfahrung aber als weniger produktiv erwiesen. Gut funktioniert hat dagegen: Die AI-Einheit holt sich ein präzises Bild davon, wie es heute läuft und morgen laufen könnte, baut dann eigenständig, holt bei Bedarf fachlichen Input und kommt mit einem Prototyp in die Demo-Session zurück. Der fachlich-technische Austausch selbst funktioniert gut, in Workshops wie bilateral. 
• Das Team stellt den Zielprozess selbst vor. Wer den Soll-Prozess vor Kolleginnen und Kollegen erklärt, muss ihn sich zu eigen gemacht haben. Das ist ein guter Test dafür, ob er verinnerlicht ist.

Schritt 3: Erst frei denken, dann früh prüfen

In der Ideenphase gilt: möglichst keine Einschränkungen. Bedenken zu Datenschutz, Mitbestimmung oder Systemgrenzen werden gesammelt und sichtbar geparkt, aber nicht diskutiert. Wer hier schon validiert, landet leicht bei einer nur leicht verbesserten Version des heutigen Prozesses.

Sobald eine Idee aber greifbar ist, etwa als klickbare Prozessschritte auf einer ersten Dummy-Oberfläche, dreht sich die Regel um. Jetzt gehören die harten Fragen auf den Tisch: Welche personenbezogenen Daten verarbeitet der Agent, und auf welcher Grundlage? Was ist auf bzw. nahe der bestehenden Systemlandschaft machbar, was braucht eine Schnittstelle, die es noch nicht gibt? Welche Schritte berühren Mitbestimmung? Wer damit wartet, bis der ganze Prozess in der neuen Welt ausdetailliert ist, riskiert, am Ende festzustellen, dass er mit den geltenden Richtlinien nicht vereinbar ist, und beginnt von vorn. Deshalb hat es sich bewährt, je Prototyp zu prüfen und nachzuschärfen, statt einmal am Ende zu validieren.

Für die Validierung selbst hilft eine einfache Faustregel: Ausgeschlossen wird eine Lösung nur bei einem Verstoß gegen geltendes Recht oder den EU AI Act. Das meiste andere ist eine Gestaltungsfrage, die sich lösen lässt, wenn die richtigen Personen früh am Tisch sitzen.

Schritt 4: Den Weg in den Betrieb planen

Am Ende des Sprints steht nicht nur ein Konzept, sondern ein Umsetzungsplan: Welche Rollen verändern sich, welche Systeme und Daten müssen bereitgestellt werden, welche Vereinbarungen mit Betriebsrat und Datenschutz sind zu treffen, und wie sieht der Business Case aus? Wie ein solcher Business Case aufgebaut sein kann, beschreiben wir in Ambition, Prozessauswahl und Business Case.