Field Note: Warum ich vor einer Automatisierung erst den Prozess verstehen will

Ich automatisiere einen Prozess nicht, bevor ich verstanden habe, was darin tatsächlich passiert. Sonst wird ein schlechter Ablauf nicht besser – er läuft nur schneller und verteilt seine Fehler zuverlässiger.

Mein erster Impuls ist nicht der richtige Startpunkt

Wenn ein Ablauf wiederholt manuelle Arbeit verursacht, liegt der Gedanke nahe, ihn möglichst früh zu automatisieren. Ein Formular wird abgeschickt, Informationen sollen ins CRM, Tags müssen gesetzt und weitere Schritte angestoßen werden. Das wirkt zunächst wie eine klare Kette: Eingabe rein, Ergebnis raus.

In meiner Arbeit begegnet mir diese Frage bei Formularen, CRM-Weitergaben, Imports, Contentprozessen und n8n-Abläufen. Der erste Impuls ist oft, die sichtbaren Handgriffe zu verbinden. Doch die Handgriffe sind nicht der Prozess. Sie sind nur das, was man gerade sehen kann.

Bevor ich etwas verbinde, will ich wissen, warum ein Feld abgefragt wird, welche Entscheidung auf einer Angabe beruht und was passiert, wenn eine Information fehlt oder nicht in das erwartete Muster passt. Wenn diese Fragen offen sind, kann ich zwar einen Ablauf bauen. Ich weiß aber noch nicht, ob er den richtigen Ablauf abbildet.

Was ich zuerst prüfe: Welche Informationen sind wirklich nötig, welche Entscheidungen werden getroffen, welche Ausnahmen gibt es – und an welcher Stelle braucht es menschliche Kontrolle?

Der manuelle Ablauf enthält oft die eigentliche Logik

Manuelle Arbeit wirkt von außen manchmal unnötig langsam. Wer sie automatisieren möchte, schaut dann zuerst darauf, wie sich Klicks, Übertragungen oder wiederkehrende Eingaben einsparen lassen. Das ist verständlich, aber zu früh angesetzt.

Hinter einem scheinbar einfachen Schritt steckt oft eine Entscheidung. Wird ein Datensatz weitergegeben, weil alle Pflichtangaben vorhanden sind? Wird er einer bestimmten Kategorie zugeordnet? Muss jemand prüfen, ob die Angaben zusammenpassen? Und wie wird mit Fällen umgegangen, die nicht eindeutig sind?

Solange diese Logik nur im Kopf der Person steckt, die den Ablauf ausführt, ist sie keine belastbare Grundlage für Automatisierung. Sie muss nicht in einem großen Dokument festgehalten werden. Aber ich muss sie sichtbar machen: als nachvollziehbare Reihenfolge von Eingaben, Prüfungen, Entscheidungen und möglichen Abzweigungen.

Für einen einfachen Ablauf kann die Skizze zunächst so aussehen:

Formular → Daten validieren → klassifizieren → CRM → Tags → Folgeprozess

Die Skizze ist noch keine technische Spezifikation. Sie hilft mir, genauer hinzusehen. Was bedeutet „validieren“ hier? Reicht es, ein Pflichtfeld zu prüfen, oder muss der Inhalt auch zu anderen Angaben passen? Was bedeutet „klassifizieren“: eine eindeutige Regel oder eine Einschätzung? Und löst ein Tag immer denselben Folgeprozess aus?

Wenn ich diese Begriffe nicht konkretisieren kann, ist der Ablauf noch nicht bereit für eine Automatisierung. Dann würde ich lediglich unklare Entscheidungen in ein Werkzeug verlagern.

Ausnahmen sind kein Randthema

Ein Prozess ist nicht nur die ideale Route, auf der alle Angaben vollständig und eindeutig sind. Auch die Fälle, die nicht hineinpassen, gehören zu seinem tatsächlichen Verhalten. Fehlt ein Feld? Widersprechen sich zwei Angaben? Kommt ein Datensatz doppelt an? Ist eine Zuordnung unsicher? Was soll dann geschehen?

Ich muss nicht jede denkbare Ausnahme vorab technisch lösen. Aber ich sollte wissen, welche davon vorkommen können und welche Folgen eine falsche automatische Entscheidung hätte. Daraus ergibt sich, ob ein Schritt automatisch laufen darf, ob er zunächst nur vorbereitet wird oder ob ein Mensch die Entscheidung treffen muss.

Gerade bei Klassifikation und Weitergabe ist die Unterscheidung wichtig. Eine klare, überprüfbare Regel lässt sich oft gut automatisieren. Eine Einschätzung mit unklaren Grenzen sollte nicht so behandelt werden, als wäre sie eindeutig. Bei Unsicherheit kann der passende nächste Schritt sein, den Fall anzuhalten, zu markieren oder zur Prüfung vorzulegen.

Das ist für mich die Brücke zu Human-in-the-loop: Menschen bleiben nicht als Notlösung im Ablauf, sondern übernehmen gezielt die Entscheidungen, die nicht zuverlässig oder nicht sinnvoll vollständig automatisiert werden können. Die Automatisierung kann Informationen ordnen, vorbereiten und weiterreichen. Sie muss nicht so tun, als könne sie jede Abweichung selbst beurteilen.

Erst verstehen, dann verändern, dann prüfen

Eine Sache hat sich bei mir verändert: Ich betrachte Automatisierung weniger als Verbindung zwischen Werkzeugen und mehr als Änderung an einem bestehenden System. Deshalb will ich zuerst den Ist-Zustand kennen. Danach entscheide ich, was geändert werden soll. Und anschließend prüfe ich, ob die Änderung tatsächlich das gewünschte Verhalten erzeugt.

Das lässt sich auch auf kleine Abläufe anwenden. Ich kann den Prozess zunächst manuell nachvollziehen und seine Schritte benennen. Dann kläre ich, welche Felder nötig sind, welche Regeln gelten und wo Sonderfälle landen. Erst danach baue ich die Automatisierung. Zum Schluss prüfe ich nicht nur, ob ein Lauf technisch erfolgreich war, sondern ob die richtigen Daten am richtigen Ort angekommen sind und ob die vorgesehenen Entscheidungen nachvollziehbar bleiben.

Diese Reihenfolge verhindert nicht jeden Fehler. Sie macht aber sichtbarer, was ich überhaupt testen muss. Ein Workflow, der ohne Fehlermeldung durchläuft, ist nicht automatisch fachlich richtig. Eine erfolgreiche Übertragung belegt zunächst nur, dass Daten übertragen wurden. Ob Klassifikation, Zuordnung und Folgeprozess stimmen, muss ich gesondert prüfen.

In diesem Sinn passt für mich das Prinzip Know → Change → Prove: erst den Zustand verstehen, dann kontrolliert verändern und schließlich die Wirkung belegen. Bei Automatisierungen gehört dazu auch, einen Weg für unklare oder fehlerhafte Fälle vorzusehen. Sonst kann ein Ablauf zwar effizient aussehen, aber schwer zu kontrollieren sein.

Was ich heute anders mache

Ich frage nicht mehr nur: „Welchen Schritt können wir automatisieren?“ Ich frage zuerst: „Welche Arbeit wird hier eigentlich geleistet?“ Das verschiebt den Blick von den sichtbaren Handgriffen zu den Informationen und Entscheidungen, die sie zusammenhalten.

Manchmal zeigt sich dabei, dass nicht die Automatisierung der nächste sinnvolle Schritt ist. Vielleicht müssen Felder verständlicher werden, Zuständigkeiten klarer sein oder Regeln überhaupt erst festgelegt werden. Das ist keine Verzögerung der technischen Arbeit. Es ist ein Teil davon, die richtige technische Arbeit zu bestimmen.

Wenn der Ablauf verständlich ist, wird die Wahl des Werkzeugs leichter. Dann lässt sich auch besser beurteilen, ob ein bestehendes Automatisierungswerkzeug genügt oder ob ein Teil der Logik an anderer Stelle liegen sollte. Ich entscheide das nicht zuerst anhand der verfügbaren Funktionen, sondern anhand des Prozesses, den das System abbilden soll.

Meine Faustregel: Ich automatisiere erst, wenn ich den manuellen Ablauf, seine Entscheidungen und seine Ausnahmen erklären kann – und weiß, wo ein Mensch übernehmen muss.

Weiterführend

• Human-in-the-loop: Warum gute KI-Workflows Menschen nicht entfernen
• n8n und KI: Architektur für robuste Automatisierungen
• Welche Prozesse eignen sich für KI-Automatisierung?