"The very goal" in the design to order
Recently, I read Elie Goldrath’s novel “The very Goal” . By virtue of the habit of taking advantage of everything, I wanted to apply the knowledge of his Theory of Constraints in the conditions of our company that develops custom software. In this article I will try to summarize the main ideas from the book, and then draw conclusions in the context of my subject area. I would be glad if someone interested in the novel, because it is worth it. Pointing to errors in my objective and logically flawless reasoning is also welcome.
The first thought with which the storyline begins is the definition of the company's objectives. According to Eli Goldrath, “that very goal” is only one and the main character spends several chapters, painfully trying to clarify it. “What determines the success of the enterprise?”, - they are plagued by his doubts, “can there be minimization of costs or 100% utilization of production capacities?”. At first, these torments seemed to me to be feigned — profits , this is the main goal of any company and the idea that the main character comes to after some time. But why did Goldrath want to show that this is not obvious?
')
A couple of days after I read the first few chapters, the director of the competitors company called me to talk with their project manager and marketer on the topic of increasing production efficiency. Since I always gladly help competitors, I accepted the invitation. My first question was: "What are the main objectives facing your company?". The manager responded: "effective management of developers, optimal distribution of tasks." Marketer said: "search for promising customers." Their director, suspecting a trick, squinted and began to look intently, waiting for an answer. I told about "the very goal."
It would seem that the phrase “the main goal of an enterprise is to make a profit” is an axiom learned by all people who studied economics. A quality software product itself will not turn into money if it is not sold, just as the customer will not become a source of profit until his needs are satisfied. Practice has shown that the company's employees consider the good performance of their duties as her goal. Since the statistical sample was small, I asked our technical director: “What is the purpose of our company?”. He replied: “To make cool software and leave a mark on the universe,” then he thought and added, “so that people like our programs. And make the world a better place. ”
After that, I began to doubt my moral and ethical qualities, but I did not divorce the philosophy. Therefore, by a strong-willed decision we will take profit maximization as the main goal of the company and choose the metrics necessary for its measurement:
* Net profit
* Return Of Investment = (return on investment - investment value) / investment value
* Cash flow
Fans of accurate translation and common sense can argue: the goal is something clearly defined that can be achieved. Therefore, we will talk more about the process of continuous improvements , the result of which is a constant increase in the three above mentioned parameters. It is important to understand that a positive effect can only be called a simultaneous improvement. For example, a million profit per month is good if investments amounted to 5 million, but it is bad if a billion was invested. Similar to cash flow. Profit can be big by the end of the quarter, when money is received for several projects, but if in the first two months there is not enough cash flow to pay salaries to programmers, then the company will cease to exist.
It all sounds simple and reasonable, but the question arises - what should be done to begin the process of continuous improvements?
It is proposed to consider alternative indicators:
Definitions:
Revenue generation rate is the rate at which the system generates money through sales.
Bonded capital is all the money invested by the system in purchased items that can be sold.
Operating expenses are all the money that the system spends turning the tied capital into revenue generation.
These definitions leave some room for use. The main thing in them is that they are interrelated and can be used in the study of processes in any production. Consider a few examples. Office rent, staff salaries, consumables are all transaction costs (if we are not going to resell markers or paper). Purchased hardware and software is associated capital.
The situation with the money spent on staff development and the time invested in the development of various useful libraries and components is a bit more complicated. Due to the specifics of the IT industry, we will consider intellectual property as a “thing” that can be sold.
From a theoretical point of view, the basic idea is to maximize the rate of revenue generation while minimizing the associated capital and the speed of operating expenses. With operating expenses, everything is clear - the less we pay for the office, the greater the profit. With the generation of income too, the dollar received today is better than a dollar tomorrow, and even better today is to get two dollars. Less obvious is the fact that tied up capital increases operating expenses. Example: the more computers used to produce software, the more electricity they consume. Semi-finished products in a furniture factory must be stored in a warehouse, transported, taken into account, etc. The programmer, in whose education a lot of money was invested, has a high qualification and, accordingly, requires a large salary. From this point of view, it seems a rational idea that developing your own products is more profitable than developing to order, since it is possible to achieve a higher rate of income generation with less coherent capital.
Before we try to apply the above theory to the practice of an IT company and develop practical tips for implementing the process of continuous improvements, let's look at two more important concepts:
The first means that one operation in production cannot begin until another is completed. For example, in order for the designer to create a user interface, he needs to receive from the analyst the requirements for this functionality. So that the programmer can finish the corresponding component, he needs graphics from the designer. The tester needs to wait for the programmer to finish working in order to check the stability and compliance of the component with the requirements. Add to this the possible interactions with the server team, customer representatives, and the sales department and you get a set of fairly long chains that connect our company hand and foot. But to generate income, you need a successful completion of all events from the first to the last, and the order is often fixed.
The basic postulate of the theory of restrictions says: the chain is not stronger than its weakest link.
This means that the rate of income generation is determined by the performance of the weakest link in the chain. If the designer delivers materials faster than the programmer can process them, then the speed of the designer will not have a positive effect on the speed of the entire system. Similarly, if a programmer quickly adds functionality, but a low level of test automation increases the time needed for quality control, then this functionality will be delivered no sooner than testers can do their job.
To present the postulate more clearly, Goldrath gives an example with schoolchildren going on a campaign. The group must completely get from point A to point B and the time it spent on this task will be no less than the time that its slowest participant would spend.
Now let's talk about statistical deviations. Measuring the speed of a designer, programmer or tester is quite difficult. Too creative we have a profession. Suppose we built a team in such a way that the average figures are aligned to the overall system capacity. That is, on average, the analyst delivers as many tasks as is needed for the iteration, the programmers, on the basis of average speed, cope with them on time and transmit to the group of testers.
The stupidest thing in such a situation would be to assume that the speed of the system will eventually be equal to the average speed under which we equalized our events - the stages of development. The problem is in statistical deviations. Designers sometimes have a headache, and sometimes, on the contrary, a muse visits them. Programmers may issue more code than expected, or suddenly go on vacation, etc.
What happens then? Let's take 4 saucers - they will be the stages of production, a bunch of coins and dice. Coins must move from one pile to another, alternately visiting the saucers 1, 2, 3 and 4. In the first step, we throw a bone and shift from the pile to the first saucer as many coins as we have dropped. Then we throw the bone again and shift from the first saucer to the second one as many coins as this time fell, but no more than we have in the first saucer. And so on, until the coins are "processed."
Since the average speed of the movement of coins between saucers is (1 + 2 + 3 + 4 + 5 + 6) / 6 = 3.5, we can assume that in 20 iterations we will get 20 * 3.5 - approximately 70 coins.
The experiment showed a real “rate of income generation”: 59 coins were processed and another 10 were stuck in tied-up capital (although they had every chance to go from beginning to end). Thus, the system worked only on 84% of the expected average power:
Hence one of the conclusions is not to rely in the project assessment solely on the speed of development. Although this link is most often the most time consuming, and therefore narrow, the speed of the system may be even lower as a result of statistical deviations.
In addition, we did not take into account that the tied capital, which appears due to statistical deviations, increased the speed of operating expenses during the system operation, which means that the real situation is even worse.
In conclusion, I will formulate several assumptions that I have made for myself and would like to put on discussion.
It is advisable not to start a task if it depends on the completion of another event and cannot be completed soon. Waiting for a bottleneck and trying to do part of the task in advance, we create tied capital. For example, if the server code is not yet ready, we can write the code of interaction with the server on the client, outputting the parameters to the log. When the server is written, the developer will still have to return to the interaction module, re-recall how it works and correct the unrecorded differences. A large number of unfinished tasks spends additional time, as we constantly think about them and go over to find an opportunity to complete. Suppose we know that we can’t finish anything that has begun, until the colleagues finish their work. In this case, the problem must be solved at the project management level, trying to increase the performance of narrow links, rather than working for the future.
When searching for new projects, quite a large number of potential customers are processed. With many of them we are entering the stage of active negotiations. Sometimes there are situations when all production facilities are already loaded, and negotiations with new customers still continue. In this case, you need to tell the sales department - "do not cook the pot." Otherwise, we have several orders that are not started and maybe never started, but they take time to interact with customers: answers to their technical questions, requests to research or evaluate something, etc. The argument “it’s a pity to get rid of a potential project” has a greater psychological factor than a rational one. The search for orders is just one of the stages of production when developing to order, and if it has greater throughput than other stages, then the creation of tied capital should be stopped, especially if there is a probability of non-conversion into income generation.
Periodically, the opposite situation happens, when the project for the client is finished and the developer needs to take something. We, as a company wishing to switch from outsourcing to product development, in such cases invented a “own” project to the programmer. And these projects started a lot, because the developers are strong in different areas and the focus was precisely on their skill. It was also believed that the project would not be of the best quality, if 10 people in turn would work on it. As a result, we have accumulated a lot of “products”, none of which reached the final consumer, i.e. did not affect the rate of income generation. Most of them are simply unfinished. It would seem that nothing terrible - but we avoided the downtime of programmers, but in so doing a huge amount of tied capital was created. We spend a lot of time on these projects, periodically trying to continue development, but mostly remembering “what is happening here” or deciding to “rewrite this part because new libraries have come out” or “we have learned to do better”. Now when developing our own products, we first of all carry out planning, allocate all the necessary resources and follow the plan until the project is completed. And if developers have downtime, then they can read a book at this time.
I want to say thank you for all the intellectual work that I have made to these lines and I wish to keep the mind wide open to new ideas. The world is logical, we can only correctly understand the prerequisites and, as an unavoidable consequence, to achieve the desired result.
Target definition
The first thought with which the storyline begins is the definition of the company's objectives. According to Eli Goldrath, “that very goal” is only one and the main character spends several chapters, painfully trying to clarify it. “What determines the success of the enterprise?”, - they are plagued by his doubts, “can there be minimization of costs or 100% utilization of production capacities?”. At first, these torments seemed to me to be feigned — profits , this is the main goal of any company and the idea that the main character comes to after some time. But why did Goldrath want to show that this is not obvious?
')
A couple of days after I read the first few chapters, the director of the competitors company called me to talk with their project manager and marketer on the topic of increasing production efficiency. Since I always gladly help competitors, I accepted the invitation. My first question was: "What are the main objectives facing your company?". The manager responded: "effective management of developers, optimal distribution of tasks." Marketer said: "search for promising customers." Their director, suspecting a trick, squinted and began to look intently, waiting for an answer. I told about "the very goal."
It would seem that the phrase “the main goal of an enterprise is to make a profit” is an axiom learned by all people who studied economics. A quality software product itself will not turn into money if it is not sold, just as the customer will not become a source of profit until his needs are satisfied. Practice has shown that the company's employees consider the good performance of their duties as her goal. Since the statistical sample was small, I asked our technical director: “What is the purpose of our company?”. He replied: “To make cool software and leave a mark on the universe,” then he thought and added, “so that people like our programs. And make the world a better place. ”
After that, I began to doubt my moral and ethical qualities, but I did not divorce the philosophy. Therefore, by a strong-willed decision we will take profit maximization as the main goal of the company and choose the metrics necessary for its measurement:
* Net profit
* Return Of Investment = (return on investment - investment value) / investment value
* Cash flow
Fans of accurate translation and common sense can argue: the goal is something clearly defined that can be achieved. Therefore, we will talk more about the process of continuous improvements , the result of which is a constant increase in the three above mentioned parameters. It is important to understand that a positive effect can only be called a simultaneous improvement. For example, a million profit per month is good if investments amounted to 5 million, but it is bad if a billion was invested. Similar to cash flow. Profit can be big by the end of the quarter, when money is received for several projects, but if in the first two months there is not enough cash flow to pay salaries to programmers, then the company will cease to exist.
It all sounds simple and reasonable, but the question arises - what should be done to begin the process of continuous improvements?
Eliyahu Goldrath's indicators
It is proposed to consider alternative indicators:
- Revenue generation rate
- Tied capital
- Operating expenses
Definitions:
Revenue generation rate is the rate at which the system generates money through sales.
Bonded capital is all the money invested by the system in purchased items that can be sold.
Operating expenses are all the money that the system spends turning the tied capital into revenue generation.
These definitions leave some room for use. The main thing in them is that they are interrelated and can be used in the study of processes in any production. Consider a few examples. Office rent, staff salaries, consumables are all transaction costs (if we are not going to resell markers or paper). Purchased hardware and software is associated capital.
The situation with the money spent on staff development and the time invested in the development of various useful libraries and components is a bit more complicated. Due to the specifics of the IT industry, we will consider intellectual property as a “thing” that can be sold.
From a theoretical point of view, the basic idea is to maximize the rate of revenue generation while minimizing the associated capital and the speed of operating expenses. With operating expenses, everything is clear - the less we pay for the office, the greater the profit. With the generation of income too, the dollar received today is better than a dollar tomorrow, and even better today is to get two dollars. Less obvious is the fact that tied up capital increases operating expenses. Example: the more computers used to produce software, the more electricity they consume. Semi-finished products in a furniture factory must be stored in a warehouse, transported, taken into account, etc. The programmer, in whose education a lot of money was invested, has a high qualification and, accordingly, requires a large salary. From this point of view, it seems a rational idea that developing your own products is more profitable than developing to order, since it is possible to achieve a higher rate of income generation with less coherent capital.
Dependent events and statistical deviations
Before we try to apply the above theory to the practice of an IT company and develop practical tips for implementing the process of continuous improvements, let's look at two more important concepts:
- Dependent events
- Statistical deviations
The first means that one operation in production cannot begin until another is completed. For example, in order for the designer to create a user interface, he needs to receive from the analyst the requirements for this functionality. So that the programmer can finish the corresponding component, he needs graphics from the designer. The tester needs to wait for the programmer to finish working in order to check the stability and compliance of the component with the requirements. Add to this the possible interactions with the server team, customer representatives, and the sales department and you get a set of fairly long chains that connect our company hand and foot. But to generate income, you need a successful completion of all events from the first to the last, and the order is often fixed.
The basic postulate of the theory of restrictions says: the chain is not stronger than its weakest link.
This means that the rate of income generation is determined by the performance of the weakest link in the chain. If the designer delivers materials faster than the programmer can process them, then the speed of the designer will not have a positive effect on the speed of the entire system. Similarly, if a programmer quickly adds functionality, but a low level of test automation increases the time needed for quality control, then this functionality will be delivered no sooner than testers can do their job.
To present the postulate more clearly, Goldrath gives an example with schoolchildren going on a campaign. The group must completely get from point A to point B and the time it spent on this task will be no less than the time that its slowest participant would spend.
Now let's talk about statistical deviations. Measuring the speed of a designer, programmer or tester is quite difficult. Too creative we have a profession. Suppose we built a team in such a way that the average figures are aligned to the overall system capacity. That is, on average, the analyst delivers as many tasks as is needed for the iteration, the programmers, on the basis of average speed, cope with them on time and transmit to the group of testers.
The stupidest thing in such a situation would be to assume that the speed of the system will eventually be equal to the average speed under which we equalized our events - the stages of development. The problem is in statistical deviations. Designers sometimes have a headache, and sometimes, on the contrary, a muse visits them. Programmers may issue more code than expected, or suddenly go on vacation, etc.
What happens then? Let's take 4 saucers - they will be the stages of production, a bunch of coins and dice. Coins must move from one pile to another, alternately visiting the saucers 1, 2, 3 and 4. In the first step, we throw a bone and shift from the pile to the first saucer as many coins as we have dropped. Then we throw the bone again and shift from the first saucer to the second one as many coins as this time fell, but no more than we have in the first saucer. And so on, until the coins are "processed."
Since the average speed of the movement of coins between saucers is (1 + 2 + 3 + 4 + 5 + 6) / 6 = 3.5, we can assume that in 20 iterations we will get 20 * 3.5 - approximately 70 coins.
The experiment showed a real “rate of income generation”: 59 coins were processed and another 10 were stuck in tied-up capital (although they had every chance to go from beginning to end). Thus, the system worked only on 84% of the expected average power:
Hence one of the conclusions is not to rely in the project assessment solely on the speed of development. Although this link is most often the most time consuming, and therefore narrow, the speed of the system may be even lower as a result of statistical deviations.
In addition, we did not take into account that the tied capital, which appears due to statistical deviations, increased the speed of operating expenses during the system operation, which means that the real situation is even worse.
findings
In conclusion, I will formulate several assumptions that I have made for myself and would like to put on discussion.
It is advisable not to start a task if it depends on the completion of another event and cannot be completed soon. Waiting for a bottleneck and trying to do part of the task in advance, we create tied capital. For example, if the server code is not yet ready, we can write the code of interaction with the server on the client, outputting the parameters to the log. When the server is written, the developer will still have to return to the interaction module, re-recall how it works and correct the unrecorded differences. A large number of unfinished tasks spends additional time, as we constantly think about them and go over to find an opportunity to complete. Suppose we know that we can’t finish anything that has begun, until the colleagues finish their work. In this case, the problem must be solved at the project management level, trying to increase the performance of narrow links, rather than working for the future.
When searching for new projects, quite a large number of potential customers are processed. With many of them we are entering the stage of active negotiations. Sometimes there are situations when all production facilities are already loaded, and negotiations with new customers still continue. In this case, you need to tell the sales department - "do not cook the pot." Otherwise, we have several orders that are not started and maybe never started, but they take time to interact with customers: answers to their technical questions, requests to research or evaluate something, etc. The argument “it’s a pity to get rid of a potential project” has a greater psychological factor than a rational one. The search for orders is just one of the stages of production when developing to order, and if it has greater throughput than other stages, then the creation of tied capital should be stopped, especially if there is a probability of non-conversion into income generation.
Periodically, the opposite situation happens, when the project for the client is finished and the developer needs to take something. We, as a company wishing to switch from outsourcing to product development, in such cases invented a “own” project to the programmer. And these projects started a lot, because the developers are strong in different areas and the focus was precisely on their skill. It was also believed that the project would not be of the best quality, if 10 people in turn would work on it. As a result, we have accumulated a lot of “products”, none of which reached the final consumer, i.e. did not affect the rate of income generation. Most of them are simply unfinished. It would seem that nothing terrible - but we avoided the downtime of programmers, but in so doing a huge amount of tied capital was created. We spend a lot of time on these projects, periodically trying to continue development, but mostly remembering “what is happening here” or deciding to “rewrite this part because new libraries have come out” or “we have learned to do better”. Now when developing our own products, we first of all carry out planning, allocate all the necessary resources and follow the plan until the project is completed. And if developers have downtime, then they can read a book at this time.
I want to say thank you for all the intellectual work that I have made to these lines and I wish to keep the mind wide open to new ideas. The world is logical, we can only correctly understand the prerequisites and, as an unavoidable consequence, to achieve the desired result.
Source: https://habr.com/ru/post/140169/
All Articles