Workflow Automatisierung Fehlerbehandlung: Wie Abläufe auch bei Störungen verlässlich bleiben

Der Alarm kommt nicht von einem System, sondern von einer Kundin. Sie hat vor einer Woche über das Kontaktformular angefragt und nie eine Antwort erhalten. Im CRM ist sie nicht zu finden. Das Formular hat laut Protokoll eine Bestätigung gesendet, der Workflow zeigt grüne Haken. Irgendwo dazwischen ist etwas verloren gegangen, und es gibt keine Spur davon.

In diesem Szenario betreibt ein Dienstleistungsbetrieb mit zwei Dutzend Beschäftigten vier Automatisierungen: Formularanfragen ins CRM, Rechnungen aus dem Postfach in die Buchhaltung, Terminerinnerungen per E-Mail und ein wöchentlicher Bericht. Jede davon wurde einzeln gebaut und lief monatelang zufriedenstellend. Niemand hat je festgelegt, was passieren soll, wenn ein Schritt scheitert.

Das ist der Normalfall, nicht die Ausnahme. Beim Bau eines Workflows denkt man an den Weg, der funktioniert. Der Alltag besteht aber auch aus Wegen, die nicht funktionieren: ein Dienst, der eine Stunde nicht antwortet, ein Pflichtfeld, das leer ankommt, ein Tageslimit, das um 15 Uhr erreicht ist. Wer diese Fälle nicht entwirft, entwirft sie trotzdem, nur unbewusst und meist als Datenverlust.

Gefährlich ist dabei weniger der Totalausfall als der Teilausfall. Fällt eine Automatisierung komplett aus, merkt man es meist binnen eines Tages, weil etwas Gewohntes ausbleibt. Verliert sie aber nur jeden zwanzigsten Vorgang, sieht jede Stichprobe gut aus. Der Schaden verteilt sich auf Wochen, wird einzelnen Personen zugeschrieben und taucht in keiner Statistik als Ursache auf. Genau diese Fehlerklasse macht aus einer bequemen Automatisierung ein Risiko, dem man blind vertraut.

Die erste Art ist die ausgefallene Schnittstelle. Ein Dienst antwortet mit einem Serverfehler, läuft in ein Zeitlimit oder ist schlicht nicht erreichbar. Die Ursache liegt außerhalb Ihres Einflusses und ist oft vorübergehend. Hier hilft Geduld in Form kontrollierter Wiederholungen, und wenn das nicht reicht, ein sauberes Zurückstellen mit Meldung.

Die zweite Art sind unvollständige oder unplausible Daten: eine E-Mail-Adresse ohne At-Zeichen, ein Betrag als Text, ein Pflichtfeld, das ein Formular durchgelassen hat. Wiederholen ist sinnlos, denn derselbe Datensatz scheitert immer wieder. Das gehört zu einem Menschen, der entscheidet, ob korrigiert, nachgefragt oder verworfen wird.

Drittens Limits und Quoten. Fast jede Schnittstelle begrenzt Abrufe pro Minute oder Tag und antwortet bei Überschreitung mit einem Hinweis, meist dem Status 429, häufig mit einer Angabe, wie lange zu warten ist. Das ist ein Fehler, der Rücksicht verlangt, keine Hartnäckigkeit. Viertens Duplikate: Webhooks werden gelegentlich mehrfach zugestellt, Nutzer klicken zweimal, ein Wiederholungsversuch trifft auf einen Schritt, der eigentlich schon gelungen war.

Die Unterscheidung ist der Kern der Sache. Wer alle vier Fälle mit demselben Mechanismus behandelt, etwa „bei Fehler dreimal wiederholen“, richtet Schaden an: Er hämmert auf einen gedrosselten Dienst, wiederholt hoffnungslos fehlerhafte Daten und erzeugt bei Duplikaten gleich noch mehr davon.

Nicht jeder Fehler verdient dieselbe Sorgfalt. Ein verpasster Wochenbericht ist ärgerlich, eine verlorene Kundenanfrage ist teuer, eine doppelt versendete Rechnung peinlich und je nach Fall rechtlich unerfreulich. Die erste Analyse fragt deshalb nicht, was technisch alles schiefgehen kann, sondern was bei jedem Schritt der schlimmste realistische Ausgang wäre.

Dafür gehen wir die Workflows Schritt für Schritt durch und notieren je Schritt drei Dinge: Was passiert, wenn er scheitert? Was passiert, wenn er zweimal läuft? Und wer würde es bemerken, und wann? Die dritte Frage ist die unbequemste, denn häufig lautet die Antwort „vermutlich die Kundin, in einer Woche“. Genau diese Schritte bekommen Vorrang.

Dazu kommt die Abhängigkeit von Fremdsystemen. Eine Schnittstelle, die Sie nicht kontrollieren, ändert sich irgendwann: ein Feld wird umbenannt, eine Version abgekündigt, ein Authentifizierungsverfahren ersetzt. Das ist keine Frage des Ob. Die Analyse hält deshalb fest, welche Schritte an welchen externen Diensten hängen und wie schnell eine Änderung auffallen würde.

Aus den Antworten entsteht eine einfache Matrix aus Schaden und Entdeckungsrisiko. Schritte mit hohem Schaden und geringer Sichtbarkeit bekommen die vollständige Behandlung mit Schlüssel, Warteschlange und Alarm. Schritte mit geringem Schaden und hoher Sichtbarkeit, etwa ein Bericht, der nicht ankommt und sofort vermisst wird, kommen mit einer einfachen Wiederholung und einer Meldung aus. Das hält den Aufwand im Verhältnis und die Abläufe verständlich.

Der Grundsatz hinter allen Maßnahmen lautet: Ein Fehler darf nie unsichtbar bleiben, und nichts darf verloren gehen, bevor ein Mensch es gesehen oder bewusst verworfen hat. Daraus folgt eine Reihenfolge der Mittel. Zuerst versucht das System, selbst zu helfen, etwa durch eine Wiederholung. Gelingt das nicht, legt es den Vorgang an einen sicheren Ort ab. Erst dann meldet es sich, und zwar gezielt.

Eine Alternative wäre, jeden Fehler sofort zu melden. Das klingt gründlich und endet nach zwei Wochen in einem Postfach, das niemand mehr liest. Meldungen für Dinge, die sich selbst heilen, erzeugen Müdigkeit, und die eine wichtige Meldung geht darin unter. Wir setzen deshalb auf Schwellen: Eine einzelne wiederholte Anfrage ist Protokollstoff, ein Dienst, der seit zehn Minuten nicht antwortet, ist ein Anruf wert.

Eine zweite Alternative ist ein Alles-oder-nichts-Ansatz, bei dem ein Workflow bei jedem Fehler komplett abbricht und zurückgerollt wird. Das passt zu Datenbanktransaktionen, selten zu Abläufen, die mehrere Fremdsysteme berühren: Eine gesendete E-Mail lässt sich nicht zurückholen. Praktikabler ist es, Schritte so zu gestalten, dass man sie sicher erneut ausführen kann, und den Vorgang an der Stelle fortzusetzen, an der er stehen blieb.

Wir denken Fehlerbehandlung in Schichten, die von innen nach außen greifen. Innen steht der einzelne Schritt mit seiner Prüfung der Eingangsdaten. Darum liegt die Wiederholungslogik, dann die Sicherung in einer Warteschlange und ganz außen die Beobachtung mit Meldungen. Jede Schicht fängt, was die innere nicht lösen konnte, und gibt es mit mehr Kontext weiter.

Wichtig ist die Prüfung am Eingang. Bevor ein Schritt ein Fremdsystem anspricht, werden Pflichtfelder, Formate und Plausibilität geprüft: Ist die Adresse wohlgeformt, liegt der Betrag im erwartbaren Rahmen, ist das Datum nicht in der Vergangenheit? Dadurch landen ungültige Daten gar nicht erst in einem Wiederholungszyklus, sondern direkt dort, wo ein Mensch sie ansieht.

Zur Konzeption gehört auch die Entscheidung, wer wofür zuständig ist. Eine Prüfwarteschlange ohne benannte Person ist ein Friedhof. Wir legen daher fest, wer sie täglich öffnet, wie lange ein Eintrag liegen darf und was passiert, wenn dieser Zeitraum überschritten wird. Bei kleinen Teams genügt oft eine Person mit klarer Vertretung, entscheidend ist die Verbindlichkeit.

Ein Beispiel für das Zusammenspiel: Das Formular liefert eine Anfrage mit ungültiger Telefonnummer. Die Eingangsprüfung stuft sie als zweifelhaft ein, legt sie samt Originaltext in die Warteschlange und benachrichtigt die zuständige Person. Der Kontakt wird nicht verworfen und nicht ungeprüft angelegt. Wenige Minuten später korrigiert ein Mensch die Nummer, bestätigt, und der Ablauf setzt dort fort, wo er angehalten wurde.

Bei Wiederholungen bewährt sich ein wachsender Abstand, der Exponential Backoff genannt wird: etwa nach einer, dann vier, dann sechzehn Sekunden, mit einer Obergrenze für Versuche und Wartezeit. Hinzu kommt eine kleine zufällige Streuung, damit nicht zehn gescheiterte Vorgänge exakt gleichzeitig zurückkehren und den gerade erholten Dienst erneut überlasten. Wiederholt wird nur bei Zeitüberschreitung, Serverfehlern und Drosselung, nicht bei Fehlern, die der Aufruf selbst verschuldet hat, etwa bei ungültigen Eingaben.

Gibt eine Schnittstelle bei Drosselung an, wie lange zu warten ist, folgt der Workflow dieser Angabe, statt eine eigene Rechnung aufzumachen. Bei dauerhaftem Limitdruck lohnt es, Abrufe zu bündeln oder zeitlich zu verteilen. Ein Tageslimit lässt sich nicht durch Wiederholen überwinden, es verlangt eine Entscheidung: Zurückstellen bis zum nächsten Zeitfenster oder den Plan beim Anbieter anpassen.

Idempotenz heißt, dass ein Schritt bei mehrfacher Ausführung dasselbe Ergebnis liefert wie bei einmaliger. Technisch geschieht das über einen Schlüssel pro Vorgang, etwa die Formular-ID oder eine aus Absender, Betreff und Datum gebildete Kennung. Bevor ein Schritt etwas anlegt, prüft er, ob dieser Schlüssel schon verarbeitet wurde. Manche Schnittstellen unterstützen solche Schlüssel direkt, bei anderen führen wir eine eigene kleine Tabelle der erledigten Vorgänge.

Der Schlüssel muss stabil und zugleich passend gewählt sein. Zu grob, und zwei echte Anfragen derselben Person am selben Tag gelten als Duplikat. Zu fein, etwa mit Zeitstempel im Schlüssel, und das Duplikat wird nie erkannt. Hier gibt es keine allgemeine Lösung, nur die Frage, was im jeweiligen Fall dieselbe Sache ausmacht.

Der heikelste Sonderfall ist der halb erledigte Vorgang. Ein Workflow legt einen Kontakt im CRM an, sendet eine Bestätigung und scheitert beim dritten Schritt, dem Anlegen einer Aufgabe. Ein Neustart von vorn erzeugt einen zweiten Kontakt und eine zweite Mail. Deshalb merkt sich der Ablauf je Vorgang, welche Schritte erledigt sind, und setzt beim ersten offenen fort. Diese Zustandsführung ist Mehraufwand, verhindert aber genau die Doppelungen, die später am meisten Ärger machen.

Ein zweiter Sonderfall: Der Fehler tritt nur manchmal auf. Eine Schnittstelle antwortet in zwei Prozent der Fälle mit einem leeren Feld, das sonst nie leer ist. Einzelne Fehlermeldungen sagen dazu wenig, ein Protokoll mit Kontext schon: Welcher Vorgang, welcher Schritt, welche Eingabe, welche Antwort. Dort sehen Sie das Muster, etwa dass es immer Datensätze mit Umlauten in einem bestimmten Feld betrifft.

Drittens die schleichende Änderung bei Fremdschnittstellen. Ein Anbieter fügt ein Feld hinzu, ändert ein Format oder schaltet eine alte Version ab. Schlimmstenfalls läuft der Workflow weiter und liefert unbemerkt falsche Ergebnisse, etwa weil ein Betrag nun in Cent statt in Euro kommt. Dagegen helfen Plausibilitätsprüfungen auf den Ergebnissen, Funktionstests mit einem Testdatensatz und das Lesen der Änderungshinweise des Anbieters, die wir als festen Termin einplanen.

Viertens betrifft es die Menschen, die Fehler beheben. Eine Prüfwarteschlange funktioniert nur, wenn ein Eintrag alles enthält, was zur Entscheidung nötig ist: die Originaldaten, den Fehlergrund in verständlichen Worten und eine Schaltfläche oder Anleitung für die nächste Aktion. Muss jemand erst in drei Systemen suchen, wird die Warteschlange gemieden.

Zu erwarten ist weniger ein Rückgang der Fehler als ein Wandel ihrer Folgen. Fehler treten weiter auf, denn Fremdsysteme bleiben fehleranfällig. Der Unterschied: Sie führen nicht mehr zu verlorenen Anfragen oder doppelten Buchungen, sondern zu einem Eintrag in der Warteschlange und einer Meldung. Der Nutzen liegt darin, dass Störungen ihre Kosten verlieren, nicht dass sie verschwinden.

Messen lässt sich das an wenigen Kennzahlen. Die Zeit zwischen Auftreten und Entdeckung eines Fehlers sollte von Tagen auf Minuten oder Stunden sinken. Der Anteil automatisch geheilter Vorgänge, also Fehler, die durch Wiederholung von selbst gelöst wurden, zeigt, wie viel Arbeit das System abnimmt. Das Alter des ältesten Eintrags in der Prüfwarteschlange verrät, ob sich jemand kümmert. Hinzu kommen Beschwerden oder Rückfragen von Kunden, die auf Verluste hindeuten.

Realistisch ist auch eine Anlaufphase. In den ersten Wochen zeigt die Beobachtung Fehlerbilder, die vorher nie sichtbar waren, und die Zahl der Meldungen steigt zunächst. Das ist ein Erfolg der Sichtbarkeit, kein Rückschritt. Danach werden Schwellen angepasst und häufige Ursachen beseitigt. Zusagen zu bestimmten Quoten geben wir nicht, weil sie von den Fremdsystemen, der Datenqualität und der Disziplin im Team abhängen.

Wer es genauer wissen will, betrachtet Fehler nach Ursache statt nach Anzahl. Häufen sich Zeitüberschreitungen bei einem einzelnen Dienst, lohnt ein Gespräch mit dem Anbieter oder ein Wechsel. Häufen sich Datenfehler an einer Eingabestelle, liegt die Lösung am Formular, nicht im Workflow. So führt die Beobachtung nicht nur zu schnellerer Reaktion, sondern langfristig zu weniger Störungen an der Quelle.

Der erste Grundsatz: Fehlerbehandlung gehört in den Entwurf, nicht ans Ende. Wer sie nachträglich ergänzt, muss Datenflüsse umbauen, die schon produktiv laufen. Bei neuen Workflows stellen wir deshalb die Frage nach dem Scheitern vor der Frage nach der Funktion. Das kostet beim Entwurf einen Nachmittag und spart später Wochen.

Der zweite: Protokolle brauchen Struktur und Aufbewahrungsregeln. Ein Eintrag sollte Vorgangs-ID, Schritt, Zeitpunkt, Ergebnis und Fehlergrund enthalten, aber keine unnötigen personenbezogenen Daten im Klartext. Wie lange Protokolle gespeichert werden, ist auch eine Datenschutzfrage, die Sie mit Ihrer Datenschutzberatung klären sollten. Wir nennen das hier als Hinweis, nicht als Rechtsauskunft.

Der dritte: Workflows sind Software und verdienen Versionierung und Tests. Jede Änderung wird als neue Version geführt, mit kurzer Notiz, was sich warum geändert hat, und lässt sich zurücksetzen. Ein kleiner Satz Testfälle, der den Normalfall, einen Dienstausfall, ein Duplikat und einen kaputten Datensatz abdeckt, wird nach jeder Änderung durchlaufen. Das ist weniger Aufwand, als es klingt, und fängt die häufigsten Folgefehler ab.

Der vierte betrifft die Alarme selbst. Eine Meldung ist nur so gut wie ihr Inhalt: Sie nennt den Workflow, den Schritt, den Vorgang, den Grund und einen Link zur Stelle, an der man handeln kann. Und sie geht an eine Person oder einen Kanal, der gelesen wird, nicht an eine Sammeladresse. Nachts muss nicht alles klingeln, aber für Kundenanfragen und Zahlungsabläufe sollte klar sein, wer morgens zuerst hinsieht.

Der fünfte betrifft den Zeitplan. Neue Automatisierungen sollten eine Phase mit engerer Beobachtung durchlaufen, bevor man sie sich selbst überlässt. Und danach braucht es feste Termine für Wartung, denn auch ein ruhiger Workflow veraltet.

Verlässliche Automatisierung zeigt sich nicht im Normalbetrieb, sondern an dem Tag, an dem etwas nicht stimmt. Dann entscheidet sich, ob ein Vorgang gesichert, gemeldet und nachvollziehbar bleibt oder spurlos verschwindet. Fehlerbehandlung ist der Teil der Arbeit, den man später nicht sieht, wenn er gut gemacht ist, und sehr deutlich vermisst, wenn er fehlt.

Der nächste Schritt ist klein. Wählen Sie einen Ihrer Workflows und gehen Sie ihn Schritt für Schritt durch: Was passiert, wenn dieser Schritt scheitert? Was, wenn er zweimal läuft? Wer würde es bemerken? Gibt es auf eine der Fragen keine klare Antwort, haben Sie die erste Lücke gefunden. Gern schauen wir mit Ihnen auf zwei oder drei Abläufe und sagen klar, wo der größte Handlungsbedarf liegt und wo ein einfacher Alarm schon genügt.

Realistisch ist ein schrittweises Vorgehen. Sie müssen nicht alle Abläufe auf einmal umbauen. Beginnen Sie mit dem, bei dem ein verlorener Vorgang am meisten kostet, und übertragen Sie die Muster danach auf die übrigen. Schon eine Eingangsprüfung, ein Schlüssel gegen Duplikate und ein verlässlicher Alarm verändern die Lage spürbar, auch wenn die vollständige Ausbaustufe noch aussteht.

Eine Grenze gehört dazu: Keine Fehlerbehandlung macht fremde Systeme zuverlässiger, sie macht Ihre Abläufe nur belastbarer gegen deren Schwächen. Und sie ersetzt keinen Menschen, der die Warteschlange tatsächlich öffnet. Technik und Zuständigkeit gehören zusammen.