Wer mit Prozessautomatisierung anfängt, steht schnell vor einer ganzen Reihe an Fragen: Welchen Prozess eigentlich zuerst? Und wie? Mit welchem Tool?
Meistens fehlt dabei ein Vorgehen, das zeigt, was in welcher Reihenfolge passiert und warum. Teams starten mit dem Tool, stolpern über ungeklärte Prozesse, und nach drei Monaten fragt niemand mehr, ob das Ganze eigentlich den versprochenen Effekt gebracht hat.
Ohne klare Methode automatisierst du das Falsche, auf die falsche Art, im falschen Moment.
Genau dafür haben wir das 4D-Modell entwickelt. Ein iteratives Vorgehen in vier Phasen, mit welchem wir jedes Projekt strukturiert durcharbeiten können.
Discover: Erst hinsehen, dann anpacken
In der Discover-Phase werden Prozesse sichtbar gemacht, analysiert und Automatisierungspotenziale gefunden, bevor „drauflosautomatisiert“ wird. In der Praxis überspringen viele leider genau diesen Schritt, obwohl er die Grundlage für alles Folgende legt.
Oft wird das einfach schnell in fünf Minuten durchgearbeitet („Wir haben einen Prozess für Onboarding, der könnte besser sein“). Dabei liegen die größten Potenziale nicht in den sichtbaren Hauptprozessen. Sie verstecken sich in den Kleinstaufgaben, die niemand auf dem Schirm hat: Das manuelle Kopieren von Kontaktdaten aus E-Mails ins CRM. Die Erinnerungsmail, die jede Woche per Hand rausgeht. Die Statusabfragen in fünf verschiedenen Chats (Stichwort: Medienbrüche).
Wir nutzen dafür gerne unser eigenes Prozessanalysetool. Damit decken wir versteckte Zeitfresser im Team auf. Du fragst dabei Team nicht „Was sind eure Prozesse?“, sondern „Was machst du täglich, was dich nervt und was nirgendwo steht?“ Das liefert andere Antworten.
Konkretes Beispiel: Ein Dienstleistungsunternehmen mit zwölf Mitarbeitenden entdeckt im Discover, dass allein das Zusammenstellen der Wochenberichte aus drei Systemen jeden Freitag 90 Minuten kostet. Steht in keinem Prozesshandbuch. War einfach immer so.
Typischer Fehler in dieser Phase: Zu schnell loslaufen. Du hast nach zwei Gesprächen das Gefühl, alles zu verstehen, und springst direkt ins Design. Das rächt sich, weil du dann Lösungen für die falschen Probleme baust.
Design: Den Soll-Prozess zuerst auf Papier
In der Design-Phase wird der Prozess entworfen, der Automatisierungsgrad festgelegt, der Toolstack definiert und Ausnahmen zusammengefasst, bevor eine einzige Zeile Logik gebaut wird. Essentiell ist, dass auch dort erst über die Art der Umsetzung entschieden wird. Es ist komplett vom Use-Case abhängig, ob mit existierendem Toolstack gearbeitet werden kann, eine Automatisierung mit make.com sinnvoll ist oder sogar ein eigenes Tool mit AI-Shoring erstellt wird.
Dieser Schritt ist der am häufigsten unterschätzte im ganzen Modell.
Die zentrale Frage ist: „Wie soll der Prozess zukünftig idealerweise laufen?“ Das ist ein Unterschied. Wer direkt vom Ist-Zustand zur Automatisierung springt, automatisiert den alten Schrott mit. Zu beantwortende Fragen darüber hinaus, die über den Erfolg entscheiden:
- Welche Schritte werden vollständig automatisiert?
- Wo braucht es menschliche Entscheidungen?
- Was sind die Ausnahmen, die der Prozess nicht abbilden kann? (Und es gibt immer Ausnahmen.)
Wer den Automatisierungsgrad nicht explizit festlegt, merkt erst beim Rollout, dass die Erwartungen auseinanderlagen.
Außerdem lohnt es sich, an dieser Stelle mit einem Automatisierungsaudit zu prüfen, welche Prozesse wirklich reif für die Umsetzung sind. Nicht jeder Prozess, den du in Discover gefunden hast, ist auch sinnvoll automatisierbar. Am schönsten ist es, die Prozesse mit dem höchsten Potenzial (geringer Aufwand, hoher Impact) zuerst anzugehen. Das unterstützt auch beim Thema AKzeptanz im Team!
Konkretes Beispiel: Für den Wochenbericht aus dem Discover-Beispiel wird im Design festgelegt: Daten aus System A und B werden automatisch zusammengeführt, System C erfordert manuelle Prüfung (weil die Datenqualität dort schwankt). Das Ergebnis landet automatisch als Entwurf beim Teamlead. Freigabe bleibt menschlich.
Typischer Fehler in dieser Phase: Ausnahmen ignorieren. „Das passiert so selten, das berücksichtigen wir nicht.“ Und dann passiert genau das in Woche zwei nach dem Launch und niemand weiß, was zu tun ist.
Develop: Entwickeln, testen, nochmal testen
Erst dann geht es wirklich los! Den Prozess entwickeln, mit echten Daten testen und iterieren, bis er zuverlässig läuft. Und dabei ist es ganz unerheblich, ob es eine Automatisierung oder ein Tool ist. Das Vorgehen ist systematisch immer gleich.
Das Testen mit Dummy-Daten hat seinen Platz. Aber es findet nie alle Probleme. Echte Daten sind unordentlich. Sie enthalten Sonderzeichen, leere Felder, unerwartete Formate. Wer das nicht früh testet, findet es beim Rollout heraus (schlechtester Zeitpunkt).
Iteratives Vorgehen heißt auch, lieber eine abgespeckte Version früh zeigen als monatelang im Verborgenen zu arbeiten um dann mit dem Big Bang anzukommen… und das falsche entwickelt zu haben. Das schafft Vertrauen bei den Menschen, die später damit arbeiten.
Wer tiefer einsteigen will, was dabei schief gehen kann und warum gute Prozesse vor dem Automatisieren Pflicht sind: Automatisiere smart, nicht blind gibt dazu einen guten Rahmen.
Konkretes Beispiel: Die erste Version des Wochenberichts-Workflows läuft in der Testumgebung sauber. In der Praxis stellt sich heraus: Zwei Mitarbeitende tragen ihre Daten in System A mit einem anderen Datumsformat ein. Der Workflow bricht ab. Drei Iterationen später ist das abgefangen. (Verkürztes Beispiel, ind er Praxis ist sowas in der Regel deutlich komplexer)
Typischer Fehler in dieser Phase: Zu lange auf Perfektion hinarbeiten. Ein Workflow, der zu 80 Prozent funktioniert und live ist, liefert mehr Lerneffekte als einer, der seit drei Monaten in der Entwicklung steckt. Immer mit Fallbacks arbeiten!
Deploy: Einführen in den Live-Betrieb
Endlich ist es so weit. Wir haben entwickelt, getestet, iteriert, optimiert. Die Automatisierung, das Tool, die Website ist fertig! Es wird Zeit das an euch z uübergeben. Das Team abholen, Ergebnisse messen und kontinuierlich optimieren.
Entscheidend ist hier, nicht einfach zu hofften dass alle den neuen Prozess einfach nutzen. Das führt garantiert, ja absolut garantiert zu Enttäuschung! Menschen umgehen Prozesse, die sie nicht verstehen oder denen sie nicht vertrauen. Und das vollkommen rational: Wenn ich nicht weiß, ob der Workflow meinen Sonderfall berücksichtigt, mache ich es lieber selbst. Wenn ich die Funktionsweise nicht verstehe, es zu kompliziert erscheint oder ich mir das selbst beibringen soll, dann hab ich es lieber schnell manuell erledigt.
Deploy bedeuetet also auch zu erklären, was sich ändert und warum. Zeigen, was der Workflow macht und was er nicht macht. Erste Wochen begleiten, Feedback einsammeln. Kennzahlen festlegen, damit du weißt, ob der Prozess das hält, was er verspricht.
Dieser Punkt hängt eng damit zusammen, warum Teams überhaupt so viel Zeit mit Verwaltungsaufwand verbringen. Oft ist fehlende Transparenz über Abläufe das eigentliche Problem, nicht fehlende Automatisierung.
Konkretes Beispiel: Der Wochenbericht-Workflow ist live. Die Teamleiterin erklärt in einem 20-minütigen Meeting, was passiert und was nicht. Sie benennt explizit: „System C prüft ihr weiterhin selbst, das ist gewollt.“ In Woche drei meldet ein Mitarbeitender, dass sein Bereich im Entwurf fehlt. Ein Fehler im Mapping wird gefunden und behoben. Ohne das Feedback wäre es unbemerkt geblieben.
Typischer Fehler in dieser Phase: Deploy and run. Wenn die Menschen alleinegelassen werden und die Lösung ihrem Schicksal überlassen wird, war es sinnlos.
Die vier Phasen im Überblick
Jetzt noch einmal auf einen Blick, was im 4D-Modell drin ist:
| Phase | Kernfrage | Typisches Werkzeug | Typischer Fehler |
|---|---|---|---|
| Discover | Was passiert wirklich? | Prozessanalyse-Tool, Shadow Work Audit, Prozessinterviews | Zu früh ins Design springen |
| Design | Wie soll es laufen? | Prozessskizze, Automatisierungsaudit | Ausnahmen nicht definieren |
| Develop | Funktioniert es mit echten Daten? | Iterative Tests, MVP-Ansatz | Zu lange bauen ohne Feedback |
| Deploy | Wird es wirklich genutzt? | Rollout-Kommunikation, KPIs | Keine saubere Übergabe und Verbesserungen |
Iterativ statt linear
Das Wichtigste am 4D-Modell: Es ist iterativ, kein linearer Wasserfall.
In der Praxis kommst du beim Design drauf, dass du in Discover zu wenig weißt, und gehst nochmal zurück. Oder du bist mitten im Develop und merkst, dass das Design eine Annahme enthält, die nicht stimmt. Das ist der Prozess und er lässt diese Korrekturen zu. Wir müssen mit Annahmen arbeiten und diese schrittweise validieren. Das Gute ist: Durch eine kontinuierliche Kommunikation ist die Korrekturfähigkeit groß und die Phasen geben die entsprechende Orientierung zum richtigen Zeitpunkt die richtigen Fragen zu stellen!
Wer sich fragt, warum das nicht mit einem neuen Tool allein funktioniert, findet in diesem Artikel über Tool-Chaos und Prozessdenken eine ehrliche Antwort darauf.
Die eigentliche Frage ist nicht, welches Tool du nimmst. Sie ist, ob du weißt, was du automatisieren willst und warum. Das 4D-Modell hilft dir, genau das herauszufinden.
Häufig gestellte Fragen
Was ist das 4D-Modell für Prozessautomatisierung?
Das 4D-Modell beschreibt ein iteratives Vorgehen für Prozessautomatisierung in vier Phasen: Discover (Prozesse sichtbar machen), Design (Soll-Prozess entwerfen), Develop (Automatisierung bauen und testen) und Deploy (einführen und messen). Es ist kein starres Wasserfall-Modell, sondern ein flexibler Rahmen, der Schleifen erlaubt.
Wie finde ich heraus, welche Prozesse sich zur Automatisierung eignen?
In der Discover-Phase analysierst du bestehende Abläufe systematisch. Ein bewährtes Werkzeug ist der Shadow Work Audit: Dabei dokumentierst du alle unsichtbaren Kleinstaufgaben, die dein Team täglich erledigt, aber nirgendwo auftauchen. So findest du die echten Zeitfresser und Automatisierungspotenziale.
Was gehört in die Design-Phase einer Prozessautomatisierung?
In der Design-Phase entwirfst du den Soll-Prozess: Wie soll der Ablauf nach der Automatisierung aussehen? Du legst fest, welche Schritte vollständig automatisiert werden, welche Ausnahmen manuell behandelt werden müssen und wo Menschen eingreifen sollen. Dieser Schritt kommt vor dem Bauen, nicht danach.
Wie lange dauert die Develop-Phase?
Das hängt von der Komplexität des Prozesses ab. Einfache Automatisierungen können in wenigen Stunden stehen. Komplexere Workflows mit mehreren Systemverbindungen brauchen oft ein bis drei Wochen. Wichtiger als Geschwindigkeit ist das iterative Testen: Lieber früh mit echten Daten testen als spät merken, dass die Logik nicht stimmt.
Warum scheitern Automatisierungen oft beim Rollout?
Weil die Menschen vergessen werden. Technisch kann alles funktionieren, aber wenn das Team nicht versteht, was sich ändert und warum, arbeiten sie um die Automatisierung herum statt mit ihr. Die Deploy-Phase ist deshalb zu mindestens 50 Prozent Kommunikation und Begleitung, nicht Technik.
