Geschäftsprozessmodellierung und -simulation mit DPMN – Ressourcenbeschränkte Aktivitäten

Konzeptuelles Modell

Ein konzeptionelles Informationsmodell eines Arbeitsplatzsystems, das zwei Objekttypen und vier Ereignistypen definiert, ist in Abbildung 2 dargestellt.

Abbildung 2: Ein konzeptionelles Informationsmodell für Fertigungsarbeitsplatzsysteme.
Wie aus den Assoziationen zwischen den vier Ereignistypen und den beiden Objekttypen hervorgeht, gibt es für alle vier Ereignistypen dieselben zwei Objekttypen, die an ihnen beteiligt sind: Teile und Arbeitsstationen, was bedeutet, dass jedes Ereignis dieser vier Typen ein bestimmtes Teil und eine bestimmte Arbeitsstation betrifft.

Beachten Sie, dass der Eingangspuffer (gefüllt mit wartenden Teilen) als ein Assoziationsende mit dem Namen wartender Teile auf der Teileseite der Assoziation zwischen Teilen und Arbeitsstationen modelliert ist, was die Tatsache ausdrückt, dass zu jedem Zeitpunkt eine Arbeitsstation null oder mehr Teile in ihrem Eingangspuffer auf die Verarbeitung warten hat.

Ein konzeptionelles Prozessmodell dieses Systems, das vier kausale Regelmäßigkeiten in Form von Ereignisregeln beschreibt, eine für jeden Ereignistyp, ist in Abbildung 3 in Form eines BPMN-Prozessdiagramms dargestellt, das Ereigniskreise verwendet, die mit Sequenzflusspfeilen verbunden sind, die die (bedingte) Kausalität ausdrücken, und Datenobjekte, die mit Ereigniskreisen verbunden sind.

Abbildung 3: Ein konzeptionelles Prozessmodell eines Fertigungsarbeitsplatzsystems.
Die vier Ereignisregeln, die durch das in Abbildung 3 dargestellte Modell beschrieben werden, sind

• Wenn ein Teil eintrifft, wird es dem Eingangspuffer hinzugefügt, und wenn die Arbeitsstation verfügbar ist, wird ein Bearbeitungsstart-Ereignis für die Bearbeitung des neu eingetroffenen Teils ausgelöst.
• Wenn ein Verarbeitungsstart-Ereignis eintritt, wird das nächste Teil aus dem Eingangspuffer verarbeitet und ein Verarbeitungsende-Ereignis wird irgendwann später (nach Ablauf der Verarbeitungszeit) ausgelöst.
• Wenn ein Verarbeitungsende-Ereignis eintritt, löst dies ein Teilabgangs-Ereignis und, falls der Eingangspuffer nicht leer ist, ein weiteres Verarbeitungsstart-Ereignis aus, das das nächste Teil aus dem Puffer betrifft.
• Wenn ein Teilabgangsereignis eintritt, wird das bearbeitete Teil von der Workstation entfernt.

Während in der BPMN alle Ereigniskreise in eine der drei Kategorien Start-, Zwischen- oder Endereignis eingeteilt werden müssen und eine andere visuelle Syntax für sie verwendet wird, ist dies in der DPMN nicht der Fall.

Entwurfsmodell

Ein Simulationsentwurfsmodell basiert auf einem konzeptionellen Modell. Je nach Zweck/Zielen einer Simulationsstudie kann es von bestimmten Elementen der durch das konzeptionelle Modell beschriebenen realen Domäne abstrahieren und es fügt rechnerische Elemente hinzu, die Entwurfsentscheidungen darstellen, wie z. B. Zufallsvariablen, die in Form von Zufallsvariablen-Stichprobenfunktionen ausgedrückt werden, die auf bestimmten Wahrscheinlichkeitsverteilungen zur Modellierung der Zufallsvariation bestimmter Systemvariablen basieren.

In diesem Modell wird das mehrwertige Assoziationsende waitingParts als geordnet definiert, was bedeutet, dass es einer mehrwertigen Referenzeigenschaft entspricht, die eine geordnete Sammlung (z. B. eine Array-Liste oder eine Warteschlange) als Wert hat.

Das Informationsentwurfsmodell in Abbildung 4 definiert, dass ein PartArrival-Ereignis sowohl auf ein Teil als auch auf eine Workstation verweisen muss, was Situationen darstellt, in denen bestimmte Teile an bestimmten Workstations ankommen. Beachten Sie, dass dieses Modell aus rechnerischer Sicht die Erstellung neuer Teilobjekte (oder deren Abruf aus einem Objektpool) erfordert, bevor ein neues PartArrival-Ereignis erstellt (oder geplant) wird, während es in Simulationsmodellen üblicher ist, ein neues Teilobjekt erst dann zu erstellen, wenn ein Ankunftsereignis eingetreten ist, was durch die Definition einer Multiplizität von 0..1 für das Teilende der PartArrival-Part-Assoziation modelliert werden kann (was bedeutet, dass Part Arrival eine optionale statt einer obligatorischen Referenzeigenschaft mit dem Namen part hat).

Abbildung 4: Ein Informationsentwurfsmodell.
Man beachte, dass das Modell zwei Operationen auf Klassenebene definiert (bezeichnet mit dem Stereotyp "rv"), die Funktionen zur Stichprobenziehung von Zufallsvariablen implementieren: PartArrival::recurrence() entspricht einer Dreieckswahrscheinlichkeitsverteilung mit den Parameterwerten Minimum, Modus und Maximum 3, 4 und 8, währendProcessingStart::processingTime() einer Exponentialverteilung mit einem Ereignisratenparameterwert von 6 entspricht.

Ein Prozessentwurfsmodell auf der Grundlage der Objekt- und Ereignistypen, die durch das Informationsentwurfsmodell in Abbildung 4 definiert und aus dem konzeptionellen Prozessmodell in Abbildung 3 abgeleitet wurden, ist in Abbildung 5 dargestellt.

Abbildung 5: Ein Prozessentwurfsmodell in Form eines DPMN-Prozessdiagramms.
Da alle Ereignisse an derselben Arbeitsstation stattfinden, sind alle drei Ereignisplanungspfeile mit der gleichen Ereigniseigenschaftszuweisung workStation := ws versehen, die einfach den Objektverweis auf die gegebene Arbeitsstation entlang der Ereignisplanungskette weitergibt. Solche Zuweisungen von Eigenschaften (in Annotationen zur Zuweisung von Ereigniseigenschaften), bei denen ein Eigenschaftswert eines Folgeereignisses auf den entsprechenden Eigenschaftswert des planenden (oder auslösenden) Ereignisses gesetzt wird, werden weggelassen (wie durch Ereignistypen mit denselben Eigenschaftsnamen impliziert), um die Prozessmodelldiagramme nicht zu überladen.

Ein DPMN-Prozessdiagramm, wie das in Abbildung 5 gezeigte, kann in eine Reihe von Ereignisregeldiagrammen aufgeteilt werden, eines für jeden seiner Ereigniskreise, wie in Tabelle 1 gezeigt. Diese Reduktion eines DPMN-Prozessentwurfsmodells auf einen Satz von Ereignisregel-Entwurfsmodellen liefert zusammen mit der in (Wagner 2017) vorgestellten operativen Semantik von Ereignisregeln die Semantik von DPMN-Prozessdiagrammen.

Beachten Sie, dass ein Ereignisregel-Entwurfsmodell auch textuell in Form eines Pseudocode-Blocks mit vier Teilen ausgedrückt werden kann: Teil 1 gibt den auslösenden Ereignistyp an und deklariert eine Regelvariable, die das auslösende Ereignis darstellt, Teil 2 deklariert weitere Regelvariablen und initialisiert sie, Teil 3 enthält ein Zustandsänderungsskript, das aus Zustandsänderungsanweisungen besteht, und Teil 4 plant Folgeereignisse.

Tabelle 1: Entwurfsmodelle für Ereignisregeln.

EINFACHE AKTIVITÄTEN

Eine einfache Aktivität ist eine Aktivität mit null oder mehr Teilnehmern, von denen keiner eine besondere Bedeutung hat (wie z. B. eine Ressource oder ein Verarbeitungsobjekt).

Konzeptionelle Modellierung von einfachen Aktivitäten

Konzeptionell ist eine Aktivität ein zusammengesetztes Ereignis, das durch ein Paar von Start- und Endereignissen zeitlich eingegrenzt ist. Wann immer ein Modell ein Paar zusammengehöriger Start- und Endereignistypen enthält, wie z. B. Bearbeitungsbeginn und -ende im Modell eines Fertigungsarbeitsplatzes auf der linken Seite von Abbildung 6 und Abbildung 7, können diese folglich durch einen entsprechenden Aktivitätstyp ersetzt werden, wie z. B. Bearbeitung, wie auf der rechten Seite dargestellt.

Abbildung 6: Einführung einer Aktivitätsart in ein konzeptionelles Informationsmodell.
Es ist offensichtlich, dass die Anwendung dieses Ersetzungsmusters zu einer konzeptionellen und visuellen Vereinfachung der betreffenden Modelle führt.

Abbildung 7: Einführung eines Aktivitätstyps in ein konzeptionelles Prozessmodell.

Entwurfsmodellierung von einfachen Aktivitäten

Wie in einem konzeptionellen Modell kann auch in einem Entwurfsmodell ein Paar entsprechender Aktivitätsstart- und -end-Ereignistypen (oder Ereigniskreise), wie ProcessingStart und ProcessingEnd in den in Abbildung 8 und Abbildung 9 gezeigten Quellmodellen, durch einen entsprechenden Aktivitätstyp (oder Aktivitätsrechtecke), wie Processing, wie in den in diesen Abbildungen gezeigten Zielmodellen, ersetzt werden.

Abbildung 8: Erweiterung der grundlegenden OEM- zu OEM-A-Klassenmodellen durch Einführung von Aktivitätstypen.
Im Falle eines Informationsdesignmodells bedeutet dieses Ersetzungsmuster, dass alle Merkmale (Attribute, Assoziationen und Operationen) der Klassen, die den Start- und den End-Ereignistyp definieren, der Klasse zugewiesen werden, die den entsprechenden Aktivitätstyp definiert, möglicherweise mit einer Umbenennung einiger dieser Merkmale. Im Beispiel von Abbildung 7 gibt es nur ein solches Merkmal: die Operation ProcessingStart::processingTime auf Klassenebene, die der Klasse Processing zugeordnet und in time umbenannt wird.

Im Falle eines Prozessentwurfsmodells impliziert das Ersetzungsmuster, dass ein Ereigniskreispaar, bestehend aus einem Ereigniskreis, der einen Ereignistyp für den Aktivitätsbeginn darstellen soll, und einem Ereigniskreis, der einen Ereignistyp für das Aktivitätsende darstellen soll, mit einem Ereignisplanungspfeil vom Ereigniskreis für den Aktivitätsbeginn zum Ereigniskreis für das Aktivitätsende, der durch einen Verzögerungsausdruck annotiert ist, durch ein Aktivitätsrechteck ersetzt wird, so dass:

• Alle Datenobjekte, die an den Ereigniskreis des Aktivitätsendes angehängt sind, werden an das Aktivitätsrechteck angehängt (da eine Aktivität stattfindet, wenn sie abgeschlossen ist).
• Alle Ereignisplanungspfeile, die vom End-Ereigniskreis der Aktivität ausgehen, werden in Ereignisplanungspfeile umgewandelt, die vom Aktivitätsrechteck ausgehen.
• Alle Aktivitätsstart-Ereignis-Terminierungspfeile werden durch entsprechende Aktivitäts-Terminierungspfeile ersetzt, die einen zusätzlichen Erstellungsparameter für die Dauer einer terminierten Aktivität haben, der auf den für den Aktivitätsend-Ereignis-Terminierungspfeil definierten Verzögerungsausdruck gesetzt wird. Im obigen Beispiel ist Processing::time() im Zieldiagramm gleich der Verzögerung
• ProcessingStart::processingTime im Quelldiagramm.
• Wenn der Ereigniskreis des Aktivitätsbeginns ein oder mehrere angehängte Datenobjekte oder einen ausgehenden Ereignisplanungspfeil hat, der nicht zum Ereigniskreis des Aktivitätsendes führt, muss ein Ereigniskreis des Aktivitätsbeginns in das Aktivitätsrechteck eingefügt werden, um das/die Datenobjekt(e) anzuhängen und als Quelle für den/die ausgehenden Ereignisplanungspfeil(e) zu dienen.

Abbildung 9: Erweiterung der grundlegenden DPMN auf DPMN-A-Prozessmodelle durch Einführung von Aktivitätsrechtecken.

Dieses Aktivitäts-Start-Ende-Umschreibungsmuster, das auch in umgekehrter Richtung angewendet werden kann, indem ein Aktivitätsrechteck durch ein Ereigniskreispaar ersetzt wird, definiert die Bedeutung eines Aktivitätsrechtecks in einem DPMN-Diagramm. Es ermöglicht die Reduzierung eines DPMN-A-Diagramms mit Aktivitätsrechtecken auf ein einfaches DPMN-Diagramm ohne Aktivitätsrechtecke.

Beachten Sie, dass das Zielmodell in Abbildung 9 zwei Ereignisregeln vorsieht:

• Bei jeder Ankunft eines Teils wird die Regelvariable wsAllocated auf true gesetzt, wenn der Status der Workstation AVAILABLE ist, und das Statusattribut der Workstation wird auf BUSY gesetzt, andernfalls wird das angekommene Teil zum Eingangspuffer waitingParts der Workstation hinzugefügt. Wenn die Regelvariable wsAllocated den Wert true hat, wird eine neue Verarbeitungsaktivität so geplant, dass sie sofort beginnt, wobei ihre (geerbten) Dauerattribute auf den Wert gesetzt werden, den man durch den Aufruf der in der Klasse der Verarbeitungsaktivität definierten Zeitfunktion erhält.
• Wenn eine Verarbeitungsaktivität endet und der Eingabepuffer waitingParts der Workstation leer ist, wird das Statusattribut der Workstation auf AVAILABLE gesetzt, andernfalls wird die Regelvariable wsReallocated auf true gesetzt und das nächste Teil aus dem Eingabepuffer waitingParts entfernt. Wenn die RegelvariablewsReallocated den Wert true hat, dann wird eine neue Verarbeitungsaktivität so geplant, dass sie sofort beginnt, wobei ihr (geerbtes) Attribut duration auf den Wert gesetzt wird, den man durch den Aufruf der in der Klasse der Verarbeitungsaktivität definierten Funktion time erhält.

Beachten Sie, dass eine Arbeitsstation eine exklusive Ressource ihrer Verarbeitungsaktivität ist. Die Konzepte der Ressourcen und der ressourcenbeschränkten Aktivitäten werden in den folgenden Abschnitten erläutert.

RESSOURCENBESCHRÄNKTE AKTIVITÄTEN

Eine ressourcenbeschränkte Aktivität ist eine Aktivität, bei der ein oder mehrere Teilnehmer eine Ressourcenrolle (z. B. Ausführender) spielen. Typischerweise ist eine ressourcenbeschränkte Aktivität eine Komponente eines Geschäftsprozesses, der im Kontext einer Organisation oder Organisationseinheit stattfindet, die mit der Aktivität als deren Prozesseigentümer verbunden ist.

Eine Aktivität eines bestimmten Typs kann bestimmte Ressourcen benötigen, um ausgeführt werden zu können. Zu jedem Zeitpunkt kann eine Ressource, die für die Durchführung einer Aktivität erforderlich ist, verfügbar sein oder nicht.

Eine Ressource ist z. B. nicht verfügbar, wenn sie besetzt oder außer Betrieb ist.Ressourcen sind Objekte eines bestimmten Typs. Zu den Ressourcenobjekten einer Aktivität gehört ihr Ausführender. Während in einem konzeptionellen Modell, das ein reales System beschreibt, für jede Aktivität ein Ausführender erforderlich ist, kann ein Simulationsentwurfsmodell von dem Ausführenden einer Aktivität abstrahieren.

Beispielsweise kann eine Beratungsaktivität einen Berater und einen Raum erfordern. Solche Ressourcenbeschränkungen werden auf der Typenebene definiert. Bei der Definition der Aktivitätsart Beratung werden diese Ressourcenbeschränkungen in Form von zwei obligatorischen Assoziationen mit den Objekttypen Berater und Raum so definiert, dass die Enden beider Assoziationen die Multiplizität 1 ("genau eine") haben. In einem Simulationslauf kann dann eine neue Beratungsaktivität nur gestartet werden, wenn sowohl ein Berater- als auch ein Raumobjekt vorhanden sind. Für alle ressourcenbeschränkten Aktivitäten kann ein Simulator automatisch die folgenden Statistiken erheben:

Für jede Aktivitätsart:

• die (durchschnittliche, maximale usw.) Länge der Warteschlange seiner Warteschlange der geplanten Aktivitäten;
• die (durchschnittliche, maximale usw.) Zykluszeit, die sich aus der Summe der Wartezeit und der Vorgangsdauer ergibt;
• den prozentualen Anteil der Zeit, in der jedes beteiligte Ressourcenobjekt mit einer Aktivität dieses Typs beschäftigt ist (seine Auslastung durch Aktivitäten dieses Typs).

Der prozentuale Anteil der Zeit, in der jedes Ressourcenobjekt im Leerlauf ist oder nicht in Ordnung ist.

Um ressourcenbeschränkte Aktivitäten zu modellieren, müssen wir ihre Typen definieren. Ein ressourcenbeschränkter Aktivitätstyp besteht aus:

• einem Satz von Eigenschaften und einem Satz von Operationen, wie jeder Entitätstyp
• einer Menge von Ressourcenrollen, die jeweils die Form einer Referenzeigenschaft mit einem Namen, einem Objekttyp als Bereich und einer Multiplizität haben, die eine Ressourcenbeschränkung definieren kann, z. B. "genau ein Ressourcenobjekt dieses Typs ist erforderlich" oder "mindestens zwei Ressourcenobjekte dieses Typs sind erforderlich".

Zu den für eine Aktivitätsart definierten Ressourcenrollen kann auch die Rolle des Ausführenden gehören. Eine Simulationssprache zur Simulation von Aktivitäten muss die Definition von Aktivitätstypen mit zwei Arten von Eigenschaften ermöglichen: gewöhnliche Eigenschaften und Ressourcenrollen. Zumindest für letztere muss es möglich sein, Multiplizitäten zur Definition von Ressourcenbeschränkungen zu definieren. Diese Anforderungen werden durch OEM-Klassendiagramme erfüllt, in denen Ressourcenrollen als stereotype Eigenschaften mit dem Stereotyp "resource role" oder kurz "res" definiert sind.

Die Erweiterung des Basis-OEM um die Konzepte, die für die Modellierung ressourcenbeschränkter Aktivitäten benötigt werden (insbesondere Ressourcenrollen mit Beschränkungen, Ressourcenpools und ressourcenabhängige Aktivitätsstartpfeile), wird als OEM-A bezeichnet.

Konzeptuelle Modellierung von ressourcenbeschränkten Aktivitäten

Die Modellierung ressourcenbeschränkter Aktivitäten ist seit den Anfängen der diskreten Ereignissimulation (DES) in den sechziger Jahren ein wichtiges Thema, während sie im Bereich der Geschäftsprozessmodellierung (BPM) vernachlässigt wurde und immer noch als fortgeschrittenes Thema gilt. So erlaubt BPMN zwar die Zuweisung von Ressourcen zu Aktivitäten, nicht aber die Modellierung von Ressourcenpools und erlaubt weder die Festlegung von Kardinalitätsbeschränkungen für Ressourcen noch von Beschränkungen für die parallele Teilnahme an mehreren Aktivitäten.

Im DES-Paradigma der Verarbeitungsnetze hat Gordon (1961) die Ressourcenmanagement-Operationen Seize und Release in der Simulationssprache GPSS eingeführt, um Ressourcen zuzuweisen und freizugeben (release). Damit hat GPSS ein Standardmodellierungsmuster für ressourcenbeschränkte Aktivitäten etabliert, das unter dem Namen Seize-Delay-Release populär geworden ist und besagt, dass bei der Simulation einer ressourcenbeschränkten Aktivität die Ressourcen zunächst zugewiesen und dann nach einer gewissen Verzögerung (die die Dauer der simulierten Aktivität darstellt) wieder freigegeben werden.

Ressourcen-Rollen und Prozessverantwortliche

Als anschauliches Beispiel betrachten wir ein Krankenhaus, das aus medizinischen Abteilungen besteht, in denen Patienten ankommen, um sich von einem Arzt in einem Raum der Abteilung untersuchen zu lassen. Eine medizinische Untersuchung als Aktivität hat vier Teilnehmer: einen Patienten, eine medizinische Abteilung, einen Arzt und ein Zimmer, aber nur zwei von ihnen spielen eine Ressourcenrolle: Ärzte und Zimmer. Dies kann in einem OEM-Klassendiagramm durch Verwendung des Stereotyps "Ressourcenrolle" zur Kategorisierung der Assoziationsenden, die Ressourcenrollen darstellen, dargestellt werden, wie in Abbildung 10 gezeigt.

Beachten Sie, dass sowohl der Ereignistyp Patientenankunft als auch der Aktivitätstyp Untersuchungen eine (obligatorische funktionale) Referenzeigenschaft Prozesseigentümer haben. Dies bedeutet, dass sowohl die Patientenankunftsereignisse als auch die Untersuchungsaktivitäten in einer bestimmten medizinischen Abteilung stattfinden, die ihr Prozesseigentümer in dem Sinne ist, dass sie Eigentümerin der aus ihnen zusammengesetzten Prozesstypen ist. Ein Prozesseigentümer wird in der BPMN als "Teilnehmer" bezeichnet (im Sinne eines Kollaborationsteilnehmers) und visuell in Form eines Containerrechtecks mit der Bezeichnung "Pool" dargestellt. In Abbildung 10 wird die Ressourcenrolle der Ärzte als "Performer" bezeichnet. Auch in der BPMN wird der Performer als ein spezieller Typ einer Ressourcenrolle betrachtet. Gemäß Abschnitt 10.2.2 der BPMN 2.0-Spezifikation (BPMN 2011) kann ein Performer "eine bestimmte Person, eine Gruppe, eine Organisationsrolle oder -position oder eine Organisation" sein.

Einer der Hauptgründe, bestimmte Objekte als Ressourcen zu betrachten, ist die Notwendigkeit, Nutzungsstatistiken zu sammeln (entweder in einem betrieblichen Informationssystem wie einem Workflow-Management-System oder in einem Simulationsmodell), indem die Nutzung von Ressourcen über die Zeit (ihre Nutzung) pro Aktivitätstyp aufgezeichnet wird. Durch die Benennung von Ressourcenrollen in Informationsmodellen liefern diese Modelle die Informationen, die in Simulationen und Informationssystemen für die automatische Erfassung von Nutzungsstatistiken benötigt werden.

Ressourcenpools und Ressourcenzuweisung

Im Beispiel des Krankenhauses ist eine medizinische Abteilung als Prozesseigner die Organisationseinheit, die für die Reaktion auf bestimmte Ereignisse (hier: Patientenankünfte) und die Durchführung bestimmter Prozesse und Aktivitäten (hier: medizinische Untersuchungen) verantwortlich ist, einschließlich der Zuweisung von Ressourcen zu diesen Prozessen und Aktivitäten. Um den Aktivitäten Ressourcen zuweisen zu können, muss ein Prozesseigner Ressourcenpools verwalten, normalerweise einen für jede Ressourcenrolle jeder Art von Aktivität (wenn die Pools nicht zwischen den Ressourcenrollen aufgeteilt werden). Ein Ressourcenpool ist eine Sammlung von Ressourcenobjekten eines bestimmten Typs. Zum Beispiel bilden die drei Röntgenräume einer Abteilung für bildgebende Diagnostik einen Ressourcenpool dieser Abteilung.

Ressourcenpools können in einem OEM-Klassendiagramm durch spezielle Assoziationen zwischen Objektklassen, die Prozesseigentümer (wie medizinische Abteilungen) darstellen, und Ressourcenklassen (wie Ärzte und Räume) modelliert werden, wobei die Assoziationsenden, die den sammlungswertigen Eigenschaften entsprechen, die Ressourcenpools darstellen, mit "Ressourcenpool" stereotypisiert werden, wie in Abbildung 10 dargestellt. Zu jedem Zeitpunkt können die Ressourcenobjekte eines Ressourcenpools außer Betrieb (wie eine defekte Maschine oder ein Arzt, der nicht im Dienstplan steht), beschäftigt oder verfügbar sein.

Abbildung 10: Die Aktivitätsart "Untersuchungen" mit zwei Ressourcenrollen und zwei Ressourcenpools.
Ein Prozessverantwortlicher hat spezielle Verfahren, um die verfügbaren Ressourcen aus den Ressourcenpools den Aktivitäten zuzuordnen. Im Modell von Abbildung 10 verfügt eine medizinische Abteilung beispielsweise über die Verfahren "einen Arzt zuweisen" und "einen Raum zuweisen", um einen Arzt und einen Raum für eine medizinische Untersuchung zuzuweisen. Diese Verfahren zur Ressourcenzuweisung können verschiedene Strategien verwenden, insbesondere für die Zuweisung von Humanressourcen, wie z. B. die erste Bestimmung der Eignung potenzieller Ressourcen (z. B. auf der Grundlage von Fachwissen, Erfahrung und früherer Leistung), die anschließende Einstufung und schließlich die Auswahl der am besten geeigneten Ressourcen (nach dem Zufallsprinzip oder auf der Grundlage ihrer Reihenfolge). Siehe auch (Arias et al. 2018).

In dem in Abbildung 11 dargestellten konzeptionellen Prozessmodell werden ein Arzt und ein Zimmer immer gemeinsam zugewiesen und freigegeben (deallocated).

Abbildung 11: Ein konzeptionelles Prozessmodell, das auf dem Informationsmodell von Abbildung 10 basiert.
Dieses Prozessmodell beschreibt zwei kausale Gesetzmäßigkeiten in Form der folgenden zwei Ereignisregeln, die jeweils mit zwei Aufzählungspunkten angegeben werden: einer zur Beschreibung aller Zustandsänderungen und einer zur Beschreibung aller Folgeereignisse, die durch die Anwendung der Regel ausgelöst werden.

Wenn ein neuer Patient eintrifft:

• Wenn ein Raum und ein Arzt verfügbar sind, werden sie für die Untersuchung des Patienten bereitgestellt; wenn kein Raum oder Arzt verfügbar ist, wird der Patient in die Warteschlange aufgenommen;
• wenn ein Arzt und ein Raum zugewiesen wurden, wird mit der Untersuchung des Patienten begonnen.

Wenn eine Untersuchung durch einen Arzt in einem bestimmten Raum abgeschlossen ist:

• Wenn die Warteschlange leer ist, werden der Raum und der Arzt freigegeben; andernfalls, wenn sich noch Patienten in der Warteschlange befinden, wird der nächste Patient geholt, um von diesem Arzt in diesem Raum untersucht zu werden;
• wenn ein anderer Patient geholt wurde, beginnt die Untersuchung dieses Patienten.

Diese konzeptionellen Ereignisregeln beschreiben die reale Dynamik einer medizinischen Abteilung entsprechend den Entscheidungen des Geschäftsprozessmanagements. Änderungen in der Warteschlange und (De-)Zuweisungen von Räumen und Ärzten werden als Zustandsänderungen (im nicht notwendigerweise computergestützten Informationssystem) der Abteilung betrachtet, da sie in Datenobjekt-Rechtecken ausgedrückt werden, die Zustandsänderungen betroffener Objekte darstellen, die durch ein Ereignis in der DPMN verursacht werden.

Geplante Aktivitäten in die Warteschlange stellen

Immer wenn eine Tätigkeit ausgeführt werden soll, aber nicht beginnen kann, weil eine erforderliche Ressource nicht verfügbar ist, wird die geplante Tätigkeit als Warteauftrag in eine Warteschlange gestellt. Im Falle einer medizinischen Untersuchung eines Patienten, wie sie im Modell in Abbildung 10 beschrieben ist, stellt die Warteschlange also tatsächlich eine Warteschlange geplanter Untersuchungen (mit Patienten) und nicht eine Warteschlange wartender Patienten dar.

Als Folge dieser Überlegungen sollte die Warteschlange einer medizinischen Abteilung, die in Abbildung 10 als eine geordnete Ansammlung von Patienten modelliert ist, in geplante Gänge umbenannt werden. Darüber hinaus sollte der Klasse medizinische Abteilungen eine Eigenschaft geplante Untersuchungen hinzugefügt werden, die eine geordnete Sammlung von Patienten-Zimmer-Paaren enthält. Diese Modellelemente würden die Geschäftsprozesspraxis des Krankenhauses widerspiegeln, eine Liste von Patienten zu führen, die auf die Zuweisung eines Zimmers warten, in das sie gehen können, sowie eine Liste geplanter Untersuchungen, bei denen jeweils ein Patient auf einen Arzt in einem Untersuchungszimmer wartet.

Anzeige des Prozessverantwortlichen und der Aktivitätsausführenden

Der Prozessverantwortliche und die beteiligten Ausführenden können in einem DPMN-Prozessdiagramm dargestellt werden, indem ein rechteckiger Pool-Container für den Prozessverantwortlichen und Pool-Partitionen, so genannte Lanes, für die beteiligten Aktivitätsausführenden verwendet werden, wie in Abbildung 12 dargestellt.

Abbildung 12: Darstellung des Prozesseigners und der Aktivitätsausführenden in einem konzeptionellen Prozessmodell.

Ressourcenbeschränkte Aktivitäten in SimulationsentwurfsmodellenErweiterung vonOEM-Klassendiagrammen durch Hinzufügen einer "Ressourcentyp"-Kategorie

Das konzeptionelle Informationsmodell in Abbildung 10 enthält zwei Objekttypen, Räume und Ärzte, die den Bereich der Eigenschaften der Ressourcenrolle und des Ressourcenpools darstellen (Assoziationsenden stereotypisiert "Ressourcenrolle" und "Ressourcenpool"). Solche Objekttypen können als "Ressourcentyp" kategorisiert werden, mit der impliziten Bedeutung, dass sie ein Ressourcenstatusattribut (mit den möglichen Werten AVAILABLE, BUSY, OUT_OF_ORDER) und die Ressourcenmanagementoperationen isAvailable, allocate und release von einer vordefinierten Klasse Resource erben. Die Einführung von Ressourcentypen ermöglicht es, Modelle zu vereinfachen, indem diese Modellierungselemente aus OEM-A-Klassenmodellen entfernt werden und Teil ihrer impliziten Semantik werden.

Erweiterung von DPMN-Prozessdiagrammen durch Hinzufügen von ressourcenabhängigen Aktivitätsstartpfeilen

Die Überfrachtung von Prozessdiagrammen durch die Anzeige der gesamten Ressourcenmanagementlogik, die für ressourcenbeschränkte Aktivitätstypen erforderlich ist, wie in Abbildung 12 dargestellt, kann durch die Einführung des neuen Modellierungselements der ressourcenabhängigen Aktivitätsstartpfeile (RDAS) vermieden werden, die die Ereignisplanung mit der Warteschlange geplanter Aktivitäten, die auf die Verfügbarkeit von Ressourcen warten, kombinieren. In Abbildung 13 bedeutet der RDAS-Pfeil zwischen dem PatientArrival-Ereignis und der WalkToRoom-Aktivität beispielsweise intuitiv: Wenn ein PatientArrival-Ereignis eingetreten ist, starten Sie eine WalkToRoom-Aktivität (um den neu eingetroffenen Patienten in einen Untersuchungsraum zu bringen), sobald die erforderlichen Ressourcen (ein Raum und eine Krankenschwester) verfügbar sind.Abbildung 13: Verwendung ressourcenabhängiger Aktivitätsstartpfeile in einem Prozessentwurfsmodell.

Beachten Sie, dass im Gegensatz zu etablierten "prozessorientierten" Modellierungswerkzeugen, wie z.B. AnyLogic, das DPMN-Prozessmodell in Abbildung 13 keine Schritte zur Ressourcenzuweisung/-freigabe spezifizieren muss, da diese durch die Spezifikation der Ressourcentypen und Ressourcenkardinalitätsbeschränkungen der Aktivitätstypen im zugrundeliegenden OEM-A-Klassenmodell implizit gegeben sindDa die in Abbildung 13 gezeigten ressourcenabhängigen Aktivitätsstartpfeile von DPMN in BPMN nicht verfügbar sind, müssen neue Modellierungswerkzeuge zur Erstellung von DPMN-Prozessdiagrammen entwickelt werden.

Proceedings of the 2020 Winter Simulation Conference K.-H. Bae, B. Feng, S. Kim, S. Lazarova-Molnar, Z. Zheng, T. Roeder, und R. Thiesing, eds.

Gerd Wagner

Fachbereich Informatik
Technische Hochschule Brandenburg
Konrad-Wachsmann-Allee 5
Cottbus, 03046, DEUTSCHLAND

Referenzen

Arias, M., J. Munoz-Gama, und M. Sepulveda. 2018. "Towards a Taxonomy of Human Resource Allocation Criteria". In Business Process Management Workshops, edited by E. Teniente and M. Weidlich, 475-483, Heidelberg: Springer International Publishing.
Business Process Model and Notation (BPMN), Version 2.0, 2011. http://www.omg.org/spec/BPMN/2.0, Zugriff am 13. Mai 2020. Gordon, G. 1961. "A general purpose systems simulation program". In AFIPS '61: Proceedings of the Eastern Joint Computer Conference, 87-104, New York: Association for Computing Machinery.
Gurevich, Y. 1985. "Eine neue These". Abstracts, Amerikanische Mathematische Gesellschaft, 6(4):317.
Schruben, L.W. 1983. "Simulationsmodellierung mit Ereignisgraphen". Communications of the ACM 26:957-963.
Wagner, G. 2019. "Informations- und Prozessmodellierung für die Simulation - Teil II: Aktivitäten und Verarbeitungsnetzwerke".
https://dpmn.info/reading/Activities.html, abgerufen am 13. Mai 2020.
Wagner, G. 2018. "Informations- und Prozessmodellierung für die Simulation - Teil I: Objekte und Ereignisse". Journal of Simulation Engineering 1:1-25. https://articles.jsime.org/1/1.
Wagner, G. 2017. "An Abstract State Machine Semantics for Discrete Event Simulation". In Proceedings of the 2017 Winter Simulation Conference, edited by W. K. V. Chan, A. D'Ambrogio, G. Zacharewicz, N. Mustafee, G. Wainer, and E. Page. 762-773. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. https://www.informs- sim.org/wsc17papers/includes/files/056.pdf.

Biografie des Autors

GERD WAGNER ist Professor für Internettechnologie im Fachbereich Informatik der Technischen Hochschule Brandenburg, Deutschland, und außerordentlicher Professor im Fachbereich Modellierung, Simulation und Visualisierungstechnik der Old Dominion University, Norfolk, VA, USA. Seine Forschungsinteressen umfassen Modellierung und Simulation, fundamentale Ontologien, Wissensrepräsentation und Web-Engineering. In den letzten Jahren hat er das OEM&S-Paradigma und die Prozesssimulations-Modellierungssprache DPMN entwickelt (siehe https://dpmn.info). Seine E-Mail Adresse lautet G.Wagner@b-tu.de.