Einführung
In der Welt des Business Process Managements besteht ständig ein Spannungsverhältnis zwischen Klarheit und Detailgenauigkeit. Stakeholder wünschen sich Übersichten auf hoher Ebene, die auf einer einzigen Folie Platz finden, während operative Teams detaillierte Anweisungen benötigen, um Aufgaben ohne Zweideutigkeit auszuführen. Jahrelang habe ich beobachtet, wie Organisationen mit diesem Gleichgewicht kämpfen, was oft zu umfangreichen, unlesbaren Diagrammen führt, die weder der einen noch der anderen Zielgruppe gerecht werden.
Kürzlich hatte ich die Gelegenheit, tief in eine Fallstudie einzusteigen, die die Personalabteilung einer mittelgroßen bis großen Organisation betraf. Sie stand vor einem klassischen Skalierungsproblem: Wie man eine hohe Anzahl an Stellenbewerbungen mit mehrstufigen Bewertungskriterien verwalten kann, ohne ein unübersichtliches Chaos zu erzeugen. Die Lösung, die sie umgesetzt haben, nutzt eine der leistungsstärksten, aber untergenutzten Funktionen von BPMN 2.0:Eingebettete Unterprozesse.
Dieser Leitfaden teilt meine Erfahrungen bei der Bewertung ihres Ansatzes und erläutert, warum die Trennung zwischen „Aufgaben“ und „Unterprozessen“ nicht nur eine visuelle Entscheidung ist, sondern eine architektonische Notwendigkeit für skalierbare Workflows. Unabhängig davon, ob Sie ein Business Analyst, HR-Operations-Manager oder Prozessarchitekt sind, bietet diese Bewertung praktische Erkenntnisse zur Modellierung komplexer Entscheidungslogik, während die Lesbarkeit für Führungskräfte gewahrt bleibt.
1. Das Problem: Wenn die Einstellung kompliziert wird
Die betreffende HR-Abteilung stand vor mehreren kritischen Herausforderungen:
-
Hohe Volumina:Hunderte Bewerbungen erforderten eine systematische Prüfung.
-
Mehrschichtige Kriterien:Kandidaten benötigten sowohl formelle Qualifikationsprüfungen (Abschlüsse, Zertifikate) als auch Bewertungen der Stellenpassung.
-
Entscheidungskomplexität:Ein Kandidat könnte die beworbene Stelle nicht passen, aber für eine andere offene Position ideal sein.
-
Nachvollziehbarkeit:Manager benötigten klare Sichtbarkeit inwarumeine Bewerbung akzeptiert oder abgelehnt wurde.
-
Skalierbarkeit:Mit dem Wachstum des Unternehmens wurden flache Diagramme zu komplex, um sie aufrechtzuerhalten.
Die zentrale geschäftliche Frage lautete:„Wie modellieren wir einen Einstellungsworkflow, der sowohl auf hoher Ebene für Führungskräfte verständlich ist, die ihn auf einen Blick erfassen können, als auch ausreichend detailliert für HR-Analysten, um ihn konsistent umzusetzen?“
Die Antwort lag in der hierarchischen Modellierung.
2. Konzeptionelle Grundlage: Aufgaben versus Unterprozesse
Bevor man sich die Diagramme ansieht, ist es entscheidend, die Unterscheidung zwischen einemAufgabeund einemUnterprozess. Dies ist die Grundlage für sauberes BPMN-Modellieren.
| Funktion | Aufgabe | Unterprozess |
|---|---|---|
| Definition | Eine atomare Einheit der Arbeit; in dem aktuellen Modell nicht weiter unterteilt. | Eine zusammengesetzte Aktivität, die ihren eigenen internen Ablauf aus Aufgaben, Gateways und Ereignissen enthält. |
| Notation | Abgerundetes Rechteck. | Abgerundetes Rechteck mit einem + Symbol in der Mitte unten. |
| Erweiterbarkeit | Kann später unterteilt werden, wird hier aber als atomar behandelt. | Enthält bereits einen detaillierten Kindprozess. |
| Token-Verhalten | Token tritt ein → Arbeit erledigt → Token verlässt. | Token löst Start des Unterprozesses aus → fließt durch Kindprozess → erreicht Endereignis → Token wird an Elternprozess weitergegeben. |
| Zweck | Einfachheit, Abstraktion. | Kapselung komplexer Logik. |
Wichtiger Hinweis: Modellierung von „Antrag einreichen“ als Aufgabe bedeutet nicht dass es nicht unterteilt werden kann. Es bedeutet lediglich, dass die Unterteilung bisher nicht erfolgt ist in diesem speziellen Modell. Dies ist eine Modellierungsentscheidung, keine dauerhafte Beschränkung.
Gateways in BPMN steuern basierend auf Bedingungen, wie Sequenzflüsse sich verzweigen oder vereinen, und fungieren als Entscheidungspunkte innerhalb sowohl Elternprozesse als auch Unterprozesse.
3. Diagrammerklärung: Der Elternprozess
Die erste Ebene des Modells ist für Führungskräfte konzipiert. Sie bietet einen Überblick über den Einstellungsablauf, ohne sich in die spezifischen Kriterien der Prüfung zu verlieren.
Abbildung: Elternprozess — Prozess mit Unterprozess „Antrag prüfen“
(Hinweis: Im ursprünglichen Kontext zeigt dieses Diagramm den übergeordneten Ablauf. Stellen Sie sich ein Startereignis vor, das zu „Antrag eingeben“ führt, dann zu „Antrag prüfen ⊕“, gefolgt von einem Gateway, das sich in „Zum Vorstellungsgespräch einladen“ oder „Antrag ablehnen“ aufteilt.)
Element-für-Element-Aufschlüsselung
| Element | Typ | Rolle |
|---|---|---|
| ○ (dünner Kreis) | Startereignis | Löst den gesamten Prozess aus, wenn ein Antrag eingereicht wird. |
| [Antrag eingeben] | Aufgabe | Erfasst/protokolliert die Bewerberdaten; auf dieser Ebene atomar. |
| [Antrag prüfen ⊕] | Eingebetteter Unterprozess | Enthält die vollständige mehrstufige Bewertungslogik; mit „+“ markiert. |
| ◇ (Diamant) | Exklusiver Gateway (XOR) | Leitet den Ablauf basierend auf dem Ergebnis des Unterprozesses weiter: „Positiv“ oder „Negativ“. |
| [Zum Vorstellungsgespräch einladen] | Aufgabe | Wird nur ausgeführt, wenn das Prüfungsergebnis positiv ist. |
| [Antrag ablehnen] | Aufgabe | Wird nur ausgeführt, wenn das Prüfungsergebnis negativ ist. |
| ◎ (dicker Kreis) | Endereignisse | Beenden die jeweiligen Zweige des Prozesses. |
Wichtige Verhaltensregel:
Im übergeordneten Prozess spielt es keine RollewelchesEndereignis im Unterprozess erreicht wurde. Entscheidend ist, dass der Unterprozess abgeschlossen istvollständig abgeschlossen bevor ein Token an den ausgehenden Sequenzfluss weitergegeben wird. Das Gateway bewertet dann die Daten von der Unterprozess erzeugt (z. B. ein Attribut namens "result" mit Werten "positiv" oder "negativ") zur Bestimmung des Routing-Pfads.
4. Diagrammerklärung: Der Kindprozess
Für HR-Analysten, die die Überprüfung konsistent durchführen müssen, wird der Unterprozess erweitert. Dadurch wird die detaillierte Logik sichtbar, die hinter dem „+“-Symbol verborgen ist.
Abbildung: Kindprozess — Unterprozess „Bewerbung prüfen“ (erweiterte Ansicht)
(Hinweis: Im ursprünglichen Kontext zeigt dieses Diagramm die interne Logik. Stellen Sie sich ein Startereignis vor, das zu „Formale Qualifikation prüfen“ führt, danach ein Gateway. Wenn OK, geht es zu „Prüfen, ob Bewerber zur Position passt“. Wenn nicht, kann es zu „Prüfen, ob Bewerber zu einer anderen offenen Position passt“ führen. Alle Pfade münden entweder in ein „Positives Ergebnis“- oder ein „Negatives Ergebnis“-Endereignis.)
Element-für-Element-Aufschlüsselung
| Element | Typ | Rolle |
|---|---|---|
| ○ (dünner Kreis) | Startereignis | Wird automatisch ausgelöst, wenn das Token des übergeordneten Prozesses eintrifft. |
| [Formale Qualifikation prüfen] | Aufgabe | Erster Bewertungsschritt: Überprüft Abschlüsse, Zertifikate und Erfahrungsschwellenwerte. |
| ◇ Gateway #1 | Exklusives Gateway | Entscheidung: Ist die formale Qualifikation OK oder NICHT OK? |
| [Prüfen, ob Bewerber zur Position passt] | Aufgabe | Zweiter Bewertungsschritt: Beurteilt die Übereinstimmung von Fähigkeiten/Erfahrung mit der spezifischen Rolle. |
| ◇ Gateway #2 | Exklusiver Gateway | Entscheidung: Passt der Bewerber auf die beworbene Stelle? |
| [Prüfen, ob der Bewerber auf eine andere offene Stelle passt] | Aufgabe | Dritte Bewertung (Fallback): Sucht nach einer möglichen Übereinstimmung in anderen offenen Positionen. |
| ◇ Gateway #3 | Exklusiver Gateway | Entscheidung: Passt der Bewerber auf irgendeine andere offene Stelle? |
| ◎ Positives Ergebnis | Ende-Ereignis | Signalisiert erfolgreiche Prüfung; setzt result = "positiv". |
| ◎ Negatives Ergebnis | Ende-Ereignis | Signalisiert gescheiterte Prüfung; setzt result = "negativ". |
Token-Flusslogik
-
Ein Token kommt vom Elternprozess → löst das Startereignis des Unterprozesses aus.
-
Das Token fließt durch Überprüfung der formellen Qualifikation.
-
Wenn die Qualifikation fehlschlägt → springt direkt zu Negatives Ergebnis Ende-Ereignis.
-
Wenn die Qualifikation gelingt → geht weiter zu Prüfen, ob der Bewerber auf die Position passt.
-
Wenn passt → geht zu Positives Ergebnis Ende-Ereignis.
-
Wenn nicht passt → versucht Überprüfen, ob der Bewerber eine andere offene Stelle erfüllt.
-
Wenn passt eine andere → Positives Ergebnis; wenn nicht → Negatives Ergebnis.
-
Sobald ein Endereignis erreicht wird, ist der Unterprozess abgeschlossen, und ein Token wird zurück an den ausgehenden Fluss des übergeordneten Prozesses gesendet.
5. Interpretation und Datenfluss-Semantik
Dies ist der feinste Aspekt der Fallstudie. In der BPMN-Syntax besteht ein scheinbarer Widerspruch:
„Gemäß der BPMN-Syntax besteht keine direkte Beziehung zwischen den verschiedenen Endereignissen innerhalb eines Unterprozesses und den Bedingungen am Entscheidungsgateway im höheren Prozess.“
In strengen BPMN-Begriffen kann das übergeordnete Gateway „sehen“ welches Endereignis im Unterprozess erreicht wurde. Wie weiß der übergeordnete Prozess dann, ob er zu „Zum Vorstellungsgespräch einladen“ oder „Bewerbung ablehnen“ geht?
Die Lösung: Datenattribute
Die korrekte Interpretation ist, dass der Unterprozess Daten. Speziell wird ein Prozessattribut namens "result" erhält den Wert "positiv" oder "negativ" je nachdem, welcher interne Pfad eingeschlagen wurde. Da alle Daten innerhalb eines Prozesses überall verfügbar sind, einschließlich innerhalb eingebetteter Unterprozesse und zurück im übergeordneten Prozess, bewerten die Gateway-Bedingungen im übergeordneten Prozess einfach dieses Attribut:
-
Bedingung:
result == "positiv"→ Weiterleitung zu „Zum Vorstellungsgespräch einladen“ -
Bedingung:
result == "negativ"→ Weiterleitung zu „Bewerbung ablehnen“
Ebenso können Gateways innerhalb des Unterprozesses ebenfalls lesen und schreiben"result" Attribut.
Warum dies praktisch von Bedeutung ist
Dieses Muster stellt sicher:
-
✅ Schwache Kopplung zwischen Eltern- und Kindprozesslogik.
-
✅ Wiederverwendbarkeit: Der Unterprozess „Bewerbung prüfen“ könnte von mehreren Elternprozessen aufgerufen werden.
-
✅ Wartbarkeit: Änderungen an den Prüfkriterien erfordern nur die Bearbeitung des Kindprozesses, nicht des Elternprozesses.
-
✅ Compliance: Jeder Entscheidungspunkt ist auditierbar mit klaren Datenverläufen.
6. Wann Sub-Prozesse gegenüber Aufgaben verwendet werden sollten
Basierend auf diesem Fallbeispiel und BPMN-Best-Practices, hier ein Entscheidungsrahmen für Ihre eigenen Modellierungsarbeiten.
✅ Verwenden Sie einen Unterprozess, wenn:
| Szenario | Beispiel aus dem Fallbeispiel |
|---|---|
| Komplexe interne Logik mit mehreren Entscheidungspunkten | „Bewerbung prüfen“ verfügt intern über 3 Gateways und 4 Aufgaben. |
| Wiederverwendbarer Prozessabschnitt in mehreren übergeordneten Prozessen verwendet | Die gleiche Überprüfungslogik könnte auf interne Versetzungen, Beförderungen usw. angewendet werden. |
| Grenzen der Teamverantwortung | HR Operations ist verantwortlich für „Bewerbung prüfen“; Rekrutierung ist verantwortlich für „Einladung zum Vorstellungsgespräch“. |
| Lesbarkeit des Diagramms | Die Kombination beider Abbildungen in einer würde zu 8+ Knoten führen und schwer lesbar werden. |
| Bedarf an hierarchischer Berichterstattung | Führungskräfte betrachten die übergeordnete Ebene; HR-Analysten arbeiten mit der untergeordneten Ebene. |
| Unabhängige Lebenszyklusverwaltung | Die Überprüfungs-Kriterien ändern sich quartalsweise; die Logik für die Terminplanung im Vorstellungsgespräch ändert sich jährlich. |
Best Practice empfiehlt die Erstellung hierarchischer Mehrschichten-Prozessmodelle und die Verwendung von Unterprozessen, um Prozesse in logische Phasen zu unterteilen.
✅ Verwenden Sie eine Aufgabe, wenn:
| Szenario | Beispiel aus der Fallstudie |
|---|---|
| Atomare, nicht teilbare Arbeit im aktuellen Modellierungsrahmen | „Bewerbung eingeben“ ist eine einzelne Formular-Eingabe-Aktion. |
| Einfachheit reicht aus — keine interne Verzweigung erforderlich | „Einladung zum Vorstellungsgespräch“ ist eine einfache Benachrichtigungs-/E-Mail-Aufgabe. |
| Zukünftige Erweiterung möglich, aber noch nicht erforderlich | „Bewerbung eingeben“ könnte später erweitert werden, um Dokumenten-Upload, Validierung usw. einzuschließen. |
| Aufruf eines externen Systems als eine einzelne Service-Aufgabe dargestellt | Aufruf einer externen ATS-API, um die Bewerbung zu speichern. |
💡 Modellierungsprinzip: Modellieren Sie immer auf der angemessenen Abstraktionsebene für Ihre Zielgruppe. Eine Aufgabe heute kann morgen zu einem Unterprozess werden, wenn sich die Anforderungen entwickeln – das ist eine Funktion, keine Einschränkung.
7. BPMN-Best-Practices demonstriert
Diese Fallstudie hebt mehrere zentrale Best-Practices hervor:
-
Hierarchische Schichtung:Zwei klare Ebenen — strategische Übersicht und operative Details — gemäß der Empfehlung, mehrschichtige Prozessarchitekturen zu erstellen.
-
Konsistente Gateway-Nutzung:Exklusive Gateways korrekt verwendet für wechselseitig ausschließliche Entscheidungspfade an jedem Verzweigungspunkt.
-
Klare Beschriftung:Jeder Ablauffluss aus einem Gateway ist mit seiner Bedingung beschriftet („Positives Ergebnis“, „Formale Qualifikation in Ordnung“, usw.) — eine anerkannte Best-Practice-Regel für Lesbarkeit.
-
Eintrittspunkt, kontrollierter Austritt:Der Unterprozess verfügt über ein Startereignis und genau zwei Endereignisse, wodurch sein Vertrag mit dem übergeordneten Prozess eindeutig definiert ist.
-
Datengesteuerte Entscheidungsfindung:Anstatt sich auf implizite Token-Routing zu verlassen, werden explizite Datenattribute („result“) zur Steuerung der Gateway-Bedingungen verwendet — was Nachvollziehbarkeit und Testbarkeit verbessert.
-
Einhaltung der Standard-Symbolik:Alle Elemente verwenden die korrekte BPMN 2.0-Notation, was die Interoperabilität über verschiedene Modellierungswerkzeuge hinweg sichert.
8. Zusammenfassungstabelle
| Aspekt | Detail |
|---|---|
| Bereich | Personalwesen / Personalrekrutierung |
| Prozessname | Bewerbungsprüfung und Entscheidung zum Vorstellungsgespräch |
| BPMN-Muster | Eingebetteter Unterprozess mit datengesteuerter Gateway-Routing-Logik |
| Knoten des übergeordneten Prozesses | 1 Start, 2 Aufgaben, 1 Unterprozess, 1 Gateway, 2 Endereignisse |
| Knoten des Unterprozesses | 1 Start, 3 Aufgaben, 3 Gateways, 2 Endereignisse |
| Wichtiger Datenattribut | result ∈ {„positiv“, „negativ“} |
| Hauptvorteil | Trennung der Anliegen; skalierbarer, wartbarer, nachvollziehbarer Prozessmodell |
| Anwendbarer Standard | BPMN 2.0 (ISO/IEC 19510) |
9. Erweiterungen & Variationen
Dieses Fallbeispiel kann in mehrere Richtungen erweitert werden, um komplexere Szenarien zu behandeln:
-
Aufruf-Aktivität:Ersetzen Sie den eingebetteten Unterprozess durch eine wiederverwendbare Aufruf-Aktivität (globaler Unterprozess), falls „Bewerbung prüfen“ über mehrere Einstellungsabläufe hinweg geteilt wird.
-
Ereignis-Unterprozess:Fügen Sie einen unterbrechenden Timer-Ereignis-Unterprozess hinzu, um Bewerbungen automatisch abzulehnen, wenn sie 30 Tage inaktiv sind.
-
Nachrichtenereignisse:Ersetzen Sie das Startereignis durch ein Nachrichten-Startereignis, um den Prozess per E-Mail oder API auszulösen.
-
Mehrfachinstanz-Unterprozess:Wenn mehrere Prüfer die gleiche Bewerbung unabhängig voneinander bewerten müssen, modellieren Sie „Bewerbung prüfen“ als Mehrfachinstanz-Unterprozess mit paralleler Ausführung.
-
Kompensation:Fügen Sie Kompensationshandler hinzu, um „Einladung zum Vorstellungsgespräch“ rückgängig zu machen, falls eine nachfolgende Hintergrundüberprüfung fehlschlägt.
Fazit
Dieses Fallbeispiel zeigt, dass BPMN-Unterprozesse nicht nur eine visuelle Bequemlichkeit sind – sie sind ein fundamentales architektonisches Mittelzur Bewältigung der Komplexität in Geschäftsprozessmodellen. Durch die Einbindung der mehrstufigen Logik „Bewerbung prüfen“ innerhalb eines Unterprozesses erreicht die Organisation Klarheit auf Führungsebene, während gleichzeitig analytische Tiefe auf operativer Ebene erhalten bleibt, alles über gut definierte Datenverträge verbunden, anstatt über fragile implizite Abhängigkeiten.
Für alle, die ähnliche Abläufe umsetzen möchten, bieten Werkzeuge wie Visual Paradigmbieten eine robuste Unterstützung für diese Muster. Mit Funktionen wie künstlicher Intelligenz-gesteuerter Diagrammerstellung, Prozesssimulation und Team-Kooperationsmöglichkeiten vereinfacht es die Erstellung von standardskonformen BPMN 2.0-Modellen. Unabhängig davon, ob Sie „Aktuell“-Prozesse abbilden oder „Zukünftig“-Verbesserungen gestalten, sorgt die Nutzung hierarchischer Modellierung dafür, dass Ihre Prozesse skalierbar, wartbar und für alle Beteiligten klar bleiben.
Referenzen
- Visual Paradigm Funktionen: Visual Paradigm bietet eine vollständig umfassende, standardskonforme BPMN 2.0-Modellierungsplattform, die speziell für Business Analysten und Entwickler entwickelt wurde und traditionelle Diagrammierung mit fortschrittlicher Automatisierung und Simulation verbindet.
- BP-Modellierungs-Lösung: Bietet intelligente Verbindungsregeln, flexible Swimlane-Editierung und ressourcenorientierte Modellierung, um operative Abläufe zu optimieren und ungültige Ablaufpfade zu vermeiden.
- AI-BPMN-Generator-Leitfaden: Erläutert, wie der AI-BPMN-Diagramm-Generator prosaische englische Prozessbeschreibungen automatisch in voll interaktive, standardskonforme BPMN 2.0-Layouts übersetzt.
- BPMN einfach gemacht: Zeigt Werkzeuge zur Vereinfachung der BPMN-Modellierung auf, einschließlich Prozessanimation und Gap-Analyse für nicht-technische Stakeholder.
- BPMN-Tutorial 1: Bietet grundlegende Tutorials zu BPMN-Notationen, einschließlich Ereignisse, spezialisierte Aufgabentypen, Gateways und Datenobjekte.
- BPMN-Tutorial-PDF: Eine herunterladbare PDF-Version des grundlegenden BPMN-Tutorials zur Offline-Nutzung.
- BPMN-Aktivitätstypen erklärt: Detaillierter Leitfaden zu verschiedenen BPMN-Aktivitätstypen, der Benutzern hilft, zwischen Service-, Benutzer-, Manueller und Skript-Aufgaben zu wählen.
- Visual Paradigm YouTube-Demo: Video-Demonstration der Funktionen von Visual Paradigm, einschließlich der Swimlane-Editierung und Prozess-Drill-Down-Funktionen.
- SysML-Modellierungsleitfaden: Diskutiert ressourcenorientierte Modellierung, bei der Elemente als wiederverwendbare Modellkomponenten anstelle statischer Formen erstellt werden.
- BPMN-Schwimmlinien-Tutorial: Konzentriert sich auf die Aufteilung von Prozessen mithilfe interaktiver horizontaler oder vertikaler Pools und Lagen.
- Überblick über BPMN-Diagramm-Tools: Betont erneut das umfassende Funktionsangebot für BPMN-Diagramme, einschließlich vollständiger Notationssupport und KI-Integration.
- Visual Paradigm Blog: Diskutiert Visual Paradigm als All-in-One-Software-Lösung und betont dessen Rolle bei der Softwareentwicklung und Prozessmodellierung.
- Leitfaden zur Geschäftsprozessmodellierung: Behandelt bewährte Praktiken für die Geschäftsprozessmodellierung, einschließlich As-Is- und To-Be-Gap-Analyse.
- Liste der BPMN-Funktionen: Listet Schlüsselfunktionen wie Prozesssimulation, Animation und Matrixtransformation für RACI/CRUD-Ausgaben auf.
- Visual-Diff-Funktion: Erklärt das Versionsvergleichstool, das Betriebsänderungen verfolgt, indem verschiedene Workflow-Versionen visuell verglichen werden.
- REST-API-Design-Lösung: Hebt agile Integrationsfunktionen hervor, die Workflow-Komponenten in Nutzerstories und Entwicklungsbacklogs synchronisiert.