Warum Ihre Prozessautomatisierung gescheitert ist

Das Muster ist immer dasselbe

Ein Unternehmen identifiziert einen Prozess, der zu viele Stunden frisst. Es wird in Automatisierung investiert — meistens RPA, manchmal ein individueller Workflow. Es funktioniert in der Demo. Es funktioniert den ersten Monat. Nach einem halben Jahr erledigt das Team den Großteil der Arbeit wieder manuell.

Das ist kein Technologie-Problem. Es ist ein Design-Problem. Und es passiert aus spezifischen, identifizierbaren Gründen.

Grund 1: Die Automatisierung wurde für den Idealfall gebaut

Die meisten Automatisierungsprojekte beginnen mit dem "Happy Path" — dem Prozess, wie er ablaufen soll. Rechnung kommt rein, Felder werden extrahiert, Daten validiert, Buchung erstellt. Sauber, sequenziell, logisch.

Das Problem: Der Happy Path deckt vielleicht 70% der tatsächlichen Fälle ab. Die restlichen 30% — Rechnungen ohne Bestellnummer, E-Mails mit drei Anhängen von denen nur einer die Rechnung ist, Lieferanten die alles als einseitigen Scan schicken — wurden im Design als Sonderfälle behandelt und auf "Phase zwei" verschoben.

Phase zwei kam nie. Stattdessen bearbeitet jemand im Team die Ausnahmen manuell. Die Automatisierung läuft parallel zum manuellen Prozess, statt ihn zu ersetzen. Die Gesamtarbeitslast ist nicht gesunken. Sie wurde nur auf zwei Systeme verteilt.

Grund 2: Kein Eskalationspfad

Ein gutes System weiß, was es nicht kann. Die meisten Automatisierungstools wissen das nicht.

Wenn ein RPA-Bot Daten vorfindet, die er nicht parsen kann — ein PDF in unerwartetem Format, ein Feld das nicht zum erwarteten Muster passt — scheitert er entweder still, loggt einen Fehler den niemand prüft, oder stoppt komplett. Es gibt keinen Mittelweg zwischen "voll automatisiert" und "vollständig kaputt."

Was fehlt, ist eine Urteilsschicht. Etwas, das eine ungewöhnliche Eingabe anschaut und entscheidet: Das ist wahrscheinlich in Ordnung, verarbeiten. Oder: Das sieht ungewöhnlich aus, markieren für menschliche Prüfung — und hier ist genau, was auffällig ist.

Diese Urteilsschicht ist das, was ein Agent bereitstellt. Nicht weil er absolut klüger ist, sondern weil er architektonisch darauf ausgelegt ist, unter Unsicherheit Entscheidungen zu treffen, statt einem festen Pfad zu folgen.

Grund 3: Der Prozess hat sich geändert, die Automatisierung nicht

Geschäftsprozesse sind nicht statisch. Ein Lieferant ändert sein Rechnungsformat. Die Buchhaltung führt einen neuen Freigabe-Workflow ein. Eine neue Compliance-Anforderung ergänzt einen Validierungsschritt. Eine Fusion bringt ein zweites ERP-System mit.

Regelbasierte Automatisierung erfordert explizite Updates für jede dieser Änderungen. Jemand muss den Workflow anpassen, testen und deployen. In Unternehmen, in denen der Ersteller der Automatisierung die Rolle gewechselt hat — oder ein externer Berater war — häufen sich diese Updates als technische Schulden.

Die Automatisierung wird zunehmend asynchron zum echten Prozess. Statt sie zu reparieren, leitet das Team mehr Arbeit am System vorbei. Irgendwann verarbeitet sie nur noch die einfachsten, vorhersagbarsten Fälle — die Arbeit, die Automatisierung eigentlich kaum brauchte.

Grund 4: Es wurde das Falsche gemessen

Der Business Case für Automatisierung sieht typischerweise so aus: "Dieser Prozess kostet X Stunden pro Monat. Automatisierung reduziert das auf Y Stunden. Der ROI ist Z."

Aber "eingesparte Stunden" ist die falsche Metrik, wenn die Automatisierung unzuverlässig ist. Die relevante Frage ist: Welchen Anteil der Fälle verarbeitet die Automatisierung korrekt und vollständig ohne menschlichen Eingriff, und wie ist die Qualität des Outputs?

Ein System, das 95% der Rechnungen korrekt verarbeitet und die restlichen 5% zur Prüfung markiert, ist wertvoll. Ein System, das 70% korrekt verarbeitet, 15% still falsch behandelt und bei 15% abstürzt, erzeugt mehr Arbeit als es einspart — weil jemand den Output auditieren muss, um herauszufinden, welche 15% falsch waren.

Die meisten Automatisierungsprojekte messen Durchsatz, nicht Genauigkeit. So entsteht ein Tool, das technisch "500 Rechnungen pro Monat verarbeitet", während ein Mensch leise die Hälfte davon nachprüft.

Was der agentische Ansatz besser macht

Der agentische Ansatz repariert keine schlechte Prozessanalyse. Wenn Sie den falschen Prozess automatisieren oder missverstehen, wie er funktioniert, wird auch ein Agent scheitern — nur auf anspruchsvollere Weise.

Was er strukturell behebt:

Umgang mit Variation. Ein Agent schlussfolgert über das, was er beobachtet, statt einem festen Pfad zu folgen. Wenn die Eingabe nicht dem erwarteten Muster entspricht, passt er sich an — versucht einen anderen Parsing-Ansatz, schlägt zusätzlichen Kontext nach oder trifft eine Ermessensentscheidung.

Eskalation mit Kontext. Wenn ein Agent etwas nicht sicher lösen kann, scheitert er nicht einfach. Er übergibt an einen Menschen mit klarer Zusammenfassung: Das habe ich gefunden, das hat mich irritiert, das empfehle ich. Der Mensch prüft eine konkrete Frage, kein generisches Fehlerprotokoll.

Anpassungsfähigkeit. Weil Agenten auf Ziele hinarbeiten statt Skripte abzuarbeiten, sind sie resilienter gegenüber Prozessänderungen. Ein neues Rechnungsformat erfordert keinen Umbau des Workflows — der Agent liest das neue Format so, wie ein Mensch es tun würde.

Konfidenz-Messung. Ein Agent kann ausdrücken, wie sicher er sich bei seinem Output ist. Eine Rechnung mit 98% Konfidenz kann automatisch freigegeben werden. Eine mit 72% Konfidenz geht in die Prüfwarteschlange. So lässt sich das System justieren — mehr Autonomie für klare Fälle, mehr Aufsicht für mehrdeutige — ohne binäre Alles-oder-Nichts-Logik.

Das schwierigere Problem: Prozessdesign

Nichts davon hilft, wenn das zugrundeliegende Prozessdesign falsch ist. Und hier scheitern die meisten Automatisierungsprojekte tatsächlich, unabhängig von der Technologie.

Bevor Sie irgendetwas bauen, brauchen Sie ehrliche Antworten auf diese Fragen:

• Wie sieht dieser Prozess in der Praxis aus — nicht auf dem Papier?
• Wo treten die Sonderfälle auf, und wie werden sie heute gehandhabt?
• Welche Informationen nutzt ein Mensch, wenn er in diesem Prozess Ermessensentscheidungen trifft?
• Wie sieht "gut genug" aus? Muss jeder Fall perfekt sein, oder ist eine 95%-Erfolgsrate mit zuverlässiger Markierung des Rests akzeptabel?
• Wer betreut das System nach der Fertigstellung? Gibt es jemanden, der sowohl den Prozess als auch die Technologie versteht?

Wenn Sie diese Fragen nicht klar beantworten können, wird kein Automatisierungstool — agentisch oder nicht — liefern, was Sie erwarten. Nicht die Technologie ist der Engpass. Das Verständnis ist es.

Was Sie beim nächsten Mal anders machen sollten

Wenn Sie schon einmal ein gescheitertes Automatisierungsprojekt erlebt haben, lohnt sich Folgendes:

Beobachten statt spezifizieren. Schauen Sie zwei Wochen lang zu, wie der Prozess wirklich läuft, bevor Sie eine einzige Anforderung schreiben. Dokumentieren Sie die Ausnahmen. Zählen Sie, wie oft der "seltene Sonderfall" tatsächlich vorkommt.

Eskalationspfad zuerst definieren. Bevor Sie entscheiden, was der Agent autonom erledigt, legen Sie fest, was er nie ohne menschliche Aufsicht tun soll. Das ist die Sicherheitshülle. Alles innerhalb kann aggressiv automatisiert werden. Alles außerhalb wird markiert.

Genauigkeit messen, nicht Geschwindigkeit. Die erste Metrik sollte sein: Welcher Anteil der Outputs ist ohne menschliche Korrektur korrekt? Geschwindigkeit ist irrelevant, wenn man dem Output nicht vertrauen kann.

Für die 30% bauen, nicht nur für die 70%. Die Sonderfälle sind der Wert. Jeder kann das Einfache automatisieren. Die Frage ist, ob Ihr System die unordentlichen, mehrdeutigen Fälle bewältigt, die die meiste menschliche Zeit binden.

Das ist der Unterschied zwischen einer Automatisierung, die in der Demo gut aussieht, und einer, die sechs Monate später tatsächlich die Arbeitslast reduziert.