Epc notation description. Comparative analysis of business process modeling notations

“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 the EPC notation as one of the most popular modern methods, which allows you to make a description difficult 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 forced to acquire also the ability for system management, similar to management 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, we need our own specific notation systems to fix formulas and laws. Such system solutions are successfully used by engineers in many fields of activity, chemists, physicists, mathematicians, etc.

The socio-economic system that is the organization is much more diverse than natural Sciences, And uniform form records of “axioms” and management formulas have 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 integral part ARIS methodology, author Wilhelm-August Scheer, developed in the early 1990s. At the end of the previous section, the figure demonstrates general form process of standardizing work using 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”. IN different systems their different graphic symbols may be used.

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 steps we get detailed plan execution of a process that is understandable to its performers. And clearly marked events and results allow you to set control points for everyone significant stages 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 row.

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.

Event-driven process chain.

The purpose of EPC is the planning and description of work flows, lower (operational) level, business processes. The main elements for constructing diagrams are events and functions. Business processes, in an EPC diagram, are depicted as sequences of alternating events and functions.

Application area of ​​EPC

The EPC diagram is a standardized graphical diagram for modeling business processes, applicable for:

• Drawing up models and documenting business processes as is (as is)
• Description of possible improvements existing business processes as it will be (to be)
• Identifying all participants in the process
• Revealing everyone information systems, resources and documents involved in the process

To get a better understanding of the EPC chart, we recommend visiting the links:

• Introduction to EPC

  The link takes you to an introduction to EPC. We recommend visiting the link first.

• Elements and structure of EPC charting

  The link leads to a description where the most important graphic elements of the diagram are presented. The presentation of the elements and their use is perfectly structured, making it very easy for you to navigate.

• Examples of rules for constructing EPC diagrams

  The link leads to a document where examples of diagramming are described. P.S. In this case, we are only interested in the information presented in the fourth chapter from page 86.

Other useful materials:

• The link leads to the collection educational materials according to the ARIS methodology.

A diagram, described in EPC notation, is an ordered combination of events and functions. For each function, the initial and final events, responsible performers, material and documentary flows accompanying it can be determined, and decomposition into lower levels can be carried out.

In Fig. Figure 4.7.1 shows an example of a process diagram in EPC (Event-Driven Process Chain) notation.

On a process diagram in EPC notation, when the button on the diagram panel is pressed, processes are numbered automatically from top to bottom. In this case, changing the position of the process on the diagram changes the order in the Navigator. If the button is not pressed, the process numbers depend on the location of the processes in the Navigator and can be determined by the user using the “Move above” and “Move below” buttons of the system Navigator context menu (see paragraph “Toolbar and Navigator context menu”). If the subprocesses of the current EPC process were created in the Navigator tree, then when the diagram is first opened, they will be arranged by the system from top to bottom.

In EPC notation, branching arrows is done using Operators.

For all diagram elements, you can select another element from the reference book using the “Change object” context menu item. In this case, a process will be created for the function as a link to the selected standard process.

When renaming a subject or object of activity on an EPC diagram, the new name may coincide with the name of an element that already exists in the corresponding directory. In this case, the further operation of the program is similar to the situation that arises when renaming an entity on the Procedure diagram (see section 4.6.2 “Working with a process diagram in the “Procedure” notation).

Table 4.7.1 EPC Notation Diagram Toolbar

Button	Purpose
	Remove the default link type. Opens a window with a list of user-defined default relationship types for selecting the types to be deleted. For more information, see “Creating Links” below.
	Show/hide all types of connections in the diagram. Controls the display of link type names on arrows. For more information, see “Creating Links” below.
	Automatic update of process numbers. If the button is pressed, process numbers will be automatically updated when their location on the diagram relative to other processes changes. If the button is not pressed, the process numbers depend on the location of the processes in the Navigator and can be determined by the user using the “Move above” and “Move below” buttons of the system Navigator context menu (see paragraph “Toolbar and Navigator context menu”). By default, the button is clicked for all new charts.
	Transfer function context from the overlying diagram. The diagram will create all the elements associated with the decomposed function in the overlying diagram. For more information, see “Function Context” below.
	Run the simulation. The simulation statistics window opens. For more details, see paragraph 7.3.

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 tasks. For example, the notation may be convenient for a business process top level and not at all convenient for describing the workflow.

There are different developers of such notations. IN different time Various 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 detailed description the notation that I chose for my projects during 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 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 as in software products, 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 (i.e. programs for drawing diagrams, and not for modeling business processes), then we do not have single base object data. 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 descriptions of business processes that support object databases, then this shortcoming 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 concept: "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 execution new feature: Record the call result, 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 a habit is developed, and the perception is in electronic format 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 itself 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 general rule: No element other than a function is associated with the 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 notations are 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.

Let it be like this in our example: if the client is interested, further work with him is carried out by the sales manager and he sets Commercial offer, which is sent by mail using the MS Outlook mail 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, which must be adhered to 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 closed reporting period(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 e-mail(event 2) will lead to 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: Delivery of goods was carried out (event 1) either by our own transport (Function 1), or 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. In doing so, he is guided by the document “Regulations on wages", the calculation is carried out in the program "1C: ZiK". 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're talking about 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, used software 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 the following: important topics, such as collecting information, highlighting business processes, decomposition, highlighting indicators. We will definitely study these issues in future issues.

September 22, 2010 20:30

"Kites, blind man's buff and tag
Hide and seek, balls, leapfrog, and skipping ropes,
And simple, and simple, and just jump ropes,
Well, simple, simple, just jump ropes!!!”

A. Vratarev

While preparing this article, I discovered an incredible fact: about the EPC notation, so simple and so popular (there are opinions that it is even more popular than BPMN), there are articles on Wikipedia in only 4 languages: English, German, Czech and Uzbek. Moreover, these articles are quite short. Perhaps by the end of the article you and I, dear reader, will understand why.

Let me start with the fact that the EPC notation was developed in the early 1990s. during the development of the ARIS methodology, as, say, its process component. The founding father of the EPC is considered to be Professor Wilhelm-August Scheer, whose name alone inspires awe in the average person (say it out loud and feel inspired). What can we say about the name of the faculty where this respected guy worked: Institut für Wirtschaftsinformatik of the University Universität des Saarlandes.

The purpose of creating the EPC notation was the ability to describe processes so that the functions performed within them have global semantics within the diagram, which means that the execution of a function on EPC diagrams is not necessarily clearly defined, but may be dependent on the state of other nodes of the diagram, sometimes very far away from each other.

The name of the notation stands for Event-driven Process Chain, which clearly indicates that the central element of EPC notation diagrams are events. Events give rise to the performance of certain actions by certain participants. The completion of actions, in turn, generates another event, and so on, until the system reaches a state, the appearance of which within the process is considered the final event.

To clearly demonstrate the capabilities of notation, I will use an everyday example, inspired by a recently completed vacation in warmer climes. A receptionist at a respected hotel, Ivo Petkov, receives a request from one of the guests for an urgent replacement of wash supplies in his room. It is quite clear that his task is to fulfill the client’s request, and in EPC terms, to bring the system from the state “Received a request from the client to change washbasins” to the state “Client’s request has been satisfied.”

We display the two indicated states on the draft diagram and immediately notice how easy our diagram will be to read, because each of its elements has not only its own shape, but also its own color. Thus, events are red hexagons, functions are green rectangles with rounded edges, and performers are depicted as yellow ovals.

So let's go back to the example. Immediately after receiving a request from a client, Ivo must send a request to fulfill the client’s request to the maid, thereby bringing the system into the “Fulfillment request sent” state. The maid, using the supplies available in the warehouse, fulfills Ivo's request. And here, for the first time, parallelization of our process appears: if the maid understands that the necessary washing supplies (say, shower gel) are not currently in stock, then she herself, perhaps unwillingly, transfers the system to the “Fulfillment of the request is impossible” state. from which it naturally follows that Ivo will have to have a not very pleasant conversation with the client, and what state the system will go to depends only on the client’s disposition and his tendency to fight. If the warehouse has all the supplies necessary for the guest, then the maid successfully fulfills the request transferred to her, reports the fulfillment to Ivo, who in turn reports this to the client. And everyone lives happily ever after and dies on the same day.

This simple process is reflected in such a joyfully winking red, green and yellow diagram as in Figure 1.

Rice. 1. EPC diagram of the process of processing a customer request in a hotel

And now, according to tradition, the advantages and disadvantages of notation.

When I first encountered EPC diagrams, I, as I mentioned earlier, was very pleased with how easy they were to read: each block is highlighted in shape and color, it is very easy to see the performers, the required materials, highlight the list of possible system states, the list of those being performed in during the process of functions. This is undoubtedly a huge plus: the customer will not have any difficulties in reading the business process diagram when implementation of EDMS, if it is presented exactly in the EPC notation. However, perhaps the customer will be confused by such a gigantic number of states, because in fact, because of them, the circuit grows greatly. Even in our example: some 4 functions generated as many as 5 states (not counting the initial one). Sometimes you wonder: why point out all of them. Let us tell you why it is necessary after agreeing on the contract general director indicate in a separate block “Agreement agreed”, and after signing - “Agreement signed”, if further the process still remains linear. Frankly speaking, there is no need, unless you are Captain Obvious.

And sometimes it is not clear how to identify the state into which the function will transfer the system. Even while preparing this simple example, I experienced certain difficulties associated precisely with this moment.

The advantage of EPC diagrams is the fact that, like IDEF0 diagrams, you can indicate the input and output data of each function on them, and trace the logic of the movement of input and output data from block to block. In addition, unlike the same IDEF0, it became possible to parallelize the process, directing it along only one of alternative branches(in IDEF0, if we add parallelism in execution, then all parallel functions will be executed simultaneously). It also seemed to me an advantage to be able to specify the performer for each stage (read: function).

But! In IDEF0, the executor is indicated once at each decomposition level, and arrows are drawn on his behalf to all blocks executed by him. In EPC, in order to calculate how many actions an executor performs, we need to go through all action blocks and check whether the executor we need is indicated in it.

This notation seemed very convenient to me from the standpoint of monitoring the execution of the process: each function certainly transfers the system to a new state, from which it follows that after executing each function, the system can be checked whether the transition to the desired state was actually carried out. But the question immediately arose: is this really necessary? For example, I rarely have such a desire =)

So, in general, the EPC notation seems to me inconvenient for describing business processes: too much attention to events, too little attention to actions and especially their grouping based on the performer or the materials used. Yes, she is simple, yes, she is beautiful, and yes, unfortunately, that’s all I can say about her, like probably many other people. =)

And articles about UML and BPMN notations are getting closer and closer.

(4.14 - rated by 21 people)