Klicks zu dokumentieren bringt nichts: die speichert das Werkzeug schon
Wer nachschlägt, wie man Automatisierungen dokumentiert, endet fast immer beim Gleichen: Screenshots aus dem Editor, eine Schritt-für-Schritt-Liste, welches Modul auf welches folgt, und eine Beschreibung jedes Knotens. Ein ganzer Nachmittag Arbeit. Und es ist verlorene Arbeit, weil du von Hand abschreibst, was das Werkzeug längst allein weiß.
Make, n8n, Zapier oder Power Automate zeigen dir den Graphen des Flows in zwei Klicks: was ihn auslöst, was danach kommt, welches Feld auf welches gemappt wird. Das ist lebendig und immer aktuell. Dein Screenshot nicht: Er verfällt, sobald der Hersteller ein Menü verschiebt oder die Farbe eines Buttons ändert, und dokumentiert von da an ein Interface, das es nicht mehr gibt.
Der Nebeneffekt ist schlimmer als die Veralterung selbst. Dokumentation, die alt aussieht, wird nicht mehr gelesen, und sobald sie nicht mehr gelesen wird, unterstellen alle, dass der Rest auch lügt. Ein Handbuch, das niemand öffnet, ist exakt so nützlich wie gar kein Handbuch — nur dass du es zusätzlich pflegen musst.
Der Graph sagt dir, was der Flow tut. Er sagt dir nie, warum. Und das Warum steht nirgends außer im Kopf desjenigen, der ihn gebaut hat.
Der Bus-Faktor: Wenn nur ein Kopf das Warum kennt, ist das dein echtes Risiko
Der Bus-Faktor eines Systems ist die Anzahl der Leute, die gehen können, bevor niemand mehr da ist, der es versteht. In der Unternehmensautomatisierung ist die Zahl fast immer eins. Eine Person hat den Flow gebaut, diese Person weiß, warum die Schwelle bei 48 Stunden liegt und nicht bei 72, und diese Person ruft man an, wenn etwas Seltsames passiert.
Es braucht keinen Bus. Ein Urlaub, ein Teamwechsel, ein längerer Ausfall oder ein besseres Angebot reichen. Und das Unangenehme ist: Der Flow geht nicht kaputt —das wäre leicht zu erkennen—, er läuft weiter pünktlich jeden Tag. Kaputt geht deine Fähigkeit, ihn zu ändern.
Man sieht es lange vor der Katastrophe. Die Symptome eines Bus-Faktors von eins sind immer dieselben fünf:
- Niemand fasst den Flow an. Änderungen werden außen drangeklebt, in einem neuen Flow, weil das Original zu ändern Angst macht.
- Jede fachliche Änderung eröffnet eine archäologische Debatte. «Warum ist das eigentlich so?». Niemand weiß es, also bleibt es, wie es ist.
- Ein Duplikat taucht auf. Jemand baut einen zweiten Flow, der fast dasselbe tut, weil bei null anzufangen billiger war, als den vorhandenen zu verstehen.
- Eine Entscheidung lässt sich nicht erklären. Ein Kunde oder ein Prüfer fragt, warum das System getan hat, was es getan hat, und die ehrliche Antwort ist: Wir wissen es nicht.
- Der Flow friert ein. Wenn die Person geht, bleibt er an, und niemand traut sich, ihn zu ändern oder abzuschalten.
Achte darauf: Kein einziges dieser fünf Symptome heilt ein Screenshot aus dem Editor.
Das Einzige, was aufgeschrieben gehört: die Geschäftsregel
Eine Geschäftsregel ist die menschliche Entscheidung, die der Flow in deinem Namen trifft, während niemand hinschaut. Sie lautet nicht «wenn Status gleich offen, sende E-Mail». Sie lautet: «Ein Kunde, der seit 48 Stunden nicht geantwortet hat, bekommt genau eine Erinnerung, weil der Standardvertrag eine Antwort binnen zwei Werktagen verspricht und wir ihn nicht brechen wollen; außer es ist ein Großkunde, dann wird der Kundenbetreuer alarmiert statt des Systems».
Alles andere —das Modul, die Reihenfolge, das Feld-Mapping— ist Umsetzung. Es ändert sich an dem Tag, an dem du das Werkzeug wechselst, und das ist egal. Die Regel überlebt das Werkzeug: Wenn du morgen von Zapier auf n8n migrierst, ist die Regel das Einzige, was du mitnehmen musst — und genau das Einzige, was nirgends aufgeschrieben steht.
Warum diese Bedingung und keine andere
Jede Zahl in einem Flow kommt irgendwoher: aus einer Servicezusage, einem Vertriebsversprechen, einer gesetzlichen Anforderung oder —am häufigsten— aus einem Meeting vor zwei Jahren. Schreib auf, woher. «48 Stunden, weil der Standardvertrag diese Frist zusagt» ist eine Bedingung, die man an dem Tag prüfen kann, an dem sich der Vertrag ändert. Ein nacktes «48 Stunden» ist eine unantastbare Zahl, die sich nie jemand zu bewegen traut.
Welche Ausnahme sie abdeckt
Die seltsamen Zweige eines Flows sind fast nie Laune: Es sind Narben. Der Filter, der Bestellungen unterhalb eines bestimmten Betrags verwirft, ist da, weil eines Tages eine Testserie durchlief und die Abrechnung verschmutzte. Die Narbe aufzuschreiben verhindert die zwei Dinge, die passieren, wenn sie nicht aufgeschrieben ist: dass jemand den Filter zum «Aufräumen» entfernt und der Vorfall zurückkommt, oder dass sich niemand herantraut, obwohl der ursprüngliche Grund vor Jahren verschwunden ist.
Wen sie alarmiert und was passiert, wenn niemand antwortet
Was in Produktion knallt, ist meistens nicht die Logik: Es ist das offene Ende. Ein Flow, der an einen Menschen eskaliert, muss sagen an wen, über welchen Kanal, mit welcher Frist — und was er tut, wenn diese Person nicht reagiert. Wenn die Antwort «er wartet unbegrenzt» lautet, ist auch das eine Entscheidung und gehört aufgeschrieben, denn an dem Tag, an dem eine Bestellung eine Woche hängt, fragt jemand, ob das ein Fehler ist oder das Design.
Direkt an der Regel kleben drei Angaben, die kein Fachwissen sind, aber genauso leicht verloren gehen: der Owner —eine Person mit Vor- und Nachnamen, keine Abteilung—, die Zugangsdaten, die er nutzt —welches Konto, von wem, mit welchen Rechten— und die Systeme, die er anfasst, getrennt nach Lesen und Schreiben. Das Schreiben ist das, was dir an einem Dienstagnachmittag das CRM durcheinanderbringen kann.
Hier streift dieser Guide die Governance und Kontrolle der Automatisierung, ohne dasselbe zu sein. Governance setzt Rechte, Audit und Handbremse: Das ist Kontrolle. Hier geht es um Wissen. Du kannst perfekte Kontrolle über einen Flow haben, den niemand versteht — und dann ist das Einzige, was du präzise tun kannst, ihn abzuschalten.
Der Mindest-Steckbrief: eine Seite pro Flow, acht Felder
Wenn der Steckbrief nicht auf eine Seite passt, wird er nicht gepflegt. Das ist das gesamte Designkriterium. Acht Felder, Antworten von zwei Zeilen, fertig:
- Was er produziert. Die konkrete Ausgabe, nicht die Kategorie. «Legt pro Bestellung eine Zeile in der Logistiktabelle an», nicht «verwaltet Bestellungen».
- Owner. Eine Person. Wenn der Name dort nicht mehr im Haus ist, ist der Steckbrief abgelaufen — und das sieht man auf einen Blick.
- Geschäftsregel. Das Warum jeder Bedingung, mit Herkunft. Das ist das lange Feld und das einzige, das die Existenz des Steckbriefs rechtfertigt.
- Ausnahmen. Welchen Sonderfall jeder Zweig abdeckt und welcher Vorfall ihn dorthin gebracht hat.
- Wen er alarmiert. Person oder Queue, Kanal, Frist, und was passiert, wenn niemand antwortet.
- Zugangsdaten. Welches Konto er nutzt, wem es gehört und mit welchen Rechten. Keine Geheimnisse im Steckbrief, versteht sich: nur der Kontoname.
- Systeme, die er anfasst. Was er liest und was er schreibt, in zwei getrennten Listen.
- Was er NICHT tut. Die ausdrückliche Grenze des Flows.
Das achte Feld ist das, welches niemand ausfüllt und das die meisten Diskussionen spart. «Fasst bereits gestellte Rechnungen nicht an», «schreibt nicht ins ERP», «antwortet nicht außerhalb der Geschäftszeiten». Ohne dieses Feld beginnt jeder Vorfall mit zwanzig Minuten Ausschlussverfahren, ob es dieser Flow war — und nach einem Jahr dichtet ihm jeder Kräfte an, die er nie hatte.
Wo der Steckbrief leben muss, damit er nicht veraltet
Jetzt der unangenehme Teil, ohne Umschweife: Wenn der Steckbrief in einem Confluence, einem Notion oder einem separaten Drive-Ordner lebt, wird er veralten. Nicht wegen des Werkzeugs, wegen der Distanz. Wer den Flow ändert, sitzt im Editor, hat es eilig und repariert gerade etwas; wenn den Steckbrief zu aktualisieren heißt, einen weiteren Tab zu öffnen, die Seite zu suchen und zu bearbeiten, wird er es nicht tun. Einmal ist nichts. Bei der zehnten Änderung lügt der Steckbrief.
Der Steckbrief muss dort leben, wo der Flow lebt. Drei Orte, die wirklich funktionieren, von wenig zu mehr Aufwand: das Beschreibungsfeld oder die Notizen im Szenario selbst —Make, n8n, Power Automate und fast alle haben eins—, dort ist die Reibung am geringsten, weil du schon drin bist; eine README neben dem exportierten JSON, wenn du die Flows in einem Repository versionierst, was dir die Änderungshistorie gratis dazugibt; und eine angepinnte Notiz in dem Kanal, in dem der Flow postet, wenn seine Ausgabe eine Benachrichtigung ist.
Das Wiki verschwindet nicht: Es wechselt die Rolle. Es hört auf, der Ort zu sein, an dem die Dokumentation lebt, und wird zum Index —welche Flows es gibt, wer jeden besitzt und wo sein Steckbrief liegt—. Das hält, weil es eine kurze Liste ist, die sich kaum ändert. Was nicht hält, ist das Detail weit weg von dem Ort, an dem man es anfasst.
Den Steckbrief zu aktualisieren gehört zur Änderung, es ist keine Extra-Aufgabe
Jede Dokumentation, die stirbt, stirbt gleich: Jemand schreibt sie in einem einmaligen Kraftakt, und ab da ist ihre Pflege «eine Aufgabe», die mit der echten Arbeit konkurriert. Sie konkurriert und verliert, jedes Mal, weil sie nie dringend ist und niemand auf sie wartet.
Der einzige Weg, das zu verhindern, ist, sie aus der Aufgabenliste zu nehmen und in die Definition of Done zu stecken. Einen Flow zu ändern ist nicht fertig, wenn der Flow läuft: Es ist fertig, wenn der Flow läuft und sein Steckbrief sagt, was er jetzt tut. Zwei Minuten, wenn der Steckbrief einen Klick entfernt ist — zwei Minuten, die es nur gibt, wenn sie niemand als optional behandelt. Der Rest —Quartalserinnerungen, Dokumentationskampagnen, interne Audits— ist Theater mit Kalender.
Damit schließt sich der Kreis zum Rest des Clusters. Ein Flow mit Steckbrief und Owner ist ein Flow, den man am Leben halten kann, ohne zu raten, und ein Flow, der nicht als eine dieser Zombie-Automatisierungen endet, die niemand abschaltet, weil niemand weiß, was dabei kaputtgeht. Dokumentieren wartet nichts und entsorgt nichts: Es macht aus Warten und Entsorgen Entscheidungen statt Wetten. Wenn du das alles von null aufbaust, liegt die komplette Landkarte im Guide zum Automatisieren mit KI.