Geekly Articles each Day
📜 ⬆️ ⬇️

Application of the Theory of Constraints to the statement of the process

In the activities of the manager there is always some share of work related to the formulation of business processes . As a rule, this is necessary when new company needs arise, greater turnover, better stability in cash flow, or just to introduce some improvements. Sometimes it happens that we are confronted only with symptoms or undesirable phenomena, when something goes wrong: we “sell” terms, the customer is dissatisfied, too high costs of maintaining the infrastructure or other costs. There is a common detail between these two positions: if there is a need for change, something means that these improvements are holding back, and this can be regarded as an undesirable phenomenon. When we begin to understand the situation, we can collect a lot of isolated facts from which it is only clear that changes are required. but where to start? How to make minimal changes?


And the same can be said about conflicts in the team. When you see a conflict of interest, but resolving it head-on, with an administrative lever, will not be the right solution. We need to look for the root cause of the conflict and solve it.




Looking for reasons


Often, analyzing the activities of the company, we see a lot of disparate but obvious facts of the type:



Could these facts be a key problem that. need to decide? - May or may not be. Until we try to tie them into a tree of cause and effect relationships.




')

The diagram is called the “current reality tree” and it should be read as: “IF we do not have time with terms THEN the customer is not satisfied”.

You can stop at this and say “Hurray! I found the problem and go to the developer. ”And even if you find the ideal developers, the problems will not be solved.

Because most likely this is not the true cause of the problem. And you need to dig further.

This is what the fifth step 5 of TOC “do not succumb to inertia” says. Of course, the tree is not complete, and the fact that “a lot of errors in the code” can also be a consequence of some other more systemic problem. In order to reveal this you just need to ask the question “Why?” Why do we have a lot of errors in the code?


And when answering this group of questions, it can be revealed that:



Wow, it turns out that the problem lies not at all on the development side, but is buried deeper, and lies also in the field of preparation for concluding a contract.


But it is IMPORTANT that these problems were not on the surface. And building a full picture






You can find the key problem with which you need to apply business process changes. This example is short, but it shows that not everything that lies on the surface is really a key problem. And when analyzing the state, 50 more different facts affecting the system can be revealed, and embedding them all into a tree of cause-and-effect relationships and identifying what is the consequence and what the reason can be found is the very limitation of the system that needs to be fixed first.



Solve problems


In the analysis of this example, we found that the key problem is the lack of accounting for the results of retrospectives, for which it would be nice to have some kind of project artifacts such as project documentation. And the results of the retrospectives also make sense in the form of a document about the lessons learned.

And here we can come to a conflict.

In order to do a project quickly, we must save time, and therefore do not have to write documents (Communications are more important than documentation). At the same time, we need to think about project support and development prospects , so we need to write documentation.

And here we come to another TOC tool, the “Key Conflict Chart” or “thundercloud”, which is a small diagram showing the non-conflicting conditions for achieving the goal, but conflicting methods of providing conditions.




In order to solve this “cloud” you can apply several different methods.



Or apply the same logical approach, and reveal false premises leading to the choice of methods to ensure our conditions. Such a method is chosen not only to ensure the condition but on the basis of some other influencing factors. Sometimes it happens that the method is chosen correctly, but the error may lie in the conditions that lead to these methods and then you have to question the conditions themselves that lead to conflict. For this, too, you need to explore the prerequisites.


To identify the prerequisites, the current reality tree considered earlier is used, which we complete by using the questions “Why?”, “Why?” And, accordingly, the answers and these “BECAUSE ...” and transferring from the abstract plane “save time” into concrete “save 20 hours "asking questions" How much to hang in grams? "," And what is it expressed? "to get measurable facts. (yes yes SMART criteria)


  1. Save time - why? How much time will save? Are there any other ways to save time?
  2. Long support - How long? How often do teams change? What is the predicted pace of development? Are there any other ways to enforce the condition?
  3. Do not write documentation - What will this lead to? What will be undesirable phenomena? What risks will increase? What will be the positive effect? What are the losses?
  4. Write Documentation - How Much Does It Cost? How much money will it bring? What is needed for this? What kind of documentation to write? How to determine what we write and do not write?

Working through each of these branches, one can identify some false prerequisites underlying the conditions or the method chosen, which can be false or come from more other root causes.

Check the effects


If, as a result of the analysis, it is revealed that our conditions are indeed correct, but a thundercloud does not dare, then you can check the effects of each method on the system as a whole by analyzing the desired effects (LC) and undesirable phenomena (NIL). This can be checked by building a tree of future reality :

For example:

If we write documentation then




If we do NOT write documentation then





Assessment at the tree level of the future reality of the consequences of our actions gives an understanding of the cost of implementing a particular method and all the undesirable phenomena that may arise during the implementation process.
The chosen solution is called a “breakthrough” and it immediately affects the whole cloud. The solution may lie outside the cloud and can be found through the methods of brainstorming TRIZ and the “six hats of thinking”.

The effects on the system in the process of modulating the tree are called “injections”.

But the resulting solution will need to be checked on a logical tree with an analysis of the consequences of our impact on the system as a whole. And the decision on the chosen option can be checked for desirable effects and undesirable phenomena. And the number of adverse events can play a significant role in choosing a solution to a breakthrough.


These techniques can also be used in assessing a situation or during negotiations. However, when modeling a scenario, instead of solving a breakthrough and injections, you can use your actions with an opponent response that can be positive (the desired effect) and negative (an undesirable phenomenon).

What to read on the topic


Source: https://habr.com/ru/post/291310/

More articles:


All Articles