Was sind Teilprozesse und warum vereinfachen sie komplexe Workflows

Je größer Prozesse werden, desto unübersichtlicher wird das Diagramm: eine Wand aus Kästchen, die niemand gern öffnet. Das kennen Sie vielleicht. Eine Onboarding-Map, die vierzig Aktivitäten über drei Bildschirme verteilt. Ein Bestellprozess, der nicht auf eine gedruckte Seite passt. Ein Freigabeverfahren, das so dicht ist, dass es neue Mitarbeitende eher abschreckt als unterstützt.

Teilprozesse lösen dieses Problem: Sie bündeln eine Gruppe von Aktivitäten in einem einzigen Diagrammelement, das geschlossen bleibt, bis man in die Details einsteigen muss. Die Übersicht bleibt lesbar, ohne dass Informationen verloren gehen.

In diesem Artikel sehen wir uns an, was ein Teilprozess ist, wie dieselbe Schrittfolge aus mehreren Modellen aufgerufen werden kann, wann es sinnvoll ist, einen Ablauf aufzuteilen, wie tief Teilprozesse verschachtelt werden sollten und welchen konkreten Nutzen sie für Lesbarkeit, Wiederverwendung, Wartung und Delegation bringen. Wer Prozesse modelliert, auch nur auf einem Whiteboard, spart mit der konsequenten Nutzung von Teilprozessen mehr Zeit als mit fast jeder anderen Technik.

Was ist ein Teilprozess?

Ein Teilprozess ist eine Aktivität, die eine eigene Abfolge von Schritten enthält. In der BPMN-Notation wird er als abgerundetes Rechteck mit einem kleinen „+“ am unteren Rand dargestellt: ein Hinweis darauf, dass hier noch mehr drinsteckt. Der übergeordnete Prozess behandelt ihn wie einen einzigen Schritt; im Inneren ist der Teilprozess ein vollständiger Mini-Prozess mit eigenem Start, eigenen Aktivitäten, Entscheidungen und einem eigenen Ende.

Der einfachste Vergleich ist ein Ordner in einem Dateisystem. Das Diagramm auf oberster Ebene zeigt den Namen des Ordners; wenn Sie ihn öffnen, sehen Sie seinen Inhalt. Sie entscheiden selbst, wann Sie ihn öffnen und wann Sie ihn geschlossen lassen, je nachdem, worüber gerade gesprochen wird.

Es gibt jedoch einen wichtigen Unterschied zu einem Ordner: Der Inhalt des Teilprozesses ist nicht im übergeordneten Prozess eingeschlossen. Der Teilprozess ist ein eigenständiges Modell, das vom übergeordneten Prozess aufgerufen wird. In der BPMN-Terminologie heißt diese Form Call Activity. Genau dadurch kann derselbe Teilprozess in vielen unterschiedlichen Prozessen verwendet werden, ohne ein einziges Mal kopiert zu werden.

Die Details existieren also nur an einer Stelle, und jeder Prozess, der sie aufruft, sieht immer die aktuelle Version.

Eine Ebene nach der anderen

Im übergeordneten Diagramm bleibt der Teilprozess als geschlossenes Element bestehen. Das „+“-Symbol zeigt an, dass darunter eine weitere Ebene liegt. Um den Inhalt zu sehen, öffnen Sie das Element und arbeiten in seinem eigenen Diagramm; für die Übersicht wechseln Sie wieder eine Ebene nach oben.

Das ist nicht nur ein technisches Detail, sondern ein Kommunikationswerkzeug. Die oberste Ebene ist für Menschen gedacht, die verstehen müssen, welche Hauptphasen es gibt und wie sie zusammenhängen: etwa in einem Abstimmungstermin, für eine Führungskraft, die den Prozess gerade übernommen hat, oder für einen Kunden, dem Sie Ihre Arbeitsweise erklären. Die darunterliegende Ebene ist für diejenigen gedacht, die diesen Teil des Prozesses tatsächlich ausführen.

Die Regel lässt sich als „eine Zoomstufe pro Gespräch“ zusammenfassen: Dasselbe Modell kann sowohl in einer Managementrunde als auch am Arbeitsplatz der ausführenden Person verwendet werden, ohne dass etwas neu gezeichnet werden muss.

Der häufigste Fehler besteht darin, aus Angst vor Unklarheit zu viele Details auf die oberste Ebene zu bringen. Das Ergebnis ist wieder die Wand aus Kästchen, mit der wir begonnen haben. Der gegenteilige Fehler besteht darin, alles hinter vagen Bezeichnungen zu verstecken und so eine Kette rätselhafter Kästen zu erzeugen, die niemand sinnvoll prüfen kann. Das Gleichgewicht liegt in der Benennung: Ein geschlossener Teilprozess mit dem Namen „Lieferantendokumente prüfen“ kommuniziert mehr als zehn aufgeklappte Kästchen.

Warum Teilprozesse verwenden?

1. Lesbarkeit: Die Übersicht bleibt klar

Ein Prozess auf oberster Ebene sollte auf einen Bildschirm passen und genau eine Frage beantworten: Was sind die wichtigsten Phasen? Beispiele für gesunde Top-Level-Strukturen sind:

• Eingang, Prüfung, Entscheidung, Abschluss
• Bestellung, Abwicklung, Fakturierung, Support
• Anfrage, Aktivierung, Schulung, Bestätigung

Jede Phase wird, wenn sie komplex ist, zu einem Teilprozess, in den man bei Bedarf hineinzoomen kann. Wer an einer Managementbesprechung teilnimmt, sieht die vier Phasen und die Entscheidungen, die sie miteinander verbinden. Der Analyst, der die Bestellabwicklung verbessert, öffnet nur diesen Teilprozess und ignoriert den Rest. Dasselbe Modell, zwei Lesestufen, kein Neuzeichnen.

Ohne Teilprozesse müssen Management und Analyst denselben Vierzig-Kästchen-Monsterprozess lesen. Und beide geben irgendwann auf.

2. Wiederverwendbarkeit: Einmal ändern, überall aktualisieren

Derselbe Teilprozess, zum Beispiel „Freigabe durch Vorgesetzten“, kann in vielen Prozessen vorkommen: Reisekosten, Bestellungen, Urlaubsanträge, Vertragsfreigaben. Wenn sich die Freigaberegeln ändern, etwa durch einen neuen Betragsgrenzwert oder eine zusätzliche Genehmigungsstufe, aktualisieren Sie die Definition nur einmal. Jeder Prozess, der sie aufruft, übernimmt die Änderung automatisch.

Das ist der Unterschied zwischen einer Prozessbibliothek und einem Stapel einzelner Diagramme. Organisationen mit einer ausgereiften BPM-Praxis behandeln gemeinsame Schritte als wiederverwendbare Bausteine, genau wie eine Codebibliothek eine Funktion. Wie das mit der Automatisierungsebene zusammenhängt, die diese Schritte ausführt, lesen Sie in Process Automation vs. Task Automation.

3. Wartung: Kleinere Diagramme lassen sich sicherer ändern

Eine einzige riesige Prozesskarte ist fragil. Ein versehentlich verschobener Konnektor kann den gesamten Ablauf neu verdrahten, und niemand kann das gesamte Modell gleichzeitig im Kopf behalten. Kleinere, fokussierte Diagramme lassen sich leichter ändern und sind weniger fehleranfällig. Wenn die Änderung lokal ist, etwa „passen wir die Schritte der IT-Aktivierung an“, öffnen Sie nur einen Teilprozess und nicht die gesamte Unternehmenskarte.

Die Wartungskosten steigen überproportional mit der Größe eines Diagramms. Teilprozesse halten jede bearbeitbare Einheit klein und damit auch die Kosten unter Kontrolle.

4. Delegation: Jedes Team besitzt seinen Teil

Unterschiedliche Teams können unterschiedliche Teilprozesse verantworten. HR besitzt „Voraussetzungen prüfen“, IT besitzt „Konten und Ausstattung aktivieren“, und die Administration besitzt „Lohnabrechnung einrichten“. Jedes Team pflegt seinen eigenen Teilprozess; der Process Owner setzt sie zusammen. Das entspricht der realen Arbeitsteilung in Organisationen und unterstützt verteilte Verantwortlichkeiten: Die Lane-Struktur innerhalb eines Teilprozesses kann die Rollen des jeweiligen Teams abbilden.

Delegation verbessert außerdem die Genauigkeit. Diejenigen, die die Arbeit tatsächlich ausführen, pflegen auch das Modell dieser Arbeit, statt dass ein zentrales Modellierungsteam versucht, für alle zu raten.

Ein konkretes Beispiel: Onboarding eines neuen Mitarbeiters

Hier ist das klassische Onboarding-Beispiel, so aufbereitet, dass die verschiedenen Ebenen klar erkennbar sind.

Oberste Ebene, Onboarding eines neuen Mitarbeiters:

Dokumente sammeln
→ IT-Aktivierung (Teilprozess)
→ Schulung (Teilprozess)
→ 30-Tage-Gespräch

Innerhalb von „IT-Aktivierung“:

E-Mail-Konto anlegen
→ Laptop bestellen
→ Software installieren
→ Lieferung bestätigen

Innerhalb von „Schulung“:

Mentor zuweisen
→ Pflichtschulungen planen
→ Abschlüsse nachverfolgen
→ Abschluss bestätigen

Der Leser sieht zuerst die Übersicht und steigt nur dort tiefer ein, wo es nötig ist. Die Führungskraft des neuen Mitarbeiters bleibt auf der obersten Ebene; der IT-Techniker arbeitet innerhalb von „IT-Aktivierung“. Dasselbe Modell dient beiden, ohne Kompromisse.

Stellen Sie sich die Alternative vor: Alle diese Schritte werden in einem einzigen Diagramm flach dargestellt. Die Führungskraft findet die relevante Phase nicht, während der Techniker sich in der Dokumentensammlung der Personalabteilung verliert. Teilprozesse ermöglichen es, mit einem einzigen Artefakt unterschiedliche Lesergruppen zu bedienen.

Eine Definition, von allen Modellen aufgerufen

Hier liegt der Unterschied zwischen einer Prozessbibliothek und einem Stapel einzelner Diagramme.

Ein Teilprozess ist kein Stück Zeichnung, das in den übergeordneten Prozess kopiert wurde. Er ist ein eigenständiges Modell mit eigenem Namen, Verantwortlichem und Lebenszyklus. Jeder Prozess, der ihn benötigt, ruft ihn auf. Der Unterschied zur Alternative, dieselbe Sequenz in jedes Modell zu kopieren, ist eindeutig:

Faustregel: Wenn Sie feststellen, dass Sie dieselbe Schrittfolge in ein zweites Modell kopieren, stoppen Sie und machen Sie daraus einen wiederverwendbaren Teilprozess. Copy-and-Paste in der Prozessmodellierung ist dieselbe Falle wie Copy-and-Paste im Code: Logik wird dupliziert, und irgendwann vergessen Sie, sie an allen Stellen zu aktualisieren.

Das gilt auch in die andere Richtung, und genau dieser Vorteil wird oft unterschätzt: Wenn Sie „Freigabe durch Vorgesetzten“ wegen eines neuen Betragsgrenzwerts aktualisieren, sind automatisch alle Prozesse, die diesen Teilprozess aufrufen, Reisekosten, Bestellungen, Urlaubsanträge, auf demselben Stand. Sie müssen nicht danach suchen und sich auch nicht daran erinnern, wo die Logik überall kopiert wurde.

Ausnahmen behandeln: der Event Subprocess

Der BPMN-Standard bietet außerdem ein fortgeschritteneres und sehr nützliches Muster: den Event Subprocess. Dabei handelt es sich um einen Teilprozess, der nicht durch den normalen Ablauf aktiviert wird, sondern durch ein Ereignis, zum Beispiel „Kunde storniert die Bestellung“ oder „Systemfehler“. Er wird mit einer gestrichelten Umrandung dargestellt und wartet auf seinen Auslöser. Häufig unterbricht er den Hauptablauf, sobald er ausgelöst wird.

Warum das wichtig ist: Ausnahmen sind die Stellen, an denen Prozesse scheitern. Wenn man sie auf diese Weise modelliert, bleibt der Hauptweg, der sogenannte Happy Path, sauber, während gleichzeitig präzise definiert wird, was bei Problemen passiert: Stornierungen, Fehlerbehandlung, Eskalationen. Zum Ereignisvokabular hinter diesem Muster siehe Start Events, End Events, Intermediate Events.

Wann sollte man aufteilen? Fünf praktische Signale

Eine einfache Ausgangsregel lautet: Wenn eine Aktivität mehr als 3 bis 5 interne Schritte enthält oder einen klar erkennbaren eigenen Anfang und ein eigenes Ende besitzt, ist sie ein guter Kandidat für einen Teilprozess. In der Praxis sind diese Signale besonders zuverlässig:

• Der Name der Aktivität verbirgt eine ganze Prozedur. „Neuen Mitarbeiter onboarden“ verbirgt zehn Schritte. „IT-Ausstattung aktivieren“ verbirgt vier. Wenn die Bezeichnung zu viel Arbeit leisten muss, um Details zu verstecken, teilen Sie auf.
• Innerhalb und außerhalb gibt es unterschiedliche Verantwortliche. Wenn ein Schritt von einem anderen Team ausgeführt wird als der umgebende Prozess, verdient er einen eigenen Teilprozess, damit dieses Team ihn verantworten kann.
• Sie erklären den Inhalt ständig in Besprechungen. Wenn regelmäßig gefragt wird „Was passiert eigentlich in diesem Schritt?“, ist das ein Signal, daraus einen Teilprozess zu machen.
• Der Schritt wiederholt sich an anderer Stelle. Wenn dieselbe Sequenz in einem anderen Prozess vorkommt, extrahieren Sie sie einmal und lassen Sie beide Prozesse darauf zugreifen.
• Der Schritt hat eigene Ausnahmen. Wenn „Vorgang validieren“ auf drei verschiedene Arten scheitern kann, modellieren Sie die Fehlerbehandlung im Teilprozess statt die oberste Ebene zu überladen.

Verschachtelung und Tiefe

Teilprozesse können weitere Teilprozesse enthalten: Onboarding eines neuen Mitarbeiters, IT-Aktivierung, Sicherheitsprofil konfigurieren, MFA aktivieren. Jede Ebene ist eine eigene Lesestufe, die nur geöffnet wird, wenn sie gebraucht wird.

Tiefe hat jedoch ihren Preis: Zu viele Ebenen führen dazu, dass Leser den Überblick verlieren. In der Praxis sind zwei oder drei Ebenen eine sinnvolle Grenze. Wenn Sie vier brauchen, modellieren Sie wahrscheinlich zu viel Umfang an einer Stelle. Dann ist es meist besser, den Ablauf in separate Prozesse aufzuteilen, die über Nachrichtenflüsse verbunden sind, wie in Lanes und Pools in BPMN beschrieben.

Einen Teilprozess nach dem anderen messen und verbessern

Ein Teilprozess ist eine klar abgegrenzte und benannte Einheit. Dadurch eignet er sich als Messgrenze: Sie können ihm Kennzahlen zuweisen, genau wie Sie einer Phase ein SLA zuordnen.

• Dauer des Teilprozesses: Wie viel Zeit vom Start bis zum Ende vergeht, gemessen über alle Instanzen.
• Wartezeit und Bearbeitungszeit: Welcher Anteil der Dauer tatsächliche Arbeit ist und welcher Anteil aus Wartezeiten zwischen den Schritten besteht.
• Nacharbeitsquote: Wie häufig der Teilprozess zu Wiederholungen oder Ausnahmen führt.
• Kosten des Teilprozesses: Welche Ressourcen innerhalb des Teilprozesses verbraucht werden, nützlich für die Prozesskostenrechnung.

Mit diesen Zahlen kann der Process Owner die Frage „Welcher Teil des Onboardings ist langsam?“ mit Daten statt mit einem Bauchgefühl beantworten. Der Teilprozess wird zur Linse. Für den breiteren Kennzahlenrahmen siehe Key Performance Indicators (KPI) für Geschäftsprozesse.

Dieselbe Abgrenzung macht auch kontinuierliche Verbesserung praktikabel: Sie können ein Serviceziel auf einen einzelnen Teilprozess anwenden statt auf den gesamten Ablauf, eine Änderung testen, etwa ein neues Routing oder einen automatisierten Schritt, ohne den Rest anzufassen, und einem Team einen Teilprozess als klar begrenzten Verbesserungsauftrag übertragen. Ohne Grenzen können Sie nichts isolieren, und ohne Isolation können Sie nichts gezielt verbessern.

Teilprozesse über den gesamten Prozesslebenszyklus

Teilprozesse sind nicht nur eine grafische Bequemlichkeit. Sie entsprechen der Art und Weise, wie Prozesse im Laufe der Zeit gesteuert werden.

• Design: Zuerst skizzieren Sie die oberste Ebene, dann zerlegen Sie sie in Teilprozesse. Die Zerlegung ist der Design-Dialog.
• Umsetzung: Jeder Teilprozess wird zu einem Baustein in einer No-Code-Prozessautomatisierungsplattform, zugeordnet zu dem Team, das ihn besitzt.
• Ausführung: Die Engine führt die enthaltenen Schritte aus und verfolgt ihren Status separat, sodass das Monitoring automatisch phasenbewusst wird.
• Verbesserung: Sie ändern einen Teilprozess, ohne die anderen anzufassen, und messen den Effekt isoliert.

Die Disziplin rund um Teilprozesse zahlt sich noch lange aus, nachdem das Diagramm gezeichnet wurde: Die Struktur, die Sie für bessere Lesbarkeit schaffen, wird zugleich zur Struktur, die Sie steuern, ausführen und verbessern. Es ist eine der wenigen Techniken, die in jeder Phase hilft und nicht nur in einer.

Teilprozesse in einer BPM-Plattform

In einer BPM-Plattform ist ein Teilprozess normalerweise ein eigenständiges Objekt erster Klasse: Sie erstellen ihn einmal und fügen ihn als unabhängigen Baustein in übergeordnete Prozesse ein. Die Plattform führt seine Schritte aus, verfolgt seinen Status und berichtet separat darüber.

Hier wird aus einem Lesbarkeitsvorteil ein operativer Vorteil: Ein Monitoring-Dashboard kann sagen „Der Engpass dieser Woche liegt in der IT-Aktivierung“, gerade weil der Teilprozess eine messbare Einheit ist und nicht nur ein Bild in einem Diagramm.

Anti-Patterns: Wenn Teilprozesse schaden

Teilprozesse sind ein Werkzeug, und wie jedes Werkzeug können sie falsch eingesetzt werden. Achten Sie auf diese fünf Fälle:

• Der bodenlose Ordner. Ein Teilprozess enthält selbst dreißig Schritte und drei weitere verschachtelte Teilprozesse. Sie haben nichts vereinfacht, sondern die Komplexität nur versteckt. Wenn ein Teilprozess so groß ist, teilen Sie den übergeordneten Prozess auf oder überdenken Sie seinen Umfang.
• Der Ein-Schritt-Teilprozess. Eine einzelne Aktivität in einen Teilprozess zu verpacken, fügt ein Kästchen und einen zusätzlichen Klick hinzu, ohne die Lesbarkeit zu verbessern. Teilen Sie nur dann auf, wenn es eine echte interne Struktur gibt.
• Versteckte Duplizierung. Dieselbe Sequenz in drei Modellen neu aufbauen, statt sie einmal zu definieren und aufzurufen. Ab diesem Moment haben Sie drei Kopien, die auseinanderlaufen können, und niemand merkt es, bis zwei Abteilungen unterschiedlich arbeiten.
• Der verwaiste Teilprozess. Ein Teilprozess, den kein anderes Modell aufruft und für den niemand verantwortlich ist. Das ist angesammelte Schuld: Löschen Sie ihn oder verbinden Sie ihn wieder sinnvoll.
• Inkonsistente Benennung. Dieselbe Sequenz an einer Stelle „Aktivierung“ und an einer anderen „IT-Setup“ nennen. Die Namen müssen identisch sein, sonst funktionieren Wiederverwendung und Suche nicht mehr zuverlässig.

Keiner dieser Punkte ist ein Grund, Teilprozesse zu vermeiden. Es sind Gründe, Ihre Modellbibliothek regelmäßig zu überprüfen, genau wie Code, und nach Duplikaten, totem Ballast und Mehrdeutigkeiten zu suchen.

Teilprozesse, Katalog und Governance

Mit wachsender Bibliothek werden Teilprozesse zu den Einheiten, die Sie katalogisieren und steuern. Ein ausgereifter Katalog listet jeden Teilprozess genau einmal auf, zusammen mit Verantwortlichem, Inputs und Outputs, beteiligten Systemen und zugehörigen Kennzahlen. Dann können Teams neue End-to-End-Prozesse zusammensetzen, indem sie bestehende Teilprozesse kombinieren, etwa „Eingang + unsere Standardfreigabe + unsere Standardbenachrichtigung“, statt alles von Grund auf neu zu zeichnen.

Dieses Kompositionsmodell ermöglicht es BPM, über die wenigen Personen mit gutem institutionellem Gedächtnis hinaus zu skalieren. Das Wissen darüber, wie gearbeitet wird, lebt im Katalog und nicht im Kopf einzelner Personen. Wenn der IT-Verantwortliche die Rolle wechselt, ist der Teilprozess „IT-Aktivierung“ immer noch da: dokumentiert, verantwortet und wiederverwendbar. Zur Governance-Ebene, die einen solchen Katalog zuverlässig hält, siehe Process Governance: Ein skalierbares Framework aufbauen.

Ein zusätzlicher Vorteil: Modelle als Schulungsmaterial

Es gibt einen Vorteil, den kaum jemand erwähnt: Eine gut strukturierte Sammlung von Modellen ist bereits Schulungsmaterial. Eine neue Person kann den Prozess auf oberster Ebene in fünf Minuten lesen und anschließend den Teilprozess öffnen, den ihr Team verantwortet, um die Details zu lernen. Das Modell erklärt die Arbeit.

Organisationen, die ihre Teilprozesse aktuell halten, verfügen faktisch über ein lebendiges Betriebshandbuch, das nicht veraltet, weil es die tatsächliche Arbeitsweise abbildet. Vergleichen Sie das mit einer Verfahrensanweisung in einem gemeinsamen Ordner, die den Prozess des letzten Jahres beschreibt: Ein BPMN-Modell korrigiert sich gewissermaßen selbst, weil falsche Modelle früher oder später die tatsächliche Arbeit blockieren würden.

So starten Sie in sechs Schritten

1. Nehmen Sie ein unübersichtliches Diagramm, das Sie bereits haben. Das, das niemand jemals ausdruckt.
2. Markieren Sie Gruppen aus drei oder mehr Schritten, die thematisch zusammengehören: alle IT-Schritte, alle Freigabeschritte, alle Benachrichtigungsschritte.
3. Machen Sie aus jeder Gruppe einen Teilprozess mit einem klaren und überprüfbaren Namen.
4. Prüfen Sie, ob die oberste Ebene jetzt wie eine Abfolge von Phasen lesbar ist, statt wie eine Liste einzelner Aktivitäten.
5. Prüfen Sie, ob einige dieser Gruppen auch in anderen Prozessen vorkommen: Wenn ja, definieren Sie sie einmal und lassen Sie alle relevanten Prozesse darauf zugreifen, statt sie jedes Mal neu zu bauen.
6. Lassen Sie jeden Teilprozess vom verantwortlichen Team validieren: Das Team sollte ihn sofort als seine eigene Arbeit erkennen.

Währenddessen werden Sie merken, wie das Diagramm „leichter“ wird. Genau darum geht es: Eine Prozesskarte, die Menschen tatsächlich öffnen, ist mehr wert als eine vollständige Karte, die niemand liest.

Häufig gestellte Fragen

Ist ein Teilprozess dasselbe wie eine Aktivität?

Nein. Eine Aktivität ist ein einzelner atomarer Schritt. Ein Teilprozess ist ein Container, der eine Folge von Aktivitäten, Gateways und Ereignissen zusammenfasst. Im übergeordneten Prozess verhält er sich wie ein einzelner Schritt, intern besitzt er jedoch ein eigenes Diagramm mit mehreren Schritten.

Kann derselbe Teilprozess von mehreren Modellen verwendet werden?

Ja, und genau darin liegt einer seiner wichtigsten Vorteile. Der Teilprozess ist eine einzige Definition, die von mehreren Prozessen aufgerufen wird. Wenn Sie ihn ändern, arbeiten alle Prozesse, die ihn verwenden, sofort mit der aktualisierten Version, ohne dass Sie jeden einzelnen Prozess separat anpassen müssen.

Kann ein Teilprozess eigene Lanes haben?

Ja. Ein Teilprozess kann eigene Lanes und Pools enthalten, um die Rollen innerhalb dieses Teilprozesses darzustellen. Das ist besonders nützlich, wenn der Teilprozess von einem anderen Team verantwortet wird als der übergeordnete Prozess.

Wie tief können Teilprozesse verschachtelt werden?

In der Praxis zwei oder drei Ebenen. Darüber hinaus ist es meist sinnvoller, in separate Prozesse aufzuteilen, die über Nachrichtenflüsse miteinander verbunden sind, statt weiter zu verschachteln.

Verlangsamen Teilprozesse die Ausführung?

Nein. Sie sind eine Möglichkeit, das Modell zu organisieren, und verursachen keine zusätzlichen Laufzeitkosten. Die Engine führt die enthaltenen Schritte genauso aus, als würden sie alle auf derselben Ebene liegen.

Wichtigste Erkenntnisse

• Teilprozesse bündeln Komplexität in einem einzigen Element, das nur bei Bedarf geöffnet wird: Die Details bleiben erhalten, die Unordnung verschwindet.
• Sie verbessern vier Dinge gleichzeitig: Lesbarkeit, Wiederverwendung, Wartung und Delegation.
• Ein Teilprozess ist eine einzige Definition, die von mehreren Prozessen aufgerufen werden kann: Einmal aktualisieren, überall konsistent.
• Der Event Subprocess behandelt Ausnahmen, ohne den Hauptablauf zu überladen.
• Verwenden Sie einen Teilprozess immer dann, wenn ein Schritt eine relevante interne Logik verbirgt oder in mehreren Prozessen wiederkehrt.

Gestalten Sie klare und gut lesbare Prozesse, Ebene für Ebene, mit Flowenti: flowenti.com