Es gibt einen Projektverlauf, der so oft vorkommt, dass man ihn vorhersagen kann. Ein Betrieb testet ein KI-Werkzeug an einem überschaubaren Fall. Der Test läuft gut, die Ergebnisse überzeugen, alle sind zufrieden. Dann kommt der Satz „und jetzt rollen wir das aus”, und danach passiert monatelang nichts.
Es liegt fast nie daran, dass die Technik im Betrieb plötzlich schlechter wird. Es liegt daran, dass ein Pilot etwas anderes beweist, als die Beteiligten glauben.
Der Pilot beweist nur, dass es im Prinzip geht
Ein Testlauf beantwortet eine einzige Frage: Kann das Verfahren die Aufgabe grundsätzlich lösen? Das ist eine wichtige Frage, aber es ist die leichteste von allen. Die drei Fragen, an denen der Betrieb tatsächlich hängt, stellt ein Pilot üblicherweise gar nicht erst.
Erstens: Im Piloten waren die Daten handverlesen
Für einen Test sucht jemand Material zusammen. Meistens unbewusst greift er dabei zu den Fällen, die sich gut eignen: vollständige Dokumente, bekannte Lieferanten, saubere Stammdaten. Im Betrieb kommt dann alles, was es wirklich gibt, und der Anteil der Sonderfälle ist regelmäßig höher, als jemand vorher geschätzt hätte.
Deshalb beginnen wir Projekte dieser Art nicht mit einem Test, sondern mit einer Sichtung. In einem anonymisierten Projekt aus unserer Arbeit, der automatisierten Rechnungsverarbeitung in einem Handwerksbetrieb, sind dafür zwei Wochen lang alle eingehenden Rechnungen nach Lieferant, Format und Sonderfall sortiert worden, bevor überhaupt etwas gebaut wurde. Nicht um vorsichtig zu sein, sondern um die echte Streuung zu kennen. Wer sie nicht kennt, baut gegen eine Annahme.
Zweitens: Im Piloten gab es keine Fehlerfälle, weil niemand welche gesucht hat
In einem Test schaut ein Mensch auf jedes Ergebnis. Genau das fällt im Betrieb weg, und damit stellt sich eine Frage, die vorher niemand stellen musste: Was passiert mit dem Fall, bei dem sich das System nicht sicher ist?
Es gibt dafür drei Antworten, und nur zwei davon taugen. Die Lösung kann den Fall stillschweigend durchlaufen lassen, sie kann ihn an einen Menschen geben, oder sie kann ihn sichtbar liegen lassen. Die erste Antwort ist die, die Projekte im Betrieb zerstört, weil der erste unbemerkt falsch verarbeitete Vorgang das Vertrauen kostet, das den Rest getragen hat.
Praktisch heißt das: eine Schwelle und eine Klärliste. Unterhalb der Schwelle läuft es durch, oberhalb prüft ein Mensch, und was nicht eindeutig ist, landet sichtbar in einer Liste statt still im System. Das ist kein Schönheitsmerkmal, sondern die Bedingung dafür, dass jemand die Verantwortung übernehmen kann.
Drittens: Im Piloten war jemand zuständig, im Betrieb niemand
Während des Tests gibt es einen Verantwortlichen. Er hat Zeit dafür bekommen, er schaut hin, er meldet, was auffällt. Mit dem Ende des Piloten endet diese Rolle, und danach ist die Lösung formal allen und tatsächlich niemandem zugeordnet.
Das ist der unspektakulärste der drei Punkte und in unserer Erfahrung der häufigste. Ein produktives System braucht eine benannte Person, die merkt, wenn die Klärliste wächst, und die befugt ist, etwas zu ändern. Ohne sie verfällt die Lösung leise: Die Sonderfälle häufen sich, jemand fängt an, sie wieder von Hand zu erledigen, und nach einigen Monaten läuft der alte Prozess daneben weiter.
Und darunter liegt die eigentliche Frage
Alle drei Punkte sind lösbar, wenn man sie kennt. Es gibt allerdings einen Fall, in dem der Sprung in den Betrieb auch mit sauberer Technik nicht gelingt, und zwar dann, wenn der Prozess schon vorher nicht funktioniert hat.
Wir sagen das in Erstgesprächen offener, als Kunden es erwarten: Ein Prozess, der bisher über informelle Absprachen, Excel-Dateien und persönliche Erfahrungswerte lief, wird durch Automatisierung nicht besser. Er wird lediglich effizienter falsch. Wenn niemand erklären kann, nach welcher Regel heute entschieden wird, dann gibt es diese Regel nicht, und eine Maschine kann sie nicht übernehmen. Dieser Teil der Arbeit lässt sich nicht an einen Dienstleister abgeben, und an ihm bleiben Projekte hängen, nicht an der Technik.
Welche Prozesse diese Prüfung bestehen, ist eine eigene Frage. Wir haben sie im Beitrag KI-Anwendungsfälle finden, die sich wirklich rechnen beantwortet.
Wie ein Übergang aussieht, der gelingt
Der Schritt vom Test in den Betrieb ist kein Schalter, sondern eine Phase, und sie gehört ins Angebot. In dem oben genannten Projekt lief die Automatisierung vier Wochen im Parallelbetrieb, in denen jede automatische Buchung gegen die manuelle geprüft wurde. In einem zweiten, ebenfalls anonymisierten Projekt zur Anbindung von ERP und CRM sind die manuellen Strecken erst nach zwei Wochen ohne Abweichung abgeschaltet worden, und zwar einzeln statt auf einmal.
Das kostet Zeit, die im Angebot sichtbar wird, und genau deshalb fällt sie in vielen Projekten weg. Der Tausch lohnt sich trotzdem: Der Parallelbetrieb ist die einzige Phase, in der ein Fehler noch nichts kostet, weil die alte Strecke daneben läuft.
In dem Rechnungsprojekt sind am Ende rund 90 Prozent der Bearbeitungszeit entfallen und die Fehlerquote ist um 95 Prozent gesunken. Der Punkt für diesen Beitrag ist aber nicht die Zahl, sondern der Weg dorthin: Sie steht am Ende einer Einführung mit Parallelbetrieb, nicht am Ende eines gelungenen Tests.
Was Sie beim nächsten Piloten anders vereinbaren
Verlangen Sie schon im Angebot drei Dinge, und zwar schriftlich. Erstens eine Sichtung der echten Fälle vor dem Bau, nicht ein Test mit ausgewähltem Material. Zweitens eine Regel für den unsicheren Fall, inklusive der Stelle, an der ein Mensch übernimmt. Drittens eine benannte Person auf Ihrer Seite, die nach dem Start zuständig bleibt, mit Zeit dafür im Kalender.
Und stellen Sie dem Anbieter eine Frage, deren Antwort viel verrät: Was passiert nach dem Piloten, und steht das mit im Preis? Wer darauf keine konkrete Antwort hat, verkauft Ihnen einen Test und nicht eine Lösung.
Wie wir diesen Übergang aufsetzen, steht unter KI-Prozessautomatisierung. Und wenn sich dabei herausstellt, dass der Prozess erst einmal geklärt gehört, sagen wir das lieber vorher als nach dem Piloten.