Warum ein Digitaler Mitarbeiter zunächst mehr Arbeit machen kann und woran echte Entlastung scheitert

In einem laufenden Projekt hatten wir zuletzt eine unangenehme Situation. Die Lösung konnte Daten auslesen, Dokumente erzeugen und immer mehr Sonderfälle abbilden. Fehler wurden behoben, neue Versionen getestet. Technisch ging sichtbar etwas weiter.

Beim Kunden war die Entlastung trotzdem noch nicht angekommen.

Ein kleiner Kreis prüfte das System zusätzlich zum Tagesgeschäft. Die Mitarbeiter, die den Prozess später jeden Tag damit bearbeiten sollten, waren noch nicht breit eingebunden. Der bisherige Ablauf lief also weiter, während der neue daneben getestet wurde. Jeder zusätzliche Testfall erzeugte zunächst mehr Arbeit: Ergebnis prüfen, Abweichung erklären, Fehler weitergeben, neue Version wieder testen.

Wir hatten ein funktionierendes KI-System gebaut. Im täglichen Ablauf war es noch nicht angekommen.

Bei einem neuen Mitarbeiter wäre das wenig überraschend. In den ersten Wochen erklärt das Team Abläufe, kontrolliert Ergebnisse und korrigiert Fehler. Ein eingerichteter Laptop macht aus ihm noch keinen produktiven Kollegen. Bei Digitalen Mitarbeitern behandeln wir das Deployment trotzdem oft wie den Moment, ab dem die Entlastung da sein müsste.

Diese Phase ist bei Digitalen Mitarbeitern heikel, weil auf beiden Seiten etwas anderes sichtbar ist. Das Projektteam sieht geschlossene Tickets, technische Fortschritte und bessere Ergebnisse. Die Anwender sehen zusätzliche Prüfungen und einen Ablauf, der ihnen noch keine Zeit zurückgibt. Beide Wahrnehmungen können gleichzeitig stimmen.

Der Kunde spürt keine Release Notes

Technischer Fortschritt lässt sich leicht zeigen. Ein Feld wird jetzt korrekt erkannt. Eine Ausnahme ist abgedeckt. Ein Dokument wird automatisch erstellt. In einer Demo ist sofort erkennbar, dass die Lösung mehr kann als vor zwei Wochen.

Ob dadurch weniger Arbeit anfällt, ist schwieriger zu beantworten.

Dafür reicht es nicht, die automatische Verarbeitung zu betrachten. Der ganze Weg zählt: Unterlagen öffnen, Ergebnis prüfen, Korrekturen eintragen, Rückfragen klären, Dokument freigeben und im Zielsystem ablegen. Wenn die KI einen Teil davon beschleunigt, der Mitarbeiter danach aber lange nach Fehlern suchen muss, sieht die technische Messung besser aus als der Arbeitstag.

Genau hier entsteht die gefährliche Lücke zwischen Projektfortschritt und Kundennutzen. Das System wird besser, aber der Effekt bleibt unsichtbar. Je länger diese Phase dauert, desto weniger helfen weitere Erklärungen über Architektur oder Modellqualität. Der Kunde bezahlt für eine Veränderung im Prozess. Er bewertet nicht, wie viel Arbeit in den letzten Release geflossen ist.

Wir hatten den Übergang zu wenig als eigene Arbeit behandelt

Die Einführung eines Digitalen Mitarbeiters braucht Zeit auf Kundenseite. Mitarbeiter müssen Fälle auswählen, Ergebnisse prüfen und fachliche Regeln erklären, die in keiner Prozessbeschreibung stehen. Gerade am Anfang ist zusätzlicher Aufwand deshalb normal.

Unser Fehler war, diesen Übergang zu wenig als eigenen Teil der Implementierung zu behandeln.

Einige Personen testeten sehr engagiert, allerdings neben ihrer normalen Arbeit. Andere Mitarbeiter kannten den neuen Ablauf noch kaum. Dazu kamen technische Korrekturen und fachliche Fragen, die einzeln besprochen wurden. Es gab Fortschritt, aber noch keinen gemeinsam definierten Punkt, an dem aus Testen produktive Nutzung werden sollte.

Im Rückblick hätten wir die tatsächlichen Bearbeiter früher gemeinsam an reale Fälle setzen müssen. Kein weiterer Präsentationstermin, sondern ein Arbeitsblock: mehrere repräsentative Vorgänge, der neue Ablauf und alle Beteiligten an einem Tisch. Dann wird schnell sichtbar, wo das System wirklich Zeit spart und wo der Prozess noch bricht.

Das lässt sich in einer Demo kaum simulieren. Die schwierigen Fälle liegen selten so vor, wie man sie für eine Präsentation auswählen würde. Unterlagen fehlen, Werte sind ungewöhnlich, eine fachliche Regel gilt nur bei bestimmten Konstellationen. Genau dieses Wissen tragen die operativen Mitarbeiter im Kopf. Wenn sie erst kurz vor dem Go-live dazukommen, beginnt ein Teil der Entwicklung praktisch von vorne.

„Gut genug“ muss im Arbeitsalltag messbar sein

Viele KI-Projekte testen lange, ohne vorher zu klären, was für den produktiven Betrieb ausreichen soll. Dann gibt es nach jeder neuen Version dieselbe Diskussion: Das Ergebnis ist besser, aber ist es schon gut genug?

Eine einzelne Genauigkeitsquote löst das Problem selten. Ein falsch formatiertes Datum hat eine andere Bedeutung als ein plausibel wirkender falscher Betrag. Manche Abweichungen fallen beim ersten Blick auf. Andere können unbemerkt in den nächsten Prozessschritt gelangen. Deshalb muss Qualität fachlich bewertet werden, nicht nur statistisch.

Genauso wichtig ist die Zeit nach der automatischen Verarbeitung. Wie lange dauert das Review? Muss der Mitarbeiter den gesamten Fall nachvollziehen oder nur wenige markierte Stellen prüfen? Wie oft wird aus einer Unsicherheit eine Rückfrage? Und was passiert mit einer Korrektur, nachdem sie vorgenommen wurde?

Für ein belastbares Go-live-Gate braucht es deshalb reale Nutzer, repräsentative Fälle und eine Messung des vollständigen Ablaufs. Vorher und nachher. Erst dann sieht man, ob der Digitale Mitarbeiter Arbeit übernimmt oder nur einen zusätzlichen Prüfschritt erzeugt.

Das Ziel muss dabei nicht vollständige Automatisierung sein. In vielen sensiblen Prozessen wird ein Mensch weiterhin freigeben. Die Qualität des Systems zeigt sich dann daran, wie gut es diese Entscheidung vorbereitet.

Wenn ein Mitarbeiter jeden Fall von vorne prüfen muss, wurde wenig gewonnen. Wenn das System die Unterlagen verarbeitet, Quellen sichtbar macht und genau die unsicheren Stellen vorlegt, verändert sich die Arbeit. Aus vollständiger Bearbeitung wird gezielte Kontrolle.

Die Implementierung endet nicht mit dem Deployment

Bei Softwareprojekten ist der technische Go-live ein klarer Meilenstein. Bei einem Digitalen Mitarbeiter beginnt dort erst die Phase, in der sich zeigen muss, ob er im Unternehmen wirklich arbeiten kann.

Dazu gehören Dinge, die in keiner Produktdemo besonders spektakulär aussehen: Zuständigkeiten, Eskalationen, Korrekturwege, kurze Schulungen und ein gemeinsames Verständnis darüber, welche Ergebnisse geprüft werden müssen. Fehlt diese Arbeit, bleibt der Digitale Mitarbeiter ein gutes System neben dem eigentlichen Prozess.

Für uns ist daraus eine einfache Konsequenz entstanden. Wir müssen Implementierung stärker vom Arbeitsalltag her planen. Die technischen Fragen bleiben wichtig, aber sie dürfen den Blick auf die Nutzung nicht verdecken. Wer bearbeitet den Fall morgen früh? Was macht diese Person anders als heute? Welche Arbeit fällt tatsächlich weg? Woran sehen wir das?

Ob der Digitale Mitarbeiter eingearbeitet ist, zeigt sich im Tagesgeschäft: Reale Nutzer brauchen für reale Fälle spürbar weniger Zeit.