What are business processes? Examples will allow us to better understand this subject, so we will actively use them.

general information

First, let's understand what business processes are. This is the name of the cumulative sequence of certain actions aimed at transforming the resources received at the input into a completed product that has value for consumers at the output. Thanks to this definition, it can be understood that there are business processes within every organization. Whether they are formalized or not, it does not matter. Remember: you can meet business processes everywhere. Examples will be given later in the article.

Let's look at a household example. There is a housewife who wants to wash the dishes (business process). She entrusts this task to the dishwasher. At the entrance we have dirty dishes. During the process, water, detergent and electricity will be used. And at the exit we get clean dishes. Business processes are built according to a similar scheme. The examples that will be given later will only confirm these words.

functional approach

Since we are interested in (specific examples), let's not postpone their consideration, but get down to business right away. Let's say we have a company where management matters. According to him, an enterprise is a set of departments. And each works to perform its specific function. But in such cases, when individual departments are focused on achieving their indicators, the overall efficiency of the company often suffers.

Let's look at one typical conflict process. The sales department requires an increase in the maximum possible assortment in order to increase turnover. However, they also want to always have a stock of goods in stock. Whereas the supply department plans to purchase a narrow range and in large quantities. After all, in such cases they will work efficiently, and their main indicator will grow (more precisely, the price from the supplier will fall). That is, there is an implementation business process that departments look at differently.

Process approach

He views everything that happens as a set of processes. There are basic and supportive. Each process has its own specific goal, which is subordinate to the task facing the entire company. In addition, there is an owner who manages resources and is responsible for the execution of everything necessary. There should also be a system for quality control and error correction. It goes without saying that no process can proceed without resources. And the list of components is completed by a system of indicators, according to which business processes are evaluated. What are the examples of this, because it was promised that they would be? Now let's take a look at one.

Imagine a map. In the very center is located. It is divided into separate components. They are accompanied by a management and support process that ensures that everything is executed as required. This is the process approach. When the work of one element is completed, its developments are transferred to the next.

Description of business processes

Examples of this in general form can be seen throughout the article. But full-fledged documentation is often comparable in thickness to small books (or even large ones if you are studying the work of a giant company).

(examples of which are also given here) requires that all operations of the enterprise be as clear and transparent as possible. This will allow them to be analyzed in the best possible way and to identify various problems even before they fail. It must be remembered that the main task of descriptions is to understand the interaction of disparate units, to track what and to whom they transfer at each stage of the task. Thanks to this, it is possible to significantly simplify and reduce the dependence of the stability of the enterprise on the unstable human factor. Also, with a competent approach, they will be reduced and that's how the description of business processes helps. An example of such optimization can be demonstrated by the manager of almost any successful company.

Development order

Let's look at a practical example of a business process in an enterprise. Initially, we need to take care of the working team of the project. It is formed from the employees of the company. Most often it turns out that one working team is not enough. What then can be done? To fill the lack of forces, you can attract a temporary group. It also helps to create a description of how the process functions at a given time. At the same time, one should strive to identify all the connections between actions, and not fix the smallest details.

To avoid getting sidetracked, standard process maps and forms can be used. When developing processes, it is recommended to use the method of successive approximations. In other words, it is necessary to repeat the cycle of improvement actions until an acceptable result is obtained.

What should be paid attention to?

You should focus on the following sections:

1. standard forms.
2. Map.
3. Routes.
4. Matrices.
5. Block diagrams.
6. Description of joints.
7. Helpful descriptions.
8. Documentation.
9. Expanded description.
10. Definition of indicators and indicators.
11. Execution regulation.

Best of all, the concept of the necessary elements can give a real example - the reengineering of business processes of an existing enterprise. But in such cases, you need to be prepared for the fact that you will have to familiarize yourself with a huge amount of documentation.

Let's say a word about cards

So, we have already considered what business processes are, examples of them in real life. Now let's go through the technical documentation, which should be there if we need an accurate and clear description. So, initially I want to pay attention to the business process map. It is a graphical representation made as a flowchart. At the same time, care must be taken to ensure that each participant has its own separate column. The lines contain time intervals. A fully designed map allows you to check if the operation has been synchronized.

You can also track whether and how information passes between different departments of the company. To get the best effect, several questions should be asked. Who performs this operation? Why does it need to be done? What does she represent? When should the operation be performed? Where is it carried out? When improving the ongoing processes, one should also ask if it can be improved.

matrices

They are necessary to highlight the most important business processes within the enterprise. During their compilation, the interconnection of everything that happens, as well as the degree of mutual influence, is taken into account.

When analyzing the process chain, it is not difficult to find that the exchange of information moves from the upper left corner to the lower right. That is, in this mathematical form, the relationship between the supplier and the consumer is described, presented in the form of a rectangle. In each cell of the matrix, all the necessary requirements for the action that were / are / will be made are indicated. They are a kind of two-dimensional models, with the help of which one can judge what is being done and how, and what goal is being pursued. The difficulties in compiling the matrix here are that in order to calculate with maximum accuracy, it is often necessary to use a significant amount of data. And this implies the presence of a large number. Moreover, in such cases, digital information is usually used, which often still has to be calculated.

A business process (process) is a cumulative sequence of actions to transform resources received at the input into a final product that has value for the consumer at the output.

With this definition, it becomes clear that business processes exist within every organization, whether formalized or not. The organization can accept functional approach to management, which considers the company as a set of departments, each of which performs certain functions.
In this case, individual divisions are focused on meeting their own indicators, but not always on the final result of the company, which can cause a conflict of interest between divisions and adversely affect the overall performance of the business. Theories of Constraints) between the sales and purchasing departments of a trading company. The sales department, in order to increase turnover, requires to ensure the maximum possible assortment and maintain a constant availability of goods in the warehouse, and the supply department buys a narrow assortment of goods in large quantities, because its main indicator of work - obtaining a lower price from the supplier to reduce costs - has nothing to do with increase in company sales.

Advantages of the process approach over the functional one

Process approach considers business as a set of processes- the main business processes, managing processes (setting goals) and supporting. Main business processes are processes that directly earn money. Supporting - processes without which the main ones cannot exist. business processes, these are the processes of providing a variety of resources.

Each business process has:

• its specific goal, subordinated to the general goal of the company;
• an owner who can manage resources and is responsible for executing the process;
• resources;
• quality control and error correction system;
• process scorecard.

The totality of all actions to transform materials and information into a finished product for the client is called value stream. Value stream it is convenient to represent graphically - in the form of a map of business processes. The figure below shows company business process map. The map allows you to visually see the value stream as a whole, understand the sequence and interconnection of processes, as well as opportunities for improvement.

Technology business process descriptions makes all company operations transparent and understandable, allows you to analyze operations and find problems in them that lead to failures. The main thing is that business processes allow you to understand the interaction between disparate units: what, to whom and for what they transmit or receive at each stage. As a result, the process approach greatly simplifies adaptation of new employees and reduces the dependence of the company on the human factor. Importantly, the process system simplifies operating expenses management.

The presence of a well-developed business process systems greatly simplifies bringing the company's activities to meet quality standards ISO 9001:2015. In the context of Russia's completed accession to the WTO, the company's compliance with ISO 9001:2015 standards becomes an important competitive advantage.

The implementation of QMS in an enterprise necessarily requires the creation and description of business processes.

Business process development

Consider the order business process development. First you need to create a working team of the project from the company's employees. Usually, one working team is not enough. Then a temporary group of departments of customers and suppliers of a particular business process is involved in its activities, which provide inputs, outputs and resources of the business process.

In order to understand how the system functions and to preserve the accumulated experience, it is first recorded how the process actually functions now. It must be remembered that the purpose of the description is to identify the links between the actions taken, and not to capture the smallest details. So description of business processes it is recommended to standardize using standard forms and process charts.

The description of the business process can be divided into the following sections:

• Standard Business Process Forms
• Business Process Map
• Business process routes
• Business Process Matrices
• Business Process Flowcharts
• Description of business process joints
• Auxiliary business process descriptions
• Detailed description of the business process
• Business process documentation
• Definition of business process indicators and indicators
• Business process execution schedule

Let's take a closer look at each stage.

1.Standard forms of business process description

We recommend using a typical sample of a standard form for describing a business process. This will allow achieving a unified approach to fixing the process by different people, which will then greatly facilitate the analysis of processes.

2. Business process map

Business Process Map- graphical representation of the business process in the form of a flowchart. Please note that each participant in the business process has a separate column. Lines are time intervals. The issued map allows you to synchronize operations and trace the path of information passing between the company's divisions.

At the stage of drawing up a business process map, the employee performing this work is not required to have competence in the field of the described business process procedures. It only captures the performers' knowledge of what and how they do. You need to get answers to the questions:

• What document ends the work cycle so that it can be started over?
• To whom is this document sent?
• What precedes this?
• Who is involved in this process inside and outside the organization?
• Who issues the task to start the process?

When drawing up a business process map, you should use the popular 5W1H question formula. Briefly, these are 5 W questions:

• Who? (Who performs this operation?)
  
• Why? (Why or why is this operation performed?)
  
• What? (What is this operation?)
  
• When? (When should this be done?)
  
• Where? (Where is the operation performed?)
  

and one question H

• how? (How is this operation done? Can it be done differently or improved?).

If the map turns out to be too complicated, this is a signal that there is no proper order in the management of the organization.

3. Business process routes

In real business processes, several departments of the enterprise often participate. For them, it is necessary to assign roles in the process. In addition, there are branching and parallel actions. Therefore representation in the form of routes is very convenient. The routes give us the logistic diagram of the process - movement of materials, people, cash and information flows. Flowcharts are used to decipher the logic of a command's actions.

4. Business process matrices

Matrix (table) of the analysis of the interaction of processes allows you to highlight the most important business processes, establish their relationship and assess the degree of influence of processes on the functioning of the QMS.

Process chain analysis detects that information is exchanged between all subprocesses. The process chain goes from the upper left corner to the lower right. The internal provider-consumer relationships are shown as boxes that indicate the requirements for the actions that were performed earlier.

5. Drawing up a block diagram of a business process

The process flow diagram is a visual diagram of the entire chain of relationships between all participants in the business process (consumers, suppliers and performers). In the process of drawing up a flowchart, the following questions are posed:

• Is the value of this business process comparable to the cost of its implementation?
• How integrated is it with other business processes?
• Can errors in this business process be immediately detected?
• What has been done to improve and ensure the quality of this business process?

6. Description of the joints of business processes

The most difficult thing is to describe the activities of the enterprise at the junctions of business processes. Consent between process owners is sometimes very difficult to obtain.

First write a description of the exits. Write them on the register first, then define the performance metrics and values ​​to aim for. Describe the process for measuring these indicators. Consider the possibility of moving from them to other performance indicators that are of interest to other users.

Then write a similar description of the inputs.

7. Auxiliary descriptions of business processes

As an auxiliary description, layout diagrams, mnemonic diagrams, Gantt charts and network diagrams. The last two are convenient to use for processes project management.

8. Detailed description of business processes

Expanded business process description can be in any form convenient for the enterprise, but must contain the main provisions:

• full name of the business process;
• business process code;
• definition of a business process, revealing its main content;
• purpose of the business process;
• business process owner responsible for forward planning of the process;
• business process manager, responsible for the ongoing maintenance of the process;
• business process standards;
• business process inputs (flows coming from outside and subject to transformation);
• business process outputs (transformation results);
• resources available to the business process;
• business processes of internal and external providers - sources of inputs;
• consumer business processes - users of the results of the considered business process;
• measured process parameters;
• process performance indicators.

9. Documenting the business process

Business processes included in the QMS system are to be documented. The most convenient form of description is a procedure. A business process can be described by one or more procedures, depending on the complexity. It is convenient to make a single view to describe all business processes.

10. Definition of indicators and indicators of the business process

The business process must be characterized by some indicators so that the process can be measured and its effectiveness evaluated. All indicators are included in 4 main groups:

• quality;
• lead time;
• number;
• costs.

In addition, it is customary to single out special groups - a group of business process indicators, a group of requirements, a group to ensure the desired flow of the process, a group of recommendations.

Indicator group business process shows the degree of achievement of the goal.

The group of requirements includes:

• human resources;
• infrastructure;
• working environment conditions.

Group for ensuring the desired course of the process:

• information;
• work instructions;
• time.

• finance;
• logistics;
• suppliers;
• partners, etc.

11. Business process execution schedule

Large business processes should be formalized as a separate document Rules for the execution of a business process". The remaining business processes can be formalized in the form of regulations on the unit and job descriptions.

The regulations should include requirements to ensure compliance with the Shewhart-Deming cycle:

• determination of business process targets for the next period;
• analysis by the owner of the business process of deviations from the normal course of the process and their documentation;
• analysis of the effectiveness of corrective measures;
• reporting to senior management.

Development and description of business processes- the first step on the way QMS implementation at the enterprise. Ahead is constant and painstaking work to bring them to the attention of all personnel, analyze and, if necessary, implement corrective actions.

And yet, the human mind has tried in vain to comprehend it for more than 2,000 years, while, on the other hand, it has succeeded, at least approximately, in the analysis of much more meaningful and complex forms. Why is that? Because a developed body is easier to study than a cell of the body. In addition, when analyzing economic forms, neither a microscope nor chemical reagents can be used. Both must be replaced by the power of abstraction.

Karl Marx. Capital. Volume 1. Preface to the first edition.

Business processes are talked about a lot and often mostly in connection with business automation. I also use this term, including in my articles on CRM systems, ERP, working with BPMN notations, IDEF0 and other tools that may be needed in the work of a business consultant and the implementation of automation systems. At the same time, I did not find an understandable and detailed definition of the term “business process” in Runet.

Many authors use it "by default" as the term "intuitive" without decoding, or generally introduce additional confusion using alternative terminology, for example, they write "business entity" instead of a business process, etc.

In this article, I decided to talk about what a business process is, tell about the history of the emergence of this concept and where it can and should be applied. I also plan to devote the next article to the topic of business processes, in which I will tell you how to use business processes correctly.

Business process definition

So, what is the difference between a business process and a function, or even just a regular process? What is the difference between these terms? I came to the following conclusion:

A business process is a logical sequence of actions of a person (or several people) in a team. The purpose of the description of the business process is the analysis and regulation of certain actions in the team.

Why I place special emphasis on people and the team:

1. A business process always takes place with the participation of a person. If actions are performed by an automatic system or program, this is no longer a business process, but a technological process or specification. And then slightly different standards, description methods and implementation features come into force.
2. A business process always involves several people, either explicitly or implicitly. Even if a person works alone (for example, a writer), he still has customers (publishing agencies) and consumers (readers). Also, the seller does not work in a "vacuum" - he has suppliers and buyers of products, and all these people are also involved in one way or another in the business process.

Why am I writing about the team, and not about a commercial structure or company? Because the concept of a business process can be used, including for a non-profit organization. It could be a charity, an ambulance visiting a patient, or even hosting a dinner party without any sales or profit. At the same time, it is also possible to describe a business process, since we have people who perform some actions to obtain a certain result.

Description of the business process

It is also important to define the business process description:

A description of a business process is a description of the sequence of actions of employees when performing certain actions in graphical and textual form in order to regulate actions in a team, analyze and optimize their sequence.

And here it is necessary to understand that a business process without a description does not exist. Only in the process of description does a business process appear, i.e. it is impossible to realize one without the other.
At the same time, all actions that are described in the business process must be logical, their sequence must lead to a certain previously set goal.

Description of business processes is a creative work. Even if you describe “what is”, some inaccuracies are still allowed, corners are “smoothed out”, some actions are omitted for ease of perception. And if “what should be” is described, then something new is created on the basis of the existing. At the same time, the business analyst is still limited by strict limits - rules, syntax, logical restrictions.

Personally, I compare the creation of a new business process with balancing on a thin thread a harmonious combination of creativity, art and strict mathematics.

At the same time, you need to understand that no business process can be perfect and 100% correspond to reality. There is always room for some simplifications and assumptions, somewhere in the implementation of even the most stringent regulations, the human factor makes its own adjustments.

In addition, as you know, in any new entity there is always the possibility of further improvement. And the creation of business processes also confirms this philosophical thesis. No matter how hard you try to describe a business process perfectly, there is still something in it that can also be improved either now or in the future.

And here it is very important, on the one hand, to stop in time yourself, because the updated business processes will be implemented by real people who are used to working “the old fashioned way”, and you need to take into account their inertia of thinking and degree of learning. Also, automation, which is usually included in the modernization of business processes, requires certain investments. And here it is necessary to proceed from the real possibilities of the customer.

A business consultant must clearly understand all this himself, know where and at what level of assumptions he simplified the description of the business process, and where he decided to postpone some decisions for the future for objective reasons (finance, human factor). And you need to be able to explain all this simply and clearly to the head of the business.

The main difference between a business process and a technological one is that in the technological process, one quite definite result is expected at the output. For example, if we are talking about production, then the output should be products with certain parameters.

Of course, even in the technological process there is a possibility of getting a marriage, but not one of the natural options, but the consequences of a violation of the technological process. While in a business process, the “output” result may differ depending on the fulfillment of certain conditions in the “body” of the business process, which was carried out without violations and failures.

For clarity, the description of the technological process may look like this:

1. We take workpiece A;
2. We connect it with the workpiece B;
3. We process under parameters C;
4. We get the detail.

Everything is unambiguous and no conditional "forks" are provided.

In a business process, the following situation is considered quite normal:

1. We get input data A:
   • If the data matches the condition B, go to the sequence of actions C;
   • If the data matches condition D, perform actions E.
2. The result is passed to the output.

Those. already in the process algorithm, possible conditions and various actions are provided, depending on the initial or intermediate data.

The history of the term

I have read information more than once that IDEF0 business process notation appeared almost in the middle of the 19th century. More realistic authors write about the period of the Second World War. But they are wrong too.

For example, when I wrote an article about IDEF0, some readers cited examples of some instructions from ministries and departments during the First World War or even earlier as examples of notations, and diagrams and visual representations of military operations were discussed as a graphic display. But all this is not a description of the business process. All of the above can be called methods, visual demonstration, instructions, but cannot be called notations.

Notations are a modern concept, moreover, notations are something that is well-established, standardized, i.e. a set of commands and notations that are used by many people, not just one or two organizations. You can come up with your own special language to describe business processes or, for example, programming. But until it gets a “run-in” in mass use, contradictions, ambiguous interpretations, and other shortcomings are not identified and eliminated, until it becomes an established and familiar standard for people, it cannot be called a notation. I plan to write more about notations later. Now let's return to the issue of the emergence of the term "business process".

In fact, the description of business processes and BPMN notation appeared in the 70s of the XX century, when information systems began to be used everywhere. Both the term itself and the notations were originally needed precisely for the development of information systems.

The fact is that after the start of the use of information systems, the complexity of organizing the work of people in organizations has increased many times over. In addition, machines do not understand abstraction, they require a strict algorithm and a certain order of input and processing of information. If before the start of automation, when information passed directly from person to person, the problem of mutual understanding was at the level of human communications, now there is a need to strictly regulate it.

As a result, it was necessary to create job descriptions not only of people in the organization, but also of their interaction with information systems. And here there were not enough textual notations (instructions), where all descriptions were in free text form, they turned out to be irrelevant and inconvenient. There was a need for standardization, in fact, to create a special command language and an unambiguous sequence of actions. Moreover, unlike machine languages, these notations should have become equally convenient for translation into machine code, and for human perception.

The first methodologically developed notations of business processes (and I will talk about methodologically developed notations, for example, IDEF3 ***) appeared in the US military. The reason is obvious - even then, the military in the United States used automation using remote connections, i.e. the same system that later became the Internet. And with this level of application of information systems, the need for business process notations was especially relevant.

*** On the topic of methodologically elaborated notations, I also want to say a few words. Why I cited IDEF3 as an example: I have not yet seen a more methodologically developed system for describing business processes. Even BPMN 2.0 is still being developed and refined. And if you read the English description of IDEF3 (I have not yet seen a translation into Russian), you will also be able to appreciate the depth of its development.

Very quickly, the methodology and notations gained immense popularity in the business environment.
Notations made it possible to obtain a tool for describing the interaction of people and digital information systems.

With their help, it was possible to optimize the business, i.e. get better performance at the same cost.

The opportunity for optimization was of particular interest to the business. As you know, in order to improve something, you need to clearly understand what you have and what you want to change from this. And graphical notations clearly showed both situations - the starting point and the desired result, as well as the most problematic areas. Based on these data, it turned out to be much easier to choose the optimal solution path and simulate the best modernization option than without such convenient tools.

It was then that the concepts of business processes and business process notations appeared, two inextricably linked concepts.

It is very important to understand that there is no, for example, a separate "sales business process". There is a sales process that will become a business process if it is described using a notation. Those. without a description in the business process notation, you are engaged in sales, no one disputes this. But while there is no definite unshakable and unambiguous description, your sales are a phenomenon, in some ways, spontaneous. And they will become a business process only after they are described within the framework of the notation and the implementation of this description in practice.

Sales is the simplest and most obvious example. Each of us in the role of a buyer, and many of us in the role of a seller, are familiar with this process. And we all know that even the same person in different situations (for different products, different buyers, in different weather, and in general, depending on the mood) will sell somewhat differently. But if you describe and clearly regulate a certain business process, then no matter what foot the seller got up in the morning, the sales process will be standardized in a certain way, limited to certain limits, and, as a result, more stable.

Why model (describe) business processes

As I wrote more than once, I work mainly with small and medium-sized businesses, where I provide a wide range of services - from identifying problems and bottlenecks in the company's work to implementing the solutions I proposed at the level of software products and automation systems.

Business process modeling helps to solve two problems at once:

• Business study. Graphical representation in the form of diagrams, i.e. business process modeling allows you to quickly understand the features of the company and identify possible bottlenecks.
• Providing visibility. As you know, “one picture is worth a thousand words”. Therefore, a schematic representation of the company's work helps the manager and business owner to understand the essence of the problem much faster and evaluate the proposed solutions. In the work of a business consultant (by the way, as well as a specialist in the implementation of software products), it is very important that the client understands all the advantages of the solution. Feedback is no less important - the manager in the diagram will be able to see some shortcomings even at the stage of discussing the project, and the implementation will do without additional difficulties and making changes to the project “on the go”.

And the combination of studying the history of the appearance of the term with my personal experience gives the following definition:

Business processes are required to present complex information in an easy to understand form for study and decision making.

Imagine a typical company with different departments: accounting, human resources, sales, warehouse, shipping, manufacturing, and so on. Above all this is one person - the head of the business. He physically cannot understand all types of business processes at an expert level. That is why they hire different specialists. But he needs to effectively manage all this, and in certain cases - to modernize.

This is where business processes come in. At the same time, certain types of human activity within the company are described in graphical notations and presented in a form that helps management understand exactly how work is done at each stage, and what can be improved here. At the same time, the head of the company does not have to have a highly qualified specialist of a particular profile.

Of course, at this level one cannot do without some information loss. It is impossible to describe with graphic notation all the nuances and details of the work of each employee. But these information losses turn out to be insignificant for understanding the processes in general and making a decision.

How to describe business processes

In order to get a description of actually operating business processes, it is enough just to carefully study the sequence of actions of each employee. Those. it is necessary to obtain information about incoming data to launch a certain process, outgoing - i.e. the result of the employee's actions, as well as step-by-step fix the actions that were required.

After all the information is collected, it needs to be translated into graphical notation. Here it is worth understanding that it is graphic notations that are considered “good form” when compiling descriptions of business processes. For yourself, you can compose the notation as you like, text options for descriptions also exist and are used, for example, by some software developers. But if you are writing notation that other people will read, whether it is a software developer or a company executive, choose graphics.

The reason for this decision is simple: information is better perceived in graphical form. If you offer a “wall of text” to a person, it will take him a lot of time and effort to figure out what you are even talking about. And to cover the whole task in this case is almost impossible. Graphic diagrams are another matter - here you can study business processes at different levels of detail, and anyone can quickly “take a look at the general view” of a graphic diagram.

1. We collect participants in the process (employees);
2. We collect incoming information necessary and sufficient to start the process;
3. We collect used systems. It can be an accounting system, CRM, email, Excel spreadsheets, etc. Everything that is actually used in the work must be recorded.
4. We define the expected result - what will happen at the end of the process.
5. We collect the sequence of actions that a person performs.
6. We isolate the conditions. Depending on the different input data and intermediate results, the actions may be different.
7. We describe all the collected information in a graphical form in a convenient notation (IDEF3, BPMN 2.0, etc.).

Business process description rules

Above, I said a lot about the creative approach, about the possibilities of including conditions and options for actions in the description of business processes. As a result, it may seem that any description of a person's actions "at work" can be considered a description of a business process. In fact, there are strict frameworks and rules that determine whether a list of actions can be called a description of a business process (in graphic or text form) or not:

• Completeness. A business process must clearly answer the question facing it. If we are talking about the process of selling a certain product or service, then the business process must fully describe the actions necessary to obtain the specified result, and culminating in just such a result (with certain assumptions, which I mentioned above).
• Conciseness. The business process must combine sufficiency, i.e. describe all the necessary steps and actions, while being as concise as possible for ease of perception. Personally, I came up with a “rule of 15 minutes” for myself - if during this period of time I can explain the presented business process to the company's management, then it can be shown to the customer. It turns out faster - great, it takes more time and words - you need to think about what can be reduced and simplified.
  I once personally saw a graphic description of a business process, made on a sheet of 2 meters long (and corresponding width). Even just to consider it and understand where which arrow leads is extremely difficult. And how to explain it to the customer, I personally can not imagine.
  Remember that a person perceives a visually defined amount of information, limited, among other things, by a certain size of a sheet or screen (this is due to the peculiarities of vision), as well as the number of elements (brain capabilities are also limited). The customer will understand a simple and concise business process by simply “covering” the scheme with a glance. Complex and oversaturated with details, you will have to study for more than one hour just to understand what is displayed there. Most likely, the head of the company, who is not an expert in the work of individual departments, and is also limited in the amount of free time, simply will not study such a complex structure and will not understand the essence of even the most profitable offers.
• Use of generally accepted notations. Do not invent your own notation and rules. Use notations that are used all over the world. I saw in the books of some domestic authors attempts to create their own notation. And, to be honest, I never understood why they make life difficult for themselves and their readers. Here, as with the language - you can come up with your own special language, but no one but you will understand it. And if it turns out to be similar to the existing ones, then confusion may also appear. Or you will be considered illiterate, because you do not use punctuation, decline words, etc. according to the rules of known languages. So it is with notations - there are already well-established, known to people and, which is also important, intuitive notations. That's why they became popular because in the process of their creation and improvements they were constantly tested for simplicity, unambiguity and convenience. If you use ready-made notations, you will be understood, perceived as an expert, and the notation rules themselves will save you from logical errors. I personally recommend IDEF3 and BPMN 2.0.
• All participants in the business process must be taken into account and directly indicated. And this must be done without using footnotes with numbering, comments in Swimm line objects (special footnotes), etc. Fans often “sin” with this to create their own designs instead of using ready-made notations. Somewhere their names do not fit, somewhere they think that a long name in the body of a business process will be inconvenient. As a result, either you have to look in the footnotes for who exactly they are talking about, or the creators of such business processes simply forget to indicate one of the participants.
• User-friendly description. The most important thing is that your consumer, the one who will read this notation, must quickly and, ideally, even without your explanations, understand the description of the business process.

Everything else depends only on you and the consumer of the business process description. If you really like the use of different colors (for arrows or objects), I think this is quite acceptable. You can also create notation not only in the tools I have proposed, but in any environment convenient for you. If the notation follows the rules listed above and is understandable to your consumer, you have created exactly what you need. And this is really a description of the business process, professional and optimal for work.

Common myths and misconceptions

Don't "reinvent the wheel"! No need to invent your own notations.

Often, instead of studying the features of existing notations, people draw free-form graphs in various graphics programs.

I don't recommend doing this. Firstly, when using ready-made tools, you do not need to invent your own designations and standards. Everything has been thought of for a long time. At the same time, standard notations are really intuitive, read unambiguously, and are known to many people. Secondly, ready-made systems (IDEF3, BPMN 2.0, etc.) have a well-developed methodology and strict restrictions. They can be perceived as a programming language and an environment for working with this language. Here you simply will not be able to make many mistakes, syntax standards and the environment itself will save you from this (limitations in the editor, automatic checks).

Do not confuse descriptions of the company's business processes and IT systems business processes.

In many automated systems, for example, 1C or Zoho CRM, there are their own entities called "business processes". But these entities have nothing to do with the business processes described in this article. Consider them "homonyms", i.e. the terms seem to sound the same, but in our case it is a description of the company's work, and in IT systems it is the name of a group of functions and reports.

Common mistake: A business process necessarily brings value (profit).

I even heard from well-known speakers that business processes should be profitable. Moreover, I even saw “analysis of errors” when creating a business process, in which a lot of attention is paid to the fact that 70% of actions do not carry any value.

In fact, business processes are different. The result of some will indeed be making a profit, for example, direct sales. In other cases, it is difficult to talk about the acquisition of value and, in general, about the evaluation of actions from this point of view. For example, how can you evaluate the value of a business process of shipping goods or generating and sending tax returns?

I believe that a business process does not necessarily bring any value, if we understand it as a direct profit for the company. The introduction of a process-oriented approach and the implementation of business processes are focused more on something else - on the preservation of value, i.e. getting more performance at the same cost.

Is it possible to create an ideal business process - when should you stop?

No. The business process should be simple, understandable, convenient, readable. But it will never be perfect.

When I started working, it always seemed to me myself that I was not working on something, somewhere it could have been done better. And often clients asked me to detail and describe in more detail this or that process. And I also considered it my shortcoming.

In fact, based on all of the above, business process modeling is some kind of assumption, a creative process. On the other hand, at one time I did not even know what to answer to requests to describe more “this” and “there”. But over time, I realized that business modeling is not just creativity, but a kind of dialectical process. And the very creation of a business process will always carry its own negation. Here it is really worth approaching the issue from a philosophical point of view. And when creating a business process, we must remember that we cannot cover everything at once, and therefore it will always be imperfect. But at the same time, we are already laying in it what we will improve in the future. It is worth approaching this simply as a fact.

Your business process must solve the task, answer the question that is considered within the framework of the project. Everything else is a matter of future possible cooperation. This is exactly how it is worth explaining to customers why you do not detail some processes or draw some other business process related to the one being discussed.

The business process diagram reflects its essence and mechanism of work. Creating a circuit in itself is not very difficult. It is enough to understand what questions the scheme should answer, and then follow the creation algorithm. If you can't wait to start creating models or don't know where to start, this article is for you.

I want to remind you that before starting the description of business processes, it is necessary. companies is the platform to start with.

The algorithm that I present here will be useful to those who are just going to describe business processes. For those who have been trained by me, the article will be an excellent repetition of what has been passed))))

Business process diagram - instructions for the impatient

1 - Define process boundaries

Every business process starts and ends with an event. The first thing to do is to mark the start and end events.

2 - Draw the main blocks of the process

Arrange the main blocks (subprocesses, operations) in the order in which they are performed.

Do not complicate the scheme at this stage. Display the blocks as if the process is running perfectly.

3 - Add forks and other events

And now it's time to complicate things a little. Add the main options for the development of the process and the main intermediate events. Complete the diagram with the missing operations.

4 - Designate the roles of participants in the process

There are no positions or specific employees in business processes. Instead, the concept of "role" is used. One employee can perform many roles. One role can be performed by many employees. A position is made up of a set of roles.

Add missing operations as needed.

5 - Place documents on the diagram

A document is not necessarily an official paper with seven signatures. From the point of view of business process management, a document is information on any information carrier. Email, report, presentation, SMS - all these are documents.

Sometimes it is necessary to display intermediate products. These are blanks, semi-finished products, or simply important parts of the work that pass from one process block to another. Add them at this stage. Of necessity.

6 - Add used programs and databases

The process should reflect which programs and databases it uses.

7 - Arrange tools and materials

If tools and/or materials are used in the process, this should also be displayed. The main points can be identified on the business process diagram. A detailed description is best given in the comments and special sections of the description. A great option is to draw up a diagram focused specifically on the use of tools and materials. In such a scheme, the emphasis is not on the flow of work, but on how, in what quantity and what materials are used in the business process.

8 - Define performance indicators in the business process

Place on the business process diagram the performance indicators that are taken into account in the system in one way or another.

9 - Associate the received scheme with other processes

Each business process is just a part of a larger system. All processes are interconnected. Essentially, a link is something that a process exchanges with other processes. Note that you must specify the processes that the current process is associated with, as well as what they exchange.

Linking a business process to other processes

10 - Check the resulting business process model

In principle, the scheme is ready. The business process diagram should answer the following questions:

• Where does the business process begin and end?
• What processes does it involve? What is exchanged?
• What operations are performed? In what order?
• Who performs the activities in the process?
• What documents are used and appear in the process? In what operations are these documents used/appeared?
• What tools, materials, software and databases are used in the process and in what operations?
• What performance indicators and where exactly are recorded in the business process?

A well-prepared scheme should be easy to understand and sufficiently informative.
The business process diagram should be understandable to the “man on the street”.
The business process diagram at the description stage should reflect how the process is performed in real life.

This algorithm will allow you to describe the necessary business processes quite simply and quickly. Next, I will talk in detail about the description of business processes. Stay in touch.

And yet, the human mind has tried in vain to comprehend it for more than 2,000 years, while, on the other hand, it has succeeded, at least approximately, in the analysis of much more meaningful and complex forms. Why is that? Because a developed body is easier to study than a cell of the body. In addition, when analyzing economic forms, neither a microscope nor chemical reagents can be used. Both must be replaced by the power of abstraction.

Karl Marx. Capital. Volume 1. Preface to the first edition.

Business processes are talked about a lot and often mostly in connection with business automation. I also use this term, including in my articles on CRM systems, ERP, working with BPMN notations, IDEF0 and other tools that may be needed in the work of a business consultant and the implementation of automation systems. At the same time, I did not find an understandable and detailed definition of the term “business process” in Runet.

Many authors use it "by default" as the term "intuitive" without decoding, or generally introduce additional confusion using alternative terminology, for example, they write "business entity" instead of a business process, etc.

In this article, I decided to talk about what a business process is, tell about the history of the emergence of this concept and where it can and should be applied. I also plan to devote the next article to the topic of business processes, in which I will tell you how to use business processes correctly.

Business process definition

So, what is the difference between a business process and a function, or even just a regular process? What is the difference between these terms? I came to the following conclusion:

A business process is a logical sequence of actions of a person (or several people) in a team. The purpose of the description of the business process is the analysis and regulation of certain actions in the team.

Why I place special emphasis on people and the team:

1. A business process always takes place with the participation of a person. If actions are performed by an automatic system or program, this is no longer a business process, but a technological process or specification. And then slightly different standards, description methods and implementation features come into force.
2. A business process always involves several people, either explicitly or implicitly. Even if a person works alone (for example, a writer), he still has customers (publishing agencies) and consumers (readers). Also, the seller does not work in a "vacuum" - he has suppliers and buyers of products, and all these people are also involved in one way or another in the business process.

Why am I writing about the team, and not about a commercial structure or company? Because the concept of a business process can be used, including for a non-profit organization. It could be a charity, an ambulance visiting a patient, or even hosting a dinner party without any sales or profit. At the same time, it is also possible to describe a business process, since we have people who perform some actions to obtain a certain result.

Description of the business process

It is also important to define the business process description:

A description of a business process is a description of the sequence of actions of employees when performing certain actions in graphical and textual form in order to regulate actions in a team, analyze and optimize their sequence.

And here it is necessary to understand that a business process without a description does not exist. Only in the process of description does a business process appear, i.e. it is impossible to realize one without the other.
At the same time, all actions that are described in the business process must be logical, their sequence must lead to a certain previously set goal.

Description of business processes is a creative work. Even if you describe “what is”, some inaccuracies are still allowed, corners are “smoothed out”, some actions are omitted for ease of perception. And if “what should be” is described, then something new is created on the basis of the existing. At the same time, the business analyst is still limited by strict limits - rules, syntax, logical restrictions.

Personally, I compare the creation of a new business process with balancing on a thin thread a harmonious combination of creativity, art and strict mathematics.

At the same time, you need to understand that no business process can be perfect and 100% correspond to reality. There is always room for some simplifications and assumptions, somewhere in the implementation of even the most stringent regulations, the human factor makes its own adjustments.

In addition, as you know, in any new entity there is always the possibility of further improvement. And the creation of business processes also confirms this philosophical thesis. No matter how hard you try to describe a business process perfectly, there is still something in it that can also be improved either now or in the future.

And here it is very important, on the one hand, to stop in time yourself, because the updated business processes will be implemented by real people who are used to working “the old fashioned way”, and you need to take into account their inertia of thinking and degree of learning. Also, automation, which is usually included in the modernization of business processes, requires certain investments. And here it is necessary to proceed from the real possibilities of the customer.

A business consultant must clearly understand all this himself, know where and at what level of assumptions he simplified the description of the business process, and where he decided to postpone some decisions for the future for objective reasons (finance, human factor). And you need to be able to explain all this simply and clearly to the head of the business.

The main difference between a business process and a technological one is that in the technological process, one quite definite result is expected at the output. For example, if we are talking about production, then the output should be products with certain parameters.

Of course, even in the technological process there is a possibility of getting a marriage, but not one of the natural options, but the consequences of a violation of the technological process. While in a business process, the “output” result may differ depending on the fulfillment of certain conditions in the “body” of the business process, which was carried out without violations and failures.

For clarity, the description of the technological process may look like this:

1. We take workpiece A;
2. We connect it with the workpiece B;
3. We process under parameters C;
4. We get the detail.

Everything is unambiguous and no conditional "forks" are provided.

In a business process, the following situation is considered quite normal:

1. We get input data A:
   • If the data matches the condition B, go to the sequence of actions C;
   • If the data matches condition D, perform actions E.
2. The result is passed to the output.

Those. already in the process algorithm, possible conditions and various actions are provided, depending on the initial or intermediate data.

The history of the term

I have read information more than once that IDEF0 business process notation appeared almost in the middle of the 19th century. More realistic authors write about the period of the Second World War. But they are wrong too.

For example, when I wrote an article about IDEF0, some readers cited examples of some instructions from ministries and departments during the First World War or even earlier as examples of notations, and diagrams and visual representations of military operations were discussed as a graphic display. But all this is not a description of the business process. All of the above can be called methods, visual demonstration, instructions, but cannot be called notations.

Notations are a modern concept, moreover, notations are something that is well-established, standardized, i.e. a set of commands and notations that are used by many people, not just one or two organizations. You can come up with your own special language to describe business processes or, for example, programming. But until it gets a “run-in” in mass use, contradictions, ambiguous interpretations, and other shortcomings are not identified and eliminated, until it becomes an established and familiar standard for people, it cannot be called a notation. I plan to write more about notations later. Now let's return to the issue of the emergence of the term "business process".

In fact, the description of business processes and BPMN notation appeared in the 70s of the XX century, when information systems began to be used everywhere. Both the term itself and the notations were originally needed precisely for the development of information systems.

The fact is that after the start of the use of information systems, the complexity of organizing the work of people in organizations has increased many times over. In addition, machines do not understand abstraction, they require a strict algorithm and a certain order of input and processing of information. If before the start of automation, when information passed directly from person to person, the problem of mutual understanding was at the level of human communications, now there is a need to strictly regulate it.

As a result, it was necessary to create job descriptions not only of people in the organization, but also of their interaction with information systems. And here there were not enough textual notations (instructions), where all descriptions were in free text form, they turned out to be irrelevant and inconvenient. There was a need for standardization, in fact, to create a special command language and an unambiguous sequence of actions. Moreover, unlike machine languages, these notations should have become equally convenient for translation into machine code, and for human perception.

The first methodologically developed notations of business processes (and I will talk about methodologically developed notations, for example, IDEF3 ***) appeared in the US military. The reason is obvious - even then, the military in the United States used automation using remote connections, i.e. the same system that later became the Internet. And with this level of application of information systems, the need for business process notations was especially relevant.

*** On the topic of methodologically elaborated notations, I also want to say a few words. Why I cited IDEF3 as an example: I have not yet seen a more methodologically developed system for describing business processes. Even BPMN 2.0 is still being developed and refined. And if you read the English description of IDEF3 (I have not yet seen a translation into Russian), you will also be able to appreciate the depth of its development.

Very quickly, the methodology and notations gained immense popularity in the business environment.
Notations made it possible to obtain a tool for describing the interaction of people and digital information systems.

With their help, it was possible to optimize the business, i.e. get better performance at the same cost.

The opportunity for optimization was of particular interest to the business. As you know, in order to improve something, you need to clearly understand what you have and what you want to change from this. And graphical notations clearly showed both situations - the starting point and the desired result, as well as the most problematic areas. Based on these data, it turned out to be much easier to choose the optimal solution path and simulate the best modernization option than without such convenient tools.

It was then that the concepts of business processes and business process notations appeared, two inextricably linked concepts.

It is very important to understand that there is no, for example, a separate "sales business process". There is a sales process that will become a business process if it is described using a notation. Those. without a description in the business process notation, you are engaged in sales, no one disputes this. But while there is no definite unshakable and unambiguous description, your sales are a phenomenon, in some ways, spontaneous. And they will become a business process only after they are described within the framework of the notation and the implementation of this description in practice.

Sales is the simplest and most obvious example. Each of us in the role of a buyer, and many of us in the role of a seller, are familiar with this process. And we all know that even the same person in different situations (for different products, different buyers, in different weather, and in general, depending on the mood) will sell somewhat differently. But if you describe and clearly regulate a certain business process, then no matter what foot the seller got up in the morning, the sales process will be standardized in a certain way, limited to certain limits, and, as a result, more stable.

Why model (describe) business processes

As I wrote more than once, I work mainly with small and medium-sized businesses, where I provide a wide range of services - from identifying problems and bottlenecks in the company's work to implementing the solutions I proposed at the level of software products and automation systems.

Business process modeling helps to solve two problems at once:

• Business study. Graphical representation in the form of diagrams, i.e. business process modeling allows you to quickly understand the features of the company and identify possible bottlenecks.
• Providing visibility. As you know, “one picture is worth a thousand words”. Therefore, a schematic representation of the company's work helps the manager and business owner to understand the essence of the problem much faster and evaluate the proposed solutions. In the work of a business consultant (by the way, as well as a specialist in the implementation of software products), it is very important that the client understands all the advantages of the solution. Feedback is no less important - the manager in the diagram will be able to see some shortcomings even at the stage of discussing the project, and the implementation will do without additional difficulties and making changes to the project “on the go”.

And the combination of studying the history of the appearance of the term with my personal experience gives the following definition:

Business processes are required to present complex information in an easy to understand form for study and decision making.

Imagine a typical company with different departments: accounting, human resources, sales, warehouse, shipping, manufacturing, and so on. Above all this is one person - the head of the business. He physically cannot understand all types of business processes at an expert level. That is why they hire different specialists. But he needs to effectively manage all this, and in certain cases - to modernize.

This is where business processes come in. At the same time, certain types of human activity within the company are described in graphical notations and presented in a form that helps management understand exactly how work is done at each stage, and what can be improved here. At the same time, the head of the company does not have to have a highly qualified specialist of a particular profile.

Of course, at this level one cannot do without some information loss. It is impossible to describe with graphic notation all the nuances and details of the work of each employee. But these information losses turn out to be insignificant for understanding the processes in general and making a decision.

How to describe business processes

In order to get a description of actually operating business processes, it is enough just to carefully study the sequence of actions of each employee. Those. it is necessary to obtain information about incoming data to launch a certain process, outgoing - i.e. the result of the employee's actions, as well as step-by-step fix the actions that were required.

After all the information is collected, it needs to be translated into graphical notation. Here it is worth understanding that it is graphic notations that are considered “good form” when compiling descriptions of business processes. For yourself, you can compose the notation as you like, text options for descriptions also exist and are used, for example, by some software developers. But if you are writing notation that other people will read, whether it is a software developer or a company executive, choose graphics.

The reason for this decision is simple: information is better perceived in graphical form. If you offer a “wall of text” to a person, it will take him a lot of time and effort to figure out what you are even talking about. And to cover the whole task in this case is almost impossible. Graphic diagrams are another matter - here you can study business processes at different levels of detail, and anyone can quickly “take a look at the general view” of a graphic diagram.

1. We collect participants in the process (employees);
2. We collect incoming information necessary and sufficient to start the process;
3. We collect used systems. It can be an accounting system, CRM, email, Excel spreadsheets, etc. Everything that is actually used in the work must be recorded.
4. We define the expected result - what will happen at the end of the process.
5. We collect the sequence of actions that a person performs.
6. We isolate the conditions. Depending on the different input data and intermediate results, the actions may be different.
7. We describe all the collected information in a graphical form in a convenient notation (IDEF3, BPMN 2.0, etc.).

Business process description rules

Above, I said a lot about the creative approach, about the possibilities of including conditions and options for actions in the description of business processes. As a result, it may seem that any description of a person's actions "at work" can be considered a description of a business process. In fact, there are strict frameworks and rules that determine whether a list of actions can be called a description of a business process (in graphic or text form) or not:

• Completeness. A business process must clearly answer the question facing it. If we are talking about the process of selling a certain product or service, then the business process must fully describe the actions necessary to obtain the specified result, and culminating in just such a result (with certain assumptions, which I mentioned above).
• Conciseness. The business process must combine sufficiency, i.e. describe all the necessary steps and actions, while being as concise as possible for ease of perception. Personally, I came up with a “rule of 15 minutes” for myself - if during this period of time I can explain the presented business process to the company's management, then it can be shown to the customer. It turns out faster - great, it takes more time and words - you need to think about what can be reduced and simplified.
  I once personally saw a graphic description of a business process, made on a sheet of 2 meters long (and corresponding width). Even just to consider it and understand where which arrow leads is extremely difficult. And how to explain it to the customer, I personally can not imagine.
  Remember that a person perceives a visually defined amount of information, limited, among other things, by a certain size of a sheet or screen (this is due to the peculiarities of vision), as well as the number of elements (brain capabilities are also limited). The customer will understand a simple and concise business process by simply “covering” the scheme with a glance. Complex and oversaturated with details, you will have to study for more than one hour just to understand what is displayed there. Most likely, the head of the company, who is not an expert in the work of individual departments, and is also limited in the amount of free time, simply will not study such a complex structure and will not understand the essence of even the most profitable offers.
• Use of generally accepted notations. Do not invent your own notation and rules. Use notations that are used all over the world. I saw in the books of some domestic authors attempts to create their own notation. And, to be honest, I never understood why they make life difficult for themselves and their readers. Here, as with the language - you can come up with your own special language, but no one but you will understand it. And if it turns out to be similar to the existing ones, then confusion may also appear. Or you will be considered illiterate, because you do not use punctuation, decline words, etc. according to the rules of known languages. So it is with notations - there are already well-established, known to people and, which is also important, intuitive notations. That's why they became popular because in the process of their creation and improvements they were constantly tested for simplicity, unambiguity and convenience. If you use ready-made notations, you will be understood, perceived as an expert, and the notation rules themselves will save you from logical errors. I personally recommend IDEF3 and BPMN 2.0.
• All participants in the business process must be taken into account and directly indicated. And this must be done without using footnotes with numbering, comments in Swimm line objects (special footnotes), etc. Fans often “sin” with this to create their own designs instead of using ready-made notations. Somewhere their names do not fit, somewhere they think that a long name in the body of a business process will be inconvenient. As a result, either you have to look in the footnotes for who exactly they are talking about, or the creators of such business processes simply forget to indicate one of the participants.
• User-friendly description. The most important thing is that your consumer, the one who will read this notation, must quickly and, ideally, even without your explanations, understand the description of the business process.

Everything else depends only on you and the consumer of the business process description. If you really like the use of different colors (for arrows or objects), I think this is quite acceptable. You can also create notation not only in the tools I have proposed, but in any environment convenient for you. If the notation follows the rules listed above and is understandable to your consumer, you have created exactly what you need. And this is really a description of the business process, professional and optimal for work.

Common myths and misconceptions

Don't "reinvent the wheel"! No need to invent your own notations.

Often, instead of studying the features of existing notations, people draw free-form graphs in various graphics programs.

I don't recommend doing this. Firstly, when using ready-made tools, you do not need to invent your own designations and standards. Everything has been thought of for a long time. At the same time, standard notations are really intuitive, read unambiguously, and are known to many people. Secondly, ready-made systems (IDEF3, BPMN 2.0, etc.) have a well-developed methodology and strict restrictions. They can be perceived as a programming language and an environment for working with this language. Here you simply will not be able to make many mistakes, syntax standards and the environment itself will save you from this (limitations in the editor, automatic checks).

Do not confuse descriptions of the company's business processes and IT systems business processes.

In many automated systems, for example, 1C or Zoho CRM, there are their own entities called "business processes". But these entities have nothing to do with the business processes described in this article. Consider them "homonyms", i.e. the terms seem to sound the same, but in our case it is a description of the company's work, and in IT systems it is the name of a group of functions and reports.

Common mistake: A business process necessarily brings value (profit).

I even heard from well-known speakers that business processes should be profitable. Moreover, I even saw “analysis of errors” when creating a business process, in which a lot of attention is paid to the fact that 70% of actions do not carry any value.

In fact, business processes are different. The result of some will indeed be making a profit, for example, direct sales. In other cases, it is difficult to talk about the acquisition of value and, in general, about the evaluation of actions from this point of view. For example, how can you evaluate the value of a business process of shipping goods or generating and sending tax returns?

I believe that a business process does not necessarily bring any value, if we understand it as a direct profit for the company. The introduction of a process-oriented approach and the implementation of business processes are focused more on something else - on the preservation of value, i.e. getting more performance at the same cost.

Is it possible to create an ideal business process - when should you stop?

No. The business process should be simple, understandable, convenient, readable. But it will never be perfect.

When I started working, it always seemed to me myself that I was not working on something, somewhere it could have been done better. And often clients asked me to detail and describe in more detail this or that process. And I also considered it my shortcoming.

In fact, based on all of the above, business process modeling is some kind of assumption, a creative process. On the other hand, at one time I did not even know what to answer to requests to describe more “this” and “there”. But over time, I realized that business modeling is not just creativity, but a kind of dialectical process. And the very creation of a business process will always carry its own negation. Here it is really worth approaching the issue from a philosophical point of view. And when creating a business process, we must remember that we cannot cover everything at once, and therefore it will always be imperfect. But at the same time, we are already laying in it what we will improve in the future. It is worth approaching this simply as a fact.

Your business process must solve the task, answer the question that is considered within the framework of the project. Everything else is a matter of future possible cooperation. This is exactly how it is worth explaining to customers why you do not detail some processes or draw some other business process related to the one being discussed.