Thoughts and Insights from the Shop Floor
Mike Rother has made some significant revisions to his Improvement Kata Handbook.
Even if you took a look earlier, get the latest and study it.
Learn to be thorough before working on speed. The speed will come naturally with competence.
Every coach in the world gives some form of this advice to her students. This is true for athletics, for music, for any skill we are trying to develop.
Yet when planning kaizen events, we tend to forgo this advice, and push the team to produce huge “results” for the Friday report-out.
Getting those results is actually pretty easy. Any facilitator with a little bit of experience with the tools can push the team to rearrange a layout, get some basic flow, and turn in some really good numbers in a few days.
But what skills has the team developed in this process?
Maybe how to see a similar opportunity and copy the layout there.
Maybe how to close out an action item list, but that is still just rote implementation.
What processes and systems have to be in place to sustain those results? What skills are needed to use those processes and systems effectively. When, during the course of these five days, did your team practice those skills, or for that matter, even learn what they need to learn?
One of the most common (and frustrating) problems for the staff lean practitioner is being asked to “measure the savings” resulting from specific improvements.
(This problem is related to, but different from, trying to measure “lean progress” or the status of implementation.)
There are two issues in play here.
First is the level of understanding in the leaders who ask for this in the first place. Frankly, it isn’t their fault. Authors, consultants, and practitioners have been “selling” the concept of “lean production” as a stand-alone thing to do for decades.
It is really easy, in the initial excitement of grasping the potential, to just try to push the tools and promise that great savings will result from simply implementing them.
The initial literature was all about describing the performance of benchmark companies (like Toyota, though there were others), describing the visible tools and saying, in effect, “if you just implement these tools, you’ll get this kind of results.
But making these changes can be expensive. The obvious costs are consulting fees, time (perceived to be) taken away from production work. Therefore, there must be a sufficient ROI to “justify” making the changes.
For the practitioner, the countermeasure is to try to shift the focus to establishing a business objective first.
This shifts the conversation from “justifying improvement” to “what problems must we solve to hit the objective?”
The financial evaluation then shifts from "justifying moving beyond the status-quo” to evaluating alternative solutions to the problem.
If you ask directly, most managers will have things in mind that they would like to do better. The challenge is to get those things framed in enough detail that some value is created for actually getting there.
The classic one-week kaizen event ends with a report-out by the team that outlines the improvements they have made, and the results they have achieved.
Actual results, though, are notorious for falling short of what was reported. Action items are left over, and things frequently peter out unless there is a huge effort to force sustainment.
Let’s look at this a little differently.
Typically what happens during the kaizen week is that a new process is designed, and some things are put into place to enable it – point of use, rearranging things for flow, etc.
The report out is describing expected results, and how the process must operate to deliver them.
In other words, a very common outcome of a kaizen event is a pretty well thought out target condition. This is how we want the process to operate, this is the result we are going to strive to achieve. It is all future tense.
What happens next will make or break things.
The next question that should be asked is “Great! When are you going to try it, and what do you expect to learn?” If the report-out does not directly address this question, then you can expect the typical result – steady erosion.
In fact, the process of seeing and addressing those problems must be embedded into the daily management process itself.
The report-out is the beginning of kaizen, not the end. The next phase is not “follow-up.” It is a natural continuation, if less intense, of the kaizen process. The report-out is describing an engineering prototype. Now it is time to test it and discover what we didn’t know during the design process.
What is the role of your lean facilitator?
This question comes up now and again, was recently posed on the LEI forums by someone looking for help with a job description.
I extrapolated from his question that he was looking to the job description as a line of defense against dilution of the facilitator’s focus and effort by projects that might not be going in the appropriate direction.
In effect, this is putting the lean facilitator in the role of a weakened zampolit with the role of educating the “correct view” and challenging decisions that run counter to it. Except that more often he has to sell the “correct view” rather than impose it.
The fact that the question is being asked at all indicates that the organization has not really thought through what their operational vision is. How will the company work, what are the responsibilities and roles of the leaders?
What are the leaders’ job descriptions in this new world?
Those job descriptions become a target condition for each of them.
What is the gap?
If there are gaps in skills and knowledge, then we need countermeasures.
At this point, the role and responsibility of a lean facilitator might begin to emerge as one of those countermeasures. Don’t have the expertise? Import it.
What doesn’t work, though, is to use the lean facilitator to substitute for the leader’s full and direct participation in the process of improvement. And no job description, no matter how carefully crafted, can fix that.
There are a lot of variations on a theme where someone asks an Internet forum how to quantify or justify the benefits of implementing a continuous improvement program.
If you think about it, though, this is really interesting question.
What are the benefits of NOT having continuous improvement? Why would managers deliberately decide not to have a learning organization, not to have continuous improvement, not to fully engage the intelligence of their workers?
Why would managers deliberately decide not to improve safety, quality, delivery, lead times?
What if we asked the question that way?
What is the benefit of not having these things?
If that question is subsequently dismissed as stupid (which I hope it would be), then the question is no longer whether they should be pursued, but how.
One of the more effective facilitation tools I have come across is to have a team first construct an ideal flow, without the constraints of the space geometry, known flow-busters, or even too much concern about the takt time.
Just make things flow as smoothly and efficiently as you can envision. Develop the flow as though a single person were performing the entire process from start to finish. Make it as smooth as possible for this person. No back tracking, no awkward motions. Everything is where it needs to be, when it needs to be there.
This allows the team to let go of all of the “reasons why not” for a while, and see the possibilities.
Then, one by one, re-introduce the constraints of reality.
How can we make it work when we introduce this problem? Does the process still meet the target objective?
Approaching it this way helps teams that are so embedded in the stormy ocean of day-to-day problems that they can’t see things possibly working smoothly.
It also reinforces the notion that we want to see things, not as “what can we improve from the baseline” but rather “how far are we from the target?”
In slightly modified form, this approach worked pretty well this week. Slightly modified? I, too, sometimes have to bend things around how the world presents itself to me.
Sometimes we like to talk in abstracts. “Reduce batch sizes” or “reduce lead time.”
But let’s be clear what we are striving for. With every improvement we make, we want to converge on the idea of:
Lest anyone thinks that is impossible, consider the post before this one about 3D printing technology, and look where it is going.
As Mike Rother emphasizes in his teaching the trend throughout the history of making things has been in this direction.
The pendulum swung in favor of volume in the industrial revolution as production shifted from craft (batch size of one, long lead times, high costs) toward large batches, in order to achieve better economics.
Somewhere along the way, we lost sight of the fact that we gave something up for those lower costs.
The companies that can return the benefits of one-off production while holding the costs are going to win.
But.. make no mistake… the suppliers of cheap mass molded and cast parts have a disruptive technology headed their way that fits the model perfectly.
I have probably written around this question in the past, but it comes up often enough that I wanted to address is specifically.
One of the challenges facing the lean practitioner is the “What can you do for me?” boss (or client).
This manager wants to know the expected ROI and outcome of your proposal before he agrees to make the investment in improvement.
This style of proposal-evaluation-decision management is exactly what is taught in every business school in the world. The process of management is a process of deciding between alternative courses of action, including no action at all.
This approach actually creates “no action” as the baseline. Any change is going to disrupt the status-quo and incur some kind of cost. Therefore, the thinking goes, the change better be worth it. “Am I going to get enough back?”
“What can you do for me?” implies a general sense of satisfaction with the status quo.
The lean thinker reverses this model. The status quo is a stagnant and dangerous place.
There is always an improved state that we are striving for.
Rather than measuring progress from the current state, we are measuring remaining gap to the target, and we must close that gap.
There are problems in the way.
Proposed solutions to those problems are evaluated on (among many other things) cost to see if the solution is an acceptable one, or if more work is required to find a better solution. But maintaining the status quo is not on the table. The decision has already been made to advance the capability of the organization. The only decision is around how to do it, not whether to do it.
So when a legacy GM style manager asks “What can you do for me?” the question must be changed to “What are you striving to achieve?”
Challenging the complacency of the status quo is our biggest hurdle.
5S has become an (almost) unchallenged starting point for converting to lean production. Although the basics are quite simple, it is often a difficult and challenging process.
After the initial push to sort stuff out and organize what remains, sustaining often usually almost always becomes an issue.
Again, because of early legacy, the most common response is what I call the 5×5 audit. This is a 5×5 grid, assigning 5 points across each of the “S” categories. It carries an assumption that managers will strive for a high audit score, and thus, work to sustain and even improve the level of organization.
Just today I overheard a manager trying to make the case that an audit score in his area ought to be higher. It was obvious that the objective, at least in the mind of the manager, was the audit score rather than solving problems.
The target condition had become abstract, and 5S had become a “program” with no evident or obvious purpose other than the general goodness that we talk about upon its introduction.
If the audit score is not the most important thing, then why do we emphasize it so much? What is our fascination with assigning points to results vs. looking at the actual results we are striving to achieve?
To digress a bit, many will say at this point that this is an example of too much emphasis on audits. And I agree. But this is more common than not, so I think of this as an instance of a general problem rather than a one-off exception.
Our target condition is a stable process with reduced, more consistent cycle times as less time is spent hunting for things. Though we may see a correlation between 5S audit scores and stability, it is all to easy to focus on the score and forget the reason.
Shop floor people tend to be intelligent and pragmatic types. They do not deal in a world of abstraction. While the correlation might make sense to a manager used to dealing in an abstract world of measurements and financials, that is often not the case where the work is actually done.
The challenge is: How do we make this pragmatic so it makes sense to pragmatic people?
Let’s start by returning the focus to pragmatic problems. Instead of citing general stories where people waste time looking for things so we can present a general solution of 5S, let’s keep the focus on specifics.
What if (as a purely untried hypothetical), we asked a team member to put a simple tick mark //// on a white board when he has to stop and hunt for something, or even dig through a pile to get something he knows is in there? If you multiply that simple exercise times all of the people in the work area, add up the tick marks every day, and then track the trend, you may just get more valuable information than you would with the 5×5 audit done once a month.
What if we actually track stability and cycle times. Isn’t this avoiding these wastes the case we make for 5S in the first place? So perhaps we should track actual results to see if out understanding is correct, or if it has gaps (which it does, always).
What if we taught area leaders to see instability, off-task motions, and to see those things as problems. Let them understand what workplace dis-organization causes.
How about tracking individual problems solved rather than a general class of blanket countermeasure?
How many sources of work instability did we address today? I’d like to see what you learned in the process. What sources of instability did you uncover as you fixed those? What is your plan to deal with them? Great!
No problems today? OK – let’s watch and see if we missed anything. OH! What happened there? Why did we miss that before? Could we have spotted that problem sooner? What do we need to change so we can see it, and fix it, before it is an issue with the work?
These are all questions that naturally follow a thorough understanding of what 5S actually means.
But we have had 5S freeze dried and vacuum packed for easy distribution and consumption. At some point along the way, we seem to have forgotten its organic state.