Was eine Automatisierung braucht, bevor sie unbeaufsichtigt laufen darf

Die erste Automatisierung, die in einem Betrieb sauber läuft, ist fast immer eine kleine: eine Rechnung, die automatisch verbucht wird. Eine Erinnerungsmail, die pünktlich rausgeht. Ein Bericht, der sich jeden Montag selbst zusammenstellt. Klein genug, dass ein Blick pro Woche reicht, um zu sehen, ob es passt.

Schwierig wird es beim zweiten Schritt: wenn aus der kleinen Automatisierung eine wird, die selbst entscheidet, wann sie läuft, was sie anfasst und wen sie dabei betrifft — eine Bestellung auslöst, eine Mahnung verschickt, einen Zugang freischaltet. Genau dann stellt sich eine Frage, die beim ersten Schritt niemand gestellt hat, weil sie sich nicht gestellt hat: Darf das hier auch dann noch richtig laufen, wenn drei Wochen lang niemand hinschaut?

Meine Erfahrung aus etlichen solchen Projekten: Die Antwort hängt nicht an der Qualität des Codes. Sie hängt an drei Dingen, die im Design stehen müssen, bevor die Automatisierung das erste Mal live geht.

Freigabe — nicht alles darf von selbst passieren

Die erste Frage ist nicht “kann die Automatisierung das technisch?”, sondern “darf sie das ohne Rückfrage?”. Beides wird gern verwechselt, weil die technische Machbarkeit meistens zuerst feststeht.

Ich teile jede Aktion, die eine Automatisierung ausführen soll, in drei Stufen: Aktionen, die sie ohne Rückfrage ausführen darf, weil ein Fehler dort billig und reversibel ist. Aktionen, die sie vorbereitet, aber erst nach einer Freigabe durch einen Menschen ausführt — ein Angebot als Entwurf statt als versendete Mail, eine Zahlung als Vorschlag statt als Buchung. Und Aktionen, die grundsätzlich bei einem Menschen bleiben, weil der Schaden im Fehlerfall die eingesparte Zeit nicht aufwiegt.

Diese Einteilung braucht eine ehrliche Bestandsaufnahme, keine Bequemlichkeitsentscheidung. “Das wird schon meistens richtig sein” ist keine Begründung für Stufe eins. Die verdient sich eine Aktion erst, wenn der schlechteste Fall aushaltbar ist.

Monitoring — den falschen Lauf erkennen, nicht nur den fehlenden

Die meisten Überwachungen, die ich in bestehenden Automatisierungen vorfinde, prüfen eine Sache: Ist der Job überhaupt gelaufen? Das ist die falsche Frage, oder zumindest nicht die einzige. Ein Job, der jede Nacht pünktlich läuft und dabei jedes Mal die falsche Adresse anschreibt, besteht diesen Test problemlos.

Deshalb baue ich zwei Ebenen ein. Die erste prüft, ob überhaupt etwas passiert ist — der klassische Heartbeat. Die zweite prüft, ob das, was passiert ist, plausibel ist: Bewegt sich die Anzahl der Aktionen in einem erwarteten Rahmen? Betrifft eine Aktion ungewöhnlich viele Datensätze auf einmal? Weicht ein Ergebnis stark von den letzten Läufen ab? Diese zweite Ebene ist die, die einen stillen Fehler tatsächlich meldet, bevor er sich über Wochen ausbreitet.

Genauso wichtig: Wer bekommt die Meldung, und wie dringend? Eine Automatisierung, die bei jeder Kleinigkeit eine E-Mail schreibt, wird nach zwei Wochen ignoriert. Eine, die nur beim echten Ausreißer eine Nachricht schickt, wird gelesen.

Rückbau — der Weg zurück ist Teil der Planung

Der Punkt, den ich am häufigsten vermisse, ist der Rückbau. Nicht der Notausschalter für die ganze Automatisierung — den hat fast jeder eingebaut. Gemeint ist die feinere Frage: Wie kommt eine einzelne fehlerhafte Aktion wieder raus, ohne dass ich das ganze System stilllege?

Wenn eine Automatisierung dreißig Kundendatensätze falsch aktualisiert hat, will ich diese dreißig zurücksetzen können — nicht die Automatisierung eine Woche lang abschalten, während ich von Hand nachziehe, was sie in der Zwischenzeit richtig gemacht hätte. Das bedeutet in der Praxis: Jede Aktion protokolliert, was vorher galt, nicht nur, was sie geändert hat. Und der Rückweg ist getestet, bevor er gebraucht wird — nicht zum ersten Mal im Ernstfall improvisiert.

Das kostet beim Bau zusätzliche Zeit. Sie zahlt sich genau in dem Moment aus, in dem etwas schiefgeht — und etwas geht irgendwann schief.

Wo dieser Weg an Grenzen stößt

Diese drei Bausteine machen eine Automatisierung nicht unfehlbar. Sie machen einen Fehler beherrschbar, statt ihn zu verhindern. Wer erwartet, dass sich damit jedes Risiko wegdesignen lässt, wird enttäuscht — das ist auch nicht das Ziel.

Und sie kosten Zeit vor dem ersten produktiven Lauf. Wer eine Automatisierung “schnell mal eben” bauen will, empfindet Freigabestufen, doppeltes Monitoring und einen getesteten Rückweg als Bremse. Bei einer kleinen, folgenlosen Aufgabe ist diese Bremse übertrieben — nicht jede Automatisierung braucht die volle Ausstattung. Die entscheidende Frage bleibt einfach: Was passiert, wenn genau diese Automatisierung drei Wochen unbeaufsichtigt falsch läuft? Ist die Antwort “nichts Schlimmes”, reicht ein einfacher Aufbau. Ist sie ein handfestes Problem, gehören alle drei Bausteine rein, bevor sie live geht.

Wenn Sie das gerade überlegen

Nehmen Sie Ihre nächste geplante Automatisierung und beantworten Sie für sich: Wer muss vorher ein Ja geben, woran würde ich einen falschen Lauf erkennen, und wie komme ich aus einer fehlerhaften Aktion wieder raus? Fehlt eine der drei Antworten, ist das der Punkt, an dem ich vor dem Start ansetzen würde.

Wenn Sie überlegen, wie das für Ihren konkreten Anwendungsfall aussieht: Schreiben Sie mir. Ein erstes Gespräch kostet nichts, und danach ist meistens klarer, wie viel Absicherung Ihre Automatisierung wirklich braucht.