The specialization of Abazhur Group of Companies is the implementation of diverse construction projects based on EPC/EPCM contracts... But for those who are in search and do not yet know what EPC and ERSM are, we offer a collection of materials that, we hope, will serve as a help for our Partners and clients in working with such relatively new instruments for domestic practice as EPC, EPC (M) contracts.

Structuring, conclusion and execution of EPC and EPC(M) contracts

Abazhur Group of Companies specializes in the implementation of diverse construction projects based on EPC/EPCM contracts, as well as other construction contracts with individual conditions. , applies system solutions in construction using BIM modeling, creates building designs that achieve low capital intensity.

EPC/EPCM contracts are the most common type of contracts in the construction industry

When choosing one form or another, it is important to remember that the type of contract can lead to a significant change in the level of costs and risks that are associated with the construction of large and large structures. The level of costs is proportional to the risks assumed by the customer. As the commercial risks taken by the owner decrease, the costs of constructing the facility and its management increase. In any business, this is logically confirmed by the risk-reward relationship.

The obligations assumed by the general contractor most often include the provision of four types of services:

• Engineering– survey work, project creation, documentation approval;
• Procurement– selection, purchase and supply of equipment and materials necessary to complete all work;
• Construction of an object– construction, assembly and commissioning works;
• Management of all construction processes (Construction Management).

Contract strategy for the implementation of large construction projects

Reducing construction time is often possible due to the fact that the EPC contractor, being the only person responsible to the customer, can develop and issue design and working documentation in parallel with the purchase of materials and equipment, as well as construction and installation work.

For example, the EPC contractor does not have to wait for the development and approval of all project documentation in order to begin contracting for equipment with a long manufacturing cycle.

The effective use of parallel design allows in some cases to significantly reduce the overall construction time. This is especially true for some gas projects, especially associated petroleum gas processing/treatment projects, where there may be a peak in production at which time a gas treatment facility must be built, otherwise the overall profitability of the project will be seriously affected. In such cases, it is justified to use the EPC model for project implementation, which, despite the higher cost, allows construction to be completed in a shorter time.

Each contract strategy - a “traditional” model of managing the customer’s forces and the EPC model has its own strengths and weaknesses. For comparison, we provide tables systematizing the negative and positive aspects of each strategy.

EPC(M)-contract

EPC(M) - structure is a contract solution, which, from the point of view of risk distribution, lies in the middle between the multilot and EPC contract models. It should be noted right away that there is no single and unambiguous understanding of what is considered an EPC(M) contract. Such an agreement can be understood, for example, as a situation where the EPCM contractor acts solely as a consultant who does not enter into any subcontract agreements on its own behalf.

Equally, an EPC(M) contract can be called a full-cycle general contract, but in which the price is determined according to the principle “ open book"(open book) or "reimbursement" (cost + fee, reimbursable)*. Complexity in the terminology is also introduced by the fact that none of the leading international organizations (FIDIC, ICC Orgalime) has issued a proforma EPC(M) agreement.

* In our opinion, it is more correct to call such contracts
EPC open book and EPC reimbursable or cost plus fee respectively

EPC(M) is the English abbreviation for Engineering Procurement Construction Management. At the same time, the correct translation of this abbreviation into Russian is “Design, Supply, Construction Management”. In the EPC(M) model, the word management most often refers specifically to construction in the narrow sense of the word, i.e. to perform construction, installation and other work on the site.

Subject to the previously stated reservations about ambiguity in terminology:

An EPCM contract is most often understood as such a structure when the EPC(M) contractor on our own or by force subsidiary company carries out design, independently carries out contracting of equipment and materials, but in terms of construction and installation work it carries out only management, i.e. does not hire construction and installation contractors on its own behalf, but only manages the contractors hired by the customer on behalf of the customer.

The fundamental difference between the EPC(M) agreement and the EPC contract is that the EPC contract is an agreement on “acceptance of responsibility and risks”

By concluding an EPC contract, the customer largely shifts the risks and responsibility to the EPC contractor, which must provide this responsibility with liquid property. The EPC(M) contract is an agreement on professional services, the customer “buys” competencies, the responsibility of the EPC(M) contractor for the timing and budget of the project is absent or negligible in comparison with the cost of the project and, thus, is of an exclusively stimulating nature.

Possible various options price structuring in the EPC(M) contract, but it is never fixed. Often the price is a combination of time rates (for those functions that the EPCM contractor performs personally - design, procurement management, construction management) and the "open book" principle.

This principle means that

• subcontracting is carried out in a manner transparent to the customer and with the participation of his representatives;
• the contractor discloses its own overhead cost structure as well as the amount of expected profit and such overhead/profit is either fixed at a specified amount or added as a percentage markup to the cost of each supply contract.

As already noted, the liability of the EPC(M) contractor is very limited and is more reminiscent of the liability of a consulting engineer (who is only responsible for dishonest or incompetent provision of his own services) rather than the liability of a general contractor.

At the same time, quite often in EPC(M) contracts there are mechanisms for stimulating the contractor using the principles bonus/malus (so-called gain sharing / pain sharing).

For example, the contract may provide that the commissioning of the facility in more early date the contractor receives additional remuneration; if there is a delay, the contractor, on the contrary, loses part of the profit.

In a similar way, incentives can be built in relation to the general: the parties can set a certain target budget and if, by effectively managing construction, the contractor achieves savings, then such savings are divided between the parties in an agreed proportion. However, the EPC(M) contractor, when agreeing on a bonus/malus, is usually not ready to risk the entire reward and therefore this mechanism does not give the customer complete comfort regarding the cost and timing of construction, but is only aimed at creating a material interest for the contractor in successful implementation project.

One of the advantages of the EPCM contract compared to the EPC model is the important fact that the tender for the selection of the EPCM contractor can be prepared and carried out much faster than the tender for the award of the EPC lumpsum contract. The fact is that in the first case, a lesser level of certainty is required from the customer regarding the scope of work, delivery boundaries and risks; and the contractor only needs to prepare a price proposal for time rates, overheads and his own profit - he is not required to prepare a firm price proposal for the total cost of the project.

When tendering according to the EPC lumpsum model, on the contrary, the customer needs to prepare detailed technical task and requirements (if the level of elaboration is insufficient, contractors may either refuse to submit proposals with a fixed price or assess the risks at a very high level); Likewise, the contractor needs an order of magnitude more time to prepare a proposal with a firm price that takes into account all the risks.

Modern methods construction, high-quality materials and technologies, functions of construction control and general contractor, industrial and commercial buildings, installation of prefabricated structures. Construction of objects of any complexity!

Terms:

EPC contractor- this is a person who performs the main volume of work of an investment project for a fixed price and assumes all the risks of its implementation from the moment of design until the moment of transfer of the finished object to the customer (including fulfillment of warranty obligations), for which he bears financial responsibility to the Customer.

It is used, as a rule, in those projects where it can estimate with a sufficient degree of accuracy the size of its expenses, as well as the degree of risks.

The EPC contract requires that the EPC contractor performs the bulk of the work on its own, therefore no special remuneration provided for organizing and managing the work of lower-level contractors involved.

EPSM contractor can enter into contracts with subcontractors on its own behalf or manage contracts concluded by the customer with specific performers of work.

The EPSM contract provides and the total cost of the project, taking into account the remuneration of the EPSM contractor, and a fixed deadline for putting the facility into operation, achieving the main technical parameters of the facility. The EPSM method (approach) allows you to manage the project, and not specific works. Specific work is performed by professionals. The task of EPSM is to assess the required properties (capabilities, professionalism, resources, etc.) of selected contractors/suppliers, and correctly distribute work and areas of responsibility between them. Next - coordinate their actions, resolve controversial issues, plan the overall scheme of the project, change plans in case of critical changes with minimal consequences, and then with all stops.

The world practice of implementing investment projects highlights EPC and EPSM contracts as the most promising strategies for implementing complex industrial projects, which account for about 80% of implemented projects.

Read in more detail the publication prepared by.

If you have any questions or comments, you can - all of them will be gratefully considered.

An EPC function diagram must begin with at least one start event (the start event may follow the process interface) and end with at least one end event (the end event may precede the process interface).

Events and functions must alternate as the process progresses. Decisions about the further course of the process are made by functions.

The recommended number of functions on the diagram is no more than 20. If the number of functions on the diagram significantly exceeds 20, then there is a possibility that the processes at the top level are incorrectly identified and the model needs to be adjusted.

Events and functions must contain strictly one incoming and one outgoing connection, reflecting the progress of the process.

The events and statements that surrounded the function in the above diagram should be the initial/resulting events and statements in the function decomposition diagram.

The diagram should not contain objects without a single connection. Each merge operator must have at least two incoming links and only one outgoing link, and each branch operator must have only one incoming link and at least two outgoing links. Operators cannot have multiple incoming and outgoing connections at the same time. If an operator has an incoming connection from the “event” element, then it must have an outgoing connection to the “function” element and vice versa. A single event must not be followed by an OR or XOR operator. Operators can merge or branch only functions or only events.

Rice. 2.62 Example of a process diagram in EPC notation

Rice. 2.63 Example of acceptable situation 3	Rice. 2.64 Example of acceptable situation 4

An example of an unacceptable situation.

Rice. 2.65 Example of an unacceptable situation

Statistical methods process management

Examples of the most popular methods of statistical analysis are given and a mechanism for their evaluation is proposed.

Pareto chart analysis

On industrial enterprises All sorts of problems constantly arise: defects, equipment malfunctions, etc. In most cases, the overwhelming number of defects and associated losses arise due to a relatively small number of reasons, and the share of material costs is about 70 - 80%. To find out which of these reasons or factors are the main ones, a Pareto chart is built.

The Pareto diagram is a tool that allows you to objectively present and identify the main causes affecting the problem under study. There are two types of Pareto charts: by results of activities and by causes.

The performance chart is designed to identify the main problem and reflects the following undesirable performance results:

· Cost: volume of losses, costs;

· Safety: accidents, breakdowns;

· Delivery times: missed deadlines, lack of inventory.

The Cause Pareto Chart reflects the causes of problems that arise during production:

· Performer of the work: shift, team, etc.;

· Equipment: machines, units, tools, etc.;

· Working methods: sequence of operations, production conditions;

· Measurements: accuracy, reproducibility, stability.

Constructing a Pareto chart consists of the following steps.

Step 1. Determine what problems need to be investigated and how to collect data; how to classify them. Set the data collection method and period.

Step 2: Develop a data recording checklist listing the types of information to be collected.

Step 3. Fill out the data recording sheet and calculate the totals.

Step 4. Develop a spreadsheet for data checks, including a graph for the totals for each item checked separately, the accumulated sum of the number of defects, the percentage of the total, and the accumulated interest. At the same time, arrange the data in order of importance.

Table 3.1.1 Construction of the Pareto chart

Step 5: Draw one horizontal and two vertical axes. Vertical axes: on the left axis, put a scale with an interval from 0 to the number corresponding to the grand total; on the right axis – a scale with an interval from 0 to 100%. Divide the horizontal axis by the number of controlled features.

Rice. 3.1.1 Pareto chart

Stage 6. Construct a bar graph where each type of marriage has its own rectangle.

Step 7. Draw a cumulative line.

When constructing a diagram, you should pay attention to the following points:

· The diagram turns out to be most effective if the number of factors is 7 – 10;

· When processing data, it is necessary to stratify them according to individual parameters (time of data selection, type of products, batch of materials, operator, etc.);

· If the “other” factor turns out to be too large, the analysis of the content of this factor should be repeated;

· The chart should be made systematically. Pareto for the same process, which will allow you to track the trend in the number of defects for each factor (Fig. 3.1.1).

Sheet music for business

Music has tied us
Has become our secret

All epigraphs for this article are taken from the song “Music Has Connected Us” by the band Mirage.

In classical music, the musician is an instrument in the hands of the composer and plays according to the notes. In popular music, musicians most often write the music themselves, and the art of improvisation does not involve notes at all. True, famous improvisations that have become classic are then translated into sheet music, and they have new life: the arrangement changes, a new sound and mood are added.

So is the business that has grown as a skillful improvisation to move to new level requires putting facts on paper to analyze what is happening and make decisions for improvement.

Recently, more and more often you can find descriptions of business processes (BP), made, as they say, "on your own". It was this circumstance that prompted the writing of the article. Unfortunately, most of these documents that I happened to see were of little use for serious business. This is not to say that they were fundamentally incorrect, but a number of omissions spoiled them so much that I wanted to immediately forget about their existence. What kind of omissions these are, and how to deal with them, we will figure out in the course of this article, gradually approaching the essence of the issue. We will try to avoid a large number of technical details, but we cannot completely avoid them, because... the subject of the conversation requires it.

Is it really me
I can't find the answer to everything

This article is addressed to those who want to save on describing business processes by entrusting the preparation of the document to internal specialists. After all, a description of business processes is not mandatory for a company, and everything works without it. But in any stable company there is a mechanism for transferring authority, it is called " job descriptions"If the business is complex and the position is key, then it is useful to draw job descriptions to make it easier to understand. Accumulation of business processes in general description necessary in order to make the business more transparent, especially for its sale.

The document “Description of BP” becomes especially relevant as soon as there is a need for reorganization (or, as it is now fashionable to say, reengineering) of the company. In this case, the document is used to:

1. On it, as on a battle map, mark the essence of the planned transformations,
2. Bring the transformation participant up to date,
3. Use a pen and not your fingers to assign tasks to department heads and external specialists.

There are advantages to preparing the document yourself:

• It works out cheaper;
• Internal specialist, better versed in the practices of his native business.

An outside consultant will first have to study the terminology and key features subject, industry standards. This takes time. True, he knows better how and what needs to be described. There are certain rules, generally accepted notations and special software. An example of such notation can be seen in Fig. 1 and fig. 2.

IDEF0 notation

An example of describing a power supply using IDEF0

Don't lecture us

Don't lecture me
Mom, this is useless

Do we really need this? - The director will ask, reasonably assuming that compliance with all standards will significantly increase the cost of the result. One of the directors I know reasoned like this: “Inviting a third-party specialist is an expensive business, but our tasks are simple - why do we need all these notations. And the specialist, sometimes he draws something with his hooks, nothing is clear, it’s not convenient to admit, so he’s still behind This is what you have to pay for."

I agree, if the tasks are simple, why bother? And if they are complex, then they need to be simplified and not complicated with fancy notation. After all, there are no obvious advantages from using beautiful hooks. If there are no obvious ones, this does not mean that there are none. These rules and notations were not invented so that the consultant would not get bored... Anyone who is involved in business knows well that not everything useful is obvious. Well, let's look for the hidden positive and to do this, let's look into the history of the issue.

The power supply description market has existed for a very long time. However, over the past decade and a half, it has made a rapid breakthrough, thanks to the emergence of a new industry - automation of accounting and management in enterprises. The growing market gave newcomers who came up with new notations a chance to break through and stake out their place. For example on Russian market in a few recent years massive advertising and information campaigns on the part of IDS Scheer (the main supplier of ARIS - see Fig. 3) created a layer of specialists in describing automated processes.

Using ARIS notation requires great detail of business processes.

The implementation of systems such as ERP (resource management), CRM (customer relations), MRP (production planning) inevitably leads to changes in processes, and if this is not planned in advance, the result may be worse than desired. In addition, automation is working with information, which means it is useful to know what information is generated by whom, where it comes from and where it goes. But special notations for introducing automation have never taken root here and are rarely used.

The description of business processes in Russia is a relatively recent trend, despite the impressive number of GOSTs in this area (3.1109, 34, ISO, etc.). Now, with the quality of description of their own business processes, things are best in banks. The fact is that, unlike other commercial structures, a bank is an infrastructure organization and therefore it is within the strict framework of regulations defined by law. The bank operates on the principle of day management. As a result, even a simplified description of the Bank’s business processes (in Russian without the use of notations) turns out to be more detailed, because rests on a foundation built on volumes of regulations defining standards, terminology, roles and rules. These standards are the generally accepted language in the banking environment and the description of business processes will be easy to read for any specialist.

IN commercial structures description of business processes requires a preliminary dictionary of terms. And when starting to prepare and coordinate it, many are faced with the fact that the same things are called differently in different departments. Going into detail, it turns out that different names actually carry different shades of meaning. Coordination of terminology is one of the most labor-intensive processes in describing a business process. It is important to get this process up and running. I can take on most of the work from the company’s own divisions, because the need to regulate its activities leads to greater organization of processes and procedures.

When description is required for automation, the reverse sequence is also possible. Changing business processes is done in parallel with the implementation of the information system, and the description of new business processes is carried out “hot on the heels” and is integral with the system documentation.

Staff

I forgot everything
We have been taught for so many years

Oddly enough, the choice of notation and the correctness of the description are more critical for small and medium-sized businesses. Large companies usually have greater process elasticity due to the interchangeability of employees. For a small business, where the execution of critical points comes down to 2-3 decision-makers, an incorrect indication of the process route can give rise to a fundamentally incorrect concept of the solution. Since the result is critical, then the tool is important, but how to choose it?

Each notation is adapted for a specific range of tasks. We will consider the most pressing task to be changing business processes within the framework of a management automation project. For these purposes, there is a good set of tools that are quite widespread: these are Russian GOSTs, and the same ARIS, and IDEF, as well as EPC (Fig. 4 and Fig. 5).

EPC notation

Description of a business process using EPC

If a book is written in a certain language, then the most important thing is to have a reader who knows this language and can read it. Based on this, the most common standard for describing BP is the best.

When choosing a notation, another important criterion is the ability to use a familiar software tool. For example, Microsoft Business Solution in 2002 offered On-Target notation for the Navision information system, accompanied by a special software solution. This is the very case when it is better to choose something else - not only does no one know the On-Target notation, but also the software environment will require time to study it. I would call a positive example the use of the IDEF notation and the Visio program, which is very widespread and has the necessary set of tools for drawing IDEF diagrams (Fig. 6).

IDEF business processes done in Visio

Of course, the description of the power supply can be done simply in words, as well as using various symbols (of your own invention) since it seems understandable. Having such a description is better than nothing, but maintaining standards is still useful.

Fullness and depth of sound

I don’t know what draws me here

1. will take a long time
2. Some details will change during the creation of the document.

A common mistake is trying to fit descriptions to fit the notation. For example, trying to describe procedures in ARIS format, i.e. achieve apparent redundancy in description when it is not required.

But more common mistake is insufficient depth of the document. As a result, the result is a formal document that is not suitable for work, because all important details have to be clarified in the process.

A melody is a sequence of sounds, not notes.

Forget about this day
Nobody needs an argument

This means that the power supply can be described simply in words, without any notations. Of course, the notation is more correct, but that’s not what’s important. Description BP is not a final product, but only a tool for new achievements. This means that it must be adapted to further active use. The main problem with most do-it-yourself documents is that they are inconvenient to use. For example, one such document consisted of a description of what was done in Microsoft Word and drawings made in PowerPoint; jumping from program to program was terribly inconvenient, I had to spend a large number of time to just put it all into one document. It turns out that the document must have the following properties:

1. Have a clear order and grouping of sections, i.e. be conceptually holistic (usually this means that if you have a concept, then you have learned to use it);
2. Clearly identify business units and give them clear names and numbering;
3. Clearly highlight business processes and also give them a clear name and numbering;
4. Elements should be numbered in such a way as to avoid confusion (this makes the search much easier): for example, Department No. 1 should have the number Dept.001 in the document, and Business Process No. 1 should have the number BP001;
5. The document must have a contents section with a tree structure;
6. A company is an integral organism and no business process hangs in the air - it is always connected with other business units, business units and departments. To reflect these connections, you can use hyperlinks - this will make it easier to find information and move from one object to another.

Anything can be used for business text editor supporting hyperlinks.

Some believe that in professional music group It is enough to have one or two real musicians. No sincere music connoisseur will agree with this. These conversations arise due to the lack of professionals and creative individuals.

Businesses have similar difficulties. There are few good specialists who know their company from head to toe, and they are very busy. By analyzing business processes on our own, we save money and perhaps save time. But it is not always possible to select the best ones to describe the power supply. You can entrust the routine to performers of a lower rank, but then there is a risk of delaying the process. Ignorance of the principles of constructing such documents carries the risk of ineffectiveness (the result is unusable, it’s the same as its absence).

The best quality and speed in document preparation is possible in an alliance with a key specialist and an experienced consultant. The result will be an agreed language for describing business processes (i.e., the terminology of the company’s business) and the description itself in detail sufficient to solve further problems.

I repeat in response to all persuasion
They won't separate us, no

We remind you that all epigraphs for this article are taken from the song “Music Connected Us” by the group Mirage

A third-party consultant will write a document in a notation language that is understandable to other consultants and often more suitable for the case. Don't you understand all these hooks? But these notations are not at all complicated, maybe it’s worth learning them?

A process model represents a coherent, integrated set of functional, behavioral, informational and organizational perspectives, but many models used today in reengineering practice do not satisfy this.

10/12/2011 Igor Fedorov

A process model is an interrelated integrated set of functional, behavioral, informational and organizational perspectives, however, many models used today in reengineering practice do not meet the requirements for process models and cannot be called process models, since they provide an incomplete picture of the modeled object and do not contain all the information needed to create an executable model.

Disputes about the choice of notation for modeling business processes still do not subside. The capabilities of the EPC (Event-driven Process Chains) and BPMN (Business Process Modeling Notation) notations, syntax, set of description language primitives, etc. are analyzed. However, it is incorrect to compare notations and languages ​​for describing a business process by analyzing their functionality - is the model functional or process is determined not only by the notation, but also by the methodology. Often the modeling methodology is replaced by notation, which leads to serious errors in the design of business processes and the appearance of low-quality models.

Models and perspectives

Model- this is a material or mental representation of an object or phenomenon, repeating some properties that are essential for the purposes of a particular modeling, and omitting other, unimportant properties in which the model may differ from the prototype. A complex object, for example a business process, is described by a set of models, each of which displays a limited set of properties, and together they describe the modeling object completely. Each of the particular models is associated with a main question that the corresponding model should answer. Four perspectives of the business process model are identified (see figure).

Functional:“What are the participants doing?” Describes the scope of work performed.

Behavioral:“How do the participants work?” Describes the sequence, execution schedule, business rules.

Informational:“What are participants processing?” Describes the business entities of the process domain.

Organizational:"Who does the work?" Describes the composition and structure of performers.

A model that describes a certain perspective answers several questions, but among them there is always a main one, to which the model must give an exhaustive answer, and may not completely answer additional ones. In the latter case, you need to be especially careful; the perspective of the model is determined precisely by the main question, and not by an auxiliary one.

Functional Perspective

A functional model describes a system in a static state and helps answer the question “what needs to be done to achieve the goal?” The answer is a list of all the actions that need to be performed to achieve the planned result. Widely used in project management work breakdown structure(Work Breakdown Structure) - the actions listed in it are not connected by a time sequence. Similarly, when modeling processes, it is very useful to create a structural breakdown that helps you understand the logic of the process and remember to perform any important function. If two different organizations perform the same process, then their functional breakdown of work will be the same, although the order of execution of work may change taking into account their differences organizational structure. Thus, the functional model is weakly dependent on the organizational structure and can be considered as a reference model.

Often a functional model is mistakenly called a process map; for example, the SCOR (The Supply-Chain Operations Reference-model) and ETOM (Enhanced Telecom Operations Map) models contain hierarchies of functions and value chains, but not processes. Even the TeleManagement Forum guidelines call for a distinction between a process as a sequence of actions performed and a process as the direction of a company's activities.

Aspects of the Behavioral Perspective

The behavioral perspective, which describes the dynamics of the system, answers the question “how do the participants perform?” To model it, a control flow diagram is used. The main question is “how?” can be divided into three: “In what order are the operations that make up the process performed? What time is the operation performed? Why are operations performed in a given order?”

The answer to the first question is given by business logic, which represents a procedural description of the order of work execution; a work flow diagram is used to display it graphically. The answer to the second is given by the process execution schedule, which determines when this or that work is performed, the time spent not performing it, and the actions taken in case of violation of the execution schedule. The answer to the third question is provided by business rules, which are a declarative description of the restrictions imposed on the process.

Business logic of the process

The sequence of operations that form a process is usually called business logic, and work flow diagrams (UML, EPC, ABC Flowchart - descriptions based on flowcharts) are used to describe it. Business logic contains explicit, prescriptive information about the route of process execution, but only indirectly takes into account the criteria for making relevant decisions.

The process diagram includes a “branching” element, which allows you to direct the execution of the process along one of the predefined routes in accordance with predetermined conditions. Branching is an element of business logic, and the condition by which branching is carried out is a business rule. Often business analysts do not separate logic and rules and place a branching element on the diagram but omit the associated branching rule.

Diagrams that describe business logic appear visually simple and clear because they do not include business rules, execution schedules, and corrective actions taken when process indicators fall outside acceptable ranges, so many analysts use them for coordination with business representatives. However, simplicity is deceptive - IT system developers have to re-collect missing information, and their understanding of the process may be very different from the views of the analyst. As a result, the model does not fully describe the process; the details are not clearly recorded, but exist only in the heads of programmers. As a result, the process model on paper does not correspond to the logic of the IT system - it is these inaccuracies in the initial description of the business process that lead to numerous modifications that arise at the stage of implementation of information systems.

Business rules

A business rule is generally understood as a statement that defines or limits some aspect of a business. Unlike a procedural description, rules postulate restrictions on the execution of a process, but do not specify how exactly the result is intended to be achieved. Business rules expert Ronald Ross gives the following classification of business rules:

• rules of behavior determine the need to perform the appropriate action and implement control actions;
• definition rules establish the criterion for the applicability of any business concept called a fact;
• calculation rules help to find out the values ​​of the desired quantities, called facts; for example, a trade discount can be determined by the total volume of purchases for a certain period, etc.;
• classification rules help verify the truth of facts; for example, a client is considered a VIP if he has a certain amount in his account and has no outstanding payments.

The branching of the process is carried out on the basis of a behavior rule that switches routes in accordance with the value of the argument, which takes the values ​​“true” or “false”, but what is “true” and what is “false” is determined by the classification rule, which, in turn, must receive as input some value obtained using the calculation rule. For example, imagine the following sequence of actions: calculate the discount amount as a function of the size of the current order (calculation rule); classify the discount size: large, medium, low (classification rule); submit the transaction for approval to a manager with the appropriate level of authority (rule of conduct). However, the vicious practice of placing a “branching” element on a diagram with both the rules of behavior and the rules of definition directly included in it has become widespread, which makes the diagram inflexible and the description incomplete. So, all the rules should be explicitly separated into separate constructs on the workflow diagram, which will help the analyst clearly localize the corresponding logic.

Execution Schedule

In the field of material production, a widely used work schedule is used to calculate the time spent on the production of a product. For business processes, the work schedule has more complex look, since each operation can be completed on time, but the entire process can be delayed due to returns back for re-processing.

The time ontology used to describe business processes contains two basic concepts: events and intervals. An event is a point on a time scale that has no duration. Events are used to coordinate the execution of different processes or branches of the same process. An interval is understood as a segment on a time scale between the initial and final events. Intervals allow you to determine the time limit allotted for the execution of an individual operation or group of operations.

When comparing business process modeling notations, you should analyze whether they operate with the basic concepts of “event” and “time interval”. This helps to understand whether the notation allows you to model the timing characteristics of a process and coordinate the execution of processes and their branches. Our observations show that many business process modeling notations do not use these basic concepts.

Degree of detail of business logic

To answer the “how?” question, the control diagram must contain as many detailed description actions that make up the process. Many analysts limit themselves to listing functions, without specifying the details of their execution, assuming that the performer knows how the work should be done. However, in practice, employees tend to perform work based on their individual experience, which leads to high variability in process execution. Modeling notations do not determine the level of detail of the description, leaving this issue to the analyst. Let's define the criteria for detailing.

The guiding document of the Russian State Standard, “Methodology of Functional Modeling IDEF0” introduces the concepts of “action” and “operation”. An action is defined as “the transformation of any property of a material or information object into another property,” and an operation is defined as “a set of sequentially and/or parallel actions performed.”

Let us clarify these definitions for the case of process modeling. Action we will call the work performed by a participant on a process object that changes this object, but does not lead to a change in its state; for example, a participant has entered new data, but this does not mean the end of processing the application. Operation we will call a set of actions leading to a change in the state of an object; for example, after all checks have been completed, the application may be approved.

A work flow diagram is usually limited to the activity level. It is believed that excessive detail makes it difficult to understand the logic of the process. The control diagram should give a comprehensive answer to the question of how the process is executed and have detailed levels of actions. As a result, such diagrams turn out to be overly detailed and risk being overloaded with details. However, this is rather a matter of modeling style - multi-level structured models can combine the simplicity of business logic at the top level of the diagram and the detailed description of individual actions at the bottom.

Degree of completeness of the business logic of the process

Most work flow diagrams describe a limited set of execution scenarios, identifying only the most obvious routes. They do not include rarely executed scenarios and ignore special and exceptional situations. Such an incomplete description of the implementation has a right to exist when it is planned to develop a functional information system, where a person determines the order of execution of operations. However, when building a process-oriented system, the order of operations is determined by the system itself, therefore, the model must cover all possible execution scenarios, including returns of control to the previous step or overtaking transitions that bypass certain processing steps, take into account the possibility of escalating the problem, handling exception situations, otherwise the operation of the system will turn out to be impossible.

Comparative analysis of EPC and BPMN notations

We have shown that a distinction must be made between work flow diagrams, control flow diagrams, and process model diagrams. A work flow diagram defines the business logic, the order of execution of operations, has activity-level detail, does not include a process execution schedule, and may not fully define the business rules of the process. The control flow diagram clarifies the work flow diagram in terms of the execution schedule and business rules, has a detailed level of actions, must describe all execution options, in other words, it describes a technology that guarantees the achievement of the planned result in the event of the exact execution of a predetermined set of actions. In the absence of at least one component, the description will be incomplete and the technology will not be followed. A process model is a collection of interrelated perspectives, each of which describes individual aspects of process behavior, and together they form an integrated, comprehensive and complete view of the process and its execution. Among other things, a control flow diagram describes the behavioral perspective of a business process model.

EPC notation is a means of describing the business logic of a process. As the comparison shows, the notation allows you to implement basic business logic patterns without being inferior to other process description notations. EPC diagrams often do not include business rules, but this deficiency should not be attributed to the notation per se, but to the methodology of application. As for the execution schedule, it should be noted that there are no tools for modeling execution time characteristics. The EPC notation contains an “event” construct, but it is used to describe the state of a control object, and not to synchronize execution. The EPC methodology does not focus on the degree of detail and completeness of the resulting diagrams, leaving this issue to the analyst. In the absence of strict regulation, analysts strive to ensure simplicity and readability of diagrams, therefore they limit themselves to describing the level of operations and do not strive to identify all execution routes. EPC notation is often used for automation using function-oriented systems, where a person plays a leading, directing role, so the absence of any execution script is not dangerous. All this allows us to classify EPC models as work flow diagrams.

The notations included in ARIS have extremely powerful process modeling capabilities, but are not supported by open and user-accessible methodologies. The document “ARIS Methodology” does not describe the methodology, but the rules for using the notation, which allows for wide possibilities for “interpretation” of modeling methods.

The problem with EPC is the attempt to adapt this tool to solve too broad a range of problems, without explaining the rules of application for a specific case. As a result, analysts apply many designs and mechanisms intuitively and unconsciously. Sometimes their intent can be understood from the context of the problem, but it is unlikely that a modern computer will be able to analyze the context itself when converting the diagram into an executable format.

BPMN notation describes the logic of the process. A little best support business logic patterns, compared to EPC, is not a decisive advantage. The notation operates with the concepts of “event” and “time interval”, and contains means of synchronizing process branches with each other and processes with each other. The notation itself does not recommend separating logic from rules, but guidelines for proper modeling style do include such a recommendation. The BPMN notation is used to create process-oriented systems, where a person plays a subordinate role, and the system plays a leading role, so skipping one, even the most rare scenario, will not allow the work to be completed and, therefore, is unacceptable; accordingly, BPMN models cover all execution scenarios. BPMN models are executable models, so they describe all the details, down to the most basic actions. All of the above allows us to classify the BPMN diagram as a control flow model.

The problems with BPMN notation are related to the fact that diagrams, as a rule, are overloaded with details and details, and therefore difficult to read. The solution seems to be the development of a methodology for constructing hierarchical multi-level models, where the top level describes the execution context of the entire process, the middle level describes the execution logic, and the bottom level describes the details of the implementation of individual operations.

Interest in BPM and BPMS (Business Process Management Suite) has reached a level of maturity where it is no longer necessary to talk about fashion. In addition, the war of standards ended and the BPMN notation received recognition from all major players, becoming a de facto standard. This event can be compared in significance to the emergence of SQL, which became the basis of modern information systems.

BPMS has finally emerged as a class software for support graphic modeling business processes, execution of business process models, monitoring and analysis (Business Activity Monitoring, BAM). However, different products implement this functionality in different ways, and when choosing a specific BPMS, you should first consider the following.

• BPMN support. Which version of BPMN is supported (1.x or 2.0)? How complete is the implementation: are messages, signals, transaction subprocesses supported?

• Type of BPMN process engine. Direct execution is preferable to translation into some other representation - only in this case is it possible to implement continuous improvement of business processes in practice.
• Communication between processes and data. It is preferable to store attributes about
process to the maximum open form– in tables and columns of a relational DBMS, which provides referential integrity, high operational characteristics and freedom of access to data from the outside, as opposed to, for example, storing attributes as an XML string.
• User interface. The interface should be functional and ergonomic
and be developed quickly, possibly without programming. The system should allow a business analyst to create a working user interface, which, if desired, can be modified with the involvement of a programmer.
• System platform. Depending on the company’s technical policy, the choice
may be limited to the Java platform or. Net – BPMSs that support both platforms are rare.
• Licensing scheme. Shareware systems allow you to save money
licenses, but require large development resources; Some commercial systems are expensive even with minimal configurations.
• Availability of a representative office or partner in Russia.

It should not be forgotten that BPMS is only one of the components of BPM, and for the success of a project to create a business process management system, competencies in methodology and in agile project management are also required.

Anatoly Belaychuk ([email protected]) – President of the company “Business Console” (Moscow).

Problems with translating an EPC diagram into an executable format

The results of modeling in EPC notation do not always lead to the creation of a model that can be converted into an executable BPM format without significant modifications.

Let us list typical modeling errors.

For novice analysts, the EPC model describes the most likely execution option, omitting rarely used alternative routes: in their diagrams you rarely see descriptions of actions in non-standard and exceptional situations.

Very often, models do not fully capture all decision-making criteria. As a result, the model has to be re-developed to refine the business rules.

Analysts do not pay attention to changes in the process control object. Let's imagine a description technological process, including the production of components. If components are produced to order, then you can include a description of their production in the main process, but if components are produced asynchronously to the main part, then their production should be a separate process with its own control object. The analyst must carefully monitor the process control object, since its change is a sign of a possible division of the end-to-end process into a chain of interacting processes.

An insufficient degree of detail in the process leads to the need to re-clarify and describe missing details at the stage of preparing requirements for the IT system being developed.

EPC diagrams do not describe execution schedules and omit issues of synchronizing branches of one process with each other and with other external processes.

Thus, it can be said that the problems of EPC lie in the area of ​​the methodology of its application, and with the presence of a modeling agreement that would define all the details of the model being developed, most of the problems, with the exception of timing parameters of execution, could be avoided.

It is not the notation, but the methodology that determines whether a model is functional or process. A process model is a multi-layered description that includes interrelated descriptions of functional, behavioral, informational and organizational perspectives. To describe the behavioral perspective, you should use a control flow diagram, which gives a comprehensive answer to the question “how is the process executed?”, including defining the sequence of operations, business rules, execution schedule, detailing the level of actions and describing all possible execution scenarios. A work flow diagram, which is unjustifiably called a process model, does not describe all the details of process behavior and is not a process diagram.

Many models that are used in reengineering practice do not satisfy all of the listed requirements and therefore cannot be called process models. The question arises: maybe this is where the failure of these business process reengineering projects lies?

Literature

1. B. Curtis, M. Kellner, J. Over. Process Modeling, 1992.
2. eTOM, Representative process flows. ITU. s.l.: Telecommunication Standardization Sector Of ITU, 2004.
3. R. Ross. Principles of the Business Rule Approach. Addison-Wesley Professional (2003).
4. C. Pedrinaci, Domingue, A. Alves de Medeiros. A Core Ontology for Business Process Analysis, Proceedings of the 5th European semantic web conference on The semantic web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008.
5. Functional modeling methodology IDEF0. Moscow: Gosstandart of Russia, 2000.
6. N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Workflow control-flow patterns.
7. Methods ARIS 7.0. Saarbrucken: IDS Scheer AG, 2005.
8. B. Silver, BPMN Method & Style. Cody-Cassidy Press, 2009.

Igor Fedorov ([email protected]) – Director of the Process Management Competence Center at MESI (Moscow).

Business process modeling, modeling perspective, functional and process modeling

"Kites, blind man's buff and tag
Hide and seek, balls, leapfrog, and skipping ropes,
And simple, and simple, and just jump ropes,
Well, simple, simple, just jump ropes!!!”

A. Vratarev

While preparing this article, I discovered an incredible fact: about the EPC notation, so simple and so popular (there are opinions that it is even more popular than BPMN), there are articles on Wikipedia in only 4 languages: English, German, Czech and Uzbek. Moreover, these articles are quite short. Perhaps by the end of the article you and I, dear reader, will understand why.

Let me start with the fact that the EPC notation was developed in the early 1990s. during the development of the ARIS methodology, as, say, its process component. The founding father of the EPC is considered to be Professor Wilhelm-August Scheer, whose name alone inspires awe in the average person (say it out loud and feel inspired). What can we say about the name of the faculty where this respected guy worked: Institut für Wirtschaftsinformatik of the University Universität des Saarlandes.

The purpose of creating the EPC notation was the ability to describe processes so that the functions performed within them have global semantics within the diagram, which means that the execution of a function on EPC diagrams is not necessarily clearly defined, but may be dependent on the state of other nodes of the diagram, sometimes very far away from each other.

The name of the notation stands for Event-driven Process Chain, which clearly indicates that the central element of EPC notation diagrams are events. Events give rise to the performance of certain actions by certain participants. The completion of actions, in turn, generates another event, and so on, until the system reaches a state, the appearance of which within the process is considered the final event.

To clearly demonstrate the capabilities of notation, I will use an everyday example, inspired by a recently completed vacation in warmer climes. A receptionist at a respected hotel, Ivo Petkov, receives a request from one of the guests for an urgent replacement of wash supplies in his room. It is quite clear that his task is to fulfill the client’s request, and in EPC terms, to bring the system from the state “Received a request from the client to change washbasins” to the state “Client’s request has been satisfied.”

We display the two indicated states on the draft diagram and immediately notice how easy our diagram will be to read, because each of its elements has not only its own shape, but also its own color. Thus, events are red hexagons, functions are green rectangles with rounded edges, and performers are depicted as yellow ovals.

So let's go back to the example. Immediately after receiving a request from a client, Ivo must send a request to fulfill the client’s request to the maid, thereby bringing the system into the “Fulfillment request sent” state. The maid, using the supplies available in the warehouse, fulfills Ivo's request. And here, for the first time, parallelization of our process appears: if the maid understands that the necessary washing supplies (say, shower gel) are not currently in stock, then she herself, perhaps unwillingly, transfers the system to the “Fulfillment of the request is impossible” state. from which it naturally follows that Ivo will have to have a not very pleasant conversation with the client, and what state the system will go to depends only on the client’s disposition and his tendency to fight. If the warehouse has all the supplies necessary for the guest, then the maid successfully fulfills the request transferred to her, reports the fulfillment to Ivo, who in turn reports this to the client. And everyone lives happily ever after and dies on the same day.

This simple process is reflected in such a joyfully winking red, green and yellow diagram as in Figure 1.

Rice. 1. EPC diagram of the process of processing a customer request in a hotel

And now, according to tradition, the advantages and disadvantages of notation.

When I first encountered EPC diagrams, I, as I mentioned earlier, was very pleased with how easy they were to read: each block is highlighted in shape and color, it is very easy to see the performers, the required materials, highlight the list of possible system states, the list of those being performed in during the process of functions. This is undoubtedly a huge plus: the customer will not have any difficulties in reading the business process diagram when implementation of EDMS, if it is presented exactly in the EPC notation. However, perhaps the customer will be confused by such a gigantic number of states, because in fact, because of them, the circuit grows greatly. Even in our example: some 4 functions generated as many as 5 states (not counting the initial one). Sometimes you wonder: why point out all of them. Let us tell you why it is necessary after agreeing on the contract general director indicate in a separate block “Agreement agreed”, and after signing - “Agreement signed”, if further the process still remains linear. Frankly speaking, there is no need, unless you are Captain Obvious.

And sometimes it is not clear how to identify the state into which the function will transfer the system. Even while preparing this simple example, I experienced certain difficulties associated precisely with this moment.

The advantage of EPC diagrams is the fact that, like IDEF0 diagrams, you can indicate the input and output data of each function on them, and trace the logic of the movement of input and output data from block to block. In addition, unlike the same IDEF0, it became possible to parallelize the process, directing it along only one of the alternative branches (in IDEF0, if we add parallelism in execution, then all parallel functions will be executed simultaneously). It also seemed to me an advantage to be able to specify the performer for each stage (read: functions).

But! In IDEF0, the executor is indicated once at each decomposition level, and arrows are drawn on his behalf to all blocks executed by him. In EPC, in order to calculate how many actions an executor performs, we need to go through all action blocks and check whether the executor we need is indicated in it.

This notation seemed very convenient to me from the standpoint of monitoring the execution of the process: each function certainly transfers the system to a new state, from which it follows that after executing each function, the system can be checked whether the transition to the desired state was actually carried out. But the question immediately arose: is this really necessary? For example, I rarely have such a desire =)

So, in general, the EPC notation seems to me inconvenient for describing business processes: too much attention to events, too little attention to actions and especially their grouping based on the performer or the materials used. Yes, she is simple, yes, she is beautiful, and yes, unfortunately, that’s all I can say about her, like probably many other people. =)

And articles about UML and BPMN notations are getting closer and closer.

(4.14 - rated by 21 people)