Die meisten Automationen laufen monatelang störungsfrei. Dabei kann trotzdem gelten: Nur eine Person weiß, was sie tut.

Der Bus-Faktor (englisch „bus factor“) benennt, wie viele Personen ausfallen dürfen, bevor Wissen über ein System verloren ist. Ein Bus-Faktor von eins ist ein Betriebsrisiko, denn dann ist das System beim Ausfall dieser Person faktisch undokumentiert – selbst wenn es weiterläuft.

🔗 Eine Automation ohne Besitzer bleibt bei Fehlern liegen. Jede Automation braucht eine benannte verantwortliche Person oder Rolle, sonst bleibt sie auch bei Personalwechsel unverstanden. Die Besitzerin erhält die Fehlermeldungen und hält das Wissen aktuell.

🔁 Erinnerung ist keine Dokumentation. Ein häufiger Einsteigerirrtum ist, die eigene Erinnerung an den Workflow als Dokumentation zu betrachten. Nach Monaten fehlt genau das, was der Störfall verlangt, weil die Fragen des Ausfalls nie aufgeschrieben wurden.

🧭 Ein Runbook je Workflow beantwortet die Fragen des Ausfalls. Was tut der Workflow, welche Systeme berührt er, wie erkennt man Fehler, welche Schritte folgen, wer ist zuständig. Beispiel: Ein Workflow versendet jede Nacht Rechnungen per Zeitplan; die Besitzerin im Buchhaltungsteam hält das Runbook aktuell. Einfache Prüfung: Für jede Automation die Fragen „Was macht sie?“, „Welche Systeme berührt sie?“ und „Wer darf sie abschalten?“ an mehrere Personen stellen.

Woran man es erkennt: Kann nur eine Person die Fragen beantworten, ist der Bus-Faktor eins.

Bus-Faktor heißt nicht „wie gut läuft es“, sondern „wer versteht es, wenn es nicht mehr läuft“. Die störungsfreie Nacht sagt nichts über die nächste Personalentscheidung.

📌 Bus-Faktor · Runbook · Verantwortlichkeit

📚 Automatisierung von Grund auf · Tag 6 von 30
#Automatisierung #workflow #Prozessoptimierung #effizienz

Bei jedem Ausfall stellen alle dieselben vier Fragen – immer in derselben Reihenfolge. Wer sie vorher aufschreibt, ist im Störfall sofort handlungsfähig.

Einsteiger begegnen dem Runbook meist erst, wenn eine Automation nachts ausfällt und niemand weiß, wer sie neu starten darf. Ohne dieses Wissen bleibt der Fehler liegen, bis jemand das System mühsam versteht.

Ein Runbook ist eine kurze, schriftliche Anleitung für den Störfall, die neben der Automation liegt. Es sagt im Ernstfall Schritt für Schritt, was zu prüfen und zu tun ist. Es ist keine Bauanleitung, sondern eine Notfallkarte.

Die Fragen bei einem Ausfall entstehen in fester Reihenfolge: Was macht diese Automation eigentlich? Läuft sie gerade noch? Wen muss man informieren? Wer darf sie neu starten oder abschalten? Das Google SRE Book empfiehlt deshalb Playbooks, die zu jedem Alarm die ersten Handgriffe nennen – so kann auch eine Vertretung handeln. Das Runbook braucht nur Zweck, beteiligte Systeme, Fehlerzeichen, Handgriffe und Zuständigkeit.

Ein Beispiel: Ein Workflow versendet jede Nacht Rechnungen per Zeitplan. Als Besitzerin ist die Sachbearbeiterin im Buchhaltungsteam eingetragen; sie erhält die Fehlermeldungen und hält das Runbook aktuell. Zum Besitz gehören drei schriftliche Angaben: wer Meldungen bearbeitet, wer Änderungen freigibt, wer vertritt.

Das Runbook wird oft mit der Erinnerung an die Automation verwechselt, die als Dokumentation gilt. Nach Monaten fehlt dann genau das, was der Störfall verlangt. Ein Bus-Faktor von eins – wie viele Personen ausfallen dürfen, bevor Wissen verloren geht – ist ein Betriebsrisiko.

Testen Sie das Runbook nicht im Leerlauf, sondern beim nächsten Fehler: Jede unklare Stelle sofort ergänzen.

Ein Runbook ist nicht die Erinnerung an den Bau, sondern die Antwort auf den Ausfall.

📌 Zweck · Fehlerzeichen · Zuständigkeit

📚 Automatisierung von Grund auf · Tag 6 von 30
#Automatisierung #workflow #effizienz

Viele Automationen laufen jahrelang stabil, bis sie plötzlich ausfallen. Dabei ist meist nicht die Technik das Problem, sondern fehlende Zuständigkeit.

Einsteiger nehmen oft an, eine fertige Automation brauche keine Pflege mehr. Das klingt plausibel, weil sie ja von selbst läuft. Wer gebaut hat, fühlt sich zudem schnell zuständig, ohne es je schriftlich festzulegen.

Tatsächlich braucht jede Automation einen Besitzer: eine benannte Person oder Rolle, die Fehler bearbeitet, Änderungen freigibt und die Dokumentation aktuell hält. Der Besitzer muss die Automation nicht selbst gebaut haben, aber er muss ansprechbar sein. Ohne Besitzer bleibt sie bei Fehlern liegen und wird bei Personalwechsel unverstanden.

Der Irrtum entsteht, weil Automation im Alltag unsichtbar arbeitet. Solange nichts auffällt, fragt niemand, wer bei einem Ausfall entscheidet.

Ein Beispiel: Ein Workflow versendet jede Nacht Rechnungen per Zeitplan. Als Besitzer ist die Sachbearbeiterin im Buchhaltungsteam eingetragen. Sie erhält die Fehlermeldungen und hält das Runbook aktuell, also die Anleitung mit den Schritten bei Fehlern.

Woran man es erkennt: Fehlgeschlagene Ausführungen häufen sich unkommentiert, und niemand zieht Änderungen an verbundenen Systemen nach. Fragen zum Zweck beantwortet ohnehin nur eine einzige Person – der Bus-Faktor, also wie viele Personen ausfallen dürfen, bevor Wissen verloren geht, ist dann gefährlich niedrig.

Besitz heißt nicht, dass der Erbauer ewig haftet, sondern dass je Workflow schriftlich steht, wer Fehler bearbeitet, wer Änderungen freigibt und wer vertritt.

📌 Besitzer benennen · Runbook pflegen · Bus-Faktor prüfen

📚 Automatisierung von Grund auf · Tag 5 von 30
#Automatisierung #workflow #Prozessoptimierung

Viele zeichnen einen Prozess als Kastenreihe mit Pfeilen und halten ihn für fertig. Dabei zeigt ein solches Bild nicht, wer arbeitet und wo die Arbeit wartet.

Viele nehmen an, ein Ablaufdiagramm genüge, wenn alle Schritte und ihre Reihenfolge stimmen. Das klingt plausibel, weil Reihenfolge das Sichtbarste an einem Ablauf ist.

Tatsächlich liegt der Wert im Besitzerwechsel. Swimlanes, auf Deutsch Bahnen, gliedern ein Prozessdiagramm in waagerechte Streifen: eine Bahn pro Rolle wie Sachbearbeitung, Freigabe oder Buchhaltung, plus eine Bahn pro beteiligtem System wie E-Mail oder Buchungssystem. Jeder Schritt wird in die Bahn seines Ausführenden gesetzt, von links nach rechts in Ablaufrichtung. Eine Verbindung zwischen zwei Bahnen zeigt genau eine Übergabe – die Stelle, an der die Arbeit den Träger wechselt.

Der Irrtum entsteht, weil ein Diagramm ohne Bahnen ordentlich aussieht und schnell gezeichnet ist. Es verdeckt aber, welche Person zuständig ist und wo Arbeit liegen bleibt.

Ein Beispiel ist die Eingangsrechnung: Sie kommt per E-Mail-Anhang an, wird von einer Person geprüft, per Mail zur Freigabe weitergereicht und danach ins Buchungssystem übertragen. Das sind drei Übergaben, und jede einzelne kann die Rechnung aufhalten, etwa wenn das Postfach nur einmal täglich geleert wird.

Woran man es erkennt: Jede Pfeilspitze zwischen zwei Bahnen markiert einen Besitzerwechsel. Bewährt hat sich, an jeder dieser Stelle drei Fragen zu prüfen: Wer empfängt die Arbeit, in welchem Format erwartet er sie, und wer ist zuständig, wenn etwas unklar ist?

Swimlane heißt nicht hübsches Prozessbild, sondern Landkarte der Übergaben. Wer die Bahnen liest, findet die Wartezeiten, bevor ein Werkzeug sie beheben soll.

📌 Bahnen nach Rolle oder System · Übergaben als Wartepunkte · Pfeilspitzen zwischen Bahnen

📚 Automatisierung von Grund auf · Tag 5 von 30
#Prozessoptimierung #Automatisierung #workflow #Lean

Die meisten Automationen brauchen Zugang zu fremden Konten. Dabei bekommen sie nie ein Passwort, sondern nur eine befristete Erlaubnis.

OAuth 2.0 regelt, wie eine Anwendung begrenzten Zugriff auf ein Konto bei einem anderen Dienst erhält, ohne dass das Passwort weitergegeben wird. Dieser Vorgang läuft überall dort, wo ein Werkzeug mit einem fremden System sprechen darf – etwa wenn eine Automation Daten in ein Buchhaltungssystem schreibt.

Zuerst fordert die Anwendung beim Dienst die gewünschte Berechtigung an. Eine API ist eine festgelegte Schnittstelle, über die ein Programm Funktionen eines anderen Systems nutzt; der Dienst listet darin genau auf, was die Anwendung erhalten soll.

Dann zeigt der Dienst dem Nutzer diese Anfrage an und fragt nach seiner Zustimmung. Der Nutzer sieht, welche Berechtigung beantragt wird, und kann vor der Freigabe prüfen, ob sie passt.

Danach erteilt der Nutzer die Erlaubnis. Der Dienst prüft den Nutzer, meist über eine Anmeldung im Browser, und bestätigt die Berechtigung. Eine n8n-Automation, die Rechnungen im Buchhaltungssystem anlegen soll, bekommt so nur das Recht, Rechnungen zu erstellen – nicht Konten zu löschen.

Zuletzt erhält die Anwendung ein Access Token, eine Art befristeter Schlüssel, den sie bei jedem Aufruf mitschickt. Wer das Token besitzt, darf genau das, was verabredet wurde – nicht mehr. Anders als ein API-Schlüssel, eine geheime Zeichenfolge, mit der sich ein Programm ausweist: Wer diesen kennt, handelt mit den Rechten des zugehörigen Kontos. Das Token dagegen trägt nur die Teilberechtigung, läuft ab und lässt sich jederzeit widerrufen, ohne ein Passwort zu ändern.

OAuth heißt nicht Passwort weiterzugeben, sondern eine begrenzte, widerrufbare Erlaubnis zu übertragen.

📌 Access Token · Berechtigung · Widerruf

📚 Automatisierung von Grund auf · Tag 4 von 30
#Automatisierung #api #n8n #Integration

Eine Low-Code-Plattform funktioniert wie eine Modelleisenbahn: Die Gleise sind fertig, die Züge laufen auf Schienen. Nur die Streckenführung legt man selbst fest.

Einsteckgleise verbinden Bahnhöfe, Weichen entscheiden über die Richtung, und der Fahrdienstplan legt die Reihenfolge fest. Wer eine Anlage baut, muss keine Gleise selbst fräsen. Trotzdem fährt kein Zug ohne Ziel dorthin, wo der Betreiber es will.

Technisch übernimmt die Plattform das Verdrahten der Schritte, das Ausführen und einfache Fehlerbehandlung. Die Gleise sind die Verbindungen zu anderen Systemen über eine API, eine festgelegte Schnittstelle für Daten und Funktionen. Die Weichen entsprechen der Feldzuordnung, dem Mapping, das festlegt, welches Quellfeld in welches Zielfeld wandert. Der Fahrdienstplan ist die Logik: welcher Schritt unter welcher Bedingung folgt.

Ein Beispiel: Eine Bestellung geht per E-Mail ein. Das ist der Trigger, der Start einer Automation. Der Workflow gleicht Kundendaten ab, erstellt eine Rechnung im Buchhaltungssystem und sendet eine Bestätigung. Das Verdrahten erledigt die Oberfläche; die Reihenfolge und die Regeln legt man selbst fest.

Das Bild hat eine Grenze: Bei Sonderfällen oder ungewöhnlichen Datenformaten enden die fertigen Gleise. Dann fügt man an einzelner Stelle eigenen Code ein, etwa in n8n über eine Code-Node mit einem kleinen Skript. Auch No-Code-Werkzeuge wie Zapier arbeiten nur mit fertigen Bausteinen – wo kein Baustein passt, bleibt nur der Mensch.

Die Oberfläche nimmt das Technische ab, nicht das Denken. Low-Code heißt: verdrahten lassen, Logik selbst gestalten.

📌 Low-Code · Bausteine · Code-Node

📚 Automatisierung von Grund auf · Tag 2 von 30
#Automatisierung #n8n #nocode #workflow

Eine Checkliste zu automatisieren klingt einfach. Wer es versucht, baut bald Ausnahme über Ausnahme ein.

Viele denken, eine Schrittfolge aufzuschreiben reiche für die Automatisierung. Das klingt plausibel, weil eine Checkliste ja ebenfalls Schritte in einer Reihenfolge vorgibt.

Tatsächlich ist ein Workflow mehr als eine Liste: eine festgelegte Folge von Schritten mit Bedingungen und Verzweigungen, die bei jedem Durchlauf nach denselben Regeln abläuft. Er hat einen definierten Start, den Trigger, ein definiertes Ende und für jede Entscheidung eine feste Regel, etwa wenn Anfrage genehmigt, dann Schritt A, sonst Schritt B. Auch die Datenübergabe zwischen den Schritten steht vorher fest: welche Information aus Schritt eins in Schritt zwei übergeht und in welcher Form.

Der Irrtum entsteht, weil Checklisten im Alltag funktionieren. Sie überlassen jede Entscheidung der Person, die sie gerade abarbeitet, und genau das versagt maschinell. Ein Prozess ist erst reif für Automatisierung, wenn die Schrittfolge und ihre Regeln für den Normalfall feststehen.

Eine Bestellung geht per E-Mail ein und löst den Workflow aus. Dann werden automatisch Kundendaten abgeglichen, die Rechnung im Buchhaltungssystem erstellt und eine Bestätigung gesendet. Bei jedem Durchlauf laufen genau diese Schritte in genau dieser Reihenfolge.

Woran man es erkennt: Läuft der Vorgang bei jedem Durchlauf nach denselben Regeln ab, egal wer ihn ausführt? Lautet die Antwort nein, weil Einzelfall-Entscheidungen im Vordergrund stehen, ist es eine Checkliste, kein Workflow.

Workflow heißt nicht eine Liste, die jeder anders abarbeitet, sondern eine geregelte Schrittfolge mit Trigger, festen Regeln und definierten Datenübergaben. Erst den Prozess festlegen, dann automatisieren.

📌 Trigger · Schrittfolge · Datenübergabe

📚 Automatisierung von Grund auf · Tag 1 von 30
#workflow #Automatisierung #Prozessoptimierung

RPA-Bot für die Buchhaltung: 200 Rechnungen pro Monat automatisch verarbeitet. Der Bot extrahiert Daten aus PDFs (OCR + Regex), prüft gegen Bestellungen, kategorisiert nach Kostenstelle und erstellt den Buchungssatz in DATEV. Fehlerquote von 8% (manuell) auf 0.3% (automatisiert). Jährliche Ersparnis: ca. 25.000 EUR an Personalkosten. #rpa #automation #buchhaltung