Using eEPC notation for graphical description of business processes. Description of ARIS notations

Introduction. Typical tasks business process descriptions

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.

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 a particular system / notation until the type and scope of the project are determined, as well as the main tasks that this project must decide. 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.

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

ARIS Organizational Chart Notation

The Organizational Chart notation is one of the main ARIS notations and is designed to build charts. organizational structure enterprises. 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 last names real employees, which occupy 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 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. 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).

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.

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 of DFD notation are shown in Table. four . 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

Introduction. Typical tasks for describing business processes

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.

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.

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

Notations supported by BPwin 4.0

Description of IDEF0 and IDEF3 notations

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

Description of DFD notation

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

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

ComputerPress 1 "2002

In this section, we will review the ARIS methodology. Currently on the market for simulation tools business processes ARIS software of the same name is presented.
The ARIS methodology includes several different notations for describing the activities of an organization from different perspectives. The existing standards and specifications for describing processes and data, such as IDEF3, ERD, DFD, UML, etc., are integrated into the methodology. The basic concept of ARIS for describing an organization is shown in fig. 2.30.
Image in fig. 2.30 is often referred to as the "ARIS house". The approach of the ARIS methodology to the description of processes is based on considering the activities of the organization from four points of view: a look at the organizational structure, a look at data (flows and structure), a look at functions (functional hierarchies), a look at control and management (summary models of business processes) .
The ARIS methodology includes a large number of different notations that allow flexible creation of various models.

organizations. Among the most significant and practically used ARIS notation include: Value-added Chain Diagram notation (value-adding process chain diagram); eEPC, Extended Event-driven Process Chain (extended event-driven process chain notation) and PCD (process chain diagram) notations; notation Organizational Chart (organizational chart); Function Tree notation (tree of functions); Product Tree notation (product tree).
Rice. 2.30. The main types of models in the ARIS methodology

The strength of the ARIS methodology (from a formal point of view) lies in its complexity, which is manifested in the relationship of models built in different notations. The ARIS methodology allows you to describe the activities of the organization from different points of view, while the resulting models are to a certain extent interconnected. However, it should be emphasized that the main advantages of such an integrated approach: require for its implementation the availability of the ARIS tool environment, which is expensive and rather difficult to use, although there is also a free, simplified version of this product called ARIS Express;
are difficult to implement in practice, as they involve a large expenditure of resources (human, material and financial) for a long time. Value-added Chain Diagram (VAD) notation
On fig. 2.31 shows one of the most important ARIS notations - the Value-added Chain Diagram notation. A value-adding process chain diagram is used to describe the business processes of an organization at the top level. As a rule, consultants using ARIS recommend identifying six to eight top-level business processes and describing them in VAD notation. Then, the resulting top-level processes are decomposed, using either VAD or eEPC notation. Let's consider the main objects of the VAD notation shown in Fig. 2.31.
The main object of the VAD notation is the Value Added Chain. In fact, it is a process or group of organizational functions that serve to add value. Objects are connected to each other by a dotted arrow of type is predecessor of. This type of link indicates that one process is the predecessor of another. It is obvious, however, that in practice all basic processes are cyclical. In addition, they have feedback. Therefore, the term is predecessor of, in our opinion, is unfortunate.
Between the processes shown in Fig. 2.31, flows of material resources and information can be displayed. To describe them, you can use objects of type Cluster (to describe information) and Technical Term (to describe material flows). The Product/Service and Information Service object types are selected in this example to describe the infrastructure required to run the process. The choice of object types for displaying real flows is rather conditional. It is very important at the beginning of work on process modeling to determine which types of objects will be used and which objects real world they will display. So, in the example in Fig. 2.31 it would be possible to show all flows (information and material) using objects of type Technical Term.

Rice. 2.31. Model in Value-added Chain Diagram notation

On fig. Figure 2.31 also shows Organizational Unit objects that represent the organizational units that perform the corresponding processes.
Objects are interconnected using links of a certain type (Fig. 2.31). For example, the information flow displayed by the Cluster object is incoming to the first process, and it is associated with it using an arrow of type is input for ("is input for"). Another example is the executes relationship type between Value-added Chain and Organizational Unit objects. The type of relationship is used by indicates that the Product/Service is used by the process, etc. Thus, in the ARIS methodology, the most important requirements are the correct choice and further use of relationships and objects of a certain type.
On fig. 2.32 shows an example of a top-level model made in the ARIS VAD notation. You are already familiar with this process. On fig. 2.17 it is given in IDEF0 notation.
The principles of constructing a top-level process diagram in VAD differ significantly from IDEF0: in VAD, arrows can enter either side of the Value-added Chain object. (Recall that in IDEF0, each side of an Activity object (function) has deep meaning.)

3
O
§
O
O

On fig. 2.33 shows a situation that is possible in the VAD notation, when the process diagram contains a lot of feedback, the meaning of which is clear only to the analyst who created the model.
This disadvantage of VAD can be circumvented by stipulating in advance the possibility of special use of feedback, as, for example, in Fig. 2.34.
Rice. 2.33. Backlinks in Value-added Chain Diagram Notation

Rice. 2.34. An example of implementing feedback in the Value added Chain Diagram notation

Note that this approach may be criticized by ARIS specialists, as it contradicts the notation. But we're holding on
from the point of view that this is quite acceptable, since the top-level models in the VAD ARIS notation can actually be used only as the simplest way graphic image process chains.
Concluding the review of the ARIS VAD notation, we once again focus on the fact that this notation is more illustrative and is not intended to create complex models of processes at the top level of an organization. ARIS eEPC notation - extension of IDEF3 notation
The ARIS eEPC (eEPC - Extended Event Driven Process Chain) notation was developed by specialists from the German company IDS Scheer AG (Germany), in particular, Professor Scheer. In table. 2.3 shows the main objects used in the framework of the notation.
In addition to those listed in Table. 2.3 of the main objects, many others can be used when building 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 of the eEPC notation, consider the main types of objects and relationships used. On fig. 2.35 presents the simplest eEPC model that describes a fragment of an enterprise business process.
On fig. 2.35 it can be seen that the links 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 character that starts the execution of functions 2 and 3.
A careful analysis of the eEPC notation shows that it practically does not differ from IDEF3. The most important difference between eEPC is the presence of the "Event" object. This object is used to display in the model the possible results of the implementation of functions, depending on which one or another subsequent
process branch. The eEPC notation is called extended, obviously, precisely because of the presence of the "Event" object in it (there is no such object in IDEF3). On fig. 2.36 provides examples of the use of symbols of logic and events when building models in the eEPC notation.
Tab. 2.3. The main objects used in the ARIS eEPC notation

№	Namenova-. fields	Description	¦Graphic performance
/>1	Function	The "function" object is used to describe the functions (procedures, works) performed by departments / employees of the enterprise		* "" H function J
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)		ija^^tionaUi^it
4	Document	An object that represents real media, such as a paper document		document
5	Applied system	The object reflects the real application system used within the framework of the function execution technology	BUT	I yplication systjs J? M	m
5	Applied system
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.	gt;
8	Boolean "AND"		©
9	Boolean "OR"	A logical operator that defines relationships between events and functions within a process. Allows you to describe process branching	@
10	Boolean exclusive "OR"	A logical operator that defines relationships between events and functions within a process. Allows you to describe process branching	®

Rice. 2.35. ARIS eEPC notation

Rice. 2.36. The use of logical operators when building models in eEPC

When building a model in ARIS, eEPC must be observed following rules: each function is initiated and terminated by an event; Each function cannot enter more than one arrow, which starts the execution of the function, and exit more than one arrow, which describes the completion of the function.
Besides these, there are other important rules formation of models in ARIS.
On fig. 2.37 shows the use of various objects of the ARIS eEPC notation when creating a business process model.

J activates
alt="" />

On fig. 2.36 and 2.37 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 reflected visually. This leads to the fact that when creating models, situations are possible when one performer is 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. Other description tools can be used to obtain information about the actual duration of processes and visual display of the workload of personnel, for example, Gantt charts in the MS Project system.
Consider examples of using the eEPC notation to describe business processes.

On fig. Figure 2.38 shows the process of processing a customer's order (it is also depicted in IDEF3 notation in Figure 2.24).
The process starts with the event "Customer order received". It initiates the "Perform order posting in the system" function, which is carried out by the sales manager. For work, he uses the "Order Accounting System". The result of the function execution is displayed by the "Order posting completed" event.
After that, the sales manager implements the "Perform analysis for compliance with the nomenclature" function. The result is two alternative events: "The order matches the item" and "The order does not match the item". 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 correspond to the nomenclature, or if production is impossible. To display these options on the process diagram, the logical “OR” symbol is used, etc.
As can be seen from fig. 2.38, 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, but its size is much larger than the scheme in the IDEF3 notation.
The process discussed above can also be represented in the ARIS PCD (Process Chain Diagram) notation, a variation of eEPC. On fig. 2.39 shows the business process of processing a client request in PCD notation. When describing it, the same objects were used that make up the process in Fig. 2.38, but they are arranged in the form of a table. In the first column - events and some symbols of logic, in the second - functions, in the third - incoming and outgoing documents, in the fourth - types of applied software, in the fifth - the positions involved in the process. This representation of the process is more common. It is better suited for documenting processes.

However, the PCD notation has a significant drawback - it can be effectively used for simple (no more than five to eight functions), preferably linear processes. Complex processes, with branched logic, are inconvenient to display using PCD, which is clearly shown in Fig. 2.39.
Rice. 2.39. ARIS PCD diagram

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. 2.40.
Rice. 2.40. Model of the organizational structure of the enterprise
alt="" />

The model is built from the objects Organizational Unit, Position, Internal Person, etc. The types of relationships embedded in the notation allow you to reflect various types of relationships between objects of the organizational structure. In the one shown in Fig. 2.40 example "Enterprise" is managed by "Director", while using the type of communication is Organization Manager for. The hierarchy of subdivisions is built with the help of links is composed of. Positions can also be indicated - Position, the names of the employees occupying them - Internal person, the type of connection - occupies. In addition to subdivision hierarchy models, subordination hierarchy models can be built in project teams, groups, etc. All objects reflected in the models can be used later when building business process models. When building complex hierarchical
structures, decomposition can be used, for example, the structure of the unit is reflected in a more detailed diagram. ARIS Function Tree Notation
This notation is intended to form function tree models. An example of such a model is shown in Fig. 2.41. All functions in this diagram are connected by links. The most commonly used link types are execution-oriented superior and is process-oriented superior. The first type of connection is used to build a tree according to a functional attribute (description of the functions of a unit). The second type of connection is used when creating a tree of functions included in a certain business process.
Rice. 2.41. Function Tree Model

The function tree can be built according to functional, process and product principles. In practice, the first principle is often used - models of the hierarchy of functions of the unit are created. ARIS Product Tree Notation
On fig. 2.42 shows the ARIS Product Tree notation. It is designed to create product tree models. Models of this type can be used to describe the material inputs and outputs of a process.

Rice. 2.42. Product Tree Model

ARIS Information Flow notation
The Information Flow notation is an analog of DFD and is used when constructing diagrams of data or document flows between the functions of an enterprise's business processes. The simplicity of the notation limits the scope of its useful application. Its main objects are Function (also used when building business process models) and Information Flow - an information flow, as shown in Fig. 2.43.
Rice. 2.43. ARIS Information Flow Notation
information flow

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. Using multiple notations when creating process models in ARIS
When forming business process models in ARIS, as a rule, several types of notations are used. On fig. 2.44 shows a diagram of the application of models created in various notations.

Rice. 2.44. Using ARIS Notations When Creating Models

As a rule, work on describing the company's business processes in ARIS begins with the creation of a model of the organizational structure. At the same time (or later), models can be developed that describe the structure of the main material and information inputs and outputs. Using these models, top-level business process models are created in VAD notation. After that, models of the functions of departments and other auxiliary models (for example, a description of applied software systems) are developed. Then, process models are formed in the eEPC notation. eEPC models are built on the basis of already existing descriptions of the organizational structure, functions of departments, materials, systems, etc. The result of the work is a set of models that describe the activities of the organization from various points of view.
A feature of working in full-fledged software products for modeling business processes is that the software product creates a database of objects and their attributes. From one
On the other hand, this allows us to consider various aspects of the interaction of model objects by choosing one of the notations (Fig. 2.44). On the other hand, an "insignificant" error when creating links between objects in one notation can significantly distort the appearance of a diagram in another notation.

Business process modeling is one of the methods to improve the quality and efficiency of the organization. This method is based on the description of the process through various elements (actions, data, events, materials, etc.) inherent in the process. As a rule, business process modeling describes the logical relationship of all elements of the process from its inception to completion within the organization. In more complex situations, modeling may involve processes or systems external to the organization.

Business process modeling allows you to understand the work and analyze the organization. This is achieved due to the fact that models can be compiled for various aspects and levels of management. In large organizations, business process modeling is more detailed and multifaceted than in small ones, which is associated with a large number of cross-functional relationships.

Goals of business modeling:

Through simulation, it is possible to trace what happens in processes from start to finish. Modeling allows you to get an "outside" view of the processes and identify improvements that will increase their efficiency.
Rationing processes. Business process modeling sets the rules for the execution of processes, i.e. how they should be done.
Business process modeling establishes a clear relationship between processes and the requirements they must fulfill.

ARIS(acronym from the English Architecture of Integrated Information Systems) is a methodology and replicated software product for modeling business processes of organizations. The product and methodology are owned by the German company Software AG as a result of the takeover of IDS Scheer by the author of the methodology, August-Wilhelm Scheer.

The implementation of the methodology is supposed to involve a specialized software product providing joint work over descriptions and diagrams. The first version of the product was released in 1994. By the end of 2000, the product had been sold to 24,000 organizations. Since 2009, a free version of the tool has been supplied - ARIS Express.

The product provides a server part (ARIS Server) with a centralized repository stored in a relational DBMS and a series of user tools for maintaining objects and preparing graphical representations (ARIS Toolset in early versions, in versions of the 2000s - ARIS Business Architect, ARIS Designer).
By the mid-2010s, a public-cloud version of the product also appeared. Available at http://www.ariscloud.com/

The ARIS product is used in various projects for reengineering and optimization of business processes, IT projects such as the implementation and operation of ERP systems, in particular, there is a well-developed integration solution for SAP R / 3.

One of the illustrations of the ARIS structured approach to a reengineering project

ARIS software forms the basis of Oracle's Business Process Analysis Suite. Technically, the ARIS toolkit is quite simple to learn and has an intuitive interface. Models are copied and pasted into document files (for example, format Microsoft Word) in the form of drawings.

ARIS products provide the ability to create scenarios for automating the compilation of various analytical reports, normative documents, new models. Each script is a subroutine that runs in ARIS Business Architect (or Toolset - earlier version) or directly on the ARIS server. Scripts are written in a special programming language - SAX Basic. For the automated generation of a particular report in ARIS, scripts operate on data from the model database, isolating specific objects and models from it.

ARIS Script technology allows you to automatic mode produce:
formation of regulatory documents based on ARIS models (for example, a process passport, process regulations);
generation of analytical reports based on ARIS models;
integration of ARIS Toolset with other applications and databases;
Formation of the database of ARIS models based on ready-made specifications.

For example, any organization in the ARIS methodology is considered from five points of view: organizational, functional, processed data, structure of business processes, products and services. Moreover, each of these points of view is divided into three sublevels: requirements description, specification description, implementation description. To describe business processes, it is proposed to use about 80 types of models, each of which belongs to one or another aspect.

ARIS provides a visual toolkit for making models visible. The toolkit also comes with a set of reference models pre-designed for typical processes in various industries.

The general principle in the toolkit is the ability to integrate models different types within one repository by means of decomposition (detailing) of objects. Thus, any organization can be described using a hierarchy of models - from generalization: for example, VACD (English value added chain diagram) to the level of procedures and the resource environment of functions.

Among the large number of possible description methods, the following can be distinguished:

eEPC(English extended event-driven process chain) - event chain of processes
ERM(eng. entity-relationship model) - the "entity-relationship" model for describing the data structure;
UML(eng. unified modeling language) - unified object-oriented modeling language

The main elements used in the ARIS notation are:

organizational chart:
organizational unit;
"Person" symbol;
Symbol "Location";
Group of persons, role: «Role».
Process Landscape:
process.
business process:
Event - an event captures the state of certain parameters at a certain point in time;
activities - work, certain action, performed over a certain period of time;
Role - position in the organization;
IT system- Information system, a special case of "data storage"
Risks - risks;
Input and Output data - sender or receiver of data.
Process control via rules (and, or, xor) - crossroads ("and", "or", "exclusive or");
Process interface - a means of communication with the process in question.
data model:
Entity - entity (table);
Attributes - entity attribute (table field);
Primary Key - unique entity attribute (table primary key);
Foreign Key - foreign key of the table;
Relationship - relationships between entities (relationship between tables);
IT infrastructure:
IT system;
hardware;
network;
network components.
System landscape:
IT system;
domain.
dental diagramm

Available model types in Aris express:organization chart, process landscape, business process, data model, IT infrastructure, system landscape, BPMN diagram, whiteboard, general diagram.

Diagram example:

organizational chart

Process landscape (VAD)

Business process (EPC (event-driven process chain)

BPMN (business process modeling notation (BPMN 2.0))

BPMN notation describes conventions to display business processes as business process diagrams. BPMN is focused on both technical specialists as well as business users. To do this, the language uses basic set intuitive elements that allow you to define complex semantic constructs. In addition, the BPMN specification defines how diagrams describing a business process can be transformed into executable models in the BPEL language. The BPMN 2.0 specification is also executable and portable (that is, a process drawn in one editor from one manufacturer can be executed on a business process engine from a completely different manufacturer, provided that they support BPMN 2.0).

Cloud version of aris cloud includes 4 types of digrams: EPC, OC, VAD, application system type diagram

The free version of the program, i.e. ARIS EXPRESS supports only basic chart types, does not have multi-user support (ARIS CLOUD supports it), does not use a database, does not contain reporting tools and model analysis tools. ARIS Express does not support links between created objects, unlike the full-fledged paid version, that is, there is no control over the integrity and consistency of the model. This means that when editing one model, the program will not make corresponding changes to another model, and will not check whether there are positions indicated as responsible in the process, etc.

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

It might be useful to read: