Was passiert, wenn der Mensch hinter den Workflows nicht da ist
Ein Workflow läuft seit Monaten unbemerkt. Dann fällt er aus, und die einzige Person, die ihn versteht, ist im Urlaub. Warum das Bus-Factor-Problem in No-Code-Automatisierungen still und teuer ist, und wie sich Single Points of Failure mit fünf einfachen Disziplinen vermeiden lassen.
Was passiert, wenn der Mensch hinter den Workflows nicht da ist
Letzten Sommer rief mich ein Kunde aus Spanien an. Er war seit zwei Tagen im Urlaub. Sein Team hatte versucht, einen Workflow zu reparieren, der nicht mehr lief. Niemand fand ihn. Niemand wusste, wo er gebaut wurde, niemand kannte die Logik, niemand hatte die Zugangsdaten zu dem Make-Account, in dem er lag.
"Ich bin doch nur eine Woche weg", sagte er.
Er war derjenige, der den Workflow vor neun Monaten gebaut hatte. Er allein. Ein Sales-Lead-Routing-Workflow, der jeden Tag zwischen 200 und 400 Leads sortierte, qualifizierte und an die richtigen Mitarbeiter zuwies. Lief tadellos, deshalb hatte ihn niemand mehr angefasst. Jetzt war er kaputt. Und der einzige Mensch, der wusste, was darin passierte, lag am Strand.
Diese Geschichte ist die Regel, nicht die Ausnahme. Ich nenne sie das Bus-Factor-Problem in der Automatisierung. Wenn die Person, die einen kritischen Workflow gebaut hat, von einem Bus überfahren wird, oder eben nur in Urlaub geht, läuft das Geschäft dann weiter, oder bleibt es stehen?
Bei den meisten Automatisierungen, die ich in Unternehmen sehe, ist die Antwort: es bleibt stehen. Die Unternehmen wissen es nur noch nicht.
Warum No-Code das Problem verschärft
In klassischer Softwareentwicklung gibt es Schutzmechanismen. Pull Requests, Code Reviews, Versionsgeschichte, geteilte Repositories. Selbst wenn ein Entwickler weggeht, ist sein Code lesbar und im Repo. Jemand anderes kann sich einarbeiten und nach drei Wochen verstehen, was die Software macht.
Bei No-Code-Plattformen wie Make, Zapier oder n8n existiert dieser Schutz nicht in der gleichen Form. Ein Workflow ist ein visuelles Diagramm, das im Account einer einzigen Person liegt. Es gibt keine Pull Requests. Es gibt keine Reviews. Versionierung, wo es sie überhaupt gibt, ist oft nur eine pro forma vorhandene Funktion.
Drei Effekte, die daraus folgen:
Wissen sitzt in einem Kopf. Der Workflow funktioniert, also schaut sich niemand mehr an, wie er funktioniert. Solange alles läuft, ist das egal. Wenn er stehen bleibt, kann nur die Person ihn reparieren, die ihn gebaut hat. Sonst niemand.
Zugänge sind privat. Der Workflow läuft im persönlichen Make-Account, weil das damals am schnellsten war. Niemand sonst hat Zugang. Niemand sonst sieht die Logs. Niemand kann eingreifen, wenn etwas schiefgeht.
Dokumentation gibt es nicht. Wer in einem No-Code-Tool baut, hat selten das Gefühl, "richtige Software" zu schreiben. Dokumentation fühlt sich wie übertriebener Aufwand an. Also dokumentiert niemand. Bis der Aufwand nicht mehr übertrieben ist.
Wann es teuer wird
Solange der Workflow läuft, ist das Bus-Factor-Problem unsichtbar. Es zeigt sich in vier Situationen:
Krankheit oder Kündigung. Die Person, die den Workflow gebaut hat, fällt aus. Schlimmstenfalls dauerhaft. Was bleibt, ist ein Diagramm, das niemand mehr versteht.
Externe Veränderungen. Eine API ändert sich. Ein Anbieter führt eine neue Auth-Methode ein. Der Workflow bricht. Die Person, die ihn reparieren könnte, ist entweder nicht da oder hat ihn vor zwei Jahren gebaut und erinnert sich nicht mehr.
Verändertes Geschäft. Das Unternehmen wächst, der Vertrieb arbeitet anders, der Lead-Routing-Workflow muss angepasst werden. Eine andere Person versucht, ihn zu ändern. Sie versteht die Logik nicht und bricht etwas, was sie nicht verstanden hat.
Audits und Compliance. Jemand fragt: "Was passiert mit den Daten, die in diesem Workflow durchlaufen?" Niemand kann es beantworten. Die Person, die es wüsste, ist nicht erreichbar oder weiß es selbst nicht mehr genau.
In allen vier Fällen ist die Reparatur teurer als die ursprüngliche Bauphase. Manchmal um den Faktor fünf. Manchmal um den Faktor zehn.
Was hilft
Es gibt kein technisches Werkzeug, das dieses Problem löst. Es ist ein Disziplinproblem, und die Disziplin muss vor dem ersten Workflow eingebaut werden, nicht nachher.
Geteilte Accounts statt persönlicher. Jeder produktive Workflow läuft in einem Team-Account, nicht im persönlichen. Make, Zapier und n8n bieten Team-Pläne. Sie kosten mehr. Sie sind ihren Preis wert.
Eine kurze Beschreibung pro Workflow, sichtbar im Workflow selbst. Drei Sätze reichen. Was tut dieser Workflow? Wann läuft er? Wer ist Owner? Diese drei Sätze stehen entweder als Kommentar im ersten Modul oder als Notiz direkt im Workflow-Header.
Eine Zwei-Personen-Regel. Jeder produktive Workflow hat einen primären Owner und einen zweiten Verantwortlichen. Der zweite kennt den Workflow, ist ihn einmal mit dem Owner durchgegangen und hat Zugang, ihn anzupassen.
Eine Übergabe alle sechs Monate. Zweimal pro Jahr setzen sich Owner und zweite Verantwortliche zusammen, gehen die produktiven Workflows durch, prüfen, ob die Beschreibungen noch stimmen, ob Zugänge funktionieren, ob die Logik noch dem aktuellen Geschäft entspricht. Diese Sitzung dauert zwei Stunden, kostet einen halben Arbeitstag pro Halbjahr und spart im Notfall Tausende.
Klare Regeln, was produktiv heißt. Nicht jeder Workflow muss diese Behandlung bekommen. Eine Spielerei zwischen zwei Mitarbeitern, ein einmaliger Daten-Import, ein internes Experiment, das ist alles in Ordnung. Aber sobald ein Workflow geschäftskritisch wird, gilt das Protokoll. Diese Schwelle muss explizit definiert sein, sonst bleibt alles informell.
Was Sie heute prüfen können
Eine schnelle Übung. Schreiben Sie auf einem Blatt Papier alle Automatisierungen auf, die in Ihrem Unternehmen produktiv laufen. Make, Zapier, n8n, vielleicht Power Automate, vielleicht selbst gebaute Skripte.
Für jeden Eintrag drei Fragen:
1. Wenn der Workflow heute Nacht ausfällt, wer kann ihn morgen reparieren? 2. Wenn diese Person nicht erreichbar ist, wer könnte ihn dann reparieren? 3. Wo ist die Logik dokumentiert, die den Workflow ausmacht?
Wenn Sie bei mehr als einem Drittel Ihrer Workflows keine klare Antwort auf alle drei Fragen haben, haben Sie ein Bus-Factor-Problem. Solche Probleme bleiben unauffällig, bis etwas schiefgeht oder jemand fehlt. Dann ist die Reparatur teuer und in den meisten Fällen vermeidbar gewesen.
Der eigentliche Punkt
Automatisierungen sind nicht "nur Werkzeuge". Sie sind Geschäftslogik, die in einem Tool steht. Wenn diese Logik nur in einem Kopf existiert, ist sie ein Single Point of Failure, den Sie in keinem Architektur-Diagramm sehen, der aber jederzeit aufschlagen kann.
Die meisten Unternehmen haben für ihre Software-Architektur längst gelernt, dass geteiltes Wissen Pflicht ist. Bei Automatisierungen sind sie zwei oder drei Jahre hinterher. Das wird sich legen, weil die Schmerzpunkte zu offensichtlich werden. Bis dahin lohnt es sich, vorne zu sein.
Wer wissen möchte, wo die kritischen Single Points of Failure in den eigenen Automatisierungen liegen, bekommt im kostenlosen Automations-Check in etwa 30 Minuten ein klares Bild.