In diesem Kapitel werden Modellierungsbeispiele vorgestellt. Sie stellten ursprünglich reale Geschäftsprozesse dar (oder Teile davon), wurden aber für dieses Buch abstrahiert und in didaktischer Hinsicht verändert und ergänzt.

Einige der Ereignisgesteuerten Prozessketten erstrecken sich über mehrere Seiten. In einem solchen Fall wird das Ende der vorangehenden zu Beginn der nachfolgenden EPK wiederholt. Damit sollte der Zusammenhang zwischen den beiden Fragmenten klar sein.

EPKs über mehrere Seiten

8.1 Angebotserstellung

Für die folgende Ereignisgesteuerte Prozesskette liegt zum einen eine inhaltliche Beschreibung vor (die Semantik des Geschäftsprozesses), zum anderen ein Text, der die Erstellung der EPK beschreibt. Die inhaltliche Beschreibung ist eingerückt. Um die Bezüge zwischen der Beschreibung der Erstellung und den Abbildungen einfacher herstellen zu können, wurden in die Abbildungen Nummern eingefügt, auf die im Text verwiesen wird.

Angebotserstellung im Anlagenbau

Prozessbeschreibung

Gestartet wird der Geschäftsprozess aufgrund einer Kundenanfrage. Diese kann per Postbrief, 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 und die Geschäftsleitung weiter.

Start

Umsetzung als EPK

Dieses Anfangsszenario wurde durch entsprechende Startereignisse modelliert, die durch einen XODER-Operator verknüpft sind. Nach dem Eingang der telefonischen Anfrage wird die geforderte textliche Fixierung als Funktion modelliert. Bei jeder Anfrageart entsteht ein Informationsobjekt, das bei der dem Operator nachfolgenden Funktion angeführt wird - lesend, da es ja wahrgenommen und interpretiert werden muss. Hier muss auch die erste Organisationseinheit angeführt werden.

Anfangsszenario

Im Anschluss wird in der Prozessbeschreibung gefordert, dass das Angebot an den zuständigen Vertriebsbereichsleiter (VBL) und die Geschäftsleitung (GL) weitergeleitet wird. Dies kann so wie hier realisiert werden: durch einen UND-Operator, dem die Tätigkeiten folgen (Position 2). Vgl. zu diesem Muster auch Abschnitt 6.2. Hier sind die Organisationseinheiten nicht angegeben, weil sie gleich sind wie in der vorangegangenen Funktion . Die Transportvorgänge selbst wurden explizit modelliert, also durch eine eigene Funktion (vgl. zum Thema Informationstransport Abschnitt 7.1).

Muster "Mehrere Tätigkeiten anstoßen"

Prozessbeschreibung - Fortsetzung

Der Vertriebsbereichsleiter gibt die Anfrage an einen seiner Vertriebsingenieure weiter, der die Angebotsrealisierbarkeit prüft. 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.

Umsetzung als EPK

Die Weiterleitung der Anfrage (ein Transportvorgang) wurde wiederum durch eine Funktion modelliert. Die Prüfung ebenso, mit drei möglichen Ergebnissen, die durch XODER verknüpft sind (Position (3)). Der Text deutet an, dass die Prüfung mehrstufig ist und dass es im ersten Schritt um das angefragte Leistungsspektrum geht. Dieses kann in vollem Umfang, teilweise oder gar nicht ("nicht realisierbar") mit dem Leistungsspektrum des Unternehmens übereinstimmen. Entsprechend sind die Ergebnisereignisse formuliert. Nach dem Ereignis Nicht realisierbar (Position 3) kann dann gleich eine Funktion folgen, in der die Absage formuliert wird. Daraus ergibt sich dann ein erstes Schlussereignis: Anfrage abgelehnt.

Prüfung und erstes Schlussereignis

Die in der Prozessbeschreibung beschriebene Anfrage bei Partnerunternehmen wurde einfach als Funktion modelliert, mit einem positiven und einem negativen Ergebnis. Im Falle des negativen Ergebnisses wird die Anfrage abgelehnt und ein weiteres Schlussereignis tritt ein. Dies ist eine eher oberflächliche Art der Modellierung. Eine detailliertere Modellierung könnte so aussehen, 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.

Alternative:
Mehr Detaillierung

Anmerkungen:
- Alternative Startereignisse
- Muster Teilaufgaben und Tätigkeiten starten

Im Geschäftsprozess bleiben somit aus den obigen Schritten zwei mögliche positive Ergebnisse, die beide den Fortgang zulassen. Im Kontrollfluss der EPK müssen diese Zweige zusammengeführt werden. Dies geschieht durch einen XODER-Operator, getreu der Regel, dass mit dem Operator zusammengeführt wird, mit dem flussaufwärts aufgeteilt wurde (vgl. Abschnitt 7.2).

Zusammenführung von Kontrollflusszweigen

Prozessbeschreibung - Fortsetzung

Danach folgt die Prüfung, ob die Angebotslegungsfrist 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.

Umsetzung in die EPK - Fortsetzung

Die Prüfung der Angebotslegungsfrist (4) führt zu einer Funktion und zwei Ergebnisereignissen. Genauso die Prüfung der Kapazität der Ingenieurgruppe. Beide Funktionen werden durch ein logisches UND verknüpft, da sie gleichzeitig angestoßen werden. Hier liegt also wieder das Muster "Tätigkeiten starten" vor (siehe auch Abschnitt 6.2).

Die insgesamt vier möglichen Ergebnisse werden nun folgendermaßen in Beziehung gesetzt:

Semantik sucht Syntax

• Treten die Ereignisse Angebotslegungsfrist nicht realisierbar und Kapazitäten vorhanden ein, wird um eine Fristverlängerung gebeten. Dies wird in der Ereignisgesteuerten Prozesskette dadurch realisiert, dass die beiden von diesen Ereignissen kommenden Kontrollflüsse mit einem logischen UND verknüpft werden (6). Danach wird dann die entsprechende Funktion (Fristverlängerung erbitten) angefügt (vgl. Abbildung 8.1-2). Dies entspricht dem Muster "Bedingungen für eine nachfolgende Tätigkeit" (vgl. Abschnitt 6.2).
• Falls sich ergibt, dass die Kapazität der Ingenieurgruppe nicht reicht (Kapazität Ingenieure nicht vorhanden), wird die Anfrage abgelehnt, unabhängig davon, welches Ergebnis die Prüfung der Angebotslegungsfrist erbrachte.
• Wenn beide Prüfungen positiv ausfallen geht es weiter im Geschäftsprozess. Um diese Semantik in die EPK zu bringen, müssen die von diesen beiden Ereignissen kommenden Kontrollflusszweige durch UND verknüpft werden (5).

Zum positiven Fortgang kommt es auch, wenn die Fristverlängerung gewährt wird. Auch für diese Semantik muss wieder ein UND-Operator eingefügt werden, der die beiden Ereignisse Angebotslegungsfrist realisierbar und Fristverlängerung gewährt verknüpft (Muster Bedingungen für Fortgang, vgl. Abschnitt 6.5).

Bleibt noch die Absage im Falle einer Nichtgewährung der Fristverlängerung. Diese wird einfach an das entsprechende Ereignis angehängt. Auch hier liegt dann wieder ein Schlussereignis vor. Die vielen Schlussereignisse legen den Gedanken nahe, die Absage in eine andere Ereignisgesteuerte Prozesskette zu verlegen und dorthin mit Hilfe von Prozesswegweisern zu verweisen (vgl. Abschnitt 7.4). Dies ist möglich. Sinnvoll wäre es hier aber nur, wenn das Absagen der Anfrage aufwändiger wäre, wenn also mehr Funktionen usw. vorlägen.

Viele Schlussereignisse

In obigem Abschnitt schimmert das Muster Kombinatorik durch. Vgl. dazu Abschnitt 6.5 und das Zoo-Beispiel in Abschnitt 8.4.

Prozessbeschreibung - Fortsetzung

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.

Umsetzung in die EPK - Fortsetzung

Die Angebotserstellung wird als Funktion modelliert für die die Anfrage Informationen liefert und aus der das Informationsobjekt Angebot entsteht. Die Ausführungen zu Stunden- und Kostenschätzungen usw. sind Funktionsaspekte und nicht Prozessaspekte [Anmerkung] und können deshalb bei einer Istanalyse ignoriert werden.

Prozess- vs. Funktions-
modellierung

Die im Text etwas unklaren Angaben zu den zuständigen Personen werden mit einer Organisationseinheit entsprechend an die Funktion angefügt. Solche nicht ganz präzisen Angaben bei Zuständigkeiten kommen bei Istanalysen häufig vor. Hier lohnt sich eine Präzisierung in solchen Fällen oftmals nicht.

Informationsobjekte werden durch eine Linie mit Funktionen verknüpft. Lesend: Pfeilspitze zur Funktion. Schreibend: Pfeilspitze zum Informationsobjekt. Transport: ohne Pfeilspitze. Vgl. die Abschnitte 3.6 und 7.1.

Erinnerung

In der nachfolgenden Funktion Angebotsdaten erfassen wird dann das Informationsobjekt Angebot gelesen und ein weiteres geschrieben, ein Eintrag in eine Datenbank mit allen Angeboten, die im Unternehmen erstellt werden (Angebot in Datenbank). Aus diesem Datenbankeintrag heraus entsteht dann mit Hilfe des Reportgenerators Angebote (RepGenA) die textliche Fassung des Angebots (Angebot textlich). Diese Funktion wird also von einem Programm durchgeführt, aber natürlich von einem Menschen gestartet. Hier soll angenommen werden, dass die vorige Funktion nach Abschluss ihrer Aktivitäten diesen Startvorgang durchführt.

Lesen und Schreiben

Prozessbeschreibung - Fortsetzung

Zustellung und Warten

Das fertige Angebot wird durch den zuständigen Vertriebsingenieur dem Kunden zugeschickt. 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 oder Vertriebsbereichsleiter und dem im Angebot genannten Projektleiter geführt. Die Ergebnisse dieser Vergabegespräche dienen dann als Grundlage für die Entscheidung im anfragenden Unternehmen.

Trifft eine Absage ein, 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.

Umsetzung in die EPK - Fortsetzung

Obiger Text beschreibt zuerst den Transportvorgang, der das Angebot zum Kunden bringt. Hier wurde wieder das zu transportierende Informationsobjekt ohne Richtungspfeil an die Funktion angehängt.

Danach liegt eine Wartesituation vor (8), die ebenfalls durch eine Funktion modelliert wird. Das positive Ergebnis, Auftrag erteilt, ist gleichzeitig auch ein Schlussereignis dieses Geschäftsprozesses. Nach diesem ist der Prozesswegweiser zum Geschäftsprozess Auftragsstart angefügt, der im folgenden Abschnitt beschrieben wird.

Muster Warten

Die beiden anderen vorgedachten Ergebnisse sind Vergabegespräche und Absage. Die Vergabegespräche sind nach dem entsprechenden Ereignis eingefügt. Das textliche Angebot wird gelesen und beschrieben, deshalb der Doppelpfeil. Es kann angenommen werden, dass das Angebot in der Datenbank auch an die Verhandlungsergebnisse angepasst wird, deshalb wurde es hier auch an die Funktion angefügt. Die Organisationseinheit wurde entsprechend der Prozessbeschreibung gestaltet. Solche Angaben sind in Istanalysen durchaus üblich. Die Formulierung "eine oder mehrere" wird durch die Rückschleife in der EPK umgesetzt.

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

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

kann dadurch umgesetzt werden, dass einfach eine entsprechende Prüfung eingebaut wird.

Der Geschäftsprozess als Ganzes findet sich hier:
https://www.staud.info/grafiken2020/GrafikenEPK.php

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

8.2 Auftragsstart

Die Beschreibung des Geschäftsprozesses beginnt mit dem Eingang des Auftrags. Der Auftrag des Kunden folgt meist einer vorangegangenen Angebotserstellung, wie im vorigen Abschnitt gezeigt. Hin und wieder kommt es vor, dass ohne einen solchen Prozess ein Auftrag eingeht. Zum Beispiel, wenn erst kurz zuvor ein vergleichbarer Auftrag ausgeführt wurde.

Auftragsstart im Anlagenbau

Prozessbeschreibung

Nach Eingang des Auftrags prüft der Vertriebsingenieur (VI), ob der Auftrag mit sämtlichen ausgehandelten Konditionen bzw. dem Angebot übereinstimmt.

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 der Auftrag abgelehnt.

Umsetzung in die EPK

Damit ist die Anfangssequenz (vgl. die folgende Abbildung) mit einem Prozesswegweiser und einem Startereignis festgelegt. Die Auftragsklärung wird zu einer Funktion (Prüfung auf Konditionen usw.), die vom Vertriebsingenieur realisiert wird. Ergibt die Prüfung keine Abweichungen schreitet der Geschäftsprozess voran zum Start zweier Funktionen (nächste Abbildung).

Ergibt die Prüfung Abweichungen vom Angebot werden diese durch akzeptable Konditionen ersetzt. Dies führt zu einer entsprechenden Funktion mit dem Informationsobjekt Auftrag und der Organisationseinheit Vertriebsingenieur [Anmerkung] . Bei dieser Ersetzung wird das Informationsobjekt Auftrag verändert. Das Zusenden des Angebots, das dann nötig wird und das Warten auf die Kundenreaktion wurde als Funktion mit einem nachfolgenden XODER-Operator modelliert.

Falls der Kunde die Ersetzung der Konditionen akzeptiert, wird der Kontrollfluss wieder mit dem positiven Ergebnis der Prüfung zusammengeführt. Falls er ablehnt, kommt es zur Ablehnung des Auftrags und danach zu einem ersten Schlussereignis.

Prozessbeschreibung - Fortsetzung

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

Das Controlling trägt 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.

Prozess- vs. Funktions-
modellierung

Umsetzung in die EPK - Fortsetzung

Vorstehender Text signalisiert, dass im positiven Fortgang des Geschäftsprozesses zwei Tätigkeiten angestoßen werden. Entsprechend wurde dies mit einem UND-Operator und zwei Funktionen in der Ereignisgesteuerten Prozesskette modelliert. Die eine wird vom VI, die andere durch die Abteilung Vertrieb realisiert. Beide beschreiben das Informationsobjekt Auftragsstammblatt.

Nach den dann folgenden Ereignissen können die beiden Kontrollflusszweige wieder zusammengeführt werden. Anschließend folgt die im obigen Text angeführte "Vermerkung" der Kostenstruktur mit der Organisationseinheit Controlling. Hier ist im Text wiederum die konkrete Ausführung der Funktion angedeutet. Der Prozessanteil besteht hier nur aus einer Funktion, daneben ist ein Stück weit die Ausführung der Funktion beschrieben. Dies muss man erkennen, wenn man eine Prozessbeschreibung bekommt: Was ist Prozess, was ist Funktionsausführung. Vgl. hierzu auch Abschnitt 12.2 und ein deutlicheres Beispiel gleich hier unten.

Was ist Prozess, was ist Funktion?

Prozessbeschreibung - Fortsetzung

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 ergibt sich aus dem jeweiligen Gehalt des Mitarbeiters. Die Hinzurechnung der direkten bereichsspezifischen Gemeinkosten ergibt den zweiten Kostensatz. Die weitere Addition des unternehmensspezifischen Gemeinkostensatzes ergibt den endgültigen dritten Kostensatz.

Umsetzung in die EPK - Fortsetzung

In obigem Text ist zweierlei vermerkt. Zum einen ein betriebswirtschaftlicher Vorgang, die Erstellung der Stundenvorgabe, zum anderen ein Regelwerk zur Bestimmung der Stundenvorgabe. Dies ist nichts anderes als die Beschreibung der Funktion. Diese eignet sich nicht für die Prozessmodellierung in einer Ereignisgesteuerten Prozesskette, sondern gibt an, wie die Funktion realisiert werden sollte. Wir haben es hier also wieder und viel deutlicher als oben mit dem Gegensatz von Prozess- und Funktionsmodellierung zu tun.

Prozess- vs. Funktions-
modellierung

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 eine einzige entsprechende Funktion mit einem Ereignis. Das Regelwerk (die Funktionsbeschreibung) wurde als Informationsobjekt modelliert, das in die Funktion einfließt.

Prozessbeschreibung - Fortsetzung

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.

Umsetzung in die EPK - Fortsetzung

Obiger Text verlangt zuerst eine Funktion, in der die Klärung der Vertragsstruktur erfolgt. Die beiden Möglichkeiten der Honorargestaltung werden dann als alternative Ergebnisereignisse dieser Funktion modelliert: Honorar nach Aufwand oder Pauschalauftrag.

Nachfolgend dann die Funktionen, die der Text verlangt: die Vermerkung des Abrechnungsmodus auf der einen Seite und die Festlegung der Rechnungstermine einschließlich der Honoraranteile auf der anderen. Das Informationsobjekt bei diesen beiden Funktionen ist aus dem Text nicht ersichtlich, es wurde ergänzt. Im Anschluss daran kann der Kontrollfluss wieder zusammengeführt werden.

Der zweite obige Absatz führt wieder zu zwei "parallel" anzustoßenden Funktionen. Dies kann mit einem UND-Operator erfolgen, wie es die folgende Abbildung zeigt (unten).

Die beiden anzustoßenden Funktionen sind Zahlungstermine mitteilen und Anlage Auftrag im PPS. Geht es nach einer Aufteilung des Kontrollflusses durch einen UND-Operator in einem Fluss weiter, können die Kontrollflusszweige wieder zusammengeführt werden (müssen aber nicht). Hier wurde darauf verzichtet, sodass nur ein Zweig weiter führt, wodurch der andere aber nicht Schlussereignis wird (vgl. Abschnitt 7.5).

Kein Schlussereignis

Prozessbeschreibung - Fortsetzung

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.

Umsetzung in die EPK - Fortsetzung

Der erste Absatz oben erfordert drei Funktionen: die Vervollständigung des Auftragsstammblatts durch die Auftragsabwicklung, die Weiterleitung zum Vertrieb und die Erstellung der Auftragsmeldung durch den Vertrieb. Der Informationstransport wurde durch eine Linie ohne Pfeilspitze verdeutlicht. Bei der Funktion Erstellung Auftragsmeldung wurde ein entstehendes Informationsobjekt angefügt.

Transport von Informationsobjekten

Der zweite obige Absatz fordert zwei parallel [Anmerkung] anzustoßende Funktionen. Der Vertrieb realisiert Auftragsmeldung archivieren, das Controlling Kopien an Technikbereich weiterleiten. Mit den nachfolgenden Ereignissen kommen diese Zweige an ihr Ende, der Geschäftsprozess geht aber - begründet durch den aufteilenden UND-Operator - noch weiter.

Prozessbeschreibung - Fortsetzung

Parallel zur internen Meldung über die Vervollständigung des Auftragsstammblatts hat der Vertriebsingenieur die externe Auftragsbestätigung an den Kunden zu erstellen.

Erfolgte der Auftrag schriftlich und hat der Auftraggeber bereits eine Auftragsbestätigung mitgeschickt, wird diese unterschrieben zurückgesandt. Sonst wird eine kurze Auftragsbestätigung vom zuständigen Vertriebsingenieur erstellt. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt. Letzterer setzt sich dann mit dem Kunden in Verbindung, um die Arbeitsaufnahme zu besprechen.

Erfolgte die Beauftragung mündlich, wird ein Auftragsbestätigungsschreiben mit sämtlichen besprochenen Konditionen verfasst und um schriftliche Bestätigung des Kunden gebeten.

Umsetzung in die EPK - Fortsetzung

Obiger Text führt nun zurück zur vorigen Abbildung. Dort muss diese Erstellung der externen Meldung "parallel" zur Vervollständigung des Auftragsstammblatts eingefügt werden. Dies wurde mit einem UND-Operator realisiert. Danach wurde die Funktion Art der Auftragserteilung prüfen eingefügt. Sie wird vom Vertriebsingenieur realisiert.

Die folgende Abbildung zeigt den Fortgang. Obige Prüfung kann zu drei Ergebnissen führen, entsprechend wurden drei Ereignisse eingefügt:

• Schriftlich mit Auftragsbestätigung
• Schriftlich ohne Auftragsbestätigung
• Telefonisch

Es folgen die in der Prozessbeschreibung angeforderten Handlungen als Funktionen. Das Zusammenführen der Kontrollflusszweige erfolgt zweistufig. Zuerst werden die beiden linken Kontrollflusszweige zusammengefasst, indem ein abstrahiertes Ereignis "Erledigt" formuliert wird, danach folgt die Zusammenführung der nun nur noch zwei Kanten. Abschließend wird, wie in der Prozessbeschreibung gefordert, die Besprechung der Arbeitsaufnahme mit dem Kunden und ein Schlussereignis angefügt.

Verschachtelte Kontrollfluss-
strukturen

Auch in diesem Text liegt wieder ein Beispiel für eine Funktionsbeschreibung inmitten der Prozessbeschreibung vor:

Prozess- vs. Funktion

"... Sonst wird eine kurze Auftragsbestätigung vom zuständigen Vertriebsingenieur erstellt. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt. ...."

Diese wurde in der Prozessmodellierung weggelassen.

Der Geschäftsprozess als Ganzes findet sich hier:
https://www.staud.info/grafiken2020/GrafikenEPK.php

8.3 Personalbeschaffung

Hier nun ein kleinerer Prozess, der didaktisch motiviert ist und der als Modellierungsaufgabe nach einer einführenden Veranstaltung zur Geschäftsprozessmodellierung in einer Klausur dienen könnte. Er beschreibt eine Personalbeschaffungssituation.

Prozessbeschreibung

Die Schulungsabteilung (SchAbt) der Firma ERPL (Endlich Richtig Programmieren Lernen) stellt fest, dass sie einen weiteren Dozenten für die C++-Schulungen einstellen muss. Sie wendet sich deshalb an die Geschäftsleitung (GL) und an die Personalabteilung (PA), um einen neuen Mitarbeiter einstellen zu können. Der Einstellungsvorschlag geschieht auf Basis des PBB (Personalbeschaffungsbogen), den die Schulungsabteilung ausfüllen und mit dem Vorschlag mitgeben muss. Die Geschäftsleitung muss in Absprache mit der Personalabteilung dem Einstellungsvorschlag zustimmen. Die Zustimmung oder Ablehnung wird schriftlich formuliert.

Umsetzung in die EPK

Informationsobjekt entsteht ... und wird transportiert. Die EPK erhält zu Beginn das Startereignis Dozent ist einzustellen. Die erste Funktion ist das Ausfüllen des Personalbeschaffungsbogens (PBB), durchgeführt durch die Schulungsabteilung (SchAbt). Es entsteht das Informationsobjekt Personalbeschaffungsbogen (PBB). Dieselbe Abteilung (deswegen wurde die Organisationseinheit weggelassen) realisiert die nächste Funktion, PBB zur Geschäftsleitung (GL) geben und um Zustimmung bitten.

Muster Entscheidungsfindung. Die Entscheidungsfindung der GL wird als Funktion mit zwei möglichen Ergebnisereignissen modelliert. Falls die GL nicht zustimmt, wird das entsprechende Ereignis zu einem der Schlussereignisse der EPK.

Prozessbeschreibung

Falls die GL zustimmt, entwerfen Schulungs- und Personalabteilung unter Berücksichtigung des Personalbeschaffungsbogens und früher verfassten Stellenanzeigen die Anzeige. Diese wird dann durch die PA in mehreren einschlägigen Computerzeitschriften inseriert. Es wird darauf geachtet, dass der Erscheinungstermin der Anzeige in den verschiedenen Zeitschriften in einem Zeitrahmen von maximal vier Wochen liegt.

Umsetzung in die EPK

Zusammenarbeit (vgl. auch Abschnitt 7.6). Der Entwurf der Anzeige wird als Funktion modelliert. Die Zusammenarbeit von SchAbt und PA wird durch die zwei Elemente für Organisationseinheiten ausgedrückt. Bei den Informationsobjekten werden PBB und Frühere Anzeigen als "liefernd" eingefügt und die aktuell entstehende Anzeige als "entstehend".

Abkürzungen:
PBB: Personalbeschaffungsbogen
SchAbt: Schulungsabteilung
GL: Geschäftsleitung
PA: Personalabteilung

Prozessbeschreibung

Vier Wochen, nachdem die letzte Anzeige erschienen ist, werden die eingegangenen Bewerbungen durch die SchAbt und PA durchgesehen. Liegen keine Bewerbungen vor, wird die Anzeige nochmals in den Zeitschriften geschaltet. Liegen zwar Bewerbungen vor, aber keine geeigneten, wird (parallel) den Bewerbern abgesagt und die Anzeige überarbeitet. Die Absagen übernimmt die Personalabteilung, die Überarbeitung der Anzeige leisten Personalabteilung und Schulungsabteilung zusammen. Dabei wird v.a. geprüft, ob man die Konditionen (Stellenvoraussetzungen, Gehalt, ...) verändern muss. Anschließend wird die Anzeige wieder veröffentlicht und derselbe Prozessabschnitt wie oben bis zur Sichtung der Bewerbungen nochmals durchlaufen.

Liegen geeignete Kandidaten vor, wählen Schulungsabteilung und Personalabteilung Kandidaten aus, die eingeladen werden sollen.

Umsetzung in die EPK

Obige Beschreibung verlangt als erstes eine Funktion, in der das Veröffentlichen der Anzeige ausgedrückt wird. Die durchführende Organisationseinheit wird nicht genannt, hier wurde die PA angenommen. In einem konkreten Projekt müsste nachgefragt werden. An die Funktion angefügt wurde auch die (aktuelle) Anzeige, als zu transportierendes Informationsobjekt.

Das 4-wöchige Warten kann durch ein zeitliches Ereignis mit UND-Anbindung in der EPK ausgedrückt werden. Damit wird hier ausgedrückt, dass der Geschäftsprozess bis vier Wochen nach Erscheinen der letzten Anzeige ruht. Das Sichten der Bewerbungseingänge kann wieder als Funktion mit den Bewerbungen als Informationsobjekt(e) ausgedrückt werden. Um die Semantik der Prozessbeschreibung auszudrücken erfordert die syntaktische Umsetzung im weiteren zwei Rückschleifen.

Muster Zeitpunkte, vgl. Abschnitt 6.4

Die erste startet vom Ereignis Keine Bewerbung liegt vor. Da in diesem Fall einfach dieselbe Anzeige nochmals geschaltet wird, erfolgt der Rücksprung vor die Funktion Anzeige veröffentlichen. In der Prozessbeschreibung wird nicht ausgedrückt, wie oft dies geschieht, deshalb baut die Syntax der EPK hier keine Sperre auf, was aber möglich wäre (vgl. Abschnitt 6.8). Ganz pragmatisch wird angenommen, dass in der konkreten Realisierung des Geschäftsprozesses die Handelnden eine Lösung finden. Dieses "Abstützen" der Modellierung auf die Pragmatik liegt sehr oft bei Istanalysen vor. Es bedeutet letztendlich einen Verzicht auf die Ausmodellierung der gesamten "tiefen" Semantik des Prozesses [Anmerkung] .

Rückschleifen mit Pragmatik (vgl. Abschnitt 6.8).

Die zweite Rückschleife ergibt sich aus dem Handeln nach dem Ergebnis Keine geeigneten Bewerber dabei. Hier wird die überarbeitete Anzeige zurückgereicht - an dieselbe Stelle flussaufwärts. Auch diese ist wieder - im obigen Sinn - pragmatisch fundiert.

Das "gleichzeitige Absagen" aus der Prozessbeschreibung kann in der EPK durch einen UND-Operator nach dem entsprechenden Ereignis ausgedrückt werden. Der eine vom UND startende Kontrollflusszweig führt zur oben beschriebenen zweiten Rückschleife, der andere zu einem Schlussereignis. Auch der dritte Zweig, der zur Auswahl der Einzuladenden führt, endet mit einem Schlussereignis.

Muster Tätigkeiten starten (vgl. Abschnitt 6.2).

Damit liegen in diesem Prozess insgesamt drei mögliche Schlussereignisse vor. Weitere wurden "pragmatisch" verhindert. Zur Verdeutlichung des Konzepts der Instanzen von Ereignisgesteuerten Prozessketten stelle man sich Prozessdurchgänge vor, die bei dem ersten Schlussereignis (ganz oben), beim zweiten (Bewerbern abgesagt) oder beim dritten (Einzuladende ausgewählt) enden. Damit wären die drei wichtigsten Instanzen dieses Geschäftsprozesses geklärt.

Instanzen

8.4 Zoo - Tieraufnahme

Die folgenden Geschäftsprozesse sind in einem Zoo angesiedelt. Sie sind fiktiv und didaktisch motiviert und natürlich stark vereinfacht. Konkret geht es um die Aufnahme eines neuen größeren Tieres (Säugetiere, Reptilien, ...) in einen Zoo.

Prozessbeschreibung

Der Prozess beginnt damit, dass ein neues Tier eintrifft (von einem anderen Zoo, von einem Tierhändler, usw.). 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 optimalen Werts erreichen ("Status 70"), ob alle Werte mindestens 50% des optimalen Werts erreichen ("Status 50") oder dies nicht erreicht wird, einzelne Werte also unter 50% des optimalen Werts liegen ("Blutwerte negativ").

• Falls die Blutwerte negativ sind, wird das Tier zurückgeschickt zur Herkunftsstelle.
• 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.
• 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.

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.

Anmerkungen zu den EPKs

Die Prüfung durch den Zootierarzt, ob es sich um ein gefährliches Tier handelt, kommt in der Prozessbeschreibung weiter unten, sie muss in der EPK vor den Betäubungsvorgang genommen werden. Dies kommt in Prozessbeschreibungen häufig vor, auch viel ausgeprägter als hier. Es lohnt sich immer, in den Prozessbeschreibungen ein Stück nach vorne zu schauen, bevor man an der jeweiligen Stelle weiter modelliert.

Nach vorne schauen, flussaufwärts!

Muster Kombinatorik. Der mittlere Teil stellt ein Beispiel für das Kombinatorikproblem der Prozessmodellierung dar (vgl. Abschnitt 6.6). Alle Ergebnisse der einen Funktion müssen mit allen der anderen kombiniert werden, falls es für jede Kombination einen eigenen weiteren Fortgang gibt.

Wie in Abschnitt 6.6 gezeigt kann für diese Semantik der UND-Operator eingesetzt werden. Nur Ereignisse, die alleine einen bestimmten Fortgang erzwingen - wie hier Blutwerte negativ - bedürfen keiner Kombination.

In den Ergebnissen "der Kombinatorik" wird nun mehrfach das Tier zurückgesandt. Deshalb lohnt es sich, den Geschäftsprozess Rücksendung als eigenen Prozess anzulegen und die Rücksendung jeweils durch einen Prozesswegweiser auszudrücken. Spätestens jetzt sollte der "sendende Prozess" auch einen Namen erhalten: Tieraufnahme. Die Verknüpfung durch Prozesswegweiser erfolgt dann wie in Abschnitt 7.4 beschrieben. Im sendenden Prozess kommt der Prozesswegweiser nach einem Ereignis, das unmittelbar vor den Aktivitäten des aufgerufenen Prozesses steht. Beschriftet wird er mit der Bezeichnung des aufgerufenen Prozesses (hier: Rücksendung). Beim aufgerufenen Prozess gibt es für jeden Verweis einen eigenen Startvorgang mit einem Prozesswegweiser (beschriftet mit der Bezeichnung des aufrufenden Prozesses) und nachfolgend dem Ereignis, das im aufrufenden Prozess vor dem Prozesswegweiser stand. Diese Ereignisse sind die eigentlichen Startereignisse des aufgerufenen Prozesses.

8.5 WebShop

Prozessbeschreibung

Der folgende Text beschreibt den Anfang eines Geschäftsprozesses zur Auftragsabwicklung bei einem WebShop, die Verarbeitung der Bestellung. Der Geschäftsprozess wird weitgehend automatisiert realisiert, durch das Modul Auftragsbearbeitung einer entsprechenden Anwendungssoftware.

Weitgehend automatisiert.

Betrachtet werden nur die Bestellungen über den WebShop, nicht die per Fax oder Brief. Wenn der Kunde nach seinen Einkaufsschritten die Einträge im letzten Web-Formular getätigt und die Bestellung abgeschickt hat, ist der Kaufvertrag zustande gekommen. Die Web-Software legt einen Auftrag, eine Liste der Fremdanbieterprodukte (LFAP) und eine Nachbestellliste (NBL) für die Bestellung an. Falls die zwei letzteren bei der Bestellverarbeitung nicht benötigt werden, werden sie am Schluss wieder gelöscht.

Danach prüft das Programm, ob die gewünschten Produkte im Lager sind, nachbestellt werden müssen oder von einem Fremdanbieter stammen (einem Unternehmen, das auf den Webseiten des Unternehmens ebenfalls Produkte anbietet). Obige Prüfung geschieht Produkt für Produkt. Der Ablauf ist wie folgt:

Prüfung Produktherkunft.

• Ist das Produkt von einem Fremdanbieter wird es in die LFAP (Liste Fremdanbieterprodukte) aufgenommen.

Ist das Produkt aus dem Sortiment des WebShops, wird zuerst geklärt, ob es im Lager vorrätig ist (Lagerprodukt) oder nicht.

• Falls es vorrätig ist, wird es in den Auftrag aufgenommen.
• Falls es nicht vorrätig ist, wird es zum Bestellprodukt und in die Nachbestellliste (NBL) aufgenommen.

Sind alle Produkte auf diese Weise geprüft, wird ...

• ... die LFAP - falls sie Einträge hat - an den oder die Fremdanbieter verschickt. Die weitere Bearbeitung erfolgt dann dort. Auch die Rechnung erhält der Kunde vom Fremdanbieter.
• ... die NBL - falls eine notwendig war - an die Abteilung Lager geschickt. Das Lager nimmt die Nachbestellung vor. Wenn die Produkte eintreffen, trägt das Lager dies mit der Anwendungssoftware in die Unternehmensdatenbank ein. Dabei werden die Produkte dieser Liste in den Auftrag aufgenommen.

Während der Nachbestellung (falls eine notwendig war) ruht der Geschäftsprozess. Erst wenn die nachbestellten Produkte eingetroffen sind, wird er fortgesetzt. Der Auftrag wird dann an das Lager geschickt. Dort werden die gewünschten Produkte zusammengestellt und verpackt.

Anschließend wird durch die Abteilung Versand das Ausdrucken der Rechnung veranlasst. Sie erhält dann in der Unternehmensdatenbank den Status Neu. Die Rechnung wird anschließend zur Warensendung getan und das Paket verschickt, wodurch die Rechnung den Status Offen erhält.

Rechnung.

Umsetzung in eine EPK

Automatisierte Abwicklung. Für diesen Geschäftsprozess wird die Existenz einer Anwendungssoftware mit einem Modul Auftragsbearbeitung und einer Unternehmensdatenbank angenommen. Die Software erledigt automatisiert die meisten Aufgaben, liest in der Datenbank und schreibt in sie. Auch die bei der ersten Funktion entstehenden Informationsobjekte NBL (Nachbestellliste), LFAP (Liste der Fremdanbieterprodukte (LFAP) und der Auftrag entstehen dort.

Die Auswahl des zu prüfenden Produkts wird in eine Funktion gelegt, die damit auch den Beginn des zu wiederholenden Abschnitts markiert (Position 1). Danach kommt die Prüfung, ob es sich um ein Lagerprodukt (2) handelt. Bei (3) werden alle Kontrollflusszweige der Auswahlfunktionen wieder zusammengeführt und es erfolgt die Prüfung, ob die Produkte schon abgearbeitet sind. Falls ja, gibt es den Sprung nach flussaufwärts. Es liegt hier also das Muster Repetitive Handlungen vor. Vgl. Abschnitt 6.9.

Muster Repetitive Handlungen.

Eine Formulierung wie "Ist das Produkt von einem Fremdanbieter ... " muss in eine Funktion, die den Sachverhalt klärt und nach der entsprechende Ereignisse folgen, umgesetzt werden. Vgl. Position (2) in Abbildung 8.5-3.

Auch die Prüfung, ob in der LFAP Einträge stehen, muss in eine Funktion gelegt werden (4). Der Versand der Liste (5) wird wieder durch eine Linie ohne Pfeilspitze verdeutlicht. Es ist ansonsten nicht üblich, in Ereignisgesteuerten Prozessketten das Löschen von Informationsobjekten auszudrücken. Hier wurde es, wegen der Systemnähe des Beispiels getan. Vgl. die durchgestrichenen Informationsobjekte LFAP und NBL.

Der Prozess ist von Anfang an automatisiert, das Modul Auftragsbearbeitung erledigt die Aufgaben. Erst ganz unten, ab Position (6), übernimmt eine Abteilung einige Aufgaben, aber bereits ab Position (8) handelt wieder die Software. Deshalb wechselt auch erst ab Position (6) die Organisationseinheit, getreu der Regel, dass die Organisationseinheiten bei einer Funktion weggelassen werden können, wenn sie gleich sind wie bei der vorangehenden.

Das Warten auf den Eingang der nachbestellten Produkte wird, wie an Position (7) gezeigt, durch ein Ereignis modelliert, dass mit UND in den Kontrollfluss eingebunden ist. Dies ist ein Beispiel für das Muster Warten. Vgl. Abschnitt 6.7.

Muster Warten.

Die letzte Abbildung unten zeigt den Schluss des Geschäftsprozesses. Das Verändern des Rechnungsstatus und das Ausdrucken der Rechnung wurde mit Hilfe eines UND-Operators "parallel" angestoßen.

8.6 Fälligkeitsprüfung

Die folgende EPK zeigt einen völlig durch Software getragenen und regelmäßig durchgeführten Geschäftsprozess, wieder bei einem WebShop. Diesmal geht es um die Überwachung der Zahlungseingänge.

Prozessbeschreibung

Im Geschäftsprozess Fälligkeitsprüfung geht es darum, Rechnungen, deren Zahlungsziel abgelaufen ist, zu identifizieren. Diese Prüfung erfolgt - natürlich automatisiert (d.h. durch ein Programm) - täglich ab 3.00 Uhr.

Dazu werden die entsprechenden Daten im Finanzwesen gelesen. Zuerst wird geprüft, ob überhaupt nicht bezahlte ("offene") Rechnungen vorliegen, was aber natürlich in der Regel der Fall ist. Sollten wider Erwarten keine nicht bezahlten Rechnungen vorliegen, beendet das Programm seine Aktivitäten.

Für nicht bezahlte Rechnungen gibt es drei Ursachen:

• ein laufendes Widerspruchsverfahren (Status der Rechnung "Widerspruch")
• das Zahlungsziel ist noch nicht erreicht (Status "Erinnerung", "Mahnung", ...)
• das Zahlungsziel ist überschritten

Liegen also nicht bezahlte Rechnungen vor, wird für jede geprüft, ob die Zahlungsfrist abgelaufen ist oder ob eine der zwei anderen möglichen Ursachen vorliegt. Handelt es sich tatsächlich um ein Ablaufen der Zahlungsfrist, erhält die Rechnung den Status "nicht bezahlt" und wird dem Mahnprozess übergeben.

Für das Controlling wird außerdem festgehalten, wie viele Rechnungen zu jedem Typ nicht bezahlter Rechnungen gehören. Bei wie vielen also ein Widerspruchsverfahren läuft, bei wie vielen das Zahlungsziel noch nicht erreicht ist und bei wie vielen das Zahlungsziel überschritten ist. Diese drei Werte werden, falls sie nicht Null sind, dem Controlling automatisiert durch eine E-Mail mitgeteilt.

Umsetzung in eine Ereignisgesteuerte Prozesskette

Der Prozess startet, wenn zwei Bedingungen erfüllt sind: falls überhaupt Fälligkeiten zu prüfen sind, was aber meist der Fall ist [Anmerkung] , und falls es 3.00 Uhr morgens ist. Dies wird durch zwei Startereignisse realisiert. Durch ein Startereignis wie 3.00 Uhr morgens kann man ein regelmäßiges Anwerfen eines Geschäftsprozesses zu einem bestimmten Zeitpunkt modellieren. Die programmtechnische Umsetzung fängt dann auch die Probleme ab, die entstehen könnten, wenn gerade um 3.00 Uhr die Leitung nicht zur Verfügung steht: Wiederholtes Starten, usw.

Jeden Morgen um 3.00.
Muster Zeitpunkte.

Als erstes wird geprüft, ob nicht bezahlte (nb) Rechnungen vorhanden sind. Dies geschieht durch eine Funktion, die auf Daten des Finanzwesens zugreift. Falls keine vorhanden sind, endet der Prozess gleich wieder (Position 1).

Abkürzung:
nb: nicht bezahlt(e)

Im anderen Fall werden in der EPK die nicht bezahlten Rechnungen, die ja offene Posten darstellen, durch eine Funktion gelesen und ausgewertet. Dies erledigt das Modul LR (Lese Rechnung) im Datenbestand Offene Posten, so dass ein entsprechender Träger der Funktion und ein Informationsobjekt einzubauen sind. Drei Ergebnisse sind möglich:

• Zahlungsziel überschritten ("zü")
• Zahlungsziel noch nicht erreicht ("znn")
• Widerspruch läuft ("zwi")

Sie werden durch Ergebnisereignisse modelliert.

Dieser Abschnitt liegt in einer Schleife, da die offenen Posten einer nach dem anderen abgearbeitet werden. Da die Anzahl der jeweils auffälligen" Rechnungen von Bedeutung ist und später benötigt wird, werden hier entsprechende Informationsobjekte eingefügt (Zähler). In der Programmierung würden diese Informationsobjekte Variablen entsprechen. Beschrieben werden die Informationsobjekte durch entsprechende Funktionen. Im Falle der nicht bezahlten Rechnungen wird dann der Status auf Nicht bezahlt gesetzt. Auch dies wird durch eine Funktion modelliert, die auf die Rechnungsköpfe der Datenbank zugreift [Anmerkung] .

Schleife für repetitives Handeln.

Es folgt das Anstoßen eines Mahnverfahrens und gleichzeitig die Weiterführung des Kontrollflusses zu dem XODER-Operator, der alle drei Verzweigungen zusammenführt (3). Das Zusammenführen der drei Kontrollflusszweige ist nötig, weil der Geschäftsprozess danach in einem Zweig weitergeht.

Abkürzungen:
LR: Modul Lese Rechnung
zü: Zahlungsziel überschritten
znn: Zahlungsziel noch nicht erreicht
zwi: Widerspruch läuft

Auf das Mahnverfahren wird durch einen Prozesswegweiser verwiesen (vgl. Abschnitt 7.4). Der Prozesswegweiser folgt immer nach einem Ereignis, das im aufgerufenen Prozess wiederholt wird. Somit muss im aufgerufenen Prozess Mahnverfahren zuerst ein Prozesswegweiser kommen (mit der Beschriftung Zahlungseingangsüberwachung) und danach das Ereignis Status auf "Nicht bezahlt" gesetzt. Dieses Ereignis stellt dann sozusagen das Startereignis des aufgerufenen Prozesses dar.

Prozesswegweiser

In der EPK (oben) folgt dann eine Funktion mit der Prüfung, ob noch eine weitere nicht bezahlte Rechnung vorliegt. Falls ja, kommt es zu einem Rücksprung nach flussaufwärts, vor die Funktion Nicht bezahlte Rechnung lesen (2). Entsprechend den Syntaxregeln für Rücksprünge wird der Kontrollflusszweig mit einem XODER-Operator in den Hauptfluss eingebunden.

Rücksprung

Falls keine offenen Rechnungen mehr vorliegen, folgt die Klärung, wie viele Rechnungen mit Zahlungsziel überschritten (zü), Zahlungsziel noch nicht erreicht (znn) und Widerspruch läuft (zwi) festgestellt werden konnten. Dazu wird für jeden Rechnungstyp zuerst festgestellt, ob der jeweilige Zähler größer Null ist. Falls ja, wird der Wert ans Controlling gemeldet. Die Meldefunktion benötigt ein zu lesendes (Zähler x) und ein zu schreibendes (Mail bzgl. X) Informationsobjekt.

zü, znn und zwi

Prozessmodellierung kennt keine Variablen. Gäbe es sie, könnte man eine solche Situation in einer Schleife bewältigen, in der nacheinander die drei Rechnungstypen verarbeitet werden. Ohne Variablenkonzept muss dieser Abschnitt verdreifacht werden. Hier berühren wir mehrfach die Grenze zur Funktionsmodellierung, d.h. zur Modellierung für eine Programmierung:

Prozess- vs. Funktions-
modellierung.

• Eine Standardprozessmodellierung benötigt kein Variablenkonzept, weil sie die funktionale Ebene kapselt. Kommt man also im Rahmen eines Modellierungsvorhabens auf diese Ebene, sollte man das Modellierungsinstrument wechseln.
• Auch die weiter oben eingeführten Informationsobjekte als Zähler markieren so eine Grenze.