Vom Prozess zum produktiven Automatisierungs-Workflow: Der technische Umsetzungsfahrplan

Phase 1: Den Prozess wirklich verstehen, bevor er automatisiert wird

Bevor überhaupt über Tools gesprochen wird, muss klar sein: Was soll nach dem Prozess objektiv anders sein? Wo beginnt und wo endet der Prozess genau? Wer trägt die fachliche Ergebnisverantwortung? Der Ist-Prozess wird über Workshops, vorhandene Logs sowie Process- und Task-Mining erfasst, die realen Varianten inklusive Schleifen und Ausnahmen werden gezählt, nicht nur der "Normalfall". Dazu kommen belastbare Zahlen zu Volumen, Spitzenlast, Saisonalität, Durchlaufzeit und den tatsächlichen Fehlerkosten in Rework, Geld, Compliance-Risiko und Kundenwirkung.

Phase 2: Daten, Regeln und Ausnahmen explizit machen

Alle beteiligten Datenquellen – Systeme, Dateien, E-Mail, Schnittstellen, Bedienoberflächen – werden inventarisiert, ihre Datenqualität geprüft: fehlende, widersprüchliche oder unstrukturierte Werte fallen hier auf, bevor sie später den Automatisierungslauf stören. Die Entscheidungslogik wird schriftlich als explizite Regel formuliert, Ausnahmen werden in bekannte und unbekannte unterteilt. Erst wenn eine stabile Schnittstelle fehlt, wird eine Automatisierung über die Bedienoberfläche (RPA) überhaupt in Erwägung gezogen – und dann mit einer schriftlichen Begründung, warum keine Schnittstelle wirtschaftlich nutzbar ist.

Phase 3: Den richtigen Mechanismus wählen und technisch absichern

Erst jetzt wird entschieden, wo künstliche Intelligenz überhaupt einen echten Engpass löst – nämlich dort, wo Regelcode die nötige Semantik nicht sinnvoll abbilden kann. Ebenso wird geprüft, ob ein Agent mit dynamischer Werkzeugwahl wirklich nötig ist oder ein fester Workflow ausreicht. Zentrale technische Absicherungen folgen in dieser Phase:

• Reversibilität jeder Aktion bewerten: Was lässt sich nicht oder nur teuer rückgängig machen?
• Berechtigungen minimieren: nur die wirklich nötigen Werkzeuge, Daten und Aktionen freigeben
• Freigabepunkte für Menschen an Wirkung und Unsicherheit koppeln, nicht pauschal überall einbauen
• Ein klarer Datenvertrag mit Eingabe- und Ausgabeschema sowie Pflichtfeldern
• Idempotenz für jeden Schritt mit echtem Seiteneffekt definieren
• Retry-Klassen zwischen temporären, dauerhaften und fachlich falschen Fehlern unterscheiden
• Timeouts, Rate-Limit-Handling und Nebenläufigkeitsregeln festlegen
• Kompensationslogik für den Fall von Teilfehlern modellieren
• Protokollierung mit Korrelations-ID, Schrittstatus, Version und Ergebnis vorsehen – inklusive einer Prüfung, welche Daten darin aus Datenschutzsicht überhaupt gespeichert werden dürfen

Phase 4: Testen, pilotieren und mit echten Kennzahlen messen

Ein belastbarer Testkatalog deckt Normalfälle, Grenzfälle, Fehlerfälle und Wiederanlauf-Szenarien ab. Sind KI-Komponenten beteiligt, kommen Evaluationsdurchläufe mit realen und bewusst schwierigen Testfällen sowie mehreren Wiederholungen hinzu – eine einzelne erfolgreiche Demo beweist keine wiederholbare Zuverlässigkeit. Der Pilot startet bewusst in kleinem Umfang mit einer messbaren Ausgangsbasis. Gemessen wird auf zwei Ebenen gleichzeitig: fachlich (Trefferquote im ersten Anlauf, Nacharbeit, Durchlaufzeit, Fehlerkosten) und technisch (Erfolgsquote, Anzahl der Retries, Latenz, Rückstau, Ausfälle) – dazu die tatsächlichen Kosten für Plattform, Schnittstellen, Modelle, Betrieb, Wartung und menschliche Prüfung.

Phase 5: Kontrolliert weiterentwickeln statt "einmal bauen, fertig"

Nach dem Go-Live endet die Arbeit nicht. Ein Änderungsprozess sorgt dafür, dass Modell-, Schnittstellen- und Workflow-Versionen kontrolliert statt beiläufig geändert werden – gerade weil sich Plattformen wie Automatisierungstools und ihre KI-Funktionen laufend weiterentwickeln. Mehr Autonomie für einen Agenten oder ein weiterer Automatisierungsschritt kommen erst hinzu, wenn der zusätzliche Nutzen an den definierten Kennzahlen tatsächlich sichtbar wird – nicht, weil es technisch möglich geworden ist.