Automatisierung: Fehler in der Kanzlei erkennen

Eine interne Aufgabe soll nach einer Formularanfrage automatisch entstehen. Das Formular zeigt eine Bestätigung, im Aufgabenboard ist aber nichts zu sehen. Hat die Übertragung nicht begonnen, ist sie abgebrochen oder wurde die Aufgabe nur falsch zugeordnet? Dieses fiktive Beispiel zeigt, warum eine einzige grüne Statusanzeige die praktische Kontrolle nicht ersetzt.

Drei Fehlerbilder getrennt betrachten

Der Ablauf meldet einen Fehler. Eine Verbindung scheitert oder ein Verarbeitungsschritt bricht ab. Hier kann die Automatisierungsplattform eine Fehlermeldung liefern. Diese muss die zuständige Person erreichen und einen prüfbaren Bezug zum betroffenen Lauf enthalten.

Der Ablauf startet nicht. Eine Eingangsverbindung ist unterbrochen oder ein geplanter Lauf bleibt aus. Ein Fehlerpfad innerhalb des Workflows kann diesen Fall übersehen, weil der Workflow gar nicht ausgeführt wurde. Vergleichen Sie deshalb an einer geeigneten Stelle erwartete Eingänge oder geplante Startzeiten mit den tatsächlich gestarteten Läufen.

Der Ablauf endet technisch, das Ergebnis bleibt unvollständig. Ein Datensatz wurde angelegt, aber der zuständigen Person nicht zugeordnet. Die Software kann den einzelnen Schreibschritt trotzdem als erfolgreich behandeln. Ihre fachliche Erfolgskontrolle muss deshalb mehr prüfen als das Ende einer Ausführung.

Diese Unterscheidung bestimmt, was überwacht werden muss. Ein zusätzlicher Alarm für technische Fehler hilft wenig, wenn das eigentliche Problem ein fehlender Start oder eine falsche Zuordnung ist.

Das Erfolgssignal im Zielsystem festlegen

Für das Formularbeispiel könnte ein brauchbares Signal so aussehen: Die Aufgabe ist über die Kennung der eingegangenen Anfrage auffindbar, der vorgesehene Bearbeiter ist gesetzt und der Status entspricht der vereinbarten Übergabe. Das ist ein eigener Planungsvorschlag; die konkreten Felder hängen von Ihren Systemen ab.

Beschreiben Sie dieses Ergebnis zuerst in normaler Sprache. Erst danach übersetzt die technische Betreuung es in eine Prüfung. Eine Bestätigung des Formulars, eine erfolgreiche API-Antwort und eine tatsächlich nutzbare Aufgabe können unterschiedliche Stationen desselben Wegs sein.

Ein technischer Nachweis sagt zudem nichts darüber, ob die Aufgabe bereits fachlich bearbeitet wurde. Halten Sie Eingang, Übergabe und Bearbeitung auch in der Auswertung auseinander.

Eine Betriebsliste für jeden wichtigen Ablauf

Die folgende Liste ist eine redaktionelle Arbeitshilfe für die Abstimmung zwischen Kanzlei und technischer Betreuung. Sie lässt sich für einen einzelnen Prozess ausfüllen und gemeinsam durchgehen.

Die Wartezeit ist keine pauschale Minutenangabe für jede Kanzlei. Leiten Sie sie aus dem konkreten Prozess ab: Wird der Eingang sofort verarbeitet oder erst in einem vereinbarten Sammellauf? Wann benötigt das Team das Ergebnis? Prüfen Sie Ihre Annahme im Test.

Bei einem rein ereignisgesteuerten Ablauf bedeutet „heute noch kein Lauf“ nicht automatisch einen Fehler. Vielleicht gab es keinen Eingang. Ein sinnvoller Alarm unterscheidet deshalb einen belegten, unbearbeiteten Eingang von einem Tag ohne neue Anfragen.

Was ein Fehler-Workflow leisten kann

n8n bietet die Zuordnung eines Fehler-Workflows, der beim Fehlschlag einer Ausführung gestartet wird. Er beginnt mit einem Error Trigger. Zusätzlich kann eine selbst definierte Bedingung über „Stop And Error“ gezielt einen Fehler auslösen. So lässt sich ein fehlendes erforderliches Ergebnis ausdrücklich behandeln, sofern die entsprechende Prüfung eingerichtet wurde. n8n: Fehler behandeln.

Diese Konfiguration ist noch kein Nachweis für einen funktionierenden Alarm. Die Dokumentation des Error Trigger weist darauf hin, dass er bei Fehlern automatischer Ausführungen reagiert und sich nicht durch einen manuell gestarteten Workflow testen lässt. Planen Sie deshalb einen passenden automatischen Test in einer abgegrenzten Testumgebung. n8n: Error Trigger.

Für einen vollständig ausgefallenen Automatisierungsdienst braucht es außerdem eine Kontrolle, die nicht allein von genau diesem Dienst abhängt. Klären Sie mit der technischen Betreuung, wie ein solcher Ausfall bemerkt wird und wie die Kanzlei dann ihre offenen Eingänge prüft.

Eine Meldung, mit der jemand arbeiten kann

Eine hilfreiche Meldung nennt den betroffenen Ablauf, die Kennung, den beobachteten Zustand und den nächsten Prüfweg. Im fiktiven Formularbeispiel könnte sie lauten: „Für Testeingang T-204 ist nach der vereinbarten Wartezeit keine zugeordnete Aufgabe nachgewiesen. Zielsystem anhand der Eingangskennung prüfen. Noch keine erneute Anlage auslösen.“

Ein vollständiger Nachrichtentext oder eine Mandatsbeschreibung muss dafür nicht in jeden Alarm kopiert werden. Halten Sie vertrauliche Inhalte im vorgesehenen System und geben Sie der zuständigen Person den benötigten, zugriffsgeschützten Bezug.

Legen Sie auch fest, wie die Übernahme der Meldung dokumentiert wird. Ein versandter Alarm beweist nicht, dass ihn jemand bearbeitet. Bleibt die Übernahme aus, sollte der vereinbarte Vertretungsweg greifen.

Vor einer Wiederholung das Ergebnis klären

Bei einer Zeitüberschreitung kann das Zielsystem eine Aktion bereits ausgeführt haben, obwohl die Antwort nicht angekommen ist. Die Amazon Builders’ Library erläutert, warum blindes Wiederholen dann zusätzliche Ergebnisse erzeugen kann und wie idempotente Schnittstellen dieses Risiko begrenzen. AWS: sichere Wiederholungen.

„Idempotent“ bedeutet hier: Derselbe Auftrag kann unter den vorgesehenen Bedingungen wiederholt werden, ohne eine zusätzliche Wirkung auszulösen. Dafür muss das Zielsystem den Mechanismus tatsächlich unterstützen. Eine selbst gewählte Kennung in einem beliebigen Textfeld stellt diese Eigenschaft noch nicht her.

Für das Aufgabenbeispiel heißt das: Erst nach dem ursprünglichen Ergebnis suchen und die Zuordnung prüfen. Ist es vorhanden, wird es weiterbearbeitet. Bleibt der Ausgang unklar, übernimmt die verantwortliche Person den Ausnahmefall. Automatische Wiederholungen brauchen eine dokumentierte Regel, begrenzte Versuche und eine getestete Behandlung bereits vorhandener Ergebnisse.

Vier Störungen vor dem Betrieb durchspielen

Verwenden Sie künstliche Daten und Testziele ohne echte Empfänger. Die folgenden Fälle sind Prüfvorschläge; produktive Verbindungen sollen dafür nicht absichtlich unterbrochen werden.

1. Abbruch eines Schritts: Die Fehlermeldung erreicht den vorgesehenen Testempfänger und nennt die betroffene Ausführung.
2. Belegter Eingang ohne Start: Die zusätzliche Kontrolle erkennt den Eingang, obwohl keine normale Ausführung vorliegt.
3. Unvollständiges Ergebnis: Der Testdatensatz existiert, erfüllt aber ein notwendiges Merkmal nicht. Die fachliche Erfolgskontrolle meldet das Problem.
4. Verlorene Antwort nach erfolgreicher Anlage: Eine kontrollierte Wiederaufnahme erzeugt kein zweites Ergebnis; bei unklarem Ausgang hält sie zur Prüfung an.

Notieren Sie für jeden Test erwartetes und beobachtetes Verhalten. Wiederholen Sie die betroffenen Prüfungen nach Änderungen an Eingangswegen, Feldern oder Zuständigkeiten. So bleibt die Betriebsliste mit dem tatsächlichen Ablauf verbunden.

Die übergeordnete Planung der Systeme und Übergaben beschreibt unser Leitfaden zur Digitalisierung der Anwaltskanzlei. Für einen bereits laufenden Prozess ist der nächste konkrete Schritt kleiner: Erfolgssignal und Ausnahmeweg mit den Personen durchgehen, die im Fehlerfall handeln müssen.