The starting hypothesis (or “plan”) is “This person should be able to do this.”

Then try (“do”).

Check: “Can s/he do it?”
If no, then we have learned something – the original assumption was wrong. This is good news. (This is the definition of “chatter” in my posts referring to Steve Spear).

It is good news because now we know the next point of weakness in the system to work on.

Escalation is simply the act of notifying the chain-of-support that there is a “problem.” On a good line, it means pulling an andon cord or turning on some kind of signal.

Many times people are overwhelmed thinking about trying to respond to all of the problems. That is where some rational thought comes into play. Respond to them in the sense of making sure safety and quality are not compromised, but then manage them. Some problems never get addressed. Fact of life. They end up in the “too hard” box. The good news is that the organization usually knows how to live with them. It isn’t about solving every problem that comes up, but rather, about systematically responding and solving as many as possible every day.

That was the beauty of the shuffling priority queue I mentioned. There was no attempt at FIFO, rather it was solving as MANY problems as possible. Sometimes the really hard ones just never got addressed, just contained.

To do this (actually solve problems), though, means carving out dedicated time to do it. Where most organizations fall down is the point where “working on solving problems” is only “when we have time.” Rather than being a prime activity, it is supposed to fit between the cracks. That doesn’t work.

It was your definition of… “Muri: “Overburden” or “Unreasonableness” – in short, asking someone to do something which he should not have to do, or which cannot be done.”

So it wasn’t an idea from a book I was reading, but from your page on Common Searches. In my mind I extended “Unreasonableness” to the many tasks I’ve been asked to do. I am a mountain of Muri. The marine saying… “We’ve done so much, with so little, for so long, THAT NOW we can do anything with nothing” is such nonsense… but it was fun to say. Thanks for the idea of escalating. Even the word “escalating” had a negative connotation with me. I thought that “Escalating” meant going crazy.

I’m starting to be a fan of the proper application of emotion/feeling instead of just a stoic-robotic response. Words like “curiosity” and “determined” do have some feelings attached to them. Now I’m seeing that “Urgency” is important. And that to “Create Urgency/Sound the Alarm” It may be necessary to do it by attaching the appropriate emotions, in a controlled fashion, to the cold hard facts and data. After all, we are humans.

In general, however, if the level of organization that SHOULD be able to solve the problem CAN’T solve the problem, then one of two things is true:
- The problem is harder than it looked. Countermeasure: Escalate. The escalation response is technical assistance from the higher level that now owns the problem.
- The people aren’t capable of solving a problem they should. Countermeasure: Escalate. The response is to guide and coach the people through the process so they learn how to do it themselves next time.

Note that any time a problem can’t be solved, the initial response is always the same: Escalate. This could be a literal andon call. What should never happen is that a problem goes unaddressed because “we don’t know what to do.”

There certainly are problems which are unsolvable, in cases where we have over reached our technology, for example. But those are rare, and when they occur, they should be well documented, understood and their effects contained so the downstream customers are not affected.

My question is: What are the consequences of finding out that people make errors?

Also sometimes I read books and I’m not sure if what I am thinking comes from the book or if it’s a new idea… But isn’t it a type or waste to have an “uncapable machine or person” take on a task? Which raises the responsibility training a high level of importance.

Yes we do have a “Fire Investigator”. We do find out how the problems start and we do followup and correct the source of the problem.

And we do have a system to identify an “out of spec” condition. We use a final inspection cell.

However, my comment meant to say we don’t have a “culture” throughout the plant nor an automatic system to detect problems and solve them. We are far away from having jidoka anywhere but at the very end of our many manufacturing and assembly processes.

Here’s an interesting part of our system. Almost every time we find an error in our product, we add an inspection step to insure it won’t happen again. This drives me (The Lean Manager) crazy. We are forced by our customer to come up with corrective actions. The easiest solution is to add an inspection step in the middle of the building process. I’m more inclined to use the 5 why’s and discover the true source of the error. However, by doing that I’m afraid we may find that low paid, untrained workers would usually be the true source of the error.

Thank you for your thoughts.

Continuing the analogy, a circuit breaker is a jidoka mechanism. By detecting an out-of-spec condition (too much current), it shuts down the operation before it can cause a bigger problem – a fire. In order to reset it, you have to find the cause of the short and fix it. That is an example of pushing the “problem solving” upstream and handling the issue while it is still small. Of course there is no way to do that manually, you can’t go check every circuit every day. So we devise technology to do it for us, and let us know when there is a problem. That is jidoka.

We do have a problem solving team. But it’s designed like the fire department. Simply put, when there’s a fire (big problem) we put it out.