Warum ein automatisierter Ablauf erst dann wirklich trägt, wenn sich die ursprünglichen Bedingungen verändern.
Eine neue Mitarbeiterin soll in drei Wochen anfangen.
Die Personalabteilung hinterlegt ihren Eintritt im HR-System. Daraufhin starten mehrere automatisierte Abläufe: Ein Benutzerkonto wird angelegt, Zugriffsrechte werden eingerichtet, ein Notebook bestellt und die ersten Termine vorbereitet.
Was früher mehrere E-Mails und manuelle Aufgaben erforderte, geschieht jetzt nahezu von selbst.
Eine Woche später verschiebt sich der Arbeitsbeginn um sechs Wochen.
Die Personalabteilung aktualisiert das Datum. Doch die Automationen wurden ausschließlich für den ursprünglichen Eintritt eingerichtet. Sie reagieren nicht auf die nachträgliche Änderung.
Das Benutzerkonto bleibt aktiviert. Die Termine bestehen weiter. Die Bestellung ist längst ausgelöst.
Keiner der automatisierten Schritte muss dafür technisch fehlerhaft gewesen sein.
Das Problem ist, dass der Prozess nur für einen Verlauf entworfen wurde, der nicht mehr gilt.
Die Situation ist hypothetisch. Sie zeigt jedoch eine grundlegende Schwäche isolierter Automatisierung.
Ein Auslöser ist noch kein Prozess.
Viele Automatisierungen beginnen mit einer einfachen Regel: Wenn ein bestimmtes Ereignis eintritt, führe eine festgelegte Aktion aus.
Ein neuer Datensatz erzeugt ein Benutzerkonto. Eine Freigabe startet eine Bestellung. Ein Statuswechsel verschickt eine Benachrichtigung.
Solche Regeln können ausgesprochen nützlich sein.
Doch ein Geschäftsprozess besteht nicht nur aus seinem ersten Auslöser. Er entwickelt sich über die Zeit. Voraussetzungen ändern sich, Entscheidungen werden zurückgenommen, Ausnahmen entstehen.
Im Onboarding ist die Anlage eines Benutzerkontos deshalb nur eine Aufgabe innerhalb eines größeren Zusammenhangs.
Der Prozess muss auch unterscheiden können, ob ein Eintritt geplant, verschoben, verbindlich freigegeben oder abgesagt wurde.
Automatisierung beschreibt, was bei einem Ereignis geschieht. Prozessarchitektur muss auch berücksichtigen, was geschieht, wenn sich seine Bedeutung verändert.
Die Ausnahme gehört zum Entwurf.
Im ursprünglichen Ablauf war kein technischer Fehler vorgesehen. Trotzdem entsteht durch die Terminverschiebung eine Situation, die behandelt werden muss.
Soll das Benutzerkonto deaktiviert bleiben, bis der Eintritt tatsächlich erfolgt? Müssen Berechtigungen erneut bestätigt werden? Kann die Notebookbestellung bestehen bleiben? Wer entscheidet darüber?
Solche Fragen sind keine nachträglichen Sonderwünsche. Sie gehören zur Definition eines verlässlichen Onboardings.
NIST beschreibt in seiner Sicherheitskontrolle AC-2 die Verwaltung von Benutzerkonten ausdrücklich als fortlaufende Aufgabe: Konten werden nicht nur angelegt, sondern auch verändert, überprüft und gegebenenfalls deaktiviert. Berechtigungen müssen mit dem tatsächlichen Personal- und Zugriffsbedarf zusammenpassen.
Technisch lassen sich solche Zustandsänderungen durchaus abbilden.
Temporal beispielsweise ermöglicht es, laufende Workflows durch neue Nachrichten und Ereignisse zu beeinflussen. Microsoft dokumentiert langlebige Abläufe, die auf eine menschliche Freigabe warten oder nach einer Frist eskalieren können.
Diese Möglichkeiten lösen jedoch nicht die eigentliche Architekturfrage.
Bevor ein System auf eine Ausnahme reagieren kann, muss feststehen, was diese Ausnahme fachlich bedeutet.
Ein Prozess braucht einen Rückweg.
Zurück zu unserer Mitarbeiterin.
Ein verlässlicher Ablauf würde die Terminverschiebung nicht lediglich als geändertes Datum speichern.
Er würde prüfen, welche bereits ausgelösten Maßnahmen davon betroffen sind.
Vorzeitig aktivierte Berechtigungen müssten entsprechend der festgelegten Zugriffsregeln angepasst werden. Termine könnten neu geplant werden. Bei der Hardwarebestellung wäre zu entscheiden, ob sie bestehen bleiben, verschoben oder storniert werden soll.
Nicht jede Aktion lässt sich einfach rückgängig machen.
Eine Bestellung, die bereits versandt wurde, verschwindet nicht durch das Zurücksetzen eines Workflow-Status.
Deshalb braucht ein Prozess nicht nur einen Start und ein gewünschtes Ergebnis, sondern auch erkennbare Zwischenzustände, Verantwortlichkeiten und einen Weg für Entscheidungen, die sich nicht automatisch treffen lassen.
Dabei ist menschliche Freigabe kein Selbstzweck. Viele Änderungen können nach klaren Regeln vollständig automatisiert werden. Andere benötigen eine fachliche Entscheidung.
Entscheidend ist, dass kein Vorgang stillschweigend liegen bleibt, nur weil der vorgesehene Normalfall verlassen wurde.
Verlässlichkeit entsteht im gesamten Ablauf.
Gute Prozessautomatisierung beginnt deshalb nicht mit der Frage, welche manuellen Tätigkeiten wir ersetzen können.
Sie beginnt damit, den Ablauf zu verstehen: Was löst ihn aus? Welche Bedingungen müssen erfüllt sein? Was verändert seinen Zustand? Wer verantwortet offene Entscheidungen? Und woran erkennen wir, dass der gewünschte betriebliche Zustand tatsächlich erreicht wurde?
Dafür ist nicht zwangsläufig eine neue Workflow-Plattform notwendig.
Oft genügt es zunächst, bestehende Regeln um klare Zustände, Änderungswege, Kontrollen und Verantwortlichkeiten zu ergänzen.
Google SRE beschreibt Automatisierung als wirkungsvolles Instrument, dessen Nutzen wesentlich davon abhängt, wie überlegt es eingesetzt wird.
Genau darin liegt der Unterschied zwischen einzelnen automatisierten Aufgaben und einer tragfähigen Prozessarchitektur.
Automatisierung nimmt uns Arbeit ab, solange alles nach Plan verläuft. Gute Architektur sorgt dafür, dass der Prozess auch dann verlässlich bleibt, wenn sich der Plan ändert.
Quellen und Vertiefung
- NIST — SP 800-53, Account Management (AC-2) — Verwaltung, Anpassung und Deaktivierung von Benutzerkonten sowie Abstimmung mit Personalprozessen.
- Temporal — Workflow Message Passing — Zustandsbezogene Verarbeitung neuer Ereignisse in laufenden Workflows.
- Microsoft Learn — Human Interaction Pattern — Freigaben, externe Ereignisse, Wartezustände und Fristen.
- Google SRE — The Evolution of Automation at Google — Möglichkeiten, Grenzen und bewusste Gestaltung von Automatisierung.
Das Einstiegsszenario ist hypothetisch. Die technischen Mechanismen sind dokumentiert; ihre Anwendung auf das beschriebene Onboarding ist eine architektonische Ableitung, kein nachgewiesener Kundenfall.
