Thoughts and Insights from the Shop Floor
In this world of laser beams and ultrasonic transducers, we sometimes lost sight of simplicity.
Remember- the simplest solution that works is probably the best. A good visual control should tell the operator, immediately, if a process is going beyond the specified parameters.
Ideally the process would be stopped automatically, however a clear signal to stop, given in time to avoid a more serious problem, is adequate.
So, in that spirit I give you (from Gizmodo) the following example:
“What have you learned?” It is a question I hear often at the end of kaizen events and other improvement activity. The key points of a typical report-out, though, seem to be on how much was accomplished, and what was learned comes as an afterthought.
A typical week-long kaizen event is organized like this:
Monday: There may be some classroom type training followed by studying the process. This study is often collecting cycle times and building spaghetti charts.
Tuesday: The team develops their vision or target state – they decide what they are going to do.
Wednesday / Thursday: Make some pretty dramatic changes to the process.
Friday: Report the results followed by pizza for everybody.
The pre-planning often includes some targets for cycle time or inventory, and sometimes even qualifies as a “target condition” that is focused on larger level objectives. But equally often, it doesn’t. The target results are vague or simply “Look at this process and improve it.”
Here is a question – how many coaching cycles – instances where a situation was understood, a target was established, an attempt was made to hit the target, and learning was assessed – actually happen in the course of this week?
In the worst case, zero. Those are the instances where the Friday report-out is followed on Monday by leaving work team to bask in their newly improved process. There is no attempt at all to see what they are struggling with, or if there is, it is an “audit” with the idea of “ensuring compliance” with the new process. No learning at all takes place in this situation. There is only blame shifting.
Nearly as bad is when the answer is “one.” That is, there is some attempt prior to Friday to see if the target condition is achieved, and to understand what new issues have emerged. The problem here is that it is usually too late to do anything. The improvement experts are moving on to planning another event, and whatever is left behind is usually an action item list of incompletes from the week.
That doesn’t work very well either.
Neither does trying to capture “learnings” on a flip chart at the end of the event. That is a nice feel-good exercise, but rarely translates into improving the process of process improvement
So if the above is a “current condition” then what is the target?
How can improvement itself be organized so that we learn how to do it better?
One thing would be to structure kaizen events to cycle through the coaching process many more times during the week. Take the five day agenda, and carry it through EVERY day. That is a start. How would your kaizen events be different if you did five one-day events in a row rather than one five day event? Isn’t that close to one-piece-flow?
What would be the next step after that?
Now and then, usually when coaching or teaching someone, I get what I think is a flash of insight. Then I realize that, no, there is nothing new here, it is just a different way to say the same thing. Still, sometimes finding a different way of expressing a concept helps people grasp it, so here is one I jotted down while I was working with a plant.
One of the myths of “lean production” is the idea that, at some point, you achieve stability in all of your processes.
Nothing could be further from the truth.
Failure is a normal condition.
The question is not, whether or not you have process breakdowns.
The question is how you respond to them. Actually, a more fundamental question is whether you even recognize “process failure” that doesn’t knock you over. Our reflex is to try to build failure modes that allow things to continue without intervention. In other words, we inject the process with Novocain so we don’t feel the pain. That doesn’t stop us from hitting our thumb with the hammer, it just doesn’t hurt so much.
But think about it a different way.
“What failed today?”
Followed by
“How do we fix that?”
Now you are on the continuous improvement journey. You are using the inevitable process failure as a valuable source of information, because it tells you something you didn’t know.
There is a huge, well established, body of theory in psychology and neuroscience that says that we learn best when three things happen:
In other words, when we (as humans) are confronted with an unexpected event, we are flooded with an emotional response that we would rather avoid. In simple terms, this translates to “we like to be right.” The easiest way to “be right” is to anticipate nothing.
This takes a lot of forms, usually sounding like excuses that explain why stability is impossible, so why bother trying?
Why indeed? Simple – if you ever want to get out of perpetual chaos, you first have to embrace the idea that you must try, and fail, before you even know what the real issues are.
One of the issues Mike Rother says he has had with the coaching questions in Toyota Kata is question #5 “When can we go see what you have learned?”
In the west, inevitably it seems, once the word “When” is uttered, everyone in the conversation leaps to hear “When will you be done?” no matter how the question is actually framed.
As I am understanding it right now, the actual intent is for the coach to establish two things:
Based on Rother’s experience with this question, I am tinkering with how to re-frame it so I can use it more effectively. Ultimately the behavior I want is an invitation to jointly observe how the proposed countermeasure has changed the process. We want to understand the actual effect vs the intended effect.
That, of course, requires that the intended effect is understood and explicitly stated before trying. That does NOT mean that every little step is documented on paper such as an A3. That is far too cumbersome at this level of granularity. We want this process to cycle faster than the time required to write this stuff down. It does mean that I would have evidence that it has been thought through rather than just blindly trying something.
Duke has posed an interesting question on the forum:
http://forums.theleanthinker.com/viewtopic.php?f=11&t=35
Actually a couple of questions.
They get to the heart of “When can you say something is actually a process?”
I have my views, but I want to hold back until I hear from some of you.
This could get as good as the 5S discussion. 🙂
In my review of Toyota Kata by Mike Rother, I suggested that the staff-level practitioners who are embedded in almost every company that is “implementing lean” could put those practices to work immediately, even if it was not an ideal “top down” teaching process.
This week I gave that a try.
I was coaching a workshop leader who was, in turn, leading the team I mentioned earlier. He was simultaneously reading the book, I referred him to “the coaching questions” on page 247 and we worked together to keep asking them as the team was doing its work.
Since the team was working to solve problems that were blocking the problem solving process, it got a little complicated to keep them focused on the right “immediate problem.” However what I observed, for sure, was that my workshop leader’s skills improved significantly as the week went on, as did the team’s understanding of the issues and countermeasures.
My working theory was that just asking the questions puts someone into “teaching mode” and, as I have said earlier, the best way to learn is to try to teach.
Was this the ideal approach advocated by Mike Rother? Nope. I will have to loop back and catch some of the foundational elements. But as I have experienced in the past, these practices are so powerful that even trying and awkward application gets significantly better results than following no structure at all.
Start asking the questions, and see what you can learn as you try to teach.
This week I am coaching a kaizen team in the first phases of implementing a process to respond to problems on the shop floor.
They clearly understand the objective, and are working hard.
The key is to keep them focused on working out the problem response process vs. getting distracted by the production problems they are responding to.
For my part, in an effort to accelerate the cycles of learning, I am trying to consciously apply “the five questions" of the coaching cycle as outlined on page 247 of Toyota Kata by Mike Rother.
They are:
This will not be my only opportunity – I have other challenges lining up in other parts of the company that I support.
I’ll tell you, though, it isn’t as easy as just asking the questions.
The first challenge is context. My actual condition is that this kind of rigor is new to even experienced kaizen practitioners out there. As Rother, and others, point out, most “kaizen events” simply aren’t structured this way.
There is a strong bias toward generalization and sweeping statements of "problems” and “what we need to do is…” I have to keep working to bring the focus back to what is directly in front of us as we try to work through this specific iteration. Yes, that other thing might be an issue, but it isn’t coming up NOW, so let’s keep working on what is actually stopping us.
This is important because it gives the problem solvers great power. If they can learn to stick to what is stopping them right now, they have an easier time not getting discouraged by all of the other issues that are out there.
One-by-one. Step-by-step.
Of course this iteration is complicated by the fact that we are working on a process designed to clear problems in another process, so it is easy to get sucked in to the production issues.
To their credit – we have a Home Depot technology andon light, and the team members who are the subjects of this experiment seem to be appreciating (for now) the fact that this group of people is swarming every issue they run into.
I suppose, at some level, that makes emotional sense. After all, the idea is to keep production moving.
But the logical follow-on question is: “OK, so if the team member encounters aproblem that is going to force her to work around things, to do the work in a way that wasn’t planned, what do you want her to do?“
I would like to thank everybody for a really engaging dialog in the previous two posts about 5S audits.
Now I would like to dig in and look at what an “audit” is actually finding, and how we are responding to those issues.
Our hypothetical production area is getting an audit. The checklist says things like “There are no unnecessary items in the work area” and “There is a location indicated for all items.”
If there are unnecessary things in the work area, or things are not in their designated locations, what happens?
Of course, the checklist is filled out and a score is assigned.
But what has been learned about the process?
In one of the comments, I asked something like “When was the problem first noticed?”
The core purpose of 5S is to establish a testable condition that asks the question: “Does the team member have everything he needs, and nothing he doesn’t, where he needs it, when he needs it, to carry out his process as we understand it?”
One of the primary purposes of marking out the locations is to indicate the standard so that someone can notice right away that the standard has been broken. What should happen right then and there?
Since we define a “problem” as “any departure from the standard or specification,” and we have taken the first step of removing ambiguity from the situation (by deciding what should be here, and marking it out), we want an immediate response to the problem.
Ideally this means that the team member would indicate trouble (andon call, or other means) as soon as he discovered that his air gun was missing, or didn’t work.
The back-up to this is the team leader’s standard work. His eyes should be scanning for situations where there is a problem that the team member hasn’t called out. This is why the standards are marked out, posted, etc. To make this job easy for him. His immediate response would be to (1) Seek to understand the situation – what pulled the team member off his standard work, where did the problem originate, (2) Correct the situation. Sometimes that’s it. Other times, there is another problem to dig into.
It could be that something about the work process or conditions has changed and the team member is improvising a bit. That would bring extra stuff into the area, for example. I recall a great example where we pulled all of the thread cutting tools out of assembly so we could better detect when assembly was getting defective fabricated parts. It worked by forcing the process to stop and an andon call since assembly could not proceed if the threads were not cut.
At the same time, if a thread cutter found its way back into the assembly area, we would know we had two problems. First, we had defective parts. But more important, the process of telling us about that problem had been bypassed.
The back-up to the team leader’s standard work is the supervisor’s standard work. She is looking two levels down, but her response is going to be different. Unless safety or quality is jeopardized, the supervisor is going to find the team leader and (1) Seek to understand what pulled the team leader off of his standard work, and (2) correct the situation.
If the next level up is spending any time at all out on the shop floor, it is the same thing – maybe once a day – seeking out verifiable evidence that things are working as they should be. In the lack of positive evidence of control, we must assume there are hidden problems.
Now, if the audit finds something like this (click on the image for a bigger one):
Then it isn’t about the tape being out of place, nor is it a question about where the screwdriver is. What we have discovered is that none of the checks have been made, or if they have, no one has done anything about them.
Someone said “If we don’t do audits then 5S deteriorates.” OK – but why does 5S deteriorate?
Simply put, it is going to deteriorate, just as your process does, a little bit every day. Disorder is always being injected into everything. Your process will never, ever be stable on its own. No matter how good you are, the next level of granularity will show up as deterioration.
This is the “chatter” that Steven Spear talks about.
The question comes down to your core intention for the audit.
If you are assessing how well the area manager is coaching and teaching his people to see and respond to problems so that you can establish a target condition for his learning, and then develop his capabilities accordingly… there are better ways (in my opinion) to do that.
If you are assigning a numeric score in the hope that, by measuring something you can influence behavior, it might work, but people can come up with ingeniously destructive ways to achieve the numeric goals. As a thought experiment – how might an area manager get a high score on his 5S audit in ways that run completely counter to the goals of 5S, people development or “lean?”
The bottom line is that “Audit 5S” is not something that you should accept as a given. Rather, it is a proposed countermeasure to some problem. But if you start with a clear problem statement like “Team members are bringing thread taps into the assembly line,” and start asking “Why” five times, get to a root cause to that problem, you are unlikely to arrive at a monthly or periodic 5S audit as a countermeasure – nor are you ever going to need one.
The problem?
I think we feel the need to do audits because we have no process to immediately detect, correct and solve the little problems that happen every day. These little issues are the ones that cause the 5S erosion. Because we don’t have a process to deal with them one-by-one, we have to have an elaborate process that disrupts our normal work flow and takes them on in big batches.
Does that sound like a “lean” process to you?
How might we relentlessly drive the “audit” process closer to the ideal of one-by-one confirmation?
That would be “lean thinking.”
When improvement teams set up kanban loops, they often get very creative about how they actually operate. What follows is an example of one such loop, and then I am inviting comment and replies to some specific questions I have.
The process works like this:
You are a kaizen manager for the company. You are checking on your kaizen teams as they do their work, and discover they are implementing the above process. The kaizen workshop leader who is guiding this team works for you.
Questions:
What, if anything, would you think about this solution, and what, if anything, would you say to the kaizen team leader?
I am serious – I am looking for input here. I have my views, but I want to hear from others.