THE TPS IS NOT A COMPLETE MANUFACTURING SYSTEM
The TPS is not a complete manufacturing system; in fact, it is only a part of a manufacturing system. To better understand what part of a manufacturing system it is, or rather what it is not, we need to return to his book for a moment. While discussing flow as the basic condition, Ohno writes,
These two sentences are so simple their significance is missed by almost everyone. However the implication to these two sentences, especially to those wishing to undertake a TPS initiative must be thoroughly understood. For example, let me paraphrase it a bit:
“From the end of WWII until 1955 we had focused our attention on improving the quality of our goods. By 1955 we thoroughly knew how to provide quality to our customers. We could discuss the key quality concerns with them, we could determine how to supply quality and we could provide it to a very high level. We used a long list of tools to achieve these communications skills but the most important two were the simple customer quality questionnaire which we statistically analyzed, of course and we also became very proficient at Quality Function Deployment (QFD). Long ago we ceased using inspection, especially visual inspections by humans, as a means of achieving quality; rather we moved to process control as a means to make the process more robust. To do this we first became proficient in data gathering and analysis using such techniques as Ishikawa outlines in his writings. Now the vast majority of our data is used for process improvement rather than product evaluation. In addition we became very proficient in a wide range of statistical techniques so we could analyze and make better decisions with our data; the four fundamental statistical techniques of Measurement System Analysis (MSA), Statistical Process Control (SPC), Designs of Experiments (DOE) plus Correlation and Regression are widely understood at even the supervisory level in our plants. We also made all levels of personnel responsible for root cause problem resolution, which means we trained them in various levels of problem solving; the “5 Whys” being the cornerstone technique. Another significant effort was the transition in our quality, process and product data. Initially, the majority of our data was attribute data on the product. We moved from a high percentage of attribute quality characteristics of the product to variables characteristics of the process. We recognized early on, that high levels of quality could not be achieved if we used attribute data; so this meant we needed to correlate the attribute defects to process parameters and we became skilled at this very early in our quality efforts. We had been very committed to providing quality products and had been working very hard on quality. With the help of Deming and a unified effort pushed by JUSE, we could supply excellent quality and our costs and losses associated with quality were very low. We had what most Westerners would call a very mature manufacturing system that could consistently produce high quality goods and deliver them on time for a reasonable price. Quality was no longer a production problem. Now we needed to look at the losses caused by producing the wrong quantities; especially the wrong quantities produced and delivered to the wrong places at the wrong times”.
If I were Ohno that is what I would have written; because that is where they were as a manufacturing company. So what Ohno built, the TPS, had a foundation of quality, but his TPS is not a quality system. Yes, it had Jidoka, but we will learn that Jidoka is there to support JIT. In addition, and as an example, Ohno makes nearly no mention of Cp and Cpk which are the two accepted measures of process capability or “process goodness”. Nearly every book you read on manufacturing and process quality reduces the concept of quality to Cp and Cpk for all measurement data; yet Ohno hardly mentions it. One has to ask why? Well, it is because of what he said --they simply could supply high level quality and quality improvements were not where they needed to focus to reach a higher level of manufacturing excellence. Their focus, as he says, was on quantity, make sure you spell that q-u-a-n-t-i-t-y.
The implication of this information, to some company which wishes to embark on the journey into Lean, is usually quite sobering. Ohno says they just spent 10 years; 10 very focused years, learning how to deliver quality, and then they embarked on the journey of quantity control. I can say with assurance that most companies who entertain the option of mimicking the TPS do not have the sound foundation which Ohno describes in his writings. After all, that is what made them Toyota and the TPS only took them farther along.
Herein lies an interesting aside. It is part of the genius of Ohno and others like him that they do not care if you try to copy them. They know that you can not unless you have undertaken and built the foundation which they had in place when they started their individual journey of quantity control.
Most think they can bypass this step and are always disappointed to find out that there are no shortcuts. If you want the benefits of the TPS; the foundational issues must be addressed. It does not mean you should not embark on the journey. I am not saying that; nor am I implying that, but in short the foundational issues must be addressed or your effort will be in vain. It is possible, with good guidance, to attack the foundational issues as well as the quantity control issues, both at the same time
To not understand this concept is dangerous…
This concept alone; specifically that the TPS is built upon a strong foundation and that one huge element of that foundation is high levels of delivered quality, is the reason that most companies fail while trying to implement a Lean initiative. I do not mean their efforts yield less than they had hoped for, I mean some downright fail.
For example I got a call from a potential client who was trying to mimic the TPS. They called me when their production rates sagged and on-time delivery had dropped below survival levels. They described their efforts as a JIT Implementation. Over the phone it took me about 2 minutes to diagnose their problems. They had tried to install a JIT system without the help of an expert. They had plunged headlong into an inventory reduction effort to improve lead times but were burdened by two major flaws. First they had only a superficial understanding of the TPS. They had in effect, a high powered rifle in the hands of a child. Second, even if they understood the basics of JIT, their system was not able to undergo inventory reductions without attacking the underlying and necessary foundational issues, principally the reduction of process variation. Consequently, the JIT system exacerbated, rather than solved their problems. My advice to them was to hire an expert, right now, to help them. They said they did not have the resources to do that. The next best recommendation I could make was to undo what they had done, returning to the method they previously had, so at least they could survive. I am not sure exactly what they did but I later learned that the business had been closed; and with it over 200 people lost their jobs.
Still others implement the TPS system and fail to achieve what the system is capable of delivering. Quite simply there are no shortcuts and to that end; shortcuts of understanding are the most devastating. So if you want to embark on any initiative, make sure that there is both a thorough understanding of the initiative as well as a commitment implementing it. (See the Five Tests of Management Commitment in Chapter 19).