The team was driving toward a consistently executed changeover process as a target condition.
In the last iteration, the process was disrupted by a scrapped first-run part. The initial level cause was an oversize bit in the NC router resulting in an out-of-spec trim and oversize holes.
This occurred in spite of the fact that there are standard tools that are supposed to be in standard locations in the tool holders on the back of the work pallet.
Upon investigation, the team found:
- The previous part had a programming error calling out the oversize tool from the wrong location.
- All of the operators were aware of this, and routinely replaced the “standard” tool with the one the program required.
- After that part was run, the standard condition had not been restored.
- There was likely a break in continuity between operators here, but that was less clear.
- The two bits are only 1/8 different, and hard to distinguish from one another across the 10 feet or so of the work pallet.
The team addressed the programming error, but among the thousands of other programs out there, they were reasonably certain that there were other cases where the same situation could be set up.
They wanted to ensure that it was very clear when there were non-standard tools in the standard locations.
Their initial approach was to create a large chart that called out which tools were to be in which holders. Their next experiment was to be to put that chart up in the work area.
“What do you expect to happen?”
That turned out to be a very powerful question. After a bit of questioning, they implied that the operator was to verify that the correct tools were in the standard positions before proceeding.
“How does this chart help them do that?”
They can see what the standard is.
“Don’t they all already know what the standard is?”
Yes…..
“So how does this chart help them do that?”
Now, to be clear, the conversation was not quite this scripted, but you are getting the idea. The point was to get them to be specific about what they expected the operator to do, and to be specific about how they expected their countermeasure to help the operator do it.
One team member offered up that maybe they could color-code the standard tools and their holders so it would be easy to check and easy to see if something was off-standard. That way, even IF the situation came up where the operator needed to deviate from the standard, anyone could easily see what was happening.
(I should add that they have already put an escalation process into place that should trap, and correct, these programming errors as they come up as well.)
The tools were color-coded over night, and in place the next day.
This wasn’t a “5S campaign,” nor is there an audit sheet that tries to measure the “level” of visual control in the work space.
Rather, this is using a visual control to visually control something, and reduce the likelihood of another scrapped part (and therefore, disrupted changeover).
Over the last week, the work cell has been improving. When things are flowing as they are supposed to, changeovers are routinely being done within the expected time.
But there are times when their standard WIP goes low; there are times when someone gets called away; when the flow doesn’t go as planned. When those things happen, they get off their standard.
The next countermeasure is to document, clearly, the normal pattern for who works where, for what inventory is where. Then the next question is “How can anyone verify, at a glance, whether or not the flow is running to the normal pattern?”
More visual controls. Ah.
Now we are seeing the reason behind 5S. It will come in to that work area, step by step, as the necessity to make things more clear arises.
Mark,
Having done more than a little changeover reduction work in my career, I have some thoughts on visual controls used during changeovers. One of my pet peeves believe it or not is checklists. Many of my teams have suggested adding visual controls – specifically checklists – to “make sure things are done correctly.” Now that sounds perfectly acceptable right? Well, let’s take a closer look.
First, adding a checklist is adding a secondary layer of protection / prevention in the form of a Poka Yoke – specifically Mistake Proofing. That would say it makes something “easy to do right and hard or impossible to do wrong.” But you know me, I’m kind of greedy. I think things should be easy to do right and impossible to do wrong. Doesn’t a checklist accomplish that? Let’s see.
Think of all the checklists you’ve seen in your career – both good and bad. The first question is whether or not they were actually used, or just forgotten. (Oh yea, it happens.) Then, how were they used? Did somebody go through each line item individually, check the actual condition against the standard to make sure they matched, or did they simply check everything off while standing in one place. Worse yet, did they simply draw a line / arrow through everything? So getting back to my ideal definition of Mistake Proofing, a checklist doesn’t always make something impossible to do wrong.
When it comes to tooling in CNC machines – which it appears you were dealing with – I’m a huge fan of standard tooling and if possible – standard locations for the standard tools. That’s because the best changeover is no changeover. If special tooling is needed, it ought to stand out like a sore thumb and go in a special / designated location. That makes it easier – but not impossible – to get wrong.
Tom
The key point here, at least for me, was not so much about the changeover, or even the 5S, but that cycling through the coaching process got them there on their own.
Hi,
Could anybody help me understand if Lean principles could be applied in a Software Development scenario?
How can one make use of CMMI to go ‘Lean’?
Thanks in advance,
Anitha
The benchmark for lean software development is Mary Poppendieck. This is a link to her web site:
http://www.poppendieck.com/
Thank you for sharing an example of coaching a group to their own solution. And what a simple, creative solution it was!
Thank you Tom for sharing about your experiences with checklists. I have had similar issues with checklists. When a checklist is the solution suggested by the group, perhaps that’s a time to coach the group to a more creative solution?