For Want of a Nail (Part III)

(This is the third part in a series; see Part I , Part II and Part IV)

In the previous installment we saw how neither the human operators nor the computerized information system had a clear, timely understanding of what inventory was meant to be in a specific location or reserved for a specific purpose. The material handling processes in place did not conform to the principle of visual control (“mieruka”). Although the system was intended as a form of kanban, it did not conform to the principles of kanban because the role of the spare parts pickers had not been considered, and there was no visual feedback for them. This could also be considered a lack of mistake-proofing (“poka-yoke”), and potentially a lack of “5s”, specifically Sort and Set In Order, again from the perspective of the spare parts picker who had no means to distinguish parts available for shipment and parts reserved for production. It also should be considered a dangerously incomplete IT systems implementation of a process, but a reliance on IT systems to “make things work” is itself not understanding the principle or benefit of visual control.

Today’s episode has to do mainly with leveling (“heijunka”). Leveling is always a sore point in implementing a Toyota Production System based process because it is in direct tension with the principle of responding to customer demand. There isn’t any case where customer demand is level and unwavering; even for oxygen, although we are always breathing, as we need more oxygen when active or excited than when resting.

But leveling is fundamental to quality, or more specifically to being able to observe whether results are in line with expectations. If you expect your production line to produce 100 units every day, all of the workers should be working at the same pace every day, and you should minimized if not eliminate mistakes caused by rushing. Further, without having a standard pace for the entire process, it is all but certain that some parts of the process will be able to operate faster than others, and the faster steps will accumulate work in process behind the slower processes. The extra inventory allows the faster process to “hide” errors by recovering while the slower process catches up, a short-term success that obscures the potential for small problems to grow into big ones.

In this particular factory, leveling production was made difficult by the large number of different end products, some of which had constant demand (although varying in total volume) and others with only occasional demand. If the occasional-demand items would politely take turns the production could be leveled and still tied directly to demand, but of course this serendipity was not reliably present.

So the basic system for moving components from storage to the production line relied upon a crew of material handlers to monitor several assembly lines and restock all of them as needed. Most materials we provided via a “two-bin” system: in concept, you start with two full bins. When the first is empty, it is taken away and refilled before the second is used up. (Sometimes more than just two bins are used.) Because the bin quantities were not all aligned to have enough parts for the same number of finished products, and because some parts were used in common across several end products (but other components were not), the rate at which parts would need to be replenished was not reliable. A change-over from assembling one product to another would mean refilling many bins simultaneously; if several lines needed to change over at around the same time, work might back up considerably.

Further, since production lines might build a number of different products and not all were built equally quickly, and not all lines were always producing, there was drastic variation in the level of support needed from material handlers. At the end of the month, and especially at the end of the quarter, pressure to build as much as possible went up sharply.

To compensate for the changing work load on the material handlers, the more senior members of the assembly team were also authorized to retrieve components from storage. When the urgency to maximize production was greatest, production planners (typically responsible for balancing available component parts with current final product demand, a desk-based job) would assist in moving components to the line so that none of the potential builders would lose time moving parts.

The production people were trained, expected, and performance measured in terms of production of complete products. Precision in counting and handling component parts was not part of how their success was evaluated in any direct way.

When parts arrived at the last minute, material handlers (full time or temporary fill-ins) would retrieve the parts directly from the receiving dock, before they had been counted, quality checked, or received into the system at all. Combined with the other uncertainties afforded by the process, the question of how much of an item was available and where it was stored was always unclear.

Several component parts were springs, or spring-like items, which could easily become entangled with one another. These parts, and all small, lightweight parts, were shipped in bags or boxes. Taking parts out of storage, or out of a bin during the assembly process, is very likely to involve pulling out more parts than desired; disentangling was not a straightforward process, and it could be expected that one or more parts could drop off, roll, or bounce into places unknown. These were always small, cheap parts; when pressure was on to build, build, build, it hardly seemed worthwhile to spend time chasing runaway parts. There’s always tons more in the bin.

Ultimately it was not clear how often dropped parts caused shortages versus parts not ever being shipped. Most small, light parts were shipped loose packed in bags or boxes and the count of pieces in each bag or box could vary. The suppliers would write on the box the count, but there was no routine verification by weight. Checking by weight as parts were removed was complicated by the light weight of the parts; they weighed little enough that plastic or cardboard would count as significant number of parts.

It would be relatively straightforward to establish the weight of the parts, establish a minimum stock by weight, and write off the continual shrinkage due to dropped parts or undetectable short shipment. But the parts were bought and tracked by each, and the each-count was always off, and so production was halted for small, cheap parts as often as it was for large expensive parts.

Better than allowing dropped parts and potentially short shipments would be designing purpose-built containers using rods or grooves to keep parts in a consistent orientation, clearly marked with a weight corresponding to an exact count. While it would require a modest investment to design and produce the specialized containers, and possibly working with the supplier to help establish a reliable process to transition the parts from their production equipment to the containers, the payback in reduced uncertainty would have paid back such costs.

For want of a nail, the shoe was lost;
For want of the shoe, the horse was lost;
For want of the horse, the rider was lost;
For want of the rider, the battle was lost;
For want of the battle, the kingdom was lost;
And all from the want of a horseshoe nail.

 

Reservations Regarding Inventory (Part II)

(This is the second part in a multi-part series. See Part I, Part III, and Part IV.)

One of the most frustrating, recurrent problems that would cause late delivery at this company was a part shortage on an assembly line because the parts had been shipped out as replacement spare parts.

This was not a true root-cause problem because if the total count of parts on hand were accurate, the most harm that could be caused would be a slight delay as parts were moved from one place to another. But, through a combination of several different system configuration decisions and limitations, it was quite common for the same item to be stored in more than one location, and quite common for the location-specific inventory count to be wrong even if the the total count were right, and quite common for the system to indicate that inventory should be taken from a place where it actually no longer was.

How did it get so bad?

The simplest way to provide component parts, widgets let’s say, for assembly into a finished product (gizmos) is to keep large quantities of widgets on the shelf and pull some out of inventory when you need to build a gizmo.

The Toyota Production System teaches that it is not good to have widgets sitting in boxes on the shelf. There are many reasons to consider this wasteful – the extra time it takes to put things up on the shelf in storage and then get them back down when needed, the overhead costs of paying for the floor and roof and shelving for the inventory, the risk that at some point the design of the gizmo will change and the widgets will no longer be useful, and so on. American business managers will usually mention the cash tied up in the inventory that can’t be used for other purposes; I consider this is the least important reason from a Toyota Production System perspective.

Under the Toyota Production System, the worst thing about having many widgets on the shelf is that they will allow you to continue on as if nothing is wrong even if any number of things go wrong: your customers order more than you expected, you break more than you expected while trying to use them, your supplier is later than expected, and so on. A problem you don’t notice is a problem you don’t fix. Since inventory will cover for almost any problem, it encourages people not to fix any problem–it makes it difficult to tell that there is any problem at all.

It would be best if the widgets appeared exactly when needed, and no sooner. Reality being what it is, nobody has managed to apply this theory throughout their entire supply chain. But, if you want to be like Toyota, one of the first things you will do is direct your factory to use a “pull” system rather than a “push” system.

A “push” system is like wood in wood chipper, gravel on a screen, water in a tub, or paper in a paper shredder. The work gets loaded on in a big batch and you try to get through it as quickly as possible. Your job is to get rid of the work and the faster you do it and the more you do the better job you have done.

A “pull” system is a bit like a vending machine or a grocery shelf with a spring loaded pusher. Right up in front, clearly available and ready to take, is one item; as soon as you take it another one appears. Of course in a vending machine the whole load is put in all at once, but in concept a “pull” system has exactly one of everything ready to immediately replace one of whatever is taken.

It is impossible to have a perfect end-to-end pull system in a world where there is weather and friction and, ultimately, time. But as an ideal concept it is a great reminder that making more than is wanted is waste. Make exactly what is wanted, when it is wanted, and no more.

The conventional, “common sense” way to run a factory is to order 1,000 widgets (the widget factory makes them in batches of 1,000 and you get a better price per each if you order in that quantity) and put them on your shelf. When you want to make 50 gizmos you create a production order and 50 widgets are taken off the shelf and brought over to the gizmo assembly line, and then the gizmo assembly line tries to build 50 gizmos as fast as possible. It is a “push” system because the assembly line reacts to having inventory dumped on it by building as fast as possible.

In an idealized “pull” system, there is one finished gizmo sitting at the end of the line. The last worker on the assembly line has an almost-finished gizmo, and each of the other workers has a gizmo in a successively less-finished state. When a customer orders a gizmo, the finished one is picked up off the end of the line and handed to them (or shipped to them). As soon as the finished gizmo is picked up off the end of the line, another gizmo is immediately finished and delivered, and every in-process gizmo moves forward one step, including the step where the widget is used.

To approximate this ideal process, you can store the widgets right there on the assembly line so that the widgets are removed from “storage” one at a time, by the worker on the line, as they are needed.

Production control software was traditionally not designed around that kind of thinking. Production software is used to consuming all of the component widgets when the order to build gizmos is first released. Clever people came up with a work-around whereby the computer system would be told when a complete gizmo was finished, and since a gizmo was finished the system could then correctly infer that one of everything that goes into a gizmo must have been used (including one widget). Rather than consuming the inventory in advance, the system effectively backtracks to correct its own records of how many widgets are still on the shelf. (“Backflushing” is a common term for this backwards flow of information.)

Now, all that was just to set the stage for one of the more interesting problems that came up. Some years before I had become involved, the company had decided that widgets needed as replacement parts should be shipped from the factory making gizmos, rather than from a separate spare-parts warehouse. Why keep the same stuff in two different places? Why ship twice, first to the warehouse and then to the customer?

But in this factory’s version of the “pull” system, widgets were moved in small batches from storage to the assembly line, to approximate as much as possible a one-piece pull system. Since it wasn’t literally a one-piece flow system, sometimes there were more parts in the bin than would actually be needed. On the other hand, for larger quantity builds, the bins would be refilled several times from stock. The computer system was only told after the fact, when all of the gizmos were built, to remove the corresponding number of widgets from inventory.

So when a customer wanted a spare part (or two, or ten, or two hundred), and when they didn’t find the parts in the warehouse, the parts picker would go to the assembly line and take the parts. Then the assembly line would run out of parts and not be able to finish making gizmos.

Fundamentally this was an inventory accuracy problem. The production control system was still checking to make sure there was enough widgets in total to meet all of the needs. But, because it was neither a true one-piece flow system nor a conventional “push” system where all the inventory on the line was truly committed for a production build, it was never visually clear to a parts picker which parts were “really” needed for a build versus just moved to the line to follow the rules of the “two-bin” system.

That it was not visually obvious to the spares parts picker is an immediate red flag from a Toyota Production System perspective. But the “Lean Manufacturing” improvements had been implemented for manufacturing, without consideration for the spare parts process. Basic problems with inventory control were amplified, both in terms of the actual physical effect but even more importantly in the frustration and ill-will the misalignment of processes caused between assembly workers and spare parts pickers. With neither clear visual process control nor up to date and accurate transaction records, it became impossible to tell where the problem started.

The whole mess was a combination of problems, beginning with the batch-based rather than one-piece backflushing, compounded by the keeping inventory in more than one place, and complicated by shipping spares out the same facility and inventory as production. But it all could have worked if the inventory handling had been flawless. Instead, for many parts, it was difficult to tell how many parts actually were in a package from the moment they first arrived in the building, and it didn’t get any easier after that. This is an example where one of the most fundamental Toyota Production Systems principles, “set in order,” was lacking. I will revisit the topic of parts handling and presentation in a later post.