A great article in the July issue of APICS magazine by Craig Schrotter, CPIM points out how a simple procedural method employed for all the right reasons can degrade into a ludicrous example of what he calls ‘procedural inertia.’ We’ll try to encapsulate his extreme example below while holding to the gist of it. It’s worth working through.
Imagine this scenario in a typical manufacturing and distribution business: A completed item ‘A’ needs to wind up on shelf ‘B’. Simple enough, right? A procedure is developed to ensure this transfer occurs consistently. But now the procedure must work with the company’s ERP system, which stipulates the Inventory module be used to process the receipt from the shop floor, describing in detail each field and mouse click needed to tell the system Item A has been received from a work order and put on Shelf B.
But what if the person writing the procedure had an incomplete understanding of the ERP system? What if they didn’t know the Inventory module had a feature for receiving materials from work orders into specific locations? The resulting procedure might call for an inventory transaction that simply adjusts the quantity of A into shelf B, rather than performing an actual receipt.
Now, the quantity of Item A would be correct but the work order producing it could not be closed for lack of a completed production receipt. So, a new procedure would be written calling for each work order to be manually closed once it’s received into inventory. But without closing work orders as the ERP system expects, item A would not be properly updated, and while the inventory might be right, the value would not, and would eventually become meaningless. (You see where this is going…?)
To address the apparent “flaw” in the system, yet another procedure would be written to calculate costs outside the ERP. The procedure would involve a spreadsheet, manually updated upon receipt of each work order for every item. Someone would have to determine costs of material and labor, and then input these into the spreadsheet. And of course, there are hundreds or even thousands of such items. Thus, the spreadsheet becomes a workbook of many sheets. The staff required to maintain all this has grown from one person spending an hour to a full-time employee.
It gets better: What if item A was the top level item in a complex bill of materials? Now, the cost of all the subordinate items would also have to be updated. And what about those items’ subordinate items? Pretty soon, we’re talking about some real added labor required to track all the changes, and record all the processes. And then let’s not even talk about what happens when a mistake or two is found.
Then one day, a new manager arrives, who can’t believe that such a simple procedure can devolve into this complex, cascading litany of procedural dark holes. So he contacts the ERP consultant, who quickly recognizes the problem and explains the proper methodology that should have been used in the first place!
But a whole culture, as author Schrotter puts is, has grown around this procedure, with dozens of reports pointing at these spreadsheets, all central now to purchasing and planning and sales. Dismantle the system? Impossible!
And that’s procedural inertia.
In the second half of our post, we’ll look at what to do about it. Stay tuned…