Thieves in the Temple – Errors in the Planning-Execution System

Here’s a quick look at how to identify and fix errors in planning execution systems

“My experience has shown that most companies vastly underestimate the number of errors that occur in execution systems.” Supply Chain Collaboration, Ronald K. Ireland with Colleen Crum, J. Ross Publishing with APICS, 2005, page 66.

After reading this, I downloaded everything I could from our demand management system to check my assumption. They were right. I saw missing replenishment types, ship to warehouse assignments, missing Ship to City/Country information making it impossible to assign an order to the proper customer as well as many duplicate entries for the same intended Ship to Customer and customer code. In addition, multiple cases existed where the data element was left as unassigned. And what about history transfers to update forecasts for phase-out products to phase-in? Customer name changes? Warehouse changes? Customer movement to another warehouse? Sourcing changes?

What if these errors occurred in other planning data such as lead time, transportation lanes, and product family assignments? What effect does this have on forecast error? What if the product hierarchy contained errors sending forecast volume to the wrong product code?

Simply put, replenishment goes to the wrong warehouse, or to none. Forecasts do likewise and immediately I began to realize Maxwell’s demons.

Rejoice! I realized the remedy for these self-inflicted wounds.

Make them visible.
Show the effects.
Report monthly to Planners for correction.
Summarize results (data in context).

Identifying and Fixing Planning Errors in Execution Systems

Make Errors Visible

Download the planning and product hierarchy data to search for:

UA (Unassigned) data elements (as in replenishment type, product code, Ship to Customer, City)
Illogical data (E.G. if the lead time to Boston=7 days, why is 17 days there for this data element?)

In this exercise use test logic to make UA and illogical data stand out. ((IF A13=”UA”, “UA”), or seek multiple customer codes for the same customer, or different spellings for the same customer.)

Show the Effects

Many of these data elements come with a volume in UOM (unit of measure) and COGS (cost of goods sold) to show the cost of mayhem. Multiply the UOM forecast by COGS.

Dollars associated with UA replenishment types, duplicate ship to customer codes, country, city
Dollars associated with misaligned product codes (shows up in S&OP as ammunition for naysayers who discredit forecasts and the S&OP process)
Unassigned descriptive data adds to the confusion in assigning volume during analysis. Bad data will offset any downstream analysis which may affect policy and programs of continuous improvement.

Report monthly to Planners for correction

Agree on a format and report data errors in sum with specific detail for correction. Use charts and graphs with the same format from month to month for comparison. Be specific for repeat offenders in terms of defect type, category, and even actual defect. After a few months, this may be used to show the areas of greatest improvement, Pareto style.

Summarize results (data in context)

An added task for the manager would be to create a dashboard in the form of a chart to show data in context. Reporting one month at a time draws a red flag to management. Are you improving or not? Relative to what? Or is this a form of deception?

Keeping in mind the volumes and cost, this discipline shows a compelling argument to trust the forecast and data for its derivation, as well as an assurance that it’s not driving replenishment to the wrong customer in the wrong warehouse.

Lastly, managers should know to use this process for improvement and not persecution. It’s difficult to create a mature, creative work environment when you’re working in fear.

One final note.
This blog concerns mostly planning data and not transactional data.

Enjoyed this post? Subscribe or follow Arkieva on Linkedin, Twitter, and Facebook for blog updates