How to Cover Up SAP DP Weaknesses to Sell Training and Consulting

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

Executive Summary

How financial incentives drive the dissemination of misleading information on SAP DP.
Bad DP Consultants are misleading their clients as to DP’s potential.

Introduction

A few years ago, I found an article by a person who sells training and consulting in SAP DP and found what I thought were some very flawed arguments that seemed designed to paper over problems in SAP DP and to position this person and their company as the only one that could solve these flaws. I published an article on this person article stating that while this approach will help generate revenue, it does not help improve DP projects. Sometime later, I found that this author had commented on my article. So once again, I analyze this author’s statements.

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.

Keep Cribbing or Find Solutions

This is the title of the article. Cribbing is an Indian term for complaining. The author proposes in this article that I should only publish information on SAP DP if I have found solutions. It is a status quo philosophy and is also related to protecting inc0me streams. People who work in applications don’t like those applications criticized, regardless of whether the criticism is accurate. His quotation is the following:

“I landed on this blog site written by a consultant who obviously makes a living on SAP. But strangely enough, this consultant has created a complete web of blog entries filled with complaints about SAP and APO particularly demand planning. The sole purpose of his writing seems to be scathing attacks on SAP.”

There is a lot that is false in this short paragraph. Let us begin with a “complete blog of entries filled with complaints.” Most of these articles explain how to use SAP APO. It is a gross exaggeration to say that even the majority of them complain about SAP. Secondly, the primary purpose of the articles is to explain how SAP works. Sometimes this results in complaints. Some of these articles that the author refers to point out elementary functionality that operates in every other application I have tested but did not work in SAP. One of these criticisms is that the best fit procedure called Auto Model Selection 1 did not work at all, and Auto Model Selection 2 functioned differently when running in the background versus when running in the Planning Book.

Secondly, that different results occurred depending upon the planning field. This is inferior software quality. It simply is. Some consultants who make money from the software may not want to have this published, but it is difficult to deny that this is a problem. I am currently working on a different elementary problem that has to do with Forecast Profiles not generating the right forecast for assigned products when running from a batch job/Process Chain. Is that scathing to point out that that should have been entirely resolved in development, or that SAP should have solved the issue over a decade ago?

The Simple-minded Criticism of Never Publishing Criticism Unless One Can Publish the “Solution.”

One of these criticisms is that the best fit procedure called Auto Model Selection 1 did not work at all, and Auto Model Selection 2 functioned differently when running in the background versus when running in the Planning Book. Secondly, that different results occurred depending upon the planning field. This is inferior software quality. It simply is. Some consultants who make money from the software may not want to have this published, but it is difficult to deny that this is a problem. I am currently working on a different elementary problem that has to do with Forecast Profiles not generating the right forecast for assigned products when running from a batch job/Process Chain. Is that scathing to point out that that should have been entirely resolved in development, or that SAP should have solved the issue over a decade ago?

His article goes on to beat the drum that I am not providing solutions.

“Unfortunately there was not any content that could solve problems or answer questions. Surely I did not find an answer to my question on his blog.”

That is because there is no answer to these problems, and still isn’t. I can’t provide answers that don’t exist. Perhaps I should not write on a topic unless the solution is there — which very much sounds like self-censorship. Essentially, the real answer to dealing with the Auto Model Selection 1 is never to use it. The solution to Auto Model Selection 2 is only to use it in the Univariate View of the Planning Book, but never as a scheduled job. However, the author seems to assume that the only benefit of publishing information is if the solution is provided. That is not true. Posting information that shows flaws can help people understand that they are not the only ones that face the issue. The major consulting companies lie to their customers about the capabilities of the software to get deals done. We should not be criticizing people for publishing true information, even if it is critical — that is unless we have a bias and don’t want criticism published at all.

For instance, one might say that one should not post that millions of Native Americans were killed during the war with the US Cavalry. After all, the statement does not provide any “solution.” But it is still essential to know the truth about what happened. After the first book is published, the information is not “new.” So every book about the Indian-US Cavalry war after the first book has been redundant? If our measure of whether something should be published is whether it provides a solution rather than whether it is true, this is a textbook mechanism for suppressing most criticism.

Criticizing Accurate Information

We should not be criticizing people for publishing true information, even if it is critical — that is unless we have a bias and don’t want criticism published at all. For instance, one might say that one should not post that millions of Native Americans were killed during the war with the US Cavalry. After all, the statement does not provide any “solution.” But it is still essential to know the truth about what happened. Secondly, after the first book is published, the information is not “new.” So every book about the Indian-US Cavalry war after the first book has been redundant? If our measure of whether something should be published is whether it provides a solution rather than whether it is true, this is a textbook mechanism for suppressing most criticism.

Finally, the author does not seem to be acquainted with the other writing at Brightwork Research & Analysis. There are many solutions offered at this site — but there are no solutions written for solutions that do not exist. There are many of our books; for instance, the book Superplant explains how to plan integrated international factories using specialized production planning and scheduling software. Many companies struggle with this but don’t have the right software to do anything about it. Inventory Optimization and Multi-Echelon Planning Software is the first book in the area to explain this technology in laymen’s terms. Promotional Forecasting is the first book to focus entirely on promotions for demand planning. Furthermore, I have described how to recover SAP DP; it means using problematic functionality in only a limited way. However, the author disagrees with the solutions. That is not the same thing as not offering solutions. I provide solutions all the time to clients by recovering SAP DP.

The next criticism has to do with whether the problems brought up are new.

“He does have pretty good complaints – very well articulated. These complaints are not new about SAP APO. Most users know these complaints and they live through this every day to their frustration.”

And they continue to be frustrated with these things to this day because they have not been fixed. Is this a good thing? Also, I am not sure about “most users” knowing these complaints. I am presently working with a company where most users are new and where the best fit has not been used for years. They are not familiar with all of the ins and outs of best fit in SAP. Also, how the problems are documented, the detail and context are, in fact, new. Deloitte or IBM or the author won’t publish these problems’ real details because they only give out information they can charge for. Finally, a lot of things aren’t “new.” For instance, people have been abusing animals for thousands of years. But should we not bring this up because it is not “new?” That seems like a strange logic for a critique.

I don’t use Auto Model Select 2 for running best-fit analysis, but instead, use my application and then build Forecast Profiles that match the results of the external application — and almost no one in the marketplace does that because they want to be 100% pro-SAP rather than using the best approach. Secondly, many companies think the problems they have are unique to them — by documenting the issues, they can realize that these are bugs in SAP’s software. He goes on to state admit that SAP should follow up.

“It is a shame the company will not listen to the users or read the thousands of OSS notes written every day. The problems that SAP has to be blamed for include issues such as forecast error calculations, incorrect alert logic, manual effort required in life cycle planning among others.”

Yes, it is a shame, but here isn’t the author “cribbing,” why “crib,” and where is the “solution.” Secondly, it might be more than that. Furthermore, many hours are being billed and charged to resolve issues that should have been addressed in development. Many problems like this are what make SAP DP such a high-maintenance application. High maintenance applications tend to fall into disrepair over time. The next criticism is a bit hard to swallow.

“However there are many problems that are created by the Integrators/Consultants including our “esteemed” blog writer due to their lack of knowledge of both demand forecasting as well as an understanding of the tool. If they don’t understand the tool, they should not be implementing it or training the users. The baggage they leave behind creates a mess that makes the software worthless and unusable.”

It is very well known that the large consulting companies have uneven quality in their SAP DP resources. Most of the DP consultants who work for the major consulting companies tend to be good in their knowledge of DP but not as reliable in forecasting as they tend to have backgrounds in engineering rather than the supply chain. However, the problem is that SAP DP has so much overhead to learn that a person who is more from the forecasting side cannot master it. SAP DP tends to repel people who are very knowledgeable in forecasting because it is difficult to get it to do basic things. You end up spending lots of time fixing it because it periodically breaks. That is, SAP DP is far more popular with IT than with business type resources. DP’s Data Workbench is tough to use and requires a person to understand reporting, databases, etc.. Interestingly, that knowledge is not necessary for several other applications. The author leaves all of that out of his observations.

Now in this quotation above, I get lumped in with the major consulting companies as a person who lacks knowledge of demand forecasting and an understanding of the tool. How does the author know this? I recover SAP DP implementations as part of my consulting practice. I am the most prolific author on SAP APO through both the website and books. I have written five books on SAP APO. I have to cover SAP SNP and DP and dip my toe into the other areas such as GATP and PP/DS. I am the first to admit I don’t know everything – for instance, I dislike the Data Workbench in DP and typically have an onsite resource who will make the necessary changes for me. But I have successfully recovered DP projects, which would seem to mean knowing something about it. I have been working with SAP since 1997 and in advanced planning at the same time. So I think the author crosses the line here by calling into question my knowledge. I would prefer he address my arguments, but he never does this. Not really. The one particular case that he discusses is not actually what I wrote, which I further explain in the article.

It also raises the question of the problem with SAP DP that it can’t be adequately implemented by consulting companies or by me. Is the author the only person who can implement SAP DP? If so, companies that buy SAP DP must know if the author is available to work on their project because they may have a problem.

Bad DP Consultants

He then goes on to list things so terrible DP consultants do.

Implement APO to be used as a typing tool and tell the users Statistics are terrible, so not worth using it. (I have never done this. I setup Forecast Profiles that the users can flexibly assign. These Forecast Profiles are based on both best fit analysis performed outside the system and requests made to me by the planners.)
Disable statistical modeling under the pretext of security. In reality, the consultants are worried about fielding questions from the users of the statistics that they do not understand themselves. (I have never done this. I have never received a question about a statistical model that I could not answer because I have studied this subject for many years.)
Enabling options and parameters in the tool without any idea of what they do to the resulting forecasts. (Also, not something that I have ever done. I test all the parameter changes before I save and distribute a new Forecasting Profile.)
Deciding on essential things such as forecast aggregations, forecasting levels, and exception management without any process discovery or user input. (I would never do that. I publish documentation on aggregation, so the concept is socialized, and then from there, ask the users how they want the characteristics assigned to which Planning Books.)
Finally, not project planning the budget to include training to the users, particularly on the Stats and Demand Planning. (I don’t set the budget, but training is underfunded on virtually every project, demand planning, or other. Companies used to train but have moved to “on the job training.”) However, with SAP DP, the training budget must be very significant because SAP DP is so painful for planners to use. Even after training, users always require more DP training.

So I have never made any of the author lists as flawed approaches to implementing/recovering DP. In fact, they are fundamental. So I am now even more confused about how the author decided to lump me in with large consulting companies. This author is not familiar with my work outside of my writing, so he is making erroneous conclusions that seem to be based on the fact he disagrees with me on specific topics. This is referred to as an Ad Hominem argument. A big issue which is on his list is that too many consultants are covering up for SAP DP’s weaknesses and blaming all problems on the implementation, or a lack of training, covering up for the application and promoting the idea that everyone but the application is to blame. The author excels at doing — and I am taking directly from his writing, not guessing as the author has done with me. Another author who does this is Michael Krigsman. If you read

The author excels at doing — and I am taking directly from his writing, not guessing as the author has done with me. Another author who does this is Michael Krigsman. If you read Krugman’s writing on software failures, the vendor or application is never to blame — and yet he presents very little but one-sided analysis of problem projects.

The author then goes on to state the decrepit state of DP implementations.

“Given how many implementations are currently plagued with tool problems aggravated by Consultant inefficiency and incompetence, perhaps more companies should think about re-implementations of APO DP. Just throw away the old concepts and practices and start thinking about how to fix the problems and make the tool more usable.”

DP Implementations in the Ditch

Well, yes, most DP implementations are in the ditch. I think most probably are not using statistical forecasting and are primarily manually override driven. And yes, they need to be recovered, re-implemented, or whatever the term might be for more investment in them being made. I have changed all of the Forecast Profiles on my current project, changes how the Planning Books are to be used, added documentation in the area of aggregation and standard operating procedures created a new Process Chain, but still much more remains to be done. This is a lot of time and money, and it has to be done to most implementations. But again, why are so many SAP DP implementations in the ditch? Is every single one the result of implementation errors? Why is the application so tricky to install? Why does it tend to fall apart after it is installed? Why is maintenance so high?

Next, the author states that I am polluting the waters and provides this quotation.

“I strongly disagree with this Consultant/writer when he concludes that best fit models are erroneous because the error calculations are defective. If you poke around the underlying mechanics which is well documented in the APO online manual, you will know that the optimization is done using the Mean Absolute Deviation, which is superior to the MAPE; MAPE is a percentage and has some awkward properties.”

My frustration with the author reaches a high point because I never concluded and never stated that the best fit models were erroneous because the error calculations are defective. Here is my exact comment:

“At first it appeared as if the main problem why SAP DP has such a problem picking a best fit forecasting methodology is that DP has a flaw in calculating its error. However, it appears that DP Auto Model Selection 1 and 2 use the MAD calculation.”

See this article for the details.

https://www.brightworkresearch.com/demandplanning/2010/07/how-sap-dp-calculates-error-incorrectly/

I did look through the SAP DP best-fit documentation and did find that that the calculation was based upon MAD. So that is an incorrect statement on the part of the author. I stated that the erroneous calculation of MAPE was an issue for accepting the best-fit output. It appears as if the SAP DP is in error – which happens to be my experience on multiple projects. What would you think if the MAPE forecast error showed a 100 order of magnitude error and the best-fit output was also incorrect? What the author is doing is correcting a “mudding of the water” that was never muddied. He is incorrect that I ever stated this and wrong in his accusation that I did not perform the research to determine what error drove the best-fit analysis. Misrepresenting an argument so it can be criticized is called creating a paper tiger. On the other hand, he may also have not understood what I wrote, but what I wrote is very clearly stated. However, other forecasting applications also have problems with displaying the correct MAPE to be evenhanded as possible.

Secondly, outside of a biased interest in protecting the product to enhance consulting revenues, I can’t understand why this author intends to defend the best fit in SAP DP when it is just about never used as anything but as a guide to choosing a better forecast model. The author recommends against using the best fit (which I apparently agree with), but other applications can use best-fit – so that would seem to be a shortcoming. Best fit in SAP does not work consistently. Therefore its usefulness is extremely low. Thirdly, the best fit will not provide an actual selection of a forecast model.

Instead, it provides parameters that only apply to the Auto Model Selection 2, which cannot be run as part of a batch job, making it not useful for creating a Forecast Profile with a model that does work. The best fit should have produced a particular model assignment if the planner wanted to assign a model and deactivate repeatedly running the best fit procedure. Another best-fit functionality selects the actual forecast model that can be used and also works in the background. I have reviewed all the major forecasting applications, and no other forecasting application has the persistent and multi-dimensional problems that SAP DP has with best-fit. To continue to push for using this functionality is only to waste my time and waste the client’s money.

The author then discusses how challenging it is to use the Auto mode in DP.

“In general Automodel is not for the faint of heart as many settings have to be correctly configured. Given the fact most configurations are done by junior consultants from big 5 consulting firms, you can guarantee that this is an unrealistic assumption.”

That is not true. Many experienced consultants in the big five will setup the Auto model and setup DP overall. I don’t know why the author thinks this as many Sr Consultants and Managers in the Big 5 configure DP and other SAP modules. But if we ignore that statement for a moment — if the point is to say the functionality is too complicated for the average consultant configuring the software, why is this same functionality so easy to use in other forecasting applications? Why does something so simple as enabling best-fit functionality, which works by default in Demand Works Smoothie, is easy to use in Demand Solutions, is automatic in ForecastPro, etc., have to be a significant challenge for anyone? Best fit in most other applications takes no effort — isn’t that then a problem for SAP DP? Is it not then a valid criticism to ask why DP still works like this?

Next, the author makes a final passing criticism which is both misleading and ridiculous.

“My two cents = Do what you can and understand what you cannot. Some intellectual honesty will also go a long way!”

I think this would be the definition of passive-aggressive. Here, in a quite underhanded way, the author implies that other consultants and I don’t know SAP DP and that we cannot understand SAP DP in the way that he can. However, the author misrepresented my article on forecast error calculation and best-fit functionality. He then misrepresented the blog posts at Brightwork Research & Analysis, saying that they are primarily critical, leaving out all of the neutral how-to articles or the fact that Brightwork Research & Analysis is the largest non-SAP affiliated website to publish on APO and SAP planning generally. Therefore, either he is not checking correctly or has some reading comprehension issues, or he is making up information to support his revenge piece’s object. He was probably emotional when we wrote the article, so he did not fact-check. He also has a clear pattern of projecting what he wants to believe into what he is reading, and his motivation for doing this seems to be to allow him to create paper tiger arguments that he can then knockdown and to “unmuddied water” that was never muddied in the first place. Here are some questions that came to mind when evaluating this author:

Given his misrepresentation of the several articles about his arguments, does he understand the other items I have written?
Coming from a non-Western country/second world nation, does he understand the importance of transparency, the idea that not all published information is to be released for a commercial end?
Does he understand concepts around journalism, journalistic integrity, what separates accurate reporting from commerce? For instance, why did he write his article in the first place? Nowhere in his article did he declare I already wrote two pieces critical of his logic before he wrote this article. I laid out the explanations in this article, but he very conveniently does not address these issues, instead preferring to focus on the areas where he thinks he can make points. However, the reader would never know from reading his article that he was trying to get even. As an author, he is obligated to explain this, not leave his reader in the dark and not hide his intentions. This is elementary writer integrity.

Part of this author’s pitch is to paper over the problems with DP, convincing potential customers that most of the DP issues can be rectified with training — which he happens to offer. The training is to give a taste; the in-classroom time is then used to pitch consulting services.

Using external applications, I can perform forecasting analysis faster than any person can use SAP DP. This is why I can recover DP implementations more quickly. I have been told this is the case for my clients that IBM, Accenture, etc., already fleeced.

I have a different approach than other consultants, based upon a realistic evaluation of DP’s real capabilities. I don’t waste time trying to protect applications or use them where they are weak. If you cannot handle accurate assessments of applications, you cannot follow this approach and be stuck using DP. That is for areas where it lags readily available inexpensive applications. If you are taking advice from consultants who are unwilling to bring up the application’s reality because all they care about is maximizing billing hours and know how to do is serve as the handmaiden to the software vendor. Your DP (or any other application, for that matter) recoveries will be far less successful. It should be understood. This does not mean removing DP. I use functionality in other applications to make changes in SAP DP, but DP is still the forecasting engine. However, it requires being objective and not putting all your eggs in the DP basket.

What is a False Dichotomy?

The framework is making a decision a foregone conclusion by limiting the options that are provided. This is called “framing” an argument. Wikipedia has the following to say on false dichotomies.

A false dilemma (also called false dichotomy, the either-or fallacy, fallacy of false choice, black-and-white thinking, or the fallacy of exhaustive hypotheses) is a type of logical fallacy that involves a situation in which only two alternatives are considered, when in fact there is at least one additional option. The options may be a position that is between the two extremes (such as when there are shades of grey) or may be a completely different alternative. – Wikipedia

This is precisely what is being done in the Firestone advertising.

I came across a textbook case of a false dichotomy in an article about SAP DP. I have listed the quotation below but kept it anonymous to protect the guilty party.

I have heard feedback from many business users and demand planners that APO DP is complicated. Some think it is too rigid!! I have heard that it is too enormous and complex. At least this is not a criticism. It is ok for something to be enormous and complex, if it solving a complex enterprise problem. Imagine Exxon Mobil trying to manage the demand for parts through out its complex global supply chain. What is the alternative? Ease of entry and view as easy as excel……… I think people are focused more on ease of data management and data entry. Excel is obvious and you can manipulate everything without moving everywhere. From my working experience, I can say you don’t want to get there – 25 MB spreadsheets and chaotic vlookups.

SAP Makes the Only Demand Planning Application?

It may surprise the person who wrote this quotation above, but companies’ options concerning statistical forecasting do not come down to SAP DP or spreadsheets. Incredible as it may seem, SAP is only one of many demand planning applications to choose from, and as with the Firestone example, SAP DP is not even one of the better applications to choose from.

I have been consulting/teaching Demand Planning for the last 15+ years. Definitely APO DP is NOT a complicated tool. The models actually are quite straight forward and based on standard exponential smoothing algorithms. The users should not worry about the backside models but just understand what to use in which business situation. THIS is the gap. We at…..have helped clients narrow the gap and develop standardized training collateral for their working reference.

That is interesting, but I both completely disagree and receive nothing but negative comments about DP’s complexity from clients I work with who use DP. Perhaps the writer has so much experience with the application somewhat reduces the validity of one’s opinion of whether an application is complex. The most critical audience for whether a tool is complicated is those who have to use it rather than experts in it.

Is SAP DP Complicated?

Yes, in fact quite complicated, and unnecessarily complicated. DP is the most complicated forecasting application I have ever used.

Are SAP DP’s Forecasting Methods Straightforward?

If the author means straightforward mathematically, then yes. However, the statement is mostly irrelevant, and more factors determine how models will be leveraged than whether a model is straightforward. A forecasting application with no user interface, giving the user no way to access the data, could still have very straightforward mathematical models.

DP’s forecasting models are generic in that all vendors have roughly the same models. However, that is rarely where statistical forecasting applications differentiate themselves currently. (In fact, one of the few very differentiated methods is called the Lewandowski method, which is in JDA DM, which few other applications in this category have). Additionally, unlike the author’s statement, DP’s offers not only exponential smoothing models. DP has moving averages and more complicated statistical forecasting methods and the ability to make causal models, etc..

This issue is that DP’s design makes the models challenging to use. The user interface is weak and confusing to all users that I have seen interact with it. In fact, demand planners hate using DP. This writer says we need to discount their opinion and superimpose his opinion because he is “so experienced” in demand planning. The best fit, which helps planners chose among the various models, is difficult for DP to use. Furthermore, DP is significantly behind other forecasting systems because the forecasting models which use parameters must mainly be set by the user, which many forecasting applications have moved beyond at this point. So there are many other factors than whether a model itself is “straightforward.” A model may be straightforward mathematically but very difficult to leverage because of the software’s design.

Should the Users Worry About the “Backside Models?”

The author uses the term “backside models,” which bears translation as it is not a real term. Essentially, the author says that users should not worry about the forecasting models employed but should know when to use which model. This is true. Planners need only understand each forecasting model conceptually, which is true of any forecasting application. It is true. However, it is also not relevant.

I believe the writer is referring to because SAP DP can be buggy that it will provide completely false results when procedures like best fit are run, which makes the users question the forecasting models, which is entirely rational on the part of the planners.

This is SAP’s problem to fix, not the uses job to silence themselves on essentially. The degree of subordination that the writer is asking for vis-a-vis SAP is amazing. SAP should be providing quality software that works consistently to enable companies to perform forecasts. SAP is not expert at forecasting, employs few forecasting experts, and is not to be blindly worshipped, but should be critically analyzed….just as with any vendor.

Problematic Areas of SAP DP

Areas where DP has serious problems include its user interface. It’s such a poor forecast aggregation and management of hierarchies, its ability to perform lifecycle planning. Major consulting companies recommend it for consensus-based forecasting, which it is not designed for (this is more a feature of DP being improperly recommended for a forecasting process it can’t do, rather than the application itself, although SAP recommends its use in this way). The fact that its best fit functionality is so high in maintenance is typically not used except in the project’s early stages.

Theoretical Versus Functionality in Practice

SAP DP has a lot of theoretical functionality. However, vanishingly few clients can actually access it because the DP’s maintenance is so high that companies run into trouble just keeping up and running without the system degrading from its basic settings. This is why its total cost of ownership is so high and so uncompetitive with other offerings.

Finally, and quite importantly, demand planners hate DP’s user interface (one user described to me that they would like to shake up a can of Budweiser and spray it over the screen when the DP interface comes up), and this is one of the significant reasons that every client I have seen that is live with DP, has planners that greatly rely upon spreadsheet.

The fact that SAP has been able to continue to sell DP into accounts is a measure of how truly uncompetitive the overall enterprise software market is. This environment is marked by major corrupt consultancies maximizing their consulting revenues by providing false information to clients about software quality and where better products do not have a fair chance to topple poor solutions with large multi-national brands behind them. It is an environment where profit maximization takes the place of recommending the best product, exactly what this writer I have quoted is doing. He has DP services to sell. Therefore he chooses to discount all DP criticism because the more clients choose to disable their forecasting process with DP, the more profit-maximizing it is for him.