ARTICLE – You need to have a solid and complete process in place if you want your problems to be actually solved, and it is more than just developing an A3 or drawing an Ishikawa.

Words: Malgorzata Jakubik and Robert Kagan, Lean Enterprise Institute Polska

As no true lean person should walk by waste and ignore a chance for improvement, we felt the need to put together our reflections on things big and small that, while working with our customers, we have found to be common “speed bumps” or even show stoppers in a lean implementation. Whether systemic or tool-related, these obstacles have one thing in common: they tell our “war stories,” which we want to share with those on the road to lean, hoping they will warn them against frequent hazards others have struggled with.

EVERYBODY IS SOLVING PROBLEMS, BUT ONLY A FEW SUCCEED

-  A PROBLEM SOLVING PROCESS IS A LOT MORE THAN A COUPLE OF TOOLS AND A PROCEDURE -

One of our long-time customers likes to say (and repeat over and over again) that there is only one thing he can always find enough of in his plant – problems! He is not complaining, just stating a fact and voicing the conviction shared by many of his fellow plant managers. Their busy lives are all about learning to swim in an ocean of problems. Do we really have to feel tossed around, at a mercy of this ocean? Can we not manage our problems better and learn to be in control of them, acting proactively instead of just reacting to what is happening with our processes and products?

No doubt about it in the lean world – structured problem solving is important. The less we fire-fight, the more we can focus on root cause analysis. The more people at all levels we involve in the process, the better off we are.

The key ingredients of a solid problem solving process seem obvious – it has to be transparent, easy to understand, flexible and effective. It has to be. But is it always? The not-so-good processes described below suggest it is not. Let’s consider them for a moment and then talk about the core of the issue: how complete the problem solving process is, or isn’t.

Case 1 – “We have elements of the process in place, but do we have an actual process?”

The plant gets a new Production Manager, who is all charged up to prove himself and reach the ambitious targets he has been given – productivity needs to go up by 20%, lead-time down by 30%. He soon finds out that he won’t be able to do anything without eliminating the fire-fighting attitude that his people have towards problem solving. He actually cannot understand why they are not solving problems well. All that he would expect from the process seems to be in place: 80% of the people have been trained in it; they know Ishikawa; they know 5 whys; they have even been introduced to A3 reporting. “Get to work!” he orders, outlining his expectations very clearly.

And they did – problem-solving meetings were organized all over the plant, problem lists put up at every corner. That pleased the manager for a while. He pushed for more A3s. He pushed for better root causes analysis. He had a feeling he was driving the organization in the right direction.

Surprisingly, however, when he checked if the actions were bringing results, he realized that nothing had really changed. There was so much activity, but why was it not effective? What he found out was that problems were picked up and worked on, but the number of problems solved was not going up.  

What was going on? When pushed for action people rushed to collect problems, and that worked well. Then, they started problem solving on as many issues as they could find, but that did not go well. No organization has enough resources to deal with all of its problems - priorities must be defined. Additionally, people had tools, but did they know which one worked best with a specific problem? A3 is a great tool, but definitely not for every problem you come across. If you are expected to write a full-blown A3 report every time an issue is raised, you’d rather keep quiet or work around the problem. And people did.

Disappointed by the lack of progress, the Production Manager decided to stop and re-think his approach. He expected a lot from his people but how were they supposed to know which problems to start working on? Were they prepared to monitor the effectiveness of countermeasures? Did they know what problem-solving tool would work best for any given problem? “Well, we have elements of the process in place, but do not have a complete process! This is what we need to fix,” he concluded.

Case 2 – “No overtime, no extra people, no problems.”

Imagine a plant belonging to a large international corporation. Nothing happens by accident here: the problem solving process has been centrally defined and passed a test for completeness:

• Sources of problem identification have been defined;
• Problem selection criteria are established;
• People know who should do what;
• A number of suitable problem solving tools were available for people to use;
• Problems are visually tracked, with countermeasures checked for effectiveness and lessons spread across the organization.

Perfect, isn’t it? So perfect that the number of problems solved per day was going down at a steady rate. It looked good on paper, yet the overall results did not seem to back that trend.

Talking to employees quickly revealed underlying issues: “If I raise a problem, I will be the one tasked with solving it and I will not be given enough time to solve it. Why would I even want to talk about it? We were told clearly: no overtime, no extra people. And who has the time to train people in the use of the tools? We have to rely on those that were already trained last year. Our manager says it should be enough. Well, it isn’t. I won’t raise any issues, however - I will just get around them.”

Even the escalation of problems seemed to have stopped at manager level. The directors were just getting reports of the successful examples of problem solving. Good thing they were not getting news of how many problems returned after the initial solution, it would not have been a nice picture. Countermeasures were not being tracked for effectiveness long enough and somehow the scheduled audits of the problem solving process were conveniently forgotten and never happened.

This time, the process was there, but what about the discipline and managerial commitment that are needed to run it well?

Two cases, two stories of seemingly good approaches that did not work.

So, what should we focus on if we want to develop a working problem solving process? Here comes our two-fold advice:

1. Make your problem solving process complete.

Define how it should work, give people a structure to help them make right decisions and make them quickly. It does take time and effort to define it well, but once there, it will pay you off quickly. To help you, here are the six elements of the complete system you need to worry about:

2. Make sure you plan resources for the process to work well:

• involve all levels of management in the process, every day and visibly;
• plan time and resources for problem solving, and don’t pretend that it will just get done “in the meantime;”
• audit the process, see if it solves problems at a root cause, so they do not return;
• learn from your problem solving – communicate the lessons, reflect and keep improving.

Are you among the good ones who get problems really solved? If that is the case – congratulations and keep up the good work. But if you struggle, maybe it is time to stop and think whether or not you have a complete process in place, and consider our advice.

^{This article is also available in Polish here}

_{THE AUTHORS}