The target condition at this point is simply to establish some degree of transparency of the current condition on a status board without having to resort to probing questions to elicit what is working, and what is not.

The observation was:

“We’ll know we are succeeding when we see a failure.”

In other words, “no problem is a big problem” but I think this says it just as well.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Failure as Success

We talk about 5S, separating the necessary from the unnecessary, a lot, but usually apply it to things.

What about information?

How is critical information presented?

How easy is it for people to see, quickly, what they must?

This is a huge field of study in aviation safety where people get hyper focused on something in an emergency, and totally miss the bigger picture.

This site has a really interesting example of how subtle changes in the way information is presented can make a huge difference for someone trying to pull out what is important. The context is totally different, so our challenge is to think about what is revealed here, and see if we can see the same things in the clutter of information we are presenting to our people.

The purpose of good visual controls is to tell us, immediately, what we must pay attention to. Too many of them, or too much detail – trying to present everything to everyone – has the opposite effect.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

He Should Have Seen It

In an email on the topic to a friend today, I cited four things that I think need to be there before this can be achieved. Upon reflection, I’d like to expand upon and share them. I think I can say that a lot of the failures I have seen can be traced back to only emphasizing one or two of them.

The organization must reset its definition of “a problem.”

I started to get at this mindset back in January with the post “ Chatter as Signal.”

In “traditional” organizations something is labeled “a problem” when it causes enough disruption (or annoys the right (wrong?) person). Anything that does not cross that threshold is tolerated. The “problem” with this approach is that many small issues are ignored and worked around. Their effects, though, tend to clump and cluster into larger cumulative symptoms. When those symptoms reach the threshold of pain, someone starts wanting some kind of action, but by now it is too late for simple solutions.

Another face of the same thinking is the “big problem” syndrome. “We can’t fix everything.” “We have to prioritize on the big hitters.” True enough, but it is not necessary to fix everything at once. That’s the point. Sure, prioritize the technically tough problems. But, at the same time, put the systems into place that allow everyone to work on the little ones, every day.

When the “big problem” statements are used as a “can’t do it” or “we can never be perfect” excuse, the organization’s underlying mindset has dropped into the ”

The “Chatter as Signal” attitude really means instead of putting together plans and processes and then tossing them over a wall for blind execution, the problem solving organization systematically and continuously checks “reality” (what really happens) against their “theory” (the plan, what they expect to happen). Whenever there is a difference between the two, they look at that as “a problem.”

Maybe the term “problem” is unfortunate.

A lot is made out there about being truly forward-looking organizations seeing “mistakes” as opportunities to learn. A “mistake” is nothing other than an instance of “We did this thinking some specific thing would happen, but something unexpected happened instead.” Or “We thought we could do it this way, but it turns out we couldn’t.” In different words, those events are “the outcome wasn’t what we planned” and “we couldn’t execute the process as planned.” In other words, “problems.”

In summary, specify what you intend to accomplish, how and when you intend to do it.
Any departure, necessary or inadvertent, from this specification is a problem.

The organization must have a process for immediately detecting and responding to problems.

It doesn’t do much good to define a problem unless you intend to respond. And you can’t stand and watch every second for problems to occur. That is the whole point of jidoka. When Sakichi Toyoda developed his loom, the prevailing common thinking was “sometimes the threads break.” “When that happens, some material is ruined.” “That is reality.” “Perfection is impossible.” Chatter is noise.

But Sakichi changed the dynamic when he designed a loom that detected a broken thread and shut itself down before any bad material was woven. Now I am fairly certain that, even today, threads break on weaving equipment. (And the same technology developed by Sakichi is used to detect it.) So, as a jidoka, this is a case of detecting a small problem and containing it immediately so it can be corrected.

Consider this: If the organization really understands jidoka then any problem that goes undetected is a problem. Thus, it isn’t necessary to fix it all at once. Rather, when problems occur, get back to where they occured. Look at the actual situation. What was the very first detectable departure from the intended process? It is quite likely that it is a small thing, and also likely it happens all the time. But this time it didn’t get caught and corrected.

Then ask: Can you prevent this departure from process?
If you can’t, can it be immediately and automatically corrected?
If not, can the process be stopped?

But detecting the problem is only the first step. The response is even more important. When a Team Member (or a machine) detects a problem and calls for help, a real live human needs to show up and show genuine interest. The immediate issue is simple: Fix the problem. Restore a safe operation that produces defect-free output. That may take a temporary countermeasure involving some improvisation, and may compromise speed and cost a little, but safety and quality are never compromised for anything… right?

The next step is to start the process of actually solving the problem. At a minimum, it needs to be written down and put into the “We’ll work on that” management queue (See the next item) to get solved. Note that “fixing it” and “solving it” are two completely separate things.

The organization must have a process for managing problem solving.

When a problem occurs, the first response is to detect it, then to fix (or contain) it. That is jidoka. But at some point, someone has to investigate why it happened, get to the root cause, and establish a robust countermeasure.

Again, I have talked around this in a couple of previous posts:
Systematic Problem Solving
A Systematic Approach to Part Shortages

However it is done, however, the organizations that do it well:

• Have a public written record of what problems are on the radar. The most common approach is a board of some kind in the area where the daily review takes place.
• Did I just say “Daily Review?” There is a process to check the status of ongoing problem solving activity every day. Problems being worked on do not get a chance to fall off the radar.
• They manage their talent. The organization I talked about in the “ Part Shortages” story had a lot of problems, not just in part shortages, but technical issues as well. Initially they had been assigning each problem to someone as soon as it came up. That quickly became unworkable because, in spite of their tremendous talent, the key players really couldn’t focus on more than one or two things at a time. It was demoralizing for them to get hammered at the meetings for “doing nothing” on five problems because they had been working on the other two. The countermeasure was a prioritized pull system. Each new problem went into a queue. As a problem solver became available (because s/he was done with one), the next problem on the list was assigned. The prioritization system was simple: The manufacturing manager could re-sequence the queue at any time.Thus, the problem at the top of the list — the next one to be assigned — was always the next most important. But it was another important rule that made this work. No one could be pulled off a problem s/he was already working on in favor of a “hot” problem. The only exceptions were a safety issue or a defect that had escaped the factory and had been reported by a customer. However you manage it, keep these things in mind:
  • Don’t arbitrarily multi-task your talent. People can’t multi-task. This is actually overloading. The other word for it is muri.
  • Don’t jerk them from one thing to the next without allowing them completion.
• They solve the problem at the lowest level of the organization capable of solving it. The corollary here is largely covered below, but it bears mentioning here: If the level that should be solving it isn’t capable then they work THAT problem – developing the skill – rather than ignoring the issue or overloading someone who is never going to have the time to work on it. This is probably the most important lesson in this piece.

They deliberately and systematically develop their problem solving skills at all levels.

It is easy to fall into the trap of assuming that someone with a technical degree is a skilled problem solver and critical thinker. Experience suggests otherwise. And even if there are a couple of people who just have the innate talent, there are not enough of them to go around. There are lots of approaches out there. In reality, all of the effective ones are anchored in the same thinking, they just use different tools and lingo to frame that thinking. My best advice is pick one, teach everyone to use it, then insist that they follow the process exactly. Only by doing that will you actually learn if the process itself has weakness or shortcomings.

Along with this is don’t confuse the tools with the process itself. THIS IS CRITICAL: Anything you draw on paper (or create in a computer) is a tool. The seven problem solving tools are not a process. A statistical control chart is not a process. An A3 is not a process. A cloud diagram is not a process. All of these are tools. The framework in which they are used is structured thinking, and that is a process.

This is important because the process itself is straight forward and simple. It can be taught to anyone. Teaching them the tools, however, teaches them nothing at all about how to solve problems. So many “problem solving courses” spend a week teaching people how to build Pareto charts, histograms, tree diagrams, run charts, even build control charts, and yet teach nothing at all about how to solve problems. Most problems can be solved by unsophisticated troubleshooting techniques that systematically eliminate possible causes. Some can’t, but most can.

This got long, but I guess I had a lot to say on the topic. In the background, I am planning on putting together some basic material on “the process of problem solving” and making it available. Hopefully that will help.

As always, comments are encouraged and appreciated. It tells me that someone actually reads this stuff.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Anchoring a Problem Solving Culture

When first implementing some of the tools and mechanics of the TPS (especially in a manufacturing environment), many of the initial efforts seem to run afoul of the industrial safety professionals. My experience suggests a couple of basic causes.

• Safety countermeasures are not seen as necessarily directly contributing to production of the product. Thus, they are often lumped in to “not value added” or “waste” – at least by implication, if not directly, by over-enthusiastic kaizen event leaders.
• Safety professionals can be stuck on specific countermeasures vs. looking at the actual risk and identifying other possible countermeasures.
• Safety professionals are concerned (and rightly so) about repetitive motion injury. They perceive that takt driven standard work might increase the risk of this.
• There is overall a general lack of understanding of the difference between regulatory compliance and keeping people safe. While these two things overlap, neither is necessary nor sufficient to assure the other.

Let me start with the last point since it probably raised the most eyebrows.

An industrial safety program has two distinct and discrete objectives:

1. To keep people from getting hurt.
2. To comply with all laws and regulations

As I said above, while meeting both of these objectives are absolutely necessary, meeting the requirements of one does not guarantee meeting the requirements of the other. To put it more directly -

• It is possible to be fully compliant with all health, safety and environmental regulations and still have a workplace which is extremely dangerous.
• It is possible to have a very healthy, safe and environmentally friendly workplace and still run afoul of laws and regulations.

Thus, it is necessary to ensure that each of these things are discretely addressed in any successful program.

It is important for both kaizen and safety professionals to be aware of this. Some things are simply required by law, even if they are wasteful, and sometimes interpretation is up to the whim of a local inspector who might be having a bad day. Whatever the case, for each regulatory requirement there must be a specific, targeted countermeasure, just as there must be one for each physical risk. Sometimes these things overlap, but sometimes they do not, and that is the key point here.

I will digress for a paragraph and make this point however: If you have the basics of workplace organization in place, you make a much better first impression on a health and safety inspector than if the place is a mess. If your fire department sees the fire extinguishers are all where they should be and up to date, access aisles and evacuation doors clear, etc. he is more biased toward the assumption that you have your basic act together than if the place is a mess. Everyone has some violations, but when they are blatant, simple things it starts you off with a bad impression, and inspectors usually start digging.

Moving beyond simple regulatory compliance, the objectives of “lean manufacturing” and safety are 100% congruent. Ethically it is never acceptable to knowingly put people in harm’s way for the sake of production. At a more pragmatic level, a hazardous workplace will adversely affect quality, production, cost, delivery and morale. I will not descend to the level of cost-justifying safety simply because it isn’t necessary. But it is equally true that an unsafe workplace has higher costs than a safe one.

The good news is that the kaizen process is incredibly effective at dealing with safety hazards.

Moving up on the above list, one of the biggest places where the safety professionals can help smooth out the work is with their expertise in ergonomics.

What the kaizen people should take a little time to understand is this: Motions with poor ergonomics nearly always take longer than motions with good ergonomics. To put it a little more clearly: Ergonomic improvements are kaizen. Once a good team understands the difference between good and bad ergonomics, they can quickly see many small improvements which all accumulate.

By standardizing the method, we standardize the good ergonomics. Where there are no standard methods, the Team Members will each develop their own which may, or may not, be the safest way to do the job.

Standardizing the right motions reduces the chance of repetitive motion injury. And paying attention to why unusual motions are necessary comes back to reducing variation and overload (muri, mura) in the workplace.

At the next level up, standard work is your best friend.

To develop any process you first take a good look and specify exactly what result you expect to achieve.
Define a defect-free outcome.
Part of that definition is “perfectly safe.” No one is going to argue with this. Of course you want a process that is perfectly safe, and produces a defect free outcome. Who wants the opposite? But until “defect free” and “perfectly safe” are explicitly defined or specified, there may be room for interpretation. Do this before working on the process steps.

Next define the work you believe will deliver a perfectly safe, defect-free outcome. Define the content, sequence and timing of the work.

Now you have a specification for content, sequence, timing and outcome – the four elements of activity that Steven Spear called out in “ Decoding the DNA of the Toyota Production System.”

Next – try it. Run the process exactly as you specified it. Verify two things:

• That the Team Member can perform the process as specified – there is nothing keeping him from doing it.
• That the Team Member actually does it that way and put in guides, controls, mistake-proofing where things go off track.

Check your results.
Was it perfectly safe? Did you see any risks? How are the ergonomics?
Adjust as necessary, then repeat.

Was the result defect free? How do you know? Is there a way for the Team Member (or an automatic step) to verify the result?

In practice, you are “trying it” and “checking the results” not just when you are developing the process, but every time it is done.

If a defect is produced at some point, then you know either:

• The process didn’t work as you expected.
• For some reason (which you don’t know yet), the Team Member did something different, or omitted a step.

Likewise, if the Team Member so much as skins a knuckle, you know the same things: The process is not perfectly safe or the process wasn’t (or couldn’t be) followed.

In most cases where the process was not followed you likely had a Team Member doing something in good faith to “get the job done.” This is the time to gently remind him that, when he can’t follow the process as designed, to please pull the andon and let someone know. Maybe you will have to make an exception to correct the current situation, but you HAVE to know if the process isn’t working or is unworkable.

Bottom line?
You get perfect safety exactly the same way you get perfect quality.
The methods and approach for getting it, and the methods and approach for correction and countermeasure are exactly the same.

Remember:
The right process produces the right result.

If you aren’t getting the result you want, then take a look at the process.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Safety and Lean Manufacturing

Problem solving is a process of asking questions and clarification.

Is a “defect-free” outcome of the process specified? Does the Team Member know what “success” is?
Is there a way for the Team Member to actually verify the result?
Does that check give the Team Member a clear Yes/No; Met/Not Met; Pass/Fail response? Or is there interpretation and judgment involved?

If there is good specification for “defect-free” – is there a specification for how to achieve it? Do you know what must be done to assure the result that you want? Does the Team Member know? Is the Team Member guided through the process? Are there verifications (poka-yoke, etc) at critical points?

If all of the above is in place, do you know what conditions must be in place for success? What is the minimum pressure for your air tools? Is there a pressure gage? Does it cut off the tool if the pressure is too low? Is there some visual check that all of the required parts, pieces, tools are there before work starts? Thank about the things you assume are there when the Team Member gets started.

For ALL OF THE ABOVE, if something isn’t right, is there a clear, unambiguous way to alert the Team Member immediately?
Is there a clear way for the Team Member to alert the chain-of-support that something isn’t right?

If there is a defined result, a defined process to achieve it, and all of the conditions required for success are present -
Is the Team Member alerted if he deviates from the specified process, or if a critical intermediate result is not right?
More poka-yoke.

Now you have the very basics for consistent execution.

Is the process carried out as you expect?
Is the result what you expected?

If not, then the process may be clear, but it clearly does not work. Stop, investigate. Fix it.

All of this is about getting more and more about what is SUPPOSED to happen and compare it to what is REALLY happening… continuously. I say continuously because “continuous improvement” does not happen unless there is continuous checking and continuous correction and problem solving. If you want “continuous improvement” you cannot rely on special “events” to get it. It has to be embedded into the work that is done every day.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Attack on Ambiguity

In the “Bad Apple” theory there is an implied assumption that the cause of an accident or other problem was one person who, at that moment in time, was not following the documented rules or procedures.

Except in the most egregious cases, such as deliberate misconduct, that is likely not the case. Most organizations have a set of “norms” that operate at some level of violation of the written or established procedures. The reasons for this are many, but usually it is because good people are doing the best they can, in the conditions they are given, to get the job done.

Failure to follow the rules does not result in an accident or incident.

Have you every run a red light or a stop sign? It happens thousands of times every day. It almost never results in an accident. Only when other contributing conditions are ripe will an accident result. Running a stop sign AND a car coming through the intersection.

The same goes for quality checks, and the more reliable an “almost 100%” process becomes, the more vulnerable you are. If a defect is only rarely produced, it is unlikely that any kind of human-based inspection will catch it. The faster the work cycle, the more this is true. The mind numbs, it is impossible to always pay attention to the detail, and the mind sees what it expects. “Failure to pay attention” is never an adequate root cause. It is blaming an unlucky Team Member for an omission that everyone makes every day just going through life. It is just, in this case, “there was a car coming through the intersection.” It is bad luck. It is being blamed for red beads in Deming’s paddle experiment.

So attaching the failure of an individual, while it is easy, avoids the core issue:

People’s failure in critical processes is a SYSTEM PROBLEM. You must investigate from the viewpoint of the person at the pointy end. What did he see? What did he perceive? What did he believe was happening and why was that belief reasonable given his interpretation of the circumstances at the time.

The post about “sticky visual controls” got to this. Your mistake-alerts or problem signals must penetrate conciousness and demand attention if they do not actually shut down the process.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

What Nukes – a little more clear.

For future reference after the link dies, the lead of the story is:

A fire at an illegal shoe factory in eastern China has left 34 people dead..

That, by the way, is a great lead. It summarizes the whole thing in a few words:

• China
• illegal factory
• fire
• 34 dead

The rest is just syntax glue. But, as usual, I digress. What the hell is the point?

Just to be clear, by the way, the original breaking-news story in no way implies that this factory was producing for export, or for that matter, for any other company. So the story is just a lead-in for this post.

Back to the lead of this article: What is your obligation, as a purchasing company, to consider things other than quality, delivery, cost in your sourcing decision?

With the rush to source in China, it is very easy to overlook even obvious things like quality. Just ask Mattel. But if gross violations of China’s internal health, safety and environmental regulations give a potential supplier a cost advantage, do you know it? Do you make a conscious decision to let that “advantage” stand? Or do you go and look for yourself, and include only suppliers which comply with the letter and the spirit of the law – as well as “do the right thing?”

Chinese health, safety and environmental regulations, by the way, are in many cases stricter than what you find in the USA or Europe. Compliance and enforcement, though, is… ah… spotty.

This is, in my mind, an ethical decision, not a legal or financial one. I can only raise the question and let you answer it in your own mind.

One more thing. This was reported on the BBC. The only way I can read BBC news on the internet in China is to go through my corporate VPN. If you try to access BBC News on a normal internet connection, you will get a “Server not responding” error because BBC is not considered appropriate for the Chinese people to read. Frankly, it seems a little arbitrary since every other news service is more or less accessible. Maybe I will start another blog sometime and just talk about “other stuff.”

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Supplier Selection: Beyond Quality, Delivery, Cost