Zwei Automatisierungen, die voneinander abhängen, ohne es zu wissen
Ein Umsatzbericht, der elf Monate im Jahr stimmt und am Monatsende falsch ist: Wie zwei zeitgesteuerte Automatisierungen eine versteckte Abhängigkeit bilden, warum der Sicherheitspuffer genau dann versagt, wenn es zählt, und wie Sie in Make, n8n und Zapier über Fertigstellung statt über die Uhr koppeln.
Zwei Automatisierungen, die voneinander abhängen, ohne es zu wissen
Bei einem Kunden lief ein Nachtjob, der jeden Morgen einen Umsatzbericht per E-Mail an die Geschäftsführung schickte. Elf Monate im Jahr stimmte der Bericht. Immer am Monatsende war er falsch, meistens ein paar Tausend Euro zu niedrig. Niemand fand einen Fehler in der Berechnung, weil keiner drin war.
Der Aufbau war unauffällig. Ein Szenario zog um 02:00 Uhr die Verkaufsdaten des Vortags aus dem Shop in eine Tabelle. Ein zweites Szenario las um 02:30 Uhr dieselbe Tabelle, rechnete die Summen zusammen und verschickte den Bericht. An einem normalen Tag war das erste Szenario nach zehn Minuten fertig. Am Monatsende, wenn das Datenvolumen sich verdreifachte, brauchte es vierzig. Um 02:30 Uhr las das zweite Szenario also eine halb gefüllte Tabelle und rechnete brav mit dem, was da war.
Beide Szenarien meldeten Erfolg. Kein roter Punkt, keine Fehlermeldung, keine Warnung. Aus Sicht der Plattform war alles in Ordnung. Der Bericht war trotzdem falsch.
Der Zusammenhang stand nirgends
Das Problem war nicht die Uhrzeit. Das Problem war, dass zwischen den beiden Szenarien eine Abhängigkeit bestand, die niemand aufgeschrieben hatte. Szenario B durfte erst laufen, wenn Szenario A fertig war. Diese Regel existierte nur im Kopf der Person, die vor anderthalb Jahren die beiden Zeiten in die Dropdowns eingetragen hatte. Und diese Person hatte das Unternehmen längst verlassen.
Die halbe Stunde Abstand war als Sicherheitspuffer gedacht. Der Gedanke dahinter ist verständlich. A braucht zehn Minuten, ich gebe B einen komfortablen Vorlauf, fertig. Das funktioniert, bis der Puffer zu klein ist. Und er ist immer genau an den Tagen zu klein, an denen es darauf ankommt: am Monatsende, während einer Kampagne, nach einem Ausfall, wenn ein Rückstau abgearbeitet wird. Ein Puffer, der für den Normalfall bemessen ist, versagt zuverlässig im Ausnahmefall.
Die Uhr ist kein Abhängigkeitsmanager
No-Code-Plattformen machen es leicht, in diese Falle zu laufen. In Make, n8n oder Zapier planen Sie einen Trigger mit zwei Klicks. Sie wählen eine Uhrzeit aus einem Menü. Was diese Werkzeuge von Haus aus nicht anbieten, ist der Gedanke: starte B, sobald A durch ist. Also behelfen sich die meisten mit festen Zeiten und einem Puffer. Der Puffer ist eine Wette darauf, dass der Vorgänger schnell genug ist. Solche Wetten verliert man selten, aber wenn, dann teuer und unbemerkt.
Was uns an solchen Fällen stört, ist die Stille. Ein Workflow, der abstürzt, meldet sich. Ein Workflow, der mit unvollständigen Daten rechnet, tut genau das, was er soll, nur eben mit dem falschen Input. Diese Sorte Fehler findet man nicht im Log. Man findet sie, wenn ein Mensch den Bericht anschaut und sagt, die Zahl kann nicht stimmen.
Koppeln Sie über Fertigstellung, nicht über die Uhrzeit
Der Ausweg ist kein größerer Puffer. Ein größerer Puffer verschiebt das Problem nur nach hinten. Der Ausweg ist, die Abhängigkeit sichtbar zu machen und die Uhr aus der Entscheidung zu nehmen.
Am saubersten ist es, die Szenarien direkt zu verketten. A ruft am Ende B auf, per Webhook oder über den eingebauten Aufruf des jeweiligen Werkzeugs. B startet dann genau in dem Moment, in dem A wirklich fertig ist, und keine Minute vorher. Das ist eine echte Reihenfolge statt einer gehofften.
Wenn sich das nicht anbietet, arbeiten Sie mit einem Status. A schreibt nach dem letzten Schritt einen Marker in einen Kontrolldatensatz, etwa "Lauf vom 21.07. abgeschlossen" mit Zeitstempel. B prüft diesen Marker, bevor es rechnet. Fehlt er oder ist er von gestern, bricht B ab und meldet sich, statt mit alten Daten weiterzumachen.
Manchmal ist die einfachste Lösung, aus zwei Szenarien eines zu machen. Wenn Laden und Verrechnen ohnehin zusammengehören, gehören sie in denselben Ablauf, wo die Reihenfolge von selbst garantiert ist. Zwei getrennte Szenarien lohnen sich nur, wenn es einen guten Grund für die Trennung gibt.
Und wenn Sie aus betrieblichen Gründen bei zwei Zeitplänen bleiben müssen, geben Sie B mindestens die Fähigkeit, sich zu weigern. Eine kurze Prüfung reicht. Passt die Zeilenzahl grob zur Erwartung? Ist der erwartete Endmarker da? Sind die Daten von heute? Lieber bricht der Bericht laut ab, als dass er still eine falsche Zahl verschickt. Ein ausgefallener Bericht fällt am Morgen auf. Ein falscher Bericht wird geglaubt.
Der Punkt dahinter
Jedes Mal, wenn Sie zwei Zeitpläne mit einem Abstand versehen, schreiben Sie eine Annahme in unsichtbarer Tinte auf. Die Annahme lautet: Der Erste ist rechtzeitig fertig. An den meisten Tagen stimmt sie. An den Tagen, an denen sie nicht stimmt, merkt es keiner, bis der Schaden schon da ist.
Wir sehen diese versteckte zeitliche Kopplung in fast jedem gewachsenen Automatisierungs-Setup, das wir uns anschauen. Sie ist kein Zeichen von schlechter Arbeit. Sie entsteht, weil die Plattformen das Planen über die Uhr einfach machen und das Koppeln über Fertigstellung nicht. Wer das einmal verstanden hat, plant Nachtjobs anders. Nicht nach der Uhr, sondern nach dem, was vorher passiert sein muss.