More than a few organizations I know are starting to understand the importance of establishing a culture of problem solving. Hopefully they are shifting from a tools implementation model to one which emphasizes how people respond to the daily friction generators.
In an email on the topic to a friend today, I cited four things that I think need to be there before this can be achieved. Upon reflection, I’d like to expand upon and share them. I think I can say that a lot of the failures I have seen can be traced back to only emphasizing one or two of them.
The organization must reset its definition of “a problem.”
I started to get at this mindset back in January with the post “Chatter as Signal.”
In “traditional” organizations something is labeled “a problem” when it causes enough disruption (or annoys the right (wrong?) person). Anything that does not cross that threshold is tolerated. The “problem” with this approach is that many small issues are ignored and worked around. Their effects, though, tend to clump and cluster into larger cumulative symptoms. When those symptoms reach the threshold of pain, someone starts wanting some kind of action, but by now it is too late for simple solutions.
Another face of the same thinking is the “big problem” syndrome. “We can’t fix everything.” “We have to prioritize on the big hitters.” True enough, but it is not necessary to fix everything at once. That’s the point. Sure, prioritize the technically tough problems. But, at the same time, put the systems into place that allow everyone to work on the little ones, every day.
When the “big problem” statements are used as a “can’t do it” or “we can never be perfect” excuse, the organization’s underlying mindset has dropped into the ”
The “Chatter as Signal” attitude really means instead of putting together plans and processes and then tossing them over a wall for blind execution, the problem solving organization systematically and continuously checks “reality” (what really happens) against their “theory” (the plan, what they expect to happen). Whenever there is a difference between the two, they look at that as “a problem.”
Maybe the term “problem” is unfortunate.
A lot is made out there about being truly forward-looking organizations seeing “mistakes” as opportunities to learn. A “mistake” is nothing other than an instance of “We did this thinking some specific thing would happen, but something unexpected happened instead.” Or “We thought we could do it this way, but it turns out we couldn’t.” In different words, those events are “the outcome wasn’t what we planned” and “we couldn’t execute the process as planned.” In other words, “problems.”
In summary, specify what you intend to accomplish, how and when you intend to do it.
Any departure, necessary or inadvertent, from this specification is a problem.
The organization must have a process for immediately detecting and responding to problems.
It doesn’t do much good to define a problem unless you intend to respond. And you can’t stand and watch every second for problems to occur. That is the whole point of jidoka. When Sakichi Toyoda developed his loom, the prevailing common thinking was “sometimes the threads break.” “When that happens, some material is ruined.” “That is reality.” “Perfection is impossible.” Chatter is noise.
But Sakichi changed the dynamic when he designed a loom that detected a broken thread and shut itself down before any bad material was woven. Now I am fairly certain that, even today, threads break on weaving equipment. (And the same technology developed by Sakichi is used to detect it.) So, as a jidoka, this is a case of detecting a small problem and containing it immediately so it can be corrected.
Consider this: If the organization really understands jidoka then any problem that goes undetected is a problem. Thus, it isn’t necessary to fix it all at once. Rather, when problems occur, get back to where they occured. Look at the actual situation. What was the very first detectable departure from the intended process? It is quite likely that it is a small thing, and also likely it happens all the time. But this time it didn’t get caught and corrected.
Then ask: Can you prevent this departure from process?
If you can’t, can it be immediately and automatically corrected?
If not, can the process be stopped?
But detecting the problem is only the first step. The response is even more important. When a Team Member (or a machine) detects a problem and calls for help, a real live human needs to show up and show genuine interest. The immediate issue is simple: Fix the problem. Restore a safe operation that produces defect-free output. That may take a temporary countermeasure involving some improvisation, and may compromise speed and cost a little, but safety and quality are never compromised for anything… right?
The next step is to start the process of actually solving the problem. At a minimum, it needs to be written down and put into the “We’ll work on that” management queue (See the next item) to get solved. Note that “fixing it” and “solving it” are two completely separate things.
The organization must have a process for managing problem solving.
When a problem occurs, the first response is to detect it, then to fix (or contain) it. That is jidoka. But at some point, someone has to investigate why it happened, get to the root cause, and establish a robust countermeasure.
Again, I have talked around this in a couple of previous posts:
Systematic Problem Solving
A Systematic Approach to Part Shortages
However it is done, however, the organizations that do it well:
- Have a public written record of what problems are on the radar. The most common approach is a board of some kind in the area where the daily review takes place.
- Did I just say “Daily Review?” There is a process to check the status of ongoing problem solving activity every day. Problems being worked on do not get a chance to fall off the radar.
- They manage their talent. The organization I talked about in the “Part Shortages” story had a lot of problems, not just in part shortages, but technical issues as well. Initially they had been assigning each problem to someone as soon as it came up. That quickly became unworkable because, in spite of their tremendous talent, the key players really couldn’t focus on more than one or two things at a time. It was demoralizing for them to get hammered at the meetings for “doing nothing” on five problems because they had been working on the other two. The countermeasure was a prioritized pull system. Each new problem went into a queue. As a problem solver became available (because s/he was done with one), the next problem on the list was assigned. The prioritization system was simple: The manufacturing manager could re-sequence the queue at any time.Thus, the problem at the top of the list — the next one to be assigned — was always the next most important. But it was another important rule that made this work. No one could be pulled off a problem s/he was already working on in favor of a “hot” problem. The only exceptions were a safety issue or a defect that had escaped the factory and had been reported by a customer. However you manage it, keep these things in mind:
- Don’t arbitrarily multi-task your talent. People can’t multi-task. This is actually overloading. The other word for it is muri.
- Don’t jerk them from one thing to the next without allowing them completion.
- They solve the problem at the lowest level of the organization capable of solving it. The corollary here is largely covered below, but it bears mentioning here: If the level that should be solving it isn’t capable then they work THAT problem – developing the skill – rather than ignoring the issue or overloading someone who is never going to have the time to work on it. This is probably the most important lesson in this piece.
They deliberately and systematically develop their problem solving skills at all levels.
It is easy to fall into the trap of assuming that someone with a technical degree is a skilled problem solver and critical thinker. Experience suggests otherwise. And even if there are a couple of people who just have the innate talent, there are not enough of them to go around. There are lots of approaches out there. In reality, all of the effective ones are anchored in the same thinking, they just use different tools and lingo to frame that thinking. My best advice is pick one, teach everyone to use it, then insist that they follow the process exactly. Only by doing that will you actually learn if the process itself has weakness or shortcomings.
Along with this is don’t confuse the tools with the process itself. THIS IS CRITICAL: Anything you draw on paper (or create in a computer) is a tool. The seven problem solving tools are not a process. A statistical control chart is not a process. An A3 is not a process. A cloud diagram is not a process. All of these are tools. The framework in which they are used is structured thinking, and that is a process.
This is important because the process itself is straight forward and simple. It can be taught to anyone. Teaching them the tools, however, teaches them nothing at all about how to solve problems. So many “problem solving courses” spend a week teaching people how to build Pareto charts, histograms, tree diagrams, run charts, even build control charts, and yet teach nothing at all about how to solve problems. Most problems can be solved by unsophisticated troubleshooting techniques that systematically eliminate possible causes. Some can’t, but most can.
This got long, but I guess I had a lot to say on the topic. In the background, I am planning on putting together some basic material on “the process of problem solving” and making it available. Hopefully that will help.
As always, comments are encouraged and appreciated. It tells me that someone actually reads this stuff.
Mark, I don’t think you need to worry that people do not read your “stuff”. I find the material on your blog very helpful and each day I learn something from you, whether here or on the lean.org forum.
I’d like to contribute by drawing a parrallel to the lean implementation.In the same way, the lean tools cannot be used successfully without following the lean thinking process and this is where successful companies do a better job.
Regarding the problem solving process, I still see a lot of companies where the task belongs to the engineering department and these people get really crowded with tasks and jobs half finished.
You are right in all your statements. We have to get rid of the silo perception and of the departmental walls and start empowering our people to become problem solvers after educating them well in the thinking process and in the tools of choice.
Cross functional teams become powerful assets of a company, where the engineer/technical specialist draws on the experience of the front line worker or of the maintenance technician, etc. Thus, the problem solving process is streamlined and the decision taking and the implementation steps are accelerated.
At the same time, we’ll need to reduce the approval time, the purchasing steps, as they all lead to extensive delays and “rework” loops. There is still the perception that not all the problems are worth solving, based on the ROI (the subject of another topic).
Very good article. My company has no problem solving system. And no problem solving culture.
We do have a problem solving team. But it’s designed like the fire department. Simply put, when there’s a fire (big problem) we put it out.
Jim –
Just a question – when your “fire department” puts out the fire, does the “fire investigator” sift through and look for how the “fire” started in the first place? That is what fire departments do…
Continuing the analogy, a circuit breaker is a jidoka mechanism. By detecting an out-of-spec condition (too much current), it shuts down the operation before it can cause a bigger problem – a fire. In order to reset it, you have to find the cause of the short and fix it. That is an example of pushing the “problem solving” upstream and handling the issue while it is still small. Of course there is no way to do that manually, you can’t go check every circuit every day. So we devise technology to do it for us, and let us know when there is a problem. That is jidoka.
Mark:
Yes we do have a “Fire Investigator”. We do find out how the problems start and we do followup and correct the source of the problem.
And we do have a system to identify an “out of spec” condition. We use a final inspection cell.
However, my comment meant to say we don’t have a “culture” throughout the plant nor an automatic system to detect problems and solve them. We are far away from having jidoka anywhere but at the very end of our many manufacturing and assembly processes.
Here’s an interesting part of our system. Almost every time we find an error in our product, we add an inspection step to insure it won’t happen again. This drives me (The Lean Manager) crazy. We are forced by our customer to come up with corrective actions. The easiest solution is to add an inspection step in the middle of the building process. I’m more inclined to use the 5 why’s and discover the true source of the error. However, by doing that I’m afraid we may find that low paid, untrained workers would usually be the true source of the error.
Thank you for your thoughts.
About your point “They solve the problem at the lowest level of the organization capable of solving it…” are you recommending solving a problem above your skill level, by taking a two step aproach 1) Learn 2)Then solve??? I can see that this will increase knowledge/skill.
Also sometimes I read books and I’m not sure if what I am thinking comes from the book or if it’s a new idea… But isn’t it a type or waste to have an “uncapable machine or person” take on a task? Which raises the responsibility training a high level of importance.
Jim –
It is true that most defects are the result of human error – either a “slip” where some step was omitted, or a “mistake” where the wrong thing was done.
My question is: What are the consequences of finding out that people make errors?
Steve –
I was a little ambiguous on the organizational level because I didn’t want to get into the negative consequences of silo and
ambiguousmatrix organizational structures.In general, however, if the level of organization that SHOULD be able to solve the problem CAN’T solve the problem, then one of two things is true:
– The problem is harder than it looked. Countermeasure: Escalate. The escalation response is technical assistance from the higher level that now owns the problem.
– The people aren’t capable of solving a problem they should. Countermeasure: Escalate. The response is to guide and coach the people through the process so they learn how to do it themselves next time.
Note that any time a problem can’t be solved, the initial response is always the same: Escalate. This could be a literal andon call. What should never happen is that a problem goes unaddressed because “we don’t know what to do.”
There certainly are problems which are unsolvable, in cases where we have over reached our technology, for example. But those are rare, and when they occur, they should be well documented, understood and their effects contained so the downstream customers are not affected.
Mark,
It was your definition of… “Muri: “Overburden” or “Unreasonableness” – in short, asking someone to do something which he should not have to do, or which cannot be done.”
So it wasn’t an idea from a book I was reading, but from your page on Common Searches. In my mind I extended “Unreasonableness” to the many tasks I’ve been asked to do. I am a mountain of Muri. The marine saying… “We’ve done so much, with so little, for so long, THAT NOW we can do anything with nothing” is such nonsense… but it was fun to say. Thanks for the idea of escalating. Even the word “escalating” had a negative connotation with me. I thought that “Escalating” meant going crazy.
I’m starting to be a fan of the proper application of emotion/feeling instead of just a stoic-robotic response. Words like “curiosity” and “determined” do have some feelings attached to them. Now I’m seeing that “Urgency” is important. And that to “Create Urgency/Sound the Alarm” It may be necessary to do it by attaching the appropriate emotions, in a controlled fashion, to the cold hard facts and data. After all, we are humans.
Muri (overburden) is just another “problem.”
The starting hypothesis (or “plan”) is “This person should be able to do this.”
Then try (“do”).
Check: “Can s/he do it?”
If no, then we have learned something – the original assumption was wrong. This is good news. (This is the definition of “chatter” in my posts referring to Steve Spear).
It is good news because now we know the next point of weakness in the system to work on.
Escalation is simply the act of notifying the chain-of-support that there is a “problem.” On a good line, it means pulling an andon cord or turning on some kind of signal.
Many times people are overwhelmed thinking about trying to respond to all of the problems. That is where some rational thought comes into play. Respond to them in the sense of making sure safety and quality are not compromised, but then manage them. Some problems never get addressed. Fact of life. They end up in the “too hard” box. The good news is that the organization usually knows how to live with them. It isn’t about solving every problem that comes up, but rather, about systematically responding and solving as many as possible every day.
That was the beauty of the shuffling priority queue I mentioned. There was no attempt at FIFO, rather it was solving as MANY problems as possible. Sometimes the really hard ones just never got addressed, just contained.
To do this (actually solve problems), though, means carving out dedicated time to do it. Where most organizations fall down is the point where “working on solving problems” is only “when we have time.” Rather than being a prime activity, it is supposed to fit between the cracks. That doesn’t work.
Mark,
Although this article was wriiten 4+ years ago I just found it. Better late than never, eh?
One of my issues I have as a CI coordinator is the buy-in from the shop floor. Metrics are great but if the people providing the feedback aren’t engaged then it turns out to be a fruitless undertaking. Before I implement any Lean concepts or metrics on the floor I explain and train our staff on the ever important “why”. Once they see the reasoning behind needed involvement and how it will positively affect them, then the buy-in is much easier.
Credibility from management is paramount. The old adage is “talk is cheap”. If management does not follow through with their commitment then it will not happen where it has to happen – on the shop floor. Machinist, assemblers, shipping personnel, etc. are bottom line people. No BS, just results. When we partake in a Kaizen and we have a laundry list of things that have to be done, then management has to deliver in the time frame agreed upon.
The last issue I want to bring up is: time. With production and on time delivery schedules we all get caught up in the day-to-day duties of getting product out the door. If a company has, say 1000 employees, it is much easier to designate a group to focus on Continuous Improvement projects such as Kaizen’s. But when a company has 50 employees then time is the biggest constraint. CI projects become ‘blitzes’, done on the fly, piecemealed when they can be fit in. A simple but painful solution is “make the time”. Do what has to be done because the resulting changes will worth the investment.
Jay –
Thanks for the comment. You made me go back and actually read the original post.
Going back to Out of the Crisis by Deming, management commitment is not enough.
Every organization I have seen that sustains a continuous improvement culture has the burden of actually improving things on a day-to-day basis being carried by line leaders – especially the first couple of levels closest to the process.
The MOST successful ones I have seen ran very few, if any, dedicated “blitz” type events, nor did they run “CI Projects.” Rather, improvement was part of the daily work, just like production is daily work, just like updating the spreadsheets is part of daily work.
Mark,
This was insightful. I’m particularly interested in more insights into the topic of problem spotting. Particularly how do organizations put adequate time (at all levels) into defining problem before jumping into solve mode, and what you have seen companies do to combat this to get results from developing this core capability.
Kirk –
Thanks for commenting –
This post was written back in 2008, before Mike Rother published Toyota Kata.
See this post for a starting point, but there are a lot of posts on the blog with Toyota Kata as at least a tangential topic.
https://theleanthinker.com/2017/12/21/mike-rother-the-toyota-kata-practice-guide/
That is probably the best framework out there for developing problem solving skills.
If you get intrigued, come to Austin, TX in February and meet a few hundred “Kata Geeks” *smile*