Make Technology Fit with People and Lean Processes

Back to the Abacus?

“Lean is antitechnology.” “Those lean bigots are always bad-mouthing IT.” “If it were up to the lean dreamers we would scrap all our computers and even our pens are too high tech—they want pencil and paper.” These are examples of statements we often hear, particularly from frustrated IT professionals who are being blocked by the lean folks from implementing the technologies they had planned. The impression is that Toyota does not believe in advanced technology of any kind. They seem to imagine Toyota as a company where everyone carries an abacus on their belts.

Let’s get this myth off the table immediately. The reality is that Toyota is a technology-based company. In fact, they are among the most sophisticated users of advanced technology in the world. We have not measured technology use in Toyota versus the competition, but we can tell you that they use it, and use lots of it—robots, supercomputers, desktop computers, RF scanning technology, SAP, lights-out factories, and so on. Consider the technology in Toyota products—i the first company to make a mass production hybrid vehicle filled with computer chips galore—and Toyotas in Japan are filled with GPS systems for navigation.

The point of confusion is simple. It’s not that Toyota avoids advanced technology, but that Toyota views technology differently. When lean experts advise a company to stop using the MRP (Material Requirements Planning) system as it is being used, or to shut down the automated storage and retrieval system, or to stop investing in that high-technology paint booth, they are not saying stop using technology but saying stop using technology in a way that produces waste. Stop using technology as a substitute for thinking.

Go back to the history of Toyota and Sakichi Toyoda, the “King of Inventors” in Japan. The company got its start as a producer of automation. Toyoda wanted to automate weaving through power looms. But he did not go out and set up an R&D lab to make the most high-tech, expensive, and exotic power loom possible. He wanted a simple and inexpensive loom that could serve the purpose of relieving some of the burden on women in the community. He built the first Toyoda looms by hand out of wood. He got his own hands dirty learning steam engine technology.

When Toyota Motor Company got into the hybrid technology business, it was not on a mission to become the world leader in advanced hybrid technology. It began with a high-powered technical team, dubbed G21, assigned to think innovatively about new ways to build cars and new ways to design cars for the twenty-first century. In the early 1990s the financial success and market penetration of Toyota was at a peak, yet chairman Eiji Toyoda took every opportunity he could to preach crisis. At one Toyota board meeting he asked, “Should we continue building cars as we have been doing? Can we survive in the twenty-first century with the type of R&D that we are doing?” This triggered the G21 team to develop a concept for the twenty-first century car. A chief engineer was assigned, and after an exhaustive search, and with prodding from new president Hiroshi Okuda, concluded that the hybrid engine was a good intermediate solution between conventional engines and the real future in fuel cells or some other renewable resource. The hybrid engine was a practical solution to a real problem—not a solution in search of a problem.

The history of Toyota has not been about avoiding new technology. It has been about putting technology into a proper perspective, one driven by a practical purpose. And then Toyota always looks at the value-added process to realize that purpose. Only then does the company consider where new technology fits into achieving that purpose. This is the lesson of lean thinking about technology. Like most other things we have been covering in this book, there is no cookbook on how to evaluate technology or how to implement it in a “lean way.” There is also no such thing as “lean technology.” There are only lean systems with technology playing an appropriate role in supporting them. In this chapter we will discuss ways to think about and adopt new technology.

Case Study: Is Toyota Technology Behind the Times?

Toyota has an interesting practice of allowing competitors to visit their factories. The Georgetown plant often hosted “automotive benchmarking” tours and has monthly “public information tours/seminars.” Visitors were able to talk to Toyota employees and ask specific questions related to how Toyota does things. On special benchmarking tours visitors are allowed to visit the shop floor and “see whatever they want to.”

On one particular tour with some Big Three plant managers, one of the visitors commented to his associates, “Get a look at this. We haven’t used that technology for at least 15 years!” The outdated technology seemed to be the center of their attention. They completely overlooked other elements of the production system that they had struggled with in their plants. One of the visitors inadvertently walked into a robot cell and shut the robot down. He didn’t even realize that this had happened, and a team leader came over and restarted the robot in less than a minute, before any loss of production occurred. The tour guide pointed this out to the plant manager and asked him how long it would take to restart a robot or line in his plant if it had been stopped. His response was, “Maybe 10 or 15 minutes,” and then he went on complaining about the outdated technology, without understanding that it is not the technology that is critical, but rather, the people who use the technology and the total system.

Toyota robots have considerably higher reliability and uptime than those in Big Three plants. Its flexible global body line that can flexibly make trucks and minivans and car bodies in any order without missing a beat is the envy of the industry. And it is full of robots all operating in harmony. Any robot goes down and the body line goes down. But they rarely go down. Most auto makers would be concerned about old technology. Toyota believes that the worst state of the technology should be when it is out of the box and then it improves with age through regular maintenance and continuous improvement.

What Do You Believe About Technology, People, and Processes?

The starting point of thinking is what you believe. It is also what you value. If you believe that technology is the solution to your problems or if you value being the kid with the best technological toys on the block, you will not get lean. The Toyota Way always starts with the customer. What does the customer want? Then ask what process will add value to the customer with minimum waste. Then recognize that any process you can concoct will still be full of waste. Getting out the waste takes time and experience with the process: It is a learning process of continuous improvement, and only those working in and

managing the process can improve it on a day-to-day basis.

Thinking in this way is a belief system. The principles of the Toyota Way are a set of beliefs in what works. It is part of the culture of Toyota. So any new technology must fit into this broader system and philosophy:

• How will technology contribute to the value adding process?
• How will technology help to eliminate waste?
• Will the technology contribute to a flexible system that can economically adjust to ups and downs in demand?
• Will the technology support people doing the work in continuous improvement of the process?
• Have people in the system challenged themselves to accomplish the goal with the most flexible and least complex technology?
• Are people using the technology as a crutch to avoid having to think deeply about improving the process?

The cross-dock case study below illustrates two contrasting belief systems with two contrasting results. Toyota took a process-oriented view in developing a standardized cross-docking system following Toyota Production System (TPS) principles that seamlessly integrated its suppliers and assembly plant. Technology clearly took a backseat in the Toyota case. A major U.S. automaker took a technology-oriented view placing IT systems at the center, hoping the IT systems would somehow integrate a diverse range of logistics providers who were selected based on low cost bids. The result, predictably, was superior performance of the Toyota logistics system.

Case Study: Technology Beliefs and Cross-Docks

Toyota made a serious investment in time and money to develop a lean cross-dock system in North America by establishing a joint venture: Transfreight. Toyota did not have any direct ownership stake but did involve its trading company partner, Mitsui, in a joint venture with TNT Logistics (later Mitsui bought out TNT). A cross-dock is simply like a juncture box. In this case, truckloads of parts come in at least daily from a variety of different suppliers spread around the country. The pallets of parts cross through the dock and are reloaded in mixed loads of just enough parts for one to two hours of use in the assembly plant. Shipments are going out to the assembly plant 12 times per day. It would be a waste of lots of truck space to have trucks picking up parts from all over the country 12 times per day and going directly to the assembly plant—the trucks would be mostly empty most of the time.

The Toyota belief was that the cross-dock was an extension of the assembly plant—a lean value chain from the supplier right to the person assembling parts to the vehicle. It was a complex process with many opportunities for error, with thousands of parts moving about each day. And each step in the process was based on tight time windows, with any delays cascading through the system. To get it right required a creative application of TPS. It needed to be a flowthrough process with minimal waste. It needed to be a visual process so people would make the right decisions at the right time. Standardized work was needed to have consistency in timing. Truck drivers were inspectors checking that all the right parts were being collected from the suppliers.

Teams of workers needed to be highly trained, with team leaders carefully checking the work at each point to be sure no errors slipped through. And every one was a thinker driven to continually improve the process.

The result was a relatively low-tech solution. For example, a ticket system was developed. Pallets of parts from suppliers were taken off the truck and immediately tagged with a specific ticket listing critical information like the part number, quantity, and main route to the assembly plant. It was color coded according to where the part would sit in the cross-dock. Specific lanes were set up for different main routes to the assembly plants. Other physical areas were set aside for parts that needed to be repacked or parts that needed to “go to sleep” and wait more than a day to be delivered. The cards were kept in a large visual board with cubby slots by supplier subroute and assembly plant main route. As one Transfreight executive stated:

Our process for managing the cross-docks is all manual. We use [Microsoft] Access and Excel, but it’s largely manual. There’s no optimization software, no RF technology to scanning of freight. I mean, we do have a system to calculate cube, miles, etc., but our processes are largely manual.

Now let’s consider an American competitor to Toyota that set up a cross-docking system in part to imitate Toyota’s just-in-time system. This auto maker also set up a joint venture, of which it owned a controlling 60 percent. When speaking to one of the executives of the joint venture, the purpose of the joint venture was described as follows:

Our vision is [centered on] our IT. This is a global, integrated system that provides both inbound and outbound visibility so we have visibility of all material and the product. We will have database management and warehouse database management globally. We will be the central clearinghouse for all data. We will have plug and play capability with any system that any company has, whether it is SAP, i2, CAPS, or Manugistics. The last part is supplier or logistics or partner compliance. So it is the measurement, the drive for Six Sigma, that we signed up for. We are delivering all the process management through the companies and the partners. That is our scope; that’s it.

Interestingly, while Toyota invested heavily in applying TPS within each cross-dock in Transfreight, the American joint venture put each new contract for different collections of parts up for bid to competitive logistics companies that ran cross-docks. Transfreight owned the cross-docks and ran each using a uniform set of management principles.

Different logistics companies won different pieces of the work for the American joint venture and used their own approaches to cross-dock management. That is why it was so important to have “plug and play” capability—each logistics company used different software. The software was the connection between the U.S. automaker and the logistics provider. For Toyota, there was a lock-tight umbilical cord connecting the processes of the suppliers, cross-docks, and the assembly plant.Through common processes and common IT, it was not necessary to have plug and play capability.

A comparison of eight cross-docks of the U.S. automaker and five crossdocks of Transfreight on key performance indicators was conducted using measures like labor productivity, utilization of forklifts, trailer/tractor ratio, and number of time windows successfully achieved. The results showed that the Transfreight cross-docks had overall superior performance to the U.S. automaker’s cross-docks. Apparently, technology was not the answer.

Tailor Technology to Fit Your People and Operating Philosophy

In the cross-dock case example above, Transfreight certainly is not using very sophisticated “supply chain solutions” software. Does that mean this software is not “lean”? On the contrary, over time Toyota has been carefully evaluating various software solutions and is gradually incorporating them into the process. But it must be carefully screened. Bringing new software into the system is a bit like transplanting an organ into the body. If it is not a match, the body might reject the organ and shut down.

Glenn Uminger has responsibility for much of the logistics system for Toyota in North America. He believed there was a role for more advanced information technology in optimizing pickup and delivery routes of trucks. A good part of this system involves Transfreight, which uses the traditional manual systems that have worked for Toyota for decades. Truck routes basically are developed manually with data from simple in-house IT systems that visually display data and routes. It is comparably easy to develop truck routes because of Toyota’s passion for heijunka. If the assembly plant has stable, leveled production, it will place a stable, leveled demand on all its supply systems. If you know the quantity that will be shipped every day to the assembly plant, and the frequency of delivery, it is relatively straightforward to put together routes that will be the same every day. Yet there still are unexpected fluctuations in assembly plant production, and enough supply points that Glenn thought planning software could be faster and perhaps do a better job than the manual process. As he explained:

I personally first picked up a commercial inbound logistics software program and brought it into the Toyota world for hands-on trials with live data to judge its benefit starting three years ago. As we did this, I met much resistance from TMC (headquarters in Japan), as they did not like software for planning, were afraid Americans would come to depend on it and forget the logic and principles that stand behind it. They also thought that the human could create the best plan and then flexibly adjust it over time. I knew we were operating a very complex network and no human could consider all of the mathematical possibilities, all revolving around firm TPS principles. The facts using live data proved me right, and TMC quickly launched an internal system development project to create software with high optimization power, at the same time respecting TPS principles. During this, a relationship was formed between the TMC developers and Dr. Sean Kim of Agillence. Over time, TMC could not exceed the performance of Agillence software, so TMC is adopting the Agillence optimization engine and including it in our new route planning system (SMAP), due to go live in two months. We and Europe have been using this in a trial setting this year.

On the surface this seems like the story of a rigid bureaucracy that is controlled by leaders resistant to change: “We did it by hand in the good old days, so why can’t you?” In reality the old liners in TMC are protecting the Toyota Way—the very essence of Toyota’s competitive advantage. If they approve every request to adopt new software based on a simple business case, before long Toyota will be full of strung-together software and their worst fears will be realized: Toyota team associates “would come to depend on it and forget the logic and principles that stand behind it.” At that point Toyota would be just like its competitors.

Instead they forced Glenn Uminger to defend his position, think hard about the issues, and present a solution that fit with TPS principles. After working on it for three years, Glenn says:

We will always search for the lowest cost solution while achieving proper application of our principles. We are not really sacrificing any service level of plant delivery frequency, lead time, heijunka from a practical view, but we are always evolving on how we achieve all objectives most effectively. Yes, we do always work on ways to reduce cost, but as we do we make sure we stay in bounds with our principles. Our SMAP system [includes the Agillence optimization engine] provides us a new tool to more dynamically plan routes, use “what if” scenarios, allows more time for study to ensure we apply the best routes considering all objectives, service, and cost. We change routes about eight times each year. We have some different ways of routing; sometimes short routes are okay at low efficiency if it frees up longer routes, so they won’t be damaged by the need to include the low-volume short distance supplier, which is out of the way of the long route.

So our total system is stronger, and we also are lowering cost when considering the total system, no extra box handling, most effective routes. Our group

worked tirelessly to spec and functionally test/develop this tool. We will achieve a payback from the tool for all our efforts in a matter of months.

This is a different story of technology adoption than we see in most companies. It is a story of a group working tirelessly to develop a solution that fits its process and principles. This is a Toyota logistics group, not an IT group. They did not place all their faith in the outside vendor. They used the vendor’s algorithm and worked with the vendor over several years to tailor it to fit TPS before finally bringing it live, including a display that meets Toyota’s tough visual management standards. While the planning horizon was long, one can safely predict that the implementation will be smooth and, if successful, will migrate as a new Toyota standard globally—to be continually improved.

Contrasting Models of Technology Adoption

In reflecting on how Toyota approaches technology, we have identified contrasting models of traditional companies versus Toyota’s lean approach. Broadly speaking, there are two different animals here—the case of hard automation and the case of IT systems for planning, scheduling, and decision making. We will consider each in turn.

Automation has been around for centuries. It is not a new story. Any engineer who has made a case for automation knows the drill. Do a cost benefit analysis where the cost is the amortized capital cost and the benefit is typically labor savings. If labor savings exceeds the amortized capital cost, the automation wins. In reality there is often a hidden bias in favor of the technology since automation does not talk back like people or threaten to unionize. Give a robot an order by programming it and it executes the order without further explanation. Many engineers make a living going through factories area by area and making cases for automation. The automation is typically purchased from the outside, and the engineer acts as a technical liaison for the outside vendor.

Look at the diagram of the traditional automation process in Figure 9-1. Clearly, the underlying philosophy is to lower labor cost by automating people out of the process. The strategy is to look at a cost-benefit analysis job by job and automate in those cases where it is cost justified. In this way variable labor costs are replaced by fixed capital costs. Some negative effects of this focus on taking out labor through automation are job insecurity, labor-management conflict, and a lot of complex and fixed equipment that has to be maintained. Skilled labor costs often go up, and equipment downtime becomes a problem. Moreover, if sales go down, management is stuck with the fixed technology costs.

From a lean viewpoint the technology is often unreliable, inflexible, and overproduces. It overproduces because it is not completely reliable and the company needs to justify the cost of the technology by keeping it busy. In an environment where large banks of inventory are the norm, this waste is usually ignored as long as the equipment is busily producing parts.

Figure 9-1. Traditional automation process

Contrast this with the lean automation process shown in Figure 9-2. Yet again the philosophy is that overall waste reduction should be the focus. The vision for any new technology is always based in TPS and viewed as a humanmachine system. Equipment must support the people doing kaizen and a lean process. Any new technology must meet a specific need and fit within the total TPS system. Often that means beginning by working to improve and refine the simpler, more manual system. See what you can get out of that system before jumping into a major technology investment. Automating a non-lean system may appear to produce local cost savings but will often add waste and reduce the motivation to create a leaner system, producing more waste in the long term. When you have squeezed what you can out of the manual system, then ask how that system can be further improved with some specific capability. Technology offers one solution to help “meet takt time by flexible, low cost humanmachine systems.”

Figure 9-2. Lean automation process

In Toyota the responsibility for bringing any new production equipment into the plant belongs to production engineering. Learning TPS is part of the initiation of any junior production engineer, and equipment is designed and selected to support TPS. For example, all equipment is extensively mistakeproofed (poka yoke) with sensors designed in to trigger an andon call when there is any abnormality in the process. The level of automation is often designed to support the worker. Chaku chaku refers to equipment that automatically ejects the completed part for the operator so the operator can just go from machine to machine in a cell, loading and picking up the kicked-out part. Equipment is right-sized to fit into a one-piece flow process. Equipment is also designed to support quick changeover. This all leads to the need for highly customized equipment that generally cannot be purchased on the open market. In fact, production engineering develops a good deal of the new technology used in Toyota’s factory. They work hand in hand with a select group of outside vendors who are closely affiliated with Toyota and understand the Toyota Way.

Case Study: Use Right-Sized Not Super-Sized Technology

Economies of scale would lead us to believe that one huge high-tech machine would be more efficient than several smaller and simpler machines. One company that makes nuclear fuel rod assemblies manufactured metal grids to hold the fuel rods in place. After each stage of processing the grids had to be cleaned. A huge washer had pressure and heat gauges and became a bottleneck as metal parts from different processes competed to get washed.

As part of a lean transformation, the grid operation was set up as a cell and the washer was the main impediment to flow, requiring large batches. Process engineering was asked whether it was possible to use smaller and simpler washers. At first they said, “Absolutely not!” But the lean team persisted in challenging them. Ultimately they concluded that an industrial strength dishwasher would work just fine. Several dishwashers could be put in the flow, greatly reducing batch sizes and eliminating the bottleneck.

A similar story can be told when looking at other types of IT systems. Traditional IT design as depicted in Figure 9-3 is a push system. The philosophical assumption is that more information and sophisticated analysis is always better than simple human judgment. IT systems are often based on a management philosophy of top-down control of the process. With the right information and the right analysis method, the system can rationally plan and control the process.

Generic information technology is developed with some abstract purpose in mind and then pushed onto “users” who are expected to make their processes for doing work conform to the business processes implied by the IT. The supposed “business processes” improved by IT are mostly aimed at getting the right data into the IT system (e.g., scanning in inventory every time it is moved).

Figure 9-3. Traditional IT system design

The result is often a narrow focus on improving the IT business processes without closely examining the actual work process. The people become dependent on the system, which is vulnerable to failures. The people stop thinking and start following the dictates of the system. This results in less kaizen and more waste.

The Toyota Way related a story of supply chain visibility software. The software was designed to make inventory visible. When the supply chain group led a pilot of the software, they discovered that business processes in the plants were primitive and undisciplined. There were no good processes for collecting inventory data in real time. As a result, the computer system did not have a realtime picture of the inventory. The computer system was intended to show how much inventory there was throughout the plants and allow vendors to see when the inventory level reached a minimum trigger point so they could ship to bring parts up to the maximum. This was a crude type of pull system. To encourage suppliers to follow the system, a performance metric was automatically calculated, measuring what percent of the time the inventory was kept within the minimum and maximum level.

In contrast, for decades Toyota focused on putting in actual pull systems. They worked to create right-sized containers and racks to hold the containers. Strict limits were established on exactly how many parts would go in each bin

TRAP: Strict Reliance on IT Systems Adds Waste

A typical example of IT in companies is the desire to “track” and “understand” the actual inventory levels in “real time.” Every transaction of material is “scanned” into the system (which is often performed by a value-adding operator—adding to the waste) so they can have “accurate” inventory. In fact this does not work, for a number of reasons—namely, errors and omissions—therefore it is necessary to have full-time “cycle counters” who roam the inventory and audit the levels to verify the overall accuracy and make inventory adjustments. In addition to this costly activity a physical inventory is taken one or two times per year for all items. This is a time-consuming ordeal that may take several days (sometimes on weekends).

In contrast, kanban control the inventory in Toyota, and kanban are monitored. Physical inventory is performed twice per year, and the manufacturing operation is stopped for a few hours, at most, to perform inventory (the storeroom would spend the entire day, since there are numerous items). Overall, the inventory system using “old-fashioned” cards was much less costly and more effective. Recently at Toyota, electronic kanban systems have been adopted for sending pull signals to suppliers and even for replenishing line-side inventory in assembly plants. But there is also a redundant manual system in the assembly plants to give visual indicators of parts usage.

and how many bins could be held in inventory. Kanban cards were printed to match the number of bins that could be produced. No card—no production— no more inventory. Toyota worked on equipment reliability, built-in quality, and operator training. Through continuous improvement, they had so little inventory that there was no real value to collecting real-time inventory data at each stage in the process—this is just waste. In other words, they worked on developing the true process of production and connecting production processes through simple communication vehicles and standard processes. They were less interested in non-value adding “business processes” aimed at getting data into computers. Interestingly, having worked out these manual systems Toyota has evolved to electronic kanban. But these run in parallel to a manual kanban system that provides for visual control yet with the benefits of modern computer technology.

The traditional supply chain software that promised visibility is actually based on a philosophy of top-down control. The belief is that if top management has all the information they need at their fingertips, they can control the system. The kanban system is based on a philosophy of local control. The workplace is viewed as a series of customer-supplier relationships with customers specifying just what they need when they need it through the kanban. Top management are expected to audit the system by walking down to the floor and seeing for themselves (Figure 9-4).

TIP: Always Verify the Actual Condition Yourself

We were working on a particular process to achieve stability and address operational availability issues, and the production planner on the team frequently commented that the process was “behind.” Observations on the floor revealed that there was no work waiting to be processed. From a traditional Toyota standpoint, an operation can’t be considered behind if an upstream process is starving it or if the customer process is full. This is all visual, and easy to determine by looking at the work area and observing the connections between operations. Confused, we asked the production planner to explain how the machine could be “behind.” The answer was, “That’s what the system says!” meaning that the MRP planning system showed work that was scheduled to be complete at that operation and wasn’t. Simply using system information without corresponding process information can lead to false assumptions and misguided efforts to correct the “problem.”

Figure 9-4. Lean IT process

As described in the Agillence software case earlier in the chapter, new IT faces a high hurdle at Toyota. The process used for adopting the Agillence software is typical at Toyota and follows the flow of logic in Figure 9-4, above, for a lean IT process. It is not enough to show in the abstract that IT can automate a process or provide more and better information. It must be clear how it will

add value and support a well-thought-out and time-tested process. Typically, the process is done well manually before it is automated. The technology supports human decision making—it does not replace it. And the technology should not be used as an excuse to stop thinking and lose a focus on kaizen. Instead, the technology should support people in waste reduction.

Keep Technology in Perspective

Toyota is an engineering-driven company, and deep down it is a technologybased company. Innovative product and process technology is at the core of Toyota’s success. But people are at the core in creating and successfully implementing innovative product and process technology.

The case below illustrates how “the process and people make the technology valuable.” In this case a competitor we will call AmCar got considerably ahead of Toyota in technology for automating product and process design. Presentations that featured things that Toyota was not capable of doing made even Toyota a bit nervous. But the reality was far different from the hype. AmCar was not using the technology effectively and was falling further behind Toyota in development lead time, problems in new vehicle launch, and in quality. It was only after AmCar hired former Toyota employees who taught them the Toyota Way of using this technology that they began to make some positive strides.

So, again, though technology plays a critical role at Toyota, it must always be kept in context. Technology is a critical piece of the system, but the system is not just how pieces of technology fit together. The system includes the process of doing the work and the people who work in the process. It is not only a matter of what technology is selected, but of how the overall system is designed and implemented. And it is important enough to carefully plan and consider in the context of your broader philosophy of how to run the business.

Case Study: The Process and People Make the Technology Valuable

In the early 1990s the U.S. automaker we’ll call AmCar began the drive toward using manufacturing simulations in the product development stage. The goal was to use computer technology to help design products that optimized the manufacturing system. Several software packages were available at the time. Delmia began to emerge as the leader in the design software race with their CATIA package, and AmCar made a commitment to this technology. There were many modules available in Delmia’s software suite, but AmCar took a product-developmentcentered approach, focusing on design packaging—how the parts fit together without interferences in the space available. For manufacturing,

the emphasis was on factory layout. Specific designs for process equipment were outsourced to suppliers who took primary responsibility for the equipment designed and did not have close interaction with the product designers.

The early promise of a truly integrated design and manufacturing system was not realized. And there was little integration between the primary functional groups (including Procurement and Supply—a large majority of component suppliers also inherited primary design responsibility for components/systems). Teams would review packaging issues, often only within functional areas (e.g., Body Engineering), and start the process very late (long after design freeze). The result was an inordinate amount of late discovery and change to both process and components, delaying product launches and leading to a long ramp-up time. In addition, there was little focus placed on developing an integrated cross-functional design review process (simultaneous engineering). The priority was placed on developing the technology, and progress became stalled despite the advancements made in software.

In 2000, a team of new employees was recruited from Toyota’s North American operations to support quality improvements as a part of an effort to turn around AmCar, which at that time was losing money and struggling with severe quality problems and warranty costs. One of the Toyota employees who had experience managing product launches immediately noticed there was little activity in using computer simulations to anticipate manufacturing problems in the product development stage. Toyota called these “digital build” simulations. The car was, in a sense, built on the computer virtually, and cross-functional teams carefully evaluated problems in manufacturing and assembling the car, using Toyota’s rigorous problem-solving methodology.

In late 2001 the Toyota TTC (Toyota Technical Center, Ann Arbor) participated in a joint technology sharing session with AmCar. Toyota representatives were surprised at the lack of advancement in digital design—a benchmarking session conducted in the late 1990s led Toyota to believe that AmCar was advancing rapidly in this arena.

Toyota indicated that this activity was a key enabler in reducing their overall development lead time.

In early 2002 another more detailed gap analysis resulted in the recommendation by AmCar senior management to pursue the simultaneous engineering (SE) and digital assembly (DA) process. To support this, in 2002 a more stringent issues-management process was implemented, along with intense pressure to complete design/process freezes, validation activities, and overall product/process changes much earlier (using Toyota processes for each item). The groundwork was being developed to increase the level of discipline required to support SE and DA.

In late 2002 the SE and DA draft process was completed, and in early 2004 a pilot was selected and implemented. The initial process focused on the business process and behavioral aspects —not technology.

Digitized photos of the parts were pulled into CATIA, and digital models of each station were created. Participants included all Engineering/Design areas, Advanced Manufacturing, Procurement and Material groups, representatives from the manufacturing plants, Quality Groups (Service, Warranty, Error Proofing), Ergonomics and Safety, and Industrial Engineering. The activities started several months prior to design freeze and continued up to the initial prototype builds (three phases). The events were very intense, and over 2,000 issues were generated in the pilot. An issues-management process was started immediately at the same intense level to record any issues observed and assign strict responsibility for their resolution by specific dates.

Initial metrics looked promising. The prototype builds for the pilot went more smoothly than usual—several significant issues were discovered and countermeasured prior to the start of prototype. The issues curve for the pilot was initiated almost nine months earlier than in previous programs. As of this writing, it was too early to have data on lead time and other performance metrics, but everyone agreed that many problems were resolved very early and launch would be much smoother.

What is interesting about this case is that AmCar was a leader in the use of CATIA technology, and as noted earlier, even Toyota was getting nervous. Yet they then fell significantly behind Toyota in the actual use of the technology. Some of the lessons that AmCar learned with the help of their recruits from Toyota were:

1. An effective process should be supported by the technology instead of trying to replace the process with the  technology.
2. Build discipline through other standardized activities, then apply the discipline to the process.
3. Cross-functional involvement and input at the lowest decisionmaking level will lead to better use of the information made available by the technology.
4. Create a pilot/learning line to simulate results: test, test, test, then roll out.
5. Create a pull from senior management through results and supporting data.
6. Continue to kaizen the process.

Reflect and Learn from the Process

1. Is your company caught up in the technology race?
2. Do you believe that having the latest, fastest, most sophisticated technology is necessary to maintain a competitive advantage?
3. Have you lost sight of the fact that the purpose of technology is to serve the people and the processes?
4. Do you look to technology to solve problems, or do you identify effective solutions and then apply technology to support people (reduce the burden)?
5. Have you invested heavily in technology, only to find that the overall performance has not improved and now it is difficult to abandon the system because of the expense (or admitting failure)?
6. If you have any technology proposals on the table right now, reevaluate the situation and request the proposer to verify how the system will support the people:
   1. How have they involved the users of the technology in the design of the technology?
   2. Have the proposers practiced “genchi genbutsu” (go and see the actual process) and studied the way the current process is being conducted today?
   3. Have all attempts been made to take waste out of the current process before proposing new technology?
   4. Has a close relationship been developed with the IT provider so they will work to customize the technology to the people and process?
   5. Has a pilot been planned to prove the technology prior to full-scale implementation?