11.1 Standardmethode |
|||||
Ein wesentliches Element von Geschäftsprozessen ist Warten. Warten auf eine Entscheidung anderer, Warten auf Produkte, Zahlungseingang, usw. Für die korrekte Modellierung solcher Wartesituationen in Ereignisgesteuerten Prozessketten gibt es grundsätzlich zwei Lösungen, die mit der folgenden Beispielsituation erläutert werden sollen: |
|||||
|
|||||
|
Warten auf Zu- |
||||
|
|||||
Eine solche Situation kann so modelliert werden, wie in der obigen Abbildung gezeigt. Nach dem Ereignis Bewerber/in ist benachrichtigt, das den Abschluss der eigentlichen Bewerberauswahl signalisiert, wird eine Wartefunktion eingefügt. Dies trägt auch der Tatsache Rechnung, dass Warten durchaus eine Tätigkeit ist. Die auf diese Funktion folgenden Ereignisse deuten die möglichen Beendigungen des Wartens an. Entweder durch eine Zu- oder eine Absage. Je nachdem werden dann die entsprechenden Funktionen angestoßen. Die Funktion Warten auf Entscheidung ist dabei unabdingbar. Ohne sie entstünde eine nicht zulässige Struktur, bei der auf ein Ereignis zwei Funktionen folgen, die durch ein exklusives ODER verknüpft sind. |
|||||
Falls gewünscht, könnte hier durch ein weiteres paralleles Ereignis (Zwei Wochen sind seit der Benachrichtigung vergangen) auch die Situation modelliert werden, dass das externe Ereignis nicht eintritt (dass sich die Bewerberin nicht meldet), damit auch dieser Fall durch die Ereignisgesteuerte Prozesskette festgehalten ist. |
|||||
Auf jeden Fall aber wird hier auf ein externes Ereignis gewartet. Dies kommt durchaus vor, da Geschäftsprozesse natürlicherweise auch auf diese Weise mit der Umwelt in Kontakt treten. Dabei wird also der weitere Verlauf des Geschäftsprozesses durch das Handeln Externer bestimmt. |
Warten auf externes Ereignis |
||||
11.2 Warten mit dem logischen UND |
|||||
Neben obiger sozusagen konventioneller Lösung findet man auch die in der nächsten Abbildung angegebene. Bei ihr wird auf die Wartefunktion verzichtet. |
|||||
|
Das logische UND als Schalter |
||||
|
|||||
Unmittelbar nach dem Benachrichtigungsereignis folgt ein logischer Operator UND. Er soll signalisieren, dass der Kontrollfluss in beide Richtungen weitergeht, obwohl semantisch nur eine der beiden Alternativen eintreten kann. Vor den beiden weiteren UND-Operatoren bleibt der Kontrollfluss dann - sozusagen – stehen (wie oben, zu Beginn der Ereignisgesteuerten Prozesskette Kontaktbearbeitung in Abschnitt 7.3xxx). Die möglichen externen Entscheidungen sind als Ereignisse modelliert, die sich gegenseitig ausschließen. Tritt nun eines der beiden Ereignisse ein, ist auf der entsprechenden Seite das UND erfüllt und die nächste Funktion wird angestoßen. Natürlich ist es auch hier möglich, durch ein entsprechendes Ereignis die Situation abzufangen, dass die externe Entscheidung auf sich warten lässt (hier: dass der Bewerber sich nicht meldet). |
|||||
Das logische UND wird in diesem Beispiel auf eine etwas andere Art verwendet als im vorigen Kapitel und wie üblicherweise, wo ja das UND signalisiert, dass alle verknüpften Kontrollflüsse durchlaufen werden müssen. Hier bedeutet es, dass der Kontrollfluss bis zum nächsten Operator fortgesetzt wird. |
|||||
11.3 Fehlende Entscheidung |
|||||
Nicht zulässig wäre die oben schon angesprochene Lösung, bei der auf die Modellierung der (externen) Entscheidung verzichtet wird (vgl. die nächste Abbildung). |
|||||
|
|||||
|
|||||
Hier fehlt der Entscheidungsprozess, was nicht sinnvoll und nicht zulässig ist (vgl. auch die „verbotenen“ Strukturen in Kapitel 4xxx). Unter anderem deshalb, weil ein interner Entscheidungsprozess [Anmerkung] sich natürlich in der zugehörigen Software als Maske niederschlagen muss (zur Anzeige und Eingabe von Informationen) und eine Parallelität zwischen EPKs und Software immer dann gegeben ist, wenn die Ereignisgesteuerten Prozessketten Geschäftsprozesse beschreiben, die durch Software abgewickelt werden (z.B. bei den SAP-EPKs und R/3). |
|||||
Diese Anordnung gibt aber einen Hinweis auf die Motivation, die zur obigen Lösung Warten mit dem logischen UND geführt haben könnte. |
|||||
11.4 Modellierung parallel zu einer Software |
|||||
Wie ja schon angemerkt, liegt allerdings in obiger Situation die Entscheidung außerhalb des Unternehmens, bei den Bewerbern, sodass sich diese Entscheidungsfunktion gerade nicht in einer Maske der Betriebswirtschaftlichen Standardsoftware niederschlägt (sondern nur deren Ergebnis). Darin liegt wohl der tiefere Grund für diese Art der Modellierung ohne Entscheidungsfunktion. Da sich dieses Warten nicht in einer Maske des Programms niederschlägt, lässt man es weg, wenn man entlang einer Software Ereignisgesteuerte Prozessketten entwickelt. |
|||||
Mehrere Operatoren hintereinander |
|||||
Es kommt oft vor, dass mehrere Operatoren hintereinander angeordnet sind. So ja auch im obigen Beispiel, wo mehrere UND-Operatoren hintereinander liegen. Ganz grundsätzlich ist dies immer dann notwendig, wenn der Kontrollfluss sich mehrfach verzweigt. |
|||||