Toyota's reputation for sustaining high product quality is legendary. But the company's methods are not secret. So why can't other carmakers match Toyota's track record? HBS professor Steven Spear says it's all about problem solving.
When HBS professor Steven Spear recently released an abstract on problem solving at Toyota, HBS Working Knowledge staffer Sarah Jane Johnston e-mailed off some questions. Spear not only answered the questions, but also asked some of his own—and answered those as well.
Sarah Jane Johnston: Why study Toyota? With all the books and articles on Toyota, lean manufacturing, just-in-time, kanban systems, quality systems, etc. that came out in the 1980s and 90s, hasn't the topic been exhausted?
Steven Spear: Well, this has been a much-researched area. When Kent Bowen and I first did a literature search, we found nearly 3,000 articles and books had been published on some of the topics you just mentioned.
However, there was an apparent discrepancy. There had been this wide, long-standing recognition of Toyota as the premier automobile manufacturer in terms of the unmatched combination of high quality, low cost, short lead-time and flexible production. And Toyota's operating system—the Toyota Production System—had been widely credited for Toyota's sustained leadership in manufacturing performance. Furthermore, Toyota had been remarkably open in letting outsiders study its operations. The American Big Three and many other auto companies had done major benchmarking studies, and they and other companies had tried to implement their own forms of the Toyota Production System. There is the Ford Production System, the Chrysler Operating System, and General Motors went so far as to establish a joint venture with Toyota called NUMMI, approximately fifteen years ago.
However, despite Toyota's openness and the genuinely honest efforts by other companies over many years to emulate Toyota, no one had yet matched Toyota in terms of having simultaneously high-quality, low-cost, short lead-time, flexible production over time and broadly based across the system.
It was from observations such as these that Kent and I started to form the impression that despite all the attention that had already been paid to Toyota, something critical was being missed. Therefore, we approached people at Toyota to ask what they did that others might have missed.
We concluded that Toyota has come up with a powerful, broadly applicable answer to a fundamental managerial problem.
— Steven J. Spear
What did they say?
To paraphrase one of our contacts, he said, "It's not that we don't want to tell you what TPS is, it's that we can't. We don't have adequate words for it. But, we can show you what TPS is."
Over about a four-year period, they showed us how work was actually done in practice in dozens of plants. Kent and I went to Toyota plants and those of suppliers here in the U.S. and in Japan and directly watched literally hundreds of people in a wide variety of roles, functional specialties, and hierarchical levels. I personally was in the field for at least 180 working days during that time and even spent one week at a non-Toyota plant doing assembly work and spent another five months as part of a Toyota team that was trying to teach TPS at a first-tier supplier in Kentucky.
What did you discover?
We concluded that Toyota has come up with a powerful, broadly applicable answer to a fundamental managerial problem. The products we consume and the services we use are typically not the result of a single person's effort. Rather, they come to us through the collective effort of many people each doing a small part of the larger whole. To a certain extent, this is because of the advantages of specialization that Adam Smith identified in pin manufacturing as long ago as 1776 in The Wealth of Nations. However, it goes beyond the economies of scale that accrue to the specialist, such as skill and equipment focus, setup minimization, etc.
The products and services characteristic of our modern economy are far too complex for any one person to understand how they work. It is cognitively overwhelming. Therefore, organizations must have some mechanism for decomposing the whole system into sub-system and component parts, each "cognitively" small or simple enough for individual people to do meaningful work. However, decomposing the complex whole into simpler parts is only part of the challenge. The decomposition must occur in concert with complimentary mechanisms that reintegrate the parts into a meaningful, harmonious whole.
This common yet nevertheless challenging problem is obviously evident when we talk about the design of complex technical devices. Automobiles have tens of thousands of mechanical and electronic parts. Software has millions and millions of lines of code. Each system can require scores if not hundreds of person-work-years to be designed. No one person can be responsible for the design of a whole system. No one is either smart enough or long-lived enough to do the design work single handedly.
Furthermore, we observe that technical systems are tested repeatedly in prototype forms before being released. Why? Because designers know that no matter how good their initial efforts, they will miss the mark on the first try. There will be something about the design of the overall system structure or architecture, the interfaces that connect components, or the individual components themselves that need redesign. In other words, to some extent the first try will be wrong, and the organization designing a complex system needs to design, test, and improve the system in a way that allows iterative congruence to an acceptable outcome.
The same set of conditions that affect groups of people engaged in collaborative product design affect groups of people engaged in the collaborative production and delivery of goods and services. As with complex technical systems, there would be cognitive overload for one person to design, test-in-use, and improve the work systems of factories, hotels, hospitals, or agencies as reflected in (a) the structure of who gets what good, service, or information from whom, (b) the coordinative connections among people so that they can express reliably what they need to do their work and learn what others need from them, and (c) the individual work activities that create intermediate products, services, and information. In essence then, the people who work in an organization that produces something are simultaneously engaged in collaborative production and delivery and are also engaged in a collaborative process of self-reflective design, "prototype testing," and improvement of their own work systems amidst changes in market needs, products, technical processes, and so forth.
It is our conclusion that Toyota has developed a set of principles, Rules-in-Use we've called them, that allow organizations to engage in this (self-reflective) design, testing, and improvement so that (nearly) everyone can contribute at or near his or her potential, and when the parts come together the whole is much, much greater than the sum of the parts.
What are these rules?
We've seen that consistently—across functional roles, products, processes (assembly, equipment maintenance and repair, materials logistics, training, system redesign, administration, etc.), and hierarchical levels (from shop floor to plant manager and above) that in TPS managed organizations the design of nearly all work activities, connections among people, and pathways of connected activities over which products, services, and information take form are specified-in-their-design, tested-with-their-every-use, and improved close in time, place, and person to the occurrence of every problem.
That sounds pretty rigorous.
It is, but consider what the Toyota people are attempting to accomplish. They are saying before you (or you all) do work, make clear what you expect to happen (by specifying the design), each time you do work, see that what you expected has actually occurred (by testing with each use), and when there is a difference between what had actually happened and what was predicted, solve problems while the information is still fresh.
That reminds me of what my high school lab science teacher required.
Exactly! This is a system designed for broad based, frequent, rapid, low-cost learning. The "Rules" imply a belief that we may not get the right solution (to work system design) on the first try, but that if we design everything we do as a bona fide experiment, we can more rapidly converge, iteratively, and at lower cost, on the right answer, and, in the process, learn a heck of lot more about the system we are operating.
You say in your article that the Toyota system involves a rigorous and methodical problem-solving approach that is made part of everyone's work and is done under the guidance of a teacher. How difficult would it be for companies to develop their own program based on the Toyota model?
Your question cuts right to a critical issue. We discussed earlier the basic problem that for complex systems, responsibility for design, testing, and improvement must be distributed broadly. We've observed that Toyota, its best suppliers, and other companies that have learned well from Toyota can confidently distribute a tremendous amount of responsibility to the people who actually do the work, from the most senior, expeirenced member of the organization to the most junior. This is accomplished because of the tremendous emphasis on teaching everyone how to be a skillful problem solver.
How do they do this?
They do this by teaching people to solve problems by solving problems. For instance, in our paper we describe a team at a Toyota supplier, Aisin. The team members, when they were first hired, were inexperienced with at best an average high school education. In the first phase of their employment, the hurdle was merely learning how to do the routine work for which they were responsible. Soon thereafter though, they learned how to immediately identify problems that occurred as they did their work. Then they learned how to do sophisticated root-cause analysis to find the underlying conditions that created the symptoms that they had experienced. Then they regularly practiced developing counter-measures—changes in work, tool, product, or process design—that would remove the underlying root causes.
Sounds impressive.
Yes, but frustrating. They complained that when they started, they were "blissful in their ignorance." But after this sustained development, they could now see problems, root down to their probable cause, design solutions, but the team members couldn't actually implement these solutions. Therefore, as a final round, the team members received training in various technical crafts—one became a licensed electrician, another a machinist, another learned some carpentry skills.
Was this unique?
Absolutely not. We saw the similar approach repeated elsewhere. At Taiheiyo, another supplier, team members made sophisticated improvements in robotic welding equipment that reduced cost, increased quality, and won recognition with an award from the Ministry of Environment. At NHK (Nippon Spring) another team conducted a series of experiments that increased quality, productivity, and efficiency in a seat production line.
What is the role of the manager in this process?
Your question about the role of the manager gets right to the heart of the difficulty of managing this way. For many people, it requires a profound shift in mind-set in terms of how the manager envisions his or her role. For the team at Aisin to become so skilled as problem solvers, they had to be led through their training by a capable team leader and group leader. The team leader and group leader were capable of teaching these skills in a directed, learn-by-doing fashion, because they too were consistently trained in a similar fashion by their immediate senior. We found that in the best TPS-managed plants, there was a pathway of learning and teaching that cascaded from the most senior levels to the most junior. In effect, the needs of people directly touching the work determined the assistance, problem solving, and training activities of those more senior. This is a sharp contrast, in fact a near inversion, in terms of who works for whom when compared with the more traditional, centralized command and control system characterized by a downward diffusion of work orders and an upward reporting of work status.
And if you are hiring a manager to help run this system, what are the attributes of the ideal candidate?
We observed that the best managers in these TPS managed organizations, and the managers in organizations that seem to adopt the Rules-in-Use approach most rapidly are humble but also self-confident enough to be great learners and terrific teachers. Furthermore, they are willing to subscribe to a consistent set of values.
How do you mean?
Again, it is what is implied in the guideline of specifying every design, testing with every use, and improving close in time, place, and person to the occurrence of every problem. If we do this consistently, we are saying through our action that when people come to work, they are entitled to expect that they will succeed in doing something of value for another person. If they don't succeed, they are entitled to know immediately that they have not. And when they have not succeeded, they have the right to expect that they will be involved in creating a solution that makes success more likely on the next try. People who cannot subscribe to these ideas—neither in their words nor in their actions—are not likely to manage effectively in this system.
That sounds somewhat high-minded and esoteric.
I agree with you that it strikes the ear as sounding high principled but perhaps not practical. However, I'm fundamentally an empiricist, so I have to go back to what we have observed. In organizations in which managers really live by these Rules, either in the Toyota system or at sites that have successfully transformed themselves, there is a palpable, positive difference in the attitude of people that is coupled with exceptional performance along critical business measures such as quality, cost, safety, and cycle time.
Have any other research projects evolved from your findings?
We titled the results of our initial research "Decoding the DNA of the Toyota Production System." Kent and I are reasonably confident that the Rules-in-Use about which we have written are a successful decoding. Now, we are trying to "replicate the DNA" at a variety of sites. We want to know where and when these Rules create great value, and where they do, how they can be implemented most effectively.
Since we are empiricists, we are conducting experiments through our field research. We are part of a fairly ambitious effort at Alcoa to develop and deploy the Alcoa Business System, ABS. This is a fusion of Alcoa's long standing value system, which has helped make Alcoa the safest employer in the country, with the Rules in Use. That effort has been going on for a number of years, first with the enthusiastic support of Alcoa's former CEO, Paul O'Neill, now Secretary of the Treasury (not your typical retirement, eh?) and now with the backing of Alain Belda, the company's current head. There have been some really inspirational early results in places as disparate as Hernando, Mississippi and Poces de Caldas, Brazil and with processes as disparate as smelting, extrusion, die design, and finance.
We also started creating pilot sites in the health care industry. We started our work with a "learning unit" at Deaconess-Glover Hospital in Needham, not far from campus. We've got a series of case studies that captures some of the learnings from that effort. More recently, we've established pilot sites at Presbyterian and South Side Hospitals, both part of the University of Pittsburgh Medical Center. This work is part of a larger, comprehensive effort being made under the auspices of the Pittsburgh Regional Healthcare Initiative, with broad community support, with cooperation from the Centers for Disease Control, and with backing from the Robert Wood Johnson Foundation.
Also, we've been testing these ideas with our students: Kent in the first year Technology and Operations Management class for which he is course head, me in a second year elective called Running and Growing the Small Company, and both of us in an Executive Education course in which we participate called Building Competitive Advantage Through Operations.
· · · ·
Steven Spear is an Assistant Professor in the Technology and Operations Management Unit at the Harvard Business School.
------------------------------
HBS Working Knowledge Close Up
Developing Skillful Problem Solvers: Introduction
Steven Spear
Within TPS-managed organizations, people are trained to improve the work that they perform, they learn to do this with the guidance of a capable supplier of assistance and training, and training occurs by solving production and delivery-related problems as bona fide, hypothesis-testing experiments. Examples of this approach follow.
A quality improvement team at a Toyota supplier, Taiheiyo, conducted a series of experiments to eliminate the spatter and fumes emitted by robotic welders. The quality circle members, all line workers, conducted a series of complex experiments that resulted in a cleaner, safer work environment, equipment that operated with less cost and higher reliability, and relief for more technically-skilled maintenance and engineering specialists from basic equipment maintenance and repair.
A work team at NHK (Nippon Spring) Toyota, were taught to conduct a series of experiments over many months to improve the process by which arm rest inserts were "cold molded." The team reduced the cost, shortened the cycle time, and improved the quality while simultaneously developing the capability to take a similar experimental approach to process improvement in the future.
At Aisin, a team of production line workers progressed from having the skills to do only routine production work to having the skills to identify problems, investigate root causes, develop counter-measures, and reconfigure equipment as skilled electricians and machinists. This transformation occurred primarily through the mechanism of problem solving-based training.
Another example from Aisin illustrates how improvement efforts—in this case of the entire production system by senior managers—were conducted as a bona fide hypothesis-refuting experiment.
The Acme and Ohba examples contrast the behavior of managers deeply acculturated in Toyota with that of their less experienced colleagues. The Acme example shows the relative emphasis one TPS acculturated manager placed on problem solving as a training opportunity in comparison to his colleagues who used the problem-solving opportunity as a chance to first make process improvements. An additional example from a Toyota supplier reinforces the notion of using problem solving as a vehicle to teach.
The data section concludes with an example given by a former employee of two companies, both of which have been recognized for their efforts to be a "lean manufacturer" but neither of which has been trained in Toyota's own methods. The approach evident at Toyota and its suppliers was not evident in this person's narrative.
Defining conditions as problematic
We concluded that within Toyota Production System-managed organizations three sets of conditions are considered problematic and prompt problem-solving efforts. These are summarized here and are discussed more fully in a separate paper titled "Pursuing the IDEAL: Conditions that Prompt Problem Solving in Toyota Production System-Managed Organizations."
Failure to meet a customer need
It was typically recognized as a problem if someone was unable to provide the good, service, or information needed by an immediate or external customer.
Failure to do work as designed
Even if someone was able to meet the need of his or her customers without fail (agreed upon mix, volume, and timing of goods and services), it was typically recognized as a problem if a person was unable to do his or her own individual work or convey requests (i.e., "Please send me this good or service that I need to do my work.") and responses (i.e., "Here is the good or service that you requested, in the quantity you requested.").
Failure to do work in an IDEAL fashion
Even if someone could meet customer needs and do his or her work as designed, it was typically recognized as a problem if that person's work was not IDEAL. IDEAL production and delivery is that which is defect-free, done on demand, in batches of one, immediate, without waste, and in an environment that is physically, emotionally, and professionally safe. The improvement activities detailed in the cases that follow, the reader will see, were motivated not so much by a failure to meet customer needs or do work as designed. Rather, they were motivated by costs that were too high (i.e., Taiheiyo robotic welding operation), batch sizes that were too great (i.e., the TSSC improvement activity evaluated by Mr. Ohba), lead-times that were too long, processes that were defect-causing (i.e., NHK cold-forming process), and by compromises to safety (i.e., Taiheiyo).
Recap
Our field research suggests that Toyota and those of its suppliers that are especially adroit at the Toyota Production System make a deliberate effort to develop the problem-solving skills of workers—even those engaged in the most routine production and delivery. We saw evidence of this in the Taiheiyo, NHK, and Aisin quality circle examples.
Forums are created in which problem solving can be learned in a learn-by-doing fashion. This point was evident in the quality circle examples. It was also evident to us in the role played by Aisin's Operations Management Consulting Division (OMCD), Toyota's OMCD unit in Japan, and Toyota's Toyota Supplier Support Center (TSSC) in North America. All of these organizations support the improvement efforts of the companies' factories and those of the companies' suppliers. In doing so, these organizations give operating managers opportunities to hone their problem-solving and teaching skills, relieved temporarily of day to day responsibility for managing, production and delivery of goods and services to external customers.
Learning occurs with the guidance of a capable teacher. This was evident in that each of the quality circles had a specific group leader who acted as coach for the quality circle's team leader. We also saw how Mr. Seto at NHK defined his role as, in part, as developing the problem-solving and teaching skills of the team leader whom he supervised.
Problem solving occurs as bona fide experiments. We saw this evident in the experience of the quality circles who learned to organize their efforts as bona fide experiments rather than as ad hoc attempts to find a feasible, sufficient solution. The documentation prepared by the senior team at Aisin is organized precisely to capture improvement ideas as refutable hypotheses.
Broadly dispersed scientific problem solving as a dynamic capability
Problem solving, as illustrated in this paper, is a classic example of a dynamic capability highlighted in the "resource-based" view of the firm literature.
Scientific problem solving—as a broadly dispersed skill—is time consuming to develop and difficult to imitate. Emulation would require a similar investment in time, and, more importantly, in managerial resources available to teach, coach, assist, and direct. For organizations currently operating with a more traditional command and control approach, allocating such managerial resources would require more than a reallocation of time across a differing set of priorities. It would also require an adjustment of values and the processes through which those processes are expressed. Christensen would argue that existing organizations are particularly handicapped in making such adjustments.
Excerpted with permission from "Developing Skillful Problem Solvers in Toyota Production System-Managed Organizations: Learning to Problem Solve by Solving Problems," HBS Working Paper, 2001.
News source: HBS Working Knowledge
