2 Prozessmodellierung mit der BPMN

Dieses Kapitel enthält Aufgaben zur Methode Business Process Model and Notation (BPMN). Zuerst wird eine textliche Beschreibung des zu modellierenden Geschäftsprozesses angegeben (Anforderungsbeschreibung), dann die Lösungsschritte und die Gesamtlösung. Wie in der Prozessmodellierung üblich, werden auch hier die Prozessmodelle durch Grafiken dargestellt, so dass die Lösungsschritte auch grafisch ausgedrückt werden. Die Methode BPMN mit ihren Business Process Diagrams (BPDs) ist ausführlich in [Staud 2024] beschrieben.

Zu den wichtigsten Dingen, die vor einem Modellierungsprojekt geklärt werden müssen, gehören:

• Zweck der Modellierung. Dient es der Prozessdokumentation, der Prozessoptimierung, der Vorbereitung einer Digitalisierung, usw.
• Das Aggregationsniveau. Dies hängt mit dem obigen Punkt zusammen. Grundsätzlich gilt, dass eine zu große Detailliertheit zu evtl. unnötiger Komplexität des Prozessmodells führt, zu wenig u.U. wichtige Semantik des Geschäftsprozesses verbirgt.

Bei den hier angeführten Aufgaben soll es, wenn nicht anders vermerkt, um eine Prozessdokumentation auf der Ebene einer Standardprozessmodellierung gehen. Vgl. [Staud 2024, Abschnitt 3.1] und das dortige Stichwortverzeichnis.

2.1 Kündigung

2.1.1 Prozessbeschreibung

(1) Der Geschäftsprozess startet damit, dass ein Mitarbeiter kündigt. Das Kündigungsschreiben wird von der Personalabteilung (PA) entgegengenommen und an die Fachabteilung (FA) sowie die Geschäftsleitung (GL) weitergeleitet. Die Geschäftsleitung prüft an Hand des Kündigungsschreibens, ob Rückfragen zu der Kündigung vorliegen. Falls ja, wird der Mitarbeiter, der gekündigt hat, zu einem Gespräch gebeten, an dem auch Vertreter der PA, der FA und des Betriebsrats teilnehmen. Das Ergebnis dieses Gesprächs wird von Hand protokolliert, in ein Textdokument übernommen und dann in die Personalakte des Mitarbeiters getan.

(2) Die PA führt eine Besprechung zum Anforderungsprofil der freigewordenen Stelle durch, an der auch die FA teilnimmt. Grundlage des Gesprächs ist die bisherige Stellenbeschreibung des Mitarbeiters. Falls beschlossen wird, das Anforderungsprofil bzgl. der freigewordenen Stelle zu verändern, wird dies durch die PA getan und es wird ein neues Anforderungsprofil erstellt, ansonsten bleibt es beim alten.

(3) Falls ein neues Anforderungsprofil erstellt wurde, wird dieses an die FA geleitet. Diese prüft, ob aus ihrer Sicht alles in Ordnung ist. Falls nein, wird die PA (Sachbearbeiter) kontaktiert und die Unstimmigkeit beseitigt. Die FA erstellt dann ein verändertes Anforderungsprofil. Danach muss dieses an die Leitung der PA zur Prüfung gegeben werden.

(4) Obiger Abschnitt, der Durchgang des Anforderungsprofils durch die FA, kann auch mehrmals nötig werden. Er wird solange wiederholt, bis die abschließende Prüfung durch die PA (Leitung) positiv ausfällt.

(5) Ist das Anforderungsprofil dann in seiner endgültigen Form, erfolgt in der PA die Festlegung der Instrumente, die zur Wiederbesetzung der Stelle genutzt werden. In Frage kommen Zeitungsinserate, das Arbeitsamt und ein interner Aushang. Welches Instrument genutzt wird, hängt von den jeweiligen Gegebenheiten ab. Sicher ist nur, dass mindestens eines immer genutzt wird. Abhängig vom gewählten Instrument wird eine Annonce entworfen und an die Zeitung geleitet (dabei werden frühere Annoncen genutzt), das Arbeitsamt angerufen oder das Anforderungsprofil ausgehängt.

2.1.2 Lösungschritte

Wie immer bei der Modellierung mit der BPMN empfiehlt es sich, mit der Bestimmung der Akteure (Abteilungen, Personen, Partnerunternehmen, Kunden, usw.) zu beginnen. Hier sind folgende erkennbar:

• Der kündigende Mitarbeiter
• Die Personalabteilung (PA)
• Die Fachabteilung (FA)
• Die Geschäftsleitung (GL)
• Der Betriebsrat (BR)

Entsprechend werden die Becken und Bahnen angelegt. Alle Akteure des Unternehmens in einem Becken, jeweils mit einer Bahn. Becken und Bahn des Mitarbeiters daneben mit einigem Abstand von den übrigen Bahnen.

Abbildung 2.1-1: Geschäftsprozess Kündigung - Die Akteure.

Der Vollständigkeit halber soll der Geschäftsprozess im Becken des Mitarbeiters beginnen. Wir fassen Erstellung und Versand des Kündigungsschreibens in einer Sender-Aufgabe Kündigung schreiben, übersenden zusammen [Anmerkung] . Die Übersendung wird als Nachricht modelliert [Anmerkung] . Entsprechend wird in der Bahn der Personalabteilung (im Becken Unternehmen) eine Prozessstart-Aufgabe für den Vorgang Kündigung entgegennehmen angelegt. Die Nachricht selbst wird an den Nachrichtenpfeil angehängt. Im Mitarbeiter-Becken kann dann dieser kleine Teilprozess gleich durch ein Schlussereignis beendet werden.

Abbildung 2.1-2: Geschäftsprozess Kündigung - Entgegennahme. Ausschnitt aus dem Gesamtmodell.

Die Weiterleitung des Kündigungsschreibens zur Fachabteilung und Geschäftsleitung (GL) kann durch ein Parallel Gateway und Nutzer-Aufgaben modelliert werden. Außerdem wird die Entgegennahme in beiden Fällen auch durch eine Nutzer-Aufgabe modelliert, zum einen in der Fachabteilung (FA), zum anderen bei der Geschäftsleitung (GL). Zur Verdeutlichung wird an die Sequenzflüsse [Anmerkung] das Datenobjekt Kündigung angehängt. In der FA folgt danach ein Schlussereignis für diese Sequenzfluss, in der GL geht der Prozess weiter.

Parallel Gateway

Abbildung 2.1-3: Geschäftsprozess Kündigung - Entgegennahme und Weiterleitung. Ausschnitt aus dem Gesamtmodell.

Anmerkung: Obiger Ausschnitt des Prozessmodells verändert sich weiter unten. Er wird wegen dort auftretender Prozessanforderungen erweitert. Dies ist ein Standardschicksal bei der Prozessmodellierung. "Weiter unten" (flussabwärts) in der Prozessbeschreibung treten Aspekte auf, die den Prozess "weiter vorne" (flussaufwärts) verändern. Darauf muss man vorbereitet sein.

In der FA endet dann dieser Zweig des Kontrollflusses. Nicht bei der GL. Hier gilt:

(1) ... Die Geschäftsleitung prüft an Hand des Kündigungsschreibens, ob Rückfragen zu der Kündigung vorliegen. Falls ja, wird der Mitarbeiter, der gekündigt hat, zu einem Gespräch gebeten, an dem auch Vertreter der PA, der FA und des Betriebsrats teilnehmen. Das Ergebnis dieses Gesprächs wird von Hand protokolliert, in ein Textdokument übernommen und dann in die Personalakte des Mitarbeiters getan.

Anforderungs-
profil

Dies kann wie folgt modelliert werden. In der GL-Bahn wurde ja eine Aufgabe für die Entgegennahme der Kündigung eingefügt. Danach wird nun die Prüfung bzgl. der Rückfragen eingefügt. Bei dieser liegen zwei alternative Fortsetzungen vor, wodurch ein Exclusive Gateway nötig wird. Der eine Zweig führt zu einem Schlussereignis (für diesen Zweig, nicht für den Geschäftsprozess), der andere zu der Aufgabe Mitarbeiter zum Gespräch bitten. Dies wird dem (ehemaligen) Mitarbeiter durch eine Nachricht mitgeteilt, was hier so modelliert ist, dass die Nachricht am Beckenrand von Mitarbeiter andockt. Das ist in dieser Methode zulässig.

Abbildung 2.1-4: Geschäftsprozess Kündigung - Entgegennahme durch GL und Entscheidung bzgl Mitarbeitergespräch. Ausschnitt aus dem Gesamtmodell.

Der Nachrichtenpfeil zum Becken des Mitarbeiters wurde hier aus Platzgründen weggelassen. Vgl. dazu das Gesamtmodell in Abbildung 2.1-8.

Gesprächsdurchführung

Wie wird nun die in der Prozessbeschreibung angeforderte Gesprächsdurchführung modelliert. Federführend ist ja die GL. Deshalb wird bei dieser, falls tatsächlich Gesprächsbedarf besteht, eine Aufgabe Mitarbeiter zum Gespräch bitten eingefügt. Diese ist per Nachricht mit dem Mitarbeiter-Becken verknüpft. Optimistisch, wie Prozessmodellierer sein müssen, gehen wir davon aus, dass der Mitarbeiter tatsächlich am Gespräch teilnimmt, was in seinem Becken durch einen kurzen Teilprozess ausgedrückt wird.

Alternative: Eine Prozessstart-Aufgabe im Mitarbeiter-Becken, an der die Nachricht andockt.
Herausforderung: Hier sehen wir eine der Herausforderungen der Prozessmodellierung, die Festlegung des sinnvollen Detaillierungsgrades. Wollte man sehr detailliert modellieren, müsste man hier auch berücksichtigen, dass der Mitarbeiter nicht kommt, in Urlaub ist, usw. Dadurch würde das Modell sehr komplex.
Pragmatik: Deshalb ist es in den einschlägigen Projekten i.d.R. so, dass die wahrscheinlichen Verläufe modelliert werden. Sonst könnte man ja auch auf die Idee kommen, eine mögliche Störung des Prozessablaufs durch Wasserschäden im Gebäude zu modellieren.

Im Prozessablauf folgt dann das gemeinsame Gespräch der vier Akteure. Dies kann, wie es die Abbildung unten zeigt, durch vier Aufgaben in vier Bahnen, die mit einer Punkt-Strich-Linie umrandet sind, ausgedrückt werden. So wird in der BPMN Zusammenarbeit dargestellt [Anmerkung] . Zu den einzelnen Aufgaben führen Kontrollflusspfeile. Innerhalb des Unternehmens getragen durch ein Parallel Gateway. Dies drückt den Unterschied zwischen Sequenzfluss und Nachricht aus. Ein Sequenzfluss hat etwas verbindliches, auf Weisungsbefugnis beruhendes. Eine Nachricht hingegen etwas optionales, weshalb bei Kontakten "nach außen" immer das Nachrichtenkonzept genommen wird.

In das Kündigungsgespräch fließt die Kündigung ein und es wird ein Handprotokoll erstellt, was durch Datenobjekte modelliert wird. Ergänzend zur Prozessbeschreibung wird hierbei angenommen, dass dies durch Mitarbeiter der Personalabteilung geschieht. Entsprechend sind die Datenobjekte grafisch in der Bahn der Personalabteilung angeordnet. Dort wird dann auch das Textdokument erstellt und in die Personalakte übernommen.

Auch dies ist ein Standardschicksal bei der Prozessmodellierung: Prozessbeschreibungen sind oft nicht eindeutig und/oder nicht vollständig. In einer solchen Situation muss bei den Auftraggebern (der Prozessmodellierung) nachgefragt werden.

Abbildung 2.1-5: Geschäftsprozess Kündigung - Gespräch zur Kündigung. Ausschnitt aus dem Gesamtmodell.

Der restliche hierzu gehörige Prozessabschnitt (Textdokument erstellen, in Personalakte übernehmen) wird durch die Personalabteilung realisiert. Die Datenobjekte drücken jeweils den Informationsfluss aus. Bei der Erstellung des Textdokuments wird das Handprotokoll gelesen und das Textprotokoll erstellt, die Übernahme in die Personalakte wird so erfasst, dass das Textprotokoll nur transportiert wird (keine Pfeilspitze ) und die Personalakte befüllt wird (Pfeil zu dieser).

Besprechung Anforderungsprofil

Im nächsten Absatz der Prozessbeschreibung geht es um eine Besprechung zum Anforderungsprofil der freigewordenen Stelle:

(2) Die PA führt eine Besprechung zum Anforderungsprofil der freigewordenen Stelle durch, an der auch die FA teilnimmt. Grundlage des Gesprächs ist die bisherige Stellenbeschreibung des Mitarbeiters. Falls beschlossen wird, das Anforderungsprofil bzgl. der freigewordenen Stelle zu verändern, wird dies durch die PA getan und es wird ein neues Anforderungsprofil erstellt, ansonsten bleibt es beim alten.

Anforderungs-
profil

Diese Semantik bilden wird dergestalt in die Syntax des Business Program Diagrams (BPDs) ab, dass vom Parallel Gateway nach der Entgegenahme der Kündigung ein weiterer Sequenzfluss abgeht, der zur Aufgabe FA zur Besprechung bitten führt. Von dieser Aufgabe gehen dann, wieder mittels Parallel Gateway, zwei Sequenzflüsse ab. Der eine in die FA und dort zur Aufgabe Besprechung zum AnfProfil (Anforderungsprofil), der andere, mittels einer Verknüpfung (wegen der Übersichtlichkeit) zur entsprechenden Aufgabe in der PA. Dass beide Abteilungen zusammenwirken, wird wieder durch die Strich-Punkt-Linie ausgedrückt. Beide greifen auf das bisherige Anforderungsprofil zu.

Semantik sucht Syntax

Abbildung 2.1-6: Geschäftsprozess Kündigung - Besprechung zum Anforderungsprofil. Ausschnitt aus dem Gesamtmodell.

In der FA endet dann dieser Sequenzflusszweig. In der PA wird, abhängig vom Ergebnis der Besprechung, entweder das Anforderungsprofil nicht geändert (Schlussereignis!) oder geändert, was wiederum weitere Aktivitäten mit sich bringt:

(3) Falls ein neues Anforderungsprofil erstellt wurde, wird dieses an die FA geleitet. Diese prüft, ob aus ihrer Sicht alles in Ordnung ist. Falls nein, wird die PA (Sachbearbeiter) kontaktiert und die Unstimmigkeit beseitigt. Die FA erstellt dann ein verändertes Anforderungsprofil. Danach muss dieses an die Leitung der PA zur Prüfung gegeben werden.

Anforderungs-
profil

(4) Obiger Abschnitt, der Durchgang des Anforderungsprofils durch die FA, kann auch mehrmals nötig werden. Er wird solange wiederholt, bis die abschließende Prüfung durch die PA positiv ausfällt.

Ein "Falls" in der Anforderung bedeutet in der Regel, dass die Prozessmodellierer nach einer Entscheidung und einer Handlung suchen müssen. So auch hier. Die Entscheidung wurde oben schon angesprochen, die Handlung ist die Veränderung des Anforderungsprofils, bei der das entsprechende Datenobjekt (AnfProfil) beschrieben wird. Es folgt die Weiterleitung an die Fachabteilung und dann die Entgegennahme dort.

"Falls"

Anschließend steht die Prüfung des neuen Anforderungsprofils in der Fachabteilung an. Gibt es Unstimmigkeiten wird dies von der Fachabteilung ausgehend mit der Personalabteilung geklärt. Deshalb wurde die Aufgabe Unstimmigkeit klären in der Fachabteilung angesiedelt. Während der Klärung wird das Datenobjekt AnfProfil geändert. Danach geht es im Sequenzfluss zurück in die Personalabteilung, zur Prüfung des (wiederum) veränderten Anforderungsprofils.

Die Prozessbeschreibung drückt aus, dass dieser Abschnitt mehrfach durchlaufen werden kann. Im Geschäftsprozess und damit im Business Process Diagram entsteht somit eine Rückschleife. Irgendwann wird diese Neugestaltung des Anforderungsprofils zu einem Ergebnis führen, dem die Fachabteilung zustimmen kann, dann gilt AnfProfil in Ordnung und die Schleife findet ein Ende.

Rückschleife

Abbildung 2.1-7: Geschäftsprozess Kündigung - Eventuelle Änderung des Anforderungsprofils. Ausschnitt aus dem Gesamtmodell.

Danach geht der Geschäftsprozess weiter zur Festlegung der Instrumente für die Wiederbesetzung der Stelle:

(5) Ist das Anforderungsprofil dann in seiner endgültigen Form, erfolgt in der PA die Festlegung der Instrumente, die zur Wiederbesetzung der Stelle genutzt werden. In Frage kommen Zeitungsinserate, das Arbeitsamt und ein interner Aushang. Welches Instrument genutzt wird, hängt von den jeweiligen Gegebenheiten ab. Sicher ist nur, dass mindestens eines immer genutzt wird. Abhängig vom gewählten Instrument wird eine Annonce entworfen und an die Zeitung geleitet (dabei werden frühere Annoncen genutzt), das Arbeitsamt angerufen oder das Anforderungsprofil ausgehängt.

Anforderungs-
profil

Dies wird als Aufgabe (Task Objekt) mit dem "einfließenden" Datenobjekt AnfProfil modelliert. Die Prozessbeschreibung macht klar, dass die Wahl der Instsrumente nicht determinieret ist, sondern in beliebiger Zusammensetzung erfolgen kann. Die Beschreibung macht auch klar, dass mindestens ein Instrument benutzt wird. Für eine solche Situation ist das verzweigende Inclusive Gateway geschaffen. Es hat die drei Zweige Interner Aushang, Arbeitsamt und Zeitungsinserat mit den entsprechenden Aufgaben. Die ersten zwei transportieren bzw. nutzen das Anforderungsprofil, beim dritten fließen das Anforderungsprofil und die früheren Anzeigen ein und es entsteht die neue Anzeige. Hier gilt es, die Pfeilrichtung zu den Datenobjekten zu beachten.

Inclusive Gateway

2.1.3 Lösung

Danach findet der Geschäftsprozess sein Ende, in der Grafik durch ein Beenden-Ereignis (Terminate) ausgedrückt. Die folgende Abbildung zeigt das gesamte Business Process Diagram in zwei Teile aufgeteilt. Hier mit Hilfe von Verknüpfungs-Zwischenereignissen. Eine Wiedergabe der gesamten Abbildung ist an dieser Stelle aus technischen Gründen nicht möglich. Diese findet sich aber dort:

https://www.staud.info/grafiken2020/grafiken.php#unterpunkt101

Abbildung 2.1-8: Geschäftsprozess Kündigung. Das gesamte Prozessmodell - linke Hälfte

Abbildung 2.1-9: Geschäftsprozess Kündigung. Das gesamte Prozessmodell - rechte Hälfte

2.2 Angebotserstellung im Anlagenbau

Vorbemerkung: Die hier zugrundeliegende Prozessbeschreibung entspricht weitgehend einer realen ersten Prozessaufnahme. Sie wurde nicht "geglättet", wie dies meist der Fall ist. Deshalb enthält sie Ablaufbeschreibungen auf unterschiedlichen Ebenen, für die Prozessmodellierung überflüssige Anmerkungen und unvollständige Angaben, v.a. bzgl. der Datenobjekte. Damit soll genau auf diese Probleme hingewiesen werden. Prozessbeschreibungen sind oft sehr unscharf bzw. lückenhaft. In einer realen Modellierungssituation würde dies bei der nächsten Projektbesprechung mit den Prozessverantwortlichen geklärt.

Probleme

2.2.1 Prozessbeschreibung

(1) Gestartet wird der Geschäftsprozess aufgrund einer Kundenanfrage. Diese kann per Brief, per Telefax, per E-Mail oder telefonisch eingehen. Falls sie telefonisch eingeht, erstellt der Vertrieb ein schriftliches Dokument, das die Anfrage festhält (Anfragefixierung) Unabhängig von der Art des Eingangs nimmt das Zentralsekretariat die Anfrage entgegen, prüft sie auf formale Korrektheit und leitet sie dann an den zuständigen Vertriebsbereichsleiter (VBL) und die Geschäftsleitung weiter. Der Vertriebsbereichsleiter gibt die Anfrage an einen seiner Vertriebsingenieure weiter, der die Angebotsrealisierbarkeit prüft.

(2) Dies betrifft zunächst das angefragte Leistungsspektrum. Liegt dieses nicht innerhalb des Leistungsspektrums des Unternehmens, erfolgt eine Absage. Können nur Teile der angefragten Leistungen erbracht werden, werden Partnerunternehmen um Unterstützung angefragt und entweder als Kooperationspartner oder Subunternehmer eingebunden. Finden sich keine geeigneten Partner, wird die Anfrage abgelehnt.

(3) Danach folgt - weiterhin durch den Vertriebsingenieur - die Prüfung, ob die Angebotslegungsfrist (ALF) realisiert werden kann. Parallel hierzu wird die für die Projektabwicklung notwendige Ingenieurgruppe auf ihre Auslastung hin überprüft. Ist die Kapazität vorhanden, die Angebotsfrist aber zu knapp, wird um Fristverlängerung nachgefragt. Wird diese nicht gewährt, erfolgt eine Absage. Ist absehbar, dass benötigte Ingenieurfachkräfte schon für längere Zeit aufgrund laufender Projekte ausgelastet sind, erfolgt ebenfalls eine Absage.

(4) Sind alle zu prüfenden Kriterien erfüllt, erfolgt die eigentliche Angebotserstellung. Dies geschieht in der Regel unter Einbeziehung der Mitarbeiter aus den relevanten Geschäftsbereichen oder der Geschäftsbereichsleiter, die z. B. bei der Stunden- und Kostenschätzung von angefragten Ingenieurstätigkeiten mitwirken und mögliche, verfügbare Ingenieure als Projektleiter und Ingenieure vorschlagen.

Die Angebotsdaten werden durch Vertriebsmitarbeiter in der Angebotsdatenbank erfasst, ein Programm (Report Generator Angebot; RepGenA) erzeugt dann die textliche Ausformulierung des Angebots für den anfragenden Kunden.

Das fertige Angebot wird durch den zuständigen Vertriebsingenieur dem Kunden zugeschickt.

(5) Danach muss die Entscheidung des Kunden abgewartet werden. Üblicherweise erteilt der Kunde den Auftrag entweder sofort aufgrund des Angebots oder er lädt zunächst zu einem oder mehreren Vergabegesprächen ein. Diese Angebotsverhandlungen werden in der Regel vom zuständigen Vertriebsingenieur und dem Vertriebsbereichsleiter geführt. Die Ergebnisse dieser Vergabegespräche dienen dann als Grundlage für die Entscheidung im anfragenden Unternehmen.

Kommt es, entweder gleich oder nach den Vergabegesprächen, zu einer Ablehnung des Auftrags, bestätigt dies der zuständige Vertriebsingenieur. Er ist außerdem verpflichtet, durch Nachfragen beim Kunden oder sonstigen Verbindungsleuten die Gründe für die Absage in Erfahrung zu bringen, falls dies nicht schon aus dem Absageschreiben hervorgeht. Dies dient dazu, die Informationsbasis für zukünftige Angebote bei diesem Kunden zu verbessern.

2.2.2 Lösungsschritte

Zu Beginn eines solchen BPMN-Modellierungsvorhabens sollten die insgesamt beteiligten Akteure (Mitarbeiter, Abteilungen und externe Partner) geklärt werden. Hier ergibt sich:

• Der Kunde
• Das Unternehmen mit dem Vertriebsingenieur (VI), dem Vertriebsbereichsleiter (VBL), dem Vertrieb (als Abteilung) und dem Zentralsekretariat

Entsprechend werden die Becken und Bahnen angelegt. Vgl. die Abbildungen unten.

Zu Punkt (1)

Die vorliegende Prozessbeschreibung ist unternehmenszentriert. In der BPMN wird aber meist der Gesamtkontext eines Geschäftsprozesses modelliert. Deshalb startet im zu erstellenden BPD (Business Process Diagram) der Prozess beim Kunden. Dort wird die Aufgabe Anfrage formulieren angestoßen. Danach wird entschieden, auf welche Weise die Anfrage verschickt wird. Dies wird durch ein Exclusive Gateway und drei nachfolgende Aufgaben modelliert:

• Anfrage per Fax versenden
• Anfrage per Brief versenden
• Telefonische Anfrage

Von diesen geht ein jeweils ein Nachrichtenfluss [Anmerkung] in das Becken Unternehmen zum Zentralsekretariat. Jede Nachricht stößt auf ein Nachrichten Zwischenereignis, empfangend. Vor diese Zwischenereignisse muss ein Exclusive Gateway ereignsbasiert, nur für den Prozessstart gesetzt werden. Genau für eine solche Situation ist dieses Prozesselement geschaffen. Auf diese Weise wird also im Zentralsekretariat der Prozess gestartet. Beim Kunden endet sein Prozess, nachdem genau eine der Aufgaben realisiert wurde.

Muster Nachrichtenversand
In der BPMN wird bzgl. der Abläufe im Geschäftsprozess konsequent zwischen Sequenzfluss und Nachrichtenfluss unterschieden.

Im Zentralsekretariat liegen also die drei empfangenden Nachrichten-Zwischenereignisse Anfrage per Brief, Anfrage per Telefax und Telefonische Anfrage vor. Bei einer telefonischen Anfrage folgt die Aufgabe Anfragefixierung mit einem entsprechenden Datenobjekt Anfrage, das beschrieben wird. Da der Sequenzfluss für alle drei Varianten einheitlich weitergeht, werden die drei Sequenzflüsse dann zusammengeführt (Position 1). Hierzu dient ein verknüpfendes Exclusive Gateway. Es folgt die Aufgabe Formale Korrektheit prüfen, die lesend auf das Datenobjekt Anfrage zugreift. Da in der Prozessbeschreibung nicht darauf eingegangen wird, was bei fehlerhafter formaler Korrektheit geschieht, wird es hier auch nicht modelliert.

Im Text wird dann die Weiterleitung an die Geschäftsleitung (GL) und den Vertriebsbereichsleiter (VBL) beschrieben. Dies erfordert ein Parallel Gateway, nach dem die entsprechenden Aufgaben modelliert wurden, an die das Datenobjekt Anfrage angehängt ist. Da dabei das Datenobjekt nicht gelesen und nicht beschrieben wird, verzichtet der Verfasser in einem solchen Fall auf die Pfeilspitzen bei der Verbindungslinie.

Muster Teilaufgaben

Muster Weiterleitung
Die Weiterleitung von Datenobjekten kann auch unterschiedliche Weise modelliert werden. Entweder so wie hier, indem die Weiterleitung als Aufgabe modelliert wird, oder durch Verbinden des Datenobjekts mit der Sequenzflusslinie, oder einfach so, dass das Informationsobjekt bei der nächsten Aufgabe wieder auftaucht. Vgl. [Staud 2024, Abschnitt 8.3].

Nach der Aufgabe Weiterleitung an GL endet dieser Sequenzflusszweig mit einem Schlussereignis, während der Weiterleitung an VBL die Aufgabe Weiterleitung an VI folgt, die vom vom VBL zu realisieren ist, weshalb der Sequenfluss in die Bahn VBL geleitet und dort die Aufgabe platziert wird.

Punkt 2 der Anforderungen

Dies betrifft zuerst das vom Kunden angefragte Leistungssprektrum. Hier deutet der Text eine dreigeteilte Entweder/Oder-Situation an, die durch ein datenbasiertes verzweigendes Exclusive Gateway modelliert wird (Position 2 in der folgenden Abbildung):

• Entweder nicht realisierbar (nicht innerhalb des Leistungssprektrums) oder
• Passend oder
• nur Teile realisierbar.

Die Absage wird durch eine entsprechende Aufgabe Auftrag ablehnen mit einem Beenden - Ereignis (terminate) modelliert, womit der Geschäftsprozess endet. Rund um die Ablehnung könnte der Nachrichtenweg der Absage modelliert werden, da die Anforderungsbeschreibung darauf verzichtet, geschieht es auch hier.

Die in der Prozessbeschreibung beschriebene Anfrage bei Partnerunternehmen als Kooperationspartner (KP) oder als Subunternehmer (SubU) wurde einfach als eine einzige Aufgabe modelliert, mit einem positiven und einem negativen Gesamtergebnis. Dies könnte, wenn es für die Prozessanalyse wichtig wäre, auch viel detaillierter realisiert werden. Zum Beispiel so, dass jede einzelne Anfrage bei einem potentiellen Partner als Funktion in einer Schleife erfasst würde. Die Schleife wäre erst dann fertig, wenn alle potentiellen Partner gefragt worden wären - mit einem positiven oder einem negativen Ergebnis.

Kommt es bei der Aufgabe Partnerunternehmen anfragen zu einem negativen Gesamtergebnis wird die Anfrage wiederum abgelehnt und ein weiteres Schlussereignis vom Typ Beenden (terminate) tritt ein.

Kommt es zu einem positiven Gesamtergebnis ("Gefunden") wird die Prozessbeschreibung in eine Aufgabe Als KP oder SubU einbinden umgesetzt. Der dann nachfolgende Sequenzfluss wird mit dem postiven Ergebnis der Prüfung ("passend") zusammengeführt, denn es geht ja ab da in einem einzigen Sequenzfluss weiter. Dies geschieht mit einem Exclusive Gateway (Pos. 3 der Abbildung).

Die folgende Abbildung zeigt die bisherigen Modellierungsschritte. Das Parallel Gateway am Ende des Sequenzflusses steht für den Fortgang des Geschäftsprozesses, vgl. unten.

Abbildung 2.2-1: Angebotserstellung für Anlagen, Teil 1

Enthaltene Elemente (Auswahl):
- Bahnen
- Becken
- Datenobjekt (Erzeugung)
- Datenobjekt (lesend))
- Datenobjekt am Sequenzfluss
- Exclusive Gateway / ereignisbasiert, für den Prozessstart
- Exclusive Gateway, verknüpfend
- Informationstransport durch Aufgabe
- Muster Teilaufgaben
- Nachrichtenfluss
- Nachrichten-Zwischenereignis, empfangend
- Parallel Gateway, verzweigend
- Verknüpfungs-Zwischenereignis / abgebend

Alternative

Noch ein Beispiel zum Thema Abstrahierung: Möglich wäre oben z.B. die Zusammenfassung der Kundenaktivitäten und eine Abstrahierung von den Nachrichtenvarianten gewesen. Dann liegt beim Kunden eine einzige Aktivität vor, die eine Nachricht übermittelt. Im Zentralsekretariat müsste dann die Aktivität Klären Anfrageart eingefügt werden, da ja für telefonische Anfragen eine Anfragefixierung erfolgt (und nur für diese). Vgl. die folgende Abbildung.

Abstrahierung

Abbildung 2.2-2: Angebotserstellung für Anlagen - alternativer Start (Abgeleitet von obigere Abbildung).

Enthaltene Elemente (Auswahl):
- Datenobjekt (lesend)
- Exclusive Gateway / datenbasiert und verknüpfend
- Exclusive Gateway / datenbasiert und verzweigend
- Nachrichtenfluss

Zu Punkt 3 der Anforderungsbeschreibung

Der Geschäftsprozess findet weiterhin beim Vertriebsingenieur (VI) statt. Der Absatz macht deutlich, dass zwei Tätigkeiten parallel angestoßen werden. Deshalb das Parallel Gateway am Ende der obigen Abbildung und am Beginn der nächsten. Die beiden Aufgaben sind Prüfung ALF und Prüfung Auslastung IngGruppe.

Die Prüfung der Angebotslegungsfrist kann zu zwei Ergebnissen führen: "ausreichend / nicht ausreichend". Genauso die Prüfung der Kapazität der Ingenieurgruppe: "Ingenieurkapazität reicht / reicht nicht". Die kombinierten insgesamt vier möglichen Ergebnisse werden nun bezüglich ihrer Konsequenzen im Text wie folgt beschrieben:

• Wenn beide Prüfungen positiv ausfallen geht es weiter im Geschäftsprozess, die Anfrage wird angenommen.
• Ist die Kapazität der Ingenieurgruppe nicht ausreichend (Kapazität Ingenieure nicht vorhanden), wird die Anfrage abgelehnt, unabhängig davon, welches Ergebnis die Prüfung der Angebotslegungsfrist erbrachte.
• Ist die Angebotslegungsfrist (ALF) nicht realisierbar und sind Kapazitäten vorhanden, wird um eine Fristverlängerung gebeten.

Es bleiben also drei mögliche Fortgänge übrig. Dies wird hier durch ein Complex Gateway modelliert (Pos. 4). Möglich wäre auch eine konventionelle Lösung mit parallelen Gateways nach dem Kombinatorikmuster (vgl. [Staud 2014, Abschnitt 6.6]), aber für solche Situationen ist in der BPM das Complex Gateway geschaffen worden.

Das Zoo-Beispiel mit EPKs in diesem Text zeigt eine Lösung auf Basis der EPK-Syntax.

In der BPD wird dies wie folgt umgesetzt:

• Nach der Aufgabe Absage wird ein Beenden-Ereignis (terminate) angefügt.
• Nach der Aufgabe Anfrage annehmen geht es zu einem vereinigenden Exclusive Gateway weiter. Dieser positive Fortgang wird mit dem anderen zuammengeführt (vgl. unten).
• Nach der Aufgabe Bitte um Fristverlängerung folgt ein Exclusive Gateway mit den zwei möglichen Ergebnissen nicht gewährt/gewährt. "Gewährt" führt zum oben angesprochenen weiteren positiven Fortgang, der mit Hilfe des Exclusive Gateway mit dem anderen zuammengeführt wird. "Nicht gewährt" führt zu einer Aufgabe Absage und zu einem Beenden-Ereignis (terminate).

Die folgende Abbildung zeigt diesen Prozessabschnitt, konzentriert auf die VI-Bahn.

Abbildung 2.2-3: Angebotserstellung für Anlagen, Teil 2 - Kapazitätsprüfung

Abkürzungen:
ALF: Angebotslegungsfrist
Enthaltene Elemente (Auswahl):
- Complex Gateway, verknüpfend
- Complex Gateway, verzweigend
- Datenobjekte am Sequenzfluss
- Exclusive Gateway / datenbasiert und verknüpfend
- Parallel Gateway, verzweigend
- Verknüpfungs-Zwischenereignis / abgebend
- Verknüpfungs-Zwischenereignis / empfangend

Zu Position 4 der Anforderungsbeschreibung

Die Angebotserstellung ist im Text detailliert beschrieben mit all ihren Funktionalitäten. Ausführungen zu Stunden- und Kostenschätzungen usw. sind aber Funktionsaspekte und nicht Prozessaspekte und können deshalb bei einer Istanalyse des Prozesses ignoriert werden. Ihr Ausmodellieren würde die Beschreibung des Prozessflusses stören. Deshalb wird diese Beschreibung der Einzelfunktionen in einen (verborgenen) Subprozess gepackt. Die für die Angebotserstellung notwendigen Textdokumente werden an den zum Subprozess führenden Sequenzfluss angefügt (vorige Abbildung).

Obiges gilt grundsätzlich. In den textlichen oder verbalen Prozessbeschreibungen (z.B. bei Istanalysen) werden Funktions- und Prozessbeschreibungen oft vermischt. Es ist Sache der Prozessmodellierer diesbezüglich eine Abgrenzung vorzunehmen. Ist z.B. eine Digitalisierung des Geschäftsprozesses geplant, müssen auch Funktionsaspekte modelliert werden. Evtl. bis auf die Programmebene, wobei da dann die Methoden der UML herangezogen werden sollten (vgl. [Staud 2019]).

Die im Text etwas unklaren Angaben zu den zuständigen Personen werden durch eine textliche Anmerkung gelöst. Solche nicht ganz präzisen Angaben bei Zuständigkeiten kommen bei Prozessbeschreibungen häufig vor.

Die nachfolgende Aktivität Angebotsdaten erfassen wird durch den Vertrieb realisiert. Dort werden die Angebotsdaten in eine Datenbank mit allen Angeboten, die im Unternehmen erstellt werden, eingetragen. Es entsteht das Datenobjekt Angebot in Datenbank. Aus diesem Datenbankeintrag heraus entsteht dann - automatisch - mit Hilfe eines Reportgenerators die textliche Fassung des Angebots (Textliches Angebot). Diese Aufgabe wird also von einem Programm durchgeführt, weshalb im Business Process Diagram (BPD) eine Aufgabe des Typs Dienst (Service Task Objekt) gewählt wurde. Da, so die Anforderungsbeschreibung, die Zusendung des fertigen Angebots der VI erledigt, wird der Sequenzfluss in dessen Bahn geführt und dort eine Sender-Aufgabe Dem Kunden zusenden angestoßen (Pos. 6 in der Grafik). Von dieser führt dann eine Nachrichtenlinie in das Kunden-Becken zu einem Nachrichten-Zwischenereignis und zur Aufgabe Angebot prüfen. Dazu unten mehr.

Abbildung 2.2-4: Angebotserstellung für Anlagen, Teil 3 - Angebot zum Kunden

Enthaltene Elemente (Auswahl):
- Datenobjekt (Erzeugung)
- Datenobjekt (lesend)
- Datenobjekt am Sequenzfluss
- Dienst-Aufgabe
- Nachrichtenfluss
- Sender-Aufgabe
- verborgener Subprozess
- Verknüpfungs-Zwischenereignis / abgebend
- Verknüpfungs-Zwischenereignis / empfangend

Zu Position 5 der Anforderungsbeschreibung

Für den Start des Geschäftsprozesses beim Kunden, die Angebotsprüfung und die Entscheidungsfindung, wurde ein Nachrichtenstartereignis (top level) eingefügt. Dieses stößt die Aufgabe Angebot prüfen an. Dabei wird das Datenobjekt Angebot gelesen.

Nachrichten-
startereignis

..i::Gruppe (BPMN)::j::Beim Kunden löst dies einen Entscheidungsprozess aus, der in seiner Grundform modelliert wurde, da eine nähere Beschreibung nicht vorliegt. Er ist im Becken des Kunden zu finden. Zu beachten ist hier die eventuelle Forderung nach Vergabegesprächen. Falls es zu diesen kommt, müssen nach der obigen Prozessbeschreibung der VBL und der VI miteinbezogen werden. Dies wurde durch jeweils eine Nachricht modelliert. Das gemeinsam geführte Gespräch wird - über die entsprechenden Bahnen hinweg - durch eine Gruppe (group) modelliert. Dazu wird in jeder beteiligten Bahn die Aufgabe Vergabegespräche führen eingefügt und mittels Nachricht (vom Kunden) angestoßen.

Entscheidung beim Kunden

Falls die Prüfung beim Kunden gleich positiv verlief oder falls die Vergabegespräche einen positiven Abschluss fanden, kommt es zur Erteilung des Auftrags und zu einem Prozessende. Die beiden Sequenzflusszweige werden vor der Aufgabe Auftrag erteilen mit Hilfe eines Exclusive Gateway zusammengeführt.

Da das Unternehmen ja von der Auftragserteilung erfahren sollte, dies aber in der Prozessbeschreibung nicht näher ausgeführt wird, wurde eine entsprechende Nachricht zum Becken des Unternehmens eingefügt (mit einer Sender-Aufgabe).

Zu einer Absage durch den Kunden kommt es entweder gleich oder ebenfalls nach den Vergabegesprächen. Deshalb werden auch hier die entsprechenden Sequenzflusszweige mit einem Exclusive Gateway zusammengeführt und danach die Sender-Aufgabe Auftrag ablehnen eingefügt. Hier ist der Adressat der Nachricht in der Prozessbeschreibung angeführt, weshalb der Nachrichtenfluss zum Vertriebsingenieur geführt wird. Gemäß der Prozessbeschreibung wird im Falle einer Absage nicht nur die Absage bestätigt, was einfach durch eine Funktion geschieht, sondern auch u.U. nachgefragt. Die diesbezügliche Formulierung

Absage

"...falls dies nicht schon aus dem Absageschreiben hervorgeht"

kann dadurch umgesetzt werden, dass einfach eine entsprechende Prüfung ("Prüfen, ob Absage begründet"; Pos. 7) eingebaut wird. War die Absage begründet, folgt ein Beenden-Ereignis (terminate), ansonsten eine nicht näher spezifizierte Nachfrage und danach dann das Prozessende.

Abbildung 2.2-5: Angebotserstellung für Anlagen, Teil 4 - Schluss

Enthaltene Elemente (Auswahl):
- Exclusive Gateway / datenbasiert und verknüpfend
- Exclusive Gateway / datenbasiert und verzweigend
- Gruppe
- Nachrichtenfluss
- None-Schlussereignis
- Sender-Aufgabe
- Verknüpfungs-Zwischenereignis / empfangend

Soweit der Geschäftsprozess Angebotserstellung für Anlagen, der damit endet. Im positiven Fall stößt er den nachfolgend skizzierten Geschäftsprozess Auftragsstart an.

2.2.3 Lösung

Den Geschäftsprozess als Ganzes kann die folgende Abbildung nur andeuten. Sie kann hier aus technischen Gründen nicht besser dargestellt werden. Eine größere und grafisch detailliertere Version dieser Grafik findet sich hier:
https://www.staud.info/grafiken2020/Grafiken.php

Abbildung 2.2-6: Angebotserstellung für Anlagen, Gesamtmodell

2.3 Auftragsstart im Anlagenbau

Die hier zugrundeliegende Prozessbeschreibung entspricht weitgehend einer realen ersten Prozessaufnahme. Sie wurde nicht "geglättet", wie dies meist der Fall ist. Deshalb enthält sie Ablaufbeschreibungen auf unterschiedlichen Ebenen, für die Prozessmodellierung überflüssige Anmerkungen und unvollständige Angaben, v.a. bzgl. der Datenobjekte. Damit soll genau auf diese Probleme hingewiesen werden. Prozessbeschreibungen sind oft sehr unscharf bzw. lückenhaft. In einer realen Modellierungssituation würde dies bei der nächsten Projektbesprechung mit den Prozessverantwortlichen geklärt.

2.3.1 Prozessbeschreibung

(1) Nach Eingang des Auftrags prüft der Vertriebsingenieur (VI), ob der Auftrag mit sämtlichen ausgehandelten Konditionen bzw. dem Angebot übereinstimmt. Gibt es keine Abweichungen wird die Auftragsbestätigung erstellt und dem Kunden mitgeteilt. Gibt es im Auftrag des Kunden Abweichungen vom Angebot werden diese in der Auftragsbestätigung durch für das Unternehmen akzeptable Konditionen ersetzt. Dies wird dem Kunden mitgeteilt und er wird gebeten, die Kenntnisnahme schriftlich zu bestätigen. Lehnt der Kunde ab, wird die Ablehnung in der Kundendatenbank vermerkt. Hat der Kunde nach drei Wochen noch nicht geantwortet, wird nachgefragt.

(2) Der Vertriebsingenieur (VI) füllt dann im ERP-System ein Auftragsstammblatt (ASB) aus, wobei im Vertrieb gleichzeitig zentral die Auftragsnummer vergeben wird, die auch ins Auftragsstammblatt (ASB) eingetragen wird.

(3) Das Controlling trägt dann die im Angebot bzw. im Auftrag festgelegte Kostenstruktur nach Honorar, Sachkosten, Reisekosten und Fremdleistungskosten auf dem Auftragsstammblatt ein und versieht es mit Vorgaben für Budget, Ressourcenplanung, Reisekosten und Zahlungsplan.

(4) Das Controlling erstellt eine Stundenvorgabe für den Projektleiter, die sich folgendermaßen errechnet: Vom beauftragten Honorar werden zunächst die Fremdleistungen und die geplanten Sachkosten (Reisekosten, Kopierkosten etc.) abgezogen. Nach Abzug eines Gewinns und einer Sicherheitsmarge in Höhe von ca. 16% ergeben sich die verfügbaren Personalkosten. Diese werden durch den Kostensatz der jeweiligen Mitarbeitergruppe geteilt. So ergibt sich die Stundenvorgabe je Mitarbeitergruppe. Alle Ingenieure im Haus sind nach den Jahren ihrer Berufserfahrung unterschiedlichen Gruppen zugeordnet. Jede Gruppe wird zu einem bestimmten Erlösstundensatz abgerechnet bzw. Kostenstundensatz belastet. Ebenso werden Sekretärinnen, studentische Hilfskräfte, Übersetzer, Technische Zeichner usw. mit bestimmten Kostensätzen eingerechnet.

Dabei werden drei Stufen unterschieden. Der erste Kostensatz (Kostensatz Stufe 1) ergibt sich aus dem jeweiligen Gehalt des Mitarbeiters. Die Hinzurechnung der direkten bereichsspezifischen Gemeinkosten ergibt den Kostensatz Stufe 2. Die weitere Addition des unternehmensspezifischen Gemeinkostensatzes ergibt den endgültigen dritten Kostensatz Stufe 3.

(5) Das Controlling ermittelt die Rechnungsstellungstermine aufgrund der vertraglichen Vereinbarungen. Bei Honorar nach Aufwand wird nur der Abrechnungsmodus (wöchentlich, monatlich, vierteljährlich, usw.) vermerkt. Bei Pauschalaufträgen sind die Rechnungsstellungstermine in der Regel an den Projektfortschritt gekoppelt und fallen mit Meilensteinen der Projektabwicklung zusammen. Bei den Rechnungsstellungsterminen für diese Aufträge werden die abzurechnenden Beträge bzw. der Prozentanteil des Honorars vermerkt.

Nach Ermittlung der Rechnungsstellungstermine werden dem Kunden durch den Vertrieb die Zahlungstermine mitgeteilt. Parallel hierzu erfolgt die Anlage des Auftrags im Produktionsplanungssystem (PPS) durch das Controlling.

(6) Das durch die Abteilung Auftragsabwicklung vervollständigte Auftragsstammblatt wird zur Erstellung der Auftragsmeldung an den Vertrieb zurückgegeben. Die ausgedruckte Auftragsmeldung wird mit den entsprechenden Anlagen (Angebot, Vertrag und sonstige für die Vertragsausführung erforderlichen Dokumente) archiviert. Außerdem werden vom Controlling Kopien an den für die Bearbeitung zuständigen Technikbereich weitergeleitet.

(7) Parallel zur internen Meldung über die Vervollständigung des Auftragsstammblatts hat der Vertriebsingenieur die externe Auftragsbestätigung an den Kunden zu erstellen. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt.

Erfolgte der Auftrag schriftlich und hat der Auftraggeber bereits eine Auftragsbestätigung mitgeschickt, wird diese unterschrieben zurückgesandt.

Erfolgte die Beauftragung mündlich, wird die externe Auftragsbestätig um sämtliche besprochenen Konditionen ergänzt und dem Kunden zugesandt.

Ansonsten wird die externe Auftragsbestätigung dem Kunden zugeschickt.

Abschließend setzt sich der Projektleiter mit dem Kunden in Verbindung, um die Arbeitsaufnahme zu besprechen.

Festlegung und erste Erkenntnis

• Die Prozessmodellierung soll als Standardprozessmodellierung erfolgen, d.h. die Geschäftsobjekte (Datenobjekte, usw.) sollen als solche erkennbar sein und mit ihnen soll im Geschäftsprozess umgegangen werden.
• Als erster Akteur kann das Unternehmen angenommen werden, in dem der Geschäftsprozess stattfindet.

Textanalyse

Wie immer lohnt es sich, die Prozessanforderungen zu Beginn als Ganzes und genau zu lesen. Hier kann erkannt werden:

(1) Nach Eingang des Auftrags prüft der Vertriebsingenieur (VI), ob der Auftrag mit sämtlichen ausgehandelten Konditionen bzw. dem Angebot übereinstimmt. Gibt es keine Abweichungen wird die Auftragsbestätigung erstellt und dem Kunden mitgeteilt. Gibt es im Auftrag des Kunden Abweichungen vom Angebot werden diese in der Auftragsbestätigung durch für das Unternehmen akzeptable Konditionen ersetzt. Dies wird dem Kunden mitgeteilt und er wird gebeten, die Kenntnisnahme schriftlich zu bestätigen. Lehnt der Kunde ab, wird die Ablehnung in der Kundendatenbank vermerkt. Hat der Kunde nach drei Wochen noch nicht geantwortet, wird nachgefragt.

Ganz normaler Prozessstart. Erster Akteur: Vertriebsingenieur (VI). Weiterer Akteur: Kunde. Geschäftsobjekte: Auftrag, Angebot, Auftragsbestätigung

(2) Der Vertriebsingenieur (VI) füllt dann im ERP-System ein Auftragsstammblatt (ASB) aus, wobei im Vertrieb gleichzeitig zentral die Auftragsnummer vergeben wird, die auch ins Auftragsstammblatt (ASB) eingetragen wird.

Zweiter Akteur: Abteilung Vertrieb. Datenobjekt Auftragsstammblatt (ASB);

(3) Das Controlling trägt dann die im Angebot bzw. im Auftrag festgelegte Kostenstruktur nach Honorar, Sachkosten, Reisekosten und Fremdleistungskosten auf dem Auftragsstammblatt ein und versieht es mit Vorgaben für Budget, Ressourcenplanung, Reisekosten und Zahlungsplan.

Dritter Akteur: Abteilung Controlling. Ansonsten verlässt die Beschreibung die Ebene der Standardprozessmodellierung und geht in die detaillierte Erläuterung der Aufgabe. So dass wir hier einen Subprozess einfügen. Zuerst einen verborgenen, dann einen entfalteten.

(4) Das Controlling erstellt eine Stundenvorgabe für den Projektleiter, die sich folgendermaßen errechnet: Vom beauftragten Honorar werden zunächst die Fremdleistungen und die geplanten Sachkosten (Reisekosten, Kopierkosten etc.) abgezogen. Nach Abzug eines Gewinns und einer Sicherheitsmarge in Höhe von ca. 16% ergeben sich die verfügbaren Personalkosten. Diese werden durch den Kostensatz der jeweiligen Mitarbeitergruppe geteilt. So ergibt sich die Stundenvorgabe je Mitarbeitergruppe. Alle Ingenieure im Haus sind nach den Jahren ihrer Berufserfahrung unterschiedlichen Gruppen zugeordnet. Jede Gruppe wird zu einem bestimmten Erlösstundensatz abgerechnet bzw. Kostenstundensatz belastet. Ebenso werden Sekretärinnen, studentische Hilfskräfte, Übersetzer, Technische Zeichner usw. mit bestimmten Kostensätzen eingerechnet.

Dabei werden drei Stufen unterschieden. Der erste Kostensatz (Kostensatz Stufe 1) ergibt sich aus dem jeweiligen Gehalt des Mitarbeiters. Die Hinzurechnung der direkten bereichsspezifischen Gemeinkosten ergibt den Kostensatz Stufe 2. Die weitere Addition des unternehmensspezifischen Gemeinkostensatzes ergibt den endgültigen dritten Kostensatz Stufe 3.

Auch solch ein Text sollte misstrauisch machen. Hier wird wieder auch die Ebene der Standardprozessmodellierung verlassen und es werden Aufgaben detailliert erläutert. So dass wir hier einen Subprozess Stundenvorgabe erstellen einfügen. Zuerst verborgen im "Standard"-Business Process Diagram, dann entfaltet im Subprozess.

(5) Das Controlling ermittelt die Rechnungsstellungstermine aufgrund der vertraglichen Vereinbarungen. Bei Honorar nach Aufwand wird nur der Abrechnungsmodus (wöchentlich, monatlich, vierteljährlich, usw.) vermerkt. Bei Pauschalaufträgen sind die Rechnungsstellungstermine in der Regel an den Projektfortschritt gekoppelt und fallen mit Meilensteinen der Projektabwicklung zusammen. Bei den Rechnungsstellungsterminen für diese Aufträge werden die abzurechnenden Beträge bzw. der Prozentanteil des Honorars vermerkt.

Nach Ermittlung der Rechnungsstellungstermine werden dem Kunden durch den Vertrieb die Zahlungstermine mitgeteilt. Parallel hierzu erfolgt die Anlage des Auftrags im Produktionsplanungssystem (PPS) durch das Controlling.

Auch dieser Text erläutert eine Aufgabe, Rechnungsstellungstermine ermitteln, in tiefer Detailliertheit. Wieder wird die Ebene der Standardprozessmodellierung verlassen. So dass wir wieder einen Subprozess einfügen.

(6) Das durch die Abteilung Auftragsabwicklung vervollständigte Auftragsstammblatt wird zur Erstellung der Auftragsmeldung an den Vertrieb zurückgegeben. Die ausgedruckte Auftragsmeldung wird mit den entsprechenden Anlagen (Angebot, Vertrag und sonstige für die Vertragsausführung erforderlichen Dokumente) archiviert. Außerdem werden vom Controlling Kopien an den für die Bearbeitung zuständigen Technikbereich weitergeleitet.

Weitere Abteilung: Auftragsabwicklung.
Weiteres Geschäftsobjekt: Auftragsmeldung

(7) Parallel zur internen Meldung über die Vervollständigung des Auftragsstammblatts hat der Vertriebsingenieur die externe Auftragsbestätigung an den Kunden zu erstellen. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt.

Erfolgte der Auftrag schriftlich und hat der Auftraggeber bereits eine Auftragsbestätigung mitgeschickt, wird diese unterschrieben zurückgesandt.

Erfolgte die Beauftragung mündlich, wird die externe Auftragsbestätig um sämtliche besprochenen Konditionen ergänzt und dem Kunden zugesandt.

Ansonsten wird die externe Auftragsbestätigung dem Kunden zugeschickt.

Abschließend setzt sich der Projektleiter mit dem Kunden in Verbindung, um die Arbeitsaufnahme zu besprechen.

Normaler Prozesslauf. Weiteres Geschäftsobjekt: externe Auftragsbestätigung

2.3.2 Lösungsschritt 1

Prozessbeschreibung, erster Punkt

(1) Nach Eingang des Auftrags prüft der Vertriebsingenieur (VI), ob der Auftrag mit sämtlichen ausgehandelten Konditionen bzw. dem Angebot übereinstimmt. Gibt es keine Abweichungen wird die Auftragsbestätigung erstellt und dem Kunden mitgeteilt. Gibt es im Auftrag des Kunden Abweichungen vom Angebot werden diese in der Auftragsbestätigung durch für das Unternehmen akzeptable Konditionen ersetzt. Dies wird dem Kunden mitgeteilt und er wird gebeten, die Kenntnisnahme schriftlich zu bestätigen. Lehnt der Kunde ab, wird die Ablehnung in der Kundendatenbank vermerkt. Hat der Kunde nach drei Wochen noch nicht geantwortet, wird nachgefragt.

Wie immer bei der Erstellung eines Business Program Diagrams (BPD) sollte zuerst die gesamte Beschreibung gelesen und der Prozess als Ganzes verstanden werden. Dabei kann man auch die handelnden Einheiten in diesem Geschäftsprozess identifizieren: Der Kunde, im Unternehmen der Vertriebsingenieur (VI), der Vertrieb, das Controlling, die Auftragsabwicklung und der Projektleiter. Entsprechend werden die Becken und Bahnen angelegt. Vgl. Abbildung 2.3-1. Um die Abbildung übersichtlich zu halten, werden folgende Abkürzungen verwendet:

• AM für Auftragsmeldung
• ASB für Auftragsstammblatt
• ABS für Auftragsbestätigung

Punkt (1) der Prozessbeschreibung kann durch ein Nachrichten-Startereignis (top level) in der Bahn Vertriebsingenieur (VI) modelliert werden. Da die Übersendung des Auftrags durch den Kunden in der Anforderungsbeschreibung nicht angesprochen wird, erscheint sie auch nicht im Prozessmodell.

Vgl. Abb. 2.3-1

Es folgt die Aufgabe Übereinstimmung prüfen mit den zu lesenden Datenobjekten Auftrag und Angebot. Der Text beschreibt dann eine Entscheidungssituation mit den zwei möglichen Ergebnissen In Ordnung bzw. Abweichung. Dies wird durch ein verzweigendes Exclusive Gateway modelliert. Ergibt die Prüfung keine Abweichungen wird die Auftragsbestätigung erstellt und der Kunde informiert. Diese wird durch eine Nachricht an das Kundenbecken modelliert, was in dieser Methode erlaubt ist.

Ergibt die Prüfung des Auftrags Abweichungen vom Angebot werden diese durch akzeptable Konditionen ersetzt. Dafür wird eine Aufgabe Akzeptable Konditionen eintragen eingefügt, die lesend und schreibend auf das Datenobjekt Auftrag zugreift.

Nun fordert die Anforderungsbeschreibung, den Kunden zu informieren und um seine Zustimmung zu bitten. Dafür wird eine Aufgabe Kunde um Bestätigung bitten und eine Nachricht zum Kunden eingefügt. Der veränderte Auftrag wird an den Nachrichtenpfeil angefügt. Das Exclusive Gateway vor der Aufgabe dient einer Rückschleife, dazu unten mehr.

Vgl. Abbildung 2.3-1

Ausschnitt aus Abbildung 2.3-1: Auftragseingang.

Das Senden des veränderten Auftrags zum Kunden wird also durch eine Nachricht ins Becken des Kunden direkt zur ersten Aufgabe Änderungen prüfen modelliert, wo dann der entsprechende Entscheidungsprozess stattfindet.

Dieser im Text nur angedeutete Prozessabschnitt wird wie folgt modelliert. Nach einem Startereignis (top level) folgt die oben erwähnte Aufgabe Änderungen prüfen mit dem Lesezugriff auf das Datenobjekt Auftrag. Es folgt ein verzweigendes Exclusive Gateway mit den möglichen Ergebnissen zustimmen / ablehnen. Danach folgt jeweils eine Sender-Aufgabe, Zustimmung mitteilen bzw. Ablehnung mitteilen und ein Schlussereignis. Von den beiden Sender-Aufgaben führen Nachrichtenpfeile ins Becken des Unternehmens in die Bahn des VI.

Beim Kunden

Ausschnitt aus Abbildung 2.3-1: Änderungsprüfung beim Kunden.

Für den Vertriebsingenieur (VI) ergibt sich nun eine Wartesituation, die durch ein ereignisbasiertes Exclusive Gateway modelliert wird. Von diesem gehen drei Sequenzflüsse weg. Zwei zu empfangenden Nachrichten-Zwischenereignissen (Zusage, Absage), einer zu einem Zeitgeber-Zwischenereignis des Typs catching ("3 Wochen vergangen").

Pos. 2 in der Abbildung

Die beiden Nachrichtenzwischenereignisse können zur Fortsetzung des Flusses führen: Eingang der Absage oder Eingang der Zusage (dass die Änderungen akzeptiert werden). Beide kommen vom Kunden, modelliert als empfangende Zwischenereignisse.

• Kam eine Absage, wird dies durch die Aufgabe Ablehnung vermerken, das zu beschreibende Datenobjekt Kundendatenbank und ein Beenden-Ereignis (terminate) modelliert.
• Kam eine Zusage wird der Sequenzfluss mit dem positiven Ergebnis der Prüfung zusammengeführt (Pos. 3). Das Verschmelzen der beiden Sequenzflüsse wird mit Hilfe eines verknüpfenden Exclusive Gateway modelliert, da die Verzweigung flussaufwärts durch einen ebensolchen verursacht war.

Das Zeitgeber-Zwischenereignis im dritten Sequenzfluss erlaubt das Modellieren der Wartezeit von drei Wochen, wie in der Prozessbeschreibung verlangt. Danach führt der Sequenzfluss zur Aufgabe Nachfragen. Hier wird die Beschreibung lückenhaft. Deshalb wurde hier angenommen, dass das Nachfragen zu einer Änderung des Auftrags führt und dass dieser geänderte Auftrag wieder dem Kunden übersandt wird. In der BPD führen wir dazu den Sequenzfluss von Nachfragen mit Hilfe eines verknüpfenden Exclusive Gateway zusammen mit dem von Akzeptable Konditionen eintragen und damit zur Aufgabe Kunde um Bestätigung bitten. Es entsteht also hier eine Schleife.

Warten

Eine solche Ergänzung einer lückenhaften Prozessbeschreibung benötigt in der wirklichen Welt natürlich der Bestätigung und Präzisierung durch die Auftraggeber.

Damit ist Punkt (1) der Prozessbeschreibung abgearbeitet. Die folgende Abbildung zeigt das Ergebnis. Hier sind auch die angelegten Bahnen und Becken erkennbar.

Abbildung 2.3-1: Auftragsstart im Anlagenbau, Teil 1 - Auftragseingang und Prüfung

Abkürzungen:
AM: Auftragsmeldung, ASB: Auftragsstsammblatt, ABS: Auftragsbestätigung
VI: Vertriebsingenieur, VBL: Vertriebsbereichsleiter
Enthaltene Elemente (Auswahl):
- Bahnen
- Becken
- Datenobjekt (lesend))
- Datenobjekt (verändernd))
- Exclusive Gateway / datenbasiert und verknüpfend
- Exclusive Gateway / datenbasiert und verzweigend
- Exclusive Gateway / ereignisbasiert und verzweigend
- Implizites verknüpfendes Exclusive Gateway
- Muster Rücksprung
- Nachrichtenfluss
- Nachrichten-Schlussereignis, abgebend
- Nachrichten-Startereignis
- Nachrichten-Zwischenereignis, empfangend
- Verknüpfungs-Zwischenereignis / abgebend
- Verknüpfungs-Zwischenereignis / empfangend
- Zeitgeber

2.3.3 Lösungsschritt 2

Vgl. bzgl. der Aufteilung Prozess- vs. Funktionsmodellierung die Prozessbeschreibung in 2.3.1.

Prozessbeschreibung - Fortsetzung

(2) Der Vertriebsingenieur (VI) füllt dann im ERP-System ein Auftragsstammblatt (ASB) aus, wobei im Vertrieb gleichzeitig zentral die Auftragsnummer vergeben wird, die auch ins Auftragsstammblatt (ASB) eingetragen wird.

Muster Teilaufgaben

(3) Das Controlling trägt dann die im Angebot bzw. im Auftrag festgelegte Kostenstruktur nach Honorar, Sachkosten, Reisekosten und Fremdleistungskosten auf dem Auftragsstammblatt ein und versieht es mit Vorgaben für Budget, Ressourcenplanung, Reisekosten und Zahlungsplan.

(4) Das Controlling erstellt eine Stundenvorgabe für den Projektleiter, die sich folgendermaßen errechnet: Vom beauftragten Honorar werden zunächst die Fremdleistungen und die geplanten Sachkosten (Reisekosten, Kopierkosten etc.) abgezogen. Nach Abzug eines Gewinns und einer Sicherheitsmarge in Höhe von ca. 16% ergeben sich die verfügbaren Personalkosten. Diese werden durch den Kostensatz der jeweiligen Mitarbeitergruppe geteilt. So ergibt sich die Stundenvorgabe je Mitarbeitergruppe. Alle Ingenieure im Haus sind nach den Jahren ihrer Berufserfahrung unterschiedlichen Gruppen zugeordnet. Jede Gruppe wird zu einem bestimmten Erlösstundensatz abgerechnet bzw. Kostenstundensatz belastet. Ebenso werden Sekretärinnen, studentische Hilfskräfte, Übersetzer, Technische Zeichner usw. mit bestimmten Kostensätzen eingerechnet.

Dabei werden drei Stufen unterschieden. Der erste Kostensatz (Kostensatz Stufe 1) ergibt sich aus dem jeweiligen Gehalt des Mitarbeiters. Die Hinzurechnung der direkten bereichsspezifischen Gemeinkosten ergibt den Kostensatz Stufe 2. Die weitere Addition des unternehmensspezifischen Gemeinkostensatzes ergibt den endgültigen dritten Kostensatz Stufe 3.

(5) Das Controlling ermittelt die Rechnungsstellungstermine aufgrund der vertraglichen Vereinbarungen. Bei Honorar nach Aufwand wird nur der Abrechnungsmodus (wöchentlich, monatlich, vierteljährlich, usw.) vermerkt. Bei Pauschalaufträgen sind die Rechnungsstellungstermine in der Regel an den Projektfortschritt gekoppelt und fallen mit Meilensteinen der Projektabwicklung zusammen. Bei den Rechnungsstellungsterminen für diese Aufträge werden die abzurechnenden Beträge bzw. der Prozentanteil des Honorars vermerkt.

Nach Ermittlung der Rechnungsstellungstermine werden dem Kunden durch den Vertrieb die Zahlungstermine mitgeteilt. Parallel hierzu erfolgt die Anlage des Auftrags im Produktionsplanungssystem (PPS) durch das Controlling.

Wir kommen nun zu Punkt 2 der Prozessbeschreibung. Der Text signalisiert, dass im positiven Fortgang des Geschäftsprozesses zwei Aufgaben angestoßen werden. Dies wird mit einem Parallel Gateway modelliert (Pos. 4 in der Abb.). Die erste Aufgabe wird vom Vertriebsingenieur (VI) im ERP-System, die zweite durch die Abteilung Vertrieb realisiert. Beide beschreiben das Datenobjekt Auftragsstammblatt (ASB). Für dieses wird hier angenommen, dass es von zwei verschiedenen Personen gleichzeitig bearbeitet werden kann.

Parallelität

Danach können die beiden Sequenzflusszweige wieder zusammengeführt werden (verknüpfendes Parallel Gateway). Dies ist ein anschauliches Beispiel für das Muster Zeitfenster. Es ist i.d.R. mit Teilaufgaben verbunden.

Muster Zeitfenster

Anschließend folgt die im obigen Text angeführte Erfassung der Kostenstruktur durch die Organisationseinheit Controlling. Hier ist im Text wiederum auch die konkrete (innere, funktionale) Realisierung der Aufgabe angedeutet. Der Prozessanteil besteht hier nur aus einem verborgenen Subprozess (Kostenstruktur eintragen). Genauer werden dann die Tätigkeiten im zugehörigen entfalteten Subprozess beschrieben (vgl. unten).

Prozess vs. Funktion

Ein solches Muster muss man erkennen, wenn man eine Prozessbeschreibung bekommt: Was ist Prozess-, was ist Funktionsbeschreibung? Vgl. hierzu auch [Staud 2014, Abschnitt 12.4] und weitere Beispiele unten.

In den folgenden Punkten folgen zwei weitere solche Funktionsbeschreibungen. Zum einen die Erstellung der Stundenvorgabe (Stundenvorgabe erstellen), zum anderen ein Regelwerk zur Bestimmung der Rechnungsstellungstermine (Rechnungsstellungstermine ermitteln). Dies ist jeweils nichts anderes als die Beschreibung die Festlegung der inneren Abläufe der Aufgabe. Wir haben es hier also wieder und viel deutlicher als oben mit dem Gegensatz von Prozess- und Funktionsmodellierung zu tun.

Nochmals
Prozess vs. Funktion

Prozessmodellierung vs. Funktionsmodellierung

Bei der Erhebung eines Geschäftsprozesses bekommt man nicht immer nur Hinweise auf den Prozessablauf, sondern auch auf die Realisierung einzelner Funktionen. Dies muss man erkennen und das festgelegte Beschreibungsniveau einhalten [Anmerkung] .

Unter Beachtung dieser Regel entsteht hier für die Erstellung der Stundenvorgabe ein einziger verborgener Subprozess mit der Bezeichnung Stundenvorgabe erstellen. Das Regelwerk (die Funktionsbeschreibung) kann in einem entfalteten Subprozess dargestellt werden. Vgl. dazu unten.

Auch die Ermittlung der Rechnungsstellungstermine wird durch einen Subprozess dargestellt. Im zugehörigen entfalteten Subprozess ist die Funktionalität dargestellt. Nach diesem Subprozess werden zwei Aufgaben angestoßen. Dies wird mit einem Parallel Gateway (Pos. 5 in der Abb.) und den zwei Aufgaben Zahlungstermine mitteilen (als Sender-Aufgabe) durch den Vertrieb und Anlage Auftrag im PPS (als Nutzer-Aufgabe) durch das Controlling modelliert.

Rechnungs-
stellungs-
termine

Bei der Mitteilung der Zahlungstermine wird ein Nachrichtenfluss von der Sender-Aufgabe zum Rand des Kunden-Becken eingerichtet. Das ist erlaubt, man überlässt dann sozusagen die Zuordnung der Nachricht dem Kunden.

Da nach der Aufgabe Anlage Auftrag im PPS zwei Aufgaben folgen (vgl. unten), werden hier noch ein Parallel Gateway und zwei weiterführende Sequenflüsse eingefügt.

Die folgende Abbildugn zeigt den jetzt modellierten Prozessabschnitt.

Abbildung 2.3-2: Auftragsstart im Anlagenbau, Teil 2 - Planen und Erfassen

Enthaltene Elemente (Auswahl) und Muster:
- Datenobjekt (lesend))
- Datenobjekt (verändernd))
- Exclusive Gateway / datenbasiert und verzweigend
- Muster Teilaufgaben
- Muster Zeitfenster
- Nutzer-Aufgabe
- Parallel Gateway, verknüpfend
- Parallel Gateway, verzweigend
- Sender-Aufgabe
- Subprozess, verborgen
- Verknüpfungs-Zwischenereignis / abgebend
- Verknüpfungs-Zwischenereignis / empfangend
Besondere Theorieaspekte:
- Prozess- vs. Funktionsmodellierung
- Start paralleler Teilaufgaben

2.3.4 Lösungsschritt 3

Prozessbeschreibung - Fortsetzung

(6) Das durch die Abteilung Auftragsabwicklung vervollständigte Auftragsstammblatt wird zur Erstellung der Auftragsmeldung an den Vertrieb zurückgegeben. Die ausgedruckte Auftragsmeldung wird mit den entsprechenden Anlagen (Angebot, Vertrag und sonstige für die Vertragsausführung erforderlichen Dokumente) archiviert. Außerdem werden vom Controlling Kopien an den für die Bearbeitung zuständigen Technikbereich weitergeleitet.

(7) Parallel zur internen Meldung über die Vervollständigung des Auftragsstammblatts hat der Vertriebsingenieur die externe Auftragsbestätigung an den Kunden zu erstellen. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt.

Erfolgte der Auftrag schriftlich und hat der Auftraggeber bereits eine Auftragsbestätigung mitgeschickt, wird diese unterschrieben zurückgesandt.

Erfolgte die Beauftragung mündlich, wird die externe Auftragsbestätig um sämtliche besprochenen Konditionen ergänzt und dem Kunden zugesandt.

Ansonsten wird die externe Auftragsbestätigung dem Kunden zugeschickt.

Abschließend setzt sich der Projektleiter mit dem Kunden in Verbindung, um die Arbeitsaufnahme zu besprechen.

Die Punkte (6) und (7) der Anforderungsbeschreibung beschreiben zwei parallel zu erledigende Aufgaben, die Vervollständigung des Auftragsstammblattes in der Auftragsabwicklung und die Erstellung der externen Auftragsbestätigung durch den VI. Deshalb wird an Position 6 der Abbildung ein Parallel Gateway eingefügt mit Sequenzflüssen zu den zwei entsprechenden Aufgaben.

Punkt (6) muss sehr genau gelesen werden. Schon der erste Halbsatz fordert zwei Handlungen: Das Übersenden des Auftragsstammblatts (ABS) an die Auftragsabwicklung und dort dessen Vervollständigung. Dafür wird die Aufgabe, Vervollständigung ASB und Weiterleitung, in der Auftragsabwicklung angelegt. Im zweiten Halbsatz folgt dann gleich die nächste Aufgabe, Erstellung Auftragsmeldung, durch den Vertrieb. Diese beiden Aufgaben sind hintereinander angeordnet und werden deshalb per Sequenfluss verbunden. In der ersten Aufgabe wird das Datenobjekt ASB beschrieben, dann transportiert (angehängt am Sequenzfluss) und schließlich gelesen. Bei der Erstellung der Auftragsmeldung wird außerdem das Datenobjekt AM beschrieben.

Anschließend wird die Weiterleitung bzw. Archivierung der Auftragsmeldung beschrieben. Dies wird durch zwei parallel [Anmerkung] anzustoßende Funktionen modelliert. Deshalb folgt wieder ein Parallel Gateway. Der Vertrieb realisiert AM mit Anlagen archivieren, das Controlling Kopien zumTechnikbereich geben. Mit den nachfolgenden Schlussereignissen kommen diese Sequenzflusszweige an ihr Ende, der Geschäftsprozess geht aber - verursacht durch das aufteilende Parallel Gateway von Position (6) - weiter.

Transportvorgänge können in der Prozessmodellierung ausdrücklich eingefügt, weggelassen oder mit der "benachbarten" Aktivität zusammengefasst werden (Aggregation). Hier wurde diesmal Letzteres gewählt. Aus der Aktivität Vervollständigung ASB wurde Vervollständigung ASB und Weiterleitung. Die Datenobjekte wurden entsprechend (erzeugend; lesend; am Sequenzfluss) eingefügt.

Transport-
vorgänge

Punkt (7) der Prozessbeschreibung führt zurück zum Parallel Gateway von Punkt 6 der Abbildung und zur parallel angestoßenen Aufgabe Externe Auftragsbestätigung erstellen mit den zwei Datenobjekten Externe ABS (wird erstellt) und ABS (wird gelesen). Die im Text angeführten Mitwirkenden werden noch hinzugefügt.

Der weitere Verlauf hängt nun davon ab, auf welche Weise die Beauftragung erfolgte. Deshalb wird nun die Aufgabe Klärung Auftragsvergabe (Pos. 7) mit nachfolgendem Exclusive Gateway eingefügt wird. Sie wird vom Vertriebsingenieur realisiert. Da im Text kein Hinweis vorliegt, wie diese Klärung erfolgt, wird dies im Modell nicht weiter präzisiert. Diese Prüfung kann zu den drei in der Anforderung angeführten alternativen Ergebnissen führen (deshalb folgt ein Exclusive Gateway):

• Auftragsvergabe schriftlich mit Auftragsbestätigung, d.h. der Kunde hat gleich bei der Auftragsvergabe die Auftragsbestätigung mitgeschickt. In diesem Fall wird einfach die ABS zum Kunden geschickt, modelliert durch eine Sender-Aufgabe (ABS unterschrieben zurücksenden), deren Nachrichtenpfeil zum Becken des Kunden führt (mit dem Datenobjekt Kunden-ABS, unterschrieben.
• Auftragsvergabe mündlich. Danach wird die Aufgabe Externe Auftragsbestätigung ergänzen eingefügt, mit dem zu beschreibenden Datenobjekt Externe ABS.
• Auftragsvergabe auf sonstige Weise. Dies soll auch die Voreinstellung sein (deshalb der Backslash). Die hier eingefügte Sender-Aufgabe erfasst das finale Erstellen und Versenden der externen ABS. Auch hier wird die externe ABS beschrieben. Der Nachrichtenpfeil wird wieder an den Beckenrand des Kunden geführt.

Diese drei alternativen Sequenzflusszweige werden durch ein verknüpfendes Exclusive Gateway wieder zusammengeführt (Pos 9 in der Abbildung). Von diesem führt ein Sequenzfluss in die Bahn Projektleiter zur Aufgabe Kontaktaufnahme mit dem Kunden und zum Schlussereignis (terminate) für den Gesamtprozess.

Die folgende Abbildung zeigt den letzten Teil des Geschäftsprozesses.

Abbildung 2.3-3: Auftragsstart im Anlagenbau, Teil 3 - Klärung und Schluss

Abkürzungen:
Ext. ABS: Externe Auftragsbestätigung
Enthaltene Elemente (Auswahl):
- Sender-Aufgabe
- Exclusive Gateway / datenbasiert und verknüpfend
- Exclusive Gateway / datenbasiert und verzweigend
- Nachrichtenfluss
- Datenobjekt (Erzeugung)
- Datenobjekt (lesend))
- Datenobjekt (verändernd)
- Datenobjekt am Sequenzfluss
- Parallel Gateway, verzweigend
- Voreinstellung bzgl Sequenzfluss

2.3.5 Gesamtlösung

Den Geschäftsprozess als Ganzes kann die folgende Abbildung nur andeuten. Sie kann hier aus technischen Gründen nicht besser dargestellt werden. Eine größere und grafisch detailliertere Version dieser Grafik findet sich hier:
https://www.staud.info/grafiken2020/Grafiken.php

Abbildung 2.3-4: Auftragsstart im Anlagenbau, das gesamte BPD

2.4 Auftragsstart, die Subprozesse

2.4.1 Überblick

In der folgenden Abbildung sind die verborgenen Subprozesseaus dem Geschäftsprozess des vorigen Abschnitts zusammengestellt.

• Kostenstruktur eintragen
• Stundenvorgabe erstellen und
• Rechnungsstellungstermine ermitteln

Sie erfassen jeweils Aufgaben, die durch Beschreibung ihrer inneren Struktur näher spezifiziert werden. Aus dem Subprozess Stundenvorgabe erstellen wird noch der Subprozess Kostenstundensätze bestimmen aufgerufen. Dazu unten mehr. Damit ergibt sich die in der folgenden Abbildung angegebene Aufrufstruktur.

Abbildung 2.4-1: Alle verborgenen Subprozesse des Geschäftsprozesses und ihre Aufrufstruktur

Diese Aufteilung in Subprozesse ist teilweise didaktisch motiviert. Durch sie soll die Trennung der Modellierung von Funktionen und Prozessen deutlich gemacht werden.

2.4.2 Kostenstruktur eintragen

Ausschnitt aus der Prozessbeschreibung in Abschnitt 2.3

(3) Das Controlling trägt dann die im Angebot bzw. im Auftrag festgelegte Kostenstruktur nach Honorar, Sachkosten, Reisekosten und Fremdleistungskosten auf dem Auftragsstammblatt ein und versieht es mit Vorgaben für Budget, Ressourcenplanung, Reisekosten und Zahlungsplan.

Die Methode BPMN sieht vor, dass der Sequenzfluss einfach an das Symbol für den Subprozess rangeführt wird. Auch bei entfalteten Subprozessen. Dieser enthält dann ein Startereignis. Dieses wird ausgelöst, wenn der zum Subprozess führende Sequenzfluss aktiv wird ("das Token ankommt"). Die Prozessbeschreibung kann dann so interpretiert werden, dass zuerst eine Aufgabe Festgelegte Kostentruktur eintragen mit den Datenobjekten Auftrag (wird gelesen) und ASB (wird beschrieben) eingefügt wird. Dann folgt die Aufgabe Vorgaben ergänzen mit dem Datenobjekt ASB und einer textlichen Ergänzung. Die folgende Abbildung zeigt den entfalteten Subprozess.

Abbildung 2.4-2: Prozess Auftragsstart im Anlagenbau, Subprozess Kostenstruktur eintragen

Methodenelemente (Auswahl):
- Datenobjekt (lesend))
- Datenobjekt (verändernd)
- Schlussereignis
- Startereignis
- Subprozess, entfaltet

2.4.3 Stundenvorgabe erstellen

Ausschnitt aus der Prozessbeschreibung in Abschnitt 2.3

(4) Das Controlling erstellt eine Stundenvorgabe für den Projektleiter, die sich folgendermaßen errechnet: Vom beauftragten Honorar werden zunächst die Fremdleistungen und die geplanten Sachkosten (Reisekosten, Kopierkosten etc.) abgezogen. Nach Abzug eines Gewinns und einer Sicherheitsmarge in Höhe von ca. 16% ergeben sich die verfügbaren Personalkosten. Diese werden durch den Kostensatz der jeweiligen Mitarbeitergruppe geteilt. So ergibt sich die Stundenvorgabe je Mitarbeitergruppe. Alle Ingenieure im Haus sind nach den Jahren ihrer Berufserfahrung unterschiedlichen Gruppen zugeordnet. Jede Gruppe wird zu einem bestimmten Erlösstundensatz abgerechnet bzw. Kostenstundensatz belastet. Ebenso werden Sekretärinnen, studentische Hilfskräfte, Übersetzer, Technische Zeichner usw. mit bestimmten Kostensätzen eingerechnet.

Vgl. auch 2.3.1

Dabei werden drei Stufen unterschieden. Der erste Kostensatz (Kostensatz Stufe 1) ergibt sich aus dem jeweiligen Gehalt des Mitarbeiters. Die Hinzurechnung der direkten bereichsspezifischen Gemeinkosten ergibt den Kostensatz Stufe 2. Die weitere Addition des unternehmensspezifischen Gemeinkostensatzes ergibt den endgültigen dritten Kostensatz Stufe 3.

Der erste Satz gibt sozusagen die verborgene Variante des Subprozesses wieder, der Text danach die entfaltete. Die Ausführungen werden in Aufgaben und beteiligte Datenobjekte abgebildet. Nach dem Startereignis folgt die Aufgabe Beauftragtes Honorar bestimmen mit den zu lesenden Datenobjekten ASB und Auftrag. Es folgt die Aufgabe Fremdleistungen und Sachkosten abziehen. Sie beschreibt ein Datenobjekt Kalkulation. Durch ein Textelement wird die Aufgabe noch präzisiert.

Anschließend wird die Aufgabe Verfügbare Personalkosten bestimmen mit textlichen Präzisierungen eingefügt. Auch sie beschreibt das Datenobjekt Kalkulation.

Im Text folgt nun eine Beschreibung die noch detaillierter ist und quasi zu einer Rechenvorschrift führt, die Bestimmung der Kostenstundensätze. Für sie wird ein eigener Subprozess eingerichtet. Hier wird er erstmal als verborgener Subprozess Kostenstundensätze bestimmen eingefügt. Mit der Aufgabe Stundenvorgabe berechnen (beschreiben Datenobjekt Kalkulation, erläutert durch textliche Anmerkung) und einem Schlussereignis endet der Subprozess.

"Sub-Sub-Prozess"

Abbildung 2.4-3: Prozess Auftragsstart im Anlagenbau, Subprozess Stundenvorgabe für Projektleiter erstellen

Methodenelemente (Auswahl):
- Datenobjekt (lesend))
- Datenobjekt (verändernd)
- Schlussereignis
- Startereignis
- Subprozess, entfaltet
- Subprozess, verborgen

Nun zur Bestimmung der Kostenstundensätze

Die detaillierte Beschreibung der Bestimmung der Kostenstundensätze beginnt oben mit "Alle Ingenieure ...". Hier wird angenommen, dass diese Bestimmung schrittweise nacheinander für die Beschäftigten erfolgt, deshalb die Rückschleife und am Ende die Prüfung, ob schon alle bearbeitet sind.

Der Subprozess beginnt mit einem Startereignis, gefolgt von einem Exclusive Gateway für die Rückschleife. Die erste Aufgabe klärt, ob nach einem Erlösstundensatz abgerechnet oder mit einem Kostenstundensatz belastet wird. Es wird angenommen, dass dies jeweils in einem Dokument (hier als Datenobjekt modelliert) festgehalten wird. Falls es um einen Erlösstundensatz geht, wird die Aufgabe Erlösstundensatz klären ausgeführt. Geht es um Kostenstundensätze werden nacheinander die drei Kostensatz-Stufen bestimmt. Danach werden die beiden Sequenzflüsse wieder mit einem verknüpfenden Exclusive Gateway zusammengeführt. Die nachfolgende Prüfung führt mit Hilfe eines verzweigenden Exclusive Gateway entweder zum Schluss des Subprozesses ("Alle bearbeitet") und damit zum Rücksprung in den aufrufenden Subprozess oder zurück an den Anfang ("Nicht alle bearbeitet"; Rücksprung), um die nächste Person einzuarbeiten.

Die Datenobjekte sind in der Prozessbeschreibung nicht präzise ausgeführt. Sie wurden hier, soweit es möglich war, eingefügt. Zum einen als Datenobjekte, die gelesen werden (Gehaltsangaben, Gemeinkosten, ...), zum anderen als zu beschreibende (Kalkulation). In einer realen Modellierungssituation müsste dies durch Nachfragen geklärt werden.

Abbildung 2.4-4: Prozess Auftragsstart im Anlagenbau, entfalteter Subprozess Kostenstundensätze bestimmen

Enthaltene Elemente (Auswahl):
- Datenobjekt (lesend))
- Datenobjekt (verändernd)
- Exclusive Gateway / datenbasiert und verknüpfend
- Exclusive Gateway / datenbasiert und verzweigend
- Muster Rücksprung
- Schlussereignis
- Startereignis
- Subprozess, entfaltet

2.4.4 Rechnungsstellungstermine ermitteln

Bleibt noch der vierte entfaltete Subprozess, der die Ermittlung der Rechnungsstellungstermine beschreibt. Zuerst wieder die Prozessbeschreibung von oben:

Ausschnitt aus der Prozessbeschreibung in Abschnitt 2.3

(5) Das Controlling ermittelt die Rechnungsstellungstermine aufgrund der vertraglichen Vereinbarungen. Bei Honorar nach Aufwand wird nur der Abrechnungsmodus (wöchentlich, monatlich, vierteljährlich, usw.) vermerkt. Bei Pauschalaufträgen sind die Rechnungsstellungstermine in der Regel an den Projektfortschritt gekoppelt und fallen mit Meilensteinen der Projektabwicklung zusammen. Bei den Rechnungsstellungsterminen für diese Aufträge werden die abzurechnenden Beträge bzw. der Prozentanteil des Honorars vermerkt.

Hier muss auch wieder an den Beginn eine Entscheidung gesetzt werden, die per Exclusive Gateway entweder zur Berechnung des Honorars nach Aufwand oder zu den Pauschalaufträgen führt. Im ersten Fall wird dann der Abrechnungsmodus vermerkt, im zweiten Fall werden zuerst die Projektmeilensteine geklärt und dann die abzurechnenden Beträge bzw. Prozentanteile vermerkt. In beiden Fällen folgt anschließend ein Schlussereignis, das den Sequenzfluss zurück in den aufrufenden Subprozess führt. Die Beschreibung der Datentransfers ist auch wieder lückenhaft, sie müsste in einer realen Modellierungssituation nachgefragt werden.

Abbildung 2.4-5: Prozess Auftragsstart im Anlagenbau, Subprozess Rechnungsstellungstermine ermitteln

Enthaltene Elemente (Auswahl):
- Datenobjekt (lesend))
- Datenobjekt (verändernd)
- Exclusive Gateway / datenbasiert und verzweigend
- Schlussereignis
- Startereignis
- Subprozess, entfaltet

2.5 Zoo - Tieraufnahme

2.5.1 Prozessbeschreibung

Die folgenden Geschäftsprozesse sind in einem fiktiven Zoo angesiedelt. Alles natürlich stark vereinfacht. Konkret geht es um die Aufnahme eines neuen Tieres (größere Tiere, wie Säugetiere, Reptilien, ...).

Geschäftsprozess Tieraufnahme

Der Prozess Tieraufnahme beginnt damit, dass ein neues Tier eintrifft (von einem anderen Zoo, von einem Tierhändler, usw.) und vom Tierarzt sowie Pfleger in Empfang genommen wird. Als erstes wird vom Tierarzt des Zoos (Zootierarzt) in der Datenbank des Zoos (ZooDB) eine sog. Tierakte für das neue Tier angelegt. Dabei werden auch einige Daten (Geburtstag, Geburtsort, Aufenthalte, ...) aus den Transportbegleitpapieren ("Begleitheft") des Tieres übernommen.

Danach wird das Tier gewogen - vom zukünftigen Pfleger, der auch den Eintrag des Gewichts in die Tierakte vornimmt - und es werden 20 zentrale Blutwerte festgestellt (Blutfettwerte, Eisengehalt, Mineralien, ...). Dies erledigt der Zootierarzt, der diese Ergebnisse in die Tierakte in der ZooDB einträgt.

Falls der Zootierarzt feststellt, dass es sich um ein gefährliches Tier handelt, wird das Tier vor den obigen Untersuchungen vom Zootierarzt betäubt.

Der weitere Fortgang hängt von den Ergebnissen obiger Untersuchungen ab. Dabei wird vereinfacht: Bezüglich des Gewichts ist nur wichtig, ob das Tier Übergewicht hat oder nicht. Bezüglich der Blutwerte wird nur unterschieden, ob alle Werte mindestens 70% des maximalen Werts erreichen ("Status 70"), ob alle Werte mindestens 50% des maximalen Werts erreichen ("Status 50") oder dies nicht erreicht wird, einzelne Werte also unter 50% des maximalen Werts liegen ("Blutwerte negativ").

- Falls die Blutwerte negativ sind, wird das Tier zurückgeschickt zur Herkunftsstelle. Dazu wird der Geschäftsprozess Rücksendung angestoßen.

-Falls das Tier kein Übergewicht hat und den Status 70 wird es durch den Zootierarzt offiziell in den Zoo aufgenommen. Dies wird in der Tierakte und in der Zoodatenbank vermerkt.

-Falls das Tier kein Übergewicht hat, aber nur den Status 50 erreicht, wird es auf den Aufnahmestatus Warten gesetzt. Danach wird es eine Woche isoliert. Wenn die Woche vergangen ist, wird die gesamte Untersuchung bzgl. Gewicht und Blutwerten wiederholt. Dies dient dazu, um festzustellen, ob die nicht so positiven Blutwerte vielleicht stressbedingt sind (durch den Transport). Fallen die Werte bei der zweiten Untersuchung wieder so aus ("Kein Übergewicht", "Status 50"), wird das Tier zurückgeschickt. D.h., es geht weiter zum Prozess Rücksendung.

-Falls das Tier Übergewicht hat und den Status 70, wird es aufgenommen. Allerdings wird ein Diätplan erstellt (vom Zoodiätassistenten (DiätAss)), der in die Tierakte eingetragen wird.

-Falls das Tier Übergewicht hat und nur den Status 50 erreicht, wird es zurückgesandt. Dieser Sachverhalt wird in die Tierakte eingetragen. und es wird der Prozess Rücksendung gestartet.

Für die Rücksendung eines Tieres ist folgendes zu leisten:

- Die Tatsache der Rücksendung wird von der Zooleitung in den Begleitpapieren und in der Tierakte der ZooDB vermerkt.

- Parallel sendet die Zooleitung zusammen mit dem Zootierarzt eine Mail an die Herkunftsstelle. In ihr wird die Rückkehr des Tieres angekündigt und der Grund für die Rücksendung angegeben.

- Danach erfolgt eine Terminvereinbarung für den Rücktransport des Tieres mit dem (Tier-) Transportunternehmen. Dies erledigt die Zooleitung zusammen mit der "Rücksendestelle" und natürlich mit dem Transportunternehmen.

2.5.2 Lösungsschritte

Wie immer sollen zuerst die Akteure und die Prozessstruktur bestimmt werden. Der Gesamtprozess teilt sich auf in einen Geschäftsprozess Tieraufnahme und einen, der die eventuelle Rücksendung eines Tieres beschreibt. Folgende Akteure können der Beschreibung entnommen werden:

• Für die Tieraufnahme der Zootierarzt, der Diätassistent und der Pfleger
• Für die Rücksendung zusätzlich die Herkunftsstelle, die Rücksendestelle, die Zooleitung und das Transportunternehmen

Tieraufnahme

Für diesen Prozess werden das Becken zum Anwendungsbereich Zoo und die Bahnen für die oben angeführten Akteure angelegt. Der Prozess startet durch eine gemeinsame Aktion von Zootierarzt und Pfleger, der Entgegennahme des Tieres. Dies wird durch zwei Startereignisse und zwei Aufgaben modelliert.

Vgl. die folgende Abbildung

Die Punkt-Strich-Linie drückt die Zusammenarbeit aus. Die nächsten Schritte werden vom Tierarzt getätigt. Das Anlegen der Tierakte in der Zoodatenbank, bei der das Begleitheft ausgewertet und die Tierakte angelegt und beschrieben wird. Diese beiden Datenobjekte werden mit entsprechenden Pfeilen angelegt.

Zusammenarbeit

Anschließend erfolgt die Prüfung der Gefährlichkeit des Tieres mit der eventuellen Betäubung (die weiter unten in den Anforderungen angesprochen wird). Das Ergebnis der Prüfung wird im Datenobjekt Tierakte festgehalten. Die beiden möglichen Ergebnisse der Prüfung werden durch ein Exlusive Gateway modelliert, wobei hier ein wegführender Zweig (Tier nicht gefährlich) keine Aktion erfordert und deshalb gleich wieder mit einem Exclusive Gateway mit dem anderen Sequenzfluss zusammengeführt wird. Der Prozess führt dann zur Pflegerin, die das Gewicht feststellt und in die Tierakte einträgt, was wiederum einen Schreibvorgang im Datenobjekt Tierakte erfordert.

Abbildung 2.5-1: Geschäftsprozess Tieraufnahme, Teil 1. Ausschnitt aus dem Gesamtmodell.

Es folgt die Bestimmung der Blutwerte durch den Zootierarzt und deren Eintrag in die Tierakte. Dies wird durch eine Aufgabe Blutwerte bestimmen und dem zu beschreibenden Datenobjekt Tierakte im Business Process Diagram (BPD) umgesetzt. Die Beschreibung zum Fortgang des Prozesses legt nun ein Complex Gateway mit folgenden abgehenden Sequenzflüssen und nachfolgenden Aufgaben nahe:

• Blutwerte negtiv. Dieser Sequenzflusszweig wird mit dem nächsten mittels eine Exclusive Gateway verbunden, dann zu einem Subprozess Rücksendung und zu einem Schlussereignis (Beenden / terminate) geführt. Hier endet der Prozess.
• Übergewicht / Status 50. Dieses Ergebnis führt auch zur Rücksendung, siehe oben.
• Übergewicht / Status 70. Dies führt zu einer Aufgabe Aufnahme mit Diätplan und Schreibvorgängen in die Zoodatenbank (ZooDB) und Tierakte. Danach geht hier der Sequenzfluss in die Bahn der Diätassistentin zu einer Aufgabe Diätplan erstellen mit Einträgen in die Datenobjekte Diätplan und Tierakte. Da dieser Sequenzflusszweig hier endet, folgt wiederum ein Schlussereignis des Typs Beenden (terminate).
• Kein Übergewicht / Status 70 führt zu einer Aufgabe Aufnahme mit der zu beschreibenden Datenbank ZooDB und dem Datenobjekt Tierakte. Danach folgt wieder ein Schlussereignis.
• Kein Übergewicht / Status 50. Die führt zu einer Aufgabe Aufnahme mit Warten, wiederum mit ZooDB und Tierakte. Die angeforderte einwöchige Wartezeit mit mit einem Zeitgeber (timer) modelliert.

Die folgende Abbildung zeigt diesen Abschnitt des Geschäftsprozesses.

Abbildung 2.5-1: Geschäftsprozess Tieraufnahme, Teil 2. Ausschnitt aus dem Gesamtmodell.

Aufnahmestatus Warten

Die Prozessbeschreibung zum Aufnahmestatus Warten kann wie folgt in das BPD umgesetzt werden. Nach dem Zeitgeber (für eine Woche warten) folgt eine Aufgabe Gewicht und Blutwerte bestimmen mit dem zu beschreibenden Datenobjekt Tierakte. Da danach zwischen zwei Alternativen gewählt werden muss, folgt ein Exclusive Gateway mit zwei abgehenden Sequenzflüssen:

• Der erste mit dem Ergebnis Besser als "Kein Übergewicht / Status 50". Er führt zur Aufgabe Ausnahme, wiederum mit schreibendem Zugriff auf ZooDB und Tierakte. Danach folgt ein Schlussereignis vom Typ Beenden (teminate).
• Der zweite mit dem Ergebnis Schlechter / gleich "Kein Übergewicht / Status 50". Er führt zu einem Zwischenereignis des Typs Verknüpfung (link) und verknüpft mit dem Prozess Rücksendung (vgl. unten). Die folgende Abbildung zeigt diesen Prozessabschnitt.

Folgende Abbildung zeigt dieses Prozessfragment.

Abbildung 2.5-1: Geschäftsprozess Tieraufnahme, Teil 3. Ausschnitt aus dem Gesamtmodell.

2.5.3 Lösung Zoo - Tieraufnahme

Den Geschäftsprozess als Ganzes kann die folgende Abbildung nur andeuten. Sie kann hier aus technischen Gründen nicht besser dargestellt werden. Eine größere und grafisch detailliertere Version dieser Grafik findet sich hier:
https://www.staud.info/grafiken2020/Grafiken.php

Abbildung 2.5-1: Geschäftsprozess Tieraufnahme

2.5.4 Lösungsschritte Zoo - Rücksendung

Nun zur eventuellen Rücksendung von Tieren. Betrachtet man die Gesamtsituation, entdeckt man folgende Träger der Aktivitäten:

• Ein Becken Zoo mit den Bahnen Zooleitung, Zootierarzt und Rücksendestelle.
• Ein Becken Herkunftsstelle.
• Ein Becken Transportunternehmen.

Wir beginnen die Modellierung mit der empfangenden Verknüpfung (link) Rücksendung in der Bahn Zooleitung, die auch den Start des Prozesses darstellt. Danach müssen zwei Aufgaben angestoßen werden: Vermerke tätigen und Mail erstellen. Dies geschieht mittels eines Parallel Gateway, das zwei Aufgaben anstößt:

Aufgabe Vermerke tätigen

Dies geschieht in der Bahn Zooleitung. Gemäß der Prozessanforderung werden dabei die Zoodatenbank (ZooDB), das Begleitheft und die Tierakte beschrieben, so dass die drei entsprechenden Datenobjekte an die Aufgabe angefügt werden. Danach folgt ein Schlussereignis für diesen Kontrollflusszweig.

Aufgabe Mail erstellen

Dies geschieht durch die Zooleitung und den Zootierarzt. Deshalb wird in beiden Bahnen die Aufgabe Mail erstellen eingefügt und durch eine Punkt/Strich-Linie umrandet, was ja Zusammenarbeit ausdrückt. Gleich danach folgt in beiden Bahnen und derselben Umrandung eine Aufgabe des Typs Sender (send task object) Mail an Herkunftsstelle. Bei der Aufgabe Mail erstellen wird jeweils das Datenobjekt Tierakte gelesen und das Datenobjekt Mail erstellt und beschrieben. In der Bahn Zootierarzt endet dann dieser Zweig, weshalb ein Schlussereignis angefügt wurde.

Modelliert man auch die externen Partner des Geschäftsprozesses, was mit der BPMN problemlos möglich ist und hier auch geschieht, wird nun im Becken Herkunftsstelle ein kurzer Geschäftsprozess mit Startereignis, Empfänger-Aufgabe (receive task object) und Schlussereignis modelliert.

Der letzte Absatz der Prozessbeschreibung beschreibt wiederum Zusammenarbeit, diesmal zwischen vier Prozessträgern:

• Der Herkunftsstelle
• Der Rücksendestelle
• Der Zooleitung
• Dem Transportunternehmen

Dies geschieht indem für die Herkunftstelle, die Rücksendestelle und das Transportunternehmen jeweils ein kurzer Prozess mit Startereignis, Aufgabe Terminvereinbarung und Schlussereignis eingefügt wird. Bei der Zooleitung wird der Sequenzfluss von der Aufgabe Mail an Herkunftstelle zu einer Aufgabe Terminvereinbarung geführt, die zusammen mit den anderen gleich benannten die Zusammenarbeit ausdrückt. Wieder umrandet eine Punkt/Strich-Linie die in Zusammenarbeit erledigten Aufgaben.

Unbehagen: Hier sollte in einer "nächsten Besprechung" mit den Auftraggebern die informationelle Basis der gemeinsamen Terminvereinbarung geklärt werden.

Der Geschäftsprozess Rücktransport endet dann mit einem Schlussereignis vom Typ Beenden (teminate).

2.5.5 Lösung Zoo - Rücksendung

Eine größere und grafisch detailliertere Version dieser Grafik findet sich hier:
https://www.staud.info/grafiken2020/Grafiken.php

2.6 Zum Nachschlagen

2.6.1 Ereignisse

Siehe https://www.staud.info/grafiken2020/Grafiken.php für eine größere und grafisch detailliertere Fassung dieser Abbildung.

2.6.2 Gateways

Siehe https://www.staud.info/grafiken2020/Grafiken.php für eine größere und grafisch detailliertere Fassung dieser Abbildung.

2.6.3 Aufgabentypen

Siehe https://www.staud.info/grafiken2020/Grafiken.php für eine größere und grafisch detailliertere Fassung dieser Abbildung.

2.6.4 Subprozesstypen

Siehe https://www.staud.info/grafiken2020/Grafiken.php für eine größere und grafisch detailliertere Fassung dieser Abbildung.