Diagnosing DP Statistical Forecasting Problems

by Shaun Snapp on September 19, 2010

What This Article Covers

  • The DP and BW Data Workbench.
  • The problems SAP development has with improving DP.
  • Why SAP DP needs and external prototype environment in order to perform proper troubleshooting.

Background

It is not unusual for companies to be unsatisfied with their forecasting performance. However, what can be particularly troubling is when even after an expensive SAP DP implementation the client is still unhappy with their forecasts. No doubt, SAP and consulting companies would prefer this not to be known or discussed, however, I have noticed some disturbing signs with DP, that clients who intend to implement DP should be cognizant of.

Data Workbench

I have written on several occasions about my criticisms of the Data Workbench.The Data Workbench is so difficult to use that it serves to limit data flexibility, and serves as a long-term cash cow for consultants in both DP and BW.

Problems With Statistical Forecasting

However, less discussed is the problem DP has with statistical forecasting. There are a host of problems that really should not exist at this late stage, and should probably result in a shake up at SAP development. Problems extend from the inability of DP to perform best fit forecasting to issues with forecasting some of the basic statistical forecasting methods. One client considers their system so fragile that they only feel comfortable using a single forecasting algorithm, even though their product database is much more varied needs than that.

Case Study: Testing The Client’s Dataset

Before getting into DP, I wanted to run my client’s data through a best of breed forecasting application. I searched for several applications online that were modified Excel Plug-ins, and found myself very disappointed. For any prospective developers out there, there is an unaddressed market for inexpensive forecasting testing software, but also for forecasting interfaces generally. I wrote about the problems with forecasting interface design a while ago. It continues to be a perplexing. When one thinks about how much innovation and creativity goes into the development of video games, the state of forecasting interfaces is the dismalest.

Prototype Environment

Every implementation needs this in order to be able to test the results from the selected application against something else and something more transparent. Myself, I at one time thought that it was sufficient to listen to vendors and check screen shots to match functionality during software selection. However, my experience with troubleshooting DP has led me to change this view and to think that the forecasting within DP or SAS or any other application should first be tested on client data, by the client, in order to see if the forecast algorithms actually work as advertised.

Getting back to the applications, I had very little success with the Excel plug-in vendors. I looked at Lokad, EZForecasting among others, but did not find what I needed. Furthermore, I found the Excel plug-ins to be a  a bit awkward compared to the dedicated forecasting user interface systems. One vendor which has a nice trial is SPSS. Although I was hesitant to use it, because they were recently purchased by IBM (when a software company is purchased by Big Evil, the software stagnates, the price charged goes up for the software and the service, developers become frustrated with the bureaucracy, and the service goes down.) Finally the software begins turning up in places it should not be because it is pushed there by IBM’s corrupt software recommendation service. However, even though SPSS’s long-term prospects are bleak, I still though it was useful to use SPSS to at least compare forecasts externally to what was being produced by DP. I also wanted to test drive SAS’s forecasting application, however, I was not able to find a downloadable trial of the SAS software.

Using SPSS

SPSS has a decent interface which allows the fast accessibility to many forecast methodologies. However, I was not able to find a distinctly seasonal method,it was necessary to build it. As for best fit functionality, the links on the SPSS website related to this are broken, and their help within the application did not lead me to the answer. So I had to search the web where there are several papers. Overall my trial with SPSS did not leave me with the idea that it would provide me with a fast forecast prototyping environment.

Making My Own

Eventually I was very close to making my forecast best fit formula in Excel. It picks from a seasonal, seasonal trend, Croston’s method. When the error gets sufficiently high, no forecast method is used and this is where an instead the periodic order up to formula is substituted over the forecast. I essence this would be like turning off demand management in SAP DP and ERP, and only activating the periodic order up to logic in the material master.

These are simply consumptive planning items. It is important to segment the product database into those that can be and are worthwhile forecasting, and those that cannot be forecasted. The large implementation partner that my client used put everything in APO and put everything towards a forecasting model. It is interesting to arrive on accounts with so much money spent, and with so little thought put into the design.

In Steps Demand Works Smoothie

However, then I found DemandWorks Smoothie. I ran into Bill Tonetti, who gave me a great over the phone presentation of what DemandWorks Smoothie could do. As soon as I found out it could perform an auto select or best fit, export the data for each line item with the coding for each forecast model selected, and that it had the ability to compare a moving average against the forecast model selected to arrive at an R squared, I knew I had to recommend to my client to purchase this application. After using the applications for months I have become extremely impressed with it, and find that it easily exceeds SAP DP in most areas. Of course VPs at companies can’t handle this, so Smoothie must always be presented as an adjunct to SAP DP.

The pricing for Smoothie allows it to be used as a pure simulation environment even if the company is using a different production system. The pricing on Demand Works can be found here. After a few days they approved the purchase of the introductory version, and I began using it to prototype the forecasting that we eventually want to move into production, with or without DP.

I discuss the use of DemandWorks Smoothie in these article.

Previous post:

Next post: