Die Frage, die niemand beantwortet, bis es 23:40 an einem Freitag ist
Die Automatisierung läuft seit acht Monaten und niemand hat mehr über sie geredet. Genau dafür wurde sie gekauft. Das Problem ist, dass dieses Schweigen mit einer Antwort auf eine Frage verwechselt wird, die nie gestellt wurde: Wenn das hier ausfällt, wer übernimmt? Und die Frage beantwortet sich von selbst, schlecht, in der ersten Nacht, in der der Bestellfluss keine Lieferscheine mehr anlegt: Jemand schreibt in die WhatsApp-Gruppe des Teams, jemand anders antwortet um sieben Uhr morgens, und unterwegs sind vierzehn Bestellungen unbearbeitet geblieben, von denen noch niemand weiß.
Bereitschaft und Support für Automatisierungen sind der Teil von Tag zwei, den fast niemand kauft, weil er in der Demo nicht vorkommt. Das ist kein 24×7-Dienst mit Telefonzentrale. Das sind vier in Ruhe getroffene Entscheidungen —was schwer ist, wen man anruft, was diese Person tut, wenn sie ankommt, und was in der Zwischenzeit passiert— aufgeschrieben an einem Ort, an dem sie jemand findet, der nicht du bist. Ohne sie ist dein Notfallplan dein Gedächtnis, und dein Gedächtnis fährt im August in den Urlaub.
Echte Schweregrade: Was einen Anruf rechtfertigt und was bis morgen wartet
Die erste Entscheidung ist nicht, wen du anrufst: Es ist, wann überhaupt jemand angerufen wird. Ohne diese aufgeschriebene Linie passieren die beiden schlechten Dinge gleichzeitig. Entweder wirkt alles dringend —und das Team lernt, die Meldungen zu ignorieren, weil sie wegen jeder Kleinigkeit losgehen— oder nichts wirkt dringend, und der Fehler, der Geld gekostet hat, wird am Montag entdeckt.
Die Operations-Branche löst das seit Jahrzehnten mit Schweregraden, und die etablierte Praxis ist vernünftig: PagerDuty empfiehlt, jede Stufe direkt auf die Eskalations- und Meldepolitik abzubilden, und warnt davor, dass sechs oder sieben Stufen, die niemand auseinanderhalten kann, zu Klassifizierungslähmung führen: drei bis fünf sind der Sweet Spot. In einem Unternehmen ohne Bereitschaftsteam sind drei mehr als genug.
| Stufe | Was es bei dir zu Hause bedeutet | Was passiert |
|---|---|---|
| Schwer | Gerade jetzt geht Geld oder eine Zusage an Kunden verloren: keine Bestellungen raus, keine Rechnungen kassiert, niemand bekommt eine Antwort. | Die Bereitschaft wird sofort verständigt, egal wie spät es ist. Der manuelle Plan wird aktiviert. |
| Lästig | Der Prozess läuft halb oder nur für einen Teil: eine ausgefallene Integration mit Umweg, ein Stapel, der nicht verarbeitet wurde, sich aber nachverarbeiten lässt. | Wird protokolliert und am nächsten Werktag als Erstes angegangen. Nachts wird niemand angerufen. |
| Hässlich, aber es kann warten | Etwas ist falsch und hat keine unmittelbare Folge: ein Bericht, der nicht erzeugt wurde, ein Feld, das leer ankommt, an einer Stelle, die bis zum Monatsabschluss niemand ansieht. | Geht in die Wartungsschlange der Woche. |
Das Kriterium, das diese Tabelle funktionieren lässt, ist nicht technisch, sondern geschäftlich: Den Schweregrad bestimmt der Schaden pro vergangener Stunde, nicht wie kaputt das System ist. Ein komplett toter Flow, der nur einen internen Bericht bewegt, ist "hässlich, aber es kann warten". Ein Flow, der zu 90 % läuft, aber Angebote mit dem falschen Preis verschickt, ist schwer. Schreib die Tabelle mit dieser Logik und mit deinen Prozessen beim Namen —"Webbestellungen", "Rechnungsstellung", "Kundenbenachrichtigungen"— statt mit abstrakten Kategorien. Ein Schweregrad, den man um 23:40 erst interpretieren muss, nützt gar nichts.
Die Bereitschaft, die in ein kleines Unternehmen passt (kopier nicht das Modell eines Konzerns)
Hier werden die meisten Artikel nutzlos: Sie beschreiben Wochenrotationen, dreistufige Eskalation und Pager. Du hast zwei Leute, die an den Flows arbeiten können, und eine davon bist du. Realistische Bereitschaft in dieser Größenordnung hat vier Teile, und keiner davon kostet Geld.
- Ein Name pro Woche, aufgeschrieben. Nicht "das Team", nicht "wer es zuerst sieht". Eine konkrete Person pro Woche, in einem gemeinsamen Kalender, mit den Wochen bereits bis zum Quartalsende verteilt. Der Wert liegt nicht in der Rotation: Er liegt darin, dass um 23:40 niemand mehr entscheiden muss, wen er stört.
- Ein Kanal, der wirklich unterbricht. Eine Mail weckt niemanden, und ein stummgeschalteter Slack-Kanal auch nicht. Die Meldung bei Schweregrad schwer muss über etwas kommen, das Krach macht: ein Anruf, eine SMS, eine als Ausnahme vom Nicht-stören-Modus konfigurierte Benachrichtigung. Alles andere darf den üblichen Weg nehmen.
- Eine Vertretung, und nur eine. Wenn die Bereitschaft nicht innerhalb einer Frist antwortet, die du festlegst —fünfzehn Minuten sind vernünftig—, wird die Vertretung verständigt. Keine vierstufige Kette: In einem Unternehmen mit zwanzig Leuten ist die dritte Stufe immer dieselbe Person.
- Eine ausdrückliche Ausgleichsregel. Wenn jemand an einem Samstag einen Vorfall übernimmt, wird das bezahlt oder abgefeiert. Eine Bereitschaft, die auf gutem Willen steht, hält exakt bis zum zweiten Mal, dass jemand ein Abendessen verpasst.
Und eine ehrliche Entscheidung, bevor du irgendetwas aufsetzt: Brauchst du wirklich eine Nachtbereitschaft? Wenn deine kritischen Prozesse nur während der Geschäftszeiten Konsequenzen haben —Rechnungsstellung, B2B-Bestellungen, interne Meldungen—, ist die richtige Antwort, keine Nachtbereitschaft zu haben und das laut auszusprechen, statt eine informelle Bereitschaft zu haben, der nie jemand zugestimmt hat. Was du dagegen immer brauchst: dass der Fehler protokolliert und am frühen Morgen sichtbar ist. In n8n baut man das mit einem einzigen Fehler-Flow, der an alle anderen angehängt ist: Die offizielle Dokumentation beschreibt, wie ein einzelner Error Workflow mit Error Trigger-Node in allen Produktions-Flows wiederverwendet wird, ohne die Meldung einzeln zu bauen. Make und Zapier haben eigene Entsprechungen.
Das einseitige Runbook: das Einzige, was eine andere Person reagieren lässt
Bereitschaft ohne Runbook ist ein Telefon, das klingelt, um jemandem mitzuteilen, dass er nichts tun kann. Ein Runbook ist das Blatt von einer Seite —einer, nicht zwölf—, das aus "der Bestellfluss ist tot" eine Abfolge macht, die auch ausführen kann, wer ihn nicht gebaut hat. PagerDuty sagt es ohne Schnörkel: Vorfälle mit hohem Schweregrad sollen auf ein Runbook zeigen, damit die reagierende Person nicht improvisiert.
Eines pro kritischem Flow. Nicht pro Flow: pro kritischem Flow, und das sind in einem normalen Unternehmen drei bis fünf. Jedes Blatt beantwortet sechs Fragen und sonst nichts:
- Was dieser Flow tut und was passiert, wenn er steht. Zwei Zeilen Geschäft, nicht Technik. "Legt den Lieferschein im ERP an, wenn eine Webbestellung reinkommt. Steht er, kommen die Bestellungen rein, werden aber nicht kommissioniert."
- Wie man in dreißig Sekunden prüft, ob er lebt. Der exakte Link zur Ausführungshistorie, und was man dort ansieht.
- Die drei Ursachen, die es schon einmal gab, und ihre Behebung. Abgelaufene Zugangsdaten, aufgebrauchtes Kontingent beim Anbieter, ein Feld, das leer ankommt. Mit dem konkreten Klick, nicht mit der Theorie.
- Wie man ihn komplett anhält. Der Knopf, der Schalter, die Stelle. Anhalten ist eine legitime Aktion und oft die richtige: Ein stehender Flow richtet weniger Schaden an als ein Flow, der falsch entscheidet.
- Was in der Zwischenzeit passiert (der manuelle Plan, nächster Abschnitt).
- An wen eskaliert wird, wenn nichts davon hilft, mit Namen und Telefonnummer.
Das Runbook ist ein naher Verwandter der Flow-Dokumentation, aber es ist nicht dasselbe, und man sollte beides nicht vermischen: deine Automatisierungen zu dokumentieren dient dazu, dass jemand sie in Ruhe pflegen und ändern kann; das Runbook dient den fünfzehn Minuten nach dem Ausfall. Eines liest man im Sitzen, das andere im Stehen. Wenn du versuchst, dass dasselbe Dokument beides tut, hast du am Ende zwölf Seiten, die um 23:40 niemand öffnet.
Der manuelle Plan: von Hand weiterarbeiten ist kein Scheitern, es ist der Plan
Das ist das Teil, das die meisten überspringen, und das, das am meisten Geld rettet. Während die Automatisierung liegt, läuft das Geschäft weiter. Bestellungen kommen weiter rein, Kunden schreiben weiter, und Rechnungen werden weiter fällig. Die Frage lautet nicht "wann reparieren wir es?", sondern "wie arbeiten wir weiter, bis es repariert ist?".
Ein kultureller Reflex steht hier im Weg: Zum manuellen Prozess zurückzukehren fühlt sich wie eine Niederlage an, wie das Eingeständnis, dass die Automatisierung nichts taugte. Es ist genau umgekehrt. Ein ernsthaftes System hat einen Notbetrieb; eines ohne ist nicht automatischer, sondern zerbrechlicher. Schreib für jeden kritischen Flow die Handversion des Prozesses auf: wer sie ausführt, wo notiert wird, was dabei getan wurde, und welches Höchstvolumen sie aushält, bevor man anfangen muss, Nein zu sagen.
Dieser letzte Teil ist der, den fast niemand aufschreibt, und der über den Rest entscheidet: Der manuelle Plan hat eine Obergrenze. Zwölf Bestellungen am Tag kann man von Hand eintippen, vierhundert nicht. Deine Zahl vorher zu kennen verändert das Gespräch während des Ausfalls, weil aus "wir halten durch" ein "wir halten bis vierzehn Uhr durch, ab dann nehmen wir keine Webbestellungen mehr an" wird. Und das Parallelprotokoll dessen, was von Hand gemacht wurde, ist keine Bürokratie: Es ist das, was den späteren Abgleich ohne Dubletten möglich macht — eine Arbeit mit eigener Mechanik, ausgeführt in die verlorenen Daten einer ausgefallenen Automatisierung zurückholen.
Das Postmortem in drei Zeilen: warum derselbe Ausfall ohne es im März wiederkommt
Der Vorfall ist vorbei, alle atmen durch, und niemand schreibt etwas auf. Drei Monate später passiert dasselbe noch einmal, und die Person, die es beim ersten Mal repariert hat, weiß nicht mehr wie. Das ist der echte Preis dafür, das Postmortem zu überspringen, und er wird nicht im Moment fällig: Er wird in der Wiederholung bezahlt.
Du brauchst nicht das zehnseitige Dokument eines Konzerns mit Tausenden Beschäftigten. Das SRE-Buch von Google —wo ein guter Teil dieser Praxis entstanden ist— besteht auf zwei Dingen, die auch nach unten skalieren: dass es ohne Schuldige abläuft, konzentriert darauf, warum das System den Fehler zugelassen hat, und nicht darauf, wer ihn gemacht hat; und dass man mit einem sehr einfachen Verfahren anfangen und es nach und nach nachschärfen kann. In deiner Größenordnung sind das drei Zeilen, am selben Tag geschrieben, an dem Ort, an dem das Runbook wohnt:
- Was passiert ist und seit wann. Mit der echten Startzeit, nicht der Erkennungszeit. Der Abstand zwischen beiden ist fast immer der nützlichste Fund der ganzen Übung.
- Was es repariert hat. Die konkrete Aktion. Die geht direkt in den Abschnitt bekannter Ursachen im Runbook, und sie ist der Grund, warum es beim zweiten Mal zehn Minuten dauert statt drei Stunden.
- Was wir geändert haben, damit es nicht wiederkommt. Eine einzige Sache, mit Verantwortlichem und Datum. Wenn es keine gibt, schreib auch das hin: "Wir akzeptieren, dass es sich wiederholen kann" ist eine gültige und bewusste Entscheidung; "mal sehen" ist es nicht.
Wenn sich diese drei Zeilen ein Jahr lang stapeln, hast du keine Anekdoten mehr, sondern eine Landkarte: welcher Flow am häufigsten ausfällt, welcher Anbieter dich die meisten Stunden gekostet hat, welche Reparatur du sechsmal angewandt hast, ohne die Ursache zu beheben. Diese Landkarte macht aus reaktivem Flickwerk echte Wartung, die vorausläuft.
Was du diese Woche aufsetzt
Alles Bisherige passt in einen Nachmittag, wenn du es in dieser Reihenfolge machst und nicht versuchst, es perfekt zu machen: die Tabelle mit drei Schweregraden und deinen Prozessen beim Namen; der Kalender mit einem Namen pro Woche und einem Kanal, der Krach macht; das einseitige Runbook deiner zwei kritischsten Flows; die Handversion dieser zwei Prozesse mit aufgeschriebener Obergrenze; und die Gewohnheit der drei Zeilen nach jedem Ausfall. Nichts davon verlangt ein neues Werkzeug. Es verlangt, dass jemand es in Ruhe entscheidet und dort aufschreibt, wo man es findet.
Die ehrliche Grenze: Das hier ist für alle gedacht, die ein paar Flows haben und ruhig schlafen wollen, ohne eine Abteilung aufzubauen. Wenn darunter Dutzende Prozesse liegen, mehrere Teams und Agenten, die allein entscheiden, ist die Reaktion auf Vorfälle kein Blatt Papier mehr, sondern eine Funktion mit Schichten, Service-Level-Vereinbarungen und eigener Eskalationsmechanik: Das ist Incident Management für KI-Agenten. Und wenn du willst, dass Schweregrade, Bereitschaft, Runbooks und manueller Plan auf deinen aktuellen Flows aufgesetzt und von jemandem betrieben werden, der nicht du ist, dann ist das Automatisierung von Operations: Tag zwei, erledigt, statt einer Absichtserklärung auf einer Serviette.