Am 30. Juli meldete sich eine Kundin. Zwei Tage, keine Avise. Der Job hatte gelaufen. Status grün, null Avise, Dauer 4,3 Sekunden. Eine Woche später ein Tourenexport. Die Mail kam pünktlich um 17:00 Uhr. Die CSV fehlte. Wieder grün. Und im Juni lief ein Import zehn Tage lang mit Exit 0. In der Zieltabelle kam keine einzige Tour an.
Meine Position nach diesem Sommer: Ein Lauf ohne Fehler und ohne Ergebnis ist ein Ausfall. Er gehört behandelt wie ein Absturz. "Job lief" ist ein Lebenszeichen. "Job hat geliefert" ist der Gesundheitsbeweis. Dazwischen liegt ein Protokoll je Schritt und eine einzige Zahl. Die Zahl misst den Zweck des Laufs.
Das ist keine Nachlässigkeit. Es ist der Standard der Werkzeuge. Ein Beispiel ist die Orchestrator-Doku von UiPath. Ein Job ist dort Successful, wenn der Roboter ihn korrekt ausgeführt und beendet hat. Faulted heißt: nicht gestartet oder unbehandelte Ausnahme. Beides sind Zustände des Programms. Keiner sagt, ob eine Datei im Anhang war.
Das gilt für jeden Hersteller. Cron-Jobs, Windows-Tasks, Workflow-Monitore: Alle fragen erst einmal dasselbe. Wann lief es zuletzt? Mit welchem Exit-Code? Und es werden mehr. Gartner beziffert den RPA-Markt 2024 auf 3,8 Milliarden US-Dollar. Plus 18 Prozent zum Vorjahr. Mehr Bots ohne Aufsicht denn je. Die meisten werden am Zeitstempel gemessen.
Google hat das Problem vor zehn Jahren beschrieben. Das SRE-Buch trennt Symptom und Ursache: "What's broken, and why?" Ein Monitoring soll das Symptom zeigen. Also das, was der Nutzer merkt. Für einen Disponenten heißt das Symptom nicht "Prozess abgestürzt". Es heißt "kein Avis im Postfach". Genau dieses Symptom fehlt in fast jedem Monitor, den ich in Speditionen gesehen habe.
Die Fälle stammen aus unserem Betrieb, anonymisiert. Ich nenne sie, weil die Muster übertragbar sind.
Erstens der Avis-Versand Ende Juli. Für einen fälligen Tag fehlte eine der zwei Eingangsdateien. Der Lauf übersprang den Tag stumm. Keine Logzeile. Die Meldung lautete "keine offenen Tage". Die Kundin fand es. Nicht das System.
Zweitens der Tourenexport am 6. August. Die Mail kam beim Partner an. Der CSV-Anhang fehlte. Ein Prüfjob hatte das erkannt und eine Warnung geschrieben. Die Warnmail kam nie an. Der Mailkanal war tot. Zwei Systeme, beide "liefen".
Drittens der Import ab 26. Juni. Ein stillgelegtes Modul fing den Aufruf ab. Exit 0. Der Task war zehn Tage grün. Der einzige Hinweis im Nachhinein: Die Laufzeit fiel von 5,5 auf 2,4 Sekunden. Niemand schaut auf die Laufzeit eines grünen Jobs.
Viertens ein Mailversand ab 11. August. Ein DNS-Aussetzer am Vortag tötete genau den Job, der die Lücke gemeldet hätte. Follow-ups liefen weiter. Erstmails standen still. Der Watchdog meldete gesund. Wöchentlicher Takt, also eine Woche unbemerkt.
Fünftens ein Auswertungsjob für einen Kunden. Der zentrale Monitor erzeugte 20 Alarme in zehn Tagen. Keine Alarmmail wurde zugestellt. Das Absenderkonto war gesperrt. Der Alarm selbst war der stille Ausfall.
(Ja, das sind fünf. Ja, alle in einem Sommer. Das ist der Grund für diesen Text.)
Ältere Zahlen stützen das Bild. Forrester Consulting befragte 2020 im Auftrag von Tricentis Firmen mit RPA. Ergebnis: 45 Prozent erleben Bot-Brüche jede Woche oder öfter. Die Studie ist sechs Jahre alt. Eine neuere mit gleicher Methodik habe ich nicht gefunden. Die Mechanik ist aber dieselbe geblieben. Bots brechen an geänderten Masken und fehlenden Daten. Und der Bruch ist oft still.
Wir haben daraus eine Regel gemacht. Sie steht in unserem Betriebshandbuch. Sie gilt für jede neue Automatisierung ohne Aufsicht. Drei Teile.
Erstens der erwartete Output, erklärt bei der Anlage. Genau eine Zahl je Lauf. Versendete Avise. Importierte Zeilen. Erfasste Aufträge. Sie steht unter einem festen Schlüssel im Protokoll des Laufs. Dazu ein Mindestwert und ein erlaubtes Leerlauf-Fenster. In unserem Watchdog heißen die Felder output_metric_key, min_output und max_idle_hours. Null als Sollwert ist erlaubt. Aber nur, wenn sie ausdrücklich hinterlegt ist.
Zweitens der Leerlauf-Grund. Läuft ein Prozess ohne Output, schreibt er den Grund ins Protokoll. Maschinenlesbar: Warteschlange leer, Eingang fehlt, Wochenende. Dauert der Leerlauf länger als das Fenster, kommt der Alarm. Wie bei einem Absturz. Ein Grund im Log ohne Schwelle zählt nicht. Hier hören die meisten Monitore auf. Sie loggen "nichts zu tun". Niemand zählt, wie lange schon.
Drittens: Ein negatives Ergebnis ist kein Erfolg. Ein Bounce ist eine Ablehnung. Ein "Zugriff verweigert" vom Portal auch. Ein Gate, das den Versand stoppt, ebenso. Solche Läufe enden nicht als Erfolg. Mindestens als Warnung. Oder in einer eigenen Kennzahl, die jemand überwacht.
Das Protokoll je Schritt trägt alle drei Teile. Login. Liste geladen. Datei gefunden. Datei angehängt. Mail gesendet. Jede Zeile mit Zeitstempel und Ergebnis. Fehlt im Protokoll die Zeile "Datei angehängt", kann der Lauf nicht grün sein. Der Avis-Fall wäre so im ersten Lauf aufgefallen.
Unser Watchdog kennt heute 98 Überwachungen. 48 davon tragen ein Output-Signal: Zahl, Mindestwert, Fenster. Sechs haben erklärte Leerlauf-Gründe. Drei haben ein Betriebszeitfenster. Das ist der Stand vom 9. September. Nicht der Endzustand. Die Nachrüstung lief im August in zwei Wellen. Je Überwachung mit einer Simulation über 30 Tage. So lösen neue Schwellen nicht sofort Dauerfehlalarm aus.
Die Fehlalarme kamen trotzdem. Und sie waren lehrreich. Ein Partner-Abruf holt alle 15 Minuten die Touren für heute und gestern. Sonntags fährt niemand. Also meldete der Watchdog jeden Sonntag "läuft, liefert aber nichts". 96 Läufe mit null Zeilen. Der Reflex wäre eine Schwelle von 48 Stunden. Dann ist der Alarm leiser. Das Risiko nicht. Die richtige Antwort war ein Feld für Werktage. Ein leerer Sonntag zählt nicht. Ein leerer Dienstag schon.
Google hat dafür einen Satz. "Every page should be actionable." Jeder Alarm braucht eine Handlung. Sonst wird er ignoriert. Und ein Alarm, der nur durch eine höhere Zeitschwelle ruhig wird, versteckt den nächsten stillen Ausfall. Es sei denn, das Output-Signal zieht nach.
Das sind fünf Fälle aus einem Betrieb mit ein paar Dutzend Pipelines. Keine Marktstudie. Wie oft stille Ausfälle in einer Spedition mit 300 Fahrzeugen vorkommen, weiß ich nicht. Ich weiß nur: In allen fünf Fällen zeigte das Werkzeug grün. Ein Mensch fand den Ausfall. Meist der Kunde.
Und nicht jeder Prozess hat eine Output-Zahl. Eine Spiegelung zwischen zwei Systemen zum Beispiel. Stammdaten aus der Datenbank in eine Konfigurationsdatei. Da gibt es keine sinnvolle Tageszahl. Dort zählt der Soll-Ist-Abgleich: Anzahl der Abweichungen, gemessen im Ziel. Erwartet wird null. Jede Abweichung alarmiert. Noch besser ist es, den manuellen Übertragungsschritt ganz zu automatisieren. Der Wächter ist das Netz darunter. Nicht die Lösung.
Der Browser-Agent aus dem letzten Beitrag meldet je Lauf zwei Zahlen. Geprüfte Aufträge. Gebuchte Änderungen. Null geprüfte Aufträge an einem Werktag sind dort ein Alarm. Kein Erfolg. Das ist die ganze Regel in einem Satz.
Welche Ihrer Automatisierungen hat eine Sollzahl je Lauf? Und welche meldet nur, dass sie gelaufen ist? Nennen Sie mir einen Prozess. Ich zeige Ihnen an unserem Logistik-Monitor, wie Zahl, Grund und Fenster im Protokoll dafür aussehen.
