Description of the ARIS eEPC notation. Feedback display. Requirements for the description of business processes of enterprises

General structure of the ARIS methodology

http://rudocs.exdat.com/docs/index-62596.html?page=3

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

Table 2.3.1 Objects for describing business processes in the ARIS eEPC notation.

In addition to the main objects listed in Table 2.3.1, many other objects can be used to construct an eEPC diagram. In practice, the use of a large number of objects of various types is impractical, since this significantly increases the size of the model and makes it difficult to read. To understand the meaning eEPC notations Let's consider the main used types of objects and links. Figure 2.3.5. the simplest eEPC model is presented, which describes a fragment of the business process of an enterprise.

Rice. 2.3.5. The simplest model in eEPC notation

From figure 2.3.5. it can be seen 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 "starting" the execution of Functions 2 and 3. A careful analysis of the eEPC notation shows that it is practically the same as the IDEF3 notation. The most important difference of eEPC is the presence of the "event" object ("Event"). This object is used to display in the model the possible results of the execution of functions, depending on which one or another subsequent process branch is executed. The eEPC notation is called, obviously, extended precisely because of the presence of the "event" object in it - there is no such object in IDEF3. When building a model in ARIS eEPC, the following rules must be observed:

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.

Figure 2.3.7 shows the use of various objects of the ARIS eEPC notation when creating a business process model.

Rice. 2.3.7. Using various objects when creating a model in eEPC notation

From figures 2.3.6. and 2.3.7. it can be seen that the business process in the eEPC notation is a sequence of procedures arranged in the order of their execution. 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 the processes and visual display of the workload of personnel in the process, you can use other description tools, such as Gantt charts in the MS Project application.

Figure 2.3.8. the business process of processing a customer order is presented. The process starts with the event "Customer order received". This event triggers the "Perform Order Posting in System" function, which is performed by the Sales Manager. He uses the "Order Accounting System" to get the job done. The result of the function execution is displayed by the "Order posting completed" event. After that, the sales manager performs the function "Perform analysis for compliance with the nomenclature". The result of the function execution is two alternative events "The order corresponds to the range" and "The order does not correspond to the range". The process is branching. The logical exclusive "OR" symbol is used to display process branching. The function "Notify the customer about the impossibility of fulfilling the order" can be performed in two cases: if the order does not match the range, or if production is impossible. To display these options on the process diagram, the logical “OR” symbol, etc. is used. As can be seen from Figure 2.3.8., the process diagram in ARIS eEPC differs from the diagram in IDEF3 by the presence of objects: events, documents, application systems and positions. The scheme in ARIS is visually more informative and perceived better, however, the size of this scheme significantly exceeds the size of the scheme in the IDEF3 notation.
Rice. 2.3.8. An example of a process description in ARIS eEPC notation

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

which software use in a 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 the introduction of an information system, reducing the cost of production, improving the quality of customer service, creating job and work instructions for the implementation ISO standards-9000 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 certain 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 of ARIS and IDEF notations is 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, you specify only the sequence of procedures, not 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 you 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 (the IDEF standard and recommendations for its use, the 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.

Introduction. Typical tasks for describing business processes

in the early stages of projects whose goal 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;
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 with 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 business processes of enterprises. 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 to a large extent affects its entire further course. 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 paragraph 2;
features of the developed/implemented information system.

It is pointless to talk about the advantage of this or that system / notation until the type and scope of the project are determined, as well as the main tasks that this project must solve. In our article, an attempt was made to compare the most popular notations (notation systems adopted in modeling) used to describe business processes, and two systems that support these notations. It is assumed that this material 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 an information system, reduce production costs, improve the quality of customer service, create 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;
roles and responsibilities - who performs the process procedures;
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;
whether there is a sequence of processes that minimizes costs (including cost, time, etc.);
how 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 designed to build diagrams of the organizational structure of an enterprise. Typically, this model is built at the start 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 relationships included in the notation allow you to reflect different kinds relations between objects of the organizational structure. In the one shown in Fig. 5 example "Enterprise" is managed by "Director", while using the type of communication "is Organization Manager for". The hierarchy of subdivisions is built using links of the "is composed of" type. In addition, positions can be indicated - "Position" and the names of the real employees who occupy them: "Internal person", as well as the type of communication "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 models of business processes. When building complex hierarchical structures, decomposition can be used, for example, the structure of a unit can be reflected in a more detailed diagram.

Notations supported by BPwin 4.0

Description of IDEF0 and IDEF3 notations

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. IDEF0 has become extremely widespread and is, in particular, the standard in international organizations such as NATO and the IMF. IDEF3 notation was developed with the aim of more convenient description of workflows (Workflow), for which it is important to reflect the logical sequence of procedures. Objects of IDEF0 and IDEF3 notations are shown in Table. 2 and .

The semantics of constructing IDEF0 and IDEF3 models presupposes the observance of clear rules. Full description 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).

One of the features of describing processes in the IDEF0 notation is a clear identification of the advantages and disadvantages of business processes. The 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 upper left corner is placed either the most important work, or the work done first. The arrows link the jobs, with five types of links being distinguished. An arrow pointing from the output of a higher work to the input or control of a lower one is a direct link; an arrow directed from the output of the lower work to the input or control of the higher work is feedback. Lack of feedback, work without output or control, duplicate work indicate the imperfection of business processes.

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

Description of DFD notation

The DFD notation is intended to describe information flows in the organization under study. Objects DFD notation shown in table. 4 . The presence of "data storage" objects and bidirectional arrows allows you to most effectively describe the workflow and requirements for the information system.

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, you specify only the sequence of procedures, not caring about the reflection of control actions (for example, documents and information), the resulting models will be of low value in terms of analysis and further use. Unfortunately, this error is the most common in practice. A Workflow model (workflow) 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.

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. For group work on large projects, BPwin models are stored in the Model Mart repository (supplied separately). Model Mart is a repository of models for BPwin and ERwin and uses relational DBMS Oracle, Informix, MS SQLServer, Sybase). It provides for administration, including the differentiation of access rights to the level of the model object, version comparison, model merging, etc.

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, that is, a detailed description of the most complex, problematic areas of activity is required, and not a total description of all processes. Strange as it may seem, there is a widespread belief among company directors that a detailed description of processes is valuable in itself 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 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 is in itself a complex, costly and time-consuming task (1-3 months) and skilled professionals. 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 rather strict regulation when creating diagrams (the IDEF standard and recommendations for its use, the IDEF form for creating a diagram, a limited number of required fields, a limit on the number of objects in one diagram, etc.). ARIS, of course, is a "heavier" tool compared to BPwin, but in the end it turns into significant difficulties and high costs for its operation.

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

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

Positioning of systems can be carried out in relation to the solution of 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 it is inconvenient for the ARIS Toolset system to create information models, and the design and configuration of databases is not provided. In this case, preparatory work on the creation of regulatory documentation may take 1-3 months, but this is a necessary element for subsequent successful work.

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

ComputerPress 1 "2002

V. Repin, S. Maklakov

Analysis of the activities of enterprises and the reorganization of business processes is an extremely difficult task that requires methodological and instrumental support. IN Lately BPwin (Computer Associates) and ARIS Toolset (ARIS) CASE tools are gaining popularity among business analysts. This article provides a brief comparative analysis these tools and recommendations for their use.

Introduction. Typical tasks for describing business processes

In the early stages of projects, the purpose of which 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 with product X;
what methodology to use to describe processes;
what to do next with the resulting business process models.

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 paragraph 2;
features of the developed/implemented information system.

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;
roles and responsibilities - who performs the process procedures;
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;
whether there is a sequence of processes that minimizes costs (including cost, time, etc.);
how the process is/will be supported by the information system.

ARIS eEPC notation

The ARIS eEPC notation stands for: 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. In table. 1 shows the main objects used in the framework of the notation.

Table 1. eEPC Notation Objects

	Name	Description
1	Function	The "Function" object is used to describe the functions (procedures, work) performed by departments / employees of the enterprise
2	Event	The "Event" object is used to describe the real states of the system that affect and control the execution of functions
3	Organizational unit	An object that reflects the various organizational units of the enterprise (for example, management or department)
4	Document	An object that represents real media, such as a paper document
5	Application system	The object reflects the real application system used within the framework of 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	Link arrow between objects	An object describes a type of relationship between other objects, such as activating the execution of a function by some event.
8	Logic "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

In addition to those listed in Table. 1 of the main objects when building an eEPC diagram, many other objects can be used. The use of a large number of different objects connected by various 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. On fig. 1 shows the simplest eEPC model that describes a fragment of an enterprise business process.

Rice. 1. Model example in eEPC notation

On fig. 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 character 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 for the 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.

On 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

From fig. 1 shows that the business process in the eEPC notation is a sequence of procedures arranged in the order of their execution. It should be noted that the actual duration of the execution 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 the simultaneous execution of two tasks. 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, you must use other description tools, such as Gantt charts in the Microsoft 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). Examples of models generated using ARIS eEPC are shown in fig. 3 and 4.

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

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 relationships included in the notation allow you to reflect various types of relationships between objects of the organizational structure. In the one shown in Fig. 5 example "Enterprise" is managed by "Director", while using the type of communication "is Organization Manager for". The hierarchy of subdivisions is built using links of the "is composed of" type. In addition, positions can be indicated - "Position" and the names of the real employees who occupy them: "Internal person", as well as the type of communication "occupies".

ARIS Information Flow notation

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

Rice. 6. Fragment of the ARIS Information Flow diagram

The simplicity of the notation limits the scope of its 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 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. IDEF0 has become extremely widespread and is, in particular, the standard in international organizations such as NATO and the IMF. IDEF3 notation was developed with the aim of more convenient description of workflows (Workflow), 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	Work (Activity)	The object is used to describe the functions (procedures, work) performed by departments/employees of the enterprise. Shown as a rectangle. The name of the work should reflect the process, the action. In order for the work to be modeled, some time must pass from the beginning to the end of the work and some resources must be expended.
2	Entry arrow	The arrow is drawn on the left side of the work and describes the incoming documents, information, material resources needed to perform the function and changed by the work.
3	exit arrow	The arrow is drawn outgoing 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	arrow control	The arrow is drawn entering the work from above and describes the control action, for example, an order, a regulatory document, etc. In IDEF0 notation, each procedure must have at least one control arrow
5	Arrow mechanism	The arrow is drawn entering the work from below and describes the so-called mechanisms, that is, the resources necessary to perform the procedure, but do not change their state during its execution. Examples: employee, machine, etc.
6	call arrow	The arrow is drawn downward from the work and is a link to another work model. In BPwin, such an 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. Shown as a rectangle. The name of the job must reflect the process, action
2	Reference Object	An object used 1) to describe links to other diagrams; 2) references to other works; 3) references 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") that define the relationship between functions within the process. Allow to describe process branching
4	Arrows	Three types of arrows that describe the sequence of processes, as well as the flow of information and objects

The semantics of constructing IDEF0 and IDEF3 models presupposes the observance of clear rules. A complete description of the 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. The works on the IDEF0 diagram are arranged in order of dominance - from the upper left corner of the diagram to the lower right. Either the most important work or the work done first is placed in the upper left corner. The arrows link the jobs, with five types of links being distinguished. An arrow pointing from the output of a higher work to the input or control of a lower one is a direct link; an arrow directed from the output of the lower work to the input or control of the higher work is feedback. Lack of feedback, work without output or control, duplicate work indicate the imperfection of business processes.

On 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 a business process description in IDEF3 notation

Description of DFD notation

The DFD notation is intended to describe information flows in the organization under study. Objects of DFD notation are shown in Table. 4. The presence of "data storage" objects and bidirectional arrows allows you to most effectively describe the workflow and requirements for the information system.

Table 4. DFD Notation Objects

	Name	Description
DFD notation
1	Work (Activity)	The object is used to describe the information processing functions performed by departments / employees of the enterprise
2	Link object	The link object models an object that acts on the system from the outside.
3	Data store	A data warehouse models a place where information is stored - an archive, a database, a 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 this route in both directions

On fig. 10 shows an example DFD diagram.

Rice. 10. Example of document flow description in DFD notation

For a more detailed description and design of an information system, ERwin, a CASE tool that allows you to create and recreate a data model, can be used together with BPwin. The link 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 the process model, each arrow can be associated with a set of entities and attributes, and each job with a set of data usage rules. Such a relationship between process and data models makes it possible to describe in detail the correspondence between data and their consumers, and thereby eliminate errors that may occur during the creation and implementation of information systems.

Organizational Charts in BPwin 4.0

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

Rice. 11. An example of an organization chart in BPwin

To create an organization chart in BPwin, you must first enter the following information in the dictionaries.
Images (bitmaps), if icons are supposed to be used on the organization chart.
Role groups - can match structural unit. In the example in fig. 10 shows the role groups "Directorate", "Accounting" and "Workshop No. 1".
Roles - can correspond to the position. In the example in fig. 10 shows the roles of “Gen. Director, Accountant, Technologist, etc.
Resources - can correspond to the name of a particular person.

Once the dictionary has been created, BPwin allows you to create a reporting hierarchy using dialog guides, including role groups, roles, and resources. In IDEF0, IDEF3, and DFD diagrams, each job can be assigned a resource performer from a 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 in the performance of technological operations in the form of separate bars.

Comparative analysis of ARIS and IDEF notations is given in Table. 5.

Table 5. Objects of ARIS, IDEF0 and IDEF3 notations

	Comparison criteria
1	Diagramming Principle/Process Logic		Dominance principle (see IDEF0 standard)	Time Sequence of Procedures
2	Process Procedure Description	Object on the diagram	Object on the diagram	Object on the diagram
3	Incoming Document
4	Input Information		Entry Arrow, Control Arrow	A separate object is used for 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 description (Reference object of type Object or arrow Object flow)
6	outgoing information	A separate object is used for description ("cluster", "technical term")	exit arrow	A separate object is used for description (Reference object of type Object or arrow Object flow)
7	Procedure performer	A separate object is used for description ("position", "organizational unit")	Arrow mechanism
8	Used equipment	A separate object is used to describe	Arrow mechanism	No (can only be reflected in the model by binding a reference object)
9	Procedure management	No. It can be reflected only by symbols of logic and events (sequence of execution of procedures) and / or an indication of incoming documents	arrow control	Only the time sequence of the execution of procedures and the logic of the process
10	Procedure execution control	No. Can be reflected by indicating incoming documents	arrow control	None (can only be reflected in the model by binding a reference object).
11	Control/Control Feedback		arrow control	No
12	Input Feedback	No. Can be reflected only by logic symbols (sequence of procedures execution)	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 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, you specify only the sequence of procedures, not caring about the reflection of control actions (for example, documents and information), the resulting models will be of low value in terms of analysis and further use. Unfortunately, this error is the most common in practice. A Workflow model (workflow) 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.

On fig. 12 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 is the control action on functions 2 and 3 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 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 business process description in ARIS eEPC

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 poorly readable (these drawbacks are also inherent in IDEF3 notation). These shortcomings are absent in the IDEF0 notation. At the same time, the 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 on how the documents (information) regulating the execution of process procedures will be reflected in the model.

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 either increase or, vice versa, weaken. The same can be said about the shortcomings: the lack of a system within the framework of one project may not be so 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, a procedure performed by one person can be more adequately described using eEPC ARIS than using IDEF0 or IDEF3 BPwin. A comparison of the functionality of the systems is given in Table. 6.

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

	Capabilities / Tooling Environment	ARIS Toolset 5.0	BPwin 4.0
1	Supported standard	(partly - DFD, ERM, UML)	IDEF0, IDEF3, DFD
2	Model storage	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 in the diagram	No	For DFD and IDEF3 - no. For IDEF0 limited to notation guidelines
6	Decomposition capability	Unlimited decomposition. Decomposition into various types of models is possible	Unlimited decomposition. It is possible to switch to another notation during decomposition
7	Model Representation Format	Not regulated	Standard form (framework) IDEF with the ability to turn it off
8	Ease of 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; the number of types is limited	The number of UDP is not limited. Types are limited (18)
10	Ability to analyze the cost of processes	Eat. Possibility to use ARIS ABC	Simplified ABC - analysis of cost by frequency of use in the process. Ability to export to Easy ABC
11	Report generation	Creating reports based on standard and custom Visual Basic macros	RPTwin, possibility of visual customization of reports, including calculation by 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 is required for export	Implemented connection with ERwin data model. Each arrow can be assigned a set of entities and attributes
15	Description of data access	No	For each work, the rights to use the data can be described. The data model object can be created directly in the BPwin environment
16	Description of related documentation	Yes, OLE support	With 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

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. For group work big projects BPwin models are stored in the Model Mart repository (supplied separately). Model Mart is a repository of models for BPwin and ERwin and uses relational DBMS Oracle, Informix, MS SQLServer, Sybase). It provides for administration, including the differentiation of access rights to the level of the model object, version comparison, model merging, etc.

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 is in itself a complex, costly and time-consuming task (1-3 months) and skilled professionals. 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 rather strict regulation when creating diagrams (the IDEF standard and recommendations for its use, the IDEF form for creating a diagram, a limited number of required fields, a limit on the number of objects in one diagram, etc.). ARIS, of course, is a "heavier" tool compared to BPwin, but in the end it turns into significant difficulties and high costs for its operation.

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

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

Task/Workbench	ARIS Toolset 5.0
A one-time project to describe business processes, for example: description of one business process in terms of control and management; functionality description 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 process database, etc.)	5	4
Automation system development: description of the functionality of the system; creation of a logical data model; connection between the process model and the data model; creation of a physical data model; application code generation.	3 3 - -	5 BPwin + ERwin + Paradigm Plus

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

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

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

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 )