A Debate on How to Recover SAP DP for Forecasting - Brightwork Research & Analysis

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Nearly all SAP consultants provide false information on the issues related to SAP in a process called sugarcoating.
In this article, we debate a person who sugar-coated the issues with SAP DP.

Background on Differing Views on SAP DP Recovery

A consultant who had some critiques of the articles in this blog recently contacted me. I think the criticism is interesting because it often provides me with information that I would not have anticipated. For instance, one reader once commented that because of my effusive praise for one application that I must be compensated in some way by that vendor. I pointed to the reader our “writing rules,” which declares all of our financial relationships, and this vendor in question is nowhere on the list. In fact, the total compensation from all vendors is so minor that it should immediately put those concerns to rest. This reader’s comments made me go back and clarify the writing rules more accurately. A question or critique that one person chooses to put effort into writing may also be shared by many who do not.

This article addresses some of the critiques as to articles published by Brightwork related to SAP DP. The articles on issues with both SAP DP and SAP SPP, in addition to articles on recruiting practices in the IT industry, seem to be some of the most controversial on this site.

To begin the article, I wanted to describe what I believe is the standard message of many consulting companies and SAP on the problems businesses face with DP. I will then get into answering the critique that was sent to me.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

Understanding The Basic Message for SAP DP Recovery from SAP and Consulting Companies

As I have written, DP is an application with many issues post-go-live. The standard approach to responding to these issues by both SAP and consulting companies can be synthesized to the following:

DP contains, in essence, all forecasting best practices and meets the needs of hundreds and hundreds of companies presently.
The problems you have with DP are related to your user base and your training. Your training must be performed again.
There may be a few settings that need to change to significantly improve the performance of DP, which may be rectified with a consulting diagnostic.

What SAP and their passive accomplices (the consulting companies) conveniently leave out is that while it’s true that hundreds and hundreds of companies use DP, I have never run into one that is happy with it.

Furthermore, the clients who tend to be the most satisfied with DP use the least functionality. I know several companies that use DP as a repository for forecasts from other systems and entry points into SNP. These clients are relatively satisfied with DP. Some executives may think it is ok, but they tend to be the most divorced from the forecasting process. The closer you get to the users, the worse the story gets. A senior manager at an implementing company once told me that the way DP performed historical adjustment was “the source of his existence.” I have also never seen DP meet or come close to meeting all of the client’s requirements. A more accurate way of describing DP is that hundreds and hundreds of companies use it and are happy with it, but that they tolerate it. Furthermore, no consulting businesses that work in DP will write articles on this because:

A). They don’t care.
B). They cannot jeopardize sales leads from SAP

A consultant once told me from Deloitte that while he agreed that DP was very problematic, but “hey, that is how you get extended on projects.”

The message(s) I have described above is very appealing to executives with malfunctioning DP software. Think of the appeal:

They made no mistakes in their software selection.
They can have everything they want if they spend more on training or a DP diagnostic.

Executives who listen to this message believe that they are close to the solution they desire to make a little more investment.

Why Does DP Require Repetitive Cycles of Training?

More training always helps, but the fact that SAP DP needs so much training to operate at low-level should be cause for concern. I take the opposite view that there is a limit to how much one can train out of a bad solution. Why this fact is lost on so many executives, I don’t understand.

Name your business with its multi-million dollar investment and several years investment in DP, and I will provide a better forecast in a concise period with an inexpensive application.

In fact, extensive work by academics, in addition to Michael Gilliland at SAS, demonstrates that the manual overrides by planners have little impact on improving the forecast.

DP makes easy things hard to do. Einstein once said that those extremely well-designed things are undifferentiated from magic. Good software makes difficult things easy, and vice versa.

The Reason for The Current Approach to DP Recovery: Software Vendor and Consulting Company Monopolies

I believe this message is molded around bill-ability. But I don’t think there is much support for it if money is taken out of the equation. This brings us to the primary issue that the perverse incentives in the enterprise market, which due to corruption, caused incorrect and ineffective applications to be recommended to clients in the first place. Many applications we are dealing with are there not because of their inherent qualities but because they line the pockets of partners at the big consulting houses. Could DP survive as a product outside of the protected confines of SAP or another monopoly enterprise vendor like Oracle? Not in my view (possibly now that it has built up market share, but when it was first introduced?).

Could the BW? (Which has the same productivity problems on projects, with unending late or never-to-arrive reports.) I doubt it. In fact, I have written an article on just this subject.

Monopoly power keeps these products selling, not software quality. We do not have the “optimal” enterprise market, and only one that is as good as the present political and economically un-knowledgeable environment allows for. Thus the enterprise software market is oligopolistic, which means inferior products can be offered and sold and may never improve much. This is because anti-trust legislation, which is designed to break all forms of monopolistic practices, is no longer enforced with much consistency. The Federal Trade Commission will sometimes block mergers, but is very reticent, due to campaign contributions from major monopoly firms and a revolving door in its administration, to actively break up companies engaged in anti-competitive activities. SAP has repeatedly engaged in anti-competitive activities, including stealing intellectual property from smaller software vendors. I have analyzed SAP and categorized it as a clear target for FTC investigation.

The Criticism of Brightwork’ Approach to DP Recovery

Now that we have delved into some of the backgrounds on SAP DP and the issues surrounding it, I wanted to include the entire critical statements that were emailed to me about the Brightwork approach on DP recovery to make sure I address it in its entirety.

“Your writings seem to be just criticisms that attack both vendors and solutions without any real effort or content to help the user who is searching with questions. You are offering Smoothie to the thousands of APO planners who have no choice but to use APO because the management told them to.”

So if we dissect the main criticisms from this quotation, we find the following:

I/Brightwork attack both vendors and solutions.
Brightwork makes no real effort or (provides no) content to help the user search for questions.
APO planners have no choice but to use APO because their management has told them (and thus, they must be assisted within this limited constraint).

Let us take each one individually:

“Attacking” Vendors and Solutions

I think we have an issue with the word use. Let us take a look at the word “attack.”

“There is no shortage of “fighting words.” The attack is the most general verb, meaning to set upon someone or something in a violent, forceful, or aggressive way (the rebels attacked at dawn); but it can also be used figuratively (attack the government’s policy).” – Apple Dictionary

I don’t recall my criticisms falling into this category. I think that this word selection is overemphasizing what I am doing to vendors and solutions. So the attack is a bit much to describe articles that are simply critical. What I think would be valid is for you to say that my criticisms are not warranted. Something like…

“Brightwork says that DP is ineffective at lifecycle planning, but in fact, DP can be made to be effective at lifecycle planning if A, B, and C are performed.”

I applied this specific approach in addressing criticisms of reorder point methods in some books, which I felt missed when to reorder points are highly appropriate to use.

This loaded terminology is being used to undermine statements I make through the application of an unappealing label. Also, one must consider the target. SAP is a giant company with revenues of 13 billion, with a worldwide reach and incredibly sharp business practices. I think they will be ok and can probably take some well-deserved criticism here and there. This applies in particular as they are so rarely criticized in media. Most information sources falling all over themselves to write fluff pieces on SAP because:

A.) They are either paid off by SAP
B.) They are dependent upon SAP for consulting opportunities; I think the internet can benefit from an information source that is out of SAP’s reach to corrupt.

As with pharmaceuticals, there is a big money train for associating with SAP. If I worked for a consulting company, I would be quickly pressured by a partner with beautiful hair because I am upsetting the apple cart and “damaging the relationship” with our “partner.” Therefore in our system, only the smallest information outlets can exercise their first amendment rights.

Does Brightwork Make No Effort to Help Users Searching for Questions?

I write both on what software can do and what it cannot do. Most information sources do not. And this includes books. Software books are censored so that they only present the software in the most appealing light. (I know as a publishing company has censored me) Scientists take the same approach when discussing or focusing on what they can explain and cover up what they cannot. Clients have repeatedly told me that they have a hard time getting straight information on enterprise software because most of the information available is designed to promote a sale.

Returning to SAP DP, some things that SAP DP has problems with, I don’t answer for within SAP DP. It’s a flaw in the design. I do not work for SAP Development, am not part of the SAP DP development team, so I cannot solve many of the application problems unless there is something that I can do from a configuration perspective. For instance, I can’t make a DP user interface better than it is. Describing the problems that I have faced with SAP DP has helped others understand the problem better. I know this because I have been contacted by people how have told me this. The only individuals who dislike what I have published about SAP DP are either SAP or those associated with SAP or somehow riding SAP’s coattails. I once wrote that SAP EWM has a ridiculously complicated configuration setup. An EWM consultant who was unhappy that I had published this information once contacted me and voiced his displeasure. Why was he unhappy? He did not tell me, but I can fairly well guess that he did not want information out there dissuading people from starting EWM implementations, as that was his consulting market.

Disseminating positive information is not in itself a “virtue.” Positive information is not “better” than negative information. Those who publish positive information, even if false or inaccurate, receive much less negative feedback than those who post negative information, no matter how accurate. Think of Moody’s, Standard & Poors, and Goldman Sachs for a minute. These companies still issue projections. Why does anyone listen to these businesses, and why are they still in business? It is simple. They are powerful. People never tire of “positive” information, no matter how inaccurate or how corrupted. Furthermore, people seem to have a general problem evaluating statements for their inherent accuracy and remembering various institutions’ accuracy. Instead, they use the status of the source to determine accuracy. The more well-known the origin and higher status, the greater the ability to disseminate false information and retain credibility.

And that is a problem because people respond to incentives. If the incentives are to stay away from conflict and ingratiate oneself by disseminating or publishing positive information, regardless of accuracy, then…well, then you will have what we have now, that is enormous quantities of positive but misleading information about the enterprise software market. When I perform research on topics, I have to apply a large amount of energy in critically analyzing statements because of this condition.

Finally, an author is not responsible for even providing a solution to every problem they observe. The most important aspect of any article is not whether there is a “happy ending,” but whether the information is accurate. If it is, then the author can be said to have done their job. If it isn’t, then they haven’t. No author should shrink from reporting uncomfortable truths or be cowed by the false criticism that they are not providing solutions. This is a time-tested argumentative technique designed to silence criticism.

Therefore, I disagree that, even if I did not provide “solutions/alternatives” (which I do), this is not adding value to the conversation. Brightwork is probably the only site that brings up the root flaws in DP’s design. Reading books, talking to consulting companies, and other information sources, companies, and decision-makers may think their bad experiences with DP are isolated. In fact, SAP makes a very concerted effort to mislead companies into thinking that their DP problems are unique.

Do APO Planners Have no Choice but to Use APO?

I believe this criticism to be somewhat circular. I am unaware of any consulting company that recommends using another forecasting application and combining it with DP. Rather, SAP and consulting companies line up to offer DP recovery packages, promising that they can be salvaged without help from another application. Therefore, many businesses can be misled into thinking that the best and the only option is to continue with trying to recover DP only one way. They are also misinformed from the low probability of success of attempting to improve DP this way.

God did not select DP. It was the consequence of poor quality information. The continuation of its use without assistance from another application is simply a condition of the executive decision-makers’ information. I certainly recognize that there is a limited budget for a second forecasting application after DP is implemented. I have found an application that can meet the requirements of companies that I consult for, which can be achieved at a minimal cost. Furthermore, this cost is lower, and the forecasting capabilities higher than the alternative of only using DP. Not all executives will choose this alternative, but it is the only option I feel comfortable recommending.

Why Use Another Application for DP Recovery Projects?

As for my logic for proposing Smoothie is that it has the highest power to effort ratio of any forecasting application I have used and can do many things that either DP can’t, or that DP can only do with so much effort that it is not sustainable, there are other useful applications out there. For statistical forecasting, I like JDA DM and ToolsGroup quite a bit (I do not think that consensus-based prediction should be attempted in statistical applications. As DP is predominantly a statistical forecasting application, I will leave out CBF from this article). The LifeCycle Add-In that SAP sells at additional cost to companies already exists in a much more sophisticated form in JDA DM and is part of the base application. Both of these applications run circles DP. These are more expensive than Smoothie, which kills them as options on most DP recovery projects.

By the time I get to DP projects, DP has consumed all their money, and they don’t have a good forecasting solution. So now that so much money has been wasted, I need to help them recover with a small amount of money.

That is the problem with DP that is unaddressed. The DP consumes so much in the way of resources and produces so little for companies that the implementation is a kill shot to its forecasting process. They are now stuck with a bad solution, with their money consumed by DP for maintenance and no political way out. This is where Excel comes to the rescue. DP is one of the great promoters of spreadsheet-based forecasting. That is why Smoothie is my go-to application for these situations.

This gets to the next point.

Effective Lifecycle Planning

On the topic of lifecycle planning, you made the following statement:

We all know life cycle planning is useless. Some of the metrics are crappy. Models produce flat forecasts. But I don’t see anywhere in your blog that explains why or how to over come this. You are simply saying SAP is useless and suggest people find something else……….

I would have to understand why you say this probably. I do think that DP is an abysmal tool for lifecycle planning. Having many phase-in-phase-out profiles, which proliferates very quickly, is not an efficient way of managing lifecycle planning. I will also concur that most companies have a lot of problems with lifecycle planning. I did actually write an article that described a very efficient way to manage life cycle planning, in fact, the easiest way I have found so far.

Adding SAS + SAP?

Other forecasting applications can augment this basic forecasting functionality in SAP. One well-respected forecasting firm that does is SAS. SAS lists the following capabilities vis-a-vis SAP:

The ability to modify forecasting hierarchies
The ability to leverage standard reports
Launched from within SAP SCM DP

SAS is the best breed forecasting solution in its functionality (although not in its interface), while SAP DP is not. SAP SCM DP is typically selected because it prefers clients to use a single software vendor for many things, not because of the application’s capabilities. I find most SAP DP consultants to be highly deluded about the quality of their products. Bias is always an issue, but consultant’s that work for large consulting companies are told to cover up the weaknesses of solutions in front of clients. In this way, the consultants for large consulting companies become nothing more than technically educated salespeople for the consulting firm’s vendors.

The Effort Required to Fill the Gaps in DP

SAP SCM DP can, with a large expense, be set up to provide many of the same forecasting methods that are available in almost any forecasting system. (time series, regression, multiple regression, and composite). However, DP has considerably less flexibility than even inexpensive applications like Demand Works Smoothie.

DP offers a high cost, a long implementation time standard solution that makes executives feel good because they are buying “SAP,” which is like repurchasing IBM from 1960 to 1990 (i.e., you normally won’t be fired, no matter how the implementation turns out). On the other hand, SAS is for companies that are advanced in forecasting and are interested in implementing ARIMA, ARIMAX, UCM, and dynamic regression. The difference in model setup is high, as is explained by this passage from Business-Forecasting.us. (see link in the references at the bottom)

APO DP offers the basic exponential smoothing models and linear regression model that use a deterministic time index as the independent variable. The exponential smoothing models work for most purposes but they are not the most efficient – for example the iterations of the smoothing parameters namely alpha beta and gamma are in increments of .5 not anything in between.

However, DP’s statistical forecasting capability is not relevant for most companies. This is because it is rare that the statistical forecasting is turned on in DP. Most of the clients I have worked with perform forecasting externally, and DP as a container for the forecast. This is not because planners do not understand the algorithms. In fact, they should not have to know them in the first place. Before the rollout best fit should have been run, the forecasting methods per product should be selected for the demand planners before beginning their manual overrides.

Using SAS

Using SAS may appeal to a segment of customers committed to SAP SCM DP but find they wanted to do more. Thus SAS is pitching itself as a bolt-on to SAP. The problem with this is SAS can completely replace DP and most likely at a lower price and higher functionality. Thus, SAS’s only real reason is for marketability given SAP’s dominant position in enterprise software. However, I would never recommend combining SAS and SAP SCM DP. For one, you end up with a very complex solution, as the quote from SAS indicates:

“Web services launch the requests from SAP to SAS and the RFC to efficiently move data to and from SAP lifeCache.” – SAS Forecasting for SAP APO

Sounds sexy, but the question should be asked,

“Why spend time trying to connect a superior forecasting solution to an inferior one, why not just implement the superior forecasting software and save yourself integration work and expense.”

SAS has an answer for this in their white paper on the topic. They state the following:

“From SAP, integrated applications and workflow that support business processes. From SAS, deep experience in analytics.” – SAS Forecasting for SAP APO

The problem is this is just marketing fluff. There is nothing particular about SAP SCM DP that relates to any workflow. The standard workflow is to perform forecasting in DP and then release to SAP SNP or SAP ERP. The integration is very straightforward, and SAS could easily release its demand plan to SNP or SAP ERP, so there is no benefit for SAP SCM DP being in the middle.

Go to top

Conclusion

I hope that this article was interesting to the individual who proposed the critique and other readers contemplating their own DP issues. The offered critiques were short, but each one took a great deal of background to answer properly.

Update As Of November 2021

Years after having this debate I found something interesting about the person I debated with.

This person ran a DP training business but was actually a poser. I ran into the person who trained them on DP and this person who debated me was not hands-on. This explains a lot as to why they were so in favor of both protecting DP (they had a training business based around the idea that that the only problem with DP projects was a lack of staffing.)
The person I debated was Indian. I already had a poor impression of Indians at the time I debated this person, but since this time I have learned so much more. Indians are fundamentally dishonest and come from a dishonest culture that promotes scamming. It was obvious from how this person was debating that he was dishonest, but I can now see it within the context that Indians will always lie when it benefits them. Indians have scammed the H1-B program so they now they represent over 75% of the entire program. Of all the people that have ever been caught faking a claim Mount Everest, they were both Indian. I have in 20 years never run into an honest Indian. One of the problems with this debate above is that I am arguing honestly, but as the person I am debating is an Indian, he is most likely lying. This is the problem why it is impossible to derive value from a conversation with Indians and why I recommend not discussing topics with Indians. It is considered entirely normal in Indian culture to lie in a debate.