“Sustaining the gains” is a frequent topic of discussion in the continuous improvement world. Often the discussion degenerates into a rant about “management commitment.”
But in the real world, people generally don’t sabotage improvements on purpose. (Though I have seen it happen, but only once.) The mechanism is far more subtle.
Before we get into what happens after improvements are made, let’s look at a common improvement process itself.
In many companies, the primary method for making improvements is through special events or projects. These are usually planned, organized and led by a staff specialist.
Although the exact methods and words vary, the general process usually looks something like this:
- Identify an opportunity, select an area for improvement.
- Analyze the current state.
- Select an improvement team.
- Teach the team members how to apply the improvement tools.
- Facilitate the development of improvement ideas.
- Work with the team members to implement them.
- Wrap up with a report or presentation, including remaining action items for management.
A variation on this is where the team is chartered, and it is up to them to identify an opportunity. This approach was more common in the late 1980’s than it is today.
This process actually works. It is capable of making pretty dramatic changes over a short period of time, often only a few days.
So why do the results erode? Or put another way, what is the problem?
Take a look at the routine decisions that are made during normal work, especially the ones that result in some change to the process. Those decisions must be made, because people have to get something done. The question comes down to whether those decisions result in improving the new process, or eroding it somehow.
Once things are in operation, some kind of unforeseen event always happens. Guaranteed. It can be something that the improvement team didn’t think of. It can be a piece of malfunctioning equipment. Maybe there is a material shortage or a defective part is delivered. The same things happen in administrative processes, only the words are different. Incomplete information arrives.
It could even be a deliberate decision. A production rate change. A software upgrade. Making room for some other activity.
All of these things, no matter how small or inconsequential, force decisions to be made. “How do we deal with this this and get production going again?”
The person making that decision is either:
- Fully capable of applying kaizen principles, and applies them in a solution to the problem.
- Is not fully fully capable of applying kaizen principles, but knows that, and seeks assistance in finding a solution to the problem.
- Is not fully capable, may or may not know this, and does the best he can to get production back on track.
Both (1) and (2) result in making the system better, more robust and more responsive.
(3) usually results in a little bit of erosion. Variation is accommodated, things are made a bit more complex, the layout is now less than optimal, the old process does not work as designed anymore so the team member must improvise a bit. That, in turn, introduces more variation into the process, and usually drives a cascade of these little decisions.
If there is no mechanism for problem escalation (and if there was, we would likely be in (1) or (2) in the first place), then this becomes the new way, and things are steadily creeping closer to where they were before the event happened.
Given enough time (which can be amazingly brief), the process reverts back to where it was, or morphs into something else entirely – but equally wasteful.
Meanwhile the improvement specialists have moved on to the next project. Even if the local leader did ask for assistance, they might not be available, or worse, they tell him to figure it out.
Follow this with an “audit” that dings the local leader for “not supporting the changes” and wonder why he is less than enthusiastic about this kind of help.
Here is the question I want to leave hanging out there:
What was the intent of the kaizen event? (and was that intent accomplished?)
Mark:
You are so correct. I am constantly trying to figure out what things I need to remove or put in place to prevent people from going back to the old way. It’s a constant struggle.
Your so difficult to deal with Mark. 🙂 You tell me the problem and analyze it perfectly, but you do not give me any answers to the problem.
“What was the intent of the kaizen event?”
During the kaizen process I always reach a point where I say something like; OK, does everyone understand who is going to do what, when and how? Is it clear? Do you agree with what we are trying to do? At this point I get some head nodding and some blank stares. I’ll go around the room and try and get alignment from everyone. Management wants to go with the change and so they push the change as though the change is a new set of rules to work by. If I don’t get the enthusiasm I want, I present the change as an experiment. At this point in the process I always wonder if the change will work and if it works will it be maintained. Often times I feel that everyone in the room is thinking; “This won’t work because XYZ will happen and we will have to go back to the old way” Or, “This won’t work because so and so will not change the way they do their job.”
I keep thinking that the intent of the kaizen is to open up people’s thinking and get them to try a different way. The intent is usually to reduce waste. However, like you said something will come up that will try and push the system back to the old way. The company culture and all of the workers influence every other worker in the plant. When we make a change we find out how interconnected the whole company is. These are very powerful forces. These influences can be changed, but it’s hard during a kaizen event to make sure all of the possible influences that affect the “new way” get changed. And when upper management and the owners don’t change it makes it much more difficult.
Here are a couple of questions for you Mark. When we make a change, when do we stop checking to see if the change is being maintained? Should we design changes so that they are self sustaining?