Lean Manufacturing

While I would like to think that all of my blog posts are important to someone, the fact is that most of you cannot find any direct link between your lean battle and what an Irish minister had to say about quality, or whether Delphi won another Shingo prize or not.  This post, however, is important - if you are trying to get your plant or your company leaner, then you need to know this.

I have all the respect in the world for Mike Wroblewski over at Get Boondoggle, and for Mark Graban at the Lean Blog, but today Mike posted a piece called Kaizen Priorities, which Mark endorsed. (Note Mark's comment below)  In spite of that respect, I cannot agree.  Only my opinion, of course, but please hear me out.  Mark is attempting to put a rest to the nonsense and chaos that swirls around lean and six sigma about where to focus kaizen activities.  The shotgun approach is rightfully criticized, and both kaizen events and six sigma have a sad track record of generating great improvements, in theory, that cannot find their way to the bottom line.  Mark's solution is to suggest a combination of priorities, including resolving bottlenecks and going after big or easy opportunities.  It is easy to see the logic behind that recommendation.  It misses the central point of the Toyota Production System, however. 

To Art Smalley's point that he has so clearly and with great authority made in his two recent articles - Lean and The Law of Unintended Consequences and TPS vs Lean - Additional Perspectives, this solution clearly smacks of starting with a tool kit, then looking for a problem that fits it.  Most important, it ignores the core lessons Taichi Ohno and Shigeo Shingo preached over and over ad nauseum.  Nowhere do either of them say to go out and look for bottlenecks, nor do they say to go look for cost savings opportunities in major product lines, or for easy improvements.  For that matter, they did not say to create a quality improvement project or a customer satisfaction improvement project for every cost reduction project you start, as my friends in the Six Sigma world did last week in Las Vegas.  These are all latter day, American ideas that well intentioned, intelligent people have conjured up to figure out the best way to use the tools.  The problem is that there is no significant, long term lean manufacturing success story that was built on any of this.

There is a long term success that was built on Ohno and Shingo's message - Toyota.

Here's the deal: Inventory and cycle time have a direct relationship to each other.  Inventory is simply the manifestation - the visible, physical result - of cycle time.  The focus of the Toyota Production System is the reduction of cycle time. I have put this quote from Ohno in several blog posts, and built my book around it:

"All we are doing is looking at the time line, from the moment the customer gives us an order to the point where we collect the cash.  And we are reducing the time line by reducing the non-value adding wastes."

Using the Toyota tools to improve something other than the time line - operations costs, defects, machine reliability, or anything else - does not necessarily add much to manufacturing.  For those of you under the age of 40, please understand that prior to Toyota and lean, we may not have been great manufacturers (it was hard what with all the dinosaurs walking around), but we were not stupid.  We knew all about bottlenecks and defects.  You say 'kaizen', we said 'cost reduction project'. Couching it in Japanese terms, involving the production workers more and laying it all out on an LEI approved Value Stream Map form is not really that much of an improvement over the old ways.

But what Ohno said changes everything.  He said go after the cycle time.  In fact, the system was defined as the "simultaneous improvement [reduction] of time and space".  That is what is new and powerful about TPS - not the tools.  When Motorola first developed Six Sigma, it was built on a mathematical interpretation of this cycle time principle.  You have also read often in my writing that Mot's principle was that the "best quality producer is the shortest cycle time producer, and the shortest cycle time producer is always the best cost producer." In bringing this to life in their factories, they focused on the mathematical notion of variability.  The variability in a process has a direct, linear relationship to the cycle time of the process - the greater the variability at any point, the more inventory is needed to buffer the rest of the process from the impact of that variability.  Toyota's principle was that there is also a direct relationship between variability and waste - or excess cost.

To find the greatest waste elimination opportunity - look for the greatest variability.  To find the greatest variability - look for the greatest block of cycle time.  That logic will take you to the target for your kaizen, or six sigma, or whatever you want to name your project.  The power of this is that it leads you to great cost reduction areas that the accounting system misses - things like overly long set ups, or quality problems, or poor plant layout and excessive material handling costs.  This is the great power of lean - not the tools.

Where Just In Time fits into all of this is in the variability calculation.  Any stumble bum manufacturer can be linear when measured in monthly terms.  Output for a given product per month from a machine, or a process or a plant is usually a pretty straight line.  Take that down to output per week and the lines on the graph start to get a little squiggly. Take it down to output for any one product per day, then down to output per hour and the lines are incomprehensible.  Those lines are showing the variability, and the waste elimination opportunities.

For instance, the yield from a machine may be a steady 98% per month.  It may even be a steady 98% per week.  But at the daily level, the graph shows 49 consecutive days of 100% yield, then a day of 0%, then 49 more at 100%, etc... That huge variability drives the plant to buffer production with a days worth of inventory in order to protect itself from the random 0% days.  That day's worth of inventory pushes cycle time out by a day.

The TPS is simply that in reverse: Chart the process and calculate the cycle time.  Go through the Why?, Why?, Why? etc... routine until you know why the days worth of inventory is there.  Reach into the TPS toolbag and pull out the stick needed to kill the quality snake, get rid of the inventory (along with the cost and space it was sucking up), then start hunting for the next biggest block of cycle time in the process.

Continuous Improvement means continuous compression of cycle time, at least that what Ohno thinks, and I am not about to argue with him.  The decay of Six Sigma from Motorola's heady days was the result of taking the tools for analyzing and eliminating variability out of the cycle time context in which it was originally conceived.  Taken out of context, the TPS tools and the Six Sigma tools are inevitably applied to problems as seen through the crappy old cost system we all use.  All it knows is direct labor - so these tools become weapons for laying people off.  It may come as news to many, but we did not need Toyota or Six Sigma to tell us how to find ways to lay people off.  We had that to an art form long before Toyota came along.  When the tools are used to improve overhead cost in the old structure, those are all part of an invisible allocation mess and the savings, if they actually occurred, can never be traced.

The power of cycle time compression is that it forces cost reduction, quality improvement, inventory reduction and delivery performance improvements at the same time.  The tools applied outside of a cycle time framework, often result in trade offs - lower costs with more inventory, better quality with higher costs, etc...

There is a chart that lays this out on my web site.  Click here to get it - print it out, study it, send me as many emails as you need to asking as many questions as you have to, but please understand this very fundamental point. Better yet - get a copy of Shingo's 'Green Book' - the original Study of Toyota Production System from Industrial Engineering Viewpoint.  Suffer through the wretched translation and you will find it all there.

And by the way, just about all of my writing flows from this point ... the Irish Minister was wrong about quality because she was advocating taking quality improvement out of the cycle time context and allowing trade offs between cost and quality; Delphi won its Shingo Prizes becasue they deployed all of the lean tools beautifully - but to the old system instead of to cycle time compression, and they too got tradeoffs resulting in nothng to the bottom line.  Applying the tools to the old system yields 'Looking Lean'.  Applying the tools to Ohno's time line yields 'Being Lean'.

... and one last note - The reason I hammer on accounting, and work so hard to push lean accounting, is that lean accounting is essentially putting the company on a cash flow basis, instead of one in which inventory is an asset.  When the financial system drives the plant towards improving cash flow, all of the hidden costs of excess cycle time come to light and the financial benefits of Ohno's wisdom become crystal clear.

Comments

[Mark Graban]

Bill - sure I told Mike "great post", but I think you accidentally mischaracterized Mike's recommendations of where to focus kaizen as mine.

Bill Waddell's Note:

You are quite right Mark. A compliment and an endorsement are two different things. My aplogies for mischaracterizing the courtesy you showed Mike.

[Mark Graban]

No worries. Keep up the great work with the blog.

[Russ Messmann]

Have any recommendations on some lit. for accounting practices for lean businesses?

[Clyde Parker]

It's refreshing to hear someone tell it like it is. This article makes GREAT SENSE to me. What perception!

[Carl]

Great post Bill. The biggest problem I see with all of the failures is the attempt to fit tools to the problem, or solving the problem one way and claiming it was solved using lean, six sigma, or any other tool.

A kaizen event, lean process, or six sigma project will solve the problem and hit the bottom line if they were the right tool to use.

Too many consultants try to fit the tool to the problem. A six sigma guy tries to solve it all with six sigma tools. Too often the improve phase does not include the lean tools necessary to solve many problems.

When we define the problem first, then use the right tool to solve it, a kaizen event will produce wonderful results. If the kaizen needs a physicist to utilize a mathematical model, then that is what should be used. If it needs an in depth oee analysis, then that should be done.