Notes for business

Music has tied us
Became our secret

All epigraphs for this article are taken from the song "Music has connected us" by the Mirage group.

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

Similarly, a business that has grown as a skillful improvisation to move to a new level requires putting the 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 their own". This circumstance prompted me to write this article. Unfortunately, most of the documents that happened to be seen were of little use for a serious matter. It cannot be said that they were fundamentally wrong, but a number of omissions spoiled them so much that one wanted to immediately forget about their existence. What are these omissions, and how to deal with them, we will figure it 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 demands it.

Am I on my own
I can't find all the answers

This article is addressed to those who want to save on the description of business processes by entrusting the preparation of the document to internal specialists. After all, a description of business processes is not a mandatory thing for a company, and everything works without it. But in any stable company there is a mechanism for the transfer of 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. The accumulation of business processes in a general description is necessary in order to make the business more transparent, especially for its sale.

The document "BP Description" 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. Introduce a participant in the transformations up to date,
3. With a pen and not on the fingers, set the task for the heads of departments and external specialists.

There are advantages to preparing a document on your own:

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

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

IDEF0 notation

An example of describing a BP using IDEF0

Don't lecture us

Don't lecture me
Mom, it's useless

Is this what we need? - The director will ask, reasonably assuming that compliance with all standards will significantly increase the cost of the result. One of the directors I knew reasoned like this: “Inviting an outside specialist is an expensive business, but our tasks are simple - why do we need all these notations. And that's what you have to pay."

I agree, if the tasks are simple, why fence the garden. And if they are complex, then it is necessary to simplify, and not complicate 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 are not invented to keep the consultant from getting bored... Anyone who is in business knows very well that not everything useful is obvious. Well, let's look for a hidden positive and for this we look into the history of the issue.

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

The use of ARIS notation requires a great deal of detail in business processes.

The introduction of ERP (resource management), CRM (customer relations), MRP (production planning) class systems inevitably leads to a change in processes, and if this is not planned in advance, the result may be worse than you want. In addition, automation is work 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 the introduction of automation have not taken root with us 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 describing 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 the regulations defined by law. The Bank operates on the principle of day-to-day management. As a result, even the simplified description of the Bank's business processes (in Russian without the use of notations) turns out to be more detailed, because relies on a foundation built on volumes of regulations that define standards, terminology, roles, and rules. These standards are the common language in the banking environment and the description of business processes will be easy to read for any specialist.

In commercial structures, the description of business processes requires a preliminary glossary of terms. And starting to prepare and coordinate it, many are faced with the fact that the same things in different departments are called differently. Going into details, it turns out that different names really carry different shades of meaning. Terminology harmonization is one of the most time-consuming processes for describing BP. It is important to start and run this process. I can take most of the work from my own divisions of the company, because the need to regulate their activities leads to a greater organization of processes and procedures.

When a 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 "in hot pursuit" and is one with the system documentation.

stave

I forgot everything
We have been taught for so many years

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

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

EPC notation

Description of a business process using EPC

If the 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, the ability to use a familiar software tool is also an important criterion. For example, Microsoft Business Solution in 2002 offered the On-Target notation for the Navision information system, accompanied by a special software solution. This is the case when it is better to choose something else - not only that, no one knows the On-Target notation, but also the software environment will take time to study it. A positive example, I would call the use of IDEF notation, and the Visio program, which is very common and has the necessary set of tools for drawing IDEF diagrams (Fig. 6).

IDEF Business Processes Made in Visio

Of course, the description of the BP can be made simply in words, as well as drawn with various symbols (of your own invention), as it seems understandable. Having such a description is better than nothing, but standards are still useful.

Fullness and depth of sound

I don't know what draws me here

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

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

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

Melody is a sequence of sounds, not notes

forget about this day
Nobody needs a fight

So you can describe the BP and just words, without any notations. With the notation, of course, it is more correct, but this is not important. Description BP is not a final product, but only a tool for new achievements. This means that it must be adapted for further active use. The main problem with most do-it-yourself documents is the inconvenience of using them. For example, one such document consisted of a description made in Microsoft Word and drawings made in PowerPoint, it was terribly inconvenient to jump from program to program, it took a lot of time to just bring it all into one document. It turns out that the document should have the following properties:

1. Have a clear order and grouping of sections, i.e. be conceptually holistic (usually this means that if you are a concept, then you have learned how to use it);
2. Clearly identify business units and give them understandable names and numbering;
3. Clearly identify business processes and also give them a clear name and numbering;
4. The elements should be numbered in such a way as to avoid confusion (this greatly facilitates the search): for example, Department No. 1 should have the number Otd001 in the document, and Business Process No. 1 should have the number BP001;
5. The document must have a content 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, with business units and departments. Hyperlinks can be used to reflect these links - this will facilitate the search for information and the transition from one object to another.

For the case, you can use any text editor that supports hyperlinks.

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

Businesses have similar challenges. There are few good specialists who know their company from head to toe, and they are very busy. Analyzing business processes on our own, we save money, and maybe save time. But it is not always possible to tear off the best ones for the description of the PSU. You can entrust the routine to performers with 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 the preparation of a document is possible in an alliance, a key specialist and an experienced consultant. The result will be an agreed language for describing business processes (that is, the terminology of the company's business) and the description itself in detail sufficient to solve further problems.

I repeat all the persuasion in response
We won't be separated, no

We remind you that all the epigraphs for this article are taken from the song "Music Tied Us" by the Mirage group

An external consultant will write the document in a notation language that other consultants understand and often more appropriate for the case. You do not understand all these hooks? But these notations are not difficult at all, maybe it is worth learning them?

The purpose of EPC is the planning and description of workflows, the lower (operational) level, business processes. The main elements for building diagrams are events and functions. Business processes, in the EPC diagram, are depicted as sequences of alternating events and functions.

Scope of EPC

The EPC diagram is a standardized graphic diagram for modeling business processes, applicable for:

• Modeling and documenting business processes as is (as is)
• Description of possible improvements to existing business processes (to be)
• Identification of all participants in the process
• Identification of all information systems, resources and documents involved in the process

To get a better idea of ​​the EPC diagram, we advise you to visit the links:

• Introduction to EPC

  The link leads to an introduction to the EPC. Suggest to visit the link first.

• Elements and Structure of EPC Charting

  The link leads to the description where the most important graphical elements of the diagram are presented. The presentation of the elements and their use is perfectly structured, it will be very convenient for you to navigate.

• Examples of rules for constructing EPC diagrams

  The link leads to a document where examples of diagramming are described. P.S. In this case, we are only interested in the information presented in the fourth chapter from page 86.

Other useful materials:

• The link leads to a collection of training materials on the ARIS methodology.

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 in the course of the process must alternate. Decisions about the further course of the process are made by the functions.

The recommended number of functions in the diagram is no more than 20. If the number of functions in 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 corrected.

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

The events and statements surrounding the function in the overlay diagram must be the start/outcome 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 one, the branching operator must have only one incoming link and at least two outgoing ones. 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 "OR (OR)" or "XOR (Exclusive OR)" operators. Operators can merge or branch only functions or only events.

Rice. 2.62 Example of a process diagram in EPC notation

Rice. 2.63 Acceptable situation example 3	Rice. 2.64 Acceptable situation example 4

An example of an invalid situation.

Rice. 2.65 Example of an unacceptable situation

Statistical Process Control Methods

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

Pareto Chart Analysis

All sorts of problems constantly arise in industrial enterprises: the appearance of defects, equipment malfunctions, etc. In most cases, the vast majority of defects and related losses occur due to a relatively small number of reasons, with the share of material costs being about 70 - 80%. To find out which of these causes 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 that affect the problem under study. There are two types of Pareto charts: by results of activity and by causes.

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

Cost: volume of losses, costs;

· Safety: accidents, accidents;

· Terms of deliveries: failure of terms, shortage of stocks.

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

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

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

· Working methods: sequence of operations, production conditions;

· Measurements: accuracy, reproducibility, stability.

The construction of the Pareto chart consists of the following steps.

Stage 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 collected.

Step 3. Complete the data entry sheet and calculate the totals.

Step 4. Develop a table template for data checks, providing a graph for the totals for each checked feature individually, the accumulated sum of the number of defects, percentages of the total, and accumulated percentages. Arrange the data in order of importance.

Table 3.1.1 Building a Pareto chart

Step 5. Draw one horizontal and two vertical axes. Vertical axes: on the left axis, apply 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

Step 6. Build 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 is 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 sampling, type of products, batch of materials, operator, etc.);

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

 Chart should be done 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).

EPC standard

EPC (Event-Driven Process Chain, event chain of processes) is a notation for displaying the progress of a process, the key elements of which are Events and Functions. The EPC notation was developed in the 90s of the XX century. EPC was invented by the German professor Wilhelm-August Scheer as part of the ARIS methodology.

A business process diagram in an EPC must begin and end with an Event. The Function must always be followed by an Event, i.e., the execution of the Function creates some event (state). Documents, organizational links, information and material flows, elements of the information system (software, databases) have their own graphic designation. For process branching, operators AND, OR, exclusive OR are used.

EPC is used at lower levels of business model description when the task is to describe the detailed flow of a business process. EPC functions can be decomposed (broken down into detailed business processes in EPC notation only).

The disadvantages of EPC include the fact that this notation has a very wide set of graphic elements, which can be difficult to understand compared to other notations. To develop processes in this notation and read them, preliminary training of employees is required.

The advantages of EPC include the ability to describe the execution of a business process in a very detailed and accurate way, to show in a diagram in a graphical form all the performers, all the objects used. Also, the advantage of EPC diagrams is the fact that, like IDEF0 diagrams, they can indicate the input and output data of each function, 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 only along one of the alternative branches (in IDEF0, if we add parallelism in execution, then all parallel functions will be executed simultaneously). The advantage also seemed to me the ability to specify the performer for each stage (read: functions). But, in IDEF0, the executor is specified at each level of decomposition once, and arrows are drawn on its behalf to all the blocks it executes. In EPC, to calculate how many actions an executor performs, you need to run through all the action blocks and check if the executor we need is indicated on it.

This notation turned out to be very attractive from the point of view of monitoring the execution of the process - each function will certainly transfer the system to a new state, which means that after the execution of each function, the system can be checked whether the transition to the desired state has really been made.

In general, the EPC notation is recognized worldwide as one of the best notations for building business processes and modeling the operation of an enterprise.

Choice of modeling method

The BPMN methodology was chosen to model the required business process. This choice is due to the fact that the BPMN notation allows you to most accurately display the logical processes that occur when performing tasks that require a highly accurate description of the sequence of actions, demonstrate the interaction between employees and the client, and also allows you to show the time gap between the execution of some tasks.

Every thing is a form of manifestation of infinite diversity.

Kozma Prutkov

Introduction to eEPC notation

Currently, there are many different principles of graphical representation of business processes, called notations. Why are there many? This question has been asked for decades by everyone who is faced with the need to describe business processes. Let's look at the reasons. There are three (in my opinion):

• -Miscellaneous tasks. Not all notations are equally convenient for solving various problems. For example, a notation can be convenient for a top-level business process and not at all convenient for describing a workflow.

Different developers of such notations. At different times, different developers tried to come up with new principles for describing circuits. They did this out of good intentions, when in practice they encountered a situation where the notation they used could not reflect the necessary subtleties (or not visually). Sometimes, in the process of evolution, such notations have become, as it were, parallel, i.e. look different, but solve the same tasks.

The desire to stand out. This is when, for unknown reasons, a new notation suddenly appears, which does not have anything outstanding in itself, but, for some reason, is promoted by its creator as the most perfect know-how. This is still happening.

The purpose of this article is not to consider all kinds of notations (I deliberately do not name them), but to dwell on a detailed description of the notation that I chose for my projects in the process of a long search for the most optimal option.

If anyone is interested in knowing what other notations are and what they are used for, I plan to do this in another article, which will be called "Let's talk about notations", but this is still in the plans.

It's time to start our story about a very interesting, simple and practical eEPC notation (in translation: an extended description of the event chain of processes). In its literal translation, the main purpose is also revealed: a description of the chain of business processes. The main "trick" of the notation is in its principle of "eventfulness", which we will consider in detail.

What are the advantages of eEPC notation:

1. Firstly, this is not quite a pure notation. Those. if in some notations there is a rigid set of elements and rules for their use (otherwise everything will get confused), then the eEPC principle allows you to add your own elements. How is it provided? Of course, there is a certain "core" around which everything is built, i.e. a set of clear rules by which the scheme is built and by which it is then read. In addition, you can add your own element, include the rules for its use in your own corporate standard (to exclude amateur activity that can confuse the scheme and complicate its readability) and that's it! This is a very important point. In addition, you can set any other restrictions and rules in your corporate standard.
2. eEPC contains elements of logic. This allows you to build schemes with conditions that are necessary to describe the activity (“if the contract is agreed, then ...., otherwise ...”)
3. The simplicity of the elements allows you to draw diagrams both in software products and in any other way, even on paper, you will not get confused.
4. eEPC is so easy to learn and understand that it can be used in real life, not just gathering dust in a closet. It will take about 2 hours to learn the rules (if the student wishes).

Of course, like everything in this world, it has its drawbacks. But rational use reduces them to a minimum. The main drawback, in my opinion, is the fact that if we use simple tools (ie programs for drawing diagrams, and not for modeling business processes), then we do not have a single database of objects. In addition, it is difficult to control inputs and outputs (it is necessary to control them, that is, to come up with a way of such control, if necessary). But, on the other hand, the use of complex business process modeling tools costs quite impressive amounts, and the project with their use is measured in millions. And so we have a very economical and understandable tool. To be more precise, this shortcoming refers specifically to the method of description I am considering, i.e. using MS Visio or similar software. If you use specialized systems for describing business processes that support object databases, then this disadvantage can be avoided. Well, it's time to start...

The main "core" of the eEPC notation

As I already mentioned, in the literal translation of the abbreviation eEPC lies the concept of eventfulness. This is a very important point on which the whole principle of constructing a circuit is built. So, there are two key concepts: "Event" and "Function". When someone first tries to draw their process in the form of an eEPC diagram, the question often arises, what is the difference between an event and a function? This must be clearly understood, otherwise you will get an unpredictable result. So: an event is a fact of accomplishing something, and it does not have a duration in time, or this time tends to 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. Let me explain with an example. The phone rings. The manager picked up the phone. In this case, "The phone rings" is an event. Phone conversation is a function. The conversation is over (hung up) - again an event. Thus, an event chain is observed: Call - conversation - end of the call. And the end of the call will most likely require the execution of a new function: recording the result of the call, etc.

Let's try to draw it. First you need to figure 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 eEPC notation. I think I need to say a few words about the colors used. If you came across the description of processes in other notations, as a rule they were black and white. And this is correct, there should not be an explicit dependence of the content on the color, because the diagram can be drawn with a pencil on paper, printed on a black and white printer, etc. In this case (in the eEPC ntation), it has historically developed that the elements have certain colors. Not to say that it was necessary, but the habit is developed, and the perception in electronic form is better - you can immediately see what is what. These colors can be considered as a recommendation. Why are they like this? I’m not sure exactly, but it seems to me that when ARIS made support for the eEPC notation in its product, it gave them such colors, and they “took root”. By the way, sometimes this notation is also called "ARIS", "ARIS EPC", which is not entirely correct, because ARIS did not invent this notation, but made support for it in their business process modeling program. In general, I recommend using colors. The main thing is that the very form of the elements should not be the same (i.e. differ only in color), because in black and white, this can be confusing. There are other rules that allow you to give "slenderness" to the eEPC diagram, we will talk about them.

So, there is an event, there is a function. How are they related?

We see that event1 led to the need to execute a certain function, which ended with event2. If applied to the example with a phone call, then it will be like this:

The link event - function - event is usually displayed from top to bottom in one line or from left to right. The direction of the chain is indicated by connecting lines with arrows. In order to make the scheme more visual, the notation provides a few more standard elements:

• Position (performer). The one who performs this function
• Information. Any information used to perform a function other than documentary information. For example, a phone call, instructions for performing an operation, etc.
• Document. The "Document" element is designed to display information media (paper or electronic). Those. presentation of information in a certain structure.
• Program (application). The software used to perform the function.

All other elements are auxiliary, and are practically not regulated by the requirements of the eEPC itself. However, there are no barriers to adding your own elements. The main thing is to fix this in the internal standard so that there is a common understanding of how they look and why they are used. Such an extension does not violate the requirements, if the event-function-event connection is not violated, and is intended only to improve the perception of information or adapt the description rules to some industry specifics. I added my own set of elements, which I will discuss below.

You still need to figure out how the considered elements should be located. All of these elements must somehow be related to the function. It's a general rule that no element other than a function is associated with an event. Those. all these elements must be connected with arrows to the function. As for the arrows and their directions: it is generally accepted that if there is no direction for transmitting information, then instead of an arrow, just a line is displayed. If information enters (enters the input), then the direction of the arrow is from the object to the function, if it exits, then vice versa.

A few more words about the location of these elements on the diagram and we can redraw our diagram, specifying the execution of the call processing function. There are no strict requirements for the arrangement of elements, but it is customary to display them in all diagrams in the same way (for the uniformity and harmony of the diagram). To unify the external view of graphic diagrams of business processes, such rules must be fixed in the internal standard and followed. A little later I will give some recommendations about this. Now let's redraw our diagram:

We see that the operator is processing an incoming call, acting in accordance with the rules for processing incoming calls and using the CRM program for this. Neither incoming nor outgoing documents are used.

As I already mentioned, one of the strengths of the notation is the elements of logic. At the same time, this is one of the most difficult moments to understand. Therefore, first I will give an example, and then we will separately deal with the elements of logic.

Let in our example be like this: if the client is interested, the sales manager conducts further work with him and puts up a commercial offer, which he sends by mail using the MS Outlook mail client. If there is no interest, then the call processing is completed. In real life, it would be nice to use call termination rules, but this is me, by the way, while we simplify it. Here's what happens:

Elements of logic in eEPC notation schemas

The elements of logic are simple, but there are some peculiarities and rules for the scheme to be logical and unambiguously interpreted. The most important rule to adhere to 100%: logical decisions can only be made when a function is executed. Those. after some event there can be no branching. Why? Because in this case it contradicts the very concept of an event - it is simple and instantaneous, without execution time. For example, if the phone rang, and a person is sitting thinking whether to pick up the phone or not, theoretically this will already be a function where he makes a decision. But in practice, including from common sense, he violates the rules for processing calls, tk. he is paid a salary to process these calls, and there is nothing to argue here (in general, as shown in the diagram).

In total, 3 elements of logic are distinguished:

• I. When two or more events happen at the same time;
• OR. When one or more events can occur, but at least one must occur;
• EXCLUSIVE OR. Either one or the other. Those. two options are not possible at the same time.

As you can see, there are two options for graphical representation of logic elements. They are no different, completely different. I brought both of them, because. In practice, both options can be seen in various sources. Which one to use is up to you. I like the first one more.

Now we need to deal with the use of logic elements. First, let's look at the options encountered, then move on to an example. Let's analyze each element separately.

Logical element "AND". When a function requires multiple events to execute at the same time:

Example: If the reporting period is closed (event 1) and the deadline for submitting a report to the manager (event 2) has come, the employee prepares a monthly report.

The connection of elements, if several events occur during the execution of the function:

Example: Some work with a customer has been completed. Two events were recorded simultaneously: mutual settlements were reconciled (event 1), the act was signed (event 2). In practice, this is rarely used. As a rule, if many actions are combined in one function

Connection of elements, if during the execution of several functions, an event occurs:

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

Connection of elements, if the occurrence of one event leads to the execution of several functions:

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

Logical element "OR".

Connecting elements if one of the events can cause the function to be executed:

Example: An application received by phone (event 1) or an application received by e-mail (event 2) will result in the need to process it.

Connecting elements if one function can fire at least one event:

Example: An invoice has been prepared and sent to be sent to a customer. The invoice could be sent by mail (event 1), by fax (event 2).

Logical element "EXCLUSIVE OR".

Connecting elements when one and only one of the events is needed to execute a function:

Example: A customer came to the store in person (event 1) or made an order via the Internet (event 2). You need to ship the goods (function 1).

Connection of elements, if at least one of the following events occurs as a result of the function execution:

Example: A decision is either made or not.

Connection of elements if the event occurs after one and only one of the functions has been executed.

Example: Goods were delivered (event 1) either by own transport (Function 1) or by a transport company (function 2)

The correct application of logic elements requires some practice. But it's not difficult. It should be noted that not all of the considered combinations are widely used in practice (in general, this is determined by the analyst's way of thinking). Try to apply elements of logic in practice. If there are difficulties, write to me, I will try to help.

Extending Notation with Your Own Elements

As I said, eEPC is not exactly a notation, but description rules. And these rules do not prohibit adding your own elements to the scheme. The main thing is that these elements are understandable, and there is a document where such element extensions are fixed. For example, I use the following additional elements that have emerged gradually in the process of describing real processes for various tasks, from a simple description to setting tasks for automation.

Data file. Used when a data file is created as a result of an operation, or a file is used to perform an operation.

Database. Used to describe information flows between automated systems.

File cabinet. Used to display a paper filing cabinet or archive.

material flow. Used to indicate the incoming and outgoing material flows, as well as the resources consumed during the execution of the process. The material flow is displayed to the left of the accompanying documents.

information cluster. Used to denote structured information (entity representation). The diagram can be used to refer to documents generated programmatically using custom applications. In this case, the "Cluster" element is located to the left of the corresponding document. Those. indicates that the user not only created a paper document, but also created an instance of it in the program.

Conventions on the rules for placing shapes on a diagram

The eEPC notation itself does not impose strict requirements on the arrangement of elements relative to each other, although it is customary to draw a diagram from top to bottom or from left to right. If this is not unified in the case of the work of several specialists, then a kind of “vinaigrette” may turn out. To avoid this, it is recommended to develop and approve your own rules for the arrangement of elements. I adhere to (and recommend) the following rules:

• The sequence of events and functions is arranged from top to bottom (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 at the top left of the functions; arrow direction from documents to function;
• Outgoing documents at the bottom left of the functions; arrow direction from function to documents;
• The "Information" element is located at the bottom right of the function. If there is not enough space, an arbitrary arrangement is allowed, as close as possible to the function;
• The "Application" element is located at the top right of the functions. (if file storages that are not reports are used for this, they are displayed similarly). Communication without an arrow.
• Elements "Database" and "Card file" are located arbitrarily;
• The "Material flow" element is located to the left of the documents accompanying it with reference to the document by a line without an arrow;
• The "Cluster" element, when used in combination with the "Document" figure to designate a document in electronic form, is located to the left of the corresponding document.

For example: Payroll Calculator calculates wages on the basis of the documents "Brigade Outfit" provided to him. At the same time, he is guided by the document "Regulations on wages", the calculation is made in the program "1C: ZiK". The result of the calculation is the document "Vedomosti".

Identifying Elements in a Diagram

As you know, a competent approach to the description of business processes involves their identification, i.e. when each process has its own code name. Accordingly, individual functions within a process also have their own names and identifiers.

Figures "Document" and "Function" are subject to mandatory identification in the diagram.

The document is identified by indicating the code of the report or document in the upper left corner in accordance with the registry. Documents received from suppliers of goods and services (incoming) are identified only by name.

A function is identified by indicating the ordinal number of the function for a given process group. Those. the function number always starts with the process group code. The issues of identifying process groups are beyond the scope of this article, we will consider them separately. Moreover, you should learn how to identify processes before you begin to describe them, otherwise there may be a desire to describe all the activities of the company in one diagram, as they sometimes try to do.

Therefore, now I will only show with an example how this can be represented in a diagram. Let's go back to the call handling example. Let's assume that we have assigned the code "04" to the sales department, the code "VK" to the process of processing the incoming contact. Then the circuit will take the following form (identification is highlighted in red for clarity). The document code at the same time indicates the serial number of the document in the general register of documents (we will also consider this separately when we get to the survey of the document management system).

Feedback display

When building models, it often becomes necessary to cycle through the process according to some condition or to display the activities of decision makers. In this case, we are talking about feedback. To display control feedback, the principle of "direct inclusion" in the process of an additional control function is used, followed by branching (using the XOR logic element). For example:

Text description of processes

No matter how hard we try to display the business process on the diagram, it will not be possible to achieve full detail, otherwise you can get bogged down in endless chains of elements and conditions. To avoid this, as well as to add information to the description of the process that cannot be displayed graphically, the description is supplemented with text accompaniment. For this, various text templates are developed, which are filled in during the description process. The forms of such templates can be different, include separate sections describing inputs and outputs, resources consumed, software used, etc.

In the simplest case, a business process description template might look like this:

Such important topics as collecting information, highlighting business processes, decomposition, and highlighting indicators remained outside the scope of this article. We will definitely study these issues in future issues.