Happy Path ist nicht genug: Wie robuste Automationen mit Sonderfällen umgehen

Die Demo läuft perfekt. Formular wird abgeschickt, Daten landen im CRM, Bestätigungs-E-Mail geht raus, Ticket wird erstellt. Fünf Minuten Bearbeitungszeit auf null reduziert.

Zwei Wochen nach dem Launch: Eine Anfrage kommt mit einem Unternehmensname, der ein Sonderzeichen enthält. Die Automation bricht ab — still, ohne Fehlermeldung. Niemand bemerkt es, bis der potenzielle Kunde sich drei Tage später meldet, weil er keine Antwort bekommen hat.

Das ist kein Sonderfall. Das ist Alltag.

Warum Ausnahmen unvermeidlich sind

Jede Automation wird gegen einen erwarteten Normalfall gebaut. Das ist richtig und notwendig — ohne definierten Normalfall gibt es nichts, was man automatisieren kann.

Das Problem entsteht, wenn die Ausnahmen ignoriert werden. Und die gibt es immer.

Menschen sind nicht vorhersehbar. Daten haben unerwartete Formate. APIs schlagen fehl. Formulare werden unvollständig abgeschickt. Dokumente haben die falsche Sprache. Ein Wert, der laut Datenmodell verpflichtend ist, fehlt trotzdem — weil jemand ein Pflichtfeld umgangen hat.

Die meisten Automationen werden für den Happy Path gebaut. In der Praxis trifft jede Automation auf Ausnahmen — und zeigt sich dort, ob sie robust ist oder nicht.

Die Kosten fehlenden Exception Handlings

Der offensichtlichste Schaden: Die Automation scheitert. Ein Prozess, der laufen sollte, läuft nicht.

Aber der subtilere Schaden ist teurer: Vertrauensverlust.

Wenn eine Automation regelmäßig versagt — auch wenn nur selten — vertrauen die Menschen, die damit arbeiten, ihr nicht. Sie beginnen, Ergebnisse doppelt zu prüfen. Sie bauen manuelle Sicherheitsnetze. Sie berichten in Retrospektiven, dass das System “nicht zuverlässig” sei — und haben Recht.

Robustheit ist keine Premium-Feature. Es ist die Mindestanforderung für eine Automation, die dauerhaft genutzt werden soll.

Eine einfache Taxonomie für Ausnahmen

Nicht jede Ausnahme ist gleich kritisch. Eine einfache Einteilung:

Korrierbare Ausnahmen — Kleine Abweichungen, die automatisch aufgelöst werden können. Eine Telefonnummer mit Leerzeichen statt ohne, ein Datumsformat, das normiert werden kann, ein Pflichtfeld, das mit einem Standardwert aufgefüllt werden kann. Diese Fälle brauchen keinen menschlichen Eingriff — aber sie brauchen Code, der sie behandelt.

Eskalierungspflichtige Ausnahmen — Fälle, die außerhalb definierbarer Parameter liegen und menschliche Entscheidung erfordern. Ein unvollständig ausgefülltes Formular, bei dem unklar ist, was der Absender meinte. Ein Dokument in einem nicht unterstützten Format. Eine API-Antwort, die kein verwertbares Ergebnis enthält. Diese Fälle landen beim Menschen — mit allen relevanten Informationen aufbereitet, nicht als leere Fehlermeldung.

Kritische Fehler — Systemfehler, die den gesamten Workflow betreffen. Datenbankverbindung unterbrochen, externer Dienst nicht erreichbar, kritischer Integrationsfehler. Diese Fälle brauchen sofortige Benachrichtigung und ein Logging, das die Ursache rekonstruierbar macht.

Exception Handling als [[Human-in-the-Loop]]-Design

Das beste Exception Handling ist kein technisches Patch — es ist ein Designprinzip: Ausnahmen landen nicht im Nirgendwo, sondern bei dem Menschen, der sie am besten auflösen kann.

Das bedeutet:

Sichtbarkeit — Wenn etwas schiefgeht, muss das für die Verantwortliche erkennbar sein — nicht nur für das System.

Kontext — Die Benachrichtigung enthält alle Information, die gebraucht wird, um die Ausnahme zu lösen. Nicht “Fehler in Schritt 3” — sondern “Anfrage von Max Mustermann konnte nicht verarbeitet werden, weil Feld ‘Unternehmen’ fehlt. [Link zur manuellen Bearbeitung]”

Lösungsweg — Der Mensch soll entscheiden, nicht suchen. Idealerweise ist der nächste Schritt aus der Benachrichtigung heraus direkt zugänglich.

Wie man Ausnahmen findet, bevor die Automation läuft

Die beste Zeit, Ausnahmen zu identifizieren, ist vor dem Bau. Drei Ansätze:

Prozessinhaber befragen — Wer kennt die Ausnahmen besser als die Menschen, die den Prozess täglich machen? Die Frage “Was läuft hier regelmäßig anders als geplant?” öffnet in fünf Minuten mehr Erkenntnisse als Stunden an Systemanalyse.

Historische Daten auswerten — Wenn der Prozess vorher manuell ablief: Gibt es Protokolle, Notizen, E-Mail-Verläufe, die zeigen, wo es gehakt hat?

Edge-Case-Workshop — Ein kurzes Meeting mit den Beteiligten, einzige Frage: “Was könnte alles schiefgehen?” Ergebnis: Eine Liste, die Schritt für Schritt priorisiert und im Design berücksichtigt wird.

Exception Handling als Lernquelle

Gut implementiertes Exception Handling hat einen Nebeneffekt, der oft unterschätzt wird: Es lehrt, wie der Prozess wirklich ist.

Ausnahmen, die regelmäßig auftreten, sind keine Ausnahmen mehr — sie sind Teil des Prozesses. Wenn fünfzehn Prozent aller eingehenden Formulare ein Pflichtfeld nicht ausgefüllt haben, ist das Pflichtfeld entweder falsch definiert oder das Formular ist zu kompliziert.

Das Logging von Ausnahmen über Zeit zeigt Muster. Muster zeigen Verbesserungsbedarf — nicht an der Automation, sondern am zugrunde liegenden Prozess.

Robuste Automationen hören nicht auf zu lernen, sobald sie in Betrieb sind. Sie liefern weiterhin Daten darüber, was der Normalfall wirklich ist.