We have worked with the development departments of various manufacturing companies, analyzing their organizational problems together and helping them solve their issues.
We often utilize the TOC (Theory of Constraints) thought process as a framework for problem solving.
In this article, we would like to share with you the process of deciphering the root cause of a problem and linking it to a solution by structuring and capturing the problem using the TOC (Theory of Constraints) framework, focusing on organizational problems common to many product development organizations in the manufacturing industry.
This is a series of five articles.
Please enjoy it until the end.
Contents of series of article
Part 1: Viewing Organizational Problems as Bad Symptoms (UDEs)
Solving Problems with Strategic Thinking, Taking Advantage of TOC
The reason why we utilize TOC (Theory of Constraints) in our company is because I myself am in love with TOC. What I like about it are the following five points.
- The idea of finding bottlenecks and attacking them to get results in a short period of time
- It strengthens logical thinking skills and eliminates organizational assumptions
- A holistic optimization approach to increase overall throughput
- A mindset that anticipates and takes steps to address obstacles and side effects of solutions
- It works well with strategic thinking and is a strong analytical tool for strategic planning
While 1-4 will be understood by those who have studied TOC (Theory of Constraints), I believe 5 is an advantage of TOC that we have been able to realize in our work with our clients.
We believe that strategy is a ploy to close the gap between goals and the current situation by setting “high goals” to win the competition and by carefully analyzing the company’s current situation, the competition, and, in business, the customers’ trends.
Therefore, we take a strategic approach to our clients’ organizational reforms by adding the traditional methods of strategy formulation and the TOC (Theory of Constraints) approach to organizational reforms of development organizations, and furthermore, by using our company’s development methods such as lean product development as a best practice and as a hint to come up with ideas for solutions.
The figure below is a conceptual diagram of our company’s organizational reforms.
In this series of articles, we will focus on analyzing organizational problems.
In order to develop the right strategy, it is necessary to conduct a correct analysis that is objective and free from assumptions.
I would also be happy if you could use this article as a hint for solving organizational problems by focusing on the idea of finding the root problem, or bottleneck, and concentrating your efforts there, rather than being blinded by the phenomena that are occurring.
After reading the series, if you are interested in the overall picture of problem solving, I hope you will also refer to the following articles.
We will now proceed with structuring the problem, Part 1.
A great book that introduces the basics of TOC (Theory of Constraints)
Viewing Organizational Problems as Bad Symptoms (UDEs)
First, let me discuss the types of companies that we have worked with and that are the subject of this analysis.
In terms of industry, the target companies for this analysis are manufacturers of measuring instruments, precision instruments, home appliances, metal materials, and medical equipment.
What they all have in common is that they have a certain main product line and earn the majority of their revenue from their main products, but they cannot rely exclusively on their main products and are looking to create new products or new businesses while continuing with their main products.
As the basis of the TOC framework, the first step is to clarify “what needs to be changed,” i.e., what the current state is and what needs to be changed.
The first step in this process is to identify the actual bad symptoms or bad conditions that are occurring in the organization.
We will capture the phenomena that are occurring as the respective thoughts of people in the field, middle managers, and people at the management level.
At this stage, there may be gaps in perception between the different levels of the hierarchy, but the important thing is to understand the phenomena on a “factual” basis.
In TOC, the actual bad symptoms are called Undesirable Effects (UDEs).
As a rule, UDEs are expressed as clear sentences, i.e., who does or has done XX or XX.
The reason for using sentences is to eliminate ambiguity and personal assumptions as much as possible.
However, even after the text is written, there is still a possibility that ambiguity may remain and assumptions may be made.
There is a method for self-checking, but I will not go into details here.
The following is a list of common UDEs that have been identified by several manufacturing companies in our study of UDEs.
- A lot of time is spent on miscellaneous tasks
- Unclear who is responsible
- A lot of rework is occurring
- Failure is denounced
- Similar failures are repeated
- Fewer engineers understand the product as a whole
- Young employee turnover is increasing
- New concept products have not been created for a long time
- Veteran’s knowledge and know-how do not remain in the company
- Not knowing what others are doing or what is going on
- Schedule delays have become the norm
- Lack of independent prototyping and proposal of ideas
- Young people do not realize the growth of their technical skills
- Know-how is not documented
- Failure to understand the real issues and potential needs of customers
What do you think? Do you see any similarities with your organization?
First, we will consider the 15 UDEs listed above.
Now, I believe that each of the above UDEs can be called an organizational problem.
Usually, many organizations and companies try to take measures to deal with each of these problems (UDEs).
If you look at the activity plans or strategy documents of many companies, you will see that they make a kind of list of issues, list the above-mentioned problems, and write what they should do for each of them as proposed countermeasures or measures.
In my experience, I have seen many such documents, but I have never seen a single case where individual measures for these 10 or more problems were implemented and 10 problems were solved in a certain period of time.
Yes, it has been a picture-perfect situation.
The TOC approach is that these 15 UDEs (problems) are actually a chain of one or two, or a small number of core problems.
In other words, there is a small number (ideally one) of root causes from which many (sometimes all) of the problems arise.
As in the example shown in the figure above, we believe that taking individual measures for each symptom, such as back pain, chills, fever, etc., is a coping strategy that is unlikely to lead to a true solution. The TOC approach is to synthesize each symptom, identify the true cause as pneumonia, and then concentrate measures there to suppress all symptoms as a result.
The next step is to find the root cause from the multiple UDEs identified, and at this point, a conflict resolution diagram (cloud) is used.
The cloud (conflict resolution diagram) is a tool to express the background of each problem (UDE) in a simple and precise manner, while eliminating assumptions.
TOC believes that all organizational problems are caused by human behavior.
We also believe that problems in an organization are not caused by someone who is a culprit (or a bad person), but rather that there is a top management policy that makes organizational activities possible, that there are multiple intermediate objectives under the top management policy, in other words, multiple evaluation criteria to evaluate the achievement of the top management policy, and that actions based on these multiple evaluation criteria become completely incompatible, and problems occur when people are in a dilemma where only one of these actions can be taken.
As shown in the figure above, there are three stages: policy, evaluation criteria, and action.
The dilemma is simply represented by a cloud (meaning “cloud”), which leads to the solution of the problem.
In the next article, we will explain how to create this conflict resolution diagram (cloud) and take one UDE from the 15 UDEs as an example to actually create a cloud.