Zombie-Automatisierungen: die Flows, die niemand mehr nutzt und die niemand abzuschalten wagt

Eine Zombie-Automatisierung ist nicht kaputt: Sie läuft und nützt niemandem

Wenn jemand fragt, was man mit den Automatisierungen macht, die niemand mehr nutzt, denkt er fast immer an kaputte Flows. Darum geht es nicht. Ein kaputter Flow meldet sich: Er stürzt ab, schickt eine rote Mail, jemand beschwert sich, und am selben Vormittag ist es behoben. Ein Zombie funktioniert. Er läuft pünktlich, tut genau das, worum man ihn vor zwei Jahren gebeten hat, und liefert sein Ergebnis an einen Prozess, den es nicht mehr gibt.

Der Report, der jeden Montag für ein Gremium erzeugt wird, das längst aufgelöst wurde. Die Synchronisation, die Bestellungen in eine Tabelle kippt, die seit März niemand mehr öffnet. Die Meldung, die in einem archivierten Slack-Kanal landet. Die Wochenmail an einen Verteiler, in dem drei Leute eine Regel «als gelesen markieren» eingerichtet haben. Alle grün, alle korrekt, alle nutzlos.

Sie überleben, weil sich niemand über sie beschwert. Ein kaputter Flow hat faktisch einen Owner —den, der unter dem Fehler leidet—; ein Zombie hat niemanden: Wer ihn bestellt hat, ist längst im anderen Team, wer ihn gebaut hat, ist weg, und wer ihn im Dashboard sieht, weiß nicht, wer von ihm abhängt. Im Zweifel fasst niemand etwas an. Und so laufen sie seit drei Jahren.

Das Problem ist: Sie sind nicht gratis. Sie verbrauchen Operationen oder Läufe deines Tarifs, und das ist echtes Geld, sobald dein Werkzeug nach Volumen abrechnet. Sie halten Zugangsdaten am Leben —Tokens, Service-Nutzer, OAuth-Integrationen—, viele davon mit Schreibrecht auf dein CRM oder dein ERP. Und sie vernebeln die Diagnose: Bei jedem Vorfall verliert jemand eine halbe Stunde damit, Flows auszuschließen, die egal sind, bevor er bei dem ankommt, der zählt. Dieser Guide ist der Zoom auf den Teil der Wartung der KI-Automatisierungen, in dem es ums Abräumen des Toten geht, nicht ums Pflegen des Lebendigen.

Das echte Inventar, nicht das, von dem du glaubst, du hättest es

Die erste Hürde ist nicht, zu entscheiden, was abgeschaltet wird: Es ist zu wissen, was überhaupt läuft. Fast kein Unternehmen weiß das, weil die Flows nicht an einem einzigen Ort leben. Der Hauptreiter deines Automatisierungswerkzeugs ist die Spitze des Eisbergs.

Die sechs üblichen Verstecke, sortiert danach, wie viele auftauchen, wenn man den Teppich anhebt:

• Das Hauptwerkzeug (Make, n8n, Zapier, Power Automate), inklusive der Ordner anderer Nutzer und der «privaten» Szenarien dessen, der sie gebaut hat.
• Die nativen Flows in jedem SaaS: Workflows in HubSpot, Regeln in Salesforce, Automatisierungen in Notion oder Airtable. Niemand zählt sie als Automatisierungen, und es sind Legionen.
• Die geplanten Skripte: Apps Script in Google Workspace, Makros mit Trigger, ein Cronjob auf einem Server, den jemand administriert hat, der nicht mehr da ist.
• Die geplanten Cloud-Tasks: Cloud Scheduler, EventBridge, Jobs in einem Container. Hier wohnt das Teure.
• Die eingehenden Webhooks, die auf eigene Endpunkte zeigen: in keinem Automatisierungs-Dashboard zu sehen, nur in den Server-Logs.
• Die Agenten und Prompts in Produktion mit eigenem Trigger — in vielen Unternehmen längst die neueste und am schlechtesten inventarisierte Schicht.

Jede Zeile des Inventars braucht sieben Spalten und keine mehr: Name, was er produziert (die konkrete Ausgabe, nicht «verwaltet Bestellungen»), wer sie konsumiert, letzter Lauf, Frequenz, verwendete Zugangsdaten und die Rechte dieser Zugangsdaten. Die Spalte, die die ganze Arbeit macht, ist die dritte. Wenn du in «wer konsumiert das» keinen Eigennamen eintragen kannst —eine Person oder ein identifizierbares System—, hast du deinen Kandidaten schon, ohne noch irgendetwas untersuchen zu müssen.

Laufen ist nicht Nutzen: Woran du erkennst, ob ein Flow wirklich gebraucht wird

Hier irren sich alle: Man sortiert die Liste nach «letzter Lauf» und winkt alles durch, was gestern lief. Aber ein Zombie läuft pünktlich jeden Tag —das ist buchstäblich seine Definition—. Der Lauf misst, dass der Flow lebt, nicht dass sein Ergebnis irgendwen interessiert. Das sind zwei verschiedene Fragen, und nur eine davon willst du gerade beantworten.

Es gibt drei Signale, die tatsächlich Konsum messen, und welches du nimmst, hängt davon ab, was der Flow am Ende tut:

Wenn er in ein System schreibt

Schau auf den Datensatz, den er erzeugt, nicht auf den Flow. Öffnet jemand dieses Dokument? Wird diese Zeile nach dem Anlegen noch bearbeitet? Taucht das Feld, das er füllt, in irgendeinem Report oder in einer Ansicht auf, die jemand aufruft? Office-Werkzeuge und CRMs speichern das Datum des letzten Zugriffs: Das ist die ehrlichste Angabe, die du finden wirst, und fast niemand schaut sie an.

Wenn er benachrichtigt

Antwortet jemand, reagiert jemand, klickt jemand? Ein archivierter Kanal, ein Mailverteiler mit automatischer Archivierungsregel oder eine Meldung, die seit achthundert Nachrichten keine einzige Antwort bekommen hat, sind dasselbe: Niemand liest das. Wenn dir deine Messaging-Plattform Lesebestätigungen oder Reaktionen zeigt, hast du die Antwort in einer Minute.

Wenn er einen anderen Flow füttert

Prüf, ob dieser andere Flow ebenfalls auf deiner Zweifelsliste steht. Zombies kommen in Ketten: Jemand hat vor einem Jahr den Endverbraucher abgeschaltet und die ganze Rohrleitung, die ihn versorgt hat, am Leben gelassen. Dieser Fall spart am meisten, wenn er auftaucht, weil auf einen Schlag ein halbes Dutzend fällt.

Wenn kein Signal eindeutig ist —und das passiert in einem Drittel der Fälle—, bleibt eine billige, ehrliche und erstaunlich selten genutzte Methode: die Stilleprobe. Du schaltest den Flow ab, hinterlässt an seiner Stelle einen sichtbaren Hinweis (eine automatische Nachricht «das ist pausiert, schreib hier, wenn du es brauchst», eine Notiz in der Tabelle, eine angepinnte Zeile im Kanal) und wartest einen kompletten Geschäftszyklus ab. Ein Monat reicht meistens; ein Quartal, wenn der Prozess quartalsweise läuft. Beschwert sich niemand, hast du deine Antwort.

Die Regel, die aus der Stilleprobe eine legitime Methode macht und kein Roulette: Abgeschaltet wird mit Hinweis und mit Frist, nie klammheimlich. Heimlich abzuschalten, um zu sehen, was passiert, ist der schnellste Weg dahin, dass die nächste Aufräumaktion niemand mehr genehmigt.

Abschalten ist nicht Löschen: die drei Züge

Der wahre Grund, warum niemand irgendetwas abschaltet: «abschalten» klingt nach unumkehrbar. Und es sieht auch so aus, weil in fast jedem Kopf abschalten, Rechte entziehen und löschen dieselbe Handlung sind. Sind sie nicht. Es sind drei, mit unterschiedlichen Risiken und unterschiedlichen Fristen, und sie zu trennen ist das, was die Entscheidung freigibt:

1. Aufhören zu laufen. Du deaktivierst den Trigger. Mit einem Klick umkehrbar, Kosten null, und genau das machst du an Tag eins. Es löscht nichts: Der Flow ist weiter da, samt intakter Historie.
2. Den Zugang widerrufen. Du entfernst die Credential, den Token oder den Service-Nutzer, den er benutzt hat —oder stufst zumindest die Schreibrechte auf Nur-Lesen herunter—. Das macht fast niemand, und genau dort sitzt das echte Risiko: Ein abgeschalteter Flow mit lebendem Token ist weiterhin ein Schlüssel mit Schreibrecht auf dein CRM, der irgendwo herumliegt, ohne Owner und ohne Aufsicht.
3. Entscheiden, was aufbewahrt wird. Der Flow wird exportiert (JSON ins Repository, mit Datum und Grund der Abschaltung). Die Daten, die er erzeugt hat, bleiben, wo sie sind: nicht anfassen. Datensätze und Logs nach dem, was deine Aufbewahrungsrichtlinie sagt. Erst danach fliegt er aus dem Dashboard — der einzige Teil, der wirklich unumkehrbar ist.

Der Zeitplan zählt genauso viel wie die Reihenfolge. Schritt eins und zwei am selben Tag —es ergibt keinen Sinn, einen Flow abzuschalten und ihm die Schlüssel zu lassen—. Schritt drei nach dreißig oder neunzig Tagen Stille. Dazwischen liegt der Flow in Quarantäne: deaktiviert, ohne Zugangsdaten, in Minuten wiederherstellbar, falls jemand auftaucht und ihn einfordert. Und einige werden auftauchen: Das ist kein Fehler der Methode, das ist die Methode bei der Arbeit.

Das geschriebene Kriterium: was ohne Diskussion abgeschaltet wird

Ein geschriebenes Kriterium macht aus einer politischen Entscheidung —«und wenn das doch jemand braucht?»— eine operative. Es muss nicht lang sein. Vier Regeln und wer die Ausnahmen abzeichnet passen auf eine halbe Seite:

• Kein Konsument mit Namen → Quarantäne. Wenn niemand eine Person oder ein identifizierbares System in die Spalte «wer konsumiert das» schreiben kann, wird der Flow abgeschaltet. «Das nutzt Operations» ist kein Name.
• Kein konsumiertes Ergebnis in 90 Tagen → Quarantäne. Achtung: konsumiertes Ergebnis, nicht Lauf. Ein Flow, der gestern lief und dessen Ergebnis seit drei Monaten niemand geöffnet hat, erfüllt diese Regel.
• Funktionales Duplikat eines anderen lebenden Flows → abgeschaltet wird der schlechter gewartete, nicht der ältere. Alter ist kein Qualitätskriterium; die Zahl der manuellen Eingriffe im letzten Quartal schon.
• Credential einer Person, die nicht mehr im Unternehmen ist → sofort abschalten, ohne Frist. Das ist kein Aufräumen, das ist Sicherheit, und es lässt keine Stilleprobe zu.

Und eine Regel, die über den anderen vier steht: Jeder darf einen Flow aus der Quarantäne zurückfordern, aber zurückfordern heißt akzeptieren, sein Owner zu sein — mit Vor- und Nachnamen. Nicht «die Abteilung». Eine Person. Ohne das ist der gerettete Flow in sechs Monaten wieder ein Zombie, und du hast umsonst aufgeräumt. Es ist dieselbe Logik des namentlichen Owners, die die gesamte Governance und Kontrolle der Automatisierung trägt: ohne Namen gibt es keine Kontrolle, nur ein Dashboard.

Takt: eine Stunde pro Quartal, kein Aufräumprojekt

Die Versuchung ist, «das große Aufräumprojekt für Automatisierungen» aufzusetzen: ein Monat Arbeit, eine riesige Tabelle, ein Abschlussbericht. Man macht es einmal, es läuft gut, und zwei Jahre später stehst du genau da, wo du vorher warst. Was hält, ist das Gegenteil: eine kurze, regelmäßige Durchsicht, die in eine Stunde passt.

Was in diese Quartalsstunde passt: die Flows durchgehen, deren Ergebnis niemand konsumiert hat, die in Quarantäne schieben, die das Kriterium erfüllen, die wieder herausholen, die jemand zurückgefordert hat (mit bereits eingetragenem Owner), und die endgültig löschen, die ein Quartal in Quarantäne liegen, ohne dass sie jemand vermisst hätte. Das erste Mal tut weh —es ist normal, zwischen einem Drittel und der Hälfte des Inventars im Zweifelsstatus zu finden—; ab dem zweiten Mal sind es dreißig Minuten.

Das Teil, das den Rückfall verhindert, kommt vorher, nicht hinterher: jeder neue Flow wird mit Owner und mit Review-Datum geboren. Zwei Felder in der Beschreibung, dreißig Sekunden beim Anlegen. Das ist der Unterschied zwischen aufräumen und nicht wieder dreckig machen, und es greift in dieselbe Gewohnheit wie die Ausfälle erkennen, die nicht warnen: billig ist nicht das Reparieren, billig ist das rechtzeitige Mitbekommen. Wenn du das alles von null aufbaust, liegt die komplette Landkarte im Guide zum Automatisieren mit KI.