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.