In my last post, I showed you how process modelling works by visualizing cooking recipes.
Of course, I haven´t modelled straight on, but I had to follow some "basic rules of EPC modelling".
Therefore, I show you today which basic rules exist.
An Activity (or Function) describes an incidental task that typically consumes time and resources. Therefore, it is an active component and has decision-making authority.
An Event describes, in accordance with DIN 69900, an occurred defined condition that causes a sequence of activities. Therefore the event is a passive component and may have no function in contrast to the decision-making authority. Events can trigger functions. Functions are triggered by events. Events describe an occurring condition.
Short overview of Rules
Generally, you start with an Event, if you model an EPC.
A number of Activities can follow an Event. In the past, it was said, that Events and Activities must alternate. This leads to very long process models with a lot of trivia events. Therefore, we suggest today to only add an event, if an important state change needs to be documented.
Recommendation, when using Events:
- at the beginning of the process or after start-process interfaces
- at the end of the process or before the end of process interfaces
- Decision events by XOR or OR connectors
- for important events, for example Milestones in project
Activities or Events must not have more than one outgoing or incoming Connection.
.jpg)
The control flow of the process is modelled using Rules (gateways).See afterwards, which Rules exist.
Rules can be used as follows:
- Of exactly one ingoing Connection follow a number of outgoing Connections (SPLIT).
- Of a number of ingoing Connections follow exactly one outgoing Connection (JOIN)
A sequence of Rules is possible.
An EPC is generally closed with the same operator like it was opened.
You end the EPC with an Event.
Logical operators
In an EPC you can use following Rules:
.jpg)
SPLIT: The processing steps that follow the rule occur in parallel and have to be performed.
JOIN: All processing steps for incoming connections must be completed so that the processing steps that follow the rule can be performed.
SPLIT: Exactly one of the following rule processing steps must be executed.
JOIN: Only one of the processing steps for incoming connections may be completed so that the processing steps that follow the rule can be performed.
SPLIT: At least one of the following rule processing steps (or even several or all processing steps) must be performed.
JOIN: At least one processing step (or even several or all processing steps) must be completed, whereupon the processing steps that follow the rule can be performed.
For logic operations between Events and Activities, there are special rules, which are shown in the ARIS Express model attached to this post. For your convenience, I also added a screenshot of the rules below:
I put this summary of the rules next to my monitor while modelling. It helps me a lot. I hope it helps you, too! So long, have fun modelling till my next post.
ARIS model
Hi Ramona,
I am very interested in the semantic of OR connectors. I can´t see (and I am backed by some authors) how can a OR really exists in a enterprise, since there will be no control of what actually happens and how long one would have to wait.
BTW, languages such as Activity Diagram (UML) have OR.
Can you provide example where this would be useful and make sence in real world?
Thanks,
Jerry
First, I want to correct myself. I wanted to say that some languages DO NOT have or (such as UML´s DA).
By your explanation, it seems that the OR is useful to register decisions that cannot be fully anticipated as a composition of AND and XOR.
In this way, the exigence of documentation is definitive.
Jerry
She created the figures on her own. But the basic rules of EPC modelling are for example documented in:
author="Scheer, A.-W. and Thomas, O. and Adam, O.", title="Process Modelling Using Event-Driven Process Chains", year="2005", booktitle="Process-Aware Information Systems", editor="Dumas, M. and van der Aalst, W. M. P. and ter Hofstede, A. H. M.", address="Hoboken, New Jersey, USA", publisher="Wiley", pages="119--146"
Hello Ramona,
I have been doing ARIS training for different groups within our enterprise over the past 6 months (introducing EPC methodology, etc.) and I keep getting a common question from each group:
"Why do you have to follow every function/activity with an event...it seems odd and redundant?"
Some take the Event- Activity- Event -Activity alternating flow at face value and proceed.
Others do not.
All see the need for an event to start and end a process, but many take exception to having to close each function/activity with an event.
It seems redundant to them, and is proving to be a barrier for adoption of EPC's in general even though the toolset doesn't hold you to this.
Do you have an answer to this question? The information that you provided above is a good start, but I wanted to know if there is a simplified answer that I can use as I introduce this material to new users of the tool.
Hello,
Since "A number of Activities can follow an Event" I am wondering whether two functions could be linked via a logical operator ('AND') and followed by a common function, instead of common event. Sometime there is no suitable event that could be put after a function in order to merge two branches into one function.
What do you think about that?
HI, this ist when 2 events trigger an activity :
Even1: raining
Event2: not raining
Activity: i will go to the beach
then, I can add many previous activities just after the event1 or 2: close windows, close doors, pick car keys, take my umbrellas or not - and so on
HI, this ist when 2 events trigger an activity :
Even1: raining
Event2: not raining
Activity: i will go to the beach
then, I can add many previous activities just after the event1 or 2: close windows, close doors, pick car keys, take my umbrellas or not - and so on
