Ein Workflow ist eine Maschine. Betreibt ihn wie eine.

Niemand stellt eine Anlage in die Halle, weil sie im Vorführvideo gut aussah. Es gibt eine Abnahme, einen Wartungsplan, eine Störmeldekette und jemanden, der für die Anlage verantwortlich ist. Bei Automatisierungsprojekten werden genau diese Schritte häufig übersehen: Die Demo mit Testdaten lief perfekt, der Workflow geht in Betrieb und niemand hat gefragt, wie er eigentlich dauerhaft sicher betrieben werden kann. Der Abstand zwischen „Demo“ und „darf im Betrieb laufen“ ist oft die eigentliche Arbeit - in diesem Artikel schauen wir uns an, wie man diesen Abstand überbrückt.

Was die Maschinenhalle längst weiß

Der Mittelstand betreibt Maschinen seit über hundert Jahren und die Disziplin dafür ist so eingeübt, dass sie kaum noch jemand als Disziplin wahrnimmt. Eine Anlage wird getestet und abgenommen, bevor sie produziert. Sie hat eine Störmeldekette: Wenn etwas klemmt, leuchtet es, hupt es, steht es auf einem Bildschirm im Leitstand. Sie hat einen definierten Grundzustand nach dem Not-Halt, damit nach einem Stopp nichts Halbes in der Anlage hängt. Es gibt einen Wiederanlaufplan, eine Betriebsanleitung und einen „Besitzer“, der zuständig ist, mit Vertretung.

Nichts davon ist für Automatisierungs-Workflows neu zu erfinden. Es ist nur zu übersetzen:

• Abnahme = ein Testlauf mit echten Fällen, bevor der Workflow in Betrieb genommen wird.
• Störmeldekette = ein zweiter Workflow, der anspringt, wenn der erste scheitert und einen Menschen benachrichtigt.
• Not-Halt mit Grundzustand = der Ablauf darf keinen halbfertigen Zustand hinterlassen; wo möglich, wird erst am Ende geschrieben.
• Wiederanlaufplan = jeder Lauf steht im Protokoll und lässt sich nach der Reparatur erneut anstoßen.
• Betriebsanleitung = eine Seite: was der Ablauf tut, wer verantwortlich ist samt Vertretung, die fünf häufigsten Störungen und was dann zu tun ist.
• Besitzer = ein Name, keine Abteilung. Mit Vertretung.

Zum Betrieb gehört noch eine zweite Ebene von Regeln: die, die nicht die Maschine selbst betreffen, sondern ihren Einsatz - in der Halle sind das bspw. Lärmgrenzen und Arbeitsschutz, bei einem Workflow ist es die Frage, welche Daten durch ihn laufen und welche Gesetze daran hängen: Datenschutz, Mitbestimmung, KI-Verordnung. Was diese Ebene an einem konkreten Ablauf bedeutet, haben wir am Beispiel Krankmeldungen durchsortiert. Dieser Artikel hier bleibt auf der Betriebs-Ebene.

Wer aus der Produktion kommt, muss für den Betrieb von Workflows also nichts großartig Neues lernen - nur eine bekannte Disziplin auf eine neue „Anlage“ anwenden. Interessant wird es bei der Frage, was an dieser Anlage anders kaputtgeht.

Laut, leise, falsch: drei Arten von Störung

Sortiert man, was bei einem Workflow schiefgehen kann, bleiben drei Klassen übrig: der technische Fehler, der sich selbst meldet. Der Infrastruktur-Ausfall, bei dem gar nichts mehr anläuft. Und der semantische Fehler, der technisch sauber durchläuft und trotzdem falsch ist. Die drei unterscheiden sich nicht darin, wie schlimm sie sind, sondern darin, ob und wie sie sich bemerkbar machen - und genau davon hängt ab, welche Vorkehrung sie brauchen.

Laut: der technische Fehler

Ein Dienst antwortet nicht, ein Anhang hat ein unbekanntes Format, eine Datei lässt sich nicht öffnen. Ein Schritt scheitert, der Lauf hält an. Technisch ist das die deterministische Klasse: Das System weiß selbst, dass es gescheitert ist, und kann es deshalb melden. Das ist der gutmütige Fall. In n8n lässt sich zu jedem Workflow ein zweiter hinterlegen, der genau dann startet - und mitgeliefert bekommt, welcher Lauf betroffen war, an welchem Schritt es hakte und mit welcher Meldung.^[1] Was er damit tut, ist eine Entscheidung, keine Technik: eine Nachricht an den Besitzer, bei kritischen Abläufen zusätzlich an einen zweiten Kanal.

Innerhalb dieser Klasse lohnt eine zweite Sortierung, weil nicht jede Störung dieselbe Antwort verdient. Die erwartete Ausnahme: eine Meldung ohne Anhang, ein unvollständiges Formular - dies sind keine Fehler, sondern erwartbare Fälle und diese bekommen im Bauplan einen eigenen Ast - etwa eine Rückfrage an den Absender. Für die vorübergehende Störung - das Netz hakt, ein Dienst ist kurz nicht erreichbar - können einzelne Schritte sich selbst wiederholen, mit ein paar Minuten Abstand und mit fester Obergrenze. Eine Wiederholung ohne Limit läuft heiß und erzeugt Kosten statt Ergebnisse. Nach dem letzten Versuch gilt wieder: anhalten und melden. Und die echte Überraschung, das neue Format, das geänderte Formular: anhalten und einen Menschen rufen. Ein Ablauf, der bei Überraschungen weiterläuft, ist keiner, den man in der Nähe von Personal- oder Finanzdaten betreiben möchte.

Leise: der Infrastruktur-Ausfall

Die zweite Klasse ist die gefährlichere, und man kann sie schnell übersehen: der Workflow, der gar nicht mehr anläuft. Das ist kein Fehler im Ablauf, sondern ein Ausfall davor: Der Server, auf dem die Automatisierungsplattform läuft, ist ausgefallen, die Zugangsdaten sind abgelaufen oder der Zeitplan wurde beim Aufräumen deaktiviert. Kein Lauf bedeutet: kein Fehler. Kein Fehler bedeutet: keine Störmeldung. Die Störmeldekette aus der ersten Klasse ist hier wirkungslos, denn sie springt nur an, wenn etwas läuft und dabei scheitert.

Dazu kommt eine Eigenschaft, die man kennen muss: Verpasste Läufe werden nicht nachgeholt. Stand die Plattform um 3 Uhr, als der nächtliche Lauf geplant war, findet dieser Lauf auch nach dem Neustart nicht statt. Der nächste Lauf startet zur nächsten geplanten Zeit.^[2]

Die Industrie kennt dieses Problem seit langem, und ihre Antwort heißt Totmannschalter: Nicht die Störung löst den Alarm aus, sondern das Ausbleiben des Lebenszeichens. Übersetzt: Ein Beobachter außerhalb der Anlage fragt regelmäßig, ob sie noch betriebsbereit ist - denn eine Anlage, die steht, kann ihren eigenen Stillstand nicht melden. n8n bringt dafür zwei Endpunkte mit, die ein externer Überwachungsdienst regelmäßig abfragt - von außerhalb der eigenen Infrastruktur, sonst stirbt der Beobachter mit der Anlage. Der Unterschied zwischen den beiden Endpunkten ist der Punkt, auf den es ankommt: Der eine antwortet, wenn der Prozess erreichbar ist; der andere erst, wenn auch die Datenbank verbunden ist - wenn die Anlage also nicht nur da ist, sondern arbeiten kann.^[3] „Sie antwortet“ und „sie ist betriebsbereit“ sind zwei verschiedene Aussagen.

Falsch: der semantische Fehler

Die dritte Klasse ist eine grundsätzliche Eigenschaft von KI-Systemen und sie ist die einzige, die kein technischer Fehler ist, sondern ein inhaltlicher. Technisch gesprochen ein semantischer Fehler: Die Form stimmt, der Inhalt nicht. Ein KI-Schritt kann scheitern, ohne zu scheitern: Der Lauf wird grün, das Ergebnis ist plausibel - aber falsch. Ein gelesenes Datum im falschen Monat, ein Feld aus dem falschen Absatz.

Die Halle kennt das. Auch eine einwandfrei laufende Maschine produziert hin und wieder Ausschuss, deshalb gibt es Toleranzen, Prüfmittel und Endkontrolle. Ein klassischer Rechenschritt liefert bei gleicher Eingabe immer dasselbe Ergebnis. Ein KI-Schritt arbeitet probabilistisch: Sein Ergebnis ist eine Schätzung - meist eine sehr gute, aber eine Restfehlerquote bleibt und der Schritt merkt selbst nicht zuverlässig, wenn er danebenliegt. Deshalb wandert die Prüfung aus dem Schritt heraus in den Ablauf drumherum: Schwellen, unter denen ein Ergebnis nicht weiterverarbeitet wird, Pflichtfelder, ohne die ein Fall nicht weitergeht und an jeder Stelle, an der das Ergebnis Wirkung hat, die Endkontrolle durch einen Menschen. Nicht als Misstrauen gegen das Werkzeug, sondern als das, was Endkontrolle in der Fertigung immer war: der Schritt, der aus Ausschuss ein beherrschbares Risiko macht.

Fünf Fragen für die Abnahme

Ob ein Workflow betriebsbereit ist, entscheidet - wie bei der Maschine - die Abnahme. Sie besteht hier aus fünf Fragen: Die ersten drei prüfen, ob der Ablauf auf jede der drei Störungsarten eine Antwort hat. Die letzten zwei prüfen den Weg zurück in den Betrieb: was ein Stopp hinterlässt und wer ihn wie behebt.

1 - Woran merkt der Ablauf selbst, dass etwas schiefging? Wenn die Antwort „gar nicht“ lautet, fehlt die Störmeldekette. Sie ist ein Nachmittag Arbeit und gehört zu jedem Workflow, der am Ende unbeaufsichtigt läuft.

2 - Woran merkt ihr, dass der Workflow nicht mehr läuft? Die Frage nach dem Lebenszeichen. Wer nur Frage 1 beantwortet hat, bewacht die Anlage, aber nicht die Halle.

3 - Woran merkt ihr, dass er läuft, aber Ausschuss produziert? Von allein merkt es niemand - das ist die Eigenschaft dieser Klasse. Merken heißt hier prüfen: Was sich messen lässt, prüft der Ablauf selbst (Schwellen, Pflichtfelder). Den Rest prüft ein Mensch, als Endkontrolle vor jeder Wirkung oder als regelmäßige Stichprobe. Wie engmaschig, richtet sich danach, was ein falsches Ergebnis anrichten würde.

4 - Was hinterlässt er, wenn er mitten im Lauf stehen bleibt? Die Antwort, die man hören will: nichts Halbes. Gelesen, geprüft, freigegeben - geschrieben wird am Ende. Dann ist ein Stopp ärgerlich, aber kein Schaden.

5 - Wer repariert ihn und steht das in der Betriebsanleitung? Eine Seite, kein dicker Ordner. Die häufigsten Störungen sollte die Vertretung nach Anleitung beheben können, ohne je einen Workflow gebaut zu haben. Eine Maschine ohne Betriebsanleitung würde niemand abnehmen - ein Workflow ohne sie ist nicht betriebsbereit.

Auch die Störmeldungen sind Daten

Auch diese Ebene übersieht man schnell: die Störmeldung selbst. Scheitert ein Lauf mitten in der Verarbeitung, steht in der Fehlermeldung oft genau das, was gerade verarbeitet wurde - bei Personalprozessen also Namen, Zeiträume, im schlechtesten Fall mehr. Diese Meldung geht dann als Mail an den Besitzer, in einen Team-Chat, in ein Protokoll: an Orte, für die nie jemand entschieden hat, dass dort Personaldaten liegen dürfen.

Deshalb laufen Fehlertexte durch dieselbe Sorte Maskierung wie alle anderen Daten, die das Haus verlassen, bevor sie in Log, Mail oder Chat gehen. Für die Diagnose reicht, welcher Lauf an welchem Schritt mit welcher Fehlerart stand - wessen Fall es war, steht im Protokoll im Haus und nur dort.

Abgleich mit dem bestehenden Prozess

Gemessen wird ein Workflow an dem Ablauf, den ihr heute habt. Auch ein manueller Prozess bleibt stehen: Die zuständige Kollegin ist krank, im Urlaub, das Postfach quillt über. Nur meldet er sich dann nicht. Die Aufgabe liegt und wartet und bemerkt wird es, wenn ein Stichtag das Ergebnis des Prozesses benötigt. Ein Workflow mit Störmeldekette und Lebenszeichen hält im Zweifel genauso an - aber er sagt sofort Bescheid, protokolliert den Fall und lässt nichts Halbes zurück. Das ist der Vergleich, um den es geht: gemeldeter Stillstand gegen stillen.

Und die Grenze gehört dazu: Ein Workflow ohne Besitzer, ohne Störmeldung und ohne Betriebsanleitung ist ein Risiko im Dauerbetrieb.

Anhalten, melden, liegen lassen - in dieser Reihenfolge. Schlimm ist nur der Stillstand, den niemand bemerkt.

Der erste Schritt ist kein großes Projekt: Stellt die fünf Fragen an einen Ablauf, der bei euch heute bereits läuft - das kann ein Workflow sein oder ein Prozess, der noch von Hand über ein Postfach läuft. Wo die ehrliche Antwort „am Stichtag“ lautet, wisst ihr, wo anzufangen ist.