Field Note: Was ich aus gescheiterten Automatisierungen gelernt habe

Ich suche zuerst nach dem falschen Versprechen

Ich habe lange gedacht, eine Automatisierung sei dann gut, wenn sie möglichst viele Schritte ohne mich erledigt. Heute ist das nicht mehr mein Maßstab. Eine Automatisierung ist für mich erst dann brauchbar, wenn ich verstehe, was sie bei unvollständigen Daten, Wiederholungen und unerwarteten Antworten tut.

Gescheiterte Automatisierungen sehen von außen oft nach einem technischen Problem aus: Ein API-Aufruf scheitert, ein Workflow läuft doppelt, ein Feld bleibt leer oder eine KI liefert ein anderes Format als erwartet. Der erste Impuls ist dann schnell gefunden: noch ein Retry, noch eine Bedingung, noch ein Parser. Manchmal hilft das. Häufig verschiebt es aber nur die Frage.

Mich interessiert inzwischen zuerst: Welcher Zustand ist hier eingetreten? Was wusste das System zu diesem Zeitpunkt? Und was darf es als Nächstes verändern? Wenn ich diese Fragen nicht beantworten kann, ist der Workflow nicht einfach nur anfällig. Ich habe sein Verhalten noch nicht ausreichend modelliert.

Was mich misstrauisch macht: Wenn der einzige Erfolgsnachweis lautet, dass ein Ablauf ohne sichtbare Fehlermeldung beendet wurde.

Ein Retry ist keine Fehlerstrategie

Retries sind nützlich, wenn ein Fehler vorübergehend ist. Ein Rate-Limit oder eine kurz nicht erreichbare Schnittstelle kann bedeuten, dass derselbe Schritt später noch einmal ausgeführt werden sollte. Aber ein erneuter Versuch löst nicht jedes Problem. Fehlen Quelldaten, ist ein Feld falsch gemappt oder entspricht eine Antwort nicht dem erwarteten Format, kann Wiederholen denselben schlechten Zustand lediglich erneut erzeugen.

Noch heikler wird es, wenn ein Teil des Ablaufs bereits erfolgreich war. Dann kann ein zweiter Durchlauf denselben Datensatz erneut anlegen, eine Änderung doppelt auslösen oder einen bereits verarbeiteten Schritt wiederholen. Der Workflow wirkt nach außen vielleicht robust, weil er Fehler nicht sofort aufgibt. Tatsächlich braucht er aber eine klare Antwort darauf, ob eine Operation sicher wiederholt werden kann.

Deshalb denke ich bei Automatisierungen früh an Idempotenz: Wenn derselbe Auftrag zweimal ankommt, soll das Ergebnis nicht ungewollt zweimal entstehen. Das ist kein Spezialthema für große Systeme. Schon ein Import oder eine Synchronisation muss unterscheiden können zwischen „neu“, „bereits verarbeitet“ und „konnte nicht sicher verarbeitet werden“.

Bei Cardfolio ist die Katalog-Synchronisation deshalb idempotent angelegt. Das ist eine konkrete Systemeigenschaft, keine Geschichte über einen bestimmten Ausfall. Sie macht Wiederholungen planbarer: Die Synchronisation soll nicht allein deshalb andere Daten erzeugen, weil ein Lauf erneut gestartet wird. Bei eisenross gilt außerdem ein leerer Feed als Fehler und ändert nichts. Ein leeres Ergebnis wird also nicht stillschweigend als gültiger neuer Zustand übernommen.

Diese beiden Entscheidungen erinnern mich daran, dass ein Workflow nicht nur wissen muss, wie er vorwärtsläuft. Er muss auch wissen, wann er nichts verändern darf.

Leere Felder sind keine kleinen Details

Ein fehlender Wert sieht in einer Tabelle harmlos aus. In einer Kette aus mehreren Schritten kann er aber die Bedeutung eines Datensatzes verändern. Ein leeres Feld kann heißen: Die Quelle hatte keine Angabe. Oder: Der Abruf ist fehlgeschlagen. Oder: Das Mapping hat die Information verloren. Das sind verschiedene Zustände, auch wenn sie technisch alle als leer erscheinen.

Dasselbe gilt für uneinheitliche KI-Ausgaben. Wenn ein nachfolgender Schritt auf eine bestimmte Struktur angewiesen ist, reicht es nicht, dass die Antwort plausibel klingt. Sie muss in der Form vorliegen, die der nächste Schritt tatsächlich verarbeiten kann. Andernfalls wird aus sprachlicher Varianz ein Datenproblem.

Ich trenne deshalb nach Möglichkeit zwischen Eingangsdaten, Verarbeitung und Freigabe. Ich will erkennen können, ob ein Wert aus der Quelle stammt, durch eine Regel ergänzt oder von einem Modell vorgeschlagen wurde. Und ich will nicht so tun, als seien diese Dinge gleich verlässlich.

Ein Beispiel dafür ist die Pipeline für erlebe-nrw: Die Verarbeitung ist als nummerierte Abfolge von SQLite über JSONL zu Astro aufgebaut. Die Reihenfolge ist damit Teil der Arbeitsweise und nicht bloß eine technische Fußnote. Bei den Angaben werden Quelle und Stand mitgeführt; dünne Seiten werden per noindex ausgeschlossen. Das beschreibt keine einzelne Panne, sondern eine Architektur, die Herkunft und Grenzen der Daten sichtbar hält.

Wenn ich nicht mehr nachvollziehen kann, woher ein Wert kommt oder warum ein Datensatz fehlt, kann ich schwer entscheiden, ob ich den Lauf wiederholen, die Quelle prüfen oder die Veröffentlichung stoppen sollte. Sichtbarkeit ist hier keine Zusatzfunktion. Sie ist Voraussetzung für eine sinnvolle Entscheidung.

Erst den Prozess verstehen, dann automatisieren

Mein früherer Reflex wäre eher gewesen, einen wiederkehrenden Handgriff möglichst schnell in einen Workflow zu übersetzen. Inzwischen mache ich einen Schritt vorher: Ich schaue mir an, wie der Prozess tatsächlich funktioniert, einschließlich seiner Ausnahmen. Welche Daten kommen regelmäßig? Was ist optional? Wann ist ein Datensatz vollständig? Welche Fälle müssen von einem Menschen beurteilt werden?

Das ist besonders wichtig, wenn ein Ablauf nicht ausschließlich aus festen Regeln besteht. KI kann Inhalte extrahieren oder strukturieren, aber daraus folgt nicht automatisch, dass das Ergebnis direkt in den produktiven Bestand gehört. Bei Wendewerk werden Satzungstexte KI-gestützt extrahiert; vor dem Zusammenführen gibt es ein Staging und ein Review. Die menschliche Prüfung ist dort kein nachträglicher Notbehelf, sondern Teil des Ablaufs.

Diese Trennung hilft mir, die Automatisierung genauer zu begrenzen. Was lässt sich sicher übernehmen? Was ist ein Vorschlag? Was muss jemand prüfen? Wo muss der Prozess stoppen, statt mit einem plausiblen, aber ungesicherten Ergebnis weiterzulaufen?

Ich automatisiere lieber einen klar abgegrenzten Schritt verlässlich, als einen ganzen Prozess als Blackbox zu behandeln. Das kann zunächst weniger beeindruckend wirken. Dafür kann ich nach einer Änderung besser erkennen, was sich verändert hat und ob die Änderung überhaupt richtig war.

Änderungen müssen rücknehmbar und belegbar sein

Eine Automatisierung, die Daten verändert, braucht für mich mehr als einen Startknopf und einen grünen Status. Ich möchte wissen, welchen Zustand sie vorgefunden hat, was sie ändern will und woran sich hinterher erkennen lässt, ob das Ergebnis stimmt.

Daraus ist mein Arbeitsprinzip Know → Change → Prove entstanden: erst den Zustand erfassen, dann eine Änderung nach Vorschau und Freigabe ausführen, anschließend die Wirkung belegen. Das gilt nicht nur für WordPress-Änderungen. Es ist auch eine nützliche Denkweise für automatisierte Abläufe, die Inhalte, Verknüpfungen oder Datensätze verändern.

Eine Vorschau macht Unterschiede sichtbar, bevor sie produktiv werden. Eine Freigabe schafft einen klaren Entscheidungspunkt. Und ein Nachweis verhindert, dass „der Workflow ist gelaufen“ mit „das gewünschte Ergebnis ist eingetreten“ verwechselt wird. Wenn etwas schiefgeht, sollte ich außerdem erkennen können, welcher Schritt betroffen war und welche Änderungen bereits erfolgt sind.

Inzwischen frage ich daher bei einer Automatisierung nicht nur, was sie im Idealfall tut. Ich frage auch, was bei einem leeren Ergebnis passiert, ob ein Lauf wiederholbar ist und ob sich eine Änderung zurücknehmen lässt. Wenn diese Antworten fehlen, ist mein nächster Schritt nicht automatisch, mehr zu automatisieren. Oft muss zuerst der Prozess oder das Datenmodell klarer werden.

Was ich heute anders mache: Ich behandle Wiederholung, fehlende Daten und menschliche Prüfung nicht als Randfälle, die später dazukommen. Ich plane sie als normalen Teil des Ablaufs.

Weiterführend

• Warum KI-Automatisierungen scheitern
• n8n und KI: Architektur für robuste Automatisierungen
• Know → Change → Prove: Wie WordPress-Änderungen sicher werden