80 for 20 - how not to optimize processes

    I wrote this post partly in an attempt to justify the perfectionism that I sometimes fall into, and partly to explain to my colleagues what I think about when I am working on the next project.

    It all started with a simple remark: two companies operating on the same market and having the same number of staff can have turnovers and profits that differ by an order of magnitude. Why does this happen if, in essence, they are doing the same job? Sometimes the main difference is that someone is the daughter of a large state-owned company or knows how to win tenders well, but it seems to me that this is only part of the explanation.

    I led a lot of IT projects from the stage “everything is bad now, do something to become good” to writing code and its subsequent technical support. In addition, I several times 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 being implemented were a means of solving someone's problems, and not the ultimate goal. I have formed a point of view that shows how the state “before” differs from the state “after”, and why “after” is liked by end users, even if it implements not 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 answer. 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 met (money has been transferred to the current account), then the company takes some action. These actions may be [delivery of a television], or [the provision of tax advisory services], or [cleaning of the premises]. The essence of the actions 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 inside the company the client’s request is transformed into a sequence of requests to different departments within the company, and each department is also a black box. The sales manager is sequentially interrogated (is the request correctly formulated?), Warehouse (goods in stock?), Accounting (payment received?). We are absolutely not interested in how exactly 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 for the operation “goods shipment and delivery to the customer” and “notification of the customer about the deadline for the execution of the order”, which are also black boxes and can generally be outsourced outside the company.

    Even within the same 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 presented in the form of a request to carry out any actions from one employee to another, and, as in all previous cases, the customer of the action does not need to know what exactly is happening, only the result is important.

    If an unexpected situation occurs at any level, it escalates up the customer chain to a level where it will be possible to handle. For example, a new employee in the sales department, who was transferred to the obligation to verify the formal correctness of incoming requests, found that the order was not formulated correctly (there are no products with this name). He reports this to the head of the department in charge of his work. The head of the department may find that this is not a product with the name WSX012, but WSXO12 (customers always confuse the letter O with zero), manually adjust the order text and return it for re-examination. Or he can confirm that the request is incorrectly compiled and return the problem with the error to the upper level, from which the information will go to the original client, who will already solve it,

    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 necessary. The director of a large online store can ideally know the processes taking place inside his company, but if he orders goods using his store, the process of his service will not fundamentally differ from the process of servicing any other customer.

    The entire set of business processes of the company can be represented in the form of appeals to the "black boxes", each of which, in some implicit way for others, implements its part of the process. The work of any leader (unless he is in a “playing coach” state) is to create such boxes and then optimize their internal work. The programmers who come next try to translate each element of this process into program code that will perform the same thing as a person did before, but in zero (negligible) time and without human errors.

    In the vast majority of 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 basic expectations of the client (wanted A, got B), or there are problems with the quality of execution.

    The same reasons can be found at all levels of the organization: a colleague has overdue the task assigned to him, and he is still stretched in the process; For three months, the procurement department could not purchase a new printer, and when it did, it turned out to be black and white, not color; the company could not send a commercial offer for a week, and when it did, it did not contain what was really requested.

    If you try to consider each such case in more detail, it turns out that, for the most part, operations in which similar problems have arisen are non-standard. They require an action that is usually not performed as part of this process. Even if the total volume of standard actions is ten 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. The main time is spent not on work, but on attempts to understand what needs to be done. Almost nothing depends on the personal qualities of the people who participate in the process - yes, a way out of the 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 taking actions, the problem decisive.

    However, and this is pleasant, both problems have one common solution - it is necessary to clearly define the algorithm of actions, according to which it is necessary to act when all possible types of events occur. If there is a clear and unambiguous algorithm of actions (not necessarily wired into the code, a paper circuit hanging on the wall is enough), problems like the ones described above practically stop appearing. The work, which used to take a week, suddenly begins to be completed in a day, what required three experienced employees, suddenly begins to require one student, performing template actions such as “opened a file - extended a formula - summed up the result - depending on the answer, he made one of three decisions ".From the outside, this seems like magic, but the main increase in labor productivity does not occur at the moment when the boring work of one person is transferred to the machine, but when the creative work of one person is reduced to the monotonous work of another. Writing a code really becomes necessary when there are so many such instructions that one person cannot reproduce them all without errors, or when the speed of order execution is a key value for the client. But in most cases, this is only an auxiliary part of the process, which could go without the help of IT.

    This method of representing processes has many analogies with the programming process as a whole and its basic concepts (such as encapsulation), is very convenient and has many useful applications. For example, using several perfectly working “black boxes”, like from Lego blocks, you can 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 effectively compared to peers, you can optimize it or just throw it out, solving the problem in another way or outsourcing it. However, as practice shows, even the first option - constructing new processes from old cubes - does not work well in practice, and the point is not the reluctance to change.
    Consider the situation: you noticed that after the purchase of service A, sometimes customers return and buy 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. The cost of each service is calculated independently different teams, but in the final proposal to the client they should be present all together - which means that if one of the three teams does not have time to prepare the proposal on time, the remaining two are waiting for it. If several teams are late, wait for the last of them. During the pilot project, you find that the chances of not meeting the deadline for each team are about 20%. So the chances are that no one will be late - 0.8 ^ 3 = 0.51, i.e. delays will occur in half the cases. Suppose that in one of three cases, such a delay leads to that the client is leaving. You compare the loss from the client’s departure with the possible profit from the sale of B and C, you find that the first is bigger, and you decide to curtail the project.

    Why did this happen? Because once upon a time, at the time of the creation of the cube, the decision was made "20% effort - 80% of the result." Then it looked like a simple and correct decision - 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 quickly as possible, concentrating only on “standard” customers and ignoring any deviations. However, this strategy led to the fact that the company actually closed for itself the opportunity for development. She cannot effectively carry out complex sales, she cannot do cross-sales, even when they are appropriate. Due to the fact that each element of a large process is unstable both in quality and in terms of time, something new cannot be built on its basis.

    In the situation above, an alternative option was also possible: an analysis was carried out in each department preparing a proposal for its product, which showed that all the wealth of the proposed options can be reduced to five packaged products, each of which is suitable for its target audience. Preparing an offer for each client now comes down to replacing the name of the client in the header of the document (although you can refuse this), 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 has been successfully launched and brings profit, it is planned to expand its experience to other services of the company. Moreover, by perfecting the underlying processes (selling A, B and C separately), the company received loyal customers, who are aware of the difficulties they face when trying to buy the same from competitors. The most enjoyable part - based on this process, you can make the next one, which will bring the company even more money. In addition to working with incoming applications, you can begin active sales to potential buyers - since the preparation of an offer for each of them is now a mechanical process that can be completed in 5 minutes.

    The proposed example is very schematic and template, but it clearly shows the situations that I encounter every day. Typically, a company has a small number of perfectly working processes and a large number of processes in which, with one or another periodicity, some problems arise. Typically, processes of the second type include the first, but very rarely, a process containing 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 are ugly, deformed cubes that can be attached to something, but which cannot be used for further construction of the structure. Not that they are not trying to use them, but any attempts to do this usually end in failure. Attempts to use cubes that work well are about as common, but the percentage of successful attempts is incomparably higher. It turns out a kind of evolution within the framework of one company, and the more ideally working cubes 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 ideal, it is convenient to use the 6 sigma rule. In a simple statement, it can be represented as an estimate of the proportion of errors among the total number of attempts to perform an action. If less than 6 errors per thousand occur 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 that I worked with, I still could not reach level 6 sigma, but this level is a good guide for the future.

    A curious remark: for almost all situations that I saw, a new process, consisting of several old ideally working parts, brings or saves a company much more money than the basic processes that are part of it separately. Composite products and services that become possible often have disproportionately greater value to consumers than each of the elements individually. At the same time, even improving the underlying processes in itself can set you apart from competitors, making you a “default choice”. I believe that, in many cases, it is this approach that allows some companies to surpass others by working under equal conditions.
    However, this approach to the design and improvement of processes does not guarantee success. It has its drawbacks - for example, does not include associated costs. Yes, those users who have already agreed to use the process will be satisfied - they will receive a predictable result exactly at the promised time. But this does not say anything about the internal efficiency of the process - extra actions may take place inside the black box, time and money can be spent inefficiently, but the external user will not know anything about this, since he works with a system that he has no way to look inside. For this reason, the satisfaction of the old users of the process will not mean anything if there is a competitor nearby who can perform the same actions, but twice as fast or at a much lower price.

    Another point that is not explicitly included in the concept is queues. There is a possibility that some kind of black box works, providing stable quality and terms over and over again, but the average speed of new orders is higher than the speed of processing current ones. In such conditions, execution queues will inevitably be formed, which cannot be avoided. In general, queues can be a signal that a given process limits the efficiency and speed of processes associated with it. There are many ways to solve this problem - from recruiting new employees and increasing speed through automation to eliminating actions that do not add value, but they are not explicitly included in this approach.

    To summarize:
    - the presentation of the company as a sequence of black boxes nested in each other is a convenient abstraction, giving a new approach to the analysis of company problems;
    - perfectly working black boxes (providing a stable result in a predetermined time) can naturally be included in more complex designs, which increases their importance for the company;
    - The “20% effort - 80% result” approach is an excellent strategy in the beginning, but it slows down or makes further development impossible;
    - processes consisting of several elements, as a rule, are more valuable to customers than each part of the process separately.

    Also popular now: