I recently read an article (a case study) about “Lean Six Sigma” in a publication. It’s not online, so I can’t link to it, nor do I really want to call them out by name.
I didn’t like the article, in part, because it used the old, tired (and wrong) idea that “Six Sigma is for quality” and that Lean is only about “faster and cheaper.”
Good gravy, how do people NOT realize that the Toyota Production System and Lean are about both flow AND quality? For direct evidence that Lean/TPS is about both, see Toyota’s website on “jidoka” and “just in time.”) The article I read is, unfortunately, an example of L.A.M.E. or “Lean As Mistakenly Explained.”
The article talks about a scenario where a city government wants to reduce traffic accidents at one particular intersection. Since an accident is a “defect,” they called on the Six Sigma belts to gather data do a bunch of statistical analysis (assuming, it seems, that a quality problem must be the domain of Six Sigma). It took time and a bunch of meetings to plan for this formal exercise. It’s a “hard problem” that’s “hard to solve,” the author said.
The Six Sigma team went to the intersection and collected timing and data on the lights and traffic.
After some time, their collected data and analysis showed a problem:
“Anna conducted a cycle-time analysis of the data hoping to uncover patterns that might explain the accidents. Although she didn’t find any patterns, she did notice that in several cases, the time deltas were negative. Knowing that cycle-times can’t be negative, she at first questioned her team to see if they had entered their data incorrectly. She had each of them switch to a different corner and collect times again. Again, negative durations appeared in the analyzed data. The measurement system was working correctly; something else had to explain the negative times.”
They were, apparently, spending more time looking at the measurement system analysis than the actual traffic.
Why did the data show a problem that they couldn’t figure out? The Black Belt finally out and used her eyes. “Go and see,” we say in the Lean/TPS world…
The negative numbers were occurring because, occasionally, one light would turn green about 2 seconds before the cross traffic light turned red. I.e., both directions of traffic were momentarily seeing a Green light and proceeding into the intersection and, thus, colliding with another vehicle.
Read that again. The accidents were happening because, for two seconds, BOTH directions had a GREEN light. Of course there were accidents.
This is the power of Lean problem solving, illustrated (eventually) by a Six Sigma Black Belt:
- Go to the actual place (get away from the statistic software and go the actual intersection, which they did originally, but not really)
- Observe with your eyes (really observe carefully and deeply)
- Talk to the people involved (could they have interviewed some accident victims who might have both said “but I had the green light!”?)
Maybe this is using the benefit of hindsight… but did it really require lots of data collection and time and discussion to discover the source of the problem?
Did this really require Six Sigma? Was this really such a hard problem?
What was the cost of the two weeks spent with the statistical analysis and data collection? “Five serious accidents” occurred in the two weeks people were standing there collecting data instead of really seeing the problem with their own eyes. These are five serious accidents that could have been avoided had this been solved faster.
The author didn’t follow his own advice in this case study, it seems:
“…requirement of a good Six Sigma project, that we have a hard problem that others have tried to solve but failed, has been satisfied. If there were a reasonable known solution available, the city should implement it first before considering a Six Sigma project.”
In the case study, the city council says the problem had been around for a long time and they’ve talked about it… yet they jumped right to the more complex Six Sigma approach.
I guess there are many ways to solve a problem. I’m not opposed to the statistical methods that are part of Six Sigma. I’m in general agreement with Toyota when they say it’s great to give everybody training in the “seven basic QC tools,” but they don’t have formal Six Sigma people or “belts.”
Six Sigma is incredibly helpful for really complicated problems.
But, what I *am* opposed to is inaccurate definitions of Lean that tend to come from “Lean Sigma” folks (like “Lean is just about speed and efficiency”).
I’m also against overly-complicated and slow problem solving methods that relies too much on experts and math when your feet and your eyes would suffice.
It makes me think of the famous Taiichi Ohno quote:
“Data is, of course, important in manufacturing,” he often remarked, “but I place greatest emphasis on facts.”
About LeanBlog.org: Mark Graban is a consultant, author, and speaker in the “lean healthcare” methodology. Mark is author of the Shingo Award-winning books Lean Hospitals and Healthcare Kaizen, as well as The Executive Guide to Healthcare Kaizen. Mark is also the VP of Customer Success for the technology company KaiNexus. He lives in San Antonio, Texas.