Startseite >> Wissen >> Techniken >> EPK-Modellierung

EPK-Modellierung

Ziel:

Es können Geschäftsprozesse einer Firma dargestellt werden, um bestehende Prozesse im Hinblick auf ihre derzeitigen und zukünftigen Veränderungen zu veranschaulichen.

Beschreibung:

Ereignisgesteuerte Prozessketten (EPK) sind halbformale grafische Darstellungen, die hauptsächlich dazu benutzt werden, um Geschäftsprozesse zu veranschaulichen.  Die EPKs wurden in den 90ern vom Institut für Wirtschaftsinformatik (IwI) an der Universität des Saarlandes entwickelt und in das ARIS (Architecture of Integrated Information Systems) Framework integriert. Dadurch, dass EPKs einerseits eine zentrale Komponente des SAP R/3 Systems und des darunter liegenden Frameworks und andererseits im ARIS Framework und in den homogen weit verbreiteten ARIS Werkzeugen von ids-scheer enthalten sind, stellen sie eine gebräuchliche, allgemein bekannte Methode der Geschäftsprozessmodellierung dar, welche in Industrie und akademischer Praxis bereits gebräuchlich ist.

Anwendung

Die EPK-Schreibweise besteht aus drei grundlegenden Notationselementen, um Vorgänge zu beschreiben. Diese Elemente werden nun in den folgenden Abschnitten beschrieben.

EVENT

Notationselement:

Beschriftungskonvention:

Zur Beschriftung von Events gilt die Vorgabe Objekt-Verb. Das Verb soll immer in der Vergangenheitsform (Perfektform) stehen. Beispielsweise:

  • „Recipient chosen“ („Empfänger ausgewählt“)
  • „Recipient has been chosen“ („Empfänger wurde ausgewählt“)

Beschreibung:

Ein Event kann sein:

  • ein Trigger (Auslöser) für eine bestimmte Funktion, welcher einen bestimmten zu erfüllenden Status genauer beschreibt (Input für eine Funktion)
  • ein Status, der erreicht wurde, nachdem ein Vorgang stattgefunden hat (Output einer Funktion)

Beispiele:

  • Empfänger ist ausgewählt worden
    Dieses Ereignis kann einerseits der Auslöser für eine nächste Funktion sein oder andererseits das Ergebnis einer Funktion „wähle Empfänger aus“
  • Lieferauftrag angekommen
    Dieses Event tritt ein, nachdem der Lieferauftrag getätigt wurde


FUNKTION

Notationselement:

Beschriftungskonvention:

Zur Beschriftung von Funktionen gilt die Vorgabe Verb-Objekt. Das Verb soll immer in der Präsensform stehen. Beispielsweise:

  • „Choose Recipient“ („wähle Empfänger“)
  • „Order IT equipment“ („bestelle IT Equipment“)

Beschreibung:

Eine Funktion steht für einen bestimmten Ablauf oder Auftrag, welcher von einer bestimmten Person ausgeführt wird und einen gewissen Input braucht, um einen Zustand zu erreichen, möglicherweise einen definierten Output zu erzeugen.

Es ist wichtig zu erwähnen, dass der Term „Funktion“ missverständlich sein kann, wenn er sehr detailliert Tätigkeiten (z.B. „wähle Empfänger aus“) oder sehr allgemein Aufträge („bestelle IT Equipment“) beschreibt.

Diese Beispiele zeigen, dass EPKs für die Präzisierung verschiedener Abläufe oder Aufträge auf sehr unterschiedlichen Detaillierungsebenen benutzt werden.

Beispiele:

  • bestelle IT Equipment
    Auf einem sehr hohen Level, ein sehr abstrakter Geschäftsvorfall, welcher den Vorgang des Bestellens von IT Equipment umfasst. Dies indiziert, dass die Aufgabe einer bestimmten Person das Bestellen von IT Equipment ist (enthält keine genauen Angaben darüber, wie die Funktion ausgeführt werden soll).
  • wähle Empfänger aus
    Diese Funktion beschreibt eine Unteraufgabe der Aufgabe “bestelle IT Equipment“

Logische Operatoren XOR, OR, AND

Notationselement:

Beschriftungskonvention:

- keine -

Beschreibung:

Die logischen Operatoren werden benutzt, um Funktionen und Events zu verbinden oder um folgendes abzubilden:

  • Entscheidungen oder Optionen (XOR wenn nur EINE der angegebenen Optionen möglich sein soll; OR, wenn mehrere Optionen möglich sind )
  • Parallele Ausführungen von Funktionen (AND)

Beispiele:

Das Beispiel zeigt eine EPK, in der die Details der Funktion „Bestelle IT Aktivitäten“ beschrieben werden. Eine Bestellung kann entweder auf eine Vorlage oder auf einen ganz neuen Prozess bezogen sein.

 

Zusätzlich zu diesen 3 Grundelementen kann eine EPK noch andere detaillierte Elemente darüber enthalten:

Organisationseinheit

Notationselement:

Beschriftungskonvention:

- keine -

Beschreibung:

Die Organisationseinheiten stehen für Rollen oder Personen, die verantwortlich für bestimmte Funktionen sind.

Beispiele:

Die Mitarbeiter der Technikabteilung sind verantwortlich für das Bestellen von IT Equipment.


Informationsobjekt

Notationselement:

Beschriftungskonvention:

- keine -

Beschreibung:

Ein Informationsobjekt kann als Input oder Output einer Funktion angesehen werden.

Beispiele:

Der Warenkorb kann ein Informationsobjekt sein, welches während der Bestellung des IT Equipments erstellt wurde. Der Katalog, der alle möglichen IT Elemente beinhaltet, kann ein Eingabeelement (Input) sein.

 

Prozesspfad

Notationselement:

Beschriftungskonvention:

siehe „Funktion“

Beschreibung:

Der Prozesspfad ist mehr oder weniger das gleiche Element wie eine Funktion. Er wurde eingeführt, um zu zeigen, dass EPKs hierarchisch beschrieben werden können, beginnend mit einer sehr abstrakten, allgemeinen Beschreibung und fortlaufend detaillierteren Funktionen. Des Weiteren repräsentiert ein Prozesspfad komplexe Aktivitäten (beispielsweise eine Aufgabe oder einen Unteraufgabe), die später noch einmal in einer separaten EPK beschrieben werden.

Hinweis: Der Prozesspfad kann auch, aus rein praktischen Gründen, eingesetzt werden, um Platz zu sparen. So zum Beispiel, um ein bestimmtes Modell zu repräsentieren, dessen genauere Beschreibung zu komplex wäre. In diesem Fall können mehrere Aktivitäten unter einem abstrakteren Namen gruppiert werden und durch ein Prozesspfadelement ersetzt werden. Dies würde dann in einem anderen EPK modelliert werden. So hat man zwei Modelle, mit denen besser umzugehen ist.

Beispiele:

Das untere Beispiel, beschrieben in dem „Funktion“-Teil, kann als ein gutes Beispiel zur Beschreibung des Prozesspfad-Tags benutzt werden. Die Aktivität “bestelle IT Equipment“ kann als ein Prozesspfadelement in einer abstrakten EPK dargestellt werden. Dies könnte dann in einer separaten EPK näher noch spezifiziert werden (siehe Bsp.):

Das Prozesspfadelement

wird hier dann in einer weiteren EPK näher detailliert:

„Das große Bild“

Die beschriebenen Notationselemente werden dazu eingesetzt, um Geschäftsprozesse über verschiedene Detaillierungsgrade hinweg näher zu veranschaulichen. Wie angedeutet, stehen die verschiedenen Elemente in Beziehung zueinander. Zum Beispiel ist eine Organisationseinheit verantwortlich für einen bestimmten Ablauf. Ein Informationsobjekt kann als In- oder Output dienen oder von einer Aktivität  oder einer Event-Trigger-Funktion beeinflusst werden. Ein Informationsobjekt kann aber auch als Status, der nach Ausführung einer Funktion erreicht wird, angesehen werden.
Diese Beschreibung zeigt auf, dass Funktionen (und Ablaufelemente) als das zentrale Objekt eines EPK-Flows angesehen werden können, da sie mit allen anderen Objekten in Beziehung stehen.
Das "große Bild" operationalisiert die Verbindungen zwischen Notationselementen per Konnektoren, wie man in der folgenden Darstellung sehen kann:

Zu den verschiedenen Verbindungen zwischen Objekten sowie den allgemeinen Notationen einer EPK gehören einige Regeln und Konventionen, die im Folgenden erklärt werden :

Regel 1
Ein EPK-Modell muss mit einem Event dem so genannten Startevent , beginnen!

Regel 2
Ein EPK-Modell muss mit einem Event , dem so genannten Endevent , enden!

Regel 3
Funktionen und Event s sollen abwechselnd vorkommen!

Regel 4
Bezüglich jeder Verbindung zwischen Event s und Funktionen gilt, dass jedes Event und jede Funktion nicht mehr als einen Input- und einen Output-Konnektor haben dürfen!

Diese Regel gilt nur für die Verbindung von Funktions- und Eventenden, nicht aber für die Verbindungen zu anderen Elementen, wie logische Operatoren, Organisationseinheiten oder Informationsobjekte.

Die folgenden vier Fälle sind syntaktisch falsch:

In jedem dieser Fälle hätten logische Operatoren benutzt werden müssen, um die Funktionen und Events zu verbinden, entweder „AND“, „OR“ oder „XOR“ .

Eine korrekte Lösung für Fall 1 wäre:

Regel 5
Ein Event ist immer passiv, es hat keine Entscheidungsgewalt!

Diese Regel betrifft besonders die Benutzung von logischen Operatoren und die Verbindung von Funktionen und Events, die auf diesen Verbindungen basieren.

Zwei Arten von Verbindungen können unterschieden werden, Teilungen und Vereinigungen.

Bei einer Vereinigung werden mehrere Funktionen oder mehrere Events durch Benutzung eines logischen Operators zu einem Event oder einer Funktion miteinander verbunden. Das folgende Schaubild zeigt die AND-Vereinigung, bei der mehrere
Events durch AND mit einer Funktion verbunden sind.

Vereinigungen sind meist kein Probleme, da keine Entscheidung getroffen werden muss.

Bei einer Teilung wird ein Event oder eine Funktion durch einen logischen Operator mit mehreren Funktionen oder Events verbunden. Das Beispiel zeigt eine AND-Teilung, mittels derer der Verlauf einer Serie von Funktionen geteilt wird.

Wenn man eine Funktion durch Benutzung von logischen Operatoren mit mehreren Events verbindet , dann ist der Teilungsfall kein Problem, da keine Entscheidungen getroffen werden müssen, wohingegen bei einer Verbindung eines Events mit mehreren Funktionen Probleme auftreten können, abhängig von der Art der Konnektoren. Drei Fälle (basierend auf den drei logischen Operatoren) müssen hier unterschieden werden:

Fall 1: Koppelung mit AND

Solange keine Entscheidung notwendig ist, ist dieser Fall erlaubt. Er repräsentiert die parallele Ausführung aller drei Funktionen.

Fall 2: Koppelung OR

Eine der Funktionen muss ausgewählt werden. Da ein Event immer passiv ist und daher keine Entscheidung treffen darf, ist dieser Fall NICHT erlaubt!

Fall 3: Koppelung XOR

Auch hier muss entschieden werden welche der drei Funktionen ausgeführt werden soll. Aus der Passivität des Events folgt, dass dieser Fall ebenso NICHT erlaubt ist!

Als erlaubte Alternative zu Fall 2 und 3 ist es möglich, hinter dem Event eine Funktion einzufügen, die die Entscheidung trifft, und, abhängig von der jeweiligen Entscheidung, Events vor den Funktionen hinzufügt.

Zusatzinformationen

  • Austausch (interchange) von EPKs
    Es existiert eine XML-basierte Sprache namens EPML (EPC Markup Language) zum Austausch von EPKs. Sie wurde von der EPK Community entwickelt (nähere Informationen unter: http://wi.wu-wien.ac.at/Wer_sind_wir/mendling/EPML/).
    Aufgrund der zahlreichen Mappings ist es möglich EPK-Modelle zwischen verschiedenen Tools auszutauschen (Beispiel: das ARIS Toolset). Es gibt auch weitere Tools, die EPKs syntaktisch überprüfen können.
  • Simulation von EPKs
    Obwohl EPKs auf Petri-Netzen basieren, ist es nicht unbedingt möglich, den Geschäftsprozess, auf dem sie basieren, zu simulieren, da die Definition von EPKs normalerweise keine genauen syntaktischen und semantischen Definitionen vorgibt. Es gibt jedoch einige Versuche, dieses Problem durch formalere Definitonen von EPKs zu lösen. Außerdem wurde ein zusätzliches Tool mit dem Namen „ EPC Tools“ von der Universität Paderborn entwickelt, das es dem Benutzer ermöglicht, ein EPK-Modell zu erstellen oder ein bereits existierendes EPK-Modell zu integrieren und dann das Ganze zu simulieren. Weitere Informationen dazu finden sich unter: http://wwwcs.uni-paderborn.de/cs/kindler/Forschung/EPCTools/. Mit dieser Software lassen sich beispielsweise syntaktische Fehler finden oder auch mögliche Deadlocks identifizieren.

Diese Technik erfüllt folgende Praktiken:

Aufgaben und Geschäftsprozesse erheben