Every thing is a form of manifestation of infinite diversity.
Kozma Prutkov

Introduction to eEPC notation

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

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

The purpose of this article is not to consider all kinds of notations (I deliberately do not name them), but to focus on detailed description 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 knowing what other notations 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 a very interesting, simple and practical eEPC notation (in translation: an extended description of the event chain of processes). In its literal translation, the main purpose is also revealed: a description of the chain of business processes. The main "trick" of the notation is in its principle of "eventfulness", which we will consider in detail.
What are the advantages of eEPC notation:

1. Firstly, this is not quite a pure notation. Those. if in some notations there is a rigid 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 it provided? Of course, there is a certain "core" around which everything is built, i.e. a set of clear rules by which the scheme is built 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 activity that can confuse the scheme 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 elements of logic. This allows you to build schemes with conditions that are necessary to describe the activity (“if the contract is agreed, then ...., otherwise ...”)
3. The simplicity of the elements allows you to draw diagrams both 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 life, not just gathering dust in a closet. It will take about 2 hours to learn the rules (if the student wishes).

Of course, like everything in this world, it has its drawbacks. But rational use reduces them to a minimum. The main drawback, in my opinion, is the fact that if we use simple tools (ie programs for drawing diagrams, and not for modeling business processes), then we do not have a single database of objects. In addition, it is difficult to control inputs and outputs (it is necessary to control them, that is, to come up with a way of such control, if necessary). But, on the other hand, the use of complex business process modeling tools costs quite impressive amounts, and the project with their use is measured in millions. And so we have a very economical and understandable tool. To be more precise, this shortcoming refers 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, in the literal translation of the abbreviation eEPC lies the concept of eventfulness. This is a very important point on which the whole principle of constructing a circuit is built. So, there are two key concepts: "Event" and "Function". When someone first tries to draw their process in the form of an eEPC diagram, the question often arises, what is the difference between an event and a function? This must be clearly understood, otherwise you will get an unpredictable result. So: an event is a fact of accomplishing something, and it does not have a duration in time, or this time tends to zero (or does not matter). Moreover, the event always causes the need to execute the function, and the execution of the function always ends with the event. Let me explain with an example. The phone rings. The manager picked up the phone. In this case, "The phone rings" is an event. 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 the end of the call will most likely require the execution of 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 the eEPC notation. I think I need to say a few words about the colors used. If you came across the description of processes in other notations, as a rule they were black and white. And this is correct, there should not be an explicit 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 ntation), it has historically developed that the elements have certain colors. Not to say that it was necessary, but a habit is developed, and perception in 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 ARIS, when it made support for the eEPC notation in its product, gave them such 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 made support for it in their business process modeling program. In general, I recommend using colors. The main thing is that the very form of the elements should not be the same (i.e. differ only in color), because in black and white, this can be confusing. There are other rules that allow you to give "slenderness" to the eEPC diagram, we will talk about them.
So, there is an event, there is a function. How are they related?
We see that event1 led to the need to execute a certain function, which ended event2. If applied to the example with a phone call, then it will be like this:

The link 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.

In order to make the scheme more visual, the notation provides a few more standard elements:

• Position(executor). The one who performs this function
• Information. Any information used to perform a function other than documentary information. For instance, phone call, operation instruction etc.
• Document. The "Document" element is designed to display information media (paper or electronic). Those. presentation of information in a certain 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 are no barriers to adding your own elements. The main thing is to fix this in the internal standard so that there is a common understanding of how they look 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 some industry specifics. I added my own set of elements, which I will discuss below.
You still need to figure out how the considered elements should be located. All of these elements must somehow be related to the function. This general rule: no element is associated with the event, except for the function. Those. all these elements must be connected with arrows to the function. As for the arrows and their directions: it is generally accepted that if there is no direction for transmitting information, then just a line is displayed instead of an arrow. If information enters (enters the input), then the direction of the arrow is from the object to the function, if it exits, then vice versa.
A few more words about the location of these elements on the diagram and we can redraw our diagram, specifying the execution of the call processing function. There are no strict requirements for the arrangement of elements, but it is customary to display them in all diagrams in the same way (for the uniformity and harmony of the diagram). To unify the external view of graphic diagrams of business processes, such rules must be fixed in the internal standard and followed. A little later I will give some recommendations about this.
Now let's redraw our diagram:

We see that the operator is processing incoming call, acting in accordance with the rules for processing incoming calls and using the CRM program for this. Neither incoming nor outgoing documents are used.
As I mentioned, one of 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 in our example be like this: if the client is interested, further work with him is carried out by the sales manager and puts commercial proposal, 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 call termination rules, but this is me, by the way, while we simplify it. Here's what happens:

Elements of logic in eEPC notation schemas

The elements of logic are simple, but there are some peculiarities and rules for the scheme to be logical and unambiguously interpreted. The most important rule to follow 100%: logical decisions can only be made when performing functions ii. 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 rang, and a person is sitting thinking whether to pick up the phone or not, theoretically this will already be a function where he makes a decision. But in practice, including from common sense, he violates the rules for processing calls, tk. he is paid a salary to process these calls, and there is nothing to argue here (in general, as shown in the diagram).
In total, 3 elements of logic are distinguished:

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

Here's what some look like:

As you can see, there are two options for graphical representation of logic elements. They are no different, completely different. I brought both of them, because. In practice, both options can be seen in various sources. Which one to use is up to you. I like the first one more.
Now we need to deal with the use of logic elements. First, let's look at the options encountered, then move on to an example. Let's analyze each element separately.
Logical element "AND".

When a function requires multiple events to execute at the same time:

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

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

Example: Completed some work with the customer. Two events were recorded simultaneously: mutual settlements were reconciled (event 1), the act was signed (event 2).

In practice, this is rarely used. As a rule, if many actions are combined in one function.

Connection of elements, if during the execution of several functions, an event occurs:

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

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

Example: A shipment 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.

Logical element "OR".
Connecting elements if one of the events can cause the function to be executed:

Example: Call received by phone (event 1) or call received by phone e-mail(event 2) will lead to the need to handle it.
Connecting elements if one function can fire at least one event:

Example: Prepared and sent the goods invoice for sending to the customer. The invoice could be sent by mail (event 1), by fax (event 2).

Connecting elements when executing multiple functions will trigger an event:

Example: A service was provided (function 1) or a product was sold (function 2), a debt arose from the client (event 1).

Logical element "EXCLUSIVE OR".

Connecting elements when one and only one of the events is needed to execute a function:

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

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

Example: The decision is either made or not.

Connection of elements, if withThe event will occur after one and only one of the functions has been executed.

Example: Goods were delivered (event 1) either by own transport (Function 1) or transport company(function 2)

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

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

Extending Notation with Your Own Elements

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

Data file. Used when a data file is created as a result of an operation, or a file is used to perform an operation.
Database. Used to describe information flows between automated systems.
File cabinet. Used to display a paper filing cabinet or archive.
material flow. Used to indicate the incoming and outgoing material flows, as well as the resources consumed during the execution of the 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 refer to documents generated programmatically using custom 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 an instance of it in the program.

Conventions on the rules for placing shapes 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 turn out. To avoid this, it is recommended to develop and approve your own rules for the arrangement of elements.

• The sequence of events and functions is arranged from top to bottom (better) or from left to right (if there is not enough space);
• Elements denoting performers are located to the right of the functions;
• Incoming documents at the top left of the functions; arrow direction from documents to function;
• 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 arrangement 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). Communication without an arrow.
• Elements "Database" and "Card file" are located arbitrarily;
• The "Material flow" element is located to the left of the documents accompanying it with reference 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: Payroll Calculator calculates wages based on the documents "Brigade Outfit" provided to him. At the same time, he is guided by the document "Regulations on wages”, the calculation is made in the program “1C: ZiK”. The result of the calculation is the document "Vedomosti".

Identifying Elements in a Diagram

As you know, a competent approach to the description of 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.
Figures "Document" and "Function" are subject to mandatory identification in the diagram.
The document is identified by indicating the code of the report or document in the upper left corner in accordance with the register. Documents received from suppliers of goods and services (incoming) are identified only by name.
A function is identified by indicating the ordinal number of the function for a given process group. Those. the function number always starts with the process group code. The issues of identifying process groups are beyond the scope of this article, we will consider them separately. Moreover, you should learn how to identify processes before you begin to describe them, otherwise there may be a desire to describe all the activities of the company in one diagram, as they sometimes try to do.
Therefore, now I will only show with an example how this can be represented in a diagram. Let's go back to the call handling example. Let's assume that we have assigned the code "04" to the sales department, the code "VK" to the process of processing the incoming contact. Then the schema will next view(Identification highlighted in red for clarity). The document code at the same time indicates the serial number of the document in the general register of documents (we will also consider this separately when we get to the survey of the document management system).

Display feedback

When building models, it often becomes necessary to cycle through the process 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 is used additional function control with subsequent branching (using the XOR logic element). For instance:

Text description of processes

No matter how hard we try to display the business process on a diagram, it will not be possible to achieve full detail, otherwise you can get bogged down in endless chains of elements and conditions. To avoid this, as well as to add information to the description of the process that cannot be displayed graphically, the description is supplemented with text accompaniment. For this, various text templates are developed, which are filled in during the description process. The forms of such templates can be different, 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:	Handling an incoming contact	04.VK
Process functions:
Name	Description	Number on the diagram
Incoming call handling	When an incoming call is received, the operator processes the call in accordance with the rules for processing incoming calls. Identifies the interest of the client, provides information about the services	04.VK.01
Formation of a commercial offer	If there is a client's interest, the operator transfers the contact to the sales manager. The sales manager prepares a commercial offer and sends it to the client by e-mail	04.VK.02
Process indicators:
Name	Evaluation/measurement method
Number of failures	database statistics

Such important topics as collecting information, highlighting business processes, decomposition, and highlighting indicators remained outside the scope of this article. We will definitely study these issues in future issues.

Typical tasks for describing business processes

Requirements for the description of business processes of enterprises

The main objective of this analytical study is to answer a number of questions that managers and specialists have at the beginning of a project to model and reorganize the business processes of an enterprise. The following questions are most often asked in this case (in order of importance for the questioners):

• what software to use in the project (“ARIS is better than BPWin”, “ERWin is better than ARIS”, etc.);
• how to model processes using a product?
• how to analyze and identify problems with the product?
• what methodology to use to describe the processes?

Currently on Russian market a sufficiently large number of CASE-systems are presented, many of which allow one way or another to create descriptions (models) of business processes of enterprises. Obviously, the choice of system largely determines the entire further course of the project. A rational choice of the system is possible if the management of the company and its specialists understand several aspects:

• project goals;
• requirements for information characterizing business processes and necessary for analysis and decision-making within a specific project;
• capabilities of CASE-systems for describing processes, taking into account the requirements of clause 2.

It is meaningless to talk about the advantage of this or that system / notation until the type and scope of the project, the main tasks that this project must solve, are determined. In this study, an attempt was made to compare the most popular notations used to describe business processes and two systems that support these notations. It is assumed that this study will serve as the basis for a discussion on the problems of the effective use of CASE-systems for describing and analyzing business processes of enterprises.

The description of business processes is carried out for the purpose of their further analysis and reorganization. The purpose of the reorganization may be to introduce information system, reducing production costs, improving the quality of customer service, creating job and work instructions when implementing ISO-9000 standards, etc. For each such task, there are certain parameters that determine the set of critical knowledge on the business process. From task to task, the requirements for describing business processes may change. In general, a business process model should answer the following questions:

• what procedures (functions, works) must be performed to obtain the desired end result;
• in what order these procedures are performed;
• what control and management mechanisms exist within the considered business process;
• who performs the procedures of the process;
• what input documents/information each process procedure uses;
• what outgoing documents/information the process procedure generates;
• what resources are needed to complete each process procedure;
• what documentation/conditions govern the execution of the procedure;
• what parameters characterize the implementation of procedures and the process as a whole.

The description of the business process is formed using a notation and a tool environment that reflects all of the above aspects. Only in this case, the business process model will be useful for the enterprise, because it can be subjected to analysis and reorganization.

2. Description of the ARIS eEPC notation

The ARIS eEPC notation is deciphered as follows - extended Event Driven Process Chain - an extended notation for describing an event-driven process chain. The notation was developed by specialists from IDS Scheer AG (Germany), in particular by Professor Scheer. The following table lists the main objects used within the notation.

Table 1

In addition to the main objects listed in Table 1, many other objects can be used to construct an eEPC diagram. The use of a large number of different objects connected by different types of links significantly increases the size of the model and makes it difficult to read. To understand the meaning of the eEPC notation, it is enough to consider the main types of objects and relationships used. The following figure shows the simplest eEPC model that describes a fragment of an enterprise business process.

Picture 1.

Figure 1 shows that the links between objects have a certain meaning and reflect the sequence of functions within the process. An arrow connecting Event 1 and Function 1 “activates” or initiates the execution of Function 1. Function 1 “creates” Event 2 followed by a logical AND symbol that “starts” the execution of Functions 2 and 3. The eEPC notation is built on certain semantic description rules:

• each function must be initiated by an event and must end with an event;
• each function cannot enter more than one arrow, which “starts” the execution of the function, and no more than one arrow can exit, describing the completion of the function.

In addition to these rules, there are other important rules formation of models in ARIS. These rules can be studied using the methodological material “ARIS Methods”, which is installed on a computer simultaneously with the demo version of the product.

Figure 2 shows the use of various ARIS objects when creating a business process model.

Figure 2.

Each object in the ARIS Toolset system that supports the ARIS business process description method has a specific set of attributes. The user is prompted to use standard attributes to describe objects or a limited number of so-called. custom attributes.

Figure 1 shows that a business process in the eEPC notation is a sequence of procedures arranged in the order in which they are performed. It should be noted that the actual duration of the procedures in the eEPC cannot be visually reflected. This leads to the fact that when creating models, situations are possible when one performer will be assigned to perform two tasks at the same time. The symbols of logic used in building the model make it possible to reflect the branching and merging of the business process. To obtain information about the actual duration of processes, it is necessary to use other description tools, such as Gantt charts in the MS Project system.

Thus, using the eEPC ARIS notation, it is possible to describe a business process as a flow of sequentially performed work (procedures, functions). An example of models generated using ARIS eEPC are shown in Figures 3-4.

Figure 3

Figure 4

3. Description of the notation IDEF0, IDEF3

The IDEF0 notation was developed on the basis of the SADT structural analysis and design methodology, approved as a US standard and successfully used in many projects related to the description of enterprises. The IDEF3 notation was developed in order to more conveniently describe workflows (Work Flow), for which it is important to reflect the logical sequence of procedures. The IDEF0 and IDEF3 notations use the following entities.

IDEF0 notation

IDEF3 notation

Table 2.

Models can use three types of arrows, shown in the following table 3.

Table 3

The semantics of constructing IDEF0 and IDEF3 models presupposes the observance of clear rules. Detailed information about building models in IDEF0.3 can be found in standards and books (see literature).

The business process formed using the IDEF0 notation is shown in Figure 5. (This process is presented in the ARIS eEPC notation in Figure 3).

Figure 5

Figure 6 shows a business process described using IDEF3 notation. (This process is represented in the ARIS eEPC notation in Figure 4.)

Figure 6

The IDEF3 notation, like the ARIS eEPC notation, uses logic symbols to represent process branching.

4. Comparative analysis of ARIS and IDEF notations

Comparative analysis ARIS and IDEF notations are given in the following table.

Table 4

One of the most important aspects of describing business process models is the reflection on the model of control actions, feedback on the control and management of the procedure. In the ARIS eEPC notation, the control of a procedure can only be reflected by specifying the incoming documents that regulate the execution of the procedure, and the sequence of execution of procedures in time (triggering events). Unlike ARIS, in the IDEF0 notation, each procedure must have at least one control action (the control input is an arrow on top). If, when creating a model in eEPC, only the sequence of procedures is indicated, without caring about the reflection of control documents and information, the resulting models will have low value in terms of analysis and further use. Unfortunately, this error is the most common in practice. A Work Flow model is created, reflecting a simple sequence of procedures and incoming / outgoing documents, while the control (control) actions on functions are not reflected in the model. Real management processes can remain “behind the scenes” by 30-90% (see an example in the following figure).

Figure 7. Disadvantages of business process description in ARIS eEPC.

In Figure 7, Function 4 is a control and serves to check the results of the work performed by functions 2 and 3. But this model does not answer the questions:

• how the control action on functions 2 and 3 is carried out, only the fact is shown that in the course of the process it is possible to return and re-execute functions 2 and 3; information about this feedback can only be disclosed in the form of a description in the attributes of model objects;
• what documents (for example, standards), orders, external conditions (for example, indoor air humidity) regulate the performance of functions.

If you try to reflect all the conditions and constraints that determine the performance of functions, then you will need to describe a large number of events and incoming information (for example, verbal orders from managers), and the model will become complex and difficult to read. (These shortcomings are also inherent in the IDEF3 notation). These shortcomings do not have IDEF0 notation. At the same time, models in IDEF0 do not provide for the use of process execution logic symbols.

Thus, the ARIS eEPC notation is an extension of the rather simple IDEF3 notation. For an adequate description of the management process in the eEPC notation, it is necessary to agree in advance how the documents (information) regulating the execution of process procedures will be reflected in the model.

5. Functionality of ARIS and BPWin products

The functionality of the modeling tools ARIS Toolset and BPWin can be correctly compared only in relation to a certain range of tasks. This study considers the task of forming models (descriptions) of enterprise business processes. Each of the considered systems has its own advantages and disadvantages. Depending on the tasks to be solved, these advantages can be either enhanced or vice versa. The same applies to shortcomings: the lack of a system within the framework of one project may not be a shortcoming within the framework of another. For example, the lack of clear conventions for modeling control actions within eEPC ARIS can lead to the creation of models that do not answer the questions posed, while the IDEF0 notation of the BPWin system allows to solve this problem. On the other hand, the description of a procedure performed by a single employee can be described more adequately using eEPC ARIS than IDEF0 or IDEF3 BPWin. A comparison of the functionality of the systems is given in the following table.

Table 5

Comparing the two systems, it should be immediately noted that ARIS uses an object DBMS to store models, and a new database is created for each project. For the convenience of the user, models (model objects) can be stored in various groups, organized depending on the specifics of the project. It is quite natural that ARIS provides various database administration functions: access control, consolidation, etc. In BPWin, model data is stored in a file, which greatly simplifies the work of creating a model, but on the other hand limits the ability to analyze model objects. Model Mart also provides database administration.

Often one of the disadvantages of BPWin is called by ARIS supporters the limitation on the number of objects in the diagram. However, the experience of real projects shows that for a project whose results can be really used (the criterion is visibility), the number of objects in the ARIS database or BPWin model is 150-300. This means that with 8 objects on one diagram, the total number of diagrams (sheets) in the model will be 20-40. ARIS Toolset databases (like BPWin) containing more than 500 objects are virtually unusable. It should be emphasized that the model is created to highlight and analyze problems, i.e. a detailed description of the most complex, problematic areas of activity is required, and not a total description of all processes. Oddly enough, there is a belief among company directors that a detailed description of processes is valuable in itself and can solve many problems. This is far from true. It is the understanding of what needs to be described and what aspects of the functioning of a real system to reflect at the same time that determines the success of a business process modeling project.

ARIS provides significantly more opportunities for working with individual model objects, but it is precisely because of the excessive number of settings that work on creating a model should be regulated by complex, multi-aspect documentation - the so-called. "Modeling Conventions". The development of these "Agreements" in itself is a complex, expensive and time-consuming task (1-3 months) and qualified specialists. If a project using ARIS starts without a detailed study of such agreements, then the probability of creating business process models that do not answer the questions posed is 80-90%. In turn, BPWin is distinguished by its ease of use and sufficient strict regulation when creating diagrams (IDEF standard and recommendations for its use, IDEF form for creating a diagram, a limited number of required fields, limiting the number of objects in one diagram, etc.) . ARIS, of course, is a “heavier” tool compared to BPWin, but this ultimately results in significant difficulties and high costs for its operation.

6. Conclusions

Recommendations for the use of systems depending on typical tasks

Various situations of application of business process modeling tools and their expert evaluation on a 5-point scale are shown in the following table.

Table 6

Positioning of systems can be carried out in relation to the solution of the problem of modeling business processes (see Figure 8).

Figure 8

Thus, for conducting small-scale (small and medium-sized enterprises, 2-5 people in a group of consultants) and duration (2-3 months) projects, it is rational to use BPWin. For large and / or long-term projects (for example, the implementation of a system of continuous improvement of business processes, ISO, TQM), ARIS is more suitable. In this case preparatory work It may take 1-3 months to create regulatory documentation, but this is a necessary element of subsequent successful work.

The ARIS eEPC notation is deciphered as follows - extended Event Driven Process Chain - an extended notation for describing the chain of an event-driven process. The notation was developed by specialists from IDS Scheer AG (Germany), in particular by Professor Scheer (see )