Prozesse nicht malen, sondern laufen lassen
Ein Flussdiagramm ist ein Bild, ein Prozess ist ein System. Warum der nützlichste Weg, Abläufe zu dokumentieren und zu analysieren, keine statische Karte ist, sondern ein Modell, das man unter Last laufen lässt — und den Engpass sichtbar werden sieht.
Prozesse nicht malen, sondern laufen lassen
Fast jede Prozessverbesserung beginnt gleich: Jemand öffnet ein Zeichenprogramm und malt den Ist-Zustand. Kästen für Schritte, Rauten für Entscheidungen, Pfeile für den Fluss. Das fühlt sich nach Fortschritt an — und ist es auch, ein gemeinsames Bild schlägt ein Dutzend privater Vorstellungen im Kopf. Dann landet das Bild an einer Wand. Und an dieser Wand stirbt die meiste Prozessarbeit still und leise.
Das Problem ist nicht das Zeichnen. Es ist, dass ein Flussdiagramm nur die Form eines Prozesses zeigen kann, nie sein Verhalten. Und fast jede interessante Frage zu einem Prozess ist eine Frage nach dem Verhalten.
Ein Flussdiagramm ist ein Bild. Ein Prozess ist ein System.
Schau auf eine beliebige Prozesslandkarte und stell die Fragen, die wirklich zählen: Wo staut sich die Arbeit, wenn die Nachfrage hochschnellt? Welcher Schritt entscheidet über den Durchsatz der ganzen Kette? Wenn wir hier eine Person dazunehmen — was passiert drei Schritte weiter hinten? Wie groß ist die realistische Spanne der Durchlaufzeit eines Vorgangs — nicht der Mittelwert, die Spanne?
Ein statisches Diagramm hat dazu nichts zu sagen. Kästen bilden keine Warteschlange. Pfeile warten nicht. Die Karte sieht gleich ruhig aus, ob der Prozess rund läuft oder unter dem Montags-Rückstau zusammenbricht. Sie hält fest, was womit verbunden ist, und schweigt zu dem Einzigen, das Geld kostet: was unter Last passiert.
Genau da klafft die Lücke. Du hast den Prozess dokumentiert, kannst das Diagramm einer neuen Kollegin in die Hand drücken — und beantwortest trotzdem nicht die eine Frage, die dein Kunde oder deine Geschäftsführung tatsächlich stellt: Wo ist der Engpass, und was ist es wert, ihn zu beheben?
Der Wechsel: von der Karte zum Modell, das läuft
Der nützlichere Gedanke zu Dokumentation ist nicht „eine Zeichnung der Schritte", sondern „ein Modell, das sich verhält wie das Original". Der Unterschied: Ein Modell hat die fehlenden Dimensionen eingebaut.
- Jeder Schritt hat eine Kapazität und eine Dauer — wie viel er schafft, wie lange er braucht — statt nur ein konturloser Kasten zu sein.
- Arbeit kommt über die Zeit an, mit schwankendem Volumen und Spitzen, statt als Pfeil, der einen glatten, unendlichen Strom suggeriert.
- Schritte hängen voneinander ab — ein nachgelagertes Team kann nur das verarbeiten, was der vorgelagerte Schritt durchlässt.
Gib einem Prozess diese Eigenschaften, und du kannst etwas tun, das ein Flussdiagramm nie erlaubt: auf Play drücken. Speise einen realistischen Arbeitsstrom ein und sieh ihn fließen. Wo ein Schritt nicht hinterherkommt, wächst die Warteschlange davor und die Auslastung klettert über 100 %. Das ist dein Engpass — nicht im Workshop behauptet, sondern beobachtet, so wie er sich auch in der Realität zeigen würde, nur schneller und ohne den Preis, es auf die harte Tour herauszufinden.
Warum das Intuition schlägt — und den Mittelwert
Zwei Reflexe sabotieren Prozessanalyse leise. Dieser Ansatz behebt beide.
Der erste ist das Bauchgefühl, wo das Problem liegt. Frag fünf Leute im Team nach dem Engpass, und du bekommst oft fünf Antworten, jede geprägt davon, wo der Einzelne sitzt. Der lauteste Schritt ist nicht immer der bindende. Ein Modell klärt das über Verhalten, nicht über Meinung: Der Schritt, der unter realistischer Last zuerst überläuft, ist der Engpass — und häufig ist es nicht der, den alle beschuldigt haben. Das klassische Muster ist ein nachgelagertes Team, das langsam wirkt, in Wahrheit aber ausgehungert ist: Es steht still, weil der Schritt, der es speist, nicht hinterherkommt. Stock das untätige Team auf, und nichts bewegt sich. Die Karte kann dir das nicht zeigen. Ein laufendes Modell zeigt es sofort.
Der zweite ist die Tyrannei des Mittelwerts. „Dieser Schritt dauert 7,5 Minuten" ist eine bequeme Fiktion. Echte Schritte dauern 5 bis 10 Minuten, die Nachfrage liegt bei 80 bis 130 Vorgängen am Tag — und es sind genau die schlechten Kombinationen, Spitzenanfall trifft langsame Bearbeitung, die einen Prozess brechen. Ein einzelner Mittelwert verbirgt exakt die Schwankung, die den Schmerz verursacht. Deshalb reicht es nicht, einen Prozess einmal mit Durchschnittszahlen durchzurechnen, und deshalb setzt ernsthafte Analyse auf Monte-Carlo-Simulation: Lass den Prozess über hunderte simulierte Tage laufen, jeden mit seinen eigenen realistischen Ausschlägen, und du fragst nicht mehr „was passiert an einem typischen Tag", sondern das, worauf es ankommt — wie oft bindet dieser Schritt, und wie schlimm wird es, wenn er es tut? Du bekommst ein P90, keinen Punkt. Eine Spanne, kein Gerücht.
Der Sinn der Analyse ist eine Entscheidung
Einen Prozess zu dokumentieren und zu analysieren ist nicht das Ergebnis. Die Entscheidung ist es. Und Entscheidungen werden getroffen — oder blockiert — je nachdem, ob die Zahl dahinter der Prüfung standhält.
Ein Modell, das läuft, verändert, was du auf den Tisch legen kannst. Statt „ich glaube, der Underwriting-Schritt ist das Problem" kannst du sagen „Underwriting bindet an 8 von 10 Tagen, und das kostet diesen Durchsatz". Statt „Automatisieren sollte helfen" änderst du eine Zahl — Person dazu, Bearbeitungszeit kürzen, Schritt automatisieren — lässt das Modell neu einpendeln und liest das Vorher/Nachher in Durchlaufzeit und in Euro pro Jahr ab. Und weil die Eingaben Spannen waren, ist auch das Ergebnis eine Spanne: 120k bis 180k pro Jahr, mit der Unsicherheit ehrlich bis zum Schluss durchgetragen — statt einer verdächtig präzisen Einzelzahl, der der erste Skeptiker im Raum zu Recht misstraut.
Diese Ehrlichkeit ist das ganze Spiel. Zahlen gewinnen einen Raum nur, wenn sie Gegendruck überleben. Ein Modell, aus Spannen gebaut, über hunderte Tage gestresst, mit jeder Zahl rückführbar auf eine Annahme, die du verteidigen kannst, ist genau dafür gemacht.
Was das in der Praxis heißt
Du musst nicht alles modellieren, und du solltest es nicht. Die Kunst ist, die wenigen Schritte zu wählen, wo die Kapazität wirklich knapp ist und die Schwankung wirklich beißt — und bei den Eingaben ehrlich zu bleiben. Ein Modell ist nur so gut wie seine Annahmen, weshalb es genauso zählt, jede Zahl nach ihrer Herkunft zu markieren (gemessen, geschätzt, geraten) wie die Simulation selbst.
Der Wechsel der Denkweise ist der wertvolle Teil — und er ist da, egal zu welchem Werkzeug du greifst:
- Dokumentiere den Ist-Zustand als Modell, nicht als Wandbild — Schritte mit Kapazität und Dauer, Arbeit, die über die Zeit ankommt, Abhängigkeiten zwischen Schritten.
- Arbeite mit Spannen, nicht mit Scheingenauigkeit — und lass diese Unsicherheit bis ins Ergebnis fließen.
- Stresstest — viele simulierte Tage, nicht ein Durchschnittslauf, damit der Engpass danach gerankt ist, wie oft er tatsächlich bindet.
- Teste die Verbesserung, bevor du sie verkaufst — einen Hebel ändern, beim Einpendeln zusehen, das Vorher/Nachher in Zeit und Geld ablesen.
Ein Flussdiagramm sagt dir, dass der Prozess existiert. Ein Modell, das läuft, sagt dir, wo es wehtut, wie sehr, und was es wert ist, das zu beheben. Für alle, die in einen Raum gehen und eine Änderung vor Leuten verteidigen müssen, die widersprechen, ist das der Unterschied zwischen „glaub mir" und „hier ist die Rechnung".
Das ist die Denkweise hinter FlowVisual — einem Desktop-Prozesssimulator, den wir genau für diese Schleife gebaut haben: modellieren, stresstesten, die Verbesserung in Euro belegen. Aktuell in der Public Beta für Windows und macOS, vollständig lokal, ohne Account. Wenn der Ansatz für dich klickt, lohnt sich ein Blick — aber der Ansatz zählt mehr als das Werkzeug.
