Every thing is a form of manifestation of unlimited diversity.
Kozma bars

Introduction to eEPC Notation

Currently, there are many different principles of graphical representation of business processes, called notations. Why are there a lot of them? This question has been asked for decades by everyone who is faced with the need to describe business processes. Let's look at the reasons. There are three of them (in my opinion):

• Different tasks. Not all notations are equally convenient for solving various problems. For example, the notation may be convenient for the top-level business process and not at all convenient for describing the workflow.
• Different developers of such notations. At different times, different developers tried to come up with new principles for describing circuits. They did this out of good intentions, when in practice they were faced with a situation where the notation used by them cannot reflect the necessary subtleties (or not visually). Sometimes in the process of evolution such notations became as if parallel, i.e. look different, and the tasks solve the same.
• The desire to stand out. This is when, for some unknown reason, a new notation suddenly appears, which does not have anything outstanding in itself, but, for some reason, it is advancing by its creator as the most advanced know-how. This is still happening.

The purpose of this article is not to consider all kinds of notations (I deliberately do not call their names), but to dwell on a detailed description of the notation that I chose for my projects during the long search for the most optimal option.
If someone is interested to find out what other notations are and what they are used for, I plan to do this in another article called “Let's talk about notations”, but this is still in the plans.
It's time to start our story about a very interesting, simple and practical eEPC notation (in translation: an extended description of the event chain of processes). In its literal translation, the main purpose is revealed: a description of a chain of business processes. The main "feature" of the notation in its principle of "eventfulness", which we consider in detail.
What are the advantages of eEPC notation?

1. Firstly, this is not exactly pure notation. Those. if in some notations there is a rigid set of elements and rules for their use (otherwise everything will be confused), then the principle of eEPC allows you to add your own elements. How is this provided? Of course, there is a certain “pivot” around which everything is built, i.e. a set of clear rules according to which the scheme is built and according to which it is then read. In addition, you can add your element, include the rules for its use in your own corporate standard (to exclude the initiative, which can confuse the scheme and complicate its readability) and that's it! This is a very important point. In addition, any other restrictions and rules can be set in your corporate standard.
2. The eEPC contains elements of logic. This allows you to build a scheme with the conditions that are necessary to describe the activity ("if the contract is agreed, then ...., otherwise ...")
3. The simplicity of the elements allows you to draw diagrams in software products, and in any other way, even on paper, you will not be confused.
4. eEPC is so easy in learning and perception that it can be used in real life, and not just gather dust in the closet. It will take about 2 hours to learn the rules (if the student wishes).

Of course, like everything else in this world, it has its drawbacks. But rational use reduces them to a minimum. The main drawback, in my opinion, is the fact that if you use simple tools (ie, programs for drawing diagrams, and not for modeling business processes), then we do not have a single database of objects. In addition, it is difficult to control the inputs / outputs (it is necessary to control them, that is, to come up with a method of such control, if required). But, on the other hand, the use of tools for modeling complex business processes is very impressive amounts, and the project with their use is measured in millions. And so we have a very economical and understandable tool. More specifically, this flaw relates specifically to the description method that I consider; using MS Visio or similar software. If you use specialized business process description systems that support object databases, this disadvantage can be avoided. Well, it's time to start ...
')

The main “core” of eEPC notation

As I already mentioned, in the literal translation of the abbreviation eEPC lies the concept of eventfulness. This is a very important point on which the whole principle of constructing the scheme is built. So, there are two key concepts: "Event" and "Function". When someone first tries to draw their process in the form of an eEPC diagram, the question often arises, what is the difference between an event and a function? This must be clearly understood, otherwise an unpredictable result will be obtained. So: an event is a fact of accomplishment of something, and having no duration in time, or this time tends to zero (or does not matter). Moreover, an event always causes the need to execute a function, and the execution of a function always ends with an event. Let me explain with an example. The phone rings. The manager picked up the phone. In this case, the “Phone Rings” is an event. A telephone conversation is a function. The conversation ended (hung up) –– again the event. Thus, there is an event chain: Call - talk - end of the call. And the completion of the call will certainly require the implementation of a new function: recording the result of the call, etc.
Let's try to draw it. First you need to figure out how to display the elements of "Event" and "Function".


These two simple elements form the basis of the rules for describing business processes in eEPC notation. I think I need to say a few words about the colors used. If you came across the description of processes in other notations, as a rule they were black and white. And this is correct, there should be no obvious dependence of the content on the color, since the scheme can be drawn in pencil on paper, printed on a black-and-white printer, etc. In this case (in the eEPC note), it so historically happened that the elements have certain colors. Not to say that it was necessary, but the habit is developed, and the perception in electronic form is better - you immediately see what is what. These colors can be considered as a recommendation. Why are they like that? I'm not exactly sure, but it seems to me that when ARIS made support for the eEPC notation in its product, it gave them such colors that they “got accustomed”. By the way, sometimes this notation is also called “ARIS”, “ARIS EPC”, which is not entirely true, since ARIS did not invent this notation, but made its support in its business process modeling program. In general, I recommend using colors. The main thing is that the form of the elements themselves should not be the same (that is, differ only in color), since in black and white this can be confusing. There are other rules that allow us to give a “slimness” to the eEPC diagram, we will talk about them.
So, there is an event, there is a function. How are they related?
We see that event1 led to the need to perform a certain function, which ended with an event2 . If applied to the example with a phone call, it will be like this:


Bundle event - function - it is customary to display the event from top to bottom in one line or from left to right. The direction of the chain is indicated by connecting lines with arrows.

To make the scheme more visual, the notation provides for several more standard elements:

• Position (performer). Who performs this function
• Information . Any information used to perform a function other than the documentary. For example, a phone call, instructions for performing an operation, etc.
• Document . The “Document” element is intended for displaying media (paper or electronic). Those. representation of information in a specific structure.
• Program (application). Software used to perform the function.

All other elements are auxiliary, and are practically not regulated by the requirements of the eEPC itself. However, there are no obstacles to adding your own elements. The main thing is to fix it in the internal standard so that there is a common understanding of how they look and why they are applied. Such an extension does not violate the requirements, if the event-function-event bundle is not violated, and is intended only to improve the perception of information or adapt the description rules to any industry specificity. I added my own set of elements, which I will discuss below.
It is also required to find out how the considered elements should be located. All of these elements must somehow be associated with a function. This is a general rule: no element is associated with an event, except for the function. Those. All these elements must be connected by arrows with the function. As for the arrows and their directions: it is considered that if there is no direction of information transfer, then instead of the arrow just a line is displayed. If information enters (arrives at the input), then the direction of the arrow from the object to the function, if it does, then vice versa.
A couple of words about the location of these elements in the diagram and you can redraw our scheme, specifying the execution of the call processing function. There are no strict requirements for the location of the elements, but it is customary to display them on all schemes equally (for uniformity and coherence of the scheme). To unify the spring type of graphical schemes of business processes, such rules should be fixed in the internal standard and follow them. A little later and give some recommendations on this issue.
Now we will redraw our scheme:


We see that the operator performs the processing of an incoming call, acting in accordance with the rules for processing incoming calls and uses the CRM program for this. Neither incoming nor outgoing documents are used.
As I already mentioned, one of the strengths of the notation are the elements of logic. At the same time it is one of the most difficult to understand moments. Therefore, first I will give an example, and then we will separately deal with the elements of logic.
Let our example be like this: if a client is interested, the sales manager conducts further work with him and issues a commercial offer, which is sent by mail using the MS Outlook email client. If there is no interest, then the call processing is completed. In real life, it would be good to use the call termination rules, but this is me, by the way, for the time being, we will simplify it. Here's what happens:

Elements of logic in eEPC notation schemes

The elements of logic are simple, but there are some peculiarities and rules for the scheme to be logical and unambiguously interpreted. The most important rule that you need to adhere to 100%: logical decisions can be made only when performing functions . Those. after some event there can be no ramification. Why? Because in this case it contradicts the very concept of an event - it is simple and instant, with no execution time. For example, if the phone rang and the person is sitting thinking whether to pick up the phone or not, it will theoretically be a function where he makes a decision. And practically, including from common sense, he violates the rules for handling calls, because he is paid a salary for processing these calls, and there is nothing to talk about (in general, as shown in the diagram).
In total there are 3 elements of logic:

• And When two or more events occur simultaneously;
• Or . When one or several events can occur, but at least one must necessarily occur;
• EXCLUSIVE OR . Either one or the other. Those. two options are not possible at the same time.

Here are some of them:




As you can see, there are two options for the graphical representation of the elements of logic. They are no different, completely alternative. I brought them both, because in practice, in various sources you can see both options. Which one to use is up to you. I like the first one better.
Now you need to understand the use of elements of logic. First, consider the options encountered, then move on to an example. Let's sort each element separately.
The logical element "and".

When a function requires the simultaneous execution of several events:



Example: If the reporting period is closed (event 1) and the deadline for submitting a report to a manager (event 2) is, the employee prepares a monthly report.

The connection of elements, if during the execution of a function, several events occur:



Example: Some work with the customer has been completed. Two events were simultaneously recorded: mutual settlements were verified (event 1), the act was signed (event 2).

In practice, such an application is not common. As a rule, if many actions are combined in one function.

The connection of elements, if, when performing several functions, an event occurs:



Example: The storekeeper collected an order (function 1), the operator wrote out the documents (function 2), the product is ready for shipment (event).

The combination of elements, if the occurrence of a single event leads to the execution of several functions:



Example : Received a consignment of goods (event). At the same time, the shipment of the goods previously ordered by customers and the placement of goods remaining in the warehouse begins.

The logical element "OR".
The connection of elements, if one of the events can cause the execution of the function:

Example : An application was received by telephone (event 1) or an application received by e-mail (event 2) would result in the need to process it.
Connection of elements, if one function can trigger at least one event:


Example: An item is prepared and sent for shipment to a customer. The invoice could be sent by mail (event 1), by fax (event 2).

The connection of elements when the execution of several functions causes an event:



Example: A service is provided (function 1) or a product is sold (function 2), a debt has arisen with a customer (event 1).

Logical element "EXCLUSIVE OR".

The connection of elements when one and only one of the events is necessary to perform a function:



Example: A customer came to the store in person (event 1) or made an order via the Internet (event 2). It is necessary to complete the shipment of the goods (function 1).

Connection of elements, if as a result of the function execution, at most one of the events occurs:



Example: The decision is either made or not.

The combination of elements, if the event occurs after one and only one of the functions is performed.









Example : Delivery of goods is carried out (event 1) either by own transport (Function 1) or by a transport company (function 2)

The correct application of the elements of logic requires some practice. But it is not difficult. It should be noted that not all the considered combinations are widely used in practice (and in general this is determined by the analyst’s way of thinking).

Try to apply the elements of logic in practice. If there are difficulties, write to me, I will try to help.

Extension of notation by own elements

As I said, the eEPC is not exactly a notation, namely the rules of description. And these rules do not prohibit adding your own elements to the schema. The main thing is that these elements should be understandable, and there should be a document where such extensions of elements are fixed. For example, I use the following additional elements that arose gradually in the process of describing real processes for various tasks, from a simple description to setting tasks for automation.


File with data . Used when the data file is created as a result of an operation, or the file is used to perform an operation.
Database. Used to describe the flow of information between automated systems.
Card file. Used to display a paper file or archive.
Material flow Used to indicate incoming and outgoing material flows, as well as resources consumed during the process. The material flow is displayed to the left of its accompanying documents.
Information cluster. Used to refer to structured information (entity representation). The diagram can be used to refer to documents formed programmatically using custom applications. In this case, the element "Cluster" is located to the left of the corresponding document. Those. says that the user not only created a paper document, but also created an instance of it in the program.

Agreement on the rules for placing figures on the scheme

By itself, the eEPC notation does not impose strict requirements on the location of elements relative to each other, although it is customary to draw a scheme from top to bottom or left to right. If this is not unified if several specialists work, then a kind of “vinaigrette” may turn out. To avoid this, it is recommended to develop and approve your rules for the arrangement of elements.

I adhere to (and recommend) the following rules:

• The sequence of events and functions is placed from top to bottom (better) or from left to right (if there is not enough space);
• Elements denoting performers are located to the right of the functions;
• Incoming documents at the top left of the functions; direction of the arrow from the documents to the function;
• Outgoing documents on the bottom left of the functions; the direction of the arrow from the function to the documents;
• The “Information” element is located at the bottom right of the function. If there is not enough space, arbitrary positioning is allowed, as close as possible to the function;
• The “Application” element is located at the top right of the functions. (if for this purpose file storages are used that are not reports, then they are displayed in the same way). Link without an arrow.
• Elements "Database" and "Card Index" are arranged arbitrarily;
• The element “Material flow” is located to the left of the accompanying documents with reference to the document by a line without an arrow;
• The element “Cluster”, when used in conjunction with the figure “Document” to designate a document in electronic form, is located to the left of the corresponding document.

For example: The payroll accountant calculates the payroll based on the Brigade Outfit documents provided to him. At the same time, he is guided by the document “Regulations on Wages”, the calculation is made in the “1C: ZIK” program. The result of the calculation is the document "Statement".

Identification of elements on the chart

As is known, a competent approach to the description of business processes provides for their identification, i.e. when each process has its own code name. Accordingly, the individual functions within the process also have their names and identifiers.
Mandatory identification in the diagram are subject to the figures "Document" and "Function".
The document is identified by indicating in the upper left corner of the code of the report or document in accordance with the registry. Documents received from suppliers of goods and services (incoming) are identified only by name.
The function is identified by specifying the sequence number of the function for this group of processes. Those. The function number always starts with the process group code. The issues of identifying groups of processes are beyond the scope of this article; we will consider them separately. Moreover, learning to identify the processes should be before you begin to describe them, otherwise there may be a desire to describe all the activities of the company in one diagram, as they sometimes try to do.
Therefore, now I will only show by example how this can be represented in the diagram. Let's go back to the call processing example. Assume that we assigned the code “04” to the sales department, the code “VK” for the process of processing an incoming contact. Then the scheme will take the following form (identification highlighted in red for clarity). The document code points to the ordinal number of the document in the general register of documents (we will also consider this separately when we get to the survey of the workflow system).

Feedback display

When building models, it is often necessary to perform the process cyclically on a certain condition or the need to display the activities of decision makers. In this case we are talking about feedback.

To display the feedback on the control, the principle of “direct inclusion” is used in the process of the additional control function followed by branching (the “Exclusive OR” logical element is used). For example:

Text description of processes

No matter how hard we try to display the business process on the diagram, it will not be possible to achieve full detail, otherwise you may get bogged down in endless chains of elements and conditions. To avoid this, as well as add to the description of the process information that can not be displayed graphically, the description is complemented by text. To do this, develop a variety of text templates that fill in the description process. The forms of such a template can be different, include separate sections with a description of the inputs and outputs, consumed resources, used software, etc.
In the simplest case, a business process description template might look like this:

Buisness process:	Processing incoming contact	04.VK
Functions of the process:
Name	Description	Number on the scheme
Handling an incoming call	When an incoming call is received, the operator processes the call in accordance with the rules for processing incoming calls. It reveals client's interest, provides information about services.	04.VK.01
Formation of commercial proposals	If there is customer interest, the operator sends the contact to the sales manager. A sales manager prepares a quotation and sends it to the customer by email.	04.VK.02
Process indicators:
Name	/

, , -, , . .