Application of Theory of Constraints for the formulation of the process

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

And the same can be said about conflicts in the team. When you see a conflict of interest, but resolving it head on, administrative leverage will not be the right way out. It is necessary to search for the root cause of the conflict and solve it.

Looking for reasons

Often, analyzing the activities of the company, we see many disparate but obvious facts such as:

• customer dissatisfied
  
• a lot of errors in the code
  
• many improvements upon delivery
  
• not in time with the deadlines
  
• develop for a long time
  

Could these facts be the key issue that. need to decide? - They may or may not be. Until we try to link them into a tree of causal relationships.

The diagram is called the "tree of current reality" and should be read as: "IF we do not have time in time, then the customer is dissatisfied."

You can stop there and say “Hurray! I found a problem and go fucking a 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 the CBT says “do not succumb to inertia”. Of course, the tree is not complete, and the fact “a lot of errors in the code” can also be a consequence of some other more systemic problem. In order to identify 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, you can identify that:

• A lot of bugs in the code BECAUSE there is no testing
• No testing BECAUSE NOT enough time
• Not enough time BECAUSE the contract is concluded late.
• There is not enough time BECAUSE the size of the project is incorrectly estimated before the conclusion of the contract.
• The size of the project is incorrectly estimated BECAUSE there are no ready-made metrics.
• There are no ready-made metrics BECAUSE project analysis is not carried out.

Wow, it turns out that the problem does not lie at all with the development side, but is buried deeper, and lies still in the area of ​​preparation for the conclusion of the contract.

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

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

We solve problems

In analyzing 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. Yes, and the results of the retrospective also make sense in the form of a document on the lessons learned.

And here we can come to a conflict.

In order to make a project quickly, we must save time, and accordingly we should not write documents (Communication is more important than documentation). At the same time, we must think about supporting the project and development prospects , therefore we must write documentation.

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

In order to solve this "cloud" you can apply several different methods

• brainstorm.
  
• theory of solving inventive problems. (TRIZ)
• six hats thinking

Or apply the same logical approach, and identify false premises leading to the choice of methods to ensure our conditions. Takak method is chosen not only to ensure the conditions but on the basis of some other influential 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 the conditions themselves leading to conflict must be called into question. To do this, you also need to explore the premises.

To identify the prerequisites, the previously considered tree of current reality is used , which we are completing using the questions “Why?” "What for?" and correspondingly the answers “BECAUSE ...” and translating from the abstract plane “save time” to a specific “save 20 hours” asking the questions “How much to hang in grams?”, “And what is this expressed in?” to get measurable facts. (yes, SMART criteria)

1. Saving Time - Why? How much time will save? Are there other ways to save time?
2. Long Support - How Long? How often do teams change? What is the forecast for the pace of development? Are there any other ways to ensure the condition?
3. Do not write documentation - Where will this lead? What will be the undesirable phenomena? What risks will increase? What will be the positive effect? What will be 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 do you need to write? How to determine what we are writing and not writing?
   

By working through each of these branches, you can identify some false prerequisites underlying the condition or the chosen method, which may be false or come from more than other root causes.

Check the consequences

If the analysis revealed that our conditions are indeed correct, but the thundercloud is not resolved, then you can check the effects of each method on the system as a whole by analyzing the desired effects (ЖE) and undesirable effects (НЖ). This can be verified by building a tree of future reality :

For instance:

If we write documentation then

• ZhE. We will have more information on future decision making, which will increase our stability in the execution of work.
  
• SUM. But at the same time it will be necessary to spend time on documentation
  
  • But we can integrate documentation into the design process.
    
    • ZhE. THEN documents will be born as a by-product and
      
    • ZhE. Design decisions will be better thought out.
      
    
    
  
  
• SUM. any document becomes obsolete at the time of writing
  
  • A description at the level of properties, characteristics, and behavior without granularity will reduce obsolescence
    
    • ZhE. Most of the documents will be relevant for a long time.
      
    
    
  
  

If we will NOT write documentation then

• ZhE. we can make the product faster
  
• SUM. when changing the developer all the information will go away with him
  
• SUM. The cost of replacing an employee will increase
  
• SUM. unpredictable financial risks appear.
  

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

The impact on the system in the process of modulating the tree is called "injection".

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 desired effects and adverse events. And the number of adverse events can play a significant role in choosing a breakthrough solution.

These techniques can also be used in assessing a situation or in negotiations. However, when simulating a scenario, instead of solving a breakthrough and injection, you can use your actions with the opponent’s response, which can be positive (desired effect) and negative (undesirable phenomenon).

What to read on the topic

• Goal. The process of continuous improvement. Eliya M. Goldratt, Jeff Cox
• Goldratt's Theory of Constraints. A systematic approach to continuous improvement. William Dettmer