What is a business process and business process description

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

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



Business processes are talked about a lot and often mainly in connection with business automation. I use this term and myself, 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 a clear and detailed definition of the term “business process” in RuNet.



Many authors use it "by default", as the term "intuitive" without decoding, or add additional confusion at all using alternative terminology, for example, they write instead of the business process "business essence", etc.

')

In this article I decided to talk about what a business process is, to talk about the history of the emergence of this concept and where it can and should be applied. I also plan to devote the following 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 functions, or even just an ordinary 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 describing a business process is to analyze and regulate certain actions in a team.

Why I place special emphasis on people and team:

1. The business process always happens with human participation. If actions are performed by an automatic system or program, it is no longer a business, but a process or specification. And then several other standards, description methods and implementation features come into force.
2. A business process always involves several people, 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 the "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 the commercial structure or company? Because the concept of a business process can be used, including, for a non-profit organization. This may be a charity, an ambulance to the patient, or even 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 get a certain result.

Description of the business process

It is also important to define the description of the business process:

A business process description is a description of the sequence of actions of employees when performing certain actions in graphical and textual form with the purpose of regulating actions in a team, analyzing and optimizing their sequence.

And here it is necessary to understand that a business process does not exist without a description. Only in the description process does a business process appear, i.e. It is impossible to realize one without the other.

In this case, all actions that are described in the business process should be logical, their sequence should lead to a specific goal set earlier.



Description of business processes - creative work. Even if you describe “what is”, some inaccuracies are still allowed, corners are “smoothed out”, some actions are missed for simplicity 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 constraints.



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



It should be understood that no business process can be perfect and 100% consistent with reality. There is always room for some simplifications and assumptions; somewhere in the implementation of even the strictest regulations, the human factor introduces its corrections.



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 the 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 on your own in time, because the updated business processes will be implemented by real people who are accustomed to working “in the old manner”, and their inert thinking and degree of learning should be taken into account. Also, automation, which is usually included in the modernization of business processes, requires certain investments. And here we must proceed from the real possibilities of the customer.



All this is a business consultant should clearly understand himself, to know where and at what level of assumptions he simplified the description of the business process, and where he decided to postpone any future decisions for objective reasons (finance, human factor). And all this needs to be able to be easily and clearly explained to a business leader.

Workflow and business process

The main difference between a business process and a technology process is that the output process technology assumes one quite definite result. 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 probability of getting a marriage, but not one of the logical options, but the consequences of a violation of the technological process. While in the business process, the result "at the exit" 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 process may look like this:

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

Everything is unequivocal and no conditional “forks” are foreseen.



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

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

Those. Already in the process algorithm, possible conditions and different actions are provided, depending on the original or intermediate data.

The history of the term

I have repeatedly read the information that IDEF0 business process notation appeared almost in the middle of the XIX century. More realistic authors write about the period of the Second World War. But they are wrong.



For example, when I wrote an article about IDEF0, some readers gave examples of instructions from ministries and departments during World War I or even earlier as examples of notations, while diagrams and visual images of hostilities were discussed as a graphic display. But all this is not a description of the business process. All of the above can be called techniques, a visual demonstration, instructions, but not a notation.



Notations are a modern concept, and notation is something well-established, standardized, i.e. a set of commands and symbols used by many people, and not one or two organizations. You can invent your own special language to describe business processes or, for example, programming. But until he gets a “run-in” in mass use, contradictions, ambiguous interpretations, other shortcomings will not be identified and eliminated, until he becomes a well-established standard common to people, you cannot call it a notation. I plan to write more about the notations later. Now back to the question of the emergence of the term "business process".



In fact, the description of business processes and BPMN notation appeared in the 1970s, when information systems began to be used everywhere. Both the term itself and the notation were needed initially for the development of information systems.



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



As a result, it was necessary to create job descriptions not only for people in the organization, but also for their interaction with information systems. And here there were not enough textual notations (instructions), where all the descriptions were in free text form, they were not relevant 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 were supposed to be equally convenient for translation into machine code, and for human perception.



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

*** On the subject of methodologically developed notations, I also want to say a few words. Why I cited IDEF3 as an example: I have not yet seen a more developed methodologically system for describing business processes. Even BPMN 2.0 is still developing and being finalized. And if you read the English description of IDEF3 (I have not yet seen the translation into Russian), then 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.

The notations allowed us 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.



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



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



It is very important to understand that there is no, for example, a separate “sale business process”. There is a sales process that will become a business process if it is described using notation. Those. Without a description in the business process notation, you are selling, no one disputes this. But so far there is no definite unshakable and unambiguous description of your sales - a phenomenon, something spontaneous. And they will become a business process only after their description in the framework of the notation and the implementation of this description in practice.



Sales is the simplest and most illustrative example. Each of us is in the role of a buyer, and many of us are familiar with this process as a seller. And we all know that even the same person in different situations (for different goods, different buyers, in different weather and in general, depending on the mood) will sell several differently. But if one describes and clearly regulates a certain business process, then no matter “with which foot the seller got up in the morning”, the sale 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 have written 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 a company’s operation to implementing solutions I have proposed at the level of software products and automation systems.



Business process modeling helps solve two problems at once:

• Study business Graphic representation in the form of diagrams, i.e. modeling of business processes allows you to quickly understand the features of the company and identify possible "bottlenecks".
• Ensuring visibility. As you know, "one picture is worth a thousand words." Therefore, a schematic representation of the company's work helps the manager and the business owner 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 software product implementation specialist), it is very important that the client understands all the advantages of the solution. No less important is the feedback - the head of the scheme will be able to see some shortcomings at the stage of discussing the project, and the implementation will go without additional difficulties and make changes to the project “on the fly”.

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

Business processes are needed to present complex information in an easy-to-read form for learning and decision making.

Imagine an ordinary company consisting of different departments: accounting, personnel, sales, warehouse, delivery, production, etc. Above all is one person - a business manager. He physically cannot at the expert level understand all kinds of business processes. That is why they hire various specialists. But he needs to effectively manage all these, and in certain cases - to modernize.



And here business processes come to the rescue. At the same time, certain types of human activity within the company are described by graphic notations and are presented in a form that helps the management to understand exactly how the work at each stage occurs and what can be improved here. In this case, the head of the company does not necessarily have to be highly qualified specialist of a particular profile.



Of course, at this level one cannot do without some information losses. It is impossible to describe in graphical notation all the nuances and details of the work of each employee. But these information losses are insignificant for understanding processes in general and making decisions.

How to describe business processes

In order to get a description of the actual business processes, it is enough just to carefully study the sequence of actions of each employee. Those. it is necessary to obtain information about the incoming data to start a specific process, outgoing - i.e. result of actions of the employee, as well as step by step record the actions that are required.



After all the information is collected, it needs to be translated into a graphical notation. Here it is worth understanding that it is graphic notations that are considered “good form” when drawing up descriptions of business processes. For yourself, you can make a notation as you prefer, textual descriptions of options also exist and are used, for example, by some software developers. But if you are compiling a notation that other people will read, it doesn’t matter whether the program developer or the company manager, choose the graphics.



The reason for this decision is simple: graphically, information is better perceived. If you offer a person a “wall of text”, it will take him a lot of time and effort to figure out what you are talking about. And to cover the entire task in this case is almost unreal. Another thing is graphical schemes - here you can study business processes at different levels of detail, and anyone can quickly “take a glimpse into the general” graphic scheme.



Recommended sequence of actions:

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

Business Process Description Rules

Above, I said a lot about creativity, about the possibilities of including conditions and options 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 textual form) or not:

• Completeness. The business process must clearly answer the question before it. If we are talking about the process of selling a particular product or service, then the business process should fully describe the actions necessary to obtain the specified result, and ending with just such a result (with certain assumptions, which I mentioned above).
• Conciseness. A 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 brought out for myself the “15 minutes rule” - 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 - fine, it takes more time and words - you need to think about what can be shortened and simplified.
  
  I once personally saw a graphical description of a business process, made on a sheet 2 meters long (and the corresponding width). It is even easy to see and understand where the arrow leads which is extremely difficult. And how to explain it to the customer, I personally can not imagine.
  
  Remember that a person perceives visually a certain amount of information, limited, including a certain size of a sheet or screen (this is due to the peculiarities of vision), as well as the number of elements (the capabilities of the brain are also limited). The customer will understand the simple and concise business process simply by “covering” the scheme with a glance. Difficult and oversaturated with details you will have to study 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, will simply not study such a complex structure and will not understand the essence of even the most profitable offers.
• The use of generally accepted notations. Do not invent your own designations and rules. Use the notation used throughout the world. I saw in the books of some domestic authors attempts to create their own system of notation. And, frankly, I did not understand why they complicate life for themselves and their readers. Here, as with a language, you can come up with your own special language, but nobody will understand it except you. And if it turns out to be similar to the existing ones, then confusion may also appear. Either you will be considered illiterate, since you are not using the rules of well-known languages ​​to use punctuation, bow words, etc. So with the notations - there are already well-established, known to people and, which is also important, intuitive notations. That is why they became popular because in the process of their creation and refinement 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 accounted for and expressly stated. And this should be done without using footnotes with numbers, comments in the Swimm line objects (special footnotes), etc. This often "sin" lovers to create their own designs instead of using ready-made notations. Somewhere in their names do not fit, somewhere they think that a long name in the body of the business process will be inconvenient. As a result, you either have to look in the footnotes for whom exactly we 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, should quickly and, ideally, even without your explanations, understand the description of the business process.

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

Common myths and misconceptions

Do not "reinvent the wheel"! No need to invent your own notation.



Often people, instead of studying the features of existing notations, draw graphs in arbitrary form in various graphical programs.



I do not recommend doing so. First, when using ready-made tools, you do not need to reinvent your designations and standards. Everything has long been invented before you. At the same time, standard notations are really understandable intuitively, read unequivocally, are known to many people. Secondly, in ready-made systems (IDEF3, BPMN 2.0, etc.) there is a well-developed methodology and strict limitations. 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, standards of syntax and the environment itself will save you from this (restrictions in the editor, automatic checks).



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



In many automated systems, for example, 1C or Zoho CRM, there are 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. terms seem to sound the same, but in our case it is the 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).



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



In fact, business processes are different. The result will be some kind of true 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 estimate the value of the business process of shipping goods or generating and sending tax reports?



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



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



Not. Business process should be simple, clear, convenient, readable. But he will never be perfect.



When I started to work, I myself all the time thought that I was not working on something, somewhere I could have done better. And often the clients asked me to detail and describe this or that process in more detail. And I also considered it a flaw.



In fact, based on 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 the requests to describe still “this” and “that”. But over time, I realized that business modeling is not just creativity, but a certain dialectical process. And the very creation of a business process will always carry its own denial. Here it is really worth approaching the issue from a philosophical point of view. And creating a business process, you need to remember that we can not cover everything at once, but because it will always be imperfect. But at the same time, we are already laying into it what we will improve in the future. It should be approached simply as a fact.



Your business process should solve the problem, answer the question that is being considered in 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 are not detailing any processes or drawing another business process related to what is being discussed.



For a better understanding of the subject I recommend articles:

• We understand the concept of BPM. What is business process management?
• Business modeling. Basic approaches
• Introduction to the IDEF0 notation and usage example
• A brief description of BPMN with an example
• What is BPMS
• Using GAP analysis to identify and coordinate project tasks

Also, currently I am preparing a book for publication and an online course in which I will describe in detail my own vision of the process approach to business, as well as my own practical experience in the field of functional and process modeling. Anyone can subscribe to a notification about the release of a new book on the link .