If a problem solving culture is the means to continuous improvement as a way of doing business it may be helpful to “unpack” the term and consider what it implies. At first glance neither part of the term seems anything special. All companies have a culture and all companies solve problems to some degree. The question then is what, is different about this problem solving culture that many continuous improvement leaders want to have? In this column I will consider the nature of the problem solving required for Lean continuous improvement. In a later column I want to explore the “culture” side of the Lean problem solving culture equation.
Since Toyota is the model most often held up as a problem solving culture it seems logical to see what can be learned from what they do. In my last column I shared some facts about the breadth and depth of Toyota’s problem solving culture. It is an environment in which employees don’t just have ideas for improvement but take the initiative to get agreement to try them out and if they are proven effective then submit dozens of them as suggestions annually for recognition and reward. The key question for others wanting such a problem solving culture is, what does the problem solving involved look like?
First, problem solving as it is carried out in Toyota has two distinguishing features. One is the requirement that everything described or claimed in the problem solving process (the problem itself; the target condition, the direct cause, the root cause) be based on confirmed facts and not assumption and interpretation.
The burden of proof on the problem solver is emphasized through questions and expectations such as, “What’s the real problem?” “Go to the gemba and grasp the actual condition first hand.” “What is purpose?” “How do you know that?” “Keep asking Why, at least 5 times.” “How do you know you have an agreement to your plan?” All of these reinforce the expectation that the person claiming to have the solution to a problem or an effective improvement be able to demonstrate with observed facts and data and not just assumptions and opinions why he or she believes a proposed countermeasure to a problem is the right one and will work.
Is this different from most problem solving practice and if so, how? Situations observed in two companies are typical of much problem solving practice. In the first example the managers of production, maintenance, planning, materials handling, quality and safety in a machining operation were in their weekly production meeting. They were discussing being behind schedule on deliveries and how they would make up the shortfalls. Someone mentioned the impact on run time of grinding machines leaking oil. For 30 minutes the group discussed when the machines could be shut down to fix the leaks, who was to blame for the leaks and issues with the design of the equipment. Finally someone asked exactly which machines were leaking. No one knew.
The second observation was in a center processing credit applications. A team of specialists had been working for six weeks collecting and analyzing data to determine why the operators were running an average of seventy-five seconds over cycle time for initial review of the applications. In spite of their in-depth analyses and experiments the specialists were unable to find the cause of the delay. Finally a session with a group of operators to ask their ideas for fixing the problem was proposed. The group suggested giving the operators a second monitor to have the review guidelines displayed all the time. Since the guidelines had been revised the operators were finding they frequently had to get out of an application and bring the new guidelines up on their screens to confirm instructions. During six weeks of studying the operation none of the specialists had thought to ask the operators what they knew about the delays.
These two situations illustrate an all too common pattern. In many companies problem solving consists of a discussion in a conference room away from the problem. Problem solving proceeds based on partial knowledge and assumption. Seldom is there an effort to go to the site of a problem to observe what is actually happening and ask for the input of those doing the work at the site. There is a leap from problem recognition to solution without taking time to determine the real problem or its cause. This is not the kind of fact-based problem solving that Toyota demands for deciding countermeasures and prosing improvements.
There is a second key distinguishing feature of problem solving at Toyota and it has few parallels in problem solving in North American settings. It is the recognition that problem solving really begins rather than ends when implementation starts. Expressions like “Planning is essential; things never go according to plan” indicate Toyota’s perspective on implementation. A plan is a theory of both what will address the cause of a problem and what it will take to implement a countermeasure to that cause. The implementation process is a learning process to find out what actually will be required to put countermeasures in place and eliminate a problem.
In the Toyota perspective implementation or “DO” is part of the Plan-Do-Check-Act cycle but there are also many smaller PDCA cycles in the DO phase. It is recognized that a plan is no guarantee of implementation according to plan and that constant checking and grasping the situation are necessary to have things go according to plan.
Two key practices during DO in Toyota’s approach to implementation are “managing performance to plan” and checking “Plan versus Actual.” The emphasis is on picking up gaps between what was planned and what is actually happening during implementation, identifying their causes and making countermeasures to close the gaps. Another way of looking at implementation as practiced in Toyota is that you are likely to need to solve a lot of problems to actually solve a problem or make an improvement. This approach might be better described as problem resolution rather than problem solving.
These practices are in contrast to the typical approaches to implementation in North America. In North American companies many admit the approach is often more P-D than P-D-C-A. Implementation in North America seems characterized by two extremes. On one hand is what appears to be the assumption that once the solution to a problem is identified that the hard work is over and everything will fall into place because now the solution is known. This may be a reflection of the nature of problem solving as experienced in math and science classes in school and college. Students are taught if they take the data given, plug it into a formula in the right places and perform the operation correctly they will get the answer. Problem solved. The difference is textbook problems are structured problems. Most of the problems encountered in business, technical operations and human systems are unstructured. The desired outcome is not known; the data is not given; there is no formula to use, and there are often many, not just one, answers.
At the other extreme is the detailed project planning and management approach that breaks implementation down into a series of numbered tasks. The breakdown of goals and actions to identify those tasks is often done by specialists and the tasks are assigned by project managers who are removed from the work processes that will be used or changed. There are checks at phase gates or major milestones but progress is often evaluated with codes such as green, yellow and red. What is frequently missing is consideration of the nature and causes of the red and yellow gaps and whether what has actually been achieved by “green” progress is the outcome that is needed.
Fact-based problem solving, project management following the Plan-Do-Check-Act cycle and Plan-versus-Actual problem solving to drive implementation of countermeasures are key features of the Toyota Way of problem solving. So is Respect for People which includes assuming employees have the ability to think. This column has looked at the technical side of a problem solving culture based on the Toyota example. In a later column I will explore the social system side of problem solving culture.