“The ability to learn faster than your competitors may be the only truly sustainable competitive advantage.”
De Geus (1988)

At Toyota, learning and continuous improvement are fundamental to how each person does his or her job every day and are inseparable from Toyota’s culture. Toyota sets challenging performance goals for every project and holds both real-time and postmortem learning events (called Hansei or reflection) that encourage functional specialists to verify and update their own knowledge database. Learning and continuous improvement are also embodied in a problem-solving process that develops root-cause countermeasures: multiple potential solutions that prevent recurrence. In fact, Toyota’s awesome ability to learn quickly and improve at a regular cadence may well be the characteristic of Toyota its competitors should fear most.

Defining Knowledge and Organizational Learning

Many theories purport to define organizational learning, knowledge transfer, information management, and how these apply to product development. It can be argued, in fact, that knowledge and learning also provides numerous views on organizational learning and the requirements for a successful learning organization.

Two types of learning: single loop learning and double loop learning. Single loop learning comprises error detection and correction without change to the underlying values of the system. (Example the thermostat detecting a decrease in temperature and turning on heat without the ability to question what it is doing). Double loop learning occurs when the actual operating norms are questioned, which is fundamental to an organization’s ability to learn.

Other scholars point out two very different types of knowledge: the first is explicit knowledge or information easily codified and transferred without significant loss of content. Explicit knowledge includes “facts, axiomatic propositions, and symbols”. The second category of knowledge is tacit knowledge or know-how. This type of knowledge is complex, hard to codify, and difficult to transfer; it requires dense ties and long relationships.

Most companies focus on explicit knowledge, defined above as easily codified, transferred without significant loss of integrity, and generally stored as facts, axiomatic propositions, or symbols. Historical dates, mathematical equations, and formulas fall into this category. Explicit knowledge is sometimes referred to as “know what” knowledge. It is characterized by voluminous databases. By contrast, tacit knowledge is complex, “sticky”, and difficult to transfer. Sharing tacit knowledge requires intricate ties between participants; it entails longer, deeper relationships, such as those that develop between a master craftsman and his apprentice. In fact, the apprenticeship tradition was designed as a means to transfer tacit “know how” knowledge from master to student.

One of the main reasons that companies fail at imitating lean systems is that they mistakenly copy only the “explicit” knowledge of lean tools and techniques. By a large, these companies attempt to implement lean culture without understanding the need to tap into the tacit knowledge of lean culture, the know-how knowledge that enables an organization to learn organically, adapt, and grow. They fail to trasp that in highly technical environments, such as product development, tacit knowledge is the true source of competitive advantage.

Toyota’s Product Development Learning Network

To understand Toyota’s learning network is to understand a piece of Toyota’s culture with its strong emphasis on the importance of people. For Toyota, transferring tacit knowledge means that people must get to know each other well enough to share deep insights. There are several ways Toyota forms a highly effective learning network in product development.

1. Supplier technology demonstrations. At the beginning of each program, suppliers demonstrate technology that might be appropriate for the new vehicle. This is a good opportunity for Toyota engineers to learn about new developments. And for Toyota to leverage supplier resources fully. Toyota suppliers bring parts and meet face to face with Toyota engineers.
2. Competitor teardown analysis. Teardown exercises provide an opportunity to learn about competitors. These hands-on exercises are another example of genchi genbutsu and an excellent way for engineers to learn. In lean PD, you also want to use these learning tools to disseminate information so that all team members learn from them.
3. Checklists and quality matrices. Toyota uses these tools to organize and store information so that people can apply it similarly across the organization.
4. Learning focused problem solving. This represent the A3 problem-solving discipline that helps people learn while seeking lasting solutions. At Toyota, problem solving begins early (at the source), is data driven, and includes a learning component.
5. Know-how database. The know-how database is the collection of standards combined with design data and tools, such as digital assembly. The functional organizations that use these databases (evolved from checklists) maintain, validate, and update them as needed.
6. Hansei events. Hansei is a Japanese word for reflection. At these reflection events, participants share their PD program experiences, lessons learned, project shortcomings.
7. Program manager conferences. Program managers from various projects meet once a year to discuss lessons learned and to pass on new standards. The lessons are derived from each program’s hansei or reflection events that the program manager leads.
8. Business Revolution Teams. These cross-functional teams are formed to address single revolutionary improvement efforts. Toyota high-level executives assign people to these teams full time and each assignment can last six months to a year. The first hybrid, Prius, began with a business revolution team, as did Toyota’s effort to eliminate engineering changes.
9. OJT skills matrices and learning-focused carrier paths. Specific OJT skill matrices and mentoring technical skills teach engineers leadership and sets their career paths. Learning is built into everyday assignments so engineers can use Toyota’s scientific method – identify, evaluate, countermeasure, verify, communicate (standardize) – to question and learn continuously. This cycle of mentoring, learning, and applying until one has the potential to mentor others is the heart of a lean learning system.
10. Resident Engineers (RE). Engineers are exchanged on temporary assignment both within Toyota and with affiliated companies. This is a learning opportunity for the RE and is also a method of standardizing practices.

Learning from Experience

If there is no mechanism or culture in an organization for capturing, retaining, and reusing knowledge, that organization is almost certainly engaged in constantly reinventing the wheel. There are a number of reasons the learning from experience process fails:

1. Time pressures. Stressful time pressures impact most people in every organization. As soon as one project is over, another one (sometimes already behind schedule) looms and must be immediately addressed.
2. Oppressive workloads. People tend to be absorbed by their current workload, often ignoring important things learned from past (even recent past) experience.
3. Blaming. Organizational lessons-learned events often turn into sessions marked by scapegoating, finger-pointing, and assigning blame. As a result, only the loudest or most powerful are heard at such events; other people are reluctant (and often silent) participants.
4. Complex projects. Complicated projects thwart understanding, causing frustration.

Furthermore, five suggestions to help reflection events success:

1. Hold the reflection as soon as possible after the event. The loss of caluable real-time information increases over time.
2. Focus on things under the group’s control. People should not waste time confessing other people’s sins or policies that the group cannot take action on.
3. Tolerate criticism and honest dialog. Participants should feel free to express all relevant views without fear of repercussion. Personal attacks should not be tolerated.
4. Must be a regular event. People must see this activity as part of the job.
5. Must update standards and processes. Just talking about it doesn’t fix it. The end result of each event must be some concrete, observable improvement or people will view these events as worthless and stop participating.

Hansei at Toyota

Hansei requires a certain humbleness or egolessness in order to search for and identify weakness in ones performance or character. Each Toyota hansei event or hansei kai (reflection meeting) is designed to enhance organizational learning from experience. There are three types of hansei:

1. Personal reflection. In this hansei exercise, a supervisor asks an engineer to reflect on some aspect of his or her performance and develop an action plan for improvement. A written response is expected and will be reviewed by both parties. Specific goals are set and a follow-up plan is outlined. This activity addresses a specific skill or capability that needs to be improved.

2. Real-time reflection. This hansei experience occurs at a group or team level and is scheduled into the product development process. These hansei kai usually take place at major milestone events, such as final data release or tool transfer to the stamping plant. PD programs can last a year or more and you can lose much information in that time, so these are regular events scheduled to take place as soon as possible after the actual activities. The hansei event can focus on a specific issue, such as looking at the problem of some parts that arrived late for the prototyping event. They might also reflect holistically on the prototyping event. Depending on the issues involved, group or team hasnei events can be cross-functional or intra-functional. They are most often cross-functional, focusing on internal customer feedback. Although flexible, they typically follow a general outline and address the following questions:

• What were our goals and objectives? (often organized by category)
• How did we actually perform to our goals?
• Why did it happen? (data analysis)
• How will we improve next time? (a written improvement plan)

These hansei events often lead to updating a relevant standard or may require an A3 for reporting or problem solving. The length of hansei events can vary significantly, but they are often scheduled as two or three meetings, each lasting two to four hours, within a two-week time period. Much of the actual “prep” work occurs before the meeting date. Toyota’s A3 and “5 why” problem-solving methodologies are rigorously employed.

3. Postmortem reflection. This is the “what went right, what went wrong” lessons-learned event. The presentations are formal, with most of the real analysis and reflection occurring before the meeting date. At the meeting, representatives from each of the functional groups review program performance and discuss results as well as new ideas stemming from real-time reflection. Program managers talk to participants to get feedback and synthesize these reflections from their programs into a small number of lessons learned that are shared at PM meetings held several times a year. At these meetings or hansei kai, program managers produce written summary documents that are shared within and across other PD program teams. Note that there is a distinction between the program manager and the chief engineer and that these roles are not interchangeable. The chief engineer is responsible for the product. The program manager (not as high a level) is responsible for the process.

Ijiwaru Testing at Toyota

Testing and validation can be another important opportunity to learn from experience in product development. Ijiwaru testing on the other hand is the practice of testing subsystem to failure. By testing these subsystems under both normal and abnormal conditions and pushing designs to the point of failure Toyota engineers gain a great deal of insight into both current and future designs and materials by understanding the absolute physical limitations of their subsystems.

The Power of Problems

Toyota views problems as a natural part of product development. In fact, in a sense, the essence of product development can be seen as a series of technical problems that must be identified and solved. From this point, companies who excel at technical problem solving will do well at product development.

In short, the lean PD process views problems as opportunities – not only to improve products but also to improve the core of a company’s product development capability. By contrast, at NAC it is common to see problems as negative and unexpected, an attitude that suggests problems shouldn’t occur at all.

To develop and sustain a lean PD process, a company will need to transform these problems into perfecting problem-solving capability so that there are mechanisms for capturing, verifying, codifying, and sharing these solutions before they are lost. Toyota accomplishes this in a number of ways, beginning with the standardized problem solving during kentou, which continues throughout the PD process. The standardized scientific problem-solving process:

• Identifies the problem’s root cause
• Evaluates the potential impact of several possible solutions
• Produces a high quality countermeasure that can resolve the immediate issue as well as prevent its recurrence
• Verifies the countermeasure during subsequent hansei events
• Communicates the result across programs by updating standards and checklists, which are increasingly part of the “know-how database”

Ignorance: The Ultimate Expense

Many companies view paying for employees to learn as an unnecessary cost. Anything that is not tactical or does not produce immediate, measureable results is “fluff”, and those who endorse an opposing view are not considered serious-minded, action-oriented business people. But the absence of deep technical understanding drives a “more is better” philosophy, which leads to more elaborate gauges, more reviews, more audits, more inspections, and more checkpoints (because it is always “safe” to check and check again). You cannot “inspect in quality” – and this applies to product development and manufacturing. Furthermore, constant inspection tends to create a culture of fear.

In Summary:

Build in learning and continuous improvement

The ability to learn and continuously improve may be a lean product development system’s most powerful competitive weapon. Within this framework, it is the tacit, “know how” knowledge that is most potent, the most difficult knowledge to foster and manage. There are no short cuts or IT solutions. Transfer and application of tacit knowledge requires close ties and a good deal of time of the sort enabled by structured mentoring, OJT, strategic and aligned training, and lots and lots of face-to-face time at the source. Toyota understands the essentials of its business and builds tacit learning into the way work is performed every day. At Toyota, tacit learning is not an add-on or extra-curricular activity. It is core curriculum that is learned through hansei, mentoring, PDCA cycles, excellence in problem solving, teardown, and other experiences, all of which are focused on improvement.

Source: Liker, J.K and Morgan, J.M, The Toyota Product Development System: Integrating People, Process and Technology, Productivity Press, 2006