I accompanied the University of Michigan’s Dean of Engineering on a trip to Japan some years ago and one of our hosts was Mikio Kitano, who at that time was overseeing the Motomachi complex—Toyota’s largest industrial complex. My Dean was asking a lot of questions about the use of information technology at Toyota. Kitano seemed a bit impatient. To make a point to the Dean he pulled out a typical information system design flowchart with all the usual IT symbols—information flowing from computer to computer, storage devices, input devices, output devices, and the like. It had been given to him some time earlier by a Toyota IT specialist as a proposal for the Motamachi assembly plant. He said he sent this flowchart back along with the IT guy who brought it to him and told him, “At Toyota we do not make information systems. We make cars. Show me the process of making cars and how the information system supports that.” He then pulled out a large process flow diagram that the IT guy had produced in response to Kitano’s demand. The top showed the body, paint, and assembly lines representing how Toyota builds cars. The bottom of the diagram showed various information technologies and the way in which they would support the production of cars. As far as Kitano was concerned, the process flow diagram showed IT in its appropriate place—supporting the production lines.
Toyota has had experience with pushing technology that is the latest and greatest, only to later regret it. One example was an experiment 10 years ago in Toyota’s Chicago Parts Distribution Center, where the company installed a highly automated rotary-rack system. At the time the warehouse was built, Toyota’s dealers placed weekly stock orders for parts. But soon after the warehouse was completed, the company implemented daily ordering and daily deliveries to reduce lead time and lower inventories in the dealerships. When the process changed from a five-day to a one-day shipment cycle, the equipment was inflexible and suddenly outdated, because the fixed conveyor length was designed for larger orders. So the smaller daily orders should have filled the smaller boxes much faster than the larger five-day boxes of parts but the person at the end of the conveyor still had to wait for the parts to come down this long conveyor. The person spent a great deal of time waiting—one of the eight wastes. The benefit of the technology was short-lived and the Chicago facility became one of Toyota’s least productive warehouses. In 2002, the company again made a significant investment in Chicago, but this time it was to remove the automation and unwind the computer system that supported it. By comparison, Toyota’s most productive regional parts depot is in Cincinnati, where there is very little automation.
When you live in the logistics world, nothing moves without information. But, we’re conservative in our approach to applying automation. You can kaizen people processes very easily, but it is hard to kaizen a machine. Our processes got far more productive and efficient, but the machine didn’t. So, the machine had to come out.
In 2002, Toyota’s Parts Distribution Centers completed a two-year systems initiative known as the Monarch Project to improve its demand forecasting and inventory planning. A joint team of logistics experts and information systems specialists spent a year identifying which components of the legacy systems worked well, which components needed an upgrade or replacement, and what new functionalities needed to be added. The focus of the Monarch system is to work behind the scenes supporting a visual system on the floor so people can go and see the actual situation. As Beseda described it:
From the warehouse person’s perspective, sitting and looking into a computer screen doesn’t tell you everything you need to know. You have to have a feel for the size of the parts and the real situation in the warehouse. The computer recommends an inventory level to the procurement analyst, but it can’t tell him if the inventory will make life tough for the person on the warehouse floor because there isn’t enough space to store it.
Procurement analysts are located at the parts centers to encourage on-site observation and frequent communication between the inventory group and warehouse operations. The two groups often collaborate to empirically refine the inventory levels of problem parts. The stockkeeper monitors the actual movement of the inventory by putting a large label on each carton and noting the date. If there is demand, the inventory is available to ship. If the dates show that inventory in some cartons is not moving, the stockkeeper and the procurement analyst can safely agree to lower the inventory level. This simple visual control is a practical way to save space and reduce clutter. The procurement analyst relies on the computer-generated stock level, but supplements the system recommendation with his or her own judgment and direct communication with the shop floor.
As Beseda observed:
First work out the manual process, and then automate it. Try to build into the system as much flexibility as you possibly can so you can continue to kaizen the process as your business changes. And always supplement the system information with “genchi genbutsu,” or “go look, go see.”