Steffen·Co-Founder & AutomationWarum du Prozesse erst dokumentieren solltest, bevor du automatisierst
Wie du Abläufe vor der Automation sauber dokumentierst, Engpässe erkennst und erst dann Prozesse automatisierst, die stabil und skalierbar sind.
"Wir wollen das automatisieren." — Die häufigste Antwort, wenn ein Betrieb merkt, dass manuelle Arbeit zu viel Zeit kostet. Die zweithäufigste Antwort, nachdem das Projekt gescheitert ist: "Wir haben gar nicht richtig verstanden, wie der Prozess eigentlich läuft." Automation verstärkt das, was bereits da ist. Einen kaputten Prozess automatisierst du kaputt — nur schneller.
Kurzfassung
Wer einen unklaren Prozess automatisiert, automatisiert das Chaos. Bevor du ein Tool öffnest: dokumentiere den Ablauf Schritt für Schritt, finde den echten Engpass, und entscheide dann, was sich wirklich lohnt zu automatisieren. Die Dokumentation ist keine Vorstufe, sie ist die eigentliche Arbeit.
Pillar aus diesem Cluster
Make für Einsteiger: So automatisierst du deinen ersten Prozess
Praxisnaher Einstieg in Make: Von Trigger bis Error-Handling baust du einen stabilen ersten Flow, der manuelle Übergaben ersetzt und zuverlässig läuft.
Zum Pillar-Artikel →Der grundlegende Fehler: Zuerst das Tool, dann der Prozess
Die typische Reihenfolge: Jemand hört von Make, Zapier oder n8n. Er setzt sich hin, verbindet ein paar Apps, und versucht, seinen Arbeitsablauf irgendwie abzubilden. Zwei Wochen später läuft etwas — aber nicht richtig. Felder fehlen, Ausnahmen werden nicht behandelt, und niemand weiß genau, was passiert, wenn ein Edge Case auftritt.
Das Problem ist nicht das Tool. Das Problem ist, dass der Prozess nie sauber definiert wurde. Er existierte nur im Kopf der Person, die ihn täglich ausführt — mit allen impliziten Annahmen, Ausnahmen und informellen Regeln, die nirgendwo dokumentiert sind.
Automation erfordert explizites Wissen. Was implizit im Kopf passiert, kann kein Tool reproduzieren. Bevor du die erste App verbindest, musst du den Prozess auf Papier verstehen.
Was Prozess-Dokumentation wirklich bedeutet
Prozess-Dokumentation ist kein 50-seitiges Word-Dokument. Es ist eine klare Antwort auf die Frage: Was passiert, Schritt für Schritt, von dem Moment an, wenn X passiert, bis zu dem Moment, wenn Y erreicht ist?
Für einen Anfrage-Eingangs-Prozess sieht das so aus: Anfrage kommt rein → Wer sieht sie zuerst? → Was wird geprüft? → Was sind die möglichen Outcomes? (passt, passt nicht, braucht mehr Info) → Was passiert bei jedem Outcome? → Wer macht was, bis wann?
Das Ziel ist nicht, einen perfekten Prozess zu dokumentieren. Das Ziel ist, den tatsächlichen Prozess sichtbar zu machen — inklusive aller Ausnahmen, Übergaben und informellen Regeln. Erst wenn das auf dem Tisch liegt, kannst du entscheiden, was davon automatisiert werden soll.
Swimlane-Diagramme: Die einfachste Methode
Ein Swimlane-Diagramm ist ein Flussdiagramm, das nach Verantwortlichkeiten aufgeteilt ist. Jede Person oder jedes Team hat eine "Lane" — eine horizontale Zeile. Schritte werden in der Lane der Person platziert, die diesen Schritt ausführt. Übergaben werden durch Pfeile zwischen den Lanes dargestellt.
Das Ergebnis zeigt auf einen Blick: Wo passieren Übergaben? Wo entstehen Wartezeiten? Welche Person ist Flaschenhals? Welche Schritte sind einfache, regelbasierte Aufgaben, die automatisiert werden könnten?
Werkzeuge dafür: Miro, FigJam, Lucidchart, oder einfach Post-its an einer Wand. Das Werkzeug ist irrelevant — die Methode ist es, die zählt.
Eine praktische Regel: Wenn ein Schritt in deinem Diagramm immer gleich aussieht (kein if-then, kein Urteilsvermögen erforderlich), ist er ein Kandidat für Automation. Wenn ein Schritt Kontext, Erfahrung oder menschliches Urteilsvermögen erfordert, bleibt er beim Menschen.
Engpässe finden: Wo verliert dein Team tatsächlich Zeit
Frag jeden, der regelmäßig im Prozess arbeitet, zwei Fragen: Was dauert länger als es sollte? Was machst du mehrfach täglich, was immer gleich aussieht?
Die Antworten zeigen die Engpässe. Häufige Kandidaten: manuelle Dateneingabe in CRM oder Tabellen, das Kopieren von Informationen zwischen verschiedenen Tools, das Versenden derselben E-Mail-Typen immer wieder, das manuelle Zuweisen von Aufgaben an Teammitglieder.
Bevor du automatisierst: Berechne den tatsächlichen Zeitaufwand. "Das dauert immer lange" ist keine Entscheidungsgrundlage. "Diese Aufgabe kostet uns täglich 45 Minuten, das sind 180 Stunden im Jahr" ist eine.
Der Test vor der Automation
Bevor du anfängst zu automatisieren, führe diesen Test durch: Gib die Prozess-Dokumentation einer Person, die den Prozess nicht kennt. Sag ihr, sie soll die nächste Anfrage anhand der Dokumentation bearbeiten — ohne Rückfragen.
Was passiert? Fast immer entstehen Fragen: "Was ist, wenn der Kunde keine Telefonnummer angegeben hat?" "Wer entscheidet, ob das Budget realistisch ist?" "Was passiert, wenn das CRM gerade nicht erreichbar ist?"
Diese Fragen sind Gold. Sie zeigen die Lücken in der Dokumentation — und damit die Edge Cases, die deine Automation später nicht kennen wird. Löse diese Fragen zuerst. Dann automatisiere.
Eine Automation, die 95 Prozent der Fälle behandelt und 5 Prozent still scheitern lässt, ist schlimmer als kein automatisierter Prozess. Du siehst das Scheitern nicht — bis ein Kunde sich beschwert.
Erst dokumentieren, dann digitalisieren, dann automatisieren
Das ist die Reihenfolge, die funktioniert. Dokumentieren: Den Ist-Prozess sichtbar machen, wie er heute wirklich läuft. Digitalisieren: Sicherstellen, dass alle Informationen in strukturierter, maschinenlesbarer Form vorliegen — nicht in PDF-Anhängen, WhatsApp-Nachrichten oder mündlichen Übergaben.
Erst dann automatisieren: Die Schritte identifizieren, die regelbasiert und wiederholbar sind, und diese systematisch aus manueller Arbeit herausnehmen.
Betriebe, die diese Reihenfolge überspringen, landen oft beim "Es läuft, aber wir wissen nicht warum — und wenn es nicht läuft, wissen wir auch nicht warum." Das ist kein System, das ist ein digitales Chaos.
Wie diese drei Schritte in echten Projekten abgelaufen sind, siehst du in unseren Cases.
Automation ist ein Multiplikator. Sie multipliziert, was bereits da ist — gute Prozesse genauso wie schlechte. Investiere zuerst in Prozessklarheit. Die Automation danach ist dann schneller, günstiger und zuverlässiger zu bauen. Und wenn etwas schiefgeht — und das wird es irgendwann — weißt du, wo du nachschauen musst.
Häufige Fragen
Wie lange dauert Prozess-Dokumentation, bevor man anfangen kann zu automatisieren?
Für einen einzelnen, klar abgegrenzten Prozess (z.B. Lead-Eingang) plan 2–4 Stunden für ein initiales Swimlane-Diagramm plus eine Runde Feedback vom Team. Perfekte Dokumentation ist nicht das Ziel — ausreichende Klarheit ist es. Lieber früh anfangen und iterieren.
Was, wenn niemand in meinem Team den Prozess vollständig kennt?
Das ist häufiger als man denkt — und selbst ein Hinweis, dass der Prozess Probleme hat. Führe ein kurzes Interview mit allen, die am Prozess beteiligt sind, und dokumentiere, was jede Person glaubt, dass sie tut. Die Unterschiede zwischen den Aussagen zeigen die Brüche.
Kann man Prozesse automatisieren, ohne sie vorher zu dokumentieren?
Technisch ja. Ob das sinnvoll ist: selten. Einfache, klar begrenzte Flows (z.B. "bei neuer E-Mail von diesem Absender → in Tabelle eintragen") können direkt umgesetzt werden. Sobald mehrere Personen, Ausnahmen oder Übergaben involviert sind, ist Dokumentation die Zeitersparnis, die sich lohnt.
Quellen
Kostenlose Analyse
Konkrete Einschätzung deiner Situation
30 Minuten. Kein Verkaufsdruck. Du weißt danach, wo du stehst und welche nächsten Schritte sinnvoll sind.