The ARIS EPC notation used to model business processes in the ARIS toolkit is a sequence of events and functions that reflect the logic of performing interrelated actions aimed at achieving a certain result.
The ARIS EPC model is intended to describe the business process execution algorithm as a sequence of event-driven functions. The ARIS EPC model focuses on the sequence of execution of functions, and to describe the conditions in the business process model, events and rules are used that can describe complex business process execution algorithms.
Functions in the ARIS EPC model are triggered by events, such as "Invoice received for approval", and terminated by events, such as "Invoice approved" or "Invoice not approved". If as a result of the execution of the function there is only one option for further execution of the business process, i.e. as a result, only one event is generated, after which the next function, the event between these functions may not be drawn.
Business process model ARIS notation An EPC necessarily begins and ends with one or more events or interfaces to other business process models. To reflect the interfaces, special objects "Process interface" are used - the object type is "Function".
When creating an ARIS EPC model, situations may arise when the same document is outgoing for one function and incoming for the next. In these cases, to improve the ergonomics of the model, it is acceptable to use one document representation with one incoming link (from the function in which it is created or corrected) and one outgoing link (to the function in which it is used).
The EPC model cannot be disconnected, i.e. the location on the model, one object that is not related to the rest, is a mistake.
The arrangement of documents in relation to functions is usually as follows, top left - incoming documents, bottom left - outgoing documents, performers, as a rule, are located to the right of the function.
The following information is indicated on the ARIS EPC model:
- functions performed
- function information resources (incoming/outgoing documents)
- events
- process interfaces
- logical operators
- performers (positions, business roles)
- Information Systems
Event naming rules in ARIS EPC
The name of the event (Event) must contain a noun and a description of the state change in the form of a verb. Example: "Deal closed".
Function naming rules in ARIS EPC
To name a function (Function), you must use its real name. The name must consist of two parts - a verbal noun that describes the function to perform, and a noun that shows the object on which it is performed. The name of the function consists of a short name of the object, starting with a capital letter, for example, "Search for customer contacts".
Role/position naming rules in ARIS EPC
The name of the business role (Person Type) must correspond to the essence of the duties assigned to the executor. As a rule, the name contains the phrase "Responsible for ...". Job titles (Position) are written in accordance with the staffing table.
Document naming conventions
The object corresponds to the document (Information Carrier) (in paper and/or in electronic format). To name documents (regardless of the symbol used), you must use their real name.
Naming rules for information systems in ARIS EPC
For name information systems(Application system type) their established names should be used.
Process Interface Naming Rules
Interface (Process interface) shows a link to an adjacent process. The name of the process interface corresponds to the name of the model that describes the adjacent part of the business process. An interface can be used to refer to business process models that are not part of the described business process.
Vladimir Repin
General manager LLC "Vladimir Repin Management"
Member of ABPMP Russia
management consultant
Business trainer
PhD
In many modern systems of the Business Process Management (BPMS) class, the BPMN specification (version 1, 2) is used to describe "executable" processes. This specification is probably the best for the purposes of formalizing automated processes. However, for the description and regulation of the processes performed by people, it is too complicated, just like some other notations that have appeared earlier.
The article considers the problems of choosing notations that are adequate to the task of describing and regulating processes performed by people. Comparison of ARIS eEPC notation, "simple flowchart" in MS Visio and "Procedures" of Business Studio is made.
Conclusions are drawn about the expediency of choosing a notation for a comprehensive description and regulation of the company's processes.
Introduction
A fairly typical situation is when the development director sets the task for his specialists to choose notations (methodologies) that will be further used to describe and regulate the company's business processes. When making this choice, it is advisable to take into account at least the following four aspects:
- Notation capabilities for describing processes of the required level of complexity;
- Possibilities of the modeling environment that supports the selected notation;
- Availability of a methodology for applying the selected notation and an appropriate tool for solving the tasks set within the project;
- Availability of specialists with the competencies necessary to use the notation and the tool, taking into account the requirements of the project implementation methodology.
If the goals of the project are not clearly formulated, then the choice of notation is likely to be made erroneously. Consider, as an example, the following statement: "We want to describe and automate the most important business processes in BPMS, regulate the work of all employees of the company and describe the requirements for improving existing software." Such a phrase contains several completely heterogeneous tasks:
- Description of executable processes within the BPM system;
- Regulation of the activities of employees with the help of internal regulatory and methodological documents (i.e., the creation of a regulatory framework);
- Description of the software requirement.
With such a statement of the problem, you will most likely have to use several notations: BPMN, some notation like Work Flow and, possibly, UML. Use one notation and one modeling tool to effective solution these heterogeneous tasks are unlikely to succeed in practice.
The BPMN notation is the most convenient (among the currently existing ones) for describing “automatically executed” processes. But it is not convenient for creating relatively simple schemes in regulatory documents for employees for the following reasons:
- The presence of semantics that is too complex and redundant to describe simple processes;
- Inconvenience in creating a complex, multi-level process model of the organization as a whole;
- Significant difficulties in training company employees (due to the complexity of the specification and the lack of specialists capable of conducting such training).
To create process diagrams that will be “transparent” and understandable to most employees of the company without long and complicated training, a different notation is needed. It is interesting to consider some of the currently popular notations in terms of the following factors:
- Easy to learn, intuitive for company employees;
- Acceptable information content of process diagrams with a minimum set of graphic symbols used;
- Notation support by modern modeling tools;
- Costs for the implementation of the methodology for describing and regulating processes using the appropriate tool;
ARIS eEPC notation
The ARIS eEPC notation was one of the first notations to become widely known in Russian market. It refers to the Work Flow type notation. The features of the notation are the presence of elements of the "event" type and the presence of logic operators: "and", "non-exclusive or", "exclusive or" (see Fig. 1).
Rice. 1. Process diagram in ARIS eEPC notation
In its full version, the ARIS eEPC notation contains a very large number of graphic elements. Therefore, when projects are executed, so-called “method filters” (under “modeling conventions”) are created, which limit the number of element types available to users when creating process diagrams. (In some modeling tools, the ARIS eEPC notation is immediately implemented with the minimum required set of elements). However, even in this case, inexperienced users create schemes of such complexity, which then cannot be unambiguously perceived. Such schemes require a detailed textual comment (or the presence of an analyst who can explain the scheme).
Why does this effect occur? It is the result of describing the set of branches that occur during the execution of the process using formal logical operators. This has to be done following certain strict rules. As a result, a cumbersome, formally correct, but poorly perceived scheme appears.
The question arises: what, in fact, fought for? Typical scheme in ARIS eEPC:
- Not suitable for automation in a BPM class system (you need to use an additional translator that translates it into BPMN notation, followed by manual refinement);
- Difficult for perception by ordinary employees of the company (they need to be taught the rules for using logical operators and the correct reading of the circuits that contain them).
Thus, the ARIS eEPC notation is not intended to describe "automatically executed" processes and is inconvenient for employees to understand due to its complexity. Modeling in ARIS eEPC does not provide significant advantages for either automation or regulation. The ARIS eEPC notation is classical and formally correct, but its "machine" logic is not convenient for ordinary employees of the company to perceive. Therefore, from a practical point of view, the effectiveness of using ARIS eEPC raises significant questions.
Note that the ARIS eEPC notation is supported by many modern business process modeling tools. But this situation does not so much prove the effectiveness of its use in projects, but rather speaks of the desire of software vendors to make money on a popular notation well-known to the market.
Despite the above problems, the use of the ARIS eEPC notation and the corresponding modeling tool, of course, makes it possible to create a sufficiently high-quality, integrated process model in a company with the possibility of subsequent uploading of information in the form of regulatory documents.
"Simple Flowchart"
The "simple block diagram" notation is implemented in the popular MS Visio office product. On Fig. 2. elements of this notation and a fragment of the corresponding scheme are shown. In full, the notation under consideration is rarely used.
In general, MS Visio presents several flowchart notations that are quite complex. Obviously, for this reason they have not found wide application, although they were included in the set of notations supplied with the system.
The "simple block diagram" notation, in its simplest and most commonly used form in practice, contains only a few elements:
- Process;
- Solution;
- Manual operation (less common);
- Document;
- Data;
- Arrow (for displaying links between schema objects).
Using the considered notation, you can show data flows if you need to describe processes for the automation task. But it is inconvenient to describe “automatically executed” processes in a BPM system.
Rice. 2. Notation "Simple block diagram" in MS Visio
Consider some of the features of the application of the "Simple flowchart", in particular the use of arrows. In practice, company employees who form diagrams using the "Simple Flowchart" follow two approaches:
- Don't name arrows at all;
- They try to assign simple and understandable names to the arrows connecting the circuit elements;
On Fig. Figure 3 shows an example of the application of the "Simple flowchart" notation in one of the companies. All five types of elements are used. Nevertheless, the scheme looks quite readable and understandable to the user - an employee of the company.
The notation "Simple block diagram" when used in companies is often subject to various variations:
- The meaning of the "decision" element is changed;
- Link arrows are used in different ways (they name or do not name, etc.);
- Link arrows are used differently in combination with the document object;
- Other.
Interestingly, the notation "simple flowchart" in one form or another is often used by quality management specialists when describing QMS processes.
Rice. 3. An example of a diagram in the notation "Simple block diagram"
The advantages of the "Simple flowchart" notation (with the number of elements reduced to a minimum) are:
- Ease of formation of graphic schemes of processes;
- Intuitive understanding of schemes for employees (even without special training);
- Minimum need for employee training;
- Availability of available tools for describing processes (MS Visio, MS Word).
However (as is often the case in practice), if the notation is used without an approved internal standard and a specialized modeling tool, the company ends up with a set of a large number of non-standardly designed schemes that are contained in various files. It is difficult to keep such a set of schemas in a coherent state and track changes. Requires a lot of manual labor of business analysts. Therefore, choosing the notation " Simple block diagram"It is necessary to develop in advance:
- The internal standard for using this notation;
- An internal standard for generating, storing and updating files with process diagrams.
In general, the large-scale use of the "Simple flowchart" notation in the company without modern means modeling seems to be very inefficient.
"Procedure" Business Studio
On Fig. Figure 4 shows a diagram formed in the “Procedure” notation of the Business Studio process modeling environment (Russia). In the considered notation, the following conventions are used:
- Process;
- Solution;
- Event;
- Precedence arrow (as in the classic notations of the Work Flow class);
- Object flow arrow;
- Footnote;
- External reference.
When constructing schemes in the "Procedure" notation, the so-called tracks ("cross-functional" scheme) are used, which makes it possible to describe the "end-to-end" processes of the company.
On the example of the process diagram shown in Fig. 4, consider how arrows are used in the diagram. The arrow labeled "Next Day Delivery Plan" has a precedence type, that is, it shows the sequence of actions in time. But at the same time, it visually informs the employee reading the diagram which document is transferred between the process operations.
In the Business Studio modeling environment, one or more documents can be linked to an arrow. They will not be visible directly on the diagram, but information about these documents can be included in the regulatory document in a convenient form (see, for example, Table 1).
Rice. 4. Process diagram in the notation "Procedure" Business Studio
Note the arrow labeled "Adjustment of the next day's internal delivery plan is required." This arrow, in fact, describes one of the events that completes the operation "Check delivery plan for the next day" (in the diagram, this is a diamond - "decision"). The second arrow coming out of this operation informs about another possible event "Internal delivery plan for the next day agreed".
On Fig. 4. it can be seen that during the process, to increase the information content of the scheme, event elements are used (“Daily, at 9-00”, “During the day”, “12-00”). Thus, information about events can be shown both in the form of special elements, and by appropriately naming arrows.
The double-headed "Clear Picking List" arrow emerging from the corresponding operation displays the flow of documents in the diagram. This arrow does not transfer control from one operation to another, but only to indicate flows of objects or data.
In general, the process diagram in the “Procedure” notation, with apparent simplicity, is very informative and convenient for description. Can be formulated the following benefits this notation (if used in Business Studio):
- The minimum required set of graphic elements for describing processes of the Work Flow type (workflow) is presented;
- The speed of creating graphic diagrams for the purposes of regulation;
- The ability to increase the information content of process diagrams due to the flexible use of events and named arrows (simultaneously with the ability to link documents to arrows and then upload information in regulatory documents);
- Process schemes are simple and understandable to all employees, even without special training;
- Simplicity in training (there is no need to attract expensive specialists from outside - training can be carried out by employees of the organizational development department);
- Process diagrams are cross-functional, which is convenient for describing the "end-to-end" processes of the company;
- You can upload and edit diagrams in MS Visio (if necessary).
The Business Studio modeling environment allows you to quickly create a process model of a company. Process information can be downloaded from the system in the form of regulatory documents in the required format. Note that Business Studio has the ability to describe processes in the ARIS eEPC notation, IDEF0 notation, and the “Process” notation (see the system manual).
As an additional example, in Fig. 5. shows a fragment of a more complex scheme, made in the notation "Procedure". By the way, to increase the information content, the arrows describing inappropriate results (“The set of documents is not complete”, “ Temperature regime violated”, etc.) are shown in red. In addition, the diagram provides additional comments on some operations.
Table 1. Information about the process presented in Fig. 4
Rice. 5. An example of a scheme in the notation "Procedure" in Business Studio
conclusions
In general, the "Procedure" notation in the version implemented in the Business Studio modeling environment is more convenient and understandable to employees than the ARIS eEPC notation. It allows you to quickly describe and regulate the processes of the company.
If it is necessary to describe and regulate many processes, of which only a small part will then be supported in the BPM system, the choice of the “Procedure” notation seems to be quite adequate for the task.
When choosing a notation for a comprehensive description of the company's processes, it is desirable to make sure that it is simple and understandable to most employees without special training and long-term development.
Of course, you can get people to describe processes in any notation using completely different modeling tools, but the costs of implementing such notations/systems in an organization can be quite significant. An overly complex notation and modeling tool can make process management methods the preserve of a narrow circle of professionals from the organization development or IT department, and the benefits of the process approach will not be fully realized.
The ARIS eEPC notation is deciphered as follows - extended Event Driven Process Chain - an extended notation for describing the chain of an event-driven process. The notation was developed by specialists from IDS Scheer AG (Germany), in particular by Professor Scheer (see )
Loading...