Every thing is a form of manifestation of infinite diversity.

Kozma Prutkov

Introduction to eEPC notation

Currently, there are many different principles for graphically representing business processes, called notations. Why are there so many of them? This question has been asked by everyone who is faced with the need to describe business processes for decades. 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, a notation may be convenient for a top-level business process but not at all convenient for describing a workflow.

There are 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 encountered a situation where the notation they used could not reflect the necessary subtleties (or was not clear). Sometimes, in the process of evolution, such notations became, as it were, parallel, i.e. look different, but solve the same problems.

The desire to stand out. This is when, for unknown reasons, a new notation suddenly appears, which has nothing outstanding in itself, but for some reason is promoted by its creator as the most perfect know-how. This still happens today.

The purpose of this article is not to consider all kinds of notations (I deliberately do not name their names), but to dwell on a detailed description of the notation that I chose for my projects in the process of a long search for the most optimal option.

If anyone is interested in finding out what other notations there are and what they are used for, I plan to do this in another article, which will be called “Let's talk about notations,” but this is still in the plans.

It's time to start our story about the very interesting, simple and practical eEPC notation (translated: extended description of the event chain of processes). Its literal translation also reveals its main purpose: a description of the chain of business processes. The main “feature” of the notation is its “eventfulness” principle, which we will consider in detail.

What are the advantages of eEPC notation:

1. Firstly, this is not quite a notation in its pure form. Those. if in some notations there is a strict set of elements and rules for their use (otherwise everything will get confused), then the eEPC principle allows you to add your own elements. How is this ensured? Of course, there is a certain “core” around which everything is built, i.e. a set of clear rules by which a diagram is constructed and by which it is then read. In addition, you can add your own element, include the rules for its use in your own corporate standard (to exclude amateur activities that can confuse the diagram and complicate its readability) and that’s it! This is a very important point. In addition, you can set any other restrictions and rules in your corporate standard.
2. eEPC contains logic elements. This allows you to build diagrams with conditions, which is necessary to describe the activity (“if the contract is agreed upon, then ...., otherwise ...”)
3. The simplicity of the elements allows you to draw diagrams both in software and in any other way, even on paper, you will not get confused.
4. eEPC is so easy to learn and understand that it can be used in real activities, and not just collecting dust in the closet. It will take about 2 hours to teach the rules (if the student wishes).

Of course, like everything in this world, it also has its drawbacks. But rational use reduces them to a minimum. The main disadvantage, in my opinion, is the fact that if we use simple tools (that is, 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 and outputs (you need to control them, i.e. come up with a way of such control, if required). But, on the other hand, the use of complex business process modeling tools costs very impressive sums, and a project using them is measured in millions. And so we have a very economical and understandable tool. To be more precise, this drawback relates specifically to the method of description I am considering, i.e. using MS Visio or similar software. If you use specialized systems for describing business processes that support object databases, then this drawback can be avoided. Well, it's time to start...

The main "core" of the eEPC notation

As I already mentioned, the literal translation of the eEPC acronym contains the concept of eventfulness. This is a very important point on which the entire principle of constructing the circuit is based. 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? You need to clearly understand this, otherwise you will get an unpredictable result. So: an event is a fact of something happening, and it does not have a 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 for a telephone conversation. In this case, “The phone rings” is an event. Telephone conversation is a function. The conversation is over (hung up) - another event. Thus, an event chain is observed: Call - conversation - end of the call. And ending the call will probably require performing a new function: recording the result of the call, etc.

Let's try to draw it. First, you need to figure out how the Event and Function elements are displayed.

These two simple elements form the basis of the rules for describing business processes in eEPC notation. I think I should say a few words about the colors used. If you came across descriptions of processes in other notations, as a rule they were black and white. And this is correct, there should not be an obvious dependence of the content on the color, because the diagram can be drawn with a pencil on paper, printed on a black and white printer, etc. In this case (in the eEPC notation), it has historically developed that the elements have certain colors. Not to say that this is necessary, but the habit is developed, and the perception in electronic form is better - you can immediately see what is what. These colors can be considered as a recommendation. Why are they like this? I’m not sure exactly, but it seems to me that because the ARIS company, when they made support for eEPC notation in their product, gave them these colors, they “took root.” By the way, sometimes this notation is also called “ARIS”, “ARIS EPC”, which is not entirely correct, because ARIS did not invent this notation, but supported it in its business process modeling program. In general, I recommend using colors. The main thing is that the shape of the elements themselves should not be the same (i.e. differ only in color), because in black and white this can cause confusion. There are other rules that make it possible to make the eEPC diagram “harmonious”; we will talk about them.

So, there is an event, there is a function. How are they connected?

We see that event1 led to the need to perform a certain function, which ended with event2. If, for example, with a phone call, it would be like this:

The connection event - function - event is usually displayed 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 diagram more visual, the notation provides several more standard elements:

• Position (performer). The one who performs this function
• Information. Any information used to perform a function other than documentary information. For example, a telephone call, instructions for performing an operation, etc.
• Document. The “Document” element is intended to display information media (paper or electronic). Those. presentation of information in a specific structure.
• Program (application). The 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 is no barrier to adding your own elements. The main thing is to fix this in an internal standard so that there is a common understanding of what they look like and why they are used. Such an extension does not violate the requirements if the event-function-event connection is not violated, and is intended only to improve the perception of information or adapt the description rules to any industry specifics. I added my own set of elements, which I will discuss below.

It is also necessary to find out how the considered elements should be located. All of these elements must be related to the function in one way or another. This is a general rule: no element other than a function is associated with an event. Those. all these elements must be connected by arrows to the function. As for the arrows and their directions: it is generally accepted that if there is no direction for the transmission of information, then instead of an arrow, just a line is displayed. If information enters (enters the input), then the direction of the arrow is from the object to the function; if it comes out, then vice versa.

A few more words about the location of these elements on the diagram and we can redraw our diagram, clarifying the execution of the call processing function. There are no strict requirements for the arrangement of elements, but it is customary to display them equally on all diagrams (for uniformity and harmony of the diagram). To unify the external appearance of graphical diagrams of business processes, such rules must be enshrined in an internal standard and followed. A little later I will give some recommendations on this matter. Now let's redraw our diagram:

We see that the operator processes 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 notation is its elements of logic. At the same time, this is one of the most difficult moments to understand. Therefore, first I will give an example, and then we will separately deal with the elements of logic.

In our example, let it be like this: if the client is interested, the sales manager carries out further work with him and puts forward a commercial offer, which he sends 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 nice to use the rules for ending a call, but that’s just me, by the way, let’s simplify it for now. Here's what happens:

Logic elements in eEPC notation diagrams

The elements of logic are simple, but there are specific features and rules to ensure that the diagram is logical and unambiguously interpreted. The most important rule that must be followed 100%: logical decisions can only be made when executing a function. Those. after some event there can be no branching. Why? Because in this case it contradicts the very concept of an event - it is simple and instantaneous, without execution time. For example, if the phone rings and a person sits thinking about whether to pick up the phone or not, theoretically this will already be a function where he makes a decision. But in practice, including common sense, he violates the rules for processing calls, because... he is paid a salary to process these calls, and there is nothing to discuss here (in general, as shown in the diagram).

In total, there are 3 different elements of logic:

• I. When two or more events occur simultaneously;
• OR. When one or more events can happen, but at least one must happen;
• EXCLUSIVE OR. Either one or the other. Those. two options are impossible at the same time.

As you can see, there are two options for graphical representation of logic elements. They are no different, completely alternative. I brought them both because... in practice, both options can be seen in various sources. Which one to use is up to you. I like the first one better.

Now you need to understand the use of logic elements. First, let's look at the options we encounter, then move on to an example. Let's look at each element separately.

Logic element "AND". When a function requires multiple events to occur simultaneously:

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

Connecting elements if, when executing a function, several events occur:

Example: Some work has been completed with a customer. Two events were recorded at the same time: mutual settlements were reconciled (event 1), the act was signed (event 2). In practice, this application does not occur often. As a rule, if many actions are combined in one function

Connecting elements, if, when performing several functions, the event occurs:

Example: The storekeeper collected the order (function 1), the operator issued the documents (function 2), the goods are ready for shipment (event).

Connecting elements if the occurrence of one event leads to the execution of several functions:

Example: A shipment of goods has arrived (event). At the same time, the shipment of goods previously ordered by customers and the placement of the remaining goods in the warehouse begin.

Logic element "OR".

Connecting elements if one of the events can cause the function to be executed:

Example: An application was received by telephone (event 1) or an application was received by email (event 2) will result in the need to process it.

Connecting elements if one function can raise at least one event:

Example: An invoice for goods has been prepared and sent to be sent to the client. The invoice could be sent by mail (event 1), by fax (event 2).

Logical element "EXCLUSIVE OR".

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

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

Connecting elements if, as a result of executing the function, at most one of the following events occurs:

Example: The decision is either made or not.

Connecting elements if the event occurs after one and only one of the functions has been executed.

Example: The goods were delivered (event 1) either by our own transport (Function 1) or by a transport company (function 2)

Correct application of logic elements requires some practice. But it's not difficult. It should be noted that not all combinations considered 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 you have any difficulties, write to me, I will try to help.

Extending the notation with your own elements

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

Data file. Used if an operation results in a data file being created, or a file is used to perform an operation.

Database. Used to describe information flows between automated systems.

Card index. 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 execution of a process. The material flow is displayed to the left of the accompanying documents.

Information cluster. Used to denote structured information (entity representation). The diagram can be used to indicate documents generated programmatically when using user applications. In this case, the Cluster element is located to the left of the corresponding document. Those. indicates that the user not only created a paper document, but also created a copy of it in the program.

Agreements on the rules for placing figures on a diagram

The eEPC notation itself does not impose strict requirements on the arrangement of elements relative to each other, although it is customary to draw a diagram from top to bottom or from left to right. If this is not unified in the case of the work of several specialists, then a kind of “vinaigrette” may result. To avoid this, it is recommended to develop and approve your own rules for the arrangement of elements. I adhere to (and recommend) the following rules:

• The sequence of events and functions is arranged from top to bottom (better) or left to right (if there is not enough space);
• Elements indicating performers are located to the right of the functions;
• Incoming documents are at the top left of the functions; arrow direction from documents to functions;
• Outgoing documents at the bottom left of the functions; arrow direction from function to documents;
• The Information element is located at the bottom right of the function. If there is not enough space, an arbitrary location is allowed, as close as possible to the function;
• The Application element is located at the top right of the functions. (if file storages that are not reports are used for this, they are displayed similarly). Link without arrow.
• The “Database” and “Card Index” elements are arranged randomly;
• The “Material Flow” element is located to the left of the accompanying documents and is linked to the document by a line without an arrow;
• The “Cluster” element, when used in combination with the “Document” figure to designate a document in electronic form, is located to the left of the corresponding document.

For example: The payroll clerk calculates wages based on the “Brigade Order” documents provided to him. At the same time, he is guided by the document “Salary Regulations”, the calculation is made in the 1C: ZiK program. The result of the calculation is the document “Statement”.

Identifying Elements in a Diagram

As you know, a competent approach to describing business processes involves their identification, i.e. when each process has its own code name. Accordingly, individual functions within a process also have their own names and identifiers.

The figures “Document” and “Function” are required to be identified on the diagram.

The document is identified by indicating in the upper left corner 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.

A function is identified by specifying the function sequence number for a given process group. Those. The function number always begins with the process group code. Issues of identifying process groups are beyond the scope of this article; we will consider them separately. Moreover, you should learn to identify processes before you begin to describe them, otherwise there may be a desire to describe all the company’s activities on one diagram, as is sometimes attempted.

Therefore, now I will only show with an example how this can be represented in the diagram. Let's return to the call processing example. Let’s assume that we assigned the code “04” to the sales department, and the code “VK” to the process of processing incoming contacts. Then the diagram will take the following form (identification is highlighted in red for clarity). The document code indicates the serial number of the document in the general register of documents (we will also consider this separately when we get to examining the document flow system).

Feedback display

When building models, there is often a need to perform a process cyclically according to some condition or the need to display the activities of decision makers. In this case we are talking about feedback. To display control feedback, the principle of “direct inclusion” in the process of an additional control function with subsequent branching is used (the “Exclusive OR” logical element is used). For example:

Text description of processes

No matter how hard we try to display a business process on a diagram, we will not be able to achieve complete detail, otherwise we can get bogged down in endless chains of elements and conditions. To avoid this, as well as to add information to the process description that cannot be displayed graphically, the description is supplemented with text accompaniment. For this purpose, various text templates are developed, which are filled in during the description process. The forms of such templates can be different and include separate sections describing inputs and outputs, resources consumed, software used, etc.

In the simplest case, a business process description template might look like this:

Buisness process:	Processing an incoming contact	04.VK
Process functions:
Name	Description	Number on the diagram
Processing an incoming call	When an incoming call arrives, the operator processes the call in accordance with the rules for processing incoming calls. Reveals client interest and provides information about services	04.VK.01
Formation of a commercial offer	If the client is interested, the operator transfers the contact to the sales manager. The sales manager prepares a commercial proposal and sends it to the client by email	04.VK.02
Process indicators:
Name	Method of evaluation/measurement
Number of failures	Database statistics

Beyond the scope of this article are such important topics as collecting information, identifying business processes, decomposition, and identifying indicators. We will definitely study these issues in future issues.

Sheet music for business

The article was published in the magazine "Management News" in January 2012.

Music has tied us
Has become our secret

All epigraphs for this article are taken from the song “Music Has Connected Us” by the band Mirage.

In classical music, the musician is an instrument in the hands of the composer and plays according to the notes. In popular music, musicians most often write the music themselves, and the art of improvisation does not involve notes at all. True, famous improvisations that have become classic are then translated into sheet music, and they have a new life: the arrangement changes, a new sound and mood are added.

Likewise, a business that has grown as a skillful improvisation to move to a new level requires putting facts on paper to analyze what is happening and make decisions for improvement.

Recently, more and more often you can find descriptions of business processes (BP), made, as they say, "on your own". It was this circumstance that prompted the writing of the article. Unfortunately, most of these documents that I happened to see were of little use for serious business. This is not to say that they were fundamentally incorrect, but a number of omissions spoiled them so much that I wanted to immediately forget about their existence. What kind of omissions these are, and how to deal with them, we will figure out in the course of this article, gradually approaching the essence of the issue. We will try to avoid a large number of technical details, but we cannot completely avoid them, because... the subject of the conversation requires it.

Is it really me
I can't find the answer to everything

This article is addressed to those who want to save on describing business processes by entrusting the preparation of the document to internal specialists. After all, a description of business processes is not mandatory for a company, and everything works without it. But in any stable company there is a mechanism for transferring authority, it is called “job descriptions”. If the business is complex and the position is key, then it is useful to draw job descriptions to make it easier to understand. Accumulating business processes in a general description is necessary in order to make the business more transparent, especially for its sale.

The document “Description of BP” becomes especially relevant as soon as there is a need for reorganization (or, as it is now fashionable to say, reengineering) of the company. In this case, the document is used to:

1. On it, as on a battle map, mark the essence of the planned transformations,
2. Bring the transformation participant up to date,
3. Use a pen and not your fingers to assign tasks to department heads and external specialists.

There are advantages to preparing the document yourself:

• It works out cheaper;
• Internal specialist, better versed in the practices of his native business.

A third-party consultant will first have to study the terminology and key features of the subject, as well as industry standards. This takes time. True, he knows better how and what needs to be described. There are certain rules, generally accepted notations and special software. An example of such notation can be seen in Fig. 1 and fig. 2.

IDEF0 notation

Fig.1.

An example of describing a power supply using IDEF0

Fig.2.

Don't lecture us

Don't lecture me
Mom, this is useless

Do we really need this? - The director will ask, reasonably assuming that compliance with all standards will significantly increase the cost of the result. One of the directors I know reasoned like this: “Inviting a third-party specialist is an expensive business, but our tasks are simple - why do we need all these notations. And the specialist, sometimes he draws something with his hooks, nothing is clear, it’s not convenient to admit, so he’s still behind This is what you have to pay for."

I agree, if the tasks are simple, why bother? And if they are complex, then they need to be simplified and not complicated with fancy notation. After all, there are no obvious advantages from using beautiful hooks. If there are no obvious ones, this does not mean that there are none. These rules and notations were not invented so that the consultant would not get bored... Anyone who is involved in business knows well that not everything useful is obvious. Well, let's look for the hidden positive and to do this, let's look into the history of the issue.

The power supply description market has existed for a very long time. However, over the past decade and a half, it has made a rapid breakthrough, thanks to the emergence of a new industry - automation of accounting and management in enterprises. The growing market gave newcomers who came up with new notations a chance to break through and stake out their place. For example, in the Russian market over the past few years, massive advertising and information campaigns on the part of IDS Scheer (the main supplier of ARIS - see Fig. 3) have created a layer of specialists in describing automated processes.

Using ARIS notation requires great detail of business processes.

Fig.3.

The implementation of systems such as ERP (resource management), CRM (customer relations), MRP (production planning) inevitably leads to changes in processes, and if this is not planned in advance, the result may be worse than desired. In addition, automation is working with information, which means it is useful to know what information is generated by whom, where it comes from and where it goes. But special notations for introducing automation have never taken root here and are rarely used.

The description of business processes in Russia is a relatively recent trend, despite the impressive number of GOSTs in this area (3.1109, 34, ISO, etc.). Now, with the quality of description of their own business processes, things are best in banks. The fact is that, unlike other commercial structures, a bank is an infrastructure organization and therefore it is within the strict framework of regulations defined by law. The bank operates on the principle of day management. As a result, even a simplified description of the Bank’s business processes (in Russian without the use of notations) turns out to be more detailed, because rests on a foundation built on volumes of regulations defining standards, terminology, roles and rules. These standards are the generally accepted language in the banking environment and the description of business processes will be easy to read for any specialist.

In commercial structures, the description of business processes requires a preliminary dictionary of terms. And when starting to prepare and coordinate it, many are faced with the fact that the same things are called differently in different departments. Going into detail, it turns out that different names actually carry different shades of meaning. Coordination of terminology is one of the most labor-intensive processes in describing a business process. It is important to get this process up and running. I can take on most of the work from the company’s own divisions, because the need to regulate its activities leads to greater organization of processes and procedures.

When description is required for automation, the reverse sequence is also possible. Changing business processes is done in parallel with the implementation of the information system, and the description of new business processes is carried out “hot on the heels” and is integral with the system documentation.

Staff

I forgot everything
We have been taught for so many years

Oddly enough, the choice of notation and the correctness of the description are more critical for small and medium-sized businesses. Large companies usually have greater process flexibility due to the interchangeability of employees. For a small business, where the execution of critical points comes down to 2-3 decision-makers, an incorrect indication of the process route can give rise to a fundamentally incorrect concept of the solution. Since the result is critical, then the tool is important, but how to choose it?

Each notation is adapted for a specific range of tasks. We will consider the most pressing task to be changing business processes within the framework of a management automation project. For these purposes, there is a good set of tools that are quite widespread: these are Russian GOSTs, and the same ARIS, and IDEF, as well as EPC (Fig. 4 and Fig. 5).

EPC notation

Fig.4.

Description of a business process using EPC

Fig.5.

If a book is written in a certain language, then the most important thing is to have a reader who knows this language and can read it. Based on this, the most common standard for describing BP is the best.

When choosing a notation, another important criterion is the ability to use a familiar software tool. For example, Microsoft Business Solution in 2002 offered On-Target notation for the Navision information system, accompanied by a special software solution. This is the very case when it is better to choose something else - not only does no one know the On-Target notation, but also the software environment will require time to study it. I would call a positive example the use of the IDEF notation and the Visio program, which is very widespread and has the necessary set of tools for drawing IDEF diagrams (Fig. 6).

IDEF business processes done in Visio

Fig.6.

Of course, the description of the power supply can be done simply in words, as well as using various symbols (of your own invention) since it seems understandable. Having such a description is better than nothing, but maintaining standards is still useful.

Fullness and depth of sound

I don’t know what draws me here

1. will take a long time
2. Some details will change during the creation of the document.

A common mistake is trying to fit descriptions to fit the notation. For example, trying to describe procedures in ARIS format, i.e. achieve apparent redundancy in description when it is not required.

But a more common mistake is insufficient document depth. As a result, the result is a formal document that is not suitable for work, because all important details have to be clarified in the process.

A melody is a sequence of sounds, not notes.

Forget about this day
Nobody needs an argument

This means that the power supply can be described simply in words, without any notations. Of course, the notation is more correct, but that’s not what’s important. Description BP is not a final product, but only a tool for new achievements. This means that it must be adapted for further active use. The main problem with most do-it-yourself documents is that they are inconvenient to use. For example, one such document consisted of a description of what was done in Microsoft Word and drawings made in PowerPoint; jumping from program to program was terribly inconvenient; it took a lot of time to simply bring it all into one document. It turns out that the document must have the following properties:

1. Have a clear order and grouping of sections, i.e. be conceptually holistic (usually this means that if you have a concept, then you have learned to use it);
2. Clearly identify business units and give them clear names and numbering;
3. Clearly highlight business processes and also give them a clear name and numbering;
4. Elements should be numbered in such a way as to avoid confusion (this makes the search much easier): for example, Department No. 1 should have the number Dept.001 in the document, and Business Process No. 1 should have the number BP001;
5. The document must have a contents section with a tree structure;
6. A company is an integral organism and no business process hangs in the air - it is always connected with other business units, business units and departments. To reflect these connections, you can use hyperlinks - this will make it easier to find information and move from one object to another.

For this purpose, you can use any text editor that supports hyperlinks.

Some people believe that in a professional music group it is enough to have one or two real musicians. No sincere music connoisseur will agree with this. These conversations arise due to the lack of professionals and creative individuals.

Businesses have similar difficulties. There are few good specialists who know their company from head to toe, and they are very busy. By analyzing business processes on our own, we save money and perhaps save time. But it is not always possible to select the best ones to describe the power supply. You can entrust the routine to performers of a lower rank, but then there is a risk of delaying the process. Ignorance of the principles of constructing such documents carries the risk of ineffectiveness (the result is unusable, it’s the same as its absence).

The best quality and speed in document preparation is possible in an alliance with a key specialist and an experienced consultant. The result will be an agreed language for describing business processes (i.e., the terminology of the company’s business) and the description itself in detail sufficient to solve further problems.

I repeat in response to all persuasion
They won't separate us, no

We remind you that all epigraphs for this article are taken from the song “Music Connected Us” by the group Mirage

A third-party consultant will write a document in a notation language that is understandable to other consultants and often more suitable for the case. Don't you understand all these hooks? But these notations are not at all complicated, maybe it’s worth learning them?

The ARIS EPC notation, used to model business processes in the ARIS toolkit, is a sequence of events and functions that reflect the logic of performing interrelated actions aimed at achieving a certain result.

The ARIS EPC model is intended to describe the algorithm for executing a business process in the form of a sequence of event-driven functions. The ARIS EPC model focuses on the sequence of functions, and to describe the conditions in the business process model, events and rules are used, which can describe complex algorithms for executing a business process.

Functions in the ARIS EPC model are triggered by events, for example, “Invoice received for approval,” and end with events, for example, “Invoice is approved” or “Invoice is not approved.” If, as a result of executing a function, there is only one option for further execution of the business process, i.e. As a result, only one event is generated, after which the next function comes; the event between these functions may not be drawn.

A business process model of ARIS EPC notation necessarily begins and ends with one or more events or interfaces to other business process models. To reflect interfaces, special objects “Process Interface” are used - the object type “Function”.

When creating an ARIS EPC model, situations may arise where the same document is an outgoing document for one function and an incoming document for the next. In these cases, to improve the ergonomics of the model, it is permissible to use one document representation with one incoming connection (from the function in which it is created or adjusted) and one outgoing connection (to the function in which it is used).

The EPC model cannot be disconnected, i.e. placing on the model one object that is not connected with the others is an error.

The location of documents relative to functions is usually the following: on the top left are incoming documents, on the bottom left are outgoing documents, performers are usually located to the right of the function.

The following information is indicated on the ARIS EPC model:

• functions performed
• information resources of functions (incoming/outgoing documents)
• events
• process interfaces
• logical operators
• performers (positions, business roles)
• Information Systems

Event naming rules in ARIS EPC

The event name must contain a noun and a verbal description of the state change. Example: “Transaction completed.”

Function naming rules in ARIS EPC

To name a function, you must use its real name. The name must consist of two parts - a verbal noun describing the function performed, and a noun indicating the object on which it is performed. The name of the function consists of the short name of the object starting with a capital letter, for example, “Search for customer contacts.”

Rules for naming roles/positions in ARIS EPC

The name of the business role (Person Type) must correspond to the essence of the responsibilities assigned to the performer. As a rule, the title contains the phrase “Responsible for...”. Job titles (Position) are written in accordance with the staffing table.

Document Naming Rules

The object corresponds to a document (Information Carrier) (in paper and/or electronic form). To name documents (regardless of the symbol used), you must use their real name.

Rules for naming information systems in ARIS EPC

To name information systems (Application system type), you should use their established names.

Process interface naming rules

The Process interface shows a link to an adjacent process. The name of the process interface corresponds to the name of the model that describes the adjacent part of the business process. The interface can be used to reference business process models that are not part of the business process being described.

“The more clearly the information is conveyed, the faster and more accurately it will be perceived by the person to whom it is addressed.” This truth has long been actively used by marketers, educators and researchers. Managers were not left out either. This article discusses EPC notation as one of the most popular modern methods, which allows you to make the description of complex work not only convenient, but also much more accurate and understandable to all participants in the project or process.

History of the emergence of graphic modeling standards

Now, when the pace of development of all processes in society is growing and systems are becoming more complex, management as the art of influencing people is also forced to acquire the ability to manage systems, similar to the management of engineering systems. In the early 90s of the last century, the word “ reengineering Michael Hammer and James Champy first introduced this definition in their book Reengineering the Corporation." And after it, the concept of “engineering” of business appeared. If the first is the redesign of business processes, then the second is the design of an effective organizational system from scratch.

This trend indicates that the search for methods of describing and even constructing an organization as a system has been going on for a long time and quite successfully. If we consider management not only as an art, but also as a science, then it, like any other scientific discipline, needs its own specific notation systems for fixing formulas and laws. Such system solutions are successfully used by engineers in many fields of activity, chemists, physicists, mathematicians, etc.

The socio-economic system, which is the organization, is much more diverse than the natural sciences, and a single form of recording “axioms” and management formulas has not yet been found. But the path has been paved. And it begins with the well-known flowcharts, which allow us to describe the procedure for achieving a given result. But, unfortunately, the visual capabilities of a flowchart are very limited, and it does not allow you to display the entire variety of elements of the business management process.

Today, quite a lot of options for flowcharts with which you can depict the interaction of people and systems in the process of creative activity have been developed. They are combined into sets of tools in order to more fully describe all aspects of the enterprise's activities. Such tools are called modeling methodologies. The most complete and well-known are three of them:

• ARIS (Architecture of Integrated Information Systems);
• SADT (Structured Analysis and Design Technique);
• UML (Unified Modeling Language).

(click to enlarge)

To fully and comprehensively describe the activities of an enterprise, it is necessary to use different graphic standards, which are included in the methodology and are called notations. But to solve narrow problems, it is enough to choose the notation that was invented for the corresponding description. Above is one of the graphical types of notation that will be discussed in this article.

Features of EPC notation

The EPC (Event-driven Process Chain) modeling notation is focused on building interaction algorithms in the process of performing a specific job. Its main elements are:

• events that start or terminate work;
• actions (work) that transfer the system from one state to another;
• performers of the work;
• resources and work results (inputs and outputs).

This notation is an integral part of the ARIS methodology, authored by Wilhelm-August Scheer, developed in the early 1990s. At the end of the previous section, the figure shows an overview of the process of standardizing work using the EPC notation. Let's consider the features of describing an organization's business processes using this notation. Even without delving into the essence of the diagram, the alternation of red and green elements immediately catches the eye - this is the chain of events and processes inherent in the name of the notation. The composition of the model elements is determined by four main positions.

It is likely that in the course of describing the process model we are going to use an information system. Then we can display it using special three-level sets of elements ( orange color).

1. IS – information system.
2. IC module.
3. IS function.

Databases traditionally have their own image - in the form of a cylinder. Although using them without an information system and a system without a database seems impossible to me today. To display the logic of transitions between functions, logical operators are used, which help to specify the conditions for the execution of parallel work or the occurrence of events. They show options for merging or branching both functions and events. There are only three logical operators: “AND”, “OR” and “Exclusive OR”. Different systems may use different graphical symbols.

Notation and use of logical operators in EPC notation

Algorithm for constructing an EPC chart

As we can see, the undoubted advantage of this notation is the intuitive set of elements and rules for constructing diagrams. To create process diagrams, it is recommended to use special process modeling programs. For EPC, this is primarily the ARIS system. But it is expensive and quite complex, and is not used for small periodic projects to streamline the activities of departments.

The simplicity and popularity of the notation stimulated the creation of other tools for drawing business processes, including in the EPC notation. The simplest of them is Visio - one of the templates in it is called “EPC Diagram”. The most useful tool for me is the Business Studio system. In it, in addition to the ability to draw a process, you can automatically generate a document (Process Regulations) and work instructions for its participants, which significantly simplifies the routine part of the process of developing performance standards.

The colors and designations of secondary elements in different programs may differ slightly, but the general rules are always followed. The example of EPC notation presented in the first section of the article reflects a simplified algorithm for working with this notation. Let's take it step by step.

After completing all the steps, we receive a detailed plan for executing the process, understandable to its performers. And clearly defined events and results allow you to set control points for all significant stages of the process. And I again refer you to the example of the visual model posted at the beginning of the article.

Advantages and disadvantages of EPC notation

In addition to simplicity and accessibility, using EPC has the following advantages.

1. Allows you to display all significant organizational elements on one diagram (as opposed to a simple flowchart).
2. It can be used at different levels of the model - to describe both global processes and make detailed instructions due to the fact that each functional block can become a subprocess.
3. It is easy to do complex parallelization of a process, since you can enter any number of events in one series.

At the same time, this notation did not become the one and only due to the following shortcomings.

1. The need to come up with events for every even minor action greatly complicates the scheme.
2. Organizational breakdowns are likely due to inconvenient tracking of assignments.
3. High-quality registration of inputs and outputs leads to an overload of the circuit with rectangles and arrows, which begin to intersect and thereby further complicate the perception of the circuit.
4. When parallelizing work, it is very difficult to reflect the executors. If one person performs a group of functions, the picture becomes more complicated with arrows. If there are several performers or we don’t want to draw long arrows, we have to duplicate the “ovals” with the performers. All this can very soon lead to complete confusion in the diagram.

From my own experience, I can say that local operating procedures drawn in this notation are quite convenient for both the developer and the user of the instructions. The notation is also suitable for project managers, since it allows them to visually plan the distribution of work in a project in a language that is intuitive for different project participants. And for developing a more complex multi-level model of enterprise activity, other modeling notations are more suitable, which we will consider in the following articles.

1. An EPC function diagram must begin with at least one start event (the start event may follow the process interface) and end with at least one end event (the end event may precede the process interface).

2. Events and functions must alternate during the process. Decisions about the further course of the process are made by functions.

3. The recommended number of functions on the diagram is no more than 20. If the number of functions on the diagram significantly exceeds 20, then there is a possibility that the processes at the top level are incorrectly identified and the model needs to be adjusted.

4. Events and functions must contain strictly one incoming and one outgoing connection, reflecting the progress of the process.

5. Events and statements surrounding the function in the above diagram ( Fig.16), should be the initial/resulting events and statements in the function decomposition diagram ( Fig.17).

Figure 16. Process diagram where Function 1 occurs	Figure 17. Decomposition diagram of Function 1

6. The diagram should not contain objects without a single connection.

7. Each merge operator must have at least two incoming connections and only one outgoing connection, a branch operator must have only one incoming connection and at least two outgoing ones. Operators cannot have multiple incoming and outgoing connections at the same time.

8. If an operator has an incoming connection from the “event” element, then it must have an outgoing connection to the “function” element and vice versa.

9. A single event must not be followed by an "OR" or "XOR" operator.

10. Operators can combine or branch only functions or only events. Simultaneous merging/branching of a function and an event is not possible.

11. The operator that branches branches and the operator that merges these branches must match. It is also possible to use the branch operator “AND” and the union operator “OR”.

Examples of acceptable situations ( Fig.18, Fig.19, Fig.20, Fig.21):

Figure 18	Figure 19	Figure 20	Figure 21

An example of an unacceptable situation ( Fig.22).