Is It True That SAP Performs Tests Before Selling Software?

Executive Summary

  • SAP claims that they support testing to prevent customers from buying software that is not a good fit.
  • We verify this claim for accuracy.

Video Introduction: Is It True That SAP Performs Tests Before Selling Software?

Text Introduction (Skip if You Watched the Video)

SAP has a long history of forcing ill-fitting applications into their customers. This is enabled by SAP’s unethical sales teams and vast, unethical, and compliant ecosystem. This ecosystem usually repeats whatever SAP says, and denigrating all other applications and pretending that SAP has high accuracy on previous statements. However, Luca Massasso of BizBrain Technologies (and ex-SAP employee), a consulting firm focused on APO and IBP, states that this is not the case. We debate Luca and contrast our experience with his. You can decide for yourself if you think that SAP is all about providing tests that show the reality of SAP to prospects and if you consider a proof of concept controlled by presales as an appropriate test.


These comments we made on an article by Lora Cecere titled Where There is Smoke There is Fire. Luca stated that SAP was adopting Lora Cecere’s focus on testing before making purchases.

Here is Luca’s Initial Comment on Lora’s article.

“Hi Lora, I was part of the team that developed SAP Supply Network Collaboration and since 2013 I dedicate my time to the implementation of SAP IBP (before “S&OP on HANA”). One thing I can confirm to you: the vast majority of customers has changed habit and they are fully following your advice: “Test technology and ensure business results. And, in the process, trust but verify.” In these recent years we have been involved in more than 40 evaluations and sales cycles and pretty much all of them required a Proof-of-concept or a small pilot. This happened for customers of almost any size. Perhaps additionally, it would make sense to mention that in the test you recommend, not much emphasis goes into the aspect of modeling the integration of Supply Chain Planning and Supply Chain Execution. On this topic, I have seen but also heard (2nd hand) many horror stories of allegedly better solutions than SAP, where the integration of planning into SAP ECC was a failure. I think your point captures what we have so far experienced in the IBP market, but I would additionally humbly recommend to look at the business process as a whole and understand that Operations team need a working end-to-end solution. Thanks for your articles, always a pleasure to read.”

Our Response

This is an interesting attempt to embrace Lora’s message and perform damage control. Contrary to your statement, SAP entirely opposes Lora’s advice on testing. SAP habitually and as a strategy circumvents testing. If APO had ever been testing, almost no one would have purchased it. This is why SAP can’t really move to the cloud, the cloud is about testing, and SAP is about making based upon giving out goodies to executives, getting SAP consulting partners to lie about the SAP applications, and false promises by SAP sales. It is the exact opposite of a testing approach. If you like testing, we have a large number of articles that test functionality on our website.

But you probably won’t want to read the test results. If the testing of APO were a movie, it would fall into the horror genre. If SAP sees a deal moving away from them based upon testing, they will put pressure at the tippy top to get the executives to ignore the test results and ignore the users’ desire. Unless you get to see how the sausage is made, it is difficult to appreciate how corrupt SAP is. SAP is all about the money. They will jam the least appropriate solutions into customers by any means necessary.”

Luca’s Response

“Your statements oversimplify the reality. I am in this business almost three decades and money is pervasive in so many dimensions including the ones that claim independence by statute. I respect different viewpoints but again reality had been and is that in my direct experience every company evaluating sap ibp has worked exercises to evaluate the software and put it to the test. For confidentiality reasons i cannot name them on a social platform, but they are among the largest sap customers and the most important companies in the world. The exercise led to conversation with SAP development on roadmaps where gaps were identified. In some cases IBP has been successfully deployed (microsoft is a public reference for example or Prestige Brands or Nature’s Way on smaller size organizations). Where i saw problems with the delivery was when the consulting force was not proficient on what the tool can’t or can do. There are plenty of examples where previous apo customers selected (or did not select) ibp based on poc/prototypes and pilots. We can look back at apo, but ignoring this and writing that sap sales cycles are not subject to testing is in my experience factually inaccurate and depending on statistics probably wrong.”

My Response

“I only want to address the last part of your answer. So I want to distinguish what you consider testing and what I consider testing. Earlier, you commented about POCs. This gives me the impression that you think a POC is a test. POCs do not meet my definition of a test. The test must be performed by an entity that does not care or is indifferent to the test results. That is, they are indifferent. I had worked on pre-sales engagements and received heavy pressure from sales to rig the results to make the SAP software look it was a perfect fit for the requirements when it wasn’t. When we would get a POC, it was good because the client would pay, but sales entirely controlled the process. The pressure is to make the sale, not to show anything realistic. I don’t think other vendors work much differently in this regard. Still, SAP, because of its enormous influence and partner network, leads all other vendors to push their applications and databases into situations for which they are a poor fit.

SAP nor can any SAP consulting partner perform any test or POC. The reason is apparent. A test must have no bias for the test to succeed or to fail. So, under your definition of a test, tests are sometimes performed during the sales process (although not often). SAP and most other vendors will oppose any independent party being included in the process. I can communicate that I have extensive experience in testing solutions, and I run a research entity. I am constantly evaluating software and recording the accuracy of things like SAP’s statements to clients. I would provide an entirely unbiased test result.

However, I can guarantee you; I will never receive a call from SAP (or Oracle or IBM) to perform tests where the client pays. SAP, Oracle, or IBM would actively fight my entry or the entry of any testing entity that they do not control. Also, I can promise, any test I perform will not match with the statements made about sales to the prospect.”


The following comment is Luca’s strongest point.

“We can look back at APO, but ignoring this and writing that sap sales cycles are not subject to testing is in my experience factually inaccurate and depending on statistics probably wrong.”

However, again, a POC run by SAP is not a test. Secondly, APO does not win every single competition is not evidence that testing is performed before APO is purchased. And this generalizes far beyond APO. SAP applications are routinely purchased without an independent entity performing the tests. Biased SAP consultants and SAP like to stated that a POC they control is a test when it isn’t.