Loops in Prozessen: Wiederholungen richtig modellieren
Wie du Wiederholungen abbildest, ohne das Prozessmodell unlesbar zu machen – erklärt am Onboarding-Prozess
Loops bilden Wiederholungen in Prozessen ab, ohne das Modell unlesbar zu machen. Wie du erkennst, wann du einen Loop brauchst – erklärt am Onboarding-Prozess.
Ein Loop ist ein Prozessabschnitt, der für jedes Element einer Liste einmal durchlaufen wird: für jedes Gerät, jede Rechnungsposition, jeden Teilnehmer, jede Abteilung. Statt denselben Ablauf mehrfach ins Modell zu kopieren, modellierst du ihn einmal und definierst, worüber er läuft.
Fast jeder reale Prozess enthält solche Wiederholungen. Und fast jedes Prozessmodell, das ohne Loops gebaut wurde, wird an genau dieser Stelle unübersichtlich.
Warum Wiederholungen Prozessmodelle sprengen
Der typische Weg ohne Loop sieht so aus: Ein neuer Mitarbeiter bekommt Laptop, Monitor, Headset und Diensthandy. Also modelliert jemand vier Zweige, je einen pro Gerät. Das funktioniert – bis das fünfte Gerät dazukommt.
Dann passiert Folgendes:
- Der neue Zweig wird kopiert, und beim Kopieren geht eine Kleinigkeit verloren: eine Frist, eine Zuständigkeit, eine Benachrichtigung.
- Eine Änderung an der Logik muss an vier oder fünf Stellen nachgezogen werden. Meist wird eine vergessen.
- Das Diagramm wird breiter, ohne mehr auszusagen. Wer es liest, sieht viermal dasselbe.
- Niemand traut sich mehr, den Prozess anzufassen, weil unklar ist, welcher Zweig wofür da ist.
Der Prozess funktioniert dabei die ganze Zeit. Er wird nur mit jeder Änderung teurer. Genau deshalb fällt das Problem oft erst Monate später auf, wenn jemand anderes den Prozess anpassen soll.
Woran du erkennst, dass du einen Loop brauchst
Ein Loop ist die richtige Wahl, wenn du eine dieser Formulierungen benutzt, während du den Prozess beschreibst:
- „für jede Position …"
- „für jedes Gerät …"
- „für jeden Standort …"
- „so lange, bis alle bestätigt haben"
- „und das Ganze noch mal für …"
Das Gegenstück: Wenn der Prozess an einer Stelle *einmal* zurückspringt – etwa nach einer Ablehnung zurück in die Überarbeitung – ist das keine Wiederholung über eine Liste, sondern eine Rückführung über ein Gateway. Beides sieht im Diagramm ähnlich aus und ist fachlich etwas anderes.
Kopierte Zweige gegen Loop im Vergleich
| Kopierte Zweige | Loop |
|---|
| Änderung der Logik | an jeder Kopie einzeln | an einer Stelle |
| Neues Element (z. B. sechstes Gerät) | Modell muss erweitert werden | Liste wird länger, Modell bleibt gleich |
| Lesbarkeit | wächst mit jeder Wiederholung | bleibt konstant |
| Fehlerquelle | vergessene Kopie, abweichende Frist | falsch befüllte Liste |
| Anzahl im Voraus bekannt? | muss bekannt sein | kann zur Laufzeit variieren |
Der letzte Punkt ist der entscheidende. Wie viele Geräte ein neuer Mitarbeiter bekommt, steht beim Modellieren nicht fest, sondern beim Start der Prozessinstanz. Genau dafür ist ein Loop gebaut.
Onboarding ist der Prozess, an dem sich das am besten zeigen lässt. Er betrifft mehrere Abteilungen, hat einen klaren Auslöser und enthält mindestens eine Wiederholung: die Ausstattung.
Das Problem kennt jedes Unternehmen: Neue Mitarbeitende warten Tage auf IT-Zugänge, Hardware oder einen Plan für die ersten Wochen. Nicht weil niemand zuständig wäre, sondern weil die Aufgaben per Mail verteilt werden und niemand den Überblick hat, welche davon schon erledigt sind.
So sieht ein Loop in FireStart aus
Der Prozess startet mit einem Formular. Danach läuft er so ab:
1. Abteilung bestimmen. Ein Gateway entscheidet, ob es sich um eine IT-Rolle oder eine Standardausstattung handelt.
2. Ausstattung freigeben. Je nach Ergebnis geht die Freigabe an das IT-Team oder an das Office-Team – als echte Aufgabe mit Zuständigkeit, nicht als Mail.
3. Mitarbeiter anlegen. Der Stammdatensatz wird automatisch erzeugt.
4. Willkommenstext generieren und Mailinhalt aufbereiten. Die Begrüßung wird aus den Daten des Prozesses zusammengesetzt.
5. Loop „Pro Gerät". Hier beginnt die Wiederholung: Für jedes freigegebene Gerät wird eine Zeile in die Geräteliste geschrieben. Ein Gerät, drei Geräte oder sieben – der Prozess bleibt derselbe.
6. Willkommensmail senden. Erst wenn der Loop komplett durchgelaufen ist, geht die Mail raus. Mit vollständiger Geräteliste, nicht mit einer halben.
Onboarding-Prozess in FireStart: Nach der Ausstattungsfreigabe läuft der Loop ‚Pro Gerät' und schreibt für jedes Gerät eine Zeile in die Geräteliste.
Im Diagramm ist der Loop als eigener Block sichtbar, mit Start und „Loop Ende". Wer den Prozess liest, sieht auf einen Blick, welcher Teil wiederholt wird und welcher einmal läuft.
Woher die Liste kommt
Ein Loop braucht etwas, worüber er läuft. In FireStart kann diese Liste aus unterschiedlichen Quellen kommen, je nachdem, was im Unternehmen schon vorhanden ist:
- aus dem Formular, über das der Prozess gestartet wurde,
- aus einem HR-System wie Personio,
- aus einer Tabelle, in der die Ausstattungspakete hinterlegt sind.
Das ist der praktische Vorteil: Wenn ein neues Gerät ins Standardpaket kommt, ändert jemand die Liste. Der Prozess selbst wird nicht angefasst.
Eine Wiederholung ist erst dann sauber automatisiert, wenn auch der Fall abgedeckt ist, dass jemand nicht reagiert. Sonst hängt der Prozess an genau einer offenen Aufgabe – und niemand merkt es, bis der neue Kollege am ersten Tag ohne Laptop dasteht.
In FireStart werden Erinnerungen und Eskalationen je Prozess konfiguriert: Wann erinnert das System, wie oft, und an wen geht die Aufgabe, wenn weiterhin nichts passiert. Die Benachrichtigung läuft über die Kanäle, die im Unternehmen ohnehin verwendet werden – etwa Microsoft Teams oder Outlook. Die Empfänger müssen sich also in kein zusätzliches System einloggen, um zu sehen, dass etwas offen ist.
Damit verschiebt sich die Verantwortung: Nicht mehr der Prozessverantwortliche muss nachfragen, wo es hakt. Der Prozess meldet sich selbst.
Ein Loop, der nur im Diagramm existiert, ist eine Absichtserklärung. Was tatsächlich passiert, entscheidet sich danach in der Praxis – und weicht mit der Zeit immer weiter vom Modell ab.
In FireStart ist das Modell der Prozess. Der Loop, den du im Diagramm siehst, ist derselbe, der ausgeführt wird. Das hat zwei Konsequenzen: Die Dokumentation kann nicht veralten, und jede Wiederholung erzeugt ihren eigenen Eintrag im Audit-Trail – mit Zeitstempel, Benutzer und Ergebnis. Bei einem Audit ist damit nachweisbar, dass für jedes Gerät tatsächlich ein Schritt stattgefunden hat.
Wann du keinen Loop verwenden solltest
Loops lösen nicht jede Wiederholung. Drei Fälle, in denen etwas anderes besser passt:
- Jede Wiederholung läuft anders ab. Wenn sich die Schritte pro Element stark unterscheiden, ist es kein Loop, sondern sind es verschiedene Prozesse mit gleichem Auslöser.
- Es geht um sehr große Datenmengen. Für Massenverarbeitung ist ein Prozess mit Aufgaben und Freigaben nicht das richtige Werkzeug. Das gehört in eine Verarbeitung im Hintergrund.
- Die Wiederholung ist eigentlich eine Rückfrage. „Zurück an den Antragsteller, bis die Unterlagen vollständig sind" ist eine Rückführung über ein Gateway, kein Loop über eine Liste.
Was das bringt
Bei Onboarding-Prozessen weist FireStart auf der Use-Case-Seite folgende Praxiswerte aus: einen fünffachen Return on Invest, 85 Prozent weniger manuellen Aufwand und Hardware sowie Software, die zum ersten Arbeitstag zu 100 Prozent bereitstehen.
Der Loop ist dabei nicht der Grund für diese Zahlen. Er ist die Voraussetzung dafür, dass der Prozess auch dann stabil bleibt, wenn sich die Ausstattung ändert, eine Abteilung dazukommt oder aus drei Geräten sieben werden.
Was ist ein Loop in einem Prozess?
Ein Loop ist ein Prozessabschnitt, der für jedes Element einer Liste einmal durchlaufen wird – etwa für jedes Gerät, jede Rechnungsposition oder jeden Standort. Der Ablauf wird einmal modelliert und mehrfach ausgeführt.
Was ist der Unterschied zwischen einem Loop und einer Verzweigung?
Eine Verzweigung über ein Gateway entscheidet, welcher Weg genommen wird. Ein Loop wiederholt denselben Weg für mehrere Elemente. Eine Rückführung nach einer Ablehnung ist eine Verzweigung, keine Wiederholung über eine Liste.
Muss ich vorher wissen, wie oft ein Loop durchläuft?
Nein. Die Anzahl ergibt sich zur Laufzeit aus der Liste, über die der Loop läuft. Genau darin liegt der Unterschied zu kopierten Prozesszweigen, bei denen die Anzahl beim Modellieren feststehen muss.
Woher kommen die Daten, über die ein Loop läuft?
Aus dem Startformular, aus einem angebundenen System wie Personio oder aus einer Tabelle. Ändert sich die Liste, ändert sich der Prozess nicht.
Wie wird verhindert, dass eine Aufgabe im Loop liegen bleibt?
Über Erinnerungen und Eskalationen, die je Prozess konfiguriert werden: Das System erinnert nach einer definierten Zeit und gibt die Aufgabe weiter, wenn weiterhin nichts passiert. Benachrichtigt wird über die gewohnten Kanäle wie Microsoft Teams oder Outlook.
Sind Loops Teil des BPMN-Standards?
Ja. BPMN 2.0 kennt Wiederholungen als eigenes Konstrukt, sowohl für Aufgaben als auch für Teilprozesse. Deshalb bleibt ein Modell mit Loops portabel und lesbar für alle, die den Standard kennen.
Wann ist ein Loop die falsche Lösung?
Wenn jede Wiederholung anders abläuft, wenn sehr große Datenmengen verarbeitet werden oder wenn es sich in Wahrheit um eine Rückfrage an den Antragsteller handelt.
Prozesse mit Wiederholungen sauber bauen
Wenn du wissen willst, wie ein solcher Prozess in deinem Unternehmen aussehen würde: Wir zeigen es dir an einem deiner eigenen Abläufe.
Demo vereinbaren
FireStart wird in der EU gehostet (DSGVO-konform, EU-Datenspeicherung). Website: www.firestart.com. Kontakt: sales@firestart.com.
