KI-Automatisierung und Workflows

Management-Zusammenfassung

Die zentrale These

Automatisierung ist eine Architekturfrage, keine Toolfrage. Ein Unternehmen kann denselben fachlichen Prozess mit Skripten, APIs, einer Workflow-Engine, RPA, einer Low-Code-Plattform, einem ML-Modell, einem LLM-Agenten oder einer Kombination daraus abbilden. Die belastbare Auswahl folgt aus Prozessstabilität, Datenstruktur, Ausnahmequote, Integrationszugang, Fehlerfolge, Volumen und Änderungsfrequenz. ^{[S-001, S-003 bis S-013]}

Für stabile, strukturierte und regelgebundene Abläufe ist deterministische Automation weiterhin der Referenzpunkt. Sie ist einfacher zu testen, zu reproduzieren und zu auditieren. Generative AI erweitert den Automationsraum dort, wo Eingaben unstrukturiert oder semantische Entscheidungen nötig sind. Agenten erweitern ihn nochmals, indem sie Schritte und Tools dynamisch wählen. Mit jeder zusätzlichen Freiheitsstufe wächst aber auch der Evaluations-, Berechtigungs- und Betriebsaufwand. ^{[S-030, S-070 bis S-077]}

Hybrid statt „alles Agent“

Die überzeugendsten dokumentierten Architekturen sind häufig hybrid. Microsofts Referenzarchitektur für Dokumentenverarbeitung kombiniert AI-Extraktion mit Validierung, Human Review, Retry und Monitoring. EY PowerMatch verbindet AI-Extraktion mit einem deterministischen 14-Schritt-Matching-Algorithmus. Komatsu koppelt Cloud/API-Workflow und AI-Extraktion mit Desktop-RPA für ein Legacy-AS/400-System. Diese Fälle beweisen keine allgemeine Überlegenheit, zeigen aber ein wiederkehrendes Konstruktionsprinzip: Probabilistische Verarbeitung wird an einer Unsicherheitsgrenze eingesetzt; irreversible oder stark regelgebundene Schritte bleiben kontrolliert. ^{[S-030, S-100 bis S-102]}

RPA bleibt relevant, aber nicht als Dauerprovisorium

Die RPA-Forschung beschreibt seit Jahren Nutzen und Schattenseiten. RPA kann vorhandene Benutzeroberflächen automatisieren und so Legacy-Systeme erschließen. Gleichzeitig dokumentieren Arbeiten Wartungs-, Governance-, Sicherheits- und Wissensrisiken. Besonders problematisch wird RPA, wenn ein Unternehmen schlechte Prozesse lediglich „schneller klickt“ oder Bots als dauerhaftes Pflaster auf Systeme legt, die eigentlich integriert oder standardisiert werden müssten. ^{[S-003, S-007, S-010, S-013, S-014]}

Ein guter RPA-Fall ist typischerweise wiederholbar, regelstabil und technisch überschaubar. Ein schlechter Fall hat viele unbekannte Ausnahmen, häufige UI-Änderungen, hohe Fehlerfolgen und implizites Expertenwissen. Die Entscheidung muss Wartungskosten und manuellen Fallback einschließen. ^{[S-005, S-006, S-009, S-011]}

Reliability ist Bestandteil der Fachlogik

Produktive Automation scheitert nicht nur an „falscher KI“. Klassische technische Probleme sind mindestens ebenso wichtig: doppelt zugestellte Events, API-Timeouts, Rate Limits, parallele Updates, halbfertige Transaktionen, abgelaufene Credentials und Änderungen externer Schnittstellen. Robuste Workflows benötigen daher Idempotenz, Retry-Klassen, Timeouts, Queues, Concurrency-Regeln, Kompensation, Auditdaten und Wiederanlauf. ^{[S-036 bis S-069, S-117]}

Ein Retry ohne Idempotenz kann einen Fehler verschärfen, wenn ein Seiteneffekt doppelt ausgeführt wird. Eine Queue kann Last puffern, garantiert aber nicht automatisch die fachlich genau-einmalige Verarbeitung. Ein technischer „Success“-Status kann fachlich falsch sein. Deshalb muss Zuverlässigkeit am Endzustand des Geschäftsfalls gemessen werden. ^{[S-064, S-068, S-069]}

Process Mining und Task Mining vor der Automation

Process Mining nutzt Event Logs, um tatsächliche Prozesse zu entdecken, Soll-Ist-Abweichungen zu analysieren und Verbesserungspotenziale sichtbar zu machen. Das Process Mining Manifesto unterscheidet Discovery, Conformance und Enhancement. Systematische Reviews zeigen zugleich, dass die Datenaufbereitung und die Ableitung konkreter Automation nicht trivial sind. ^{[S-002, S-004]}

Task Mining ergänzt diese Sicht durch Desktop-Interaktionen. Object-centric Process Mining adressiert Prozesse, in denen mehrere Objekte wie Bestellung, Lieferung, Rechnung und Zahlung miteinander verknüpft sind. OCEL 2.0 schafft dafür eine offene Spezifikation. ^{[S-019 bis S-028]}

Der entscheidende Satz für das Buch lautet: Process Mining zeigt, was passiert; es beweist nicht automatisch, warum es passiert oder was automatisiert werden sollte.

n8n und Make als Werkzeuge, nicht als Theorie

n8n und Make sind 2026 leistungsfähige visuelle Automationsplattformen mit API-Integrationen, Webhooks, Fehlerbehandlung und AI-/Agentenfunktionen. Beide Produkte verändern sich laufend. n8n dokumentiert Agent-Knoten, AI-Metriken, Queue-/Concurrency-Funktionen und Human Review; Make hat 2026 seine neue AI-Agent-App, MCP-Funktionen und Subagents erweitert. ^{[S-033 bis S-061]}

Diese Produktdetails sind schnell veraltend. Für das Sachbuch sollten deshalb dauerhafte Prinzipien wie Idempotenz, Zustandsmodelle und Freigabepunkte erklärt werden; Tool-Screenshots, Limits und konkrete Agentenfeatures gehören in aktualisierbare Zusatzmaterialien.

Agenten: die neue Grenze liegt bei Zuverlässigkeit

Agentenbenchmarks zeigen schnell wachsende Fähigkeiten, aber auch erhebliche methodische Probleme. WebArena dokumentierte historisch eine große Lücke zu Menschen. tau-bench machte wiederholte Zuverlässigkeit mit pass^k explizit. 2026er Arbeiten auditieren Benchmarks selbst und zeigen, dass vermeintliche Agentenfehler teilweise aus defekten Aufgaben oder Fehlbewertungen stammen können. ^{[S-073, S-074, S-081 bis S-095]}

Daraus folgt keine pauschale Ablehnung agentischer Automation. Es folgt eine höhere Beweisanforderung. Ein Agent, der dynamisch E-Mail, CRM, Dateien und Kalender verändert, muss auf Trajektorien, Zustandsänderungen, Berechtigungen, Wiederholbarkeit und Recovery geprüft werden. Endantwortqualität allein reicht nicht. ^{[S-077, S-090]}

Reale Fälle: Quellenstärke ernst nehmen

Dieses Dossier enthält 20 dokumentierte Praxisfälle. Sie reichen von offiziellen GAO- und UK-Regierungsquellen über wissenschaftliche Fallstudien bis zu Microsoft-Kundenstories. Anbieterfälle sind wertvoll, weil sie reale Architekturen zeigen. Ihre ROI-Zahlen sind aber häufig Anbieter-/Kundenangaben. Uber berichtet beispielsweise in einer Microsoft-Fallstudie bis zu 150.000 zu kategorisierende Menüpositionen pro Tag und potenzielle Einsparungen von mehr als 5 Mio. USD jährlich; das ist kein unabhängiger Auditbefund. ^[S-099]

GAO ist methodisch anders gelagert: Der Prüfbericht dokumentiert konkrete Projektkosten mehrerer DHS-RPA-Projekte. Auch diese Kosten beweisen jedoch nicht automatisch den Nutzen. Genau diese Trennung zwischen *Implementierung*, *Kosten* und *Wirkung* muss im späteren Buch beibehalten werden. ^[S-106]

Praktische Konsequenz für Unternehmen

Die empfohlene Reihenfolge lautet:

1. Prozess und gewünschtes Ergebnis definieren.
2. Reale Varianten und Datenqualität verstehen.
3. Regeln, Ausnahmen und Fehlerfolgen quantifizieren.
4. Erst dann entscheiden, ob API, Workflow, RPA, AI oder Agent nötig ist.
5. Den probabilistischen Teil so klein wie möglich halten.
6. Irreversible Aktionen durch Regeln, Berechtigungen und Freigaben absichern.
7. Failure Paths vor dem Go-live testen.
8. Fachliche End-to-End-Metriken statt Demo-Erfolg messen.
9. Änderungen von Modellen, Connectors und Plattformen versioniert behandeln.
10. Nur dann mehr Autonomie hinzufügen, wenn zusätzlicher Nutzen messbar ist.

Das Ziel ist nicht maximale Automatisierung, sondern ein wirtschaftlich tragfähiger, kontrollierbarer Prozess. ^{[S-005 bis S-013, S-030, S-075]}

Die 50 wichtigsten Kernaussagen

Methodik, Evidenzhierarchie und Recherchegrenzen

Recherchefrage

Das Dossier untersucht, wann klassische Workflow-/RPA-Automatisierung ausreicht, wann AI-Komponenten sinnvoll werden und wann Agentenautonomie einen zusätzlichen Nutzen rechtfertigt. Zusätzlich wird betrachtet, wie Process Mining und Task Mining Automationsentscheidungen vorbereiten und welche technischen Reliability-Muster für produktive Workflows erforderlich sind.

Evidenzhierarchie

1. Standards und offizielle Prüf-/Behördenquellen: OMG, OASIS, GAO, OECD, UK Government.
2. Peer-reviewte Forschung und systematische Reviews: RPA, Process Mining, Governance und Wartbarkeit.
3. Forschungs-Preprints: besonders bei Agenten, Computer Use und 2026er Benchmarks; ausdrücklich als vorläufig gekennzeichnet.
4. Anbieter-Engineering-Dokumentation: n8n, Make, Temporal, Microsoft, Anthropic, OpenAI. Gut für konkrete Produkt- und Implementierungsmechanismen, nicht als neutraler Marktvergleich.
5. Anbieter-/Kundenfallstudien: geeignet für dokumentierte Architekturen; Nutzen- und ROI-Zahlen sind als Anbieterangaben gekennzeichnet.

Aktualität

Stichtag ist 7. August 2026. Toolfeatures, Modellnamen, Agentenbenchmarks, Connectoren, Preise und Plattformlimits gelten als schnell veraltend. Zeitlose Grundlagen – BPMN, Process Mining, Idempotenz, Retry, RPA-Grundprinzipien – werden von Produktmomentaufnahmen getrennt.

Was dieses Dossier bewusst nicht behauptet

• Es gibt kein universelles Ranking von n8n, Make, Power Automate, UiPath, Temporal oder anderen Plattformen.
• Es wird kein ROI aus Anbieterfallstudien verallgemeinert.
• Es wird kein einzelner Agentenbenchmark als allgemeine Prozesszuverlässigkeit interpretiert.
• Es wird nicht behauptet, dass agentische Systeme klassische Workflows ersetzen.
• Es wird nicht behauptet, dass RPA zwingend veraltet ist.

Recherchegrenzen

Ein großer Teil aktueller Agentenforschung liegt 2026 als Preprint vor. Viele industrielle Automationsfälle werden nur von Plattformanbietern veröffentlicht. Unabhängige Langzeitstudien zu Wartungsaufwand und realisiertem ROI agentischer Automation sind wesentlich dünner als die öffentliche Produktkommunikation. Wo Quellen keine unabhängige Wirkungsmessung zulassen, wird dies ausdrücklich gesagt.

Begriffliche Landkarte: Prozess, Workflow, BPA, RPA und Agent

Prozess ist nicht dasselbe wie Workflow

Ein Geschäftsprozess beschreibt eine fachliche Abfolge von Aktivitäten, Entscheidungen, Rollen, Informationen und Ergebnissen. Ein Workflow ist die ausführbare oder zumindest technisch spezifizierte Steuerung eines Teils dieses Prozesses. BPMN 2.0.2 stellt dafür eine standardisierte Notation bereit. Sie unterscheidet unter anderem Ereignisse, Aktivitäten, Gateways, Nachrichtenflüsse und Pools/Lanes. Für die Buchreihe ist diese Trennung wichtig: Wer einen Prozess „automatisiert“, automatisiert in der Praxis häufig nur einzelne Workflow-Abschnitte. ^[S-001]

Business Process Automation (BPA) ist ein Oberbegriff. Darunter können klassische Workflow-Engines, Skripte, Integrationsplattformen, RPA, Dokumentenverarbeitung und agentische Komponenten fallen. Der Begriff ist in Forschung und Produktmarketing nicht vollständig einheitlich. Deshalb sollte jedes Beispiel konkret benennen, *welcher Teil* eines Prozesses mit *welchem Mechanismus* automatisiert wird. ^[S-097]

RPA

RPA wird in systematischen Reviews als Automatisierung regelbasierter Routineprozesse beschrieben, typischerweise über die Bedienoberfläche bestehender Anwendungen. Der Reiz liegt darin, dass ein Unternehmen nicht zwingend die Zielsoftware verändern muss. Genau diese schwache Kopplung an interne APIs ist zugleich eine strukturelle Schwäche: Ändern sich Masken, Feldpositionen, Dialoge oder Berechtigungen, kann der Bot angepasst werden müssen. ^{[S-003, S-007, S-010]}

RPA ist deshalb weder „alt“ noch automatisch „schlecht“. Es ist ein Integrationsmuster, das dort vernünftig sein kann, wo Systeme keine wirtschaftlich brauchbare Schnittstelle bieten. Die Architekturentscheidung sollte nicht ideologisch zwischen „API“ und „Bot“ getroffen werden, sondern nach Stabilität, Wartbarkeit, Zugriffsmöglichkeiten und Fehlerfolgen. ^{[S-005, S-009, S-101]}

Agentische Prozessautomatisierung

Bei einem klassischen Workflow ist der zulässige Pfad überwiegend vorgegeben. Ein LLM-Agent erhält dagegen Ziel, Kontext und Tools und wählt Teile des Aktionspfads dynamisch. ReAct verband bereits 2022 Reasoning-Spuren mit Aktionen; spätere Tool- und Multi-Agent-Arbeiten erweiterten das Muster. Anbieter wie Anthropic und OpenAI unterscheiden ebenfalls zwischen fest verdrahteten Workflows und Agents. ^{[S-070 bis S-076]}

Diese Flexibilität ist keine kostenlose Leistungssteigerung. Dynamische Pfade vergrößern den Test- und Überwachungsraum. Für Prozesse mit hoher finanzieller, rechtlicher oder operativer Wirkung ist deshalb nicht die Frage „Kann ein Agent das?“, sondern „Welche Entscheidung darf er selbst treffen, welche Aktion darf er selbst ausführen, wie wird ein Fehler erkannt und wie wird der Prozess sicher fortgesetzt?“ ^{[S-074, S-077, S-090]}

Deterministisch versus generativ: die zentrale Architekturentscheidung

Deterministische Automatisierung

Deterministisch bedeutet hier nicht, dass jedes externe System immer denselben technischen Zustand liefert. Gemeint ist: Die Entscheidungslogik des Workflows ist vorgegeben. Wenn Bedingung A erfüllt ist, folgt Pfad B; wenn nicht, folgt Pfad C. Solche Abläufe sind besonders attraktiv, wenn Daten strukturiert, Regeln stabil, Ausnahmefälle begrenzt und Fehlerwirkungen klar sind. ^{[S-001, S-003]}

Typische Beispiele sind:

• Daten zwischen zwei APIs synchronisieren;
• eine Rechnung nach festem Kontierungsregelwerk routen;
• bei Überschreitung einer Frist eine Erinnerung senden;
• einen Datensatz nach eindeutigem Schlüssel aktualisieren;
• PDF-Dateien nach festen Metadaten benennen und ablegen;
• einen bereits fachlich freigegebenen Datensatz in ein Zielsystem schreiben.

Der Vorteil ist nicht „Intelligenzlosigkeit“, sondern Prüfbarkeit. Regeln können versioniert, mit Testfällen abgedeckt und bei Bedarf gezielt geändert werden. Der Nachteil: Unstrukturierte Sprache, neue Varianten und semantische Mehrdeutigkeit müssen explizit aufgefangen werden.

Generative oder probabilistische Komponenten

LLMs und andere ML-Modelle werden interessant, sobald Inputs nicht zuverlässig durch feste Regeln erschlossen werden können. Das betrifft etwa freie E-Mails, Dokumente, Sprachtranskripte, Bedeutungsähnlichkeit, Entwürfe oder flexible Klassifikation. Dokumentenreferenzarchitekturen von Microsoft kombinieren AI-Extraktion ausdrücklich mit Validierung, menschlicher Prüfung, Retry und Monitoring. ^{[S-030 bis S-032]}

Der Fehler besteht darin, aus „AI kann diesen unstrukturierten Schritt lösen“ abzuleiten, der *gesamte Prozess* müsse generativ werden. Eine robuste Architektur kann zum Beispiel so aussehen:

1. Eingang per Webhook oder Queue.
2. Dateiformat und Absender deterministisch prüfen.
3. AI extrahiert Felder aus dem Dokument.
4. Schema- und Plausibilitätsprüfungen laufen deterministisch.
5. Unsichere oder widersprüchliche Fälle gehen in Human Review.
6. Freigegebene Daten werden deterministisch verbucht.
7. Ergebnis und Auditdaten werden protokolliert.

Das ist nicht weniger „KI“. Es ist eine Architektur, die probabilistische Fähigkeit dort nutzt, wo sie Nutzen stiftet, und ihre Unsicherheit begrenzt. ^{[S-030, S-100, S-111]}

Wann Regeln reichen

Regeln reichen häufig, wenn alle folgenden Punkte weitgehend erfüllt sind:

• Eingangsdaten besitzen ein stabiles Schema;
• Entscheidungskriterien sind explizit formulierbar;
• dieselben Inputs sollen dieselben fachlichen Entscheidungen erzeugen;
• Ausnahmen sind bekannt und selten;
• externe Systeme besitzen stabile APIs oder robuste Schnittstellen;
• Nachvollziehbarkeit ist wichtiger als sprachliche Flexibilität;
• Fehler lassen sich durch Tests vollständig oder weitgehend abdecken.

AI wird eher sinnvoll, wenn mindestens ein relevanter Engpass semantisch oder variantenreich ist: unstrukturierte Dokumente, freie Kommunikation, Bedeutungszuordnung, flexible Extraktion oder Entwurf. Agentenautonomie wird erst dann begründbar, wenn die Reihenfolge der Schritte selbst nicht sinnvoll vorab festgelegt werden kann und dynamische Toolwahl einen messbaren Zusatznutzen bringt. ^{[S-075, S-076, S-098]}

Architekturbausteine einer belastbaren Automatisierung

Trigger: Zeit, Event, Webhook und Polling

Ein Workflow beginnt mit einem auslösenden Ereignis. Zeitpläne sind einfach, können aber unnötige Leerlaufabfragen erzeugen. Webhooks reagieren ereignisnah, setzen aber eine verlässliche Zustellung und eine Strategie für Lastspitzen voraus. Polling ist dort nötig, wo das Quellsystem keine Events liefert. Make und n8n dokumentieren alle diese Muster; ihre konkreten Limits und Implementierungsdetails ändern sich jedoch schnell. ^{[S-044, S-054, S-057]}

Queues und Entkopplung

Queues trennen Eingang und Verarbeitung. Das kann Lastspitzen glätten und Worker skalierbar machen. n8n dokumentiert hierfür einen Queue-Modus; AMQP standardisiert nachrichtenorientierte Kommunikation. Die fachliche Zuverlässigkeit entsteht aber nicht durch die Queue allein. Der Prozess muss weiterhin definieren, was bei Duplikaten, Zeitüberschreitungen, vergifteten Nachrichten oder dauerhaft fehlerhaften Zielsystemen geschieht. ^{[S-036, S-117]}

Idempotenz

Ein Schritt ist idempotent, wenn Wiederholung mit demselben fachlichen Auftrag nicht zu einem unerwünschten zusätzlichen Seiteneffekt führt. Das ist für Retries zentral. Ein Beispiel: „Setze Status auf bezahlt“ kann idempotent implementiert werden; „Überweise 500 Euro“ ist es ohne zusätzliche Transaktions- oder Idempotenzlogik nicht. Temporal hebt Idempotenz im Zusammenhang mit Activities und Saga-Kompensationen ausdrücklich hervor. ^{[S-064, S-068, S-069]}

Praktische Muster:

• fachlicher Idempotency-Key pro Auftrag;
• Unique Constraint im Zielsystem;
• Check-before-write nur, wenn Race Conditions berücksichtigt sind;
• Upsert statt blindem Insert;
• dedizierte Outbox-/Inbox-Tabellen;
• Speicherung externer Transaktions-IDs;
• Statusmaschine statt lose Folge von Einzelschritten.

Retry, Backoff und Timeout

Ein Retry ist nur für Fehler sinnvoll, die sich durch Wiederholung plausibel beheben können. Validierungsfehler oder fachlich unzulässige Daten werden durch zehn Wiederholungen nicht besser. Netzwerkfehler und temporäre Rate-Limits dagegen häufig schon. Deshalb sollten Fehlerklassen unterschieden werden. Make und n8n dokumentieren eigene Mechanismen für Rate Limits und unvollständige Ausführungen; Temporal beschreibt Retry- und Timeout-Muster für durable Workflows. ^{[S-039, S-050, S-055, S-060, S-065, S-068]}

Reihenfolge und Parallelität

Parallelität erhöht Durchsatz, kann aber fachliche Reihenfolgen verletzen. Zwei Updates desselben Kundenkontos dürfen unter Umständen nicht beliebig vertauscht werden. Make weist darauf hin, dass Instant-Webhooks standardmäßig parallel verarbeitet werden können und Reihenfolge explizit konfiguriert werden kann; n8n bietet Concurrency-Kontrollen. ^{[S-038, S-051, S-054]}

Kompensation statt magischem Rollback

Wenn ein Prozess fünf externe Systeme verändert, existiert häufig keine gemeinsame ACID-Transaktion. Scheitert Schritt fünf, können Schritte eins bis vier bereits wirksam sein. Das Saga-Muster behandelt solche Fälle mit fachlichen Kompensationen. „Hotel stornieren“ ist dabei nicht dasselbe wie „Datenbanktransaction rollback“: Die Kompensation ist eine neue reale Aktion mit eigenen Fehlerfällen. ^[S-064]

Observability

Ein Produktionsworkflow braucht mindestens:

• eindeutige Ausführungs-ID;
• fachliche Korrelations-ID;
• Start-/Endzeit;
• Schrittstatus;
• Fehlerklasse;
• Retry-Zahl;
• verarbeitete Objekt-ID;
• Modell-/Prompt-/Workflow-Version bei AI-Schritten;
• menschliche Freigabe, falls vorhanden;
• Endergebnis und Rework-Status.

n8n und Make stellen Ausführungs-, Audit- und Szenariologs bereit. Dass eine Plattform Logs hat, beantwortet aber nicht, welche Daten darin gespeichert werden dürfen oder wie lange sie aufzubewahren sind. Diese Fragen gehören in die Datenschutz- und Governance-Dossiers. ^{[S-045, S-058, S-059]}

RPA und Legacy-Automatisierung

Warum RPA trotz APIs nicht verschwindet

Unternehmen besitzen historisch gewachsene ERP-, Host-, Desktop- und Branchenanwendungen, die keine moderne API bereitstellen oder deren Änderung unverhältnismäßig teuer wäre. Hier kann UI-RPA eine pragmatische Brücke sein. Komatsu beschreibt etwa eine Architektur, in der Cloud-Automation und AI-Dokumentenextraktion mit Desktop-RPA verbunden werden, um ein Legacy-AS/400-System zu bedienen. ^{[S-101, S-102]}

Die Wartbarkeitsfalle

Die Forschung dokumentiert wiederkehrende RPA-Probleme: Bots können als „Band-Aid“ über schlechte Prozesse gelegt werden; Kosten und Governance werden unterschätzt; UI-Änderungen brechen Automationen; Know-how wandert vom Fachprozess in Bot-Skripte. Das bedeutet nicht, RPA zu vermeiden, sondern RPA-Schulden sichtbar zu machen. ^{[S-007, S-010, S-013, S-014]}

Für jedes UI-RPA sollte dokumentiert sein:

• Warum keine API genutzt wird;
• welche Oberfläche/Version automatisiert wird;
• wer Änderungen am Zielsystem meldet;
• welche Testfälle nach Updates laufen;
• wie der Bot bei unbekannten Dialogen stoppt;
• wer Prozesswissen besitzt;
• wie ein manueller Fallback funktioniert.

Auswahl geeigneter RPA-Kandidaten

Ein guter RPA-Kandidat ist nicht einfach „viel manuelle Arbeit“. Typisch günstig sind hohe Wiederholungszahl, stabile Eingaben, wenige Varianten, klare Regeln, geringe Änderungsfrequenz und technisch verlässliche Oberflächen. Schlecht sind Prozesse mit vielen impliziten Entscheidungen, häufigem Layoutwechsel, unvollständigen Daten und hoher Fehlerwirkung. ^{[S-005, S-006, S-009, S-011]}

n8n: aktueller Produktstand und belastbare Einordnung

Status: ANBIETERDOKUMENTATION. Dieser Abschnitt ist eine Produktmomentaufnahme zum 7. August 2026 und muss vor Veröffentlichung aktualisiert werden.

n8n positioniert sich als Workflow-Automationsplattform, die API-Integrationen, Code und AI-Funktionen kombiniert. Die Dokumentation beschreibt Cloud- und Self-Hosting-Varianten sowie AI-Knoten und Tool-Nutzung. ^{[S-033 bis S-035]}

Für robuste Produktionsworkflows relevant sind insbesondere:

• Queue- und Worker-Betrieb für Skalierung ^{[S-036, S-037]};
• Concurrency-Kontrollen ^[S-038];
• Rate-Limit-Behandlung ^[S-039];
• Ausführungshistorie und Retry fehlgeschlagener Workflows ^{[S-040 bis S-042]};
• Sub-Workflows zur Modularisierung ^[S-043];
• Webhooks für ereignisgetriebene Abläufe ^[S-044];
• Execution-Data- und externe Speicheroptionen ^{[S-045, S-046]};
• AI-Guardrails und Metriken ^{[S-041, S-047]};
• Human Review für bestimmte Agent-Tool-Aufrufe ^[S-048];
• Git-basierte Umgebungen/Source-Control-Mechanismen ^[S-049].

Ein wichtiger Lehrpunkt für das Buch ist die Versionsabhängigkeit. Die n8n-Dokumentation zu v2.0 zeigt, dass sich auch fundamentales Ausführungsverhalten ändern kann. Deshalb sollte ein Buch nicht behaupten, „n8n retryt immer automatisch“ oder „n8n garantiert X“, sondern Produktangaben mit Versionsdatum führen und Architekturprinzipien davon trennen. ^{[S-040, S-042]}

n8n kann einfache Integrationen sehr schnell abbilden. Sobald ein Workflow jedoch Geldbewegungen, irreversible Systemänderungen, hohe Last oder autonome Tool-Aufrufe enthält, gelten dieselben Engineering-Fragen wie in Code: Idempotenz, Berechtigungen, Retry-Klassen, Tests, Zustandsmanagement, Rollback/Kompensation und Observability.

Make: aktueller Produktstand und belastbare Einordnung

Status: ANBIETERDOKUMENTATION. Auch dieser Abschnitt ist eine Momentaufnahme.

Make bildet Automationen als Szenarien mit Modulen, Routern, Filtern, Webhooks und Fehlerbehandlung ab. Für robuste Abläufe dokumentiert Make unterschiedliche Error Handler, unvollständige Ausführungen, Reihenfolgeoptionen, Rate-Limit-Behandlung, Data Stores, Scheduling und Audit-/Execution-APIs. ^{[S-050 bis S-061]}

2026 ist besonders schnelllebig: Make veröffentlichte eine neue AI-Agent-App, MCP-Tools, zusätzliche Agentenfunktionen und Subagents. Der Release-Feed dokumentiert zugleich laufende Änderungen von Apps, Modulen und Modellangeboten. Genau deshalb sollten Produktdetails nicht als dauerhafte Definition von „agentischer Automatisierung“ verwendet werden. ^{[S-052, S-053]}

Ein fachlich wichtiger Punkt ist die Parallelität von Webhooks. Ereignisse können schneller eintreffen, als ein Zielsystem sie verarbeitet. Wenn die Reihenfolge für das Geschäftsergebnis relevant ist, muss sie bewusst modelliert werden. Gleiches gilt für Rate-Limits und Fehlerzustände. ^{[S-051, S-054, S-055]}

Der praktische Nutzen einer visuellen Plattform liegt nicht darin, Engineering überflüssig zu machen. Er liegt darin, Integrationen, Datenmapping und Orchestrierung schneller sicht- und änderbar zu machen. Je höher die Kritikalität, desto wichtiger werden trotz visueller Oberfläche Tests, Umgebungen, Zugriffskontrollen und nachvollziehbare Änderungshistorie.

Process Mining: vom Event Log zur Automationsentscheidung

Drei Kernaufgaben

Das Process Mining Manifesto unterscheidet insbesondere Discovery, Conformance und Enhancement. Discovery erzeugt aus Event Logs ein Prozessmodell. Conformance vergleicht beobachtetes Verhalten mit einem Modell. Enhancement nutzt reale Ausführungsdaten zur Verbesserung eines vorhandenen Modells oder Prozesses. ^[S-002]

Für Automation ist Process Mining interessant, weil Unternehmen häufig nicht wissen, wie viele reale Varianten eines vermeintlich einfachen Prozesses existieren. Ein Workshop sagt dann „Rechnungseingang hat fünf Schritte“, während Eventdaten dutzende Schleifen, Nacharbeiten und Sonderpfade zeigen können.

Voraussetzungen

Process Mining benötigt wenigstens:

• Ereignisse;
• Zeitbezug;
• Aktivitätsbezeichnung;
• Zuordnung zu einem Prozessobjekt oder einer object-zentrierten Struktur;
• ausreichend konsistente Semantik.

Schlechte Logs erzeugen präzise Visualisierungen schlechter Daten. Besonders problematisch sind fehlende Ereignisse, uneinheitliche Zeitstempel, technische statt fachlicher Aktivitätsnamen und falsche Case-Zuordnungen. Die RPA/PM-Review von El-Gharib und Amyot beschreibt die Vorverarbeitung von Interaction Logs als zentrale Herausforderung. ^[S-004]

Was Process Mining nicht beweist

Process Mining kann zeigen, dass Variante B länger dauert oder häufiger zurückspringt. Es beweist nicht automatisch, *warum* das passiert oder ob Automation die Ursache beseitigt. Denkbar sind beispielsweise fehlende Stammdaten, Lieferantenqualität, rechtliche Prüfpflichten oder bewusste manuelle Kontrollen. Prozessdaten sind Ausgangspunkt für Hypothesen, nicht Ersatz für Fachanalyse.

Object-centric Process Mining

Klassisches Process Mining zwingt oft eine Case-ID auf den Prozess. In Procure-to-Pay interagieren jedoch Bestellung, Bestellpositionen, Lieferung, Rechnung und Zahlung. OCEL 2.0 und object-centric Process Mining modellieren mehrere Objekte und Beziehungen. Das kann Doppelzählungen und künstliche Prozesspfade reduzieren, erhöht aber Anforderungen an Datenmodell und Interpretation. ^{[S-019 bis S-025]}

Task Mining: was Menschen am Bildschirm tatsächlich tun

Task Mining zeichnet feingranulare Interaktionen wie Klicks, Eingaben und Anwendungsschritte auf, um Routinevarianten und Automationskandidaten zu erkennen. Microsoft grenzt Task Mining von Process Mining ab: Process Mining arbeitet stärker auf Ereignisdaten von Systemen; Task Mining fokussiert Desktop-Aktivitäten. ^{[S-027, S-120]}

Der methodische Nutzen liegt auf der Hand: Ein Team kann sagen, es kopiere „ein paar Werte“ aus einer E-Mail ins ERP. Die Aufzeichnung kann zeigen, dass dafür fünf Programme, mehrere Suchschritte und zahlreiche Korrekturen nötig sind. Daraus kann eine bessere Integrations- oder RPA-Architektur entstehen.

Gleichzeitig ist Task Mining organisatorisch sensibel. Die Daten können sehr detailliert offenlegen, wie Beschäftigte arbeiten. Die technische Möglichkeit zur Aufzeichnung ist deshalb nicht gleichbedeutend mit rechtlicher oder organisatorischer Zulässigkeit. Datenschutz, Zweckbindung, Transparenz, Mitbestimmung und Zugriff auf Rohaufzeichnungen sind separat zu prüfen; diese Vertiefung gehört in Dossiers 1 und 5.

Automationskandidaten aus Task Mining sollten nicht allein nach Klickzahl priorisiert werden. Ein seltener, aber fehlerträchtiger 30-Minuten-Prozess kann wichtiger sein als ein häufiges Zwei-Sekunden-Makro. Entscheidend sind Volumen, Fehlerkosten, Wartezeit, Ausnahmen, Änderungsfrequenz und End-to-End-Nutzen.

Agenten: wann dynamische Toolwahl sinnvoll wird

Workflow oder Agent?

Anthropic beschreibt Workflows als Systeme, bei denen LLMs und Tools über vordefinierte Codepfade orchestriert werden, und Agents als Systeme, bei denen LLMs Prozess und Tool-Nutzung dynamischer steuern. Diese Anbieterdefinition ist praktisch nützlich, aber keine rechtlich oder wissenschaftlich verbindliche Taxonomie. ^[S-075]

Ein Agent ist plausibel, wenn:

• der nächste Schritt erst aus dem aktuellen Zustand ableitbar ist;
• viele Tools existieren und ihre Auswahl situationsabhängig ist;
• offene Recherche oder Diagnose nötig ist;
• der Prozess mit starren Verzweigungen unverhältnismäßig komplex würde;
• der Nutzen der Flexibilität die höheren Test- und Kontrollkosten rechtfertigt.

Ein Agent ist meist unnötig, wenn:

• jeder Schritt vorher bekannt ist;
• nur ein API-Aufruf oder eine feste Sequenz gebraucht wird;
• eine finanzielle Buchung nach festen Regeln erfolgen soll;
• das System bei gleichem Input zwingend denselben Pfad nehmen muss;
• jede Toolaktion vorab genehmigt werden muss und die Reihenfolge ohnehin feststeht.

Evaluation statt Demo

Agenten sehen in einer Demo oft überzeugend aus, weil ein erfolgreicher Pfad sichtbar wird. Für Produktion zählt die Verteilung über viele Fälle. tau-bench führte deshalb pass^k ein: Ein System, das einen Fall einmal löst, kann über Wiederholungen inkonsistent sein. ^[S-074]

2026 wird zusätzlich sichtbar, dass selbst Benchmarks fehlerhaft sein können. Eine Audit-Arbeit zu Computer-Use-Agents berichtete bei 150 öffentlich als fehlgeschlagen bewerteten Trajektorien 15,3 Prozent problematische Fail-Verdikte, darunter False Negatives und defekte Aufgaben. Das ist ein Preprint und muss aktualisiert werden, aber die methodische Botschaft ist robust: Eval-Fehler sind selbst ein Risiko. ^[S-086]

Was gemessen werden sollte

Für produktive Agenten reichen „Task solved“ und Modellscore nicht. Sinnvolle Ebenen sind:

1. Endzustand: Ist das fachliche Ziel korrekt erreicht?
2. Pfad: Wurden verbotene oder unnötige Aktionen ausgeführt?
3. Daten: Wurden richtige Objekte gelesen und geschrieben?
4. Policy: Wurden Berechtigungen und Freigaben eingehalten?
5. Wiederholbarkeit: Wie stabil ist das Ergebnis über mehrere Läufe?
6. Kosten: Tokens, API-Aufrufe, Laufzeit, menschliches Rework.
7. Recoverability: Kann nach Teilfehlern sicher fortgesetzt werden?
8. Provenienz: Ist nachvollziehbar, welche Evidenz zu welcher Aktion führte? ^{[S-077, S-082, S-090]}

Multi-Agent-Systeme

Multi-Agent-Systeme können Recherche parallelisieren oder Rollen trennen. AutoGen und spätere Arbeiten untersuchen solche Architekturen; Anthropic beschreibt ein produktives Multi-Agent-Recherche-System. Die zusätzliche Koordination schafft jedoch neue Failure Modes: doppelte Arbeit, widersprüchliche Zwischenergebnisse, Kostenexplosion und Fehler bei Übergaben. ^{[S-072, S-080, S-095]}

Für Unternehmen sollte daher nicht „mehr Agents = mehr Intelligenz“ gelten, sondern: Jede zusätzliche Agentenrolle braucht einen belegbaren funktionalen Zweck.

Human-in-the-loop: Kontrolle als Prozessbaustein

Human-in-the-loop ist kein pauschales Sicherheitslabel. Ein Mensch hilft nur, wenn er die fragliche Information sehen, verstehen, prüfen und tatsächlich zurückweisen kann. In Workflows sollte daher definiert werden:

• Was wird geprüft?
• Wann wird geprüft?
• Wer darf freigeben?
• Welche Daten sieht die Person?
• Welche Frist gilt?
• Was passiert bei Nichtreaktion?
• Kann die Entscheidung geändert oder zurückgesetzt werden?
• Wie wird die Freigabe protokolliert?

Temporal dokumentiert ein Approval Pattern; n8n weist bei bestimmten Tool-Aufrufen auf Human Review hin. Microsofts Dokumentenreferenzarchitektur routet Fälle zur manuellen Prüfung und Korrektur. ^{[S-030, S-048, S-066]}

Ein typischer Fehler ist Automation Bias: Die Person sieht eine AI-Empfehlung, prüft sie aber nur oberflächlich und bestätigt fast alles. Deshalb können stichprobenbasierte Blindprüfungen, begründete Ablehnungsfelder und separate Qualitätskontrollen sinnvoll sein. Die konkrete arbeitspsychologische und rechtliche Bewertung ist nicht Gegenstand dieses Dossiers, gehört aber in Governance und Arbeitsmarkt/Kompetenz.

Testen, Versionieren und Betreiben

Tests müssen die reale Prozesslogik abdecken

Für einen Workflow sind mindestens vier Testebenen zu unterscheiden:

• Unit-/Modultest: einzelne Transformation oder Regel;
• Integrationstest: reale oder simulierte API-/Systemgrenze;
• End-to-End-Test: gesamter fachlicher Ablauf;
• Failure-Test: Zeitüberschreitung, Duplikat, falsches Format, Rate Limit, Zielsystem offline, menschliche Ablehnung.

Bei AI-Komponenten kommen Evaluationssets hinzu. n8n dokumentiert eigene Metriken für AI-Workflows; Anthropic beschreibt code-basierte, modell-basierte und menschliche Grader. Entscheidend ist nicht der Evaluationsrahmen als Marke, sondern die Qualität der Testfälle. ^{[S-041, S-077]}

Versionierung

Ein produktiver Workflow sollte reproduzierbar beschreiben, mit welcher Version er lief. Bei AI-Schritten gehören dazu mindestens Modellbezeichnung, relevante Parameter, Prompt-/Instruction-Version, Toolset und Wissensstand. Bei klassischen Workflows genügt die Workflowversion allein häufig ebenfalls nicht, weil Connector-Versionen und externe APIs geändert werden können. n8n und Make zeigen 2026, wie schnell Apps, Agentenfeatures und Modelle wechseln. ^{[S-042, S-052]}

Betriebskennzahlen

Technische Erfolgsquote allein ist unzureichend. Ein Workflow kann „grün“ sein und fachlich falsche Daten verbuchen. Empfehlenswert ist eine Kombination aus:

• technische Success Rate;
• fachliche First-Time-Right-Rate;
• Ausnahmequote;
• Rework-Minuten;
• Durchlaufzeit;
• Fehlerkosten;
• Zahl automatischer Retries;
• Wartungsstunden;
• Anteil manueller Freigaben;
• AI-Fehlklassifikationen;
• Kosten pro verarbeitetem Fall.

Diese Kennzahlen verbinden technische Zuverlässigkeit mit dem ROI-Dossier 6. ^{[S-008, S-012]}

Prozessauswahl: eine belastbare Entscheidungsmatrix

Vor der Toolauswahl sollte jeder Automationskandidat entlang derselben Fragen bewertet werden.

Aus den RPA-Frameworks und Implementierungsstudien ergibt sich kein universeller Schwellenwert. Die Faktoren sind jedoch konsistent: Automatisierbarkeit ist eine Kombination aus technischer Machbarkeit, Prozessstabilität, wirtschaftlichem Volumen und Risikoprofil. ^{[S-005, S-006, S-009, S-011, S-013]}

Dokumentierte Praxisfälle: Evidenz statt Demo

Praxisfälle werden in diesem Dossier nach Belegstärke getrennt:

• A – Offizielle Prüf-/Behördenquelle: unabhängiger oder amtlicher Bericht über ein reales System.
• B – Wissenschaftliche Fallstudie: methodisch dokumentierter Forschungsfall.
• C – Anbieter-/Kundenfallstudie: realer Kunde, aber Auswahl und Nutzenkommunikation durch Anbieter; Zahlen nicht automatisch auditiert.
• D – Produktbeispiel: Architektur-/Dokumentationsbeispiel ohne belastbaren Wirksamkeitsnachweis.

Die wichtigste Regel für das spätere Buch lautet: Architekturbeispiele dürfen aus Anbieterfällen stammen; ROI-Zahlen müssen als Anbieter-/Kundenangaben gekennzeichnet bleiben.

20 dokumentierte Automatisierungsfälle

Muster über die Fälle hinweg

Über die Fälle hinweg sind fünf wiederkehrende Muster sichtbar:

1. Hybride Verarbeitung: AI übernimmt Extraktion oder Klassifikation; nachgelagerte Geschäftsregeln bleiben explizit. ^{[S-100, S-101, S-111]}
2. Legacy-Brücken: RPA bleibt dort relevant, wo Zielsysteme keine moderne Integration erlauben. ^[S-101]
3. Human Review: Behörden- und Dokumentenfälle behalten menschliche Prüfschritte für sensible oder unsichere Ergebnisse. ^{[S-030, S-105, S-113]}
4. Schrittweise Reife: Palkeet wird von der OECD als Entwicklung von einzelnen RPA-Nutzungen in Richtung Hyperautomation/ML beschrieben. ^[S-108]
5. Evidenzproblem: Bei Anbieterfällen sind beeindruckende Einsparungen möglich, aber die öffentliche Quelle liefert häufig keine unabhängige Baseline-, Kontrollgruppen- oder Langzeitprüfung. ^{[S-099 bis S-112]}

Für das Buch sollten daher nicht die größten Prozentzahlen im Vordergrund stehen, sondern das Prozessmuster und die Bedingungen, unter denen es funktioniert.

18 Unternehmensszenarien

Bewertungslogik

Ein Szenario wird nicht deshalb agentisch, weil ein LLM beteiligt ist. Ein LLM kann innerhalb eines vollständig vorgegebenen Workflows genau einen Klassifikations- oder Entwurfsschritt übernehmen. Umgekehrt kann ein Agent trotz klar begrenzter Tools hohe Autonomie besitzen, wenn er selbst bestimmt, welchen Schritt er als Nächstes ausführt. Die relevante Achse ist daher Pfadfreiheit, nicht nur Modellnutzung. ^{[S-075, S-076]}

36-stufiger Umsetzungsfahrplan

Entscheidungsbäume: Wann reicht regelbasiert?

Entscheidungsbaum A – von der Aufgabe zur Architektur

Frage 1: Sind Input und Entscheidung vollständig strukturiert?

• Ja -> feste Regeln/API-Workflow zuerst prüfen.
• Nein -> Frage 2.

Frage 2: Ist nur ein einzelner semantischer Schritt unstrukturiert?

• Ja -> AI als eingegrenzten Klassifikations-/Extraktions-/Entwurfsschritt einbauen; Rest deterministisch.
• Nein -> Frage 3.

Frage 3: Ist die Reihenfolge der Arbeitsschritte im Voraus sinnvoll definierbar?

• Ja -> orchestrierter Workflow mit mehreren AI-Schritten.
• Nein -> Agent prüfen.

Frage 4: Darf das System irreversible oder hochwirksame Aktionen autonom ausführen?

• Nein -> Toolrechte einschränken und Approval Gate einbauen.
• Ja -> Risiko, Evals, Recovery und Audit auf höchstem Niveau nachweisen.

Frage 5: Existiert eine stabile API?

• Ja -> API vor UI-Automation priorisieren, sofern wirtschaftlich und funktional sinnvoll.
• Nein -> RPA/Computer Use prüfen, mit höherem Wartungsbudget.

Entscheidungsbaum B – Muss überhaupt automatisiert werden?

1. Ist der Prozess fachlich notwendig?
2. Kann er vereinfacht oder abgeschafft werden?
3. Kann die Quelle so geändert werden, dass fehlerhafte Arbeit gar nicht entsteht?
4. Kann das Zielsystem direkt integriert werden?
5. Erst danach: Welcher Automationsmechanismus ist sinnvoll?

Dieses Vorgehen verhindert den klassischen Fehler, eine technisch beeindruckende Lösung für ein vermeidbares Prozessproblem zu bauen. ^{[S-002, S-007]}

Fehler- und Reliability-Playbook

Illustrative Zuverlässigkeitsrechnung

Zur Veranschaulichung, nicht als empirische Agentenmetrik: Wenn 20 voneinander unabhängige Schritte jeweils mit Wahrscheinlichkeit 0,98 korrekt wären, läge die Wahrscheinlichkeit, dass alle 20 korrekt sind, bei etwa 0,98^20 ≈ 0,668. In realen Workflows sind Fehler nicht unabhängig; die Rechnung zeigt nur, warum lange End-to-End-Ketten eine andere Zuverlässigkeitsfrage darstellen als einzelne gute Modellantworten.

Die praktische Konsequenz lautet: Reduziere die Zahl probabilistischer Entscheidungen, erkenne Fehler früh, mache Zwischenzustände sichtbar und baue Recovery statt Hoffnung.

20 Mythenprüfungen

20 offene Forschungs- und Praxisfragen

50 buchrelevante Faktenkarten

Faktenkarte F-001

• Aussage: Prozessautomatisierung ist nicht gleich KI. Ein vollständig deterministischer Ablauf kann einen Geschäftsprozess automatisieren, ohne ein statistisches Modell zu enthalten.
• Status: GRUNDLAGE
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Begriffe BPA/RPA/Workflow sauber trennen.
• Primär-/Hauptquellen: S-001, S-003, S-097
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-002

• Aussage: RPA wird in der Forschung typischerweise als Automatisierung regelbasierter Routinehandlungen an bestehenden Benutzeroberflächen beschrieben.
• Status: FORSCHUNGSSTAND
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: RPA-Produkte können inzwischen zusätzliche AI-Funktionen enthalten.
• Primär-/Hauptquellen: S-003, S-016
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-003

• Aussage: Process Mining rekonstruiert und analysiert reale Prozessabläufe aus Event Logs; es ist nicht selbst die Automatisierung.
• Status: FORSCHUNGSSTAND
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Datenqualität und Event-Semantik begrenzen die Aussagekraft.
• Primär-/Hauptquellen: S-002, S-026
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-004

• Aussage: Task Mining betrachtet feingranulare Nutzerinteraktionen am Arbeitsplatz und kann Automatisierungskandidaten sichtbar machen.
• Status: ANBIETERDOKUMENTATION / METHODIK
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Aufzeichnung kann Datenschutz- und Beschäftigtenfragen auslösen.
• Primär-/Hauptquellen: S-027, S-120
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-005

• Aussage: Object-centric Process Mining vermeidet die erzwungene Reduktion komplexer Prozesse auf genau eine Case-ID und modelliert mehrere interagierende Objekte.
• Status: FORSCHUNGSSTAND
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Werkzeuge und Datenmodelle entwickeln sich weiter.
• Primär-/Hauptquellen: S-019 bis S-025, S-028
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-006

• Aussage: Stabile Regeln, strukturierte Eingaben und klar definierte Ausnahmen sprechen grundsätzlich für deterministische Automatisierung als Ausgangspunkt.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Kein universelles Gesetz; Entscheidung hängt von Kosten, Risiko und Systemlandschaft ab.
• Primär-/Hauptquellen: S-003, S-005 bis S-013
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-007

• Aussage: Generative Modelle sind besonders dort relevant, wo semantische Interpretation, Klassifikation, Extraktion, Zusammenfassung oder Entwurf erforderlich sind.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Ausgaben müssen auf Prozesszweck und Fehlerfolgen zugeschnitten validiert werden.
• Primär-/Hauptquellen: S-030 bis S-032, S-070, S-098
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-008

• Aussage: Ein hybrides Muster – AI für unstrukturierte Eingaben, deterministische Regeln für Transaktionen – ist in dokumentierten Praxisfällen wiederholt zu sehen.
• Status: PRAXISBEFUND
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Fallstudien beweisen keine allgemeine Überlegenheit.
• Primär-/Hauptquellen: S-030, S-100, S-101, S-111
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-009

• Aussage: Wo eine stabile API existiert, ist API-Integration im Regelfall weniger an Bildschirmdarstellung gekoppelt als UI-RPA.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Legacy-Systeme ohne geeignete API können RPA weiterhin rechtfertigen.
• Primär-/Hauptquellen: S-003, S-007, S-010, S-101
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-010

• Aussage: UI-RPA bleibt für Legacy-Systeme relevant, wenn keine wirtschaftlich nutzbare Schnittstelle verfügbar ist.
• Status: FORSCHUNGS-/PRAXISBEFUND
• Bedeutung für das Buch: Grundlage für die klare Trennung von Prozessmechanik und KI-Hype.
• Einschränkung: Wartungsbedarf bei UI-Änderungen muss eingepreist werden.
• Primär-/Hauptquellen: S-005, S-010, S-101
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-011

• Aussage: Automatisiert man einen schlechten oder unnötig komplexen Prozess unverändert, kann man dessen Ineffizienz technisch verfestigen.
• Status: FORSCHUNGSSTAND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Vor der Automation Prozessziel und Varianten prüfen.
• Primär-/Hauptquellen: S-002, S-007, S-013
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-012

• Aussage: Process Mining kann Discovery, Conformance und Verbesserung unterstützen, ersetzt aber nicht die fachliche Beurteilung, ob ein Prozess sinnvoll ist.
• Status: FORSCHUNGSSTAND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Event Logs zeigen Verhalten, nicht automatisch Ursache oder Geschäftswert.
• Primär-/Hauptquellen: S-002, S-004
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-013

• Aussage: Retries ohne Idempotenz können seiteneffektbehaftete Schritte doppelt ausführen.
• Status: ENGINEERING-GRUNDLAGE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Die konkrete Schutzmaßnahme hängt vom Zielsystem ab.
• Primär-/Hauptquellen: S-064, S-068, S-069
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-014

• Aussage: Timeouts, Backoff und Rate-Limit-Behandlung gehören zu robusten API-Workflows, weil externe Systeme temporär nicht erreichbar oder gedrosselt sein können.
• Status: ENGINEERING-GRUNDLAGE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Produktmechanismen unterscheiden sich.
• Primär-/Hauptquellen: S-039, S-055, S-065, S-068
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-015

• Aussage: Parallelität ist keine reine Performancefrage: Bei zustandsabhängigen Geschäftsvorgängen kann Ausführungsreihenfolge fachlich relevant sein.
• Status: ENGINEERING-GRUNDLAGE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Reihenfolge explizit modellieren, wenn sie fachlich erforderlich ist.
• Primär-/Hauptquellen: S-038, S-051, S-054
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-016

• Aussage: Queues entkoppeln Produzenten und Verarbeitung, erzeugen aber neue Betriebsfragen wie Rückstau, Wiederanlauf und Priorisierung.
• Status: ENGINEERING-GRUNDLAGE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Queue allein garantiert keine fachlich genau-einmalige Verarbeitung.
• Primär-/Hauptquellen: S-036, S-117
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-017

• Aussage: Verteilte Transaktionen benötigen häufig Kompensationslogik, wenn ein vollständiger technischer Rollback über alle beteiligten Systeme nicht möglich ist.
• Status: ENGINEERING-GRUNDLAGE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Kompensation ist fachlich zu definieren und selbst fehlertolerant zu bauen.
• Primär-/Hauptquellen: S-064
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-018

• Aussage: Human-in-the-loop sollte als expliziter Workflow-Zustand mit Zuständigkeit, Frist und Fortsetzung modelliert werden, nicht als informelle E-Mail außerhalb des Prozesses.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Konkrete Tools können Approval-Mechanismen anbieten.
• Primär-/Hauptquellen: S-048, S-066, S-030
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-019

• Aussage: No-Code und Low-Code reduzieren Implementierungshürden, beseitigen aber nicht Anforderungen an Datenmodell, Fehlerbehandlung, Berechtigungen, Tests und Betrieb.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Komplexität verschiebt sich teilweise in Konfiguration und Governance.
• Primär-/Hauptquellen: S-007, S-033 bis S-061
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-020

• Aussage: Produktfeatures von Make und n8n ändern sich schnell und dürfen nicht als zeitlose Architekturwahrheiten behandelt werden.
• Status: ANBIETERBEFUND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Vor Buchveröffentlichung erneut prüfen.
• Primär-/Hauptquellen: S-040, S-042, S-052
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: hoch
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-021

• Aussage: n8n dokumentiert 2026 AI-Agent-Knoten, Tool-Nutzung, Evaluationsmetriken und Human-Review-Muster.
• Status: ANBIETERANGABE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Versions- und planabhängig; kein neutraler Marktvergleich.
• Primär-/Hauptquellen: S-034, S-041, S-048
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: hoch
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-022

• Aussage: Make hat 2026 seine neue AI-Agent-App, MCP-Tools und Subagents erweitert.
• Status: ANBIETERANGABE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Sehr schnell veraltender Produktstand.
• Primär-/Hauptquellen: S-052, S-053
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: hoch
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-023

• Aussage: Fehlerbehandlung ist in Automationsplattformen ein eigener Designbereich und sollte nicht erst nach einem Produktionsfehler ergänzt werden.
• Status: ENGINEERING-GRUNDLAGE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Mechanismen unterscheiden sich nach Plattform.
• Primär-/Hauptquellen: S-050, S-060, S-065
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-024

• Aussage: Ausführungs- und Auditlogs sind für Betrieb, Fehleranalyse und Nachvollziehbarkeit zentral, können aber selbst sensible Daten enthalten.
• Status: ENGINEERING / GOVERNANCE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Datenschutz und Aufbewahrung separat prüfen.
• Primär-/Hauptquellen: S-045, S-058, S-059
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-025

• Aussage: Versionierung und getrennte Umgebungen reduzieren das Risiko, ungetestete Workflow-Änderungen direkt in Produktion zu bringen.
• Status: ENGINEERING-GRUNDLAGE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Konkrete Implementierung toolabhängig.
• Primär-/Hauptquellen: S-049, S-068
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-026

• Aussage: LLM-Agenten unterscheiden sich von festen Workflows dadurch, dass das Modell Teile des Aktionspfads dynamisch auswählt.
• Status: FORSCHUNGS-/ANBIETERDEFINITION
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Grenze ist in realen Produkten fließend.
• Primär-/Hauptquellen: S-070, S-075, S-096
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-027

• Aussage: Je freier ein Agent Schritte und Tools wählen darf, desto größer wird der zu testende Zustands- und Aktionsraum.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Autonomie kann in offenen Aufgaben Nutzen bringen, erhöht aber Evaluationsaufwand.
• Primär-/Hauptquellen: S-077, S-082, S-091
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-028

• Aussage: Ein einmaliger erfolgreicher Agentenlauf belegt keine wiederholbare Prozesszuverlässigkeit.
• Status: FORSCHUNGSSTAND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Mehrfachläufe und End-to-End-Metriken sind erforderlich.
• Primär-/Hauptquellen: S-074, S-077
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-029

• Aussage: tau-bench führte pass^k ein, um konsistente Erfüllung von Tool- und Policy-Aufgaben über Wiederholungen zu messen.
• Status: FORSCHUNGSSTAND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Werte gelten nur für Benchmarkversion, Modell und Scaffold des jeweiligen Experiments.
• Primär-/Hauptquellen: S-074
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-030

• Aussage: Das ursprüngliche WebArena-Ergebnis zeigte eine große Lücke zwischen GPT-4-basiertem Agenten und menschlicher Leistung; dieser Wert ist historisch und kein aktueller Produktbenchmark.
• Status: HISTORISCHER BENCHMARK
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Nicht auf heutige Systeme übertragen.
• Primär-/Hauptquellen: S-073
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: hoch
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-031

• Aussage: Aktuelle 2026er Agentenbenchmarks ändern sich schnell; absolute Werte gehören in eine Refresh-Liste.
• Status: FORSCHUNGSSTAND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Preprints und Evaluationsversionen können sich ändern.
• Primär-/Hauptquellen: S-081 bis S-095
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: hoch
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-032

• Aussage: Ein Audit von Computer-Use-Benchmarks berichtete 2026, dass ein Teil der vermeintlichen Agentenfehler auf fehlerhafte Bewertung oder defekte Aufgaben zurückging.
• Status: PREPRINT-BEFUND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Vor Veröffentlichung Paper-Version und Folgearbeiten erneut prüfen.
• Primär-/Hauptquellen: S-086
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: hoch
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-033

• Aussage: Agenten-Evaluation muss nicht nur Endantworten, sondern auch Zustandsänderungen, Tool-Aufrufe, Richtlinieneinhaltung und Nebenwirkungen prüfen.
• Status: FORSCHUNGS-/ENGINEERINGSTAND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Metriken sind an die reale Aufgabe anzupassen.
• Primär-/Hauptquellen: S-074, S-077, S-090
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-034

• Aussage: Multi-Agent-Systeme können Arbeit parallelisieren oder Rollen spezialisieren, fügen aber Koordination, Übergaben und zusätzliche Fehlerwege hinzu.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Nicht automatisch besser als ein Agent oder ein Workflow.
• Primär-/Hauptquellen: S-072, S-080, S-095
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-035

• Aussage: Die Empfehlung, mit der einfachsten hinreichenden Architektur zu starten, ist gut begründete Engineering-Guidance, aber kein Naturgesetz.
• Status: ANBIETER-GUIDANCE / SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Bei offenen Aufgaben kann höhere Agentenautonomie gerechtfertigt sein.
• Primär-/Hauptquellen: S-075, S-076
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-036

• Aussage: Tool-Outputs und externe Inhalte können unvollständig, widersprüchlich oder manipuliert sein; ein Agent sollte sie nicht automatisch als vertrauenswürdige Steuerbefehle behandeln.
• Status: ENGINEERING / SECURITY-SCHNITTSTELLE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Vertiefte Prompt-Injection-Analyse gehört in Dossier 10.
• Primär-/Hauptquellen: S-079, S-090
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-037

• Aussage: Dokumentenautomation zeigt ein besonders brauchbares Hybridmuster: AI extrahiert, Regeln validieren, Unsicherheit wird an Menschen geroutet, danach folgt deterministische Verbuchung.
• Status: PRAXIS-/ARCHITEKTURBEFUND
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Confidence-Schwellen müssen auf den eigenen Datensatz kalibriert werden.
• Primär-/Hauptquellen: S-030, S-031, S-100, S-111
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-038

• Aussage: Ein Modell-Confidence- oder Anbieter-Score ist nicht automatisch eine kalibrierte Fehlerwahrscheinlichkeit.
• Status: METHODISCHER GRUNDSATZ
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Schwellenwerte müssen empirisch gegen reale Fehlerkosten getestet werden.
• Primär-/Hauptquellen: S-030, S-031, S-077
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-039

• Aussage: Automationskandidaten sollten nach Volumen, Regelstabilität, Ausnahmequote, Datenqualität, Integrationszugang, Fehlerfolge und Änderungsfrequenz priorisiert werden.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Gewichtung ist unternehmensspezifisch.
• Primär-/Hauptquellen: S-005, S-006, S-009, S-013
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-040

• Aussage: Ein hoher manueller Zeitaufwand allein macht einen Prozess nicht zum guten Automationskandidaten, wenn Eingaben chaotisch, Regeln instabil oder Fehlerfolgen hoch sind.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Vorher Standardisierung oder Teilautomation prüfen.
• Primär-/Hauptquellen: S-005 bis S-013
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-041

• Aussage: ECLAIR berichtete in frühen Fallstudien 12–18 Monate Setup, rund 60 % initiale Ausführungsgenauigkeit traditioneller RPA und 40 % End-to-End-Abschluss für das vorgeschlagene FM-System; diese Werte sind kein allgemeiner Marktbenchmark.
• Status: PREPRINT / FALLSTUDIE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Kontext-, System- und Stichprobenabhängig.
• Primär-/Hauptquellen: S-098
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: hoch
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-042

• Aussage: Anbieter-Fallstudien sind nützlich, um reale Architekturmuster zu sehen, aber schwächer für kausale ROI-Aussagen.
• Status: METHODIK
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Nutzenzahlen als Anbieter-/Kundenangaben kennzeichnen.
• Primär-/Hauptquellen: S-099 bis S-112
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-043

• Aussage: Uber dokumentiert in einer Microsoft-Fallstudie ein hybrides Tax-Categorization-Setup mit RPA und ML für bis zu 150.000 Menüpositionen pro Tag sowie potenziellen Einsparungen über 5 Mio. USD jährlich; die Werte sind nicht unabhängig auditiert.
• Status: ANBIETER-FALLSTUDIE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Nur im angegebenen Kundensetting verwenden.
• Primär-/Hauptquellen: S-099
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: hoch
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-044

• Aussage: EY PowerMatch dokumentiert ein hybrides Finanzmuster: AI-Extraktion, deterministischer 14-Schritt-Matching-Algorithmus und manuelle Bearbeitung unsicherer Fälle.
• Status: ANBIETER-FALLSTUDIE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Architekturmuster belastbarer als Nutzenbehauptungen.
• Primär-/Hauptquellen: S-100
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-045

• Aussage: Komatsu dokumentiert eine Kette aus Cloud-API, AI-Dokumentenextraktion und Desktop-RPA für ein Legacy-AS/400-System.
• Status: ANBIETER-FALLSTUDIE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Zeigt Nutzen hybrider Integration, nicht allgemeine Performance.
• Primär-/Hauptquellen: S-101, S-102
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-046

• Aussage: GAO dokumentiert bei DHS mehrere RPA-Projekte mit stark unterschiedlichen Ist-Kosten gegenüber ähnlichen ursprünglichen Schätzungen; Projektkosten allein belegen jedoch keinen realisierten Nutzen.
• Status: OFFIZIELLER PRÜFBERICHT
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Kosten und Wirkung getrennt auswerten.
• Primär-/Hauptquellen: S-106
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-047

• Aussage: OECD beschreibt Palkeet als Entwicklung von kleinen RPA-Anwendungen hin zu Hyperautomation und ML im öffentlichen Finanzmanagement.
• Status: INTERGOVERNMENTALER FALL
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Keine allgemeine ROI-Garantie.
• Primär-/Hauptquellen: S-107, S-108
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-048

• Aussage: Offizielle britische Transparenzregister zeigen 2025 reale Korrespondenzsysteme, die Entity Extraction, Klassifikation, Regeln, RPA und menschliche Prüfung kombinieren.
• Status: OFFIZIELLE PRAXISQUELLE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Behördenkontext; Übertragbarkeit auf Unternehmen prüfen.
• Primär-/Hauptquellen: S-105, S-113, S-114
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: mittel
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-049

• Aussage: Automationsqualität sollte mit fachlichen End-to-End-Kennzahlen gemessen werden – nicht nur mit „Workflow erfolgreich“ oder Modellgenauigkeit.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Beispiele: richtige Buchung, vollständiger Fallabschluss, Rework, Fehlerkosten, Durchlaufzeit.
• Primär-/Hauptquellen: S-012, S-041, S-077
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Faktenkarte F-050

• Aussage: Die wirtschaftlich und technisch vernünftige Zielarchitektur ist häufig die kleinste Kombination aus Regeln, Schnittstellen, AI und menschlicher Prüfung, die den geforderten Nutzen bei akzeptablem Risiko erreicht.
• Status: EIGENE SYNTHESE
• Bedeutung für das Buch: Geeignet als belegte Einordnung für Architektur, Praxis oder Risikodarstellung.
• Einschränkung: Muss je Prozess empirisch validiert werden.
• Primär-/Hauptquellen: S-005 bis S-013, S-030, S-075
• Zuletzt geprüft: 7. August 2026
• Aktualisierungsrisiko: niedrig
• Mögliche Verwendung: Kapitel Automatisierungsarchitektur, Fallbeispiel, Mythos oder Geschäftsführer-Checkliste.

Glossar

Activity

Ausführbarer oder fachlicher Arbeitsschritt in einem Prozess.

Agent

System, das mit einem Modell Ziele verfolgt und Tools/Schritte teilweise dynamisch auswählt.

AMQP

Offener Standard für nachrichtenorientierte Middleware.

API

Programmierschnittstelle zwischen Systemen.

Approval Gate

Expliziter Freigabepunkt vor Fortsetzung eines Workflows.

Backoff

Wartezeitstrategie zwischen Wiederholungsversuchen.

BPA

Business Process Automation; Oberbegriff für technische Prozessautomatisierung.

BPM

Business Process Management; Management und Verbesserung von Geschäftsprozessen.

BPMN

Standardisierte grafische Notation für Geschäftsprozesse.

Case ID

Kennung, die Ereignisse einem Prozessfall zuordnet.

Compensation

Fachliche Gegenaktion zur Rücknahme/Abmilderung bereits erfolgter Seiteneffekte.

Concurrency

Gleichzeitige Ausführung mehrerer Vorgänge.

Connector

Vorkonfigurierte Verbindung zu einem externen System/API.

Correlation ID

Kennung, mit der zusammengehörige technische Ereignisse über Systeme verfolgt werden.

Dead Letter Queue

Ablage für Nachrichten, die nach Regeln nicht erfolgreich verarbeitet werden konnten.

Deterministischer Workflow

Workflow mit vorgegebenen Entscheidungs- und Ausführungspfaden.

Event

Ereignis, das einen Zustand oder Prozessschritt markiert.

Event Log

Strukturierte Sammlung von Prozessereignissen.

Exactly once

Zielvorstellung, eine fachliche Wirkung genau einmal zu erzeugen; praktisch oft über Idempotenz und Zustandskontrolle umgesetzt.

Execution

Ein konkreter Lauf eines Workflows.

Fallback

Alternativer Pfad, wenn der primäre Mechanismus ausfällt.

First-Time-Right

Anteil der Fälle, die ohne Nacharbeit fachlich korrekt abgeschlossen werden.

Guardrail

Technische oder organisatorische Begrenzung zulässiger Aktionen/Ausgaben.

Human-in-the-loop

Menschliche Prüfung oder Entscheidung innerhalb des Automationsprozesses.

Idempotency Key

Eindeutige Kennung, mit der wiederholte Verarbeitung desselben Auftrags erkannt wird.

Idempotenz

Eigenschaft, dass Wiederholung nicht zu unerwünschten zusätzlichen Seiteneffekten führt.

iPaaS

Integration Platform as a Service; Plattform für Cloud-/API-Integration.

LLM

Large Language Model.

Low-Code

Entwicklung mit hohem Anteil visueller/konfigurativer Bausteine und ergänzendem Code.

No-Code

Konfiguration ohne zwingendes Schreiben klassischen Programmcodes; technische Komplexität bleibt bestehen.

Object-centric Process Mining

Process Mining mit mehreren interagierenden Prozessobjekten statt einer einzigen Case-ID.

OCEL

Object-Centric Event Log.

Orchestrierung

Koordination mehrerer Dienste, Schritte oder Agenten.

Polling

Regelmäßiges Abfragen einer Quelle auf neue Daten.

Process Discovery

Ableitung eines Prozessmodells aus Event Logs.

Process Mining

Analyse realer Prozesse anhand von Ereignisdaten.

Queue

Puffer für zu verarbeitende Nachrichten/Aufträge.

Rate Limit

Begrenzung der zulässigen API-Aufrufe innerhalb eines Zeitfensters.

RAG

Retrieval-Augmented Generation; Einbindung externer Wissensquellen in Generierung.

Retry

Erneuter Ausführungsversuch nach einem Fehler.

RPA

Robotic Process Automation; softwarebasierte Ausführung regelbasierter Interaktionen, oft über Benutzeroberflächen.

Saga

Muster für verteilte Geschäftsprozesse mit lokalen Transaktionen und Kompensationen.

Scenario

Bezeichnung eines Automationsworkflows in Make.

Schema Validation

Prüfung, ob Daten eine vorgegebene Struktur und Datentypen erfüllen.

Side Effect

Änderung außerhalb der reinen Berechnung, z.B. E-Mail senden, Geld buchen, Datensatz ändern.

SLA

Service Level Agreement bzw. definierte Leistungs-/Reaktionsanforderung.

State Machine

Modell, das zulässige Zustände und Übergänge explizit definiert.

Task Mining

Analyse aufgezeichneter Nutzerinteraktionen zur Erkennung von Aufgabenmustern.

Timeout

Maximale Warte- oder Ausführungsdauer eines Schritts.

Tool Calling

Modellgesteuerter Aufruf definierter externer Funktionen/Werkzeuge.

Trace

Zusammenhängende technische Spur eines Prozesslaufs.

Transaction

Logisch zusammengehörige Zustandsänderung mit definierten Konsistenzregeln.

Trigger

Auslöser eines Workflows.

UI Automation

Automatisierung über eine grafische Benutzeroberfläche.

Webhook

HTTP-basierter Ereignisaufruf von einem System an ein anderes.

Worker

Prozess/Instanz, die Jobs ausführt.

Workflow

Technisch oder formal definierte Abfolge von Aktivitäten und Entscheidungen.

Workflow Engine

Laufzeitumgebung zur Steuerung von Workflows.

Workflow Version

Kennung eines reproduzierbaren Workflow-Stands.

Conformance Checking

Vergleich von beobachtetem Prozessverhalten mit einem Sollmodell.

Process Enhancement

Verbesserung eines Prozessmodells mithilfe realer Ausführungsdaten.

Process Variant

Tatsächlich beobachtete Ablaufvariante eines Prozesses.

Rework

Nacharbeit nach fehlerhafter oder unvollständiger Bearbeitung.

Provenienz

Nachweis, welche Daten, Quellen und Aktionen zu einem Ergebnis geführt haben.

Eval

Systematischer Test einer AI-/Agentenfunktion gegen definierte Aufgaben und Grader.

Pass^k

Metrik für konsistenten Erfolg über mehrere Wiederholungen.

Subagent

Agent, der als spezialisierter Teil eines übergeordneten Agentensystems eingesetzt wird.

Beleg- und Quellenmatrix

Vollständiges Quellenregister

Schnell veraltende Informationen und Qualitätsbericht

Refresh-Liste

Qualitätsbericht

Quellenanzahl: 120 dokumentierte Quellen. Standards/amtliche/intergovernmentale Quellen: OMG, OASIS, GAO, OECD, UK Government. Forschungsquellen: systematische Reviews, peer-reviewte Facharbeiten und klar gekennzeichnete Preprints. Anbieterquellen: n8n, Make, Temporal, Microsoft, Anthropic, OpenAI; als Produkt-/Engineeringquellen gekennzeichnet. Dokumentierte Praxisfälle: 20, davon amtliche/Prüfquellen, wissenschaftliche Fälle, Anbieterfälle und Referenzarchitekturen. Kernaussagen/Faktenkarten: 50. Unternehmensszenarien: 18. Mythenprüfungen: 20. Offene Fragen: 20. Umsetzungsfahrplan: 36 Schritte.

Bekannte Schwächen des Dossiers

1. Agentenforschung 2026 ist vorläufig. Mehrere relevante Quellen sind Preprints. Absolute Benchmarkwerte müssen vor Veröffentlichung erneuert werden.
2. Industrielle Wirksamkeitsdaten sind selektiv. Viele konkrete Unternehmensfälle werden von Plattformanbietern veröffentlicht; unabhängige Langzeitmessungen sind seltener.
3. Toolvergleich ist bewusst unvollständig. Das Dossier untersucht Make und n8n, weil sie im Auftrag ausdrücklich genannt wurden, und ergänzt Microsoft/Temporal als Architektur- und Fallquellen. Es ist kein Marktüberblick aller Automationsplattformen.
4. Recht und Security sind nur Schnittstellen. Datenschutz, AI Act, Haftung, Governance und Prompt Injection werden in Dossiers 1, 2, 4, 5 und 10 vertieft.
5. ROI wird nicht erneut vollständig behandelt. Wirtschaftlichkeitsmethodik gehört in Dossier 6; hier werden ROI-Aussagen nur quellenkritisch eingeordnet.

Redaktionsregeln für die spätere Buchnutzung

• Nie schreiben: „Agenten ersetzen Workflows.“ Stattdessen: Agenten erweitern den Automationsraum bei dynamischen Aufgaben.
• Nie schreiben: „RPA ist tot.“ Stattdessen: RPA bleibt für Legacy-/UI-Integration relevant, hat aber bekannte Wartungs- und Governancekosten.
• Nie schreiben: „n8n/Make kann X immer.“ Produktfeature mit Versions-/Stichtagsbezug formulieren.
• Nie Anbieter-ROI ohne Kennzeichnung als unabhängige Evidenz darstellen.
• Bei Benchmarkwerten immer Datum, Benchmarkversion, Modell/Scaffold und methodische Einschränkung nennen.
• Bei AI-Komponenten immer zwischen Modellleistung und End-to-End-Prozessqualität unterscheiden.

Schlussfolgerung

Der Forschungsstand liefert keine Begründung für eine pauschale Verschiebung von klassischer Automatisierung zu vollständig autonomen Agenten. Er liefert vielmehr eine Schichtenarchitektur: stabile Regeln und APIs für stabile Arbeit, RPA als Legacy-Brücke, Process/Task Mining zur Prozesssicht, AI für semantische Unsicherheit, Agenten für tatsächlich offene Aktionspfade und Menschen für bewusst gesetzte Entscheidungs- oder Risikogrenzen.

Für Unternehmen ist das die entscheidende Entdramatisierung des AI-Hypes: Ein guter automatisierter Prozess ist nicht derjenige mit dem meisten Modellanteil. Es ist derjenige, der möglichst wenig unnötige Unsicherheit enthält und trotzdem den gewünschten Geschäftswert erzeugt.