How to model business processes in eEPC notation?
In the course of my work and teaching, I come across a description of the organization’s business processes in the eEPC (Extended event driven process chain) notation, which was adopted by the de facto standard for describing the procedures and procedures after examining the organization’s activities. Unfortunately, using this notation it is very easy to make modeling mistakes without knowing the rules by which it is compiled. These errors lead subsequently to inconsistencies in the logic of the process, and as a result - a misunderstanding of the real situation in the organization. This article is a summary of my experience in modeling business processes, and I hope some readers will provide useful guidance.
First, remember what is called a process. There are a lot of definitions of the process, let’s dwell on the most well-known and formal of them: the process is a coherent and interconnected sequence of actions (work, operations) carried out by officials and departments of the organization to obtain the desired end result (goal achievement, task solution, program implementation, service provision ).
Modeling in eEPC notation is a description of the sequence of functional steps (actions) within a single business process that are performed by employees (divisions, departments) and allows communication between organizational and functional models, so this notation is ideal for describing scenarios and procedures.
There are a lot of objects that can be used in the model, but often only a few of them are used: the process interface, the event, logical rules, the function and the objects of the organizational scheme (position, employee, department).
I am often asked how to name events and functions when modeling. In order to answer this question, it is necessary to understand what an event is. An event is a state that is a prerequisite for the start and end of a function. The basic rule of modeling is that any process must begin and end with an event or an interface to another process, and any function must begin with an event or a logical operator. When defining events, it is important to remember that an event is instantaneous in time, that is, there can be no events like “Waiting for agreement approval”, it should be replaced with two events “Agreement agreed” and “Agreement not agreed”. Examples of the most typical events:
As for functions, then it must be remembered that a function is a description of an element of work that forms one (usually minimal) logical step within the process, therefore it is undesirable to list several actions in the name of a function, for example, “Checking and buying goods”, “Concluding a contract and invoicing ”, it is necessary to break down such cases into 2 independent functions.
')
Most of the errors in the model are due to improper use of logical operators and their combinations. There are only three of them: and, or, exclusive or. I will give a few examples of their use on the example of simple models.
The most common mistakes are the use of the operator "OR" and "exclusive OR" after the event, for example:
Both of these situations are prohibited because the event cannot make decisions. In this case, the only option is to use the operator "And":
or adding two additional states:
Another error is the omission of logical operators when the event has two outgoing connections, or the function has two incoming connections.
The most common mistake is incorrect use of feedback, for example, like this:
In this case, the logical operator is missing, that is, the rule that a function can have only one incoming link has been violated. It will also be an error if the AND operator is used as a logical operator. The only correct solution in this case is the use of the logical operator "exclusive OR":
In conclusion, I want to note that for a successful complete description of a business process, it is necessary to know not only the rules of modeling, but before starting the description you need to know:
First, remember what is called a process. There are a lot of definitions of the process, let’s dwell on the most well-known and formal of them: the process is a coherent and interconnected sequence of actions (work, operations) carried out by officials and departments of the organization to obtain the desired end result (goal achievement, task solution, program implementation, service provision ).
Modeling in eEPC notation is a description of the sequence of functional steps (actions) within a single business process that are performed by employees (divisions, departments) and allows communication between organizational and functional models, so this notation is ideal for describing scenarios and procedures.
There are a lot of objects that can be used in the model, but often only a few of them are used: the process interface, the event, logical rules, the function and the objects of the organizational scheme (position, employee, department).
I am often asked how to name events and functions when modeling. In order to answer this question, it is necessary to understand what an event is. An event is a state that is a prerequisite for the start and end of a function. The basic rule of modeling is that any process must begin and end with an event or an interface to another process, and any function must begin with an event or a logical operator. When defining events, it is important to remember that an event is instantaneous in time, that is, there can be no events like “Waiting for agreement approval”, it should be replaced with two events “Agreement agreed” and “Agreement not agreed”. Examples of the most typical events:
- the onset of the planned date, time, for example, “a decision was made to start a project”
- receipt or sending by an employee of an application, order, form, information, for example, “a request has been received from a client”
As for functions, then it must be remembered that a function is a description of an element of work that forms one (usually minimal) logical step within the process, therefore it is undesirable to list several actions in the name of a function, for example, “Checking and buying goods”, “Concluding a contract and invoicing ”, it is necessary to break down such cases into 2 independent functions.
')
Most of the errors in the model are due to improper use of logical operators and their combinations. There are only three of them: and, or, exclusive or. I will give a few examples of their use on the example of simple models.
The most common mistakes are the use of the operator "OR" and "exclusive OR" after the event, for example:
Both of these situations are prohibited because the event cannot make decisions. In this case, the only option is to use the operator "And":
or adding two additional states:
Another error is the omission of logical operators when the event has two outgoing connections, or the function has two incoming connections.
The most common mistake is incorrect use of feedback, for example, like this:
In this case, the logical operator is missing, that is, the rule that a function can have only one incoming link has been violated. It will also be an error if the AND operator is used as a logical operator. The only correct solution in this case is the use of the logical operator "exclusive OR":
In conclusion, I want to note that for a successful complete description of a business process, it is necessary to know not only the rules of modeling, but before starting the description you need to know:
- Who
- what task does
- when
- with what tools
- and what data (what documents are received at the entrance, what output)
- who is responsible for success or failure (process owner)
- how to measure success or failure (key performance indicators)
Source: https://habr.com/ru/post/137086/
All Articles