I saw a discussion posting on the Supply Chain Movement discussion group in Linked-in. The discussion was around the fact that a company had difficulty getting accurate forecasts. To compensate, they’ve been increasing their buffer inventories and were looking for metrics to monitor their inventory levels. There were many suggestions around the best metrics to track and a couple suggestions for increasing forecast accuracy. All great stuff. I had a different approach that I thought I would discuss here.
As was pointed out by one of the commenters, there are strategies to improve forecast accuracy that should be explored. The problem is that no matter how much you try, the forecast is always going to be inaccurate to some degree. Traditionally, we would add buffer inventory to cover the demand fluctuations, but this is expensive. So how do you deal with forecast variability and reduce inventory costs? It comes down to your ability to respond when changes occur.
There are two factors to being able to improve responsiveness; 1) Reduce replenishment lead time – Use lean techniques to evaluate your value stream and reduce lead times. Most inventory levels are maintained to cover demand during lead time. Safety Stock formulas use variation during lead time as a key factor. Reduce your replenishment lead time and you can reduce inventory levels. 2) Reduce the lag between sensing a demand change and reacting to it. In other words, how long does it take before the event (a new order in excess of forecast for example) is recognized, the impact understood and an action plan is in place?
In many traditional systems, this can take days. This is time lost before the supply chain even knows about the change! Why so long? Traditional ERP systems perform planning in a batch process that can take hours to run. Often, this means MRP processing is run daily or sometimes weekly. This means that an order added first thing in the morning doesn’t get visibility beyond the top level assembly until after the next day. Then we still need to determine if we can accommodate the change and if not, what changes need to be made to the plan to make this happen. Traditional ERP tools are just not responsive enough.
What is needed is a response management tool. A response management tool provides visibility to the entire supply chain, models and emulates the ERP logic in each ERP system in the supply chain, allows the creation of simulation scenarios to try different response approaches, provides collaboration capabilities to bring those that can contribute together quickly, provides reporting tools including comparative scorecards that allow you to evaluate the impact of a change and the effectiveness of your solution. Finally, once the decision is made, a response management tool allows you to communicate the changes throughout your supply chain so that all are in alignment.
Reducing your replenishment lead time and improving your ability to sense and respond to changes in demand can result in the ability to absorb some amount of forecast error while lowering inventory levels.
TrackBack
• Digg This
• Add to del.icio.us
Tags: Forecast, Inventory, Supply chain visibility
Posted in Response Management
You can leave a response, or trackback from your own site.
Good point John. Considering the complicated nature of the distribution chain and the huge number of independent entities involved it would be impossible to consistently forecast accurately. Yet it is sad that instead of changing their process I see companies recklessly investing in odd forecasting tools. Even the response management tool that you suggest will have limited impact.
Solid article. I agree totally that shortening your time frames is an essential part of protecting yourself against bad forecasts (as are collaboration with the forcaster to help them develop better forecasts). Another way to do this is to engineer the living daylights out of your manufacturing process. Often this results in a significant reduction in shop lead times which can make your build process much more agile.
I don’t think though that we can lay the blame for this on the ERP systems. I have worked with a number of such systems and generally the decisions that lead to a two or three day lag between the arrival of an order and it’s recognition by the ERP system are due to management decisions. We don’t want to run MRP every day because we don’t have processing time (that can be fixed), we don’t want to run MRP every day because we don’t have the staff to review it (duh), we don’t want this, we don’t want that because it’s not the way we have done things. I think most traditional ERP systems are even able to run ERP on the fly.
It just seems that most of the time, the real corporate enemy is not software systems, but rather the company itself.
Thanks for your feedback, Dave. I wanted to respond to a couple of your points. I completely agree that engineering your manufacturing processes can reduce shop lead times and make you much more agile. The challenge many companies are facing today is that the manufacturing process has been outsourced in part or in total. In this scenario, the latitude a company may have to improve agility by reducing lead times is limited.
I think we are arguing a similar point when it comes to the problem with ERP systems. You are correct in saying that management doesn’t want to run MRP every day because of the processing time. Typical ERP batch processes run in hours not minutes. Even if we could run MRP continuously, the impact of the order drop in wouldn’t be understood for hours. What’s needed is to be able to run MRP in seconds. Imagine the world if you had that kind of information. You could drop an order in and see instantly what changes need to be made. You could try different resolution options and see immediately if they would work.
You’ve hit on another key aspect…we don’t run MRP every day because we don’t have the staff to review it. The problem with traditional MRP tools is that it is very difficult to prioritize the actions that must be taken. I remember in my manufacturing days taking planner reports in the thousands of pages and passing them around to the individual planners knowing full well that there was no way they could work all those issues. What’s needed is a prioritized list of actions that is always current. As you finish one action, the next one to do is one which will potentially cost your company the most. You may never get to the small reschedule-out actions…but you are always working on the issues that will cost your company the most if it’s not taken care of.
A well written and very accurate article. It has been my experiance that supplier lag time is the one variable that can affect lean processing the most. I understand why companies increase “buffer” inventory. You can engineer your processes to death, but if your suppliers cannot deliver on a consistant basis, it’s all for naught. Also, some companies ( one inwhich I have worked) are reactionary instead of proactive. Always closing the barn door after the horse is out. Forsight, scheduling, and a well thoughtout plan, are essential for quality MRP processes. As far as change, it is human nature to resisit change. However, change must be embraced in the Supply chain aspect of todays business world.
This is a little late but I wanted to respond to John’s comments.
I agree with what you say that many companies, because of outsourcing, have given up the ability to control the lead time. But, that was a decision that these companies made. I believe very firmly that today we think very linearly. Someone comes up with an idea that we could save money by outsourcing or something else and all of a sudden we are subordinating every other concern to that. I think we are beginning to see a reaction to the outsource everything mentality, but bottom line – I don’t buy into the ‘victim’ lifestyle. Companies are responsible for their decisions. Take control of your life and make it what you want it to be. Realize that everything has it’s costs – not just wages.
Second, I don’t believe I ever said that companies don’t run MRP every day. Most of the clients I have run MRP every day. In the software system I work with a full MRP run (on the AS/400) takes about 45 to 75 minutes so running it every day is no problem. The trouble is we need to be able to run MRP in an on demand (yes, like we get movies), and at the ‘what if’ level. This is something that mainframe MRP systems could do (via a net change run) but what screws it up is record locking which is a serious issue on the mainframes (and not so much when you are using a copy of the data on a PC system). And that is the real problem with mainframe based MRP systems. They are fast enough, they just can’t do a good enough job with me running a dozen ‘what if’ scenarios in a row as a planner. Just a clarification.
By the way – I like the posts you guys put out. Good solid thoughts there. Too many of the posts are just fluff. Keep up the good work.