Unsere größten Automation-Fails und was sie uns gelehrt haben
An einem Sonntagmorgen hat eine unserer Automationen 1.400 E-Mails verschickt. An 340 Kunden, jeder vier Stück, innerhalb von elf Minuten.
Ich schreibe das auf, weil ich seitdem eine Regel habe, die ich vorher nicht hatte. In Gesprächen höre ich oft, Automatisierung sei entweder fertig oder kaputt. Sie ist meistens weder noch.
Hier sind fünf Fehlschläge aus unseren eigenen Brands. Jeder mit dem, was passiert ist, warum es passiert ist, und was wir daraus gebaut haben. Keine anonymen Kundengeschichten, keine schöngerechneten Zahlen. Unsere eigenen.
Fail 1: Eine Schleife ohne Abbruchbedingung
Wir hatten einen Workflow, der Bestellungen an den Fulfiller übergibt. Wenn der Fulfiller nicht antwortet, versucht er es erneut. Klingt vernünftig.
Das Problem: Es gab keine Obergrenze. Der Fulfiller hatte eine Wartung und lieferte 40 Sekunden lang Fehler zurück. Der Workflow probierte es weiter. Nach einer Stunde standen 6.000 Aufrufe im Log, und unser API-Kontingent für den Tag war aufgebraucht. Danach kamen echte Bestellungen nicht mehr durch.
Die Ursache: Ich hatte an den Fehlerfall gedacht, aber nicht an den Fehlerfall, der anhält. Ein einzelner Aussetzer und ein zwanzigminütiger Ausfall sehen für den Workflow gleich aus.
Die Lehre: Jeder Wiederholungsversuch braucht drei Grenzen. Eine maximale Anzahl, einen wachsenden Abstand zwischen den Versuchen, und einen definierten Endzustand. Bei uns heißt der Endzustand: Der Fall landet in einer Liste, ein Mensch bekommt eine Nachricht, der Workflow hört auf. Stillstand mit Meldung ist immer besser als Bewegung ohne Ziel.
Fail 2: 1.400 Mails an einem Sonntag
Zurück zur Einleitung. Der Workflow schickte eine Versandbestätigung, sobald eine Tracking-Nummer im System auftauchte. Sonntagnacht ist der Server neu gestartet. Beim Hochfahren hat das System die Warteschlange der letzten Stunden noch einmal abgearbeitet. Und weil der Neustart dreimal passierte, dreimal zusätzlich.
Nirgendwo stand die Frage: Habe ich diese Mail für diese Bestellung schon verschickt?
Die Ursache: Ein Workflow, der nur den Auslöser kennt und nicht sein eigenes Ergebnis. Fachleute nennen das fehlende Idempotenz. Das bedeutet: Wenn du denselben Schritt zweimal ausführst, soll beim zweiten Mal nichts mehr passieren.
Die Lehre: Alles, was das Haus verlässt, bekommt bei uns einen Schlüssel und einen Vermerk. Vor dem Versand prüft der Workflow, ob dieser Schlüssel schon vermerkt ist. Das sind zwei zusätzliche Schritte pro Workflow und ungefähr zehn Minuten Bauzeit. Der Sonntag hat uns rund 300 Euro an Gutscheinen und einen halben Tag Entschuldigungen gekostet.
Fail 3: Bestandszahlen, die niemand mehr glaubte
Wir gleichen Lagerbestände zwischen Shop, Marktplätzen und Fulfiller ab. Eine Zeitlang lief das über einen Abgleich alle 15 Minuten. Jeder Kanal schrieb seinen Stand, der letzte gewann.
Über Wochen wurden die Zahlen falsch. Mal 3 Stück zu viel, mal 8 zu wenig. Wir haben zweimal Ware verkauft, die es nicht mehr gab. Und einmal wochenlang ein Produkt als ausverkauft geführt, von dem 60 Stück im Regal lagen.
Die Ursache: Zwei Systeme haben denselben Wert gleichzeitig geändert. Wenn beide von einem alten Stand ausgehen, überschreibt der langsamere den schnelleren. Dazu kam eine Zeitzone: Ein Kanal lieferte Zeitstempel in UTC, ein anderer in lokaler Zeit. Zwei Stunden Versatz reichen, um die falsche Änderung zur neueren zu erklären.
Die Lehre: Für jeden Wert gibt es genau ein System, das ihn besitzt. Alle anderen lesen ihn und schreiben ihn nie. Bei uns ist das der Fulfiller, weil dort die Ware physisch liegt. Und jeder Zeitstempel im Haus ist UTC, ohne Ausnahme. Diese Entscheidung hätte am Anfang zwei Stunden Nachdenken gekostet. Nachträglich hat sie eine Woche Umbau gekostet.
Fail 4: Wir haben einen Prozess automatisiert, den es zwei Wochen später nicht mehr gab
Bei einer unserer Brands haben wir den Retourenprozess automatisiert. Formular, Label, Prüfung, Erstattung, Bestandsbuchung. Sechs Tage Arbeit, sauber gebaut, gut getestet.
Zwölf Tage nach dem Livegang haben wir den Fulfiller gewechselt. Der neue arbeitete mit einem anderen Rücksendeverfahren. Von den sechs Tagen Arbeit blieb ungefähr ein Tag übrig.
Die Ursache: Der Wechsel stand seit Monaten im Raum. Ich wusste das. Ich habe trotzdem gebaut, weil der Prozess gerade wehtat und weil ich Lust auf die Aufgabe hatte. Es war Ungeduld, keine Fehleinschätzung.
Die Lehre: Bevor wir bauen, fragen wir seit dem: Steht dieser Prozess in sechs Monaten noch so da? Wenn die Antwort unsicher ist, bauen wir die kleinste Version, die den Schmerz nimmt, und warten. Wann sich Automatisierung grundsätzlich nicht lohnt, haben wir in Wann Automatisierung keinen Sinn macht aufgeschrieben. Der umgekehrte Fehler, zu spät zu automatisieren, kostet übrigens auch, nachzulesen in Der 10.000 Euro Fehler.
Fail 5: Ein Workflow war elf Tage tot, und niemand hat es gemerkt
Unser wöchentlicher Report für eine Brand lief seit einem Jahr. Irgendwann kam er nicht mehr. Aufgefallen ist es, weil jemand eine Zahl gesucht hat.
Elf Tage vorher hatte ein Anbieter seine Zugangsdaten rotiert. Der Workflow brach am ersten Schritt ab. Er meldete den Fehler brav in ein Log, das niemand liest.
Die Ursache: Wir haben überwacht, ob Fehler auftreten. Wir haben nicht überwacht, ob etwas ausbleibt. Ein Workflow, der stirbt, macht keinen Lärm. Er wird einfach still.
Die Lehre: Jeder regelmäßige Workflow braucht einen Wächter, der prüft, ob er gelaufen ist. Bei uns meldet sich ein zweiter, kleiner Ablauf, wenn der erste innerhalb seines Zeitfensters kein Lebenszeichen hinterlassen hat. Das ist unspektakulär und hat seitdem drei tote Workflows gefunden, bevor jemand sie vermisst hat.
Was die fünf gemeinsam haben
Ich habe lange gedacht, das seien fünf verschiedene Themen. Sind sie nicht. Vier von fünf Fällen haben denselben Kern: Der Workflow kannte seinen eigenen Zustand nicht.
Er wusste nicht, wie oft er es schon versucht hat. Er wusste nicht, ob er diese Mail schon geschickt hat. Er wusste nicht, wessen Zahl gerade die richtige ist. Er wusste nicht, dass er letzte Woche gelaufen ist.
Ein Workflow, der nur auf Auslöser reagiert und nichts über sich selbst weiß, funktioniert perfekt, solange alles glatt läuft. Das ist die gefährliche Sorte Fehler, denn sie zeigt sich erst am ersten schlechten Tag.
| Fail | Kern | Regel bei uns |
|---|---|---|
| Endlose Wiederholung | Kein Endzustand | Grenze, Abstand, Meldung |
| Doppelte Mails | Kein Gedächtnis | Schlüssel vor jedem Versand |
| Falsche Bestände | Kein Eigentümer | Ein System besitzt den Wert |
| Zu früh gebaut | Kein stabiler Prozess | Erst Klarheit, dann Automation |
| Toter Workflow | Keine Erwartung | Wächter auf Ausbleiben |
Was uns nicht gerettet hätte
Zwei Dinge, die oft als Antwort auf solche Geschichten kommen und bei uns nicht die Lösung waren.
Mehr Tests. Alle fünf Workflows hatten Tests. Getestet wurde der Weg, den ich mir vorgestellt habe. Der Sonntag mit dem Neustart stand in keinem Test, weil ich nicht auf die Idee kam. Tests prüfen deine Annahmen, sie ersetzen sie nicht.
Eine menschliche Freigabe an jeder Stelle. Freigaben helfen enorm, aber nur bei Entscheidungen, die ein Mensch in Sekunden beurteilen kann. Bei doppelten Mails oder einem stillen Ausfall hilft kein Klick. Wo Freigaben wirklich tragen, steht in Human in the Loop.
Die Grenzen dieser Lehren
Ich will nicht so tun, als hätten wir das jetzt gelöst. Drei Einschränkungen.
Erstens: Die Regeln oben kosten Zeit. Ein Workflow mit Wächter, Schlüssel und sauberen Grenzen braucht ungefähr 30 Prozent länger als die schnelle Version. Bei einer Automation, die zweimal im Monat läuft, ist das schlicht zu viel. Wir bauen dort bewusst nachlässiger und wissen es.
Zweitens: Wir machen weiter Fehler. Dieses Jahr hatten wir zwei neue Sorten, die in keiner der fünf Kategorien stecken. Die Liste ist keine Abschlussliste.
Drittens: Bei KI-Schritten greift keine dieser Regeln. Ein Modell, das eine falsche, aber plausibel klingende Antwort schreibt, verletzt keine technische Bedingung. Warum das so ist und was hilft, steht in KI-Halluzinationen vermeiden.
Fazit
Am teuersten waren bei diesen fünf Fällen die Stunden, in denen wir unseren eigenen Zahlen misstraut und alles von Hand nachgerechnet haben. Das Geld war der kleinere Posten. Eine Automation, der du nicht glaubst, ist schlimmer als gar keine.
Wenn du selbst gerade baust: Nimm dir die Tabelle oben und geh damit durch deinen wichtigsten Workflow. Vier Fragen, zwanzig Minuten. Bei den meisten fällt sofort etwas auf.
Und falls du wissen willst, welche Prozesse sich bei dir überhaupt lohnen, ist E-Commerce Prozesse automatisieren der bessere Startpunkt als dieser Artikel hier.
Wenn du deine bestehenden Automationen einmal von außen durchgehen lassen willst: Sprich mit uns bei Flowhouse. Wir sagen dir auch, wenn alles in Ordnung ist.