Description of the notation ARIS Neck. Modeling business processes using ARIS (Express and Cloud)

business model notation

Notation ARIS EEPC.

The notation of ARIS EEPC is decrypted as follows: Extended Event Driven Process Chain is an extended notation of a process chain description managed by events. Notation developed by IDS Scheer AG (Germany) specialists, in particular Professor Sheer. In tab. 1 The objects used in the framework of notation are given.

Table 1. EEPC notation objects

Name	Description	Graphic representation
	The function "Function" is used to describe the functions (procedures, works) performed by divisions / employees of the enterprise
	The Event Object is used to describe the real states of the system that affect and manage the performance of functions.
Organizational unit	Object reflecting various organizational links of the enterprise (for example, management or department)
Document	Object reflecting real storage media, such as paper document
Applied system	The object reflects the real application system used in the framework of the function execution technology
Information cluster	The object characterizes the data as a set of entities and connections between them. Used to create data models
Communication arrow between objects	The object describes the type of relationship between other objects, such as activation of the execution of the function by some event
Logical "and"
Logical "or"	Logical operator defining links between events and functions within the process. Allows you to describe the branching of the process.
Logical excluding "or"	Logical operator defining links between events and functions within the process. Allows you to describe the branching of the process.

In addition to those specified in Table. 1 Basic Objects When constructing an EEPC diagram, many other objects can be used. The use of a large number of different objects associated with different types of connections, significantly increases the size of the model and makes it poorly readable. To understand the meaning of the EEPC notation, it suffices to consider the basic types of objects and links. In fig. 1 shows the simplest EEPC model describing the fragment of the business process of the enterprise.

Fig. one.

In fig. 1 shows that the links between objects have a certain meaning and reflect the sequence of functions within the process. The arrow connecting the event 1 and the function 1, "activates" or initiates the execution of function 1. The function 1 "creates" event 2, followed by a logical "and" symbol, the execution of functions 2 and 3. The EEPC notation is built on certain semantic Description Rules:

1. Each function should be initiated by the event and must end with the event;
2. In each function, a more than one arrow, "running" execution of the function, and exit no more than one arrow describing the completion of the function.

In addition to these rules, there are other important rules 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. 2 shows the use of various ARIS objects when creating a business process model.

Fig. 2.

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

From fig. 1 shows that the EEPC business process is a sequence of procedures located in the order of their execution. It should be noted that the real duration of the procedures in EEPC cannot be reflected visually. This leads to the fact that when creating models, situations are possible when the simultaneous execution of two tasks will be assigned to one performer. The logic symbols used in constructing the model allow you to reflect the branching and merging of the business process. For information about the real duration of the processes, you must use other description tools, such as Gantt graphics in the Microsoft Project system.

Thus, using the EEPC ARIS notation, you can describe a business process in the form of a stream of consistently performed work (procedures, functions). Examples of models formed using ARIS EEPC are shown in Fig. 3 and 4.

Fig. 3.

Fig. four. Description of the analysis and approval of the application of the Client

V. Repin, S. Maklakov

Analysis of the activities of enterprises and the reorganization of business processes is an extremely difficult task requiring methodical and tool support. Recently, CASE tools BPWIN (Computer Associates) and ARIS Toolset (ARIS) are becoming increasingly popular among business analysts. This article provides a brief comparative analysis of these funds and recommendations for their use.

Introduction Typical tasks descriptions of business processes

In the early stages of projects, the purpose of which is the reorganization of business processes and the implementation information systems, managers and specialists most often arise the following questions:

what results from the point of view of improving the organization's activities can be achieved using technologies and reorganization of business processes;
what software is used in the project ("ARIS is better BPWIN?", "Erwin is better ARIS?", etc.);
how to model processes using the product "x";
how to analyze and identify problems with the help of the product "X";
which methodology is used to describe processes;
what to do next with the obtained business processes models.

Currently on russian market A sufficiently large number of CASE systems are presented, many of which allow one way or another to create descriptions (models) of business processes of enterprises. At the same time, there are systems oriented primarily on the creation of models of processes and uncomfortable or not intended for creating data models and settings. Obviously, the choice of the system is determined by the objectives of the project and significantly affects its entire further move. The rational choice of the system is possible when an understanding of the company's management and its specialists of several aspects:

project goals;
information requirements characterizing business processes and necessary for analysis and decision-making by the speeds of a particular project;
the capabilities of the CASE systems on the description of the processes, taking into account the requirements of paragraph 2;
features of the developed / implemented information system.

Talking about the advantage of one or another system / notation is meaningless until the type and framework of the project, as well as the main tasks that this project must decide. Our article attempts to compare the most popular notations (designations adopted during modeling) used to describe business processes, and two systems that support these notations. It is assumed that this material will serve as a basis for a discussion on the problems of effective application of CASE systems for describing and analyzing enterprise business processes.

A description of business processes is carried out in order to further analyze and reorganize them. The purpose of the reorganization can be the introduction of an information system, reducing the cost of production, improving the quality of customer service, the creation of official and working instructions when implementing ISO 9000 standards, etc. For each such task, there are certain parameters that determine the set of critical knowledge according to the business process. From the task of the task of the requirements for the description of business processes may vary. IN general The business process model should give answers to the following questions:

what procedures (functions, work) must be performed to obtain a given end result;
in which sequence these procedures are performed;
what control and management mechanisms exist within the framework of the business process under consideration;
roles and responsibility - who performs process procedures;
what incoming documents / information use each process procedure;
what outgoing documents / information generates a process procedure;
what resources are needed to perform each process procedure;
what documentation / conditions regulate the implementation of the procedure;
what parameters characterize the execution of procedures and the process as a whole;
there is a sequence of processes, minimizing costs (including cost, time, etc.);
as far as the process is supported / will be supported by the information system.

Description of the business process is formed by notation and tool media to reflect all the above aspects. Only in this case the business process model will be useful for the enterprise, as it can be analyzed and reorganized.

Notation ARIS EEPC.

Table 1. EEPC notation objects

	Name	Description
1	Function	The function "Function" is used to describe the functions (procedures, works) performed by divisions / employees of the enterprise
2	Event	The Event Object is used to describe the real states of the system that affect and manage the performance of functions.
3	Organizational unit	Object reflecting various organizational links of the enterprise (for example, management or department)
4	Document	Object reflecting real storage media, such as paper document
5	Applied system	The object reflects the real application system used in the framework of the function execution technology
6	Information cluster	The object characterizes the data as a set of entities and connections between them. Used to create data models
7	Communication arrow between objects	The object describes the type of relationship between other objects, such as activation of the execution of the function by some event
8	Logical "and"
9	Logical "or"	Logical operator defining links between events and functions within the process. Allows you to describe the branching of the process.
10	Logical excluding "or"	Logical operator defining links between events and functions within the process. Allows you to describe the branching of the process.

Fig. 1. Example model in EEPC notation

each function must be initiated by the event and must end with the event;
in each function, more than one arrow, "running" execution of the function, and exit no more than one arrow, describing the completion of the function.

In addition to these rules, there are other important rules for the formation of models in ARIS. These rules can be studied using the Methodological material "ARIS methods", which is installed on the computer simultaneously with the demo version of the product.

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

Fig. 2. An example of the use of ARIS objects to describe business processes

Fig. 3. Description of the process of customer service

Fig. 4. Description of the analysis and approval of the application of the client

Notation ARIS Organizational Chart

The notation of Organizational Chart is one of the main notations of ARIS and is intended to build the enterprise organizational structure schemes. As a rule, this model is built at the beginning of the project to model business processes. The model reflects the existing divisions of the enterprise in the form of a hierarchical structure, as shown in Fig. five.

Fig. 5. Model of organizational structure of the enterprise

The model is built from ORGANIZATIONAL UNIT, "POSITION", "INTERNAL PERSON", and others. The types of links are allowed to reflect different kinds relations between the objects of the organizational structure. In the presented in Fig. 5 Example "Enterprise" is managed by the "Director", while using the Type of Communication "IS Organization Manager For". The hierarchy of units is based using the "IS Composed Of" links. In addition, posts can be indicated - "Position" and surnames real employeesThey occupy them: "Internal Person", as well as the type of communication "Occupies".

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

Notation ARIS Information Flow

The notation of the information flow is an analogue of DFD notation (see below) and is used in constructing data stream diagrams or documents between the enterprise business process functions, as shown in Fig. 6.

Fig. 6. Fragment of the ARIS Information Flow chart

Simplicity of notation limits its areas useful use. The main objects of the notation are "FUNCTION" (used also when building models of business processes) and "Information Flow" - an information flow (Fig. 7).

Fig. 7. Notation ARIS INFORMATION FLOW

When building models of business processes, the EEPC model can first be constructed, and then, using the functions defined during the functions, is a model of information flows.

Notations supported by BPWIN 4.0

Description of the notations IDEF0 and IDEF3

The notation of IDEF0 was developed on the basis of the SADT structural analysis and design methodology, approved as the US standard and successfully operated in many projects related to the description of enterprises. IDEF0 was extremely widespread and is, in particular, the standard in international organizations such as NATO and the IMF. The notation of IDEF3 was developed to more conveniently describe working processes (workflow) for which it is important to reflect the logical sequence of procedures. The objects of the notations IDEF0 and IDEF3 are shown in Table. 2 and 3.

Table 2. EEPC notation objects

	Name	Description
Notation IDEF0.
1	Work (Activity)	The object is used to describe the functions (procedures, works) performed by divisions / employees of the enterprise. Depicted by a rectangle. The job name must display the process, action. In order for the work to be modeled, there must be some time from the beginning before the end of work and should be spent any resources.
2	Entry arrow	The arrow is drawn in the work in the left and describes incoming documents, information, material resources necessary to perform the function and varying work
3	Outlet arrow	The arrow is drawn outgoing from the work on the right and describes the results of the performance - outgoing documents, information, material resources. In the notation IDEF0, each procedure must necessarily have at least one output arrow
4	Arrow control	The arrow is drawn in the work on top and describes the control effect, such as a disposal, a regulatory document, etc. In the notation IDEF0, each procedure must necessarily have at least one control arrow
5	Arrow mechanism	The arrow is drawn the incoming operation from below and describes the so-called mechanisms, that is, the resources necessary to perform the procedure, but not changing its state in the process. Examples: employee, machine, etc.
6	Arrow challenge	The arrow is drawn outgoing from work down and is a reference to another model of work. In BPWin, this arrow is used to merge and splitting models

Table 3. Idef3 notation objects

	Name	Description
Notation DFD.
1	Work	The object is used to describe the functions (procedures, works) performed by divisions / employees of the enterprise. Depicted by a rectangle. The name of the work should display the process, action
2	Referent Link Object	Object used 1) to describe references to other diagrams; 2) references to other works; 3) references to objects; 4) to explain the logic of the branching of the arrows at the intersections; 5) various comments for functions and intersections
3	Crossroads	Logical operators (5 types - synchronous and asynchronous "and", synchronous and asynchronous "or", excluding "or"), defining the relationship between the functions within the process. Allow 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 information flows and objects

The semantics of the construction of IDEF0 and IDEF3 models involves compliance with clear rules. Full description of IDEF standards can be found on the site http://www.idef.com/.

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

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

One of the features of the description of the processes in the notation IDEF0 is a clear detection of advantages and disadvantages of business processes. Works on the IDEF0 diagram are located in the order of dominance - from the upper left corner of the chart to the lower right. In the upper left corner is located either the most important work, or the work performed first. The arrows bind work, and five types of connections differ. The arrow directed from the exit of the superior work on the entrance or control of the subordinate, is a direct connection; The arrow directed from the output of the lower operation to the input or control of the higher, is feedback. No feedback, work without output or control, duplicate work indicate the imperfection of business processes.

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

Fig. 9. An example of a description of the business process in the notation IDEF3

In the notation IDEF3, as well as in notation Aris EEPC, the logic symbols reflecting the branching of the process are used. The Idef3 notation chart allows you to present the entire process, and the sequence of operations and the process execution logic is tracked.

Description of notation DFD

Notation DFD is designed to describe information flows in the organization's surveyed. DFD notation objects are shown in Table. 4. The presence of "data warehouse" objects and bidirectional arrows allows you to most effectively describe the workflow and the requirements for the information system.

Table 4. DFD Notation Objects

	Name	Description
Notation DFD.
1	Work (Activity)	The object is used to describe the functions for processing information performed by divisions / employees of the enterprise
2	Link object	The reference object simulates an object affecting the outside system
3	Data store	The data warehouse simulates the storage location - archive, database, repository, etc.
4	Arrow	The arrow shows the flow streams, the movement of documents moving together as one package. The arrow may be bidirectional, that is, it shows the flow of information on this route in both directions

In fig. 10 shows the example of the DFD diagram.

Fig. 10. Example Description of Document Management in DFD Notation

For a more detailed description and design of the information system, in conjunction with BPWin, an ERWIN - CASE means can be used to create and recreate the data model. Communication of the BPWIN Process Model and ERWIN data models are made by importing the dictionaries of entities and attributes from Erwin in BPWIN. In the model of processes, each arrow can be assigned a set of entities and attributes, and each operation is a set of data use rules. Such interrelation of models of processes and data allows you to describe in detail the compliance of the data and their consumers and thereby eliminate errors that may arise when creating and implementing information systems.

Organizational Charts (Organizational Chart) in BPWIN 4.0

BPWIN organizational charts are an analogue of Aris organizational diagrams and the same as in ARIS are intended to describe the subordination hierarchy in organizations.

Fig. 11. Example of organizational diagram in BPWIN

To create an organizational diagram in BPWin, you must first in the dictionaries to make the following information.
Images (Bitmaps), if the organizational diagram is supposed to use icons.
Role groups - can match structural unit. In the example in fig. 10 shows the roles of the roles "Directorate", "Accounting" and "Shop number 1".
Roles - may correspond to positions. In the example in fig. 10 shows the role "gene. Director, "Accountant", "Technologist", etc.
Resources - can correspond to the name of a particular person.

After creating a BPWIN dictionary allows you to create a subordination hierarchy with the help of dialogs, including role groups, roles and resources. In the IDEF0, IDEF3 and DFD diagrams of each work, a resource vocabulary can be appointed. Roles and resources can also be used when creating a SWIM LANE diagram - a variety of IDEF3 diagram, on which the area of \u200b\u200bresponsibility of employees of the enterprise in the form of technological operations is shown in the form of separate bands.

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

Table 5. ARIS notation objects, IDEF0 and IDEF3

	Criteria comparison
1	Principle of Construction Chart / Process Logic		The principle of domination (see IDEF0 standard)	Temporary procedure
2	Process procedure description	Object on a diagram	Object on a diagram	Object on a diagram
3	Incoming document
4	Incoming information		Input arrow, control arrow	A separate object is used to describe (object reference type OBJECT or Object Flow arrow)
5	Outgoing document	A separate object is used to describe ("Document")	Outlet arrow	A separate object is used to describe (object reference type OBJECT or Object Flow arrow)
6	Outgoing information	A separate object is used to describe ("Cluster", "Technical Term")	Outlet arrow	A separate object is used to describe (object reference type OBJECT or Object Flow arrow)
7	Contractor	A separate object is used to describe ("Position", "Organizational Unit")	Arrow mechanism
8	Used equipment	A separate object is used to describe	Arrow mechanism	No (can be reflected in the model only linking object link)
9	Procedure Management	Not. Can be reflected only by the characters of logic and events (procedure sequence) and / or indicating incoming documents	Arrow control	Only the temporary sequence of procedures and process logic
10	Control procedure	Not. Can be reflected by the indication of incoming documents	Arrow control	No (can be reflected in the model only linking object link).
11	Feedback on Management / Control		Arrow control	Not
12	Feedback on the entrance	Not. Can be reflected only by logic symbols (procedure sequence)	Entry arrow	Not

One of the most important aspects of the description of business processes models is reflected on the model of control influences, feedback on control and management of the procedure. In the notation of ARIS EEPC, the procedure management can be reflected only by specifying incoming documents that regulate the procedure and sequence of procedures in time (launching events). Unlike ARIS, in the notation of IDEF0, each procedure must have at least one control action (control input - the arrow from above). If, when creating a model in EEPC, only the sequence of procedures, without taking care of the reflection of control influences (for example, documents and information), the obtained models will have a low value from the point of view of analysis and further use. Unfortunately, this error is most common in practice. The Workflow model (work flow) is created, reflecting a simple sequence of procedures and incoming / outgoing documents, while the control (control) effects on functions in the model are not reflected.

In fig. 12 Function 4 is the control and serves to check the results of operation performed by functions 2 and 3. But this model Does not answer questions:

how does the control effect on the function 2 and 3? It is shown only the fact that in the course of the process is possible and re-executing 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 humidity), regulate the performance of functions?

Fig. 12. Disadvantages of business process description in ARIS EEPC

If you try to reflect all the conditions and limitations that determine the performance of functions, it will be necessary to describe a large number of events and incoming information (for example, the oral orders of managers) and the model will become complex and poorly read (these shortcomings are also inherent in IDEF3 notations). These disadvantages are absent in the notation IDEF0. At the same time, the models in IDEF0 does not provide for the use of process logic characters.

Thus, the notation of ARIS EEPC is the expansion of a fairly simple notation of IDEF3. For an adequate description of the management process in the notation of EEPC, it is necessary to agree on how the documents will be reflected in the model (information) regulating the implementation of the process procedures.

Functionality ARIS and BPWIN products

Functionality tools modeling Aris. Toolset and BPWin can be correctly compared only with respect to a certain circle of tasks. IN this study The task of forming models (descriptions) of the enterprise business processes is considered. Each of the systems under consideration has its advantages and disadvantages. Depending on the tasks being solved, these advantages can both amplify and disintegrate. The same can be said about the shortcomings: the disadvantage of the system within a single project may not be such within the framework of the other. For example, the lack of clear agreements on modeling management impacts within the EEPC ARIS can lead to the creation of models that do not meet the questions, while the BPWin Idef0 does not meet this task. On the other hand, a procedure performed by one employee may be more adequately described using EEPC ARIS than using IDEF0 or IDEF3 BPWIN. Comparison of the functionality of the systems is provided in Table. 6.

Table 6. Comparison of the functionality of ARIS ToolSet 5.0 and BPWIN 4.0

	Opportunity / Instrumental Wednesday	ARIS ToolSet 5.0.	BPWIN 4.0.
1	Supported standard	(Partly - DFD, ERM, UML)	IDEF0, IDEF3, DFD
2	Model 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		Not. The size of the database is limited by computing resources.
4	Possibility of group work	There is. Used Aris Server	There is. Used Modelmart
5	Restriction on the number of objects in the diagram	Not	For DFD and IDEF3 - no. For IDEF0 limited notation recommendations
6	The possibility of decomposition	Unlimited decomposition. Possible decomposition for various types of models	Unlimited decomposition. Possible transition to another notation in the decomposition process
7	Model presentation format	Not regulated	Standard Blank (frame) IDEF with the possibility of its disconnection
8	Convenience of creating models	Complex control panel, there is an alignment of objects, there is Undo	Simple control panel, no level alignment, no undo
9	UDP - user-defined object properties	Large, but limited number of properties; The number of types is limited	The number of UDP is not limited. The number of types is limited (18)
10	The ability to analyze the cost of processes	There is. Ability to use ARIS ABC	Simplified ABC is an analysis of the cost of use in the process. Ability to export to Easy ABC
11	Generation reports	Creating reports based on standard and custom Visual Basic macros	RPTWIN, the ability to visual reporting, including the calculation of the formulas using UDP
12	The complexity of the development of non-standard reports	Complicated	Simply
13	Export reports		Implemented Report Exports in MS Office, Text File, RTF, HTML
14	Communication with the data model	The ability to build ERD diagrams, additional software must be exported.	Implemented with the ERWIN data model. Each arrow can be put in line with entities and attributes
15	Data Access Description	Not	Each work may describe the rights to use data. The data model object can be created directly in the BPWIN environment.
16	Description of the accompanying documentation	There is support OLE	Using a UDP type Command with each arrow associates any document that can be downloaded using Windows - Applications. Running application is carried out directly from the BPWIN environment

Comparing two systems, it should be immediately noted that the object DBMS is used to store models in ARIS and a new database is created under each project. For the convenience of the user's user (models) can be stored in various groups, organized depending on the specifics of the project. It is quite natural that the ARIS provides various database administration functions: access control, consolidation, etc. In BPWin, these models are stored in the file, which significantly simplifies the work on the creation of the model. For group work on large projects, it is provided for the storage of BPWIN models in the Model Mart repository (comes separately). Model Mart is a storage of models for BPWIN and ERWIN and uses relational DBMS Oracle, Informix, MS SQLServer, Sybase). It provides administration, including the delimitation of access rights to the level of the model of the model, the comparison of versions, fusion of models, etc.

Often one of the disadvantages of BPWIN supporters ARIS call a limit on the number of objects on the chart. However, the experience of real projects shows that for the project, the results of which can be actually used (criterion - disorder), the number of objects in the ARIS database or the BPWIN model is 150-300. This means that with 8 objects on the same 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 actually impossible to use. 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. Oddly, in the field of directors of companies, the conviction is common in the fact that a detailed description of the processes in itself is value and can solve many problems. But it is far from the truth. It is an understanding that it is necessary to describe and what aspects of the functioning of the real system to reflect, determines the success of the project to model business processes.

Aris provides substantially more opportunities for working with individual objects of the model, but precisely as a result of the excessive amount of settings, work on the creation of a model should be regulated by complex, multidimensional documentation - the so-called modeling agreements. The development of these agreements in itself is a complex, expensive and requiring considerable time (1-3 months) and qualified specialists. If the project using ARIS begins without a detailed study of such agreements, the probability of creating models of business processes that do not respond to the questions raised is 80-90%. In turn, BPWIN is easy to use and sufficiently strict regulation when creating diagrams (IDEF standard and recommendations for its use, the IDEF form to create a diagram, a limited number of required fields, limit the number of objects on one diagram, etc.). ARIS is definitely a more "heavy" tool compared to BPWIN, but in the end it turns into significant difficulties and high costs for its operation.

Various situations of the use of instrumental means of modeling business processes and their expert score 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 modeling tasks of business processes

Task / Instrumental Wednesday	ARIS ToolSet 5.0.
One-time project to describe business processes, for example: description of one business process in terms of control and management; description of functionality new system top-level management	3	5
Long (continuous) project to describe the company's activities from various points of view (organizational structure, document structure, large amount of processes database, etc.)	5	4
Development of an automation system: description of the functionality of the system; creating a logical data model; communication of the processes and data model; creating a physical data model; generating application code.	3 3 - -	5 BPWIN + ERWIN + PARADIGM PLUS

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

Fig. 13. Evaluation of the effectiveness of ARIS Toolset and BPWIN

Thus, for maintaining small scale (small and medium enterprises, 2-5 people in the group of consultants) and duration (2-3 months) of projects rationally use BPWIN. For large and / or long projects (for example, such as the implementation of a continuous improvement system of business processes, ISO, TQM) is more suitable for ARIS. It should be noted that the ARIS ToolSet system is inconvenient 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 of subsequent successful work.

Website www.finexpert.ru
Web site
Website www.idef.com
S.V. Maklakov. BPWIN and ERWIN. CASE-tools for the development of information systems. Moscow: Dialog Mafi, 2000, 256s.
YES. Marka, K. McGouen Methodology of structural analysis and design. Moscow, 1993.
"ARIS methods." PDF file, more than 1000 pages comes with the demo version of the ARIS Toolset system.
August-Wilhelm Sheer. Business processes: basic concepts, theories, methods. Moscow: Enlightener, 1999.

Any thing is the form of manifestation of infinite diversity.
Goat rods

Introduction to the notation EEPC

Currently, there are many different principles of the graphical presentation of business processes referred to as notations. Why are there many of them? This question has been asking for a dozen years anyone who faces the need to describe business processes. Let's deal with the reasons. Their three (in my opinion):

Different tasks. Not all notations are equally convenient for solving various tasks. For example, the notation can be convenient for the top-level business process and not at all convenient to describe the workflow.
Different developers of such notations. At various times, different developers tried to come up with new principles for describing schemes. They did it from good motivations when in practice came across the situation when the notation used by them cannot reflect the necessary subtleties (or not visual). Sometimes in the process of evolution, such notations became parallel, i.e. They look different, and tasks decide the same.
The desire to stand out. This is when for incomprehensible reasons suddenly a new notation appears, which does not have anything outstanding, but for some reason, who moves it to its creator as an excellent know-how. This happens so far.

The purpose of this article is not to consider all kinds of notations (I consciously do not call their names), but to stay on a detailed description of the notation that I chose for my projects in the process of long searching the most optimal option.
If someone is interested to know what other notations are and for what they are used, I plan to do this in another article, which will be called "talk about notations", but it is still in the plans.
It is time to start our story about very interesting, simple and practical EEPC notation (translated: an extended description of the event chain of processes). In its literal translation, the main purpose is revealed: a description of the chain of business processes. The main "chip" of notation in its principle of "events", which we consider in detail.
What advantages has a notation EEPC:

First, it is not quite notation in its pure form. Those. If in some notations there is a hard set of elements and rules to use (otherwise everything is confused), then the EEPC principle allows you to add your own elements. How is it provided? Of course, there is a certain "rod", around which everything is built, i.e. A set of clear rules for which a scheme is built and for which it is then read. In addition, you can add your own item, to include the rules for its use in your own corporate standard (to eliminate the amateur that can confuse the scheme and complicate its readability) and everything! This is a very important point. In addition, in its corporate standard, any other restrictions and rules can be asked.
eEPC contains logic elements. This allows you to build schemes with the conditions that need to describe activities ("if the contract is agreed, then ...., otherwise ...")
Easy elements allows you to draw diagrams as in software productsSo and in any other way, at least on paper, you do not confuse.
eEPC is so easy in learning and perception, which can be used in real activity, and not just dust in the closet. The training rules will need about 2 hours (with the desire of the student).

Of course, like everything in this world, it has the disadvantages. But rational use reduces them to a minimum. The main drawback, in my opinion, is the fact that if you use simple tools (i.e., programs for drawing schemes, and not for modeling business processes), then we do not have a single database of objects. In addition, it is difficult to control the inputs-outputs (it is necessary to control them, i.e. come up with a way of such control, if required). But, on the other hand, the use of modeling tools of complex business processes is very impressive sums, and the project with their use is measured in millions. And so we have a very economical and understandable tool. To speak more precisely, this flaw belongs to the method of description under consideration, i.e. Using MS Visio or similar software. If you are the use of specialized business process description systems that support object databases, this shortage can be avoided. Well, it's time to start ...

Chief "Rod" notation EEPC

As I mentioned, in the literal translation of the EEPC abbreviation, the concept of events lies. This is a very important point on which the whole principle of constructing a scheme is built. So, there are two key concepts: "Event" and "Function". When someone for the first time try to draw your own process in the form of the EEPC chart, then the question often arises, and what is the difference between the event from the function? This must be clearly understood, otherwise it will be an unpredictable result. So: the event is the fact of the accuracy of something, and not having a duration in time, or this time strives for zero (or does not matter). Moreover, the event always causes the need to execute the function, and the execution of the function always ends with the event will explain on the example. The phone rings. The manager took the phone for a telephone conversation. In this case, the phone calls "is an event. Telephone call - This is a function. The conversation is completed (hanging the phone) -sno event. Thus, the event chain is observed: the call is the conversation - the end of the call. And the termination of the call will certainly require the execution of a new function: recording the result of the call, etc.
Let's try to draw it. First you need to find out how the Event and Function elements are displayed.

These two simple elements form the basis of the rules for describing business processes in the notation EEPC. I think I must say a few words about the colors used. If you have come across the description of the processes in other notations, as a rule they were black and white. And it is correct, the explicit dependence of the content from the color should not be, because The scheme can be drawn by a pencil on paper, printed on a black and white printer, etc. In this case (in the EEPC stations), it is so historically developed that the elements have certain colors. Not to say that it was necessarily, but the habit is produced, and perception in in electronic format Better - it is immediately clear that there is something. These colors can be viewed as a recommendation. Why are they like that? I'm definitely not sure, but it seems to me that the ARIS company, when I made the EEPC notation support in my product, gave them such colors, they "got together." By the way, sometimes this notation is also called "ARIS", "ARIS EPC", which is not quite true, because ARIS has not invented this notation, and has made it support in its business processes modeling program. In general, I recommend using colors. The main thing is that the form of the elements is not the same (i.e. differ only in color), because In the black and white version it can cause confusion. There are other rules that allow the "slim" by the EEPC diagram, we will talk about them.
So, there is an event, there is a function. How are they connected?
We see that event1 led to the need to perform some function that ended event2. If applied for example with a phone call, it will be like this:

Configuration Event - Function - Event is usually displayed from top to bottom to one line either from left to right. The chain direction is indicated by the binding lines with arrows.

In order for the scheme to be more visual, notation provides for some more standard items:

Position (executor). Feature
Information. Any information used to perform a function except documentary. For example, a phone call, instructions for performing operation that
Document. The "Document" element is designed to display media (paper or electronic). Those. Representing information in a specific structure.
Program (application). Software used to perform a function.

All other elements are auxiliary, and practically not regulated by the requirements of the EEPC itself. However, there are no obstacles in order to add your own elements. The main thing is to fix it in the internal standard so that there is a single understanding, as they look and why apply. Such an extension does not violate the requirements if the bunch of an event-event function is not disturbed, and is intended only for improving the perception of information or adaptation of the rules of description in any industry specificity. I added my set of elements about which I will tell below.
It is still required to find out how the items considered should be located. All these elements must somehow be associated with the function. it general rule: No element is associated with the event, except for the function.Those. All these elements must be connected by arrows with a function. As for the arrows and their directions: it is considered that if there is no direction of information transfer, then simply line is displayed instead of the arrow. If the information enters (enters the input), then the direction of the arrow from the object to the function, if it turns out, then on the contrary.
A few words about the place of finding these elements in the diagram and you can redraw our scheme, specifying the execution of the call processing function. There are no harsh requirements for the location of the elements, but it is customary to display them in all the schemes equally (for monotony and harmony of the scheme). To unify the most type of graphic schemes of business processes, such rules must be consolidated in the internal standard and follow them. A little later, I will give some recommendations about this.
Now redraw our scheme:

We see that the operator performs the processing of an incoming call, acting in accordance with the processing rules of incoming calls and uses the CRM program for this. Nor incoming nor outgoing documents are not used.
As I mentioned, the elements of logic are one of the strengths of the notation. At the same time, it is one of the most difficult to understand the moments. Therefore, at first I will give an example, and then we will separately understand the elements of logic.
Let in our example it will be like this: in the case of the client's interest, the sales manager is still carried out with him and exposes offerwhich emails using the MS Outlook email client. If there is no interest, then the call processing is completed. In real life, it would be good to use the rules for completing the call, but this is me so, by the way, while it simplifies. This is what happens:

Logic elements in EEPC notation schemes

Elements of logic are simple, but there are features and rules so that the scheme is logical and unambiguously interpreted. The most important rule to which 100% must be adhered to: logical solutions can only be accepted when performing functions.aI. Those. After some event can not be branching. Why? Because in this case it contradicts the very concept of event - it is simple and instantaneous, without execution time. For example, if the phone rang, and a person sits thinks, take him a phone or not to take, theoretically, it will already be a function where he makes a decision. And practically, including out of common sense, it violates the rules for processing calls, because He pays a salary for treating these calls, and there is nothing to argue here (in general, as painted in the scheme).
In total, 3 logic elements differ:

AND. When two or more events occur at the same time;
OR. When a few events may occur, but at least one must be sure to happen;
Excluding or. Either one or another. Those. Two options are simultaneously impossible.

Here's how one looks like:

As you can see, there are two options for graphic representation of logic elements. They do not differ anything, completely alternative. I brought them both, because In practice B. various sources You can see both options. Which one to use, solve you. I like the first one.
Now it is necessary to deal with the use of logic elements. First consider the encountered options, then proceed for example. We will analyze each element separately.
Logical element "and".

When the function requires simultaneous execution of several events:

Example: If the reporting period is closed (event 1) and the deadline for submission to the head (event 2) has arrived, the employee is preparing a monthly report.

The connection of the items, if, when executing a function, there are several events:

Example:Completed some work with the customer. At the same time, two events were recorded: mutual settlements are drilled (Event 1), the act is signed (Event 2).

In practice, such an application is not often found. As a rule, if a lot of actions are combined in one function.

The connection of the elements, if, when performing multiple functions, an event occurs:

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

The connection of the elements if the occurrence of one event leads to the execution of several functions:

Example: A lot of goods arrived (event). At the same time, the shipment of the goods previously ordered by customers and the placement of the remaining in the warehouse begins.

Logical element "or".
The connection of the elements, if one of the events may cause the function:

Example: Application received on the phone (event 1) or the receipt of the application for e-mail (Event 2) will need to process it.
Connecting elements if one function can cause at least one event:

Example: The product was prepared and sent to send the client. The account could be sent by mail (Event 1), by fax (event 2).

The connection of the items when the execution of several functions will cause an event:

Example:Service (Function 1) was provided or sold goods (Function 2), an arrears of the client arose (Event 1).

Logical element "excluding or".

The connection of the elements when one and only one of the events is required to perform the function:

Example:The client came to the store personally (event 1) or made an order via the Internet (Event 2). You need to ship goods (Function 1).

The connection of the elements, if, as a result of the execution of the function, a maximum of one of the events occurs:

Example:The solution is either accepted or not.

Connection of elements if withclearance will occur after one and only one of the functions is performed.

Example: Delivery of goods carried out (event 1) or its own transport (function 1), or transport company (Function 2)

The correct application of logic elements requires a certain practice. But it is not difficult. It should be noted that not all considered combinations are widely applied in practice (and in general it is determined by the analyst thinking).

Try to apply logic items in practice. If there are difficulties, email me, I will try to help.

Expansion of notation with its own elements

As I said, EEPC is not quite notation, namely the rules of the description. And these rules do not prohibit add their own elements on the scheme. The main thing is that these elements be understandable, and there is a document where such extensions are fixed. For example, I use the following additional items that occur gradually in the process of describing real processes for various tasks, from a simple description for setting tasks for automation.

Data file. It is used if the data file is created as a result of the operation, or the file is used to perform the operation.
Database.Used when describing information flows between automated systems.
Card file.Used to display a paper file or archive.
Material flow. Used to designate incoming and outgoing material flows, as well as resources consumed when performing the process. The material flow is displayed to the left of the accompanying documents.
Information cluster. Used to designate structured information (presentation of entity). The diagram can be used to designate documents generated by programmatically when using user applications. In this case, the cluster element is located on the left of the corresponding document. Those. It suggests that the user did not just create a paper document, but also created its instance in the program.

Agreements on the rules of placement of figures in the diagram

The notation of EEPC itself does not impose strict requirements in the location of the elements relative to each other, although it is customary to draw the scheme from top to bottom or from left to right. If it is not to be unified in the case of several specialists, it may turn out a kind of "vinegar". What to avoid, it is recommended to work out and approve your rules for the location of the elements.

The sequence of events and functions are located on top down (better) or from left to right (if there is not enough space);
Elements denoting performers are located to the right of the functions;
Incoming documents on the left at the top of the functions; Direction of the arrow from documents to the function;
Outgoing documents left at the bottom of the functions; Direction of the arrow from the function to documents;
The "Information" element is located at the bottom right of the function. If there is not enough space, an arbitrary location is allowed, as close as possible to the function;
The "Appendix" element is located at the top to the right of the functions. (If this uses file storage, which are not reports, are displayed similarly). Communication without an arrow.
The "database" and "card file" elements are arbitrary;
The "Material Stream" element is located on the left of the documents accompanying it with reference to the document without an arrow;
The "cluster" element in the case of use in combination with the figure "Document" to designate a document in electronic form is located to the left of the corresponding document.

For example: payroll calculator calculates wages based on the "Brigade Outfit" documents provided to him. At the same time, he is guided by the document "Regulations on wages"The calculation produces in the program" 1C: ZIK ". The result of the calculation is the document "Statement".

Identification of elements in the diagram

As is known, a competent approach to the description of business processes provides for their identification, i.e. When each process has its own code name. Accordingly, individual functions within the process also have their names and identifiers.
Compulsory identification in the diagram are subject to "Document" and "Function" figures.
The document is identified by specifying in the upper left corner of the report code or document in accordance with the registry. Documents received from suppliers of goods and services (incoming) are identified only by name.
The function is identified by specifying the sequence number of the function for this group of processes. Those. The function number always starts with the code of the process group. Issues of identifying groups of processes go beyond this article, we will consider them separately. Moreover, learn how to identify processes should be able to describe them, otherwise the desire to describe all the company's activities on the same diagram, as sometimes try to do.
Therefore, now I will only show you on the example, as it can be represented in the diagram. Let's go back for example with call processing. Suppose that the sales department we assigned the code "04", the processing process of incoming contact code "VC". Then the scheme will take the following form (Identification is highlighted in red for clarity). The document code in this case points to the ordinal number of the document in the general register of documents (we will also be considered separately when we get to the examination of the document management system).

Display feedback

When building models, the need for cyclic execution of the process on a certain condition or the need to display the activities of decision makers are arising. In this case, we are talking about feedback.

To display the control feedback, the "direct inclusion" principle is used to the process of an additional control function with the subsequent branch (the logical element "excluding or" is used). For example:

Text Description Processes

As if we did not try to display the business process in the scheme, it would not be possible to achieve complete detail, otherwise you can be mired in endless chains of elements and conditions. To avoid this, as well as add information to the description of the process that cannot be displayed graphically, the description is complemented by text accompaniment. To do this, develop various text patterns that are filled in the process of description. Forms such template can be different, include individual sections with a description of inputs and outputs, consumed resources used by software, etc.
In the simplest case, the business process description template may look like this:

Buisness process:	Processing of incoming contact	04.VK
Process functions:
Name	Description	Room on the scheme
Processing an incoming call	When an incoming call is received, the operator processes the call in accordance with the rules for processing incoming calls. Reseigns the interest of the client, provides information about the services	04.VK.01
Formation of a commercial offer	If you have the interest of the client, the operator transmits the contact by the Sales Manager. Sales Manager is preparing a commercial offer and sends the Client by e-mail	04.Vc.02
Process indicators:
Name	Evaluation method / measurement
Number of failures	Statistics on the database

Outside this article remained such important topicsHow to collect information, allocating business processes, decomposition, highlighting indicators. These issues we will definitely study in further issues.

Introduction Typical tasks of describing business processes

and early stages of projects, the purpose of which is the reorganization of business processes and the introduction of information systems, the leaders and specialists are most often the following questions arise:

what results from the point of view of improving the organization's activities can be achieved using the technologies for describing and reorganizing business processes;
what software is used in the project ("ARIS is better BPWIN?", "Erwin is better ARIS?", etc.);
how to model processes using the product "x";
how to analyze and identify problems with the help of the product "X";
which methodology is used to describe processes;
what to do next with the obtained business processes models.

Currently, the Russian market presents a sufficiently large number of CASE systems, many of which allow one or another to create descriptions (models) of business processes of enterprises. At the same time, there are systems oriented primarily on the creation of models of processes and uncomfortable or not intended for creating data models and settings. Obviously, the choice of the system is determined by the objectives of the project and significantly affects its entire further move. The rational choice of the system is possible when an understanding of the company's management and its specialists of several aspects:

project goals;
information requirements characterizing business processes and necessary for analysis and decision-making within a specific project;
the capabilities of the CASE systems on the description of the 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 framework of the project is defined, as well as the main tasks that this project should decide. Our article attempts to compare the most popular notations (designations adopted during modeling) used to describe business processes, and two systems that support these notations. It is assumed that this material will serve as a basis for a discussion on the problems of effective application of CASE systems for describing and analyzing enterprise business processes.

A description of business processes is carried out in order to further analyze and reorganize them. The purpose of the reorganization can be the introduction of an information system, reducing the cost of production, improving the quality of customer service, the creation of official and working instructions when implementing ISO 9000 standards, etc. For each such task, there are certain parameters that determine the set of critical knowledge according to the business process. From the task of the task of the requirements for the description of business processes may vary. In the general case, the business process model should give answers to the following questions:

what procedures (functions, work) must be performed to obtain a given end result;
in which sequence these procedures are performed;
what control and management mechanisms exist within the framework of the business process under consideration;
roles and responsibility - who performs process procedures;
what incoming documents / information use each process procedure;
what outgoing documents / information generates a process procedure;
what resources are needed to perform each process procedure;
what documentation / conditions regulate the implementation of the procedure;
what parameters characterize the execution of procedures and the process as a whole;
there is a sequence of processes, minimizing costs (including cost, time, etc.);
as far as the process is supported / will be supported by the information system.

Notation ARIS Organizational Chart

The model is built from ORGANIZATIONAL UNIT, "POSITION", "INTERNAL PERSON", etc., and others. The types of links are made to reflect the various types of relationships between the objects of the organizational structure. In the presented in Fig. 5 Example "Enterprise" is managed by the "Director", while using the Type of Communication "IS Organization Manager For". The hierarchy of units is based using the "IS Composed Of" links. In addition, posts may be indicated - "Position" and the names of real employees who occupy them: "Internal Person", as well as the type of communication "Occupies".

Notations supported by BPWIN 4.0

Description of the notations IDEF0 and IDEF3

The semantics of the construction of IDEF0 and IDEF3 models involves compliance with clear rules. Full description of IDEF standards can be found on the site http://www.idef.com/.

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

In the notation of IDEF3, as well as in the notation of ARIS EEPC, logic symbols are used, reflecting the branching of the process. The Idef3 notation chart allows you to present the entire process, and the sequence of operations and the process execution logic is tracked.

Description of notation DFD.

Notation DFD is designed to describe information flows in the organization's surveyed. DFD notation objects are shown in Table. four . The presence of "data warehouse" objects and bidirectional arrows allows you to most effectively describe the workflow and the requirements for the information system.

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

non-plant situations of the use of instrumental means of modeling business processes and their expert score on a 5-point scale are shown in Table. 7.

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

Thus, for maintaining small scale (small and medium enterprises, 2-5 people in the group of consultants) and duration (2-3 months) of projects rationally use BPWIN. For large and / or long projects (for example, such as the implementation of a continuous improvement system of business processes, ISO, TQM) is more suitable for ARIS. It should be noted that the ARIS ToolSet system is inconvenient 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 of subsequent successful work.

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

ComputerPress 1 "2002

The notation of the ARIS Necess is decoded as follows - Extended Event Driven Process Chain is an extended notation of a process chain description managed by events. Notation Developed by IDS Scheer AG (Germany) specialists, in particular Professor Sheer (see)

Perhaps it will be useful to read: