Feeds:
Posts
Comments
I was recently asked a question regarding the advantages and disadvantages of DP. I thought I would take part of the email exchange and post it here.
______________________________________________
Questioner:

I would be interested in knowing how DP is different from demand planning in Manugistics.
Especially:
1. Weaknesses
2. Strengths
3. Level of integration with supply planning (eg ability to effectively measure forecast consumption)
4. APO suitability for products with short life cycle (eg movie/music DVD)
Shaun:

Well, ok here is a more technical reply. I will think on it, I have articles you can read already to get a general background. Here are the DP related posts on sapplanning.org
http://sapplanning.org/2009/05/22/dp/
However, I am not sure I get the short life cycle issue. As you are well aware, there is nothing new under the sun in forecasting, DP uses the same forecasting approaches that you have seen a million times, and has an auto select feature like everybody else. The main thing about DP is that it is difficult to configure because it uses the Data Warehouse Workbench and requires the learning of an entirely new vocabulary (InfoObject, InfoProvider), and a strong tolerance for pain to administer. It can forecast short or long term, like any other forecasting system. So what do they mean by applicability to short term forecasting, is there some trick or method companies who do short term forecasting use? SAP F&R, which is replenishment focused handles short term forecasting by allowing store managers to input their order amounts, and decentralizes the ordering and short term forecasting.
I can also say, I have never seen DP used for short term forecasting. DP typically has the longest time horizon, SNP shorter, PP/DS shorter still and so on.
As for DP to SNP, this is the most commonly implemented integration in APO-land. In terms of measuring forecast consumption, here is how it works.. and I quote from Supply Chain Management with APO by Jorg Thomas Dickersback.
“The horizons for the forecast consumption  (number of days forwards or backwards from the confirmed date of the sales order) and the consumptive mode (backwards only, forwards only or both) are maintained in the product master.”
“The forecast is calculated each time a sales order is created, changed or deleted and each time the forecast is released from DP.”
“the consumption of the forecast is performed on the location product level, although it is possible to restrict the forecast consumption to a more detailed level using descriptive characteristics” (furthermore, forecast consumption can be set as backwards, (sales orders consume forecast quantities that lie before the requirements date), backward/foreward (sales orders consumer forecasted quantities that lie before the requirements date. If the actual demand is no satisfied, the sales orders then consume forecast quantities that lie after the requirements date in order to satisfy the remaining demand, forward consumption (sales orders consume forecasted quantities that lie after the requirements date). – The recommendation is that the for fast moving products, the consumption can be set backwards/forwards for a shorter period of time (say a week),and for slow moving products, the consumption can be set for a month or longer.
Descriptive characteristics are a different conversation, but essentially, consumption is inherent each time the forecast is released to SNP. The question  of how inherent it is if it is released to SAP ERP and not SNP (an alternative implementation), is another question. I think it probably is, but that would become a question for the integration mechanism, called the CIF, and is another line of inquiry.
Strengths:
All the methods every other forecasting system has, including autoselect or best fit:
  1. Integration with SCM
  2. Integration with SAP ERP
Weaknesses:
  1. Data Warehouse Workbench
  2. The necessity to learn a new vocabulary to use
Questioner:

What type of exception reporting (eg actual greater than forecast) are available in APO? How difficult is to create your own report (does this require coding or is it similar to combining fields like in access DB)?
Short term forecasting (the way you described it) is managed a lot better via retail inventory management solutions or VMI.
Does APO support:
  1. Easy elimination of certain data points (to exclude from forecast)?
  2. Good graphical depiction of interpolation (past data) and extrapolation (future forecast)?
  3. Causal analysis (or factor-based regression)
  4. Fair share logic (when forecasting is done at a sub-assembly level and then allocated to final SKUs using %%)
  5. Profile-based forecasting (with some factors impacting profile characteristics – eg slope)
  6. Calculation of statistical parameters (which helps to determine the quality of forecast)
  7. If a client outsourced all manufacturing and only drops orders to be fulfilled using APO DP for demand planning and its own tool for VMI (on the customer side) does it make sense to use CTM (with VMI generating replenishment orders)?
  8. Since production is outsourced, client is not concerned with manufacturing capacity while it is critical to replenish on-time since you are dealing with time-sensitive product and WallMart.
Shaun:

Exceptions are handled by the alert monitor. See this paper for the details.
http://snappdocs.files.wordpress.com/2007/12/how_to_use_the_apo_alert_monitor_for_reporting.pdf
It is very flexible and access can be given to whoever the project sees fit. We are trying to figure this out now on my current project.
  1. Not sure about easy elimination of outliers, I don’t think so. Sounds like a report that would have to be run off of the DP data. SAP would answer differently, that all of that is handled by BW, but it still has to be coded, and its a separate system, not integrated — so the process would be disjointed.
  2. Graphical depiction is weak. The charting in DP is nonexistent. I am a big fan of the charts in the forecasting in the SPP module, but that is not DP so does not apply. (DP and SPP development teams don’t seem to talk)
  3. DP can do some causal based forecasting, is basic but functional. SPP has a stronger functionality called “Leading Indicator” forecasting, which is causal, but since it’s not implemented more than a few places, it’s not very well tested. My take is it’s not that important because very very few clients do causal forecasting. But I would like to hear your take on it.
  4. Yes, the forecast can be disaggregated this way, and a number of other ways as well. SAP makes a big thing about this functionality.
  5. I am not sure what profile forecasting is. I think this is just forecast parameters (i.e. a field for the trend component and so on), if that is what you mean then yes.
  6. Well DP has best fit. But I don’t see how calculation of the statistical parameters helps determine the quality of the forecast. Isn’t the quality of the forecast determined simply by the comparison of the old forecast vs. the old actuals? Maybe you can explain some more here.

Protected: SOP

This post is password protected. To view it please enter your password below:


What SCM Modules are Most and Least Implemented?

Something of interest to many people in SCM is the frequency that SCM modules are implemented. We have built up a database of 43 SCM implementations, and from this sample have come up with the following frequency, as presented by a pie chart.

Implementations by SCM Module

SAP SCM Case Studies

What Is It?

A Product Wheel is an attempt to mitigate the following production problem.

The ‘product wheel’ approach is the name for the formal resolution of a typical scheduling problem: to produce n different SKU’s in a single step production process, in m possible resources or machines. Problem can be addressed in two stages as follows: to allocate products to their best manufacturing option (distribute the n products among the m resources), and to schedule the assigned products in the right resource in an optimal sequence. - Rual Tome, Juan Manual Dominguez of S&T

The pie chart or wheel represents production runs on a particular resource or set of resources.

The product wheel is really a pie chart which essentially shows the competing products for manufacturing resources as an endless cycle. Higher demand products are given longer production runs that lower demanded products, that is one determination of the “width” of the slices of the product wheel. The other dimension is sequence. Here the sequencing of runs is designed to match with the twin needs of minimal inventory combined with the need to have product available to ship when needed. Thus we have come up with a compressed defintion.

Where production is scheduled in a way to make best use of production resources in view of competing products and with meeting the needs of minimal inventory and maximum inventory availability at the right time for shipment to warehouses – SAP Planning

Product Wheel and PPDS?

There is nothing special that needs to be done in order to implement the product wheel concept with PPDS. If the PPDS model is an accurate reflection of the production constraints and the demand dates are correct, PPDS will naturally create a “product wheel” in terms of the production plan. This simply comes down to how accurately PPDS is modeled.

Conclusion

The concept of the product wheel is a convenient visual concept for humans to understand something, that if PPDS, or other production planning and scheduling systems can already produce, as long as they are fed the appropriate information.

Reference

http://sytsa.com/repository/success_stories/ingles/ps_p_the_product_wheel_approach.pdf?PHPSESSID=8f27b1f8905f9bfe4cab217f03900c79

This post is password protected. To view it please enter your password below:


This post is password protected. To view it please enter your password below:


Older Posts »