Dear Gemba Coach,
Since Toyota formulated TPS 50 years ago, many other companies have come up with their own business systems ñ I have been taught the Nissan Production Way. Why do you lean experts still revere the Toyota Production System? Hasn’t any one come up with something better? Is this just conservatism or ideology or do you actually have a reason to stick with TPS?
Wow! Bonus points for a challenging take-no-prisoners question! I have no direct experience of the Nissan Production Way but, having personally contributed to building several such systems in various companies, I think I understand where youíre coming from. If, in the same lapse of time, Microsoft has replaced IBM as a reference, Apple has replaced Microsoft, and now Google or Amazon are dethroning Apple ñ why wouldnít the same evolution be likely in Production Systems? Iíve had to think carefully about this, and take into account that as one of the ìyou lean expertsî I am probably biased, and as resistant to cognitive dissonance as the next man, so what is the test method that would make my answer valid and not just an expression of wishful thinking that TPS remains a gold standard for lean.
The question, as I grasp it is: what is so unique about the Toyota Production System that it remains a standard for lean as opposed to either more recent evolutions such as the Nissan Production Way or alternative directions such as Lean Startup?
First, letís clarify what weíre talking about. There are many paper versions of the TPS mostly involving customer satisfaction, just-in-time, jidoka and standardization/kaizen in some order or other. Some versions include employee satisfaction and mutual trust, earlier versions have the twin pillars of just-in-time and automation with a human touch resting on the base of load-smoothing production, with respect for humanity in the center, and so forth. But to me these paper systems do not accurately describe my experience of TPS with time spent on the gemba with a sensei to look into the details of visualization, problem identification, and kaizen activities.
TPS is not something you know, itís something you do. As Art Smalley translates, one of TPSís principal founders, Taiichi Ohno describes it as ìa series of related activities aimed at the elimination of waste in order to reduce cost, improve quality and improve productivity.î He explicitly states that it is about developing the scientific mindset of starting with actual phenomena of the shop floor and searching for root causes in order to solve the problem. This is rather specific and highlights the fact that the Toyota Production System is most definitely not Toyotaís system of production. Toyotaís production practices are the outcome of TPS activities, NOT TPS itself.
A System of Questions
Which brings me to what I still consider distinctive in TPS. To my mind, TPS is a system of questions supporting the essential gemba question of ìwhy?î Itís not random questioning †and itís nothing to do with applying principles, no matter how lofty. Itís a practice to teach you to ask the right question in specific circumstances. My way of reading the TPS ìtempleî would be:
- What is our current level of customer satisfaction and how to improve it?
- What is our current level of just-in-time and how to improve it?
- What is our current level of jidoka in terms of how good are we at distinguishing OK from not-OK at every step of the process?
- What is our current adherence to work standards and how much kaizen are we doing ?
- How satisfied are our employees in terms of do they feel engaged in their work, involved with their teams and other colleagues, and can we develop higher mutual trustetween employees and management?
As a system of knowledge, this makes TPS quite unique. Knowledge is not held in the form of answers such as ìin this situation, to obtain this, do that,î but in the form of targeted questions such as ìin this situation, to seek this, answer this question.î For instance, on the shop floor if youíre trying to improve flow, itís very, very different to say:
- To improve flow the number of kanban cards in the system should be X
Or:
- To improve flow cut the shop stock in half
Both statements will lead to specific knowledge about the flow of parts, but in completely different ways and, in actual practice, to very different answers.
And a Hierarchy of Questions
I was recently asked for my opinion on a very elaborate IT system to run the shop through e-kanban ñ with significant performance improvement results ñ and I realized I didnít have an opinion because my understanding of kanban is as a support to kaizen, not as an operational method to schedule production. To my mind, kanban is the ultimate tool to reduce the level of the water in the lake and make the problems appear, and then hit the problems with kaizen activities involving the people running production themselves.
Itís a system of questions inasmuch as there is a hierarchy of questions. For instance, how to improve the level of just-in-time? Say, from just-in-time within the week to just- in-time within the day, will then break down into: How to improve the level of load-smoothing? How to get batches closer to takt time? How to reduce the number of breaks in the flow (points where inventory accumulates)? How to tighten up the pull system?
Furthermore, itís also a system inasmuch as the questions are interrelated: how is possible to do use kanban without identifying bad parts at each part of the process? How is it possible to improve jidoka without going to single-piece-flow? How can we maintain single-piece-flow and jidoka without standardized work? How can standardized work exist without takt or specifying the standard stock of 1 or zero parts? And so on.
Is this original? Yes, very. Maybe even unique. My background is in sociology and theory of knowledge and the most common take on knowledge is the so-called ìtripartiteî approach: since Plato we tend to see knowledge as ìjustified true beliefsî:
- If one doesnít believe a thing, one clearly cannot know it;
- No matter how sincere or well justified a belief, if itís plain wrong it cannot be considered as knowledge;
- Itís not enough to consider intently that something is true, one also needs to have a good reason to think so ñ lucky guesses arenít knowledge. Indeed, changes in justification systems have had paradigm-shifting impacts on what we consider to be true, from cave-man mysticism, to religion, to Newtonian science, to modern science, etc.
As a result, as far as I know, we tend to think of systems of knowledge as systems of answers. The knowledge management craze of the 1990s was all about making explicit every implicit knowledge, and capturing it in a computer. This probably happened in an unexpected way with the advent of the web where we now have access not just to one answer, but to any oneís answer with a strong enough opinion to go to the trouble of posting it.
What I havenít come across so far is a system of knowledge based on specific questions. Science has clearly moved that way as modern scientists well recognize that facts have a half-life and that questions are more interesting than answers. For instance, we, as yet, have absolutely zero answer to the puzzle of where (or what) is all the dark matter in the universe but the question keeps motivating thousands of scientists and big money research programs. But in business thinking what is mostly on offer are systems of questions, complete with To Do lists and roadmaps ñ the lean movement has indeed spewed a few, and Iíve been guilty of doing so myself on several occasions.
Learning to Learn
Your question is very helpful in highlighting the profound misunderstanding of seeking answers from TPS if Iím indeed correct and what it holds is kaizen questions. This misalignment would explain many mishaps in the lean field. It would also explain why it is so difficult for ìus lean guysî to implement John Shookís vision of ìlearning to learn.î The hypothesis Iím proposing to you is that the key to learning to learn is not to accumulate answers (this is unavoidable, thatís how the mind works), but to become truly expert at what questions to ask.
Seeing TPS as a system of questions would also shed an interesting light on another puzzle Iíve encountered in 20 years of studying lean: how different Toyota plants are to each other. The main elements are there, certainly, such as the andon, the visual management, the precise internal logistics, but beyond that, each plant definitely has a personality of its own and many good practices of one wonít be found in the other and vice versa. Local answers to the same question will give similar, but differing answers.
Questions can be very powerful tools. For instance, one CEO of a high-tech company I know now uses the jidoka question of ìwhat is your test method to determine the quality of parts I make for you?î as the basis of his discussions with his customers, which has greatly improved the quality of his exchanges with his counterparts (either they know and they see that he is serious about quality, either they donít and that is a good contractual topic to start working on at the outset.) Questions also explain why standards are local, expressed in the form of trade-off curves and why standardization does not mean uniformization. The same question can have different answers according to what specific situation one finds oneself ñ industrial knowledge is far more specific than weíd think.
As a system of questions I believe that TPS remains unrivaled probably because no one else has quite looked at knowledge in this very unique way. Thank you again for asking this tough question, because whatever your answer is, it has certainly made me think long and hard, and I now look at many things in a different light. ìAsking ìwhy?î might go much deeper than I even imagined.
