Description of the ARIS eEPC notation. Display feedback. Requirements for describing business processes of enterprises

General structure of the ARIS methodology

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

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

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

In addition to the main objects listed in Table 2.3.1, many other objects can be used when constructing an eEPC diagram. In practice, using a large number of objects of different types is impractical, since this significantly increases the size of the model and makes it difficult to read. To understand the meaning eEPC notation Let's look at the main types of objects and connections used. In Figure 2.3.5. the simplest eEPC model is presented, describing a fragment of an enterprise’s business process.

Rice. 2.3.5. The simplest model in eEPC notation

From Figure 2.3.5. it is clear that the connections 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 an AND symbol “triggering” the execution of Function 2 and 3. A careful analysis of the eEPC notation shows that it is practically no different from the IDEF3 notation. The most important difference between eEPC is the presence of an “event” object. This object is used to display in the model the possible results of executing functions, depending on which one or another subsequent branch of the process is executed. The eEPC notation is obviously called extended precisely because it contains an “event” object - there is no such object in IDEF3. When building a model in ARIS eEPC, the following rules must be observed:

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.

Figure 2.3.7 shows the use of various ARIS eEPC notation objects 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 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 cannot be visually reflected in eEPC. This leads to the fact that when creating models, situations are possible when one performer will be assigned to perform two tasks simultaneously. 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 and visually display the workload of personnel in the process, you can use other description tools, for example, Gantt charts in the MS Project application.

In Figure 2.3.8. The business process of processing a customer order is presented. The process begins with the event “Customer order received.” This event initiates the “Post order in the system” function, which is performed by the Sales Department manager. He uses an “Order Accounting System” to complete the work. The result of the function execution is displayed by the “Order accounting completed” event. After this, the sales manager performs the “Perform product compliance analysis” function. The result of executing the function is two alternative events: “The order matches the item” and “The order does not match the item.” The process branches. To display the branching of a process, the logical exclusive "OR" symbol is used. The “Notify the customer about the impossibility of fulfilling the order” function can be performed in two cases: if the order does not correspond to the item, or production is impossible. To display these options on the process diagram, the logical “OR” symbol is used, etc. As can be seen from Figure 2.3.8., the process diagram in ARIS eEPC differs from the diagram in IDEF3 in the presence of objects: events, documents, application systems and positions. The diagram in ARIS is visually more informative and is perceived better, but the size of this diagram is significantly larger than the size of the diagram 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 describing business processes of enterprises

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

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 using the product?
what methodology should be used to describe processes?

Currently on Russian market There are quite a large number of CASE systems, many of which allow, in one way or another, to create descriptions (models) of enterprise business processes. It is obvious that the choice of system largely determines the entire further course of the project. 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;
capabilities of CASE systems for describing processes taking into account the requirements of clause 2.

It is pointless to talk about the advantages of a particular system/notation until the type and scope of the project and the main tasks that the project must solve have been determined. This study attempts to compare the most popular notations used to describe business processes and two systems that support these notations. It is expected that this study 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, a business process model should answer 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;
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.

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, because it can be analyzed and reorganized.

2. Description of the 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. The following table shows 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 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. The following figure shows the simplest eEPC model that describes a fragment of an enterprise’s business process.

Picture 1.

Figure 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, “triggering” the execution of Functions 2 and 3. The eEPC notation is built on certain semantic description rules:

every function must be initiated by an event and must end with an event;
Each function cannot contain more than one arrow that “starts” the execution of the function, and no more than one arrow can exit that describes 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.

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

Figure 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 invited to use standard attributes to describe objects or a limited number of so-called. custom attributes.

From Figure 1 it can be seen 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 cannot be visually reflected in eEPC. This leads to the fact that when creating models, situations are possible when one performer will be assigned to perform two tasks simultaneously. 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 MS 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). An example of models generated using ARIS eEPC is shown in Figures 3-4.

Figure 3.

Figure 4.

3. Description of IDEF0, IDEF3 notation

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. The IDEF3 notation was developed to more conveniently describe work processes (Work Flow), for which it is important to reflect the logical sequence of procedures. The IDEF0 and IDEF3 notations use the following objects.

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 requires adherence to clear rules. Detailed information about building models in IDEF0.3 can be found in standards and books (see literature).

A business process generated using the IDEF0 notation is shown in Figure 5. (This process is represented 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 ARIS eEPC notation in Figure 4.)

Figure 6.

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

4. Comparative analysis of ARIS and IDEF notations

A 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 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 indicate only the sequence of procedures, without worrying about reflecting control documents and information, the resulting models will have low value from the point of view of analysis and further use. Unfortunately, this is the error that is most common in practice. A Work Flow model is created, reflecting a simple sequence of procedures and incoming/outgoing documents, while control (control) influences on functions are not reflected in the model. Real management processes can remain “behind the scenes” by 30-90% (see example in the next figure).

Figure 7. Disadvantages of describing a business process in ARIS eEPC.

In Figure 7, 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 the questions:

how the control action is carried out on functions 2 and 3, 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 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 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, IDEF0 models 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 how the documents (information) regulating the implementation of process procedures will be reflected in the model.

5. Functionality of ARIS and BPWin products

The functionality of the ARIS Toolset and BPWin modeling tools can only be correctly compared in relation to a certain range of tasks. This study examines the problem of forming models (descriptions) of enterprise business processes. Each of the systems under consideration has its own advantages and disadvantages. Depending on the tasks being solved, these advantages can be enhanced or vice versa. The same applies to shortcomings: a system flaw within one project may not be a shortcoming within 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 described more adequately by eEPC ARIS than by IDEF0 or IDEF3 BPWin. A comparison of the systems' functionality is given in the following table.

Table 5.

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, but on the other hand, limits the ability to analyze model objects. Model Mart also provides database administration.

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, 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 in itself is valuable 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 that determines the success of a business process modeling project.

ARIS provides significantly more opportunities for working with individual model objects, but precisely due to the excessive number of settings, the work on creating a model must be regulated by complex, multifaceted documentation - the so-called. “Modeling conventions.” The development of these “Agreements” in itself is a complex, expensive task that requires significant 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 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 using business process modeling tools and their expert assessment on a 5-point scale are shown in the following table.

Table 6.

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

Figure 8.

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, implementation of a system of continuous improvement of business processes, ISO, TQM), ARIS is more suitable. In this case preparatory work The creation of regulatory documentation may take 1-3 months, but this is a necessary element for subsequent successful work.

Introduction. Typical tasks for describing business processes

and in 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;
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 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 can be indicated - “Position” and the names of the real employees occupying 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.

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 .

The semantics of constructing IDEF0 and IDEF3 models requires adherence to 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. 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 there is either the most important work, or the work performed 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.

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. Objects 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.

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.

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.

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

V. Repin, S. Maklakov

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

Introduction. Typical tasks for describing business processes

At 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 using 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;
the capabilities of CASE systems to describe processes taking into account the requirements of paragraph 2;
features of the information system being developed/implemented.

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

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. Example of a model in eEPC notation

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:

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.

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. 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 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”.

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 such international organizations 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	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	Mechanism arrow	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 which do not change 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

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 the 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

The functionality of the ARIS Toolset and BPwin modeling tools can only be correctly compared in relation to a certain range of tasks. This study examines the problem of forming models (descriptions) of enterprise business processes. 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 big projects storage of BPwin models in the Model Mart repository is provided (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.

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

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.

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)