80 for 20 - how not to optimize processes
I wrote this post partly in an attempt to justify the perfectionism I sometimes fall into, and partly in order to explain to my colleagues what I think about when I am working on another project.
It all started with a simple remark: two companies operating in the same market and having the same number of personnel may have turnovers and profits that differ by an order of magnitude. Why does this happen if, in essence, they do the same work? Sometimes the main difference lies in the fact that someone is a daughter of a large state-owned company or knows how to win tenders well, but, as I see it, this is only part of the explanation.
I led a lot of IT projects from the “now everything is bad, do something to make it good” stage before writing the code and its subsequent technical support. In addition, several times I acted as a customer for projects, in the technical part of which I did not understand at all. It is important that I worked in companies where the IT component was not the basis of the business, which means that the projects performed were a means of solving someone’s problems, and not the ultimate goal. I have formed a point of view that shows how the “before” state differs from the “after” state, and why the “after” is liked by the end users, even if it implements non-optimal business logic.
')
From the client’s point of view, any company can be represented as a black box, the internal structure of which is unknown. You can submit a request inside it - and, in most cases, the “black box” will return a deterministic response. If the request is correctly formulated (for example, it is an order, and it contains all the information necessary for execution) and some additional conditions are fulfilled (money is transferred to the current account), then the company performs some actions. These actions can be [TV delivery], or [provision of consulting services in the field of taxation], or [room cleaning]. The essence of the actions performed is not important - it is important that the customer creates a request and wants, without delving into the internal structure of the process, to get the result.
You can go deeper and see that within the company the client’s request is transformed into a sequence of requests to different departments within the company, each department also being a black box. The sales manager (questioned correctly?), The warehouse (the goods in stock?), The accounting department (payment received?) Are polled. We are absolutely not interested in exactly how they will receive this answer, only the result is important. If the answer is “yes” to each of the questions, then a request is made to perform the operation “shipment of goods and delivery to the client” and “notifying the client about the time for order execution”, which are also black boxes and can be outsourced in general.
Even within the framework of one department, there may be a division of labor, when several colleagues divide the work among themselves according to some rule. This process can also be represented as a request to perform any actions from one employee to another, and, as in all previous cases, the customer does not have to know what exactly is happening, only the result is important.
If an unforeseen situation occurs at any level, it is escalated up the customer chain to a level where it can be processed. For example, a new employee in the sales department, to whom the duty of checking the formal correctness of incoming requests was shifted, found that the order was incorrectly formulated (there is no product with this name). He reports this to the head of the department in charge of his work. The head of the department may find out that there is not a product with the name WSX012, but WSXO12 (customers always confuse the letter O with zero), manually correct the order text and return it for re-check. Or he can confirm that the request is incorrect and return the task with an error to the upper level, from which the information gets to the original client, who will already decide how the request should be reformulated.
The term “black box” does not mean that the customer really does not know what is happening on the other side of his order, just to create a request and receive an answer this knowledge is not needed. The director of a large online store can ideally know the processes occurring within his company, but if he orders a product using his store, the process of servicing it will in no way differ from the process of servicing any other customer.
The entire set of business processes of a company can be represented in the form of calls to “black boxes”, each of which implements its part of the process in some way implicitly for others. The job of any manager (unless he is in the “playing coach” state) is to create such boxes and then optimize their internal work. Programmers who come after him try to shift each element of this process into a program code that will do the same thing that a person did before him, but in zero (negligible) time and without human errors.
In most cases, customer dissatisfaction arises for one of two reasons:
- time delays. The result is not received or received in a time that does not satisfy the customer;
- the result does not meet the client's basic expectations (wanted A, received B), or there are problems with the quality of execution.
The same reasons are encountered at all levels of the organization: a colleague has delayed the task entrusted to him, and also has been in the process; for three months the purchasing department could not buy a new printer, and when it was purchased it turned out to be black and white, and not color; the company could not send a commercial offer for a week, and when it did, it didn’t have what it was really asked for.
If you try to consider each such case in more detail, it turns out that, for the most part, operations in which such problems have arisen are non-standard. They are required to perform an action that is usually not performed in this process. Even if the total amount of standard actions is dozens of times larger than the volume of non-standard ones, delays and errors occur precisely in those places for which there is no proven algorithm that can be followed. Most of the time is spent not on work, but on trying to understand what needs to be done. Practically nothing depends on the personal qualities of the people involved in the process - yes, the way out of a non-standard situation will be found a little faster or a little slower, but, in any case, most of the time will be spent on thinking about the situation, and not on the actions, the problem decisive.
However, this is also nice, both problems have one general solution - it is necessary to clearly state the algorithm of actions for which you need to act upon the occurrence of all possible types of events. In the presence of a clear and unambiguous algorithm of actions (not necessarily wired into a code, there is enough paper scheme hanging on the wall) problems similar to the one described above almost cease to appear. The work, which used to take a week, suddenly begins to be done in a day, something that required three experienced employees, suddenly begins to demand one student who performs standard actions like “opened a file - stretched a formula - summed up the result - depending on the answer made one of three decisions ". From the side, this seems to be magic, but the main increase in labor productivity does not occur at the moment when one person takes the tedious work to a machine, but when one person’s creative work is reduced to the monotonous work of another. Writing code really becomes necessary when there are so many such instructions that one person cannot reproduce all of them without mistakes, or when the speed of order fulfillment is a key value for a client. But in most cases this is only an auxiliary part of the process, which could go without the help of IT.
This way of presenting processes has many similarities with the programming process as a whole and its basic concepts (such as encapsulation), is very convenient and has many useful applications. For example, it is possible, using several ideally working “black boxes”, like from Lego cubes, to design a new process that will allow the company to earn / save some more money. Comparing the cubes with each other, you can make management decisions: if the cube inside the company does not work efficiently compared to its counterparts, you can optimize it or just throw it out, solving the problem in another way or taking it to outsourcing. However, as practice shows, even the first option - the design of new processes from old cubes - does not work well in practice, and it’s not at all unwilling to change.
Consider the situation: you noticed that after buying service A, customers sometimes come back and buy more services B and C. You decide that you can increase sales of B and C by making a purchase offer to everyone who buys A. Calculation of the cost of each service offer is done independently different teams, but they must be present all together in the final offer to the client - which means that if one of the three teams fails to prepare the proposal on time, the remaining two are waiting for it. If several teams are late, they are waiting for the last one. During the pilot project, you find that the chances of not meeting the deadline for each of the teams are about 20%. So the chances are that no one will be late - 0.8 ^ 3 = 0.51, i.e. Time delays will occur in half the cases. Suppose that in one of three cases such a delay leads to the client leaving. You compare the losses from the client’s withdrawal with the possible profit from the sale of B and C, find that the first one is greater, and decide to close the project.
Why did this happen? Because once upon a time, at the time of the cube creation, the decision was made “20% of efforts - 80% of the result”. Then it looked like a simple and correct solution - it is not known whether sales of each of the services will go at all, and after they went, it was necessary to increase the volume as soon as possible, concentrating only on “standard” clients and ignoring any deviations. However, this strategy led to the fact that the company actually closed the opportunity for development. It cannot effectively carry out complex sales, it cannot do cross-sales even when they are relevant. Due to the fact that each element of a large process is unstable, both in quality and in terms, it is impossible to build something new on its basis.
In the situation above, an alternative option was possible: in each department that prepared a proposal for its product, an analysis was conducted, which showed that all the wealth of the proposed options can be reduced to five boxed products, each of which is suitable for its target audience. Preparation of the proposal to each client is now reduced to replacing the client name in the header of the document (although this can be waived), and delays and errors simply disappeared. Each proposal now consists of carefully prepared and tested parts, which are much better than those that were before. The project with cross-sales successfully launched and brings profit, it is planned to expand its experience to other services of the company. Moreover, by honing the basic processes (sales of A, B and C separately), the company received loyal customers who know what difficulties they face when trying to buy the same from competitors. The most pleasant part - based on this process, you can do the following, which will bring the company even more money. In addition to working with incoming applications, you can begin active sales to potential buyers - the benefit of preparing proposals for each of them is now a mechanical process that can be completed in 5 minutes.
The proposed example is very schematic and patterned, but it vividly shows the situations that I encounter every day. Typically, a company has a small number of ideally working processes and a large number of processes in which, with varying frequency, there are some problems. Typically, the processes of the second type include the first, but very rarely the process that contains problems, is used in another process. Ideally working processes can be represented as cubes of the correct form, from which you can make any process that you can imagine. The second ones are ugly, deformed cubes that can be attached to anything, but which cannot be used for further construction of the structure. Not that they are not tried to be used, but any attempts to do this usually end in failure. Attempts to use cubes that work well occur about as often, but the percentage of successful attempts is incomparably higher. It turns out a kind of evolution within one company, and the more ideally working cubes there are in its composition - the wider the field for experiments and the more flexibility the company receives.
To assess how close the process is to the ideal, it is convenient to use the 6 sigma rule. In simple terms, it can be represented as an estimate of the proportion of errors among the total number of attempts to perform an action. If there are less than 6 errors per thousand in the process, the process satisfies the 4 sigma condition, if less than 2 per ten thousand - the 5 sigma rule, less than three per million - 6 sigma. For most of the processes I worked with, I was never able to reach the level of 6 sigma, but this level is a good guide to the future.
A curious note: for almost all situations that I have seen, the new process, consisting of several old, ideally working parts, brings or saves the company much more money than the basic processes that are part of it separately. Composite products and services that become possible often have incomparably greater value for consumers than each of the elements separately. At the same time, even the improvement of basic processes in itself can distinguish you in comparison with competitors, making you the “default choice”. I believe that, in many cases, it is this approach that allows some companies to surpass others, working in initially equal conditions.
However, such an approach to the design and improvement of processes does not guarantee success. It has its drawbacks - for example, it does not take into account the associated costs. Yes, those users who have already agreed to use the process will be satisfied - they will get a predictable result exactly at the promised moment. But this doesn’t say anything about the internal efficiency of the process - extra actions can be performed inside the black box, time and money are inefficiently spent, but the external user will not know anything about it, because he works with the system, inside which he has no opportunity to look. For this reason, the satisfaction of the old users of the process will not matter if there is a competitor nearby who can perform the same actions, but twice as fast or at a much lower price. To solve such problems, it is better to use other methods - for example, “lean manufacturing” or its analogues in the application to the services sector.
Another point that is not explicitly included in the concept is the queues. There is a possibility that some kind of black box works, providing stable quality and time after time after time, but the average rate of receipt of new orders is higher than the speed of processing current ones. Under such conditions, queues for execution will inevitably form, which cannot be avoided. In general, queues can be a signal that a given process limits the efficiency and speed of its associated processes. There are many ways to solve this problem - from recruiting new employees and increasing speed by automating to eliminating actions that do not add value, but they are not explicitly included in this approach.
Summing up:
- Representing the company as a sequence of black boxes nested in each other is a convenient abstraction, giving a new approach to analyzing the company's problems;
- ideally working black boxes (providing a stable result for a predetermined time) can naturally be included in more complex structures, which increases their importance for the company;
- The approach “20% of efforts - 80% of the result” is an excellent strategy at the beginning, but it slows down or makes further development impossible;
- processes consisting of several elements, as a rule, are more valuable for customers than each part of the process separately.
It all started with a simple remark: two companies operating in the same market and having the same number of personnel may have turnovers and profits that differ by an order of magnitude. Why does this happen if, in essence, they do the same work? Sometimes the main difference lies in the fact that someone is a daughter of a large state-owned company or knows how to win tenders well, but, as I see it, this is only part of the explanation.
I led a lot of IT projects from the “now everything is bad, do something to make it good” stage before writing the code and its subsequent technical support. In addition, several times I acted as a customer for projects, in the technical part of which I did not understand at all. It is important that I worked in companies where the IT component was not the basis of the business, which means that the projects performed were a means of solving someone’s problems, and not the ultimate goal. I have formed a point of view that shows how the “before” state differs from the “after” state, and why the “after” is liked by the end users, even if it implements non-optimal business logic.
')
From the client’s point of view, any company can be represented as a black box, the internal structure of which is unknown. You can submit a request inside it - and, in most cases, the “black box” will return a deterministic response. If the request is correctly formulated (for example, it is an order, and it contains all the information necessary for execution) and some additional conditions are fulfilled (money is transferred to the current account), then the company performs some actions. These actions can be [TV delivery], or [provision of consulting services in the field of taxation], or [room cleaning]. The essence of the actions performed is not important - it is important that the customer creates a request and wants, without delving into the internal structure of the process, to get the result.
You can go deeper and see that within the company the client’s request is transformed into a sequence of requests to different departments within the company, each department also being a black box. The sales manager (questioned correctly?), The warehouse (the goods in stock?), The accounting department (payment received?) Are polled. We are absolutely not interested in exactly how they will receive this answer, only the result is important. If the answer is “yes” to each of the questions, then a request is made to perform the operation “shipment of goods and delivery to the client” and “notifying the client about the time for order execution”, which are also black boxes and can be outsourced in general.
Even within the framework of one department, there may be a division of labor, when several colleagues divide the work among themselves according to some rule. This process can also be represented as a request to perform any actions from one employee to another, and, as in all previous cases, the customer does not have to know what exactly is happening, only the result is important.
If an unforeseen situation occurs at any level, it is escalated up the customer chain to a level where it can be processed. For example, a new employee in the sales department, to whom the duty of checking the formal correctness of incoming requests was shifted, found that the order was incorrectly formulated (there is no product with this name). He reports this to the head of the department in charge of his work. The head of the department may find out that there is not a product with the name WSX012, but WSXO12 (customers always confuse the letter O with zero), manually correct the order text and return it for re-check. Or he can confirm that the request is incorrect and return the task with an error to the upper level, from which the information gets to the original client, who will already decide how the request should be reformulated.
The term “black box” does not mean that the customer really does not know what is happening on the other side of his order, just to create a request and receive an answer this knowledge is not needed. The director of a large online store can ideally know the processes occurring within his company, but if he orders a product using his store, the process of servicing it will in no way differ from the process of servicing any other customer.
The entire set of business processes of a company can be represented in the form of calls to “black boxes”, each of which implements its part of the process in some way implicitly for others. The job of any manager (unless he is in the “playing coach” state) is to create such boxes and then optimize their internal work. Programmers who come after him try to shift each element of this process into a program code that will do the same thing that a person did before him, but in zero (negligible) time and without human errors.
In most cases, customer dissatisfaction arises for one of two reasons:
- time delays. The result is not received or received in a time that does not satisfy the customer;
- the result does not meet the client's basic expectations (wanted A, received B), or there are problems with the quality of execution.
The same reasons are encountered at all levels of the organization: a colleague has delayed the task entrusted to him, and also has been in the process; for three months the purchasing department could not buy a new printer, and when it was purchased it turned out to be black and white, and not color; the company could not send a commercial offer for a week, and when it did, it didn’t have what it was really asked for.
If you try to consider each such case in more detail, it turns out that, for the most part, operations in which such problems have arisen are non-standard. They are required to perform an action that is usually not performed in this process. Even if the total amount of standard actions is dozens of times larger than the volume of non-standard ones, delays and errors occur precisely in those places for which there is no proven algorithm that can be followed. Most of the time is spent not on work, but on trying to understand what needs to be done. Practically nothing depends on the personal qualities of the people involved in the process - yes, the way out of a non-standard situation will be found a little faster or a little slower, but, in any case, most of the time will be spent on thinking about the situation, and not on the actions, the problem decisive.
However, this is also nice, both problems have one general solution - it is necessary to clearly state the algorithm of actions for which you need to act upon the occurrence of all possible types of events. In the presence of a clear and unambiguous algorithm of actions (not necessarily wired into a code, there is enough paper scheme hanging on the wall) problems similar to the one described above almost cease to appear. The work, which used to take a week, suddenly begins to be done in a day, something that required three experienced employees, suddenly begins to demand one student who performs standard actions like “opened a file - stretched a formula - summed up the result - depending on the answer made one of three decisions ". From the side, this seems to be magic, but the main increase in labor productivity does not occur at the moment when one person takes the tedious work to a machine, but when one person’s creative work is reduced to the monotonous work of another. Writing code really becomes necessary when there are so many such instructions that one person cannot reproduce all of them without mistakes, or when the speed of order fulfillment is a key value for a client. But in most cases this is only an auxiliary part of the process, which could go without the help of IT.
This way of presenting processes has many similarities with the programming process as a whole and its basic concepts (such as encapsulation), is very convenient and has many useful applications. For example, it is possible, using several ideally working “black boxes”, like from Lego cubes, to design a new process that will allow the company to earn / save some more money. Comparing the cubes with each other, you can make management decisions: if the cube inside the company does not work efficiently compared to its counterparts, you can optimize it or just throw it out, solving the problem in another way or taking it to outsourcing. However, as practice shows, even the first option - the design of new processes from old cubes - does not work well in practice, and it’s not at all unwilling to change.
Consider the situation: you noticed that after buying service A, customers sometimes come back and buy more services B and C. You decide that you can increase sales of B and C by making a purchase offer to everyone who buys A. Calculation of the cost of each service offer is done independently different teams, but they must be present all together in the final offer to the client - which means that if one of the three teams fails to prepare the proposal on time, the remaining two are waiting for it. If several teams are late, they are waiting for the last one. During the pilot project, you find that the chances of not meeting the deadline for each of the teams are about 20%. So the chances are that no one will be late - 0.8 ^ 3 = 0.51, i.e. Time delays will occur in half the cases. Suppose that in one of three cases such a delay leads to the client leaving. You compare the losses from the client’s withdrawal with the possible profit from the sale of B and C, find that the first one is greater, and decide to close the project.
Why did this happen? Because once upon a time, at the time of the cube creation, the decision was made “20% of efforts - 80% of the result”. Then it looked like a simple and correct solution - it is not known whether sales of each of the services will go at all, and after they went, it was necessary to increase the volume as soon as possible, concentrating only on “standard” clients and ignoring any deviations. However, this strategy led to the fact that the company actually closed the opportunity for development. It cannot effectively carry out complex sales, it cannot do cross-sales even when they are relevant. Due to the fact that each element of a large process is unstable, both in quality and in terms, it is impossible to build something new on its basis.
In the situation above, an alternative option was possible: in each department that prepared a proposal for its product, an analysis was conducted, which showed that all the wealth of the proposed options can be reduced to five boxed products, each of which is suitable for its target audience. Preparation of the proposal to each client is now reduced to replacing the client name in the header of the document (although this can be waived), and delays and errors simply disappeared. Each proposal now consists of carefully prepared and tested parts, which are much better than those that were before. The project with cross-sales successfully launched and brings profit, it is planned to expand its experience to other services of the company. Moreover, by honing the basic processes (sales of A, B and C separately), the company received loyal customers who know what difficulties they face when trying to buy the same from competitors. The most pleasant part - based on this process, you can do the following, which will bring the company even more money. In addition to working with incoming applications, you can begin active sales to potential buyers - the benefit of preparing proposals for each of them is now a mechanical process that can be completed in 5 minutes.
The proposed example is very schematic and patterned, but it vividly shows the situations that I encounter every day. Typically, a company has a small number of ideally working processes and a large number of processes in which, with varying frequency, there are some problems. Typically, the processes of the second type include the first, but very rarely the process that contains problems, is used in another process. Ideally working processes can be represented as cubes of the correct form, from which you can make any process that you can imagine. The second ones are ugly, deformed cubes that can be attached to anything, but which cannot be used for further construction of the structure. Not that they are not tried to be used, but any attempts to do this usually end in failure. Attempts to use cubes that work well occur about as often, but the percentage of successful attempts is incomparably higher. It turns out a kind of evolution within one company, and the more ideally working cubes there are in its composition - the wider the field for experiments and the more flexibility the company receives.
To assess how close the process is to the ideal, it is convenient to use the 6 sigma rule. In simple terms, it can be represented as an estimate of the proportion of errors among the total number of attempts to perform an action. If there are less than 6 errors per thousand in the process, the process satisfies the 4 sigma condition, if less than 2 per ten thousand - the 5 sigma rule, less than three per million - 6 sigma. For most of the processes I worked with, I was never able to reach the level of 6 sigma, but this level is a good guide to the future.
A curious note: for almost all situations that I have seen, the new process, consisting of several old, ideally working parts, brings or saves the company much more money than the basic processes that are part of it separately. Composite products and services that become possible often have incomparably greater value for consumers than each of the elements separately. At the same time, even the improvement of basic processes in itself can distinguish you in comparison with competitors, making you the “default choice”. I believe that, in many cases, it is this approach that allows some companies to surpass others, working in initially equal conditions.
However, such an approach to the design and improvement of processes does not guarantee success. It has its drawbacks - for example, it does not take into account the associated costs. Yes, those users who have already agreed to use the process will be satisfied - they will get a predictable result exactly at the promised moment. But this doesn’t say anything about the internal efficiency of the process - extra actions can be performed inside the black box, time and money are inefficiently spent, but the external user will not know anything about it, because he works with the system, inside which he has no opportunity to look. For this reason, the satisfaction of the old users of the process will not matter if there is a competitor nearby who can perform the same actions, but twice as fast or at a much lower price. To solve such problems, it is better to use other methods - for example, “lean manufacturing” or its analogues in the application to the services sector.
Another point that is not explicitly included in the concept is the queues. There is a possibility that some kind of black box works, providing stable quality and time after time after time, but the average rate of receipt of new orders is higher than the speed of processing current ones. Under such conditions, queues for execution will inevitably form, which cannot be avoided. In general, queues can be a signal that a given process limits the efficiency and speed of its associated processes. There are many ways to solve this problem - from recruiting new employees and increasing speed by automating to eliminating actions that do not add value, but they are not explicitly included in this approach.
Summing up:
- Representing the company as a sequence of black boxes nested in each other is a convenient abstraction, giving a new approach to analyzing the company's problems;
- ideally working black boxes (providing a stable result for a predetermined time) can naturally be included in more complex structures, which increases their importance for the company;
- The approach “20% of efforts - 80% of the result” is an excellent strategy at the beginning, but it slows down or makes further development impossible;
- processes consisting of several elements, as a rule, are more valuable for customers than each part of the process separately.
Source: https://habr.com/ru/post/301528/
All Articles