Solving the unflushed inventory problem

Just over a year ago, I wrote at length about unflushed inventory. In the year that has passed since then, I have been fighting a mainly unsuccessful battle in order to raise public awareness of the problem. Suddenly, a solution appeared about a month ago.

I was talking with our company's ERP consultant about one of the problems inherent with bills of material (BOM): the BOM tells us how much it costs to make a part and whilst also providing the raw input into the manufacturing process. There have been times when I have needed to divorce these two functions. Even though we have discussed this before, the consultant hadn't provided any kind of solution, but this time he mentioned, off the cuff, that if I mark a certain flag in the parts table, then the part will not be sent to the production floor as a result of a production order.

There are parts whose BOM contains virtual parts such as royalties. We need the BOM to contain the royalty because this contributes a certain amount to the cost of the final product. On the other hand, negative inventory of this 'part' builds up every month which only serves to confuse the inventory system. Once I marked this royalty part with the special flag, it carried out its costing function without interfering with manufacturing. 

Such a small change can produce large gains.

Thinking about this a few weeks later,  I realised that this flag held the key to solving the unflushed inventory problem. To recap: ERP's work order (based on the BOM) says to use a certain amount of raw material (wood), but via the use of an external optimiser, the workers are able to produce the same amount of finished product with less than the dictated amount of raw material. This causes problems with stock keeping and creates what Priority calls unflushed inventory. 

For a while it seemed as if Priority was ignorant of the output from the optimiser, but then I realised that there was a 'warehouse transfer order' entered into Priority which transferred the required amount of wood planks from the raw materials store to the factory floor - this order is the optimiser's output. After some more cogitation, I realised that I could utilise this order: I could convert it into the list of parts which had been removed from the factory floor, consumed by the production process. In other words: the optimiser would cause X amount of planks to be sent to the factory floor, then my program which would remove those X planks as if they had been consumed normally. As the plank parts had been marked with the special flag in Priority, the fact that the default BOMs required Y planks became totally irrelevant.

The required program took a few iterations to write correctly, but after a few days it was working perfectly (it is now run automatically every evening). Every day I check the inventory of the shop floor in order to ensure that no wood planks are listed; if there are, then I correct the faulty definition of the plank in the computer in the knowledge that the plank will be removed from inventory the next time that my program runs.

Thus the unflushed inventory problem has been solved ... at least, as far as wood is concerned. There are still far too many parts to be found in the unflushed inventory, but as most of those parts seem to be screws or similarly small and insignificant parts, I can't get anyone interested in the problem.