Description of the ARIS eEPC notation. Modeling business processes using ARIS (express and cloud)

business model notation

ARIS eEPC notation

The ARIS eEPC notation stands for the following: 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 Professor Scheer. In table 1 shows the main objects used within the notation.

Table 1. eEPC notation objects

Name	Description	Graphical representation
	The “Function” object is used to describe the functions (procedures, works) performed by departments/employees of the enterprise
	The “Event” object is used to describe the real states of the system that influence and control the execution of functions
Organizational unit	An object reflecting various organizational units of an enterprise (for example, management or department)
Document	An object that represents real-life storage media, such as a paper document
Application system	The object reflects the real application system used within the function execution technology
Information cluster	An object characterizes data as a set of entities and relationships between them. Used to create data models
Arrow of connection between objects	An object describes the type of relationship between other objects, such as the activation of a function by some event
Logical "AND"
Logical "OR"	A logical operator that defines relationships between events and functions within a process. Allows you to describe process branching
Logical exclusive "OR"	A logical operator that defines relationships between events and functions within a process. Allows you to describe process branching

In addition to those indicated in the table. 1 main objects, many other objects can be used when constructing an eEPC diagram. The use of a large number of different objects connected by different types of connections 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. In Fig. Figure 1 presents the simplest eEPC model, which describes a fragment of an enterprise’s business process.

Rice. 1.

In Fig. 1 shows that the connections between objects have a certain meaning and reflect the sequence of functions within the process. The 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 "triggers" the execution of Functions 2 and 3. The eEPC notation is built on certain semantic description rules:

1. Every function must be initiated by an event and must end with an event;
2. each function cannot include more than one arrow that “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 others important rules formation of models in ARIS. These rules can be studied using the methodological material “ARIS Methods”, which is installed on the computer simultaneously with the demo version of the product.

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

Rice. 2.

Each object in the ARIS Toolset system, which supports the ARIS method of describing business processes, has a specific set of attributes. The user is asked to use standard attributes to describe objects or limited quantity custom attributes.

From Fig. 1 shows that a business process in eEPC notation is a sequence of procedures arranged in the order of their execution. It should be noted that the actual duration of procedures in eEPC cannot be reflected visually. This leads to the fact that when creating models, situations are possible when one performer will be assigned to simultaneously perform two tasks. The logic symbols used to build the model allow you to reflect the branching and merging of a business process. To obtain information about the actual duration of processes, it is necessary to use other description tools, for example, Gantt charts in the Microsoft Project system.

Thus, using the eEPC ARIS notation, you can describe a business process in the form of a flow of sequentially performed work (procedures, functions). Examples of models generated using ARIS eEPC are shown in Fig. 3 and 4.

Rice. 3.

Rice. 4. Description of the process of analysis and approval of the client’s application

V. Repin, S. Maklakov

Analyzing the activities of enterprises and reorganizing business processes is an extremely complex task that requires methodological and instrumental support. Recently, CASE tools BPwin (Computer Associates) and ARIS Toolset (ARIS) have become increasingly popular among business analysts. This article provides a brief comparative analysis these funds and recommendations for their use.

Introduction. Typical tasks descriptions of business processes

At the early stages of projects, the purpose of which is to reorganize business processes and implement information systems, managers and specialists most often have the following questions:

what results in terms of improving the organization’s activities can be achieved using technologies for describing and reorganizing business processes;
which software use in a project (“Is ARIS better than BPwin?”, “Is ERwin better than ARIS?”, etc.);
how to model processes using product “X”;
how to analyze and identify problems using product “X”;
what methodology to use to describe processes;
what to do next with the resulting business process models.

Currently on Russian market There are quite a large number of CASE systems, many of which allow one way or another to create descriptions (models) of enterprise business processes. At the same time, there are systems that are primarily focused on creating process models and are inconvenient or not designed at all for creating data models and configuring a DBMS. Obviously, the choice of system is determined by the goals of the project and significantly affects its entire further course. A rational choice of system is possible if the company’s management 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;
the capabilities of CASE systems to describe processes taking into account the requirements of paragraph 2;
features of the information system being developed/implemented.

It is pointless to talk about the advantages of a particular system/notation until the type and scope of the project, as well as the main tasks that this project must decide. Our article makes an attempt to compare the most popular notations (notation systems adopted for modeling) used to describe business processes, and two systems that support these notations. It is expected that this material will serve as the basis for a discussion on the problems of effective use of CASE systems for describing and analyzing enterprise business processes.

Description of business processes is carried out for the purpose of their further analysis and reorganization. The purpose of the reorganization may be the introduction of an information system, reducing production costs, improving the quality of customer service, creating job and work instructions during implementation ISO standards 9000, etc. For each such task, there are certain parameters that determine a set of critical knowledge about the business process. From task to task, the requirements for describing business processes may change. IN general case The business process model should provide answers to the following questions:

what procedures (functions, work) must be performed to obtain the specified final result;
in what sequence these procedures are performed;
what control and management mechanisms exist within the business process under consideration;
roles and responsibilities - who carries out the process procedures;
what input documents/information each process procedure uses;
what output documents/information does the process procedure generate;
what resources are needed to perform each process procedure;
what documentation/conditions govern the implementation of the procedure;
what parameters characterize the implementation of procedures and the process as a whole;
is there a sequence of processes that minimizes costs (including cost, time, etc.);
to what extent the process is/will be supported by the information system.

The description of a business process is formed using notation and a tool environment that allows you to reflect all the above aspects. Only in this case will the business process model be useful for the enterprise, since it can be analyzed and reorganized.

ARIS eEPC notation

Table 1. eEPC notation objects

	Name	Description
1	Function	The “Function” object is used to describe the functions (procedures, works) performed by departments/employees of the enterprise
2	Event	The “Event” object is used to describe the real states of the system that influence and control the execution of functions
3	Organizational unit	An object reflecting various organizational units of an enterprise (for example, management or department)
4	Document	An object that represents real-life storage media, such as a paper document
5	Application system	The object reflects the real application system used within the function execution technology
6	Information cluster	An object characterizes data as a set of entities and relationships between them. Used to create data models
7	Arrow of connection between objects	An object describes the type of relationship between other objects, such as the activation of a function by some event
8	Logical "AND"
9	Logical "OR"	A logical operator that defines relationships between events and functions within a process. Allows you to describe process branching
10	Logical exclusive "OR"	A logical operator that defines relationships between events and functions within a process. Allows you to describe process branching

Rice. 1. Example of a model in eEPC notation

every function must be initiated by an event and must end with an event;
each function cannot include more than one arrow that “starts” the execution of the function, and cannot exit more than one arrow describing the completion of the function.

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

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

Rice. 2. An example of using ARIS objects to describe business processes

Each object in the ARIS Toolset system, which supports the ARIS method of describing business processes, has a specific set of attributes. The user is offered to use standard attributes to describe objects or a limited number of custom attributes.

Rice. 3. Description of the customer service process process

Rice. 4. Description of the process of analysis and approval of the client’s application

ARIS Organizational Chart Notation

Organizational Chart notation is one of the main notations of ARIS and is intended for constructing diagrams organizational structure enterprises. Typically, this model is built at the beginning of a business process modeling project. The model reflects the existing divisions of the enterprise in the form of a hierarchical structure, as shown in Fig. 5.

Rice. 5. Model of the organizational structure of the enterprise

The model is built from the objects “Organizational unit”, “Position”, “Internal person”, etc. The types of connections included in the notation make it possible to reflect different kinds relationships between objects of the organizational structure. In the one shown in Fig. In the example 5, “Enterprise” is managed by “Director”, and the connection type “is Organization Manager for” is used. The hierarchy of departments is built using connections of the “is composed of” type. In addition, positions may be indicated - “Position” and surnames real employees occupied by them: “Internal person”, as well as the type of connection “occupies”.

In addition to models of the hierarchy of departments, models of the hierarchy of subordination in project teams, groups, etc. can be built. All objects reflected in the models can be used in the future when building business process models. When building complex hierarchical structures, decomposition can be used, for example, the structure of a department can be reflected in a more detailed diagram.

ARIS Information Flow Notation

Information Flow notation is analogous to DFD notation (see below) and is used when constructing data flow diagrams or documents between functions of enterprise business processes, as shown in Fig. 6.

Rice. 6. Fragment of the ARIS Information Flow diagram

The simplicity of the notation limits its scope useful application. The main objects of the notation are “Function” (also used when building business process models) and “Information Flow” - information flow (Fig. 7).

Rice. 7. ARIS Information Flow Notation

When building business process models, an eEPC model can be built first, and then, using the functions defined in the process, an information flow model.

Notations supported by BPwin 4.0

Description of IDEF0 and IDEF3 notations

The IDEF0 notation was developed based on the SADT structural analysis and design methodology, approved as a US standard and successfully used in many projects related to the description of enterprise activities. IDEF0 has become extremely widespread and is, in particular, a standard in international organizations such as NATO and the IMF. The IDEF3 notation was developed to more conveniently describe workflows, for which it is important to reflect the logical sequence of procedures. Objects of IDEF0 and IDEF3 notations are shown in table. 2 and 3.

Table 2. eEPC notation objects

	Name	Description
IDEF0 notation
1	Activity	The object is used to describe the functions (procedures, work) performed by departments/employees of the enterprise. Depicted as a rectangle. The job name should reflect the process, the action. In order for a job to be simulated, some time must pass from the start to the end of the job and some resources must be expended
2	Entry arrow	The arrow is drawn entering the work on the left and describes the incoming documents, information, material resources necessary to perform the function and changed by the work
3	exit arrow	The arrow is drawn emanating from the work on the right and describes the results of the work - outgoing documents, information, material resources. In IDEF0 notation, each procedure must have at least one exit arrow
4	Control arrow	An arrow is drawn entering the work from above and describes a control action, for example an order, normative document etc. In IDEF0 notation, each procedure must have at least one control arrow
5	Mechanism arrow	The arrow is drawn entering the work from below and describes the so-called mechanisms, that is, resources necessary to perform the procedure, but not changing their state during its execution. Examples: employee, machine, etc.
6	Call arrow	The arrow is drawn coming from the work down and is a link to another work model. In BPwin, this arrow is used to merge and split models

Table 3. IDEF3 notation objects

	Name	Description
DFD Notation
1	Job	The object is used to describe the functions (procedures, work) performed by departments/employees of the enterprise. Depicted as a rectangle. The job name should reflect the process, action
2	Referent object	An object used 1) to describe links to other diagrams; 2) links to other works; 3) links to objects; 4) to explain the logic of branching arrows at intersections; 5) various comments on functions and intersections
3	Crossroads	Logical operators (5 types - synchronous and asynchronous “AND”, synchronous and asynchronous “OR”, exclusive “OR”), defining the relationship between functions within the process. Allows you to describe the branching of the process
4	Arrows	Three types of arrows that allow you to describe the sequence of processes, as well as the flow of information and objects

The semantics of constructing IDEF0 and IDEF3 models requires adherence to clear rules. A complete description of IDEF standards can be found at http://www.idef.com/.

An example of a business process description in IDEF0 notation is shown in Fig. 8 (corresponds to the process shown in Fig. 3).

Rice. 8. An example of a business process description in IDEF0 notation

One of the features of describing processes in the IDEF0 notation is a clear identification of the advantages and disadvantages of business processes. Works on the IDEF0 diagram are arranged in order of dominance - from the upper left corner of the diagram to the lower right. In the top left corner is either the most important job or the job done first. Arrows connect the works, and there are five types of connections. An arrow directed from the output of a higher work to the input or control of a lower one is a direct connection; an arrow directed from the output of a lower-level operation to the input or control of a higher-level one is feedback. Lack of feedback, work without output or management, duplicate work indicate imperfection of business processes.

In Fig. Figure 9 shows an example of a business process description in IDEF3 notation (corresponds to the process shown in Figure 4).

Rice. 9. An example of describing a business process in IDEF3 notation

The IDEF3 notation, like the ARIS eEPC notation, uses logic symbols to reflect process branching. A diagram in IDEF3 notation allows you to represent the entire process, tracking the sequence of operations and the logic of the process.

Description of DFD Notation

DFD notation is intended to describe information flows in the organization being surveyed. The objects of the DFD notation are shown in Table. 4. The presence of “data warehouse” objects and bidirectional arrows allows you to most effectively describe the document flow and requirements for the information system.

Table 4. DFD Notation Objects

	Name	Description
DFD Notation
1	Activity	The object is used to describe information processing functions performed by departments/employees of the enterprise
2	Link object	A reference object models an object that affects the system from outside
3	Data store	A data warehouse models a place where information is stored - an archive, database, repository, etc.
4	Arrow	The arrow shows the flow of information, the movement of documents moving together as one package. The arrow can be bidirectional, that is, it shows the flow of information along a given route in both directions

In Fig. Figure 10 shows an example of a DFD diagram.

Rice. 10. An example of document flow description in DFD notation

For a more detailed description and design of an information system, ERwin can be used together with BPwin - a CASE tool that allows you to create and recreate a data model. The connection between the BPwin process model and the ERwin data model is made by importing a dictionary of entities and attributes from ERwin into BPwin. In a process model, each arrow can be associated with a set of entities and attributes, and each job can be associated with a set of rules for using data. This relationship between process and data models makes it possible to describe in detail the correspondence of data and their consumers and thereby eliminate errors that may arise during the creation and implementation of information systems.

Organizational Chart in BPwin 4.0

BPwin organizational charts (Fig. 11) are analogous to ARIs organizational charts and, like in ARIS, are intended to describe the hierarchy of subordination in organizations.

Rice. 11. Example of an organizational chart in BPwin

To create an organizational chart in BPwin, you must first enter the following information in the dictionaries.
Images (bitmaps), if you plan to use icons on the organizational chart.
Role groups - can match structural unit. In the example in Fig. Figure 10 shows the role groups “Directorate”, “Accounting” and “Workshop No. 1”.
Roles - may correspond to the position. In the example in Fig. 10 shows the roles of “Gen. Director", "Accountant", "Technologist", etc.
Resources - can correspond to the last name of a specific person.

After creating the dictionary, BPwin allows you to create a hierarchy of subordination, including role groups, roles and resources, using guide dialogs. In IDEF0, IDEF3 and DFD diagrams, each job can be assigned a resource worker from the resource dictionary. Roles and resources can also be used to create a Swim Lane diagram - a variation of the IDEF3 diagram, which shows the areas of responsibility of enterprise employees when performing process operations in the form of separate stripes.

A comparative analysis of the ARIS and IDEF notations is given in Table. 5.

Table 5. Objects of ARIS, IDEF0 and IDEF3 notations

	Comparison criteria
1	Diagram principle/process logic		Dominance principle (see IDEF0 standard)	Time sequence of procedures
2	Description of the process procedure	Object on diagram	Object on diagram	Object on diagram
3	Incoming document
4	Incoming information		Entry Arrow, Control Arrow	A separate object is used for the description (Reference object of type Object or arrow Object flow)
5	Outgoing document	A separate object is used for description (“document”)	exit arrow	A separate object is used for the description (Reference object of type Object or arrow Object flow)
6	Outgoing information	Uses a separate object for description ("cluster", "technical term")	exit arrow	A separate object is used for the description (Reference object of type Object or arrow Object flow)
7	Performer of the procedure	A separate object is used for description (“position”, “organizational unit”)	Mechanism arrow
8	Equipment used	Uses a separate object for description	Mechanism arrow	No (can only be reflected in the model by reference object binding)
9	Procedure management	No. Can only be reflected by symbols of logic and events (sequence of procedures) and/or indication of incoming documents	Control arrow	Only the time sequence of procedures and process logic
10	Monitoring the execution of the procedure	No. Can be reflected by indicating incoming documents	Control arrow	No (can only be reflected in the model by reference object binding).
11	Management/control feedback		Control arrow	No
12	Login feedback	No. Can only be reflected by logic symbols (sequence of procedures)	Entry arrow	No

One of the most important aspects of describing business process models is the reflection on the model of control actions, feedback on control and management of the procedure. In the ARIS eEPC notation, procedure control can only be reflected by indicating the incoming documents that govern the execution of the procedure and the sequence of procedures in time (trigger events). Unlike ARIS, in IDEF0 notation each procedure must have at least one control action (control input - arrow on top). If, when creating a model in eEPC, you specify only the sequence of procedures, without worrying about reflecting control actions (for example, documents and information), the resulting models will have low value in terms of analysis and further use. Unfortunately, this is the error that is most common in practice. A Workflow model is created, reflecting a simple sequence of execution of procedures and incoming/outgoing documents, while control (control) influences on functions are not reflected in the model.

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

How is the control influence on functions 2 and 3 carried out? Only the fact is shown that during the process it is possible to return and re-execute functions 2 and 3; information about this feedback may be
disclosed only as 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?

Rice. 12. Disadvantages of describing a business process in ARIS eEPC

If you try to reflect all the conditions and restrictions 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). The IDEF0 notation does not have these disadvantages. 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 fairly simple IDEF3 notation. To adequately describe the management process in the eEPC notation, it is necessary to agree in advance on how the documents (information) regulating the implementation of process procedures will be reflected in the model.

Functionality of ARIS and BPwin products

Tool functionality ARIS modeling Toolset and BPwin can be correctly compared only in relation to a certain range of tasks. IN this study The problem of forming models (descriptions) of enterprise business processes is considered. Each of the systems under consideration has its own advantages and disadvantages. Depending on the tasks being solved, these advantages can either increase or, conversely, weaken. The same can be said about shortcomings: a shortcoming of a system within the framework of one project may not be such 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 us to solve this problem. On the other hand, a procedure performed by one person may be more adequately described using eEPC ARIS than using IDEF0 or IDEF3 BPwin. A comparison of the systems' functionality is given in Table. 6.

Table 6. Comparison of functionality of ARIS Toolset 5.0 and BPwin 4.0

	Features/Workplace Environment	ARIS Toolset 5.0	BPwin 4.0
1	Supported standard	(partially - DFD, ERM, UML)	IDEF0, IDEF3, DFD
2	Model data storage system	Object Database	Models are stored in files. It is possible to create a repository based on a relational DBMS using ModelMart
3	Database size limit		No. Database size is limited by computing resources
4	Possibility of group work	Eat. Used by ARIS Server	Eat. Used by ModelMart
5	Limit on the number of objects on the diagram	No	For DFD and IDEF3 - no. For IDEF0, limited by notation guidelines
6	Possibility of decomposition	Unlimited decomposition. Decomposition into different types of models is possible	Unlimited decomposition. It is possible to switch to another notation during the decomposition process
7	Model presentation format	Not regulated	Standard form (frame) IDEF with the ability to disable it
8	Ease of use when creating models	Complex control panel, there is object alignment, there is undo	Simple control panel, no object alignment, no undo
9	UDP - User Defined Object Properties	Large but limited number of properties; number of types is limited	The number of UDPs is not limited. Limited number of types (18)
10	Ability to analyze process costs	Eat. Possibility to use ARIS ABC	Simplified ABC - cost analysis by frequency of use in a process. Ability to export to Easy ABC
11	Generating reports	Create reports based on standard and user-custom Visual Basic macros	RPTwin, the ability to visually customize reports, including calculation using formulas using UDP
12	Difficulty in developing custom reports	Difficult	Just
13	Export reports		Implemented export of reports to MS Office, text file, RTF, HTML
14	Communication with the data model	Ability to build ERD diagrams, additional software required for export	Implemented connection with the ERwin data model. Each arrow can be associated with a set of entities and attributes
15	Description of data access	No	Data usage rights may be described for each work. The data model object can be created directly in the BPwin environment
16	Description of supporting documentation	Yes, OLE support	Using the UDP command type, each arrow is associated with any document that can be loaded using a Windows application. The application is launched directly from the BPwin environment

When comparing the two systems, it should immediately be noted that ARIS uses an object DBMS to store models and a new database is created for each project. For user convenience, 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 functions for database administration: access control, consolidation, etc. In BPwin, model data is stored in a file, which greatly simplifies the work of creating a model. For group work on large projects, BPwin models are stored in the Model Mart repository (supplied separately). Model Mart is a model repository for BPwin and ERwin and uses relational DBMS Oracle, Informix, MS SQLServer, Sybase). It provides administration, including differentiation of access rights to the model object level, comparison of versions, merging models, etc.

ARIS supporters often cite the limitation on the number of objects on the diagram as one of the disadvantages of BPwin. However, the experience of real projects shows that for a project whose results can actually be 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 identify and analyze problems, that is, 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 widespread belief among company directors that a detailed description of processes in itself is valuable and can solve many problems. But this is far from the truth. It is the understanding of what needs to be described and what aspects of the functioning of a real system to reflect that determines the success of a business process modeling project.

ARIS provides significantly more opportunities for working with individual model objects, but precisely because of the excessive number of settings, work on creating a model must be regulated by complex, multi-aspect documentation - the so-called modeling agreements. The development of these agreements in itself is complex, expensive and requires considerable time (1-3 months) and qualified specialists. If a project using ARIS begins without detailed development of such agreements, then the likelihood of creating business process models that do not answer the questions asked is 80-90%. In turn, BPwin is easy to use and has fairly strict regulations when creating diagrams (the IDEF standard and recommendations for its use, the IDEF form for creating a diagram, a limited number of mandatory fields, limiting the number of objects on one diagram, etc.). ARIS is certainly a “heavier” tool compared to BPwin, but in the end this results in significant difficulties and high costs for its operation.

Various situations of using business process modeling tools and their expert assessment on a 5-point scale are shown in Table. 7.

Table 7. Assessment of the applicability of ARIS Toolset 5.0 and BPwin 4.0 for business process modeling tasks

Task/Workbench	ARIS Toolset 5.0
One-time project to describe business processes, for example: description of one business process from the point of view of control and management; description of functionality new system top level management	3	5
A long-term (continuous) project to describe the company’s activities from various points of view (organizational structure, document structure, large volume of process database, etc.)	5	4
Automation system development: description of the system functionality; creating a logical data model; connection between the process model and the data model; creating a physical data model; application code generation.	3 3 - -	5 BPwin + ERwin + Paradigm Plus

Positioning of systems can be carried out in relation to solving the problem of modeling business processes (Fig. 13).

Rice. 13. Evaluating the effectiveness of ARIS Toolset and BPwin

Thus, for 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, such as the implementation of a system of continuous improvement of business processes, ISO, TQM), ARIS is more suitable. It should be noted that the ARIS Toolset system is inconvenient to create information models, and designing and configuring databases is not provided. In this case, preparatory work to create regulatory documentation may take 1-3 months, but this is a necessary element of subsequent successful work.

Website www.finexpert.ru
Web site
Website www.idef.com
S.V. Maklakov. BPwin and ERwin. CASE-tools for information systems development. Moscow: Dialogue-MEPhI, 2000, 256 p.
YES. Marka, K. McGowan Methodology of structural analysis and design. Moscow, 1993.
"ARIS Methods". PDF file, more than 1000 pages. Supplied with a demo version of the ARIS Toolset system.
August-Wilhelm Scheer. Business processes: basic concepts, theories, methods. Moscow: Enlightener, 1999.

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):

Various 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 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:

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.
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 ...”)
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.
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 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 has no duration in time, or this time tends to zero (or does not matter). Moreover, an event always causes the need to execute a function, and the execution of a function always ends with an event. Let me explain with an example. The phone rings. The manager picked up the phone for a telephone conversation. In this case, “The phone rings” is an event. Phone conversation is a function. The conversation is over (hung up) – another event. Thus, an event chain is observed: Call - conversation - end of 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 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 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 that ended event2. If, for example, with a phone call, it would be like this:

The connection between event and function 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:

Job title(executor). 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 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 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 that you need to adhere to 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 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. And practically, including from common sense, it 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:

AND. When two or more events happen at the same time;
OR. When one or more events can happen, but at least one thing must happen;
EXCLUSIVE OR. Either one or the other. Those. two options are impossible 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 alternative. I brought them both because... in practice in various sources you can see both options. Which one to use is up to you. I like the first one better.
Now you need to understand the use of 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: Completed some work with the 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: Prepared and sent the goods invoice for shipment to the client. 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 is provided (function 1) or a product is sold (function 2), and a debt arises from the client (event 1).

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.

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

Example: The goods were delivered (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.

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 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 the following: important topics, such as collecting information, highlighting business processes, decomposition, highlighting indicators. We will definitely study these issues in future issues.

Introduction. Typical tasks for describing business processes

In the early stages of projects whose goal is the reorganization of business processes and the implementation of information systems, managers and specialists most often have the following questions:

what results in terms of improving the organization’s activities can be achieved using technologies for describing and reorganizing business processes;
what software to use in the project (“ARIS is better than BPwin?”, “ERwin is better than ARIS?”, etc.);
how to model processes using product “X”;
how to analyze and identify problems using product “X”;
what methodology to use to describe processes;
what to do next with the resulting business process models.

Currently, a fairly large number of CASE systems are presented on the Russian market, many of which allow one way or another to create descriptions (models) of enterprise business processes. At the same time, there are systems that are primarily focused on creating process models and are inconvenient or not designed at all for creating data models and configuring a DBMS. Obviously, the choice of system is determined by the goals of the project and significantly affects its entire further course. A rational choice of system is possible if the company’s management 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;
the capabilities of CASE systems to describe processes taking into account the requirements of paragraph 2;
features of the information system being developed/implemented.

It is pointless to talk about the advantages of a particular system/notation until the type and scope of the project, as well as the main tasks that this project must solve, have been determined. Our article makes an attempt to compare the most popular notations (notation systems adopted for modeling) used to describe business processes, and two systems that support these notations. It is expected that this material will serve as the basis for a discussion on the problems of effective use of CASE systems for describing and analyzing enterprise business processes.

Description of business processes is carried out for the purpose of their further analysis and reorganization. The purpose of the reorganization may be the introduction of an 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 a set of critical knowledge about the business process. From task to task, the requirements for describing business processes may change. In general, a business process model should provide answers to the following questions:

what procedures (functions, work) must be performed to obtain the specified final result;
in what sequence these procedures are performed;
what control and management mechanisms exist within the business process under consideration;
roles and responsibilities - who carries out the process procedures;
what input documents/information each process procedure uses;
what output documents/information does the process procedure generate;
what resources are needed to perform each process procedure;
what documentation/conditions govern the implementation of the procedure;
what parameters characterize the implementation of procedures and the process as a whole;
is there a sequence of processes that minimizes costs (including cost, time, etc.);
to what extent the process is/will be supported by the information system.

ARIS Organizational Chart Notation

The Organizational Chart notation is one of the main ARIS notations and is intended for constructing diagrams of the organizational structure of an enterprise. Typically, this model is built at the beginning of a business process modeling project. The model reflects the existing divisions of the enterprise in the form of a hierarchical structure, as shown in Fig. 5 .

The model is built from the objects “Organizational unit”, “Position”, “Internal person”, etc. The types of connections included in the notation make it possible to reflect various types of relationships between objects of the organizational structure. In the one shown in Fig. In the example 5, “Enterprise” is managed by “Director”, and the connection type “is Organization Manager for” is used. The hierarchy of departments is built using connections of the “is composed of” type. In addition, positions can be indicated - “Position” and the names of the real employees occupying them: “Internal person”, as well as the type of connection “occupies”.

Notations supported by BPwin 4.0

Description of IDEF0 and IDEF3 notations

The semantics of constructing IDEF0 and IDEF3 models requires adherence to clear rules. A complete description of IDEF standards can be found at http://www.idef.com/.

An example of a business process description in IDEF0 notation is shown in Fig. 8 (corresponds to the process shown in Fig. 3).

Description of DFD Notation

DFD notation is intended to describe information flows in the organization being surveyed. The objects of the DFD notation are shown in Table. 4 . The presence of “data warehouse” objects and bidirectional arrows allows you to most effectively describe the document flow and requirements for the information system.

Conclusions. Recommendations for the use of systems depending on typical tasks

Various situations of using business process modeling tools and their expert assessment on a 5-point scale are shown in Table. 7.

Positioning of systems can be carried out in relation to solving the problem of modeling business processes (Fig. 13).

Thus, for 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, such as the implementation of a system of continuous improvement of business processes, ISO, TQM), ARIS is more suitable. It should be noted that the ARIS Toolset system is inconvenient for creating information models, and designing and configuring databases is not provided. In this case, preparatory work to create regulatory documentation may take 1-3 months, but this is a necessary element of subsequent successful work.

August-Wilhelm Scheer. Business processes: basic concepts, theories, methods. Moscow: Enlightener, 1999.

ComputerPress 1"2002

The ARIS eEPC notation stands for the following - 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 Professor Scheer (see)

It might be useful to read: