Category: Quality

Posted on

Eliminating Key Points

TWI Job Instruction is a structured process for breaking a job or task into teachable elements, and a 4 step process for teaching that job to someone.

I am not going to try to explain everything about breaking down a job here, this post is primarily for people who use job breakdowns and job instruction already.

The process of breaking down a job involves:

  • Identifying the Important Steps – the sub-tasks that materially advance the work.
  • Then identifying Key Points within important steps. These are things which the team member must pay special attention to, or perform a specific way. The guideline is that a key point is something which:
    • Is a safety issue – could injure the worker, or someone else.
    • Would “make or break the job” – critical to quality or the outcome of the work.
    • Is a “knack” or special technique that an experienced team member would use to make the job easier to do.

Breaking down a job this way takes practice, but it is a great way to identify the elements that are critical to safely getting a quality job done, and ensuring that the team member understands them.

But I want to propose this is only the first step.

Every key point is something the team member must remember in order to to not get hurt (or hurt others); to avoid scrapping or damaging something; to perform at the level you need.

Take it to the next level.

Think of these key points and the training that they drive as temporary countermeasures.  They are stop gaps you have in place until you can do something more robust.

Take one key point at a time. Why is it necessary? Why is it possible to do this step any way but the best way?

Can you alter the work environment – the product, the process, the equipment, the visual controls to reduce the things the team member has to remember (and you have to remember to teach)?

Can you make it impossible to perform that step in any way other than the way it should be done?

If you can’t, can you make it impossible to proceed until the error is corrected, before any harm is done?

If you can’t, can you make it so obvious that it is impossible to miss?

If you can’t, can you put in a robust reminder? (Signs and placards generally DON’T WORK for this unless they are especially “sticky.”

Every key point is something you have identified as critical to doing the job directly. Therefore every key point should drive a focused effort to mistake-proof the work.

You want to have as few as possible… but no fewer.

Posted on

The Value of Mistake Proofing

Most companies use some version of the words “respect for people” in their HR mantras. But how is that respect demonstrated?

A team member made a mistake today. He is building a sub-assembly on a mixed model line. He picked a part from a small blue bin with a divider in it.

On one side of that divider is the part he should have picked and installed.

On the other side of the divider is a very similar part.

Guess which one ended up in his hand?

The issue wasn’t caught until a couple of positions down line. When it was caught, it was quickly reworked and corrected.

This particular team member is coming up on the end of his 90 day probationary employment period.

He has seen co-workers who “didn’t make it” (not cut out for assembly work). But he is a smart guy, hard worker, has participated in a lot of improvements for the work he is doing.

Nevertheless, he is worried about the consequences of making this mistake so close to his 90 day evaluation. He just wrote, it seems, what he hopes is his last COBRA check* that will cover him and his wife until his health insurance kicks in at the end of the month.

What is the value of mistake-proofing this operation?

Actually, the consequences of this error are minor. It is easily caught and quickly corrected in a subsequent operation. It is very, very rare. You could make the argument that there are better returns spending the limited problem solving time on bigger issues, and you’d be right… to a point.

But what if this team member’s experience was to see attention focused, not on him, but on what it was about the layout of the work area, about the presentation of parts, about the structure of the work, made it possible to make this error.

What if they acknowledged, overtly, that this kind of mistake is a consequence of being a human being, and that it was only that he happened to be the one standing there when the random chance generator came up?

What if he saw the team leader and supervisor engage him in conversation about what might be done to at least eliminate some of those possibilities? (We don’t really know what happened, though there are some likely guesses.)

What if he was also asked to look for other similar error opportunities, even in his co-worker’s areas, and help eliminate those as well?

What would be the return?

Might this team member work just a little harder to make things even better in the future?

Maybe he would help turn around a cynical or skeptical co-worker.

Maybe he would feel a bit appreciated for what he is contributing instead of losing sleep about his job.

Maybe, at some point in the future, when he is a shop steward, he might remember that “they” are all to human as well.

Who knows.

Before you say “it isn’t worth it” remember what Deming pointed out – “Management’s real job is to manage the unmeasurable.”

Good news – in this (real life) case, they are, for sure, eliminating the split bin and separating the two similar parts from one another; plus likely separating two other bins holding similar bolts. Maybe more, there are some ideas being kicked around.

In the end, though, consider if you will the ROI on team members knowing you will support them in their quest to succeed every day.

*For my non-US readers: COBRA is a program where someone can continue employer-provided health care after termination of employment for up to 18 months by paying the cost yourself. This is sometimes cheaper than purchasing private health insurance.

Posted on

Appearances vs. Reality

I’m looking at a form labeled as an X-Bar / R-Bar SPC chart. It is filled out pretty consistently by the operators.

But the “control limits” are actually specification limits, and the “standard deviation” looks like it is calculated as 1/3 x the spec limits to force the lines to where they want them from the mean… er ah… nominal.

When I asked about it, at least one company leader was under no illusion that this was a statistical process control, it is simply a means to develop a run chart of actual parameters vs. a nominal value and the specification limits.

I’ve seen far worse, like the time an engineer didn’t understand the difference between “in control” and “in specification.”

But what do they say in their everyday conversations? Do they talk about this process being “within specification” or “in control?” I expect the later.

Posted on

Another Customer Story

I was in a newly opened store of a large big-box outdoor sports store, and saw an item on display that I had already decided to buy this summer. The displayed price was actually a bit less than what I had been encountering online, so I went ahead.

Unfortunately the one “in stock” on the shelf turned out to be a different model (in the wrong slot), and I didn’t complete the transaction. (A retail nightmare, where the customer clearly wants to buy a big-ticket item you thought you had, but actually didn’t.)

The salesperson behind the counter offered that I could order the item from their web site, have it shipped to the store, and I could pick it up without incurring any shipping charges. Seemed fair enough.

I went online, but the online price was higher than the in-store price. In a sort of reverse from the story I told in December, I emailed customer service and asked if they would match the in-store price for the item.

In a few minutes I got a reply, with an “Incident Number” that said they would, but I would have to call in the order to the 800 number.

All well and good.

I called, and of course “catalog sales” had to refer me to customer service.

Customer service, in turn, had no way to look up the “Incident Number” on the email. “I don’t have any way of referring to that…” (Yeah, go ahead and tell the customer what you can’t do.)

I was referred to someone else (in email? I don’t know). He could not look up the number either, so I read the email exchange back to him. He honored the price, took the order, and it is on the way.

But really?

What is the “incident number” even for if nobody can reference it? In this day and age of networked and cross-linked everything…. what can I say? Perhaps my old I.T. background showing here.

Bottom line:

Turn around and face your systems from the customer’s perspective. Spend some time in the chalk circle. Think through how your process responds to unusual situations.

If a customer refers to something that you should know about your own process, but don’t, there is a kaizen opportunity here. You have an obstacle in the way of smooth seamless customer service. What concrete steps(s) will move you toward eliminating that barrier and smoothing things out?

Posted on

Scrap Bin Kaizen

If you are in a production operation, be it a factory or even administration, take a look in your scrap bins (or trash cans). What you find there can be very informative.

Is all scrap treated the same? In a lot of metal working operations, I see routine drop scrap mixed in with scrapped parts and products – things that were not intended to end up there.

If that is the case, what does it tell you about the attitude around scrapping a part? Is it routine, just part of getting the job done, like drop scrap?

If you find a scrapped part, can you find the defect or flaw that caused it to be unusable? How much work (and cost) was added after that defect was created? All of that is additional cost that added no value.

Was it painted? Partly assembled? Did it go through a bottleneck operation and consume capacity of the entire factory?

What about your trash cans or recycle bins in the office?

Do you see signs of frequent paper jams in printers and copiers? These events suck time away, and more than just the time to clear them. They cause a mental shifting of thought pattern away from the productive work that takes additional time to recover.

Here are a couple of thoughts.

Separate the routine drop scrap from bad parts that were supposed to be good parts. If you sacrifice parts to adjust in changeovers, separate those out into their own category.

Each of these is a different line of inquiry starting with the question “Why?”

Consider taking your bad parts from the last 24 hours and bringing them to a central location (or a location in the department). Conduct a “morning market” and get to the bottom of at least a couple of the root causes. You don’t have to solve all of them at once, just pick one and drive it to ground. Then another.

Scrap is not simply a material and time waste. It is a reflection of how well you really understand your processes.

Posted on

The Process of Caring

Vance left a really good comment on the recent Travel Tales post. He said, in part:

Having worked in the airline business, it’s really a matter of having employees that CARE (most due to their own pride, not by management) We many times had weather and mis-connected passengers to deal with. It only took a few minutes of extra time to send a message to the destination station and let them know what to expect or which passenger was going to be disappointed to not get their bag. Today’s situation is exacerbated by under-staffing, stressed employees, passengers with sometimes unrealistic expectations, checked bag fees, etc it’s ugly and very little relief in sight.

He brings up some really interesting points. In most of the airline industry, like most industry in general, “caring” is thought of as something the people have to do.

“The employees don’t care” or even “management doesn’t care” are pretty common statements.

Let’s turn it around.

How was the original process designed?

Continuing on the theme from the original post, I would speculate that most players in the airline industry see themselves as providing transportation to people and their stuff.

The process design is, logically, going to center on what things have to happen to get people and their stuff from their point of entry into the system through to their point of exit at baggage claim. (the fact that the trip doesn’t actually end at baggage claim is another topic – one which has been discussed by Jim Womack in Lean Thinking, among other places.)

In traditional thinking, improvements in that process will involve making those things happen cheaper, usually by doing less.

What if, though, we start with a different question:

“What experience do we want the customer to have?”

Describe, first and foremost, the things the customer has to do to get herself and her stuff from the point of departure to (sadly) baggage claim. (Bonus points if beyond, but let’s not stretch the fantasy too far.)

Even better, act it out. Simulate it. Try it on. Work out the kinks, from the customer’s perspective.

Next, design the interface between your customer and your process. What does the customer-touching part of your process have to look like to deliver that experience?

(I often wonder if airline executives ever see their own web reservation systems.)

Now, only when you know what the “on stage” part of your process looks like can you design the rest of it – the back stage parts that make it all happen.

Economics come into play at this last stage. This is where you have to get creative. If the solution is too expensive, work on the back-stage part to make it cleaner and more streamlined. The customer facing part of the process is the target condition. Your problem solving works to deliver that experience in continuously better ways.

What does this have to do with “caring?”

Remember, this is from the customer’s perspective. When we say “our employees care” do we not really mean “our customer’s feel cared-about?” Since we started with the customer’s experience, if that is what is desired, it was built into the process specification from the beginning.

Once there is a process that we predict will result in customer’s feeling that people care about them, then your market surveys make sense. You are not soliciting complaints about things to fix, you are validating (or refuting) your design assumptions. Every bit of customer feedback will be a learning experience.

Don’t forget Murphy.

In a complex business like airline travel, sometimes luggage doesn’t get to baggage claim at the same time as the customer. It happens. But this is the time to really apply the above process design. What do you want the customer to experience when things go wrong?

Ironically, in the customer satisfaction world, a spectacular and surprising recovery actually generates more loyalty than flawless delivery of service. This is the moment for your company to shine.

Whatever happens, though, make sure it is something you would do on purpose rather than relying on chance or a random team member’s disposition. Build “caring” into the process itself, and you will embed it into the culture.

Posted on

Simple Solutions

Carlos Villela’s blog lixo.org has a great story about simple solutions. I really have no idea if it is true or not – indeed, a couple of the details don’t hang together. On the other hand, I have seen for myself the kind of thinking that is described in this story.

Link to full story: Networks are smart at the edges.

The factory is having a quality issue. The response is pretty typical:

The project followed the usual process: budget and project sponsor allocated, RFP, third-parties selected, and six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time. They solved the problem by using some high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box weighing less than it should. The line would stop, and someone had to walk over and yank the defective box out of it, pressing another button when done.

And a great solution. It stops the line and forces someone to pay attention to the problem. While I would usually add that these instances need to be followed up by problem solving to eliminate the issue, even if I were doing so, I wouldn’t eliminate the final verification check. Even Toyota performs a thorough and rigorous final inspection. But that’s not the point here.

It turns out, the number of defects picked up by the scales was 0 after three weeks of production use. It should’ve been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers come back saying the report was actually correct. The scales really weren’t picking up any defects, because all boxes that got to that point in the conveyor belt were good.

Puzzled, the CEO travels down to the factory, and walks up to the part of the line where the precision scales were installed. A few feet before it, there was a $20 desk fan, blowing the empty boxes out of the belt and into a bin.

“Oh, that — one of the guys put it there ’cause he was tired of walking over every time the bell rang”, says one of the workers.

Like the Dilbert cartoon about 25 critical focus areas, this is more funny because the original reaction is totally typical, especially in companies who are comfortable with technology, controls, automation, etc.

Cudos to the CEO who realized, at least, that “No problem is a problem” and went to investigate at the actual gemba.

Once the team had a challenge (in this case small-Peanut-MMsprovided by the annoying bell) they dealt with what they saw as the issue.

Oh – and this graphic? It is an inside joke for some of my readers. Maybe we should have put some fans on the conveyer.

Thanks to Hal for sending the original link to this article.

Posted on

Mike Rother: Time to Retire the Wedge

Note – this post was written pretty much simultaneously with a post on the lean.org forum.

Mike Rother has put up a compelling presentation that highlights a long-standing misunderstanding about the purpose of “standards.”

Some time ago, a (well-meaning) author or consultant constructed a graphic that shows the PDCA wheel rolling up the incline of improvement. There is a wedge labeled “Standards” shoved as a chock block under the wheel to keep it from rolling back. That graphic has been copied many times over the years, and shows up in nearly every presentation about PDCA or standard work.

The implication – at least as interpreted by most – is that a process is changed for the better, a new standard is created, and people are expected to follow the standard to “hold the gains” while they work on rolling the PDCA wheel up to the next level on the ramp.

Slide 6 (taken from the book Toyota Kata) shows the underlying assumptions that are implied by this approach, especially when it doesn’t work.

There are some interesting assumptions embedded in the “wedge thinking.”

The first one is that “the standard can be ‘held’ by the people doing the work.

That, in turn, means that if when things start to deteriorate, the workers and first line leaders are somehow responsible for the “slippage” or “not supporting the changes.”

With this attitude, we hear things like “Our workers aren’t disciplined enough” or “How do I make them follow the standard?” The logical countermeasures are those associated with compliance – audits focused on compliance, and sometimes even escalating punitive actions.

Back in my early days, I had a shop floor team member call us on it quite well: “How can you expect us to hold some kind of standard work if the parts don’t fit?” (or aren’t here, or the tools don’t work, or jigs are misaligned, or the machine isn’t running right, or someone is absent, or we are being told to hurry and just get stuff out the door?)

This is the approach of control. The standard is fixed until we decide to change it.

Taiichi Ohno didn’t teach it this way.

Neither did Deming or Juran. Neither did Goldratt. Nor does Six Sigma, TQM, TPM.

Indeed, if we want creativity to be focused on improvements, we have to look up the incline, not back.

We are putting “standards” on the wrong side of the wheel. Rother’s presentation gets it right – the “standards” are the target – what we are striving to achieve.

The purpose of standards is to compare what we actually do against what we wanted to do so we know when they are different and so we have some idea what stopped us from getting there.

Then we have to swarm the problem, and remove the barrier. Try it again, and learn what stops us the next time.

The old model shows “standards” as a countermeasure to prevent backsliding, when in reality, standards are a test to see if our true countermeasures are working.

I believe this model of “standards” as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what “continuous improvement” really means.

It is time to actively refute the model.

If you own your corporate training materials, find that slide (it is in there somewhere) and change it.

If you see this model in a presentation, challenge it. Ask what should happen if something gets in the way of meeting this “standard.”

“What, exactly do you expect the team member to do?”  That sparks an interesting conversation which reveals quite a bit.

Posted on

NPR: Hospitals New Face Pressure to Reduce Infection Rates

This article on NPR is chiefly about the dilemma that hospital administrators are facing as escalating government reporting requirements are being tied to their Medicare payments. (For my non-US readers, Medicare is the U.S. government medical insurance program for seniors and retirees. It pays a huge portion of hospital’s revenue, and thus, its policies carry a lot of weight).

The article’s lead does a good job of summing up the issue:

Under laws in more than two dozen states and new Medicare rules that went into effect earlier this year, hospitals are required to report infections — risking their reputations as sterile sanctuaries — or pay a penalty. That’s left hospital administrators weighing the cost of ‘fessing up against the cost of fines.

So, in effect, the administrators are faced with weighing the financial impact of lost Medicare payments vs. the financial impact of telling the truth about their infection rates. This is, in my mind, yet another symptom of the General Motors style of management that is taught by every MBA program in the world.

It also suggests that there is a viable alternative of continuing to maintain the illusion that it is not a problem.

Is it a problem? Hospital infections kill about 90,000 people a year in the USA. Compare that with the 40,000 or so that are killed in traffic accidents, and you get the idea.

Add to that the fact that the patient ends up getting billed (and usually insurance pays the bulk) for the treatment of these infections.

Fundamentally this is about quality, and the problem is certainly not limited to health care. (it is just that lives are at stake)

How does your company respond when there is a known issue that is impacting quality?

If you deliver a defective product or service, do you charge your customers for the rework? This is not a facetious question. Some companies do.

Do you avoid collecting information for fear of revealing the true magnitude of a problem?

Do your workers fear bringing it up when they are directed to carry out inappropriate actions, or actions which violate the company’s written policies and procedures?

Is it OK to improvise outside of your known process in order to get the part out the door?

Back to the hospital – we know how to tackle this problem. It is merely extremely difficult. That doesn’t make it impossible. I am glad it is getting attention. I am disappointed that it takes government generated threats of visibility to get action.

Posted on

WWII Visual Control

PC pointed out a really interesting bit of visual control history to me.

In a recently aired episode of Showdown: Air Combat the host, a USAF fighter jock, asked about a series of colored stripes painted on a bit of sheet metal attached to the landing gear of a beautifully restored A6M Zero .

The piece of aluminum sheet is attached to the landing gear and fairs in the landing gear bay when retracted. The plane’s pilot/historian explained that they were an indicator for the ground (or deck) crew. As the landing gear’s hydraulic struts compress they align with the different stripes, allowing the crew to instantly see the load condition of the aircraft.

So for the cost of nothing more than a few square inches of paint they had an immediate, reliable, easy to use (from a distance, even), intuitive “mechanism” for the aircraft handlers to obtain critical fuel+ordinance info on the planes at any time.

While weight is always critical on an aircraft, it is even more critical on a WWII era aircraft carrier, before there were catapults. Where I can see this simple visual check becoming really valuable is if the crew spots one that is different than the others.

Here is a question – how can you adopt this principle to make a quick, visual weight check to assure, for example, that everything is in the package before it ships?