5S With Purpose

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.

Color coded tool holders.

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.

Simple Solution to Complex Problem

This video captures a crucial aspect of lean thinking – searching for the simple and elegant solution.

We can’t say this is an obvious idea, a lot of very smart people have been working on this problem for decades.

But it is a simple idea. Sometimes the search needs to be outside of the regular domain people are used to working in.

The web site is here:http://creativemachines.cornell.edu/jamming_gripper

The other aspect of lean thinking that is captured here is keep working to solve the problem. I run into so many technical people today who are so convinced that the problem is unsolvable with current technology that they either give up, or look to advance the state of the art in some (usually expensive) way.

One thing I am glad to see is a trend in engineering schools toward making things rather than just designing them.

Organize, Standardize, Stabilize, Optimize

As I work in the field, I continue to encounter a desire to get right to optimal results – “Why aren’t we working to eliminate all of the waste?”

Once people start seeing opportunities, there is a great temptation to try to simply engineer a new process and implement it. This is especially true in value stream mapping processes. The future state map seems like an engineering specification – just make it look like this, and all of these issues will go away.

The “kaizen bursts” are supposed to represent the obstacles in the way, but they often show up as “action items” instead as people are tempted to make this into a project.

But the messy reality in the actual workplace (gemba) requires a far more methodical approach.

The title of this post is from four steps that a consultant friend shared with me years ago. As I converge my own practice toward guiding people through implementing the daily improvement culture vs. implementing the tools, I am finding these words a handy mantra. This is how I have found myself explaining it lately:

image

Organize includes all steps required to make the current condition apparent. This can include 5S activity, but is by no means limited to that.

You want to know enough about what is going on that you can tell the normal, intended, pattern from one which has been disrupted by an obstacle or issue.

In other words, you know how the process should operate if people don’t encounter any serious issues.

This allows you to standardize.

This is not a standard in terms of something you are trying to enforce.

Rather, it is a standard that you are striving to achieve each and every time the process is run.

“Did we make takt time with this work cycle?”

“Did this changeover go the way we intended?”

“Did we make a good part this time?”

(for Brian): “Did we get the quote out in two days?”

Once you know how the process is supposed to work, and what results you are supposed to get, you can clearly identify those times when it doesn’t work that way, or the results are not what you wanted.

imageStabilize: Now you can begin marching up the PDCA ramp toward the standard as you work to stabilize the process by systematically eliminating the issues.

Of course, for this to actually work, you must have a process to flag problems right away, pounce on them, clear them, and then feed them into a follow-on process that works to solve them.

As you apply countermeasures to sources of instability, you are adjusting the standard itself to include those countermeasures, making it more robust.

So Stabilize and Standardize play off one another in successive PDCA cycles.

imageNow… here is the trick part. Optimize can be indistinguishable from “Stabilize.” It is more of a semantics issue than anything else, and honestly, it isn’t worth arguing about.

Why?

Because as a process becomes stable, you are going to keep driving toward perfection, True North. You are going to have intermediate-term goals you are trying to reach that keep you moving forward. You are optimizing as long as you are moving in the right direction. So there isn’t really a distinctive point of shifting gears, there is only the most important issue to address right now to hit the next target condition.