How Toyota Changed the Way We Make Things

Don’t make irreversible decisions in the first place; delay design decisions as long as possible, and when they are made, make them with the best available information to make them correctly.

Video by Bloomberg

The Japanese Car Company is a corporate behemoth – but it’s done much more than just give us Corollas or Land Cruisers. It’s changed the way the world makes products. Here’s how.

Toyota knows how to make cars. It does it so well, it became the first company to produce more than 10 million cars a year. Its success is rooted in a special system and began what is now known as lean manufacturing and its ethos is emulated by companies around the world to make products faster, cheaper, and better.

Here’s how Toyota changed the way we make things.

Following the 2nd World Warm Japan was left in a precarious economic position. Steel and other metals are scarce. Already disadvantaged by lacking natural resources materials were hard come by, the companies had to be creative to compete.

Toyota’s founder, Sakichi Toyoda started a loom business, but it was his son Kiichiro who founded a motor company in 1937.

Then he used to work with narrow margins. As the shortage of materials increased during the war the number of head lamps on his model truck was reduced to one and it only had brakes on one of the axels.

The turning point for Toyota’s production system would come in the early 50’s when Kiichero’s cousin Eiji travelled to the US with a veteran loom machinist Taiichi Ohno.

They visited Ford’s River Rouge plant in Michigan and were impressed by the scale of the operation but knew that in cash-strapped Japan companies didn’t have the resources for such a system. Having months’ worth of stock sitting in a warehouse would tie up precious capital they didn’t have. Instead, what truly impressed Ohno was a visit to a supermarket at Piggly Wiggly, according to a legend.

Japan didn’t really have self-service stores at this point and he was struck by the way customers could choose exactly what they wanted when they wanted. He decided to model his production line on a similar idea. With the supermarket formula only enough parts were produced in the first phase to replace what was used in the second, and so on. This is where the Just-in-time System really took shape. Toyota was able to eliminate much of the waste in Ford system making smaller numbers of parts to be used when it needed them allowing the company to operate on a tighter budget. As part of this Ohno developed Kanban, a sign based scheduling method which shows goods-in, goods-in-production and goods-out. It’s now seen as a precursor to barcodes.

Ohno and Toyoda also noticed that American car companies were still employing many of Henry Ford’s early production techniques. They kept operations at full tilt in order to maximize efficiencies of scale, but then had to repair defective cars after they rolled off the line.

Ohno believed this caused more problems and didn’t encourage workers or machines to stop making the mistake. So he placed a cord at about every station which any worker could pull to stop the entire assembly if they spotted the problem. The whole team would work on it to prevent it from happening again. As teams identified more problems the number of errors began to drop dramatically.

Combined with the culture of continuous incremental improvement called Kaizen the Toyota production system built a brand known for making reliable and affordable cars.

But Toyota was also getting good at producing cars quickly. In 1962, the company had produced 1 million vehicles. By 1972 they produced 10 million.

It was around that time that the efficiencies of their factories enabled Toyota to produce a car every 1.6 man hours, much lower than their competitors in the US, Sweden, and Germany. And as the oil crises of the decade sent gas prices higher, cheap to run Japanese cars became much more appealing to Americans as powerful but gas guzzling vehicles suddenly became very expensive to run.

Today Toyota has made over 250 million vehicles.

Others have looked to them to learn the lessons of Lean, combining craft with mass production, avoiding waste while striving for constant improvement. Boing is perhaps the most famous, restructuring a plant to better suit TPS.

Toyota’s production system changed not just how cars are made lovely but how we approach making things from staff. It also showed that there’s always a better way to make a product.

Learn more:

Lean Software Development: An Agile Toolkit
by Mary and Tom Poppendieck

Companies such as Honda and Toyota put a premium on rapid, concurrent development and the ability to make changes late in the development cycle.

Toyota and Honda had discovered a different way to avoid the penalty of incorrect design decisions: Don’t make irreversible decisions in the first place; delay design decisions as long as possible, and when they are made, make them with the best available information to make them correctly.

The seven lean principles:

  1. Eliminate waste. Waste is anything that does not add value to a product, value as perceived by the customer. In lean thinking, the concept of waste is a high hurdle. If a component is sitting on a shelf gathering dust, that is waste. If a development cycle has collected requirements in a book gathering dust, that is waste. If a manufacturing plant makes more stuff than is immediately needed, that is waste. If developers code more features than are immediately needed, that is waste. In manufacturing, moving product around is waste. In product development, handing off development from one group to another is waste. The ideal is to find out what a customer wants, and then make or develop it and deliver exactly what they want, virtually immediately. Whatever gets in the way of rapidly satisfying a customer need is waste.
  2. Amplify learning. Development is an exercise in discovery, while production is an exercise in reducing variation, and for this reason, a lean approach to development results in practices that are quite different than lean production practices. Development is like creating a recipe, while production is like making the dish. Recipes are designed by experienced chefs who have developed an instinct for what works and the capability to adapt available ingredients to suit the occasion. Yet even great chefs produce several variations of a new dish as they iterate toward a recipe that will taste great and be easy to reproduce. Chefs are not expected to get a recipe perfect on the first attempt; they are expected to produce several variations on a theme as part of the learning process. Software development is best conceived of as a similar learning process with the added challenge that development teams are large and the results are far more complex than a recipe. The best approach to improving a software development environment is to amplify learning.
  3. Decide as late as possible. Development practices that provide for late decision making are effective in domains that involve uncertainty, because they provide an options-based approach. In the face of uncertainty, most economic markets develop options to provide a way for investors to avoid locking in decisions until the future is closer and easier to predict. Delaying decisions is valuable because better decisions can be made when they are based on fact, not speculation. In an evolving market, keeping design options open is more valuable than committing early. A key strategy for delaying commitments when developing a complex system is to build a capacity for change into the system.
  4. Deliver as fast as possible. Until recently, rapid software development has not been valued; taking a careful, don’t-make-any-mistakes approach has seemed to be more important. But it is time for “speed costs more” to join “quality costs more” on the list of debunked myths. Rapid development has many advantages. Without speed, you cannot delay decisions. Without speed, you do not have reliable feedback. In development the discovery cycle is critical for learning: Design, implement, feedback, improve. The shorter these cycles are, the more can be learned. Speed assures that customers get what they need now, not what they needed yesterday. It also allows them to delay making up their minds about what they really want until they know more. Compressing the value stream as much as possible is a fundamental lean strategy for eliminating waste.
  5. Empower the team. Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work. Involving developers in the details of technical decisions is fundamental to achieving excellence. The people on the front line combine the knowledge of the minute details with the power of many minds. When equipped with necessary expertise and guided by a leader, they will make better technical decisions and better process decisions than anyone can make for them. Because decisions are made late and execution is fast, it is not possible for a central authority to orchestrate activities of workers. Thus, lean practices use pull techniques to schedule work and contain local signaling mechanisms so workers can let each other know what needs to be done. In lean software development, the pull mechanism is an agreement to deliver increasingly refined versions of working software at regular intervals. Local signaling occurs through visible charts, daily meetings, frequent integration, and comprehensive testing.
  6. Build integrity in. A system is perceived to have integrity when a user thinks, “Yes! That is exactly what I want. Somebody got inside my mind!” Market share is a rough measure of perceived integrity for products, because it measures customer perception over time. Conceptual integrity means that the system’s central concepts work together as a smooth, cohesive whole, and it is a critical factor in creating perceived integrity. Software needs an additional level of integrity—it must maintain its usefulness over time. Software is usually expected to evolve gracefully as it adapts to the future. Software with integrity has a coherent architecture, scores high on usability and fitness for purpose, and is maintainable, adaptable, and extensible. Research has shown that integrity comes from wise leadership, relevant expertise, effective communication, and healthy discipline; processes, procedures, and measurements are not adequate substitutes.
  7. See the whole. Integrity in complex systems requires a deep expertise in many diverse areas. One of the most intractable problems with product development is that experts in any area (e.g., database or GUI) have a tendency to maximize the performance of the part of the product representing their own specialty rather than focusing on overall system performance. Quite often, the common good suffers if people attend first to their own specialized interests. When individuals or organizations are measured on their specialized contribution rather than overall performance, suboptimization is likely to result. This problem is even more pronounced when two organizations contract with each other, because people will naturally want to maximize the performance of their own company. It is challenging to implement practices that

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: