The Art of Blaming the Client When an SAP Project Goes South

Executive Summary

  • SAP has a specific premeditated way of paying off consulting and media entities to get them to point the blame towards customers.
  • These financial connections are not declared by either IT media entities or those interviewed in the articles.

Video Introduction: Formal Way of Blaming the Customer

Text Introduction (Skip if You Watched the Video)

After reading some articles on project failure, we have observed a consistent theme in much of the coverage. This is another example of how every time an implementation goes sour, it seems as if the official publications put more of the blame on the clients. The repetitiveness is such that it appears to be an algorithm at play when a project goes south. We review an article written by a fake independent expert on ERP, who is highly biased. You will learn how this fake independent expert provided false information to readers about the SAP ERP failure at The City of San Diego.

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. 

The Algorithm of Deflecting Blame

An algorithm is a set of repeating steps, a pattern.

The algorithm of explaining major implementation failures looks like the following:

  1. The software gets to make a statement, which is positive and boilerplate.
  2. The next entity they go to is the consulting company, which often issues a similar boilerplate statement, which typically involves a backdoor brag and an IT analyst.
  3. The IT analyst almost always says something convoluted, which seems very carefully crafted to emphasize the process rather than the performance of either the vendor or the implementation partner. This may have something to do with the fact that the vendor and the implementation partner advertise in these publications.

City of San Diego SAP Implementation

An excellent example of this is the City of San Diego’s case and its failed $50 SAP implementation.

The City of San Diego SAP implementation has been in the news for some time and had a wealth of information on which to conclude. After the implementation failure, the City of San Diego hired the consulting company, Huron Consulting, to perform the post-mortem analysis.

Financial Bias Among the Commenters?

The spokesman for the software vendor has a bias not to take any responsibility for the issues and to minimize the story. All comments are cleared through their legal department. The publishing company has a financial bias because they take advertising from software vendors, consulting companies, etc.. And believe me, I can understand the position that these publications are in. They get, on average less than half of their revenues from subscriptions, so they have to be careful how they publish because advertisers are pleased to threaten to pull their advertising revenues in response to articles they don’t like.

I also have noted that some of the commentaries seem to be thick with financial bias, and worse than this, an economic bias that is not obvious and appears to be undeclared. For instance, I am concerned that Michael Krigsman, probably the most quoted analyst on IT project failure, often mentions that the client made errors. At the same time, in his mind, the consulting company and vendor receive no blame whatsoever. Krigsman does not only occasionally but has a pattern of blaming the client. This, of course, will ingratiate him to the software vendor.

Here is one of his statements.

“Change management and training are critical parts of any ERP impleClients have a hard time accepting it, but that is the truth of the matter, and I have extensively documented some of the areas that I have run into that do not work, as advertised in various articles sub-blogs scmfocus.com.mentation,”

And the following.

“Employees without sufficient training may avoid the new system because they cannot figure how to use it. Bypassing the new system is prescription for disaster because data may then reside in multiple systems, or software applications.”

Who Messed Up Training Exactly?

His comment in this article is that training is essential, but was that the issue in the San Diego implementation? That should be made clear in the quotation. Anyone can state that this or that is a standard issue on projects. But if the discussion is about a specific project, then a particular observation into the analyst’s opinion on the problem is required.

I point this out because it is not only the City of San Diego’s responsibility to — for instance — schedule and verify software training but the implementation partner’s responsibility as well.  Another critical question is who performed the training? This is often done by SAP and or the consulting company — again, the report is silent on these points.

His next quote from Krigsman is peculiar to the project.

“Also the fact that San Diego memorialized inefficient processes into the SAP system rather than take the opportunity to refine them will require it to repeat this core implementation step,”

Krigsman Cherry Picks the Conclusion from the Huron Report

This statement by Krigsman cherry picks the conclusions of the Huron Consulting report. See this quotation from the report:

“However, it is difficult to know whether underutilization of SAP and reliance on manual processes are attributable to the lack of SAP training; processes poorly designed at the time of implementation, which now require reconfiguration; new system enhancements are needed to achieve full automated functionality for P&C; or other factors. One certainty is that when P&C processes are 4 slowed, it significantly impacts all operations of the City as we have learned in recent years.”

The report says that they don’t seem to know the cause, and through the report, several reasons are pointed to.

Krigsman was neither on the project nor had more access to information than the Huron Consulting report. Did he interview the City of San Deigo, SAP, Axon, etc.. The article does not say.

Did Krigsman interview the City of San Deigo, SAP, Axon, etc…? Where is this information coming from?

The article does not say.

Who Did What?

The Huron Consulting report does an excellent job of assigning blame to no one. So The City of San Diego hired a Huron to provide an objective statement. However, reading the report and having worked for consulting companies and knowing how those at the top of them think, I would wager that the partner that managed the story realized that by saying as little as possible and by being diplomatic that he/she could maximize Huron’s future business. And that is Huron Consulting’s objective, not to provide an accurate assessment to the City of San Diego. The question is, how did Huron think it was going to increase business by diving into the report. Was this through more business with SAP? It’s just impossible to know.

Huron Consulting Did Not Want Any Trouble

Reading the report shows that the people who rolled the report that Huron Consulting wrote were uninterested in getting to the bottom of anything. They made a great effort to obscure what should have been fundamental facts of the implementation. One huge mystery is who implemented this software for the City of San Diego?

Mystery Implementation Partner?

Who implemented SAP for the City of San Diego is not significant enough to be in the Huron Consulting report. Interestingly, the Huron report also does not bring up SAP’s performance at all — and there is no mention of the implementation partner in the report.

Why? 

The answer to this big mystery is that Axon Consulting had the contract until 2009 when they were fired and replaced by SAP. However, you will not find that anywhere in the Huron report. At the time, this was considered a coup for SAP, but five years after — SAP was not able to successfully implement at least an important part of their application.

The report is both hazy on what the problems are and who is responsible. In five years, that is the time after 2009 when they replaced Axon; SAP would have had ample time to provide training — why didn’t they?

SAP ERP May Not Be the Right Application for Requirements?

Another portion of the report states that SAP ERP may not be the right application for the requirements. So why not? Why is the elaboration so lacking? Here is a quotation from the Huron Consulting report.

“It is also possible that SAP may not be appropriate for certain functions, such as the solicitation process, which is being handled through Planet Bids; or whether it is cost effective to integrate Planet Bids with SAP as suggested by Huron.”

This is quite an equivocal statement. Anything is “possible,” but Huron was hired to provide its professional opinion. One could have made this statement before doing any research of any kind. Why didn’t Huron use their internal knowledge or find an SME on the open market to determine if it was or wasn’t?

This is the type of statement that makes one question the intention of Huron — as if they deliberately made the report as vague as possible. There are some uses of the word “possible,” mainly when parties’ liability outside of the City of San Diego is at issue. Did the City of San Diego pay for an audit or report to learn what was possibly a problem?

Software Selection Issues?

If it is a fact that the solution sold had mismatches with the requirements, which it most likely is given the problems on the implementation, it relates to an error in software selection. But did SAP sales give San Diego the impression that their software could cover their requirements? I cover this topic in the article The Effect of SaaS on Software Selection.

Again, the report is silent on this particular but crucial topic. The way the report was written lead me to presume that Huron had a SAP consulting practice and that Huron was cozying up to SAP by writing a report that protected SAP. Initially, I thought I found jobs advertised for SAP consultants at Huron. However, that does not appear to be the case in any substantial way. I also found a job posting that listed SAP as one of the skills, but it was a related skill — not as the primary skill. I also found an article written by Huron regarding Business Objects Consulting — which is now an SAP product, but there is nothing about SAP on Huron’s website. Huron does not appear to receive a substantial amount of consulting revenue from SAP work. Therefore the way the report is written seems inconsistent with the lack of leverage SAP has over Huron. There is something’s analysis of the Huron report’s analysis, but I can’t find Huron’s motivation.

Using Krigsman to Deflect

Krigsman’s statements have the consistent effect of deflecting the client’s criticism away from SAP regarding what they received for what is, in this particular case, a $50 million expenditure. Huron Consulting’s report does the same. One of the most prescient comments was made by a self-identified City of San Diego employee made back in 2011.

“As a retired City of San Diego drone, aka 1st level supervisor, I watched in amazement as they spent tens of millions of dollars on SAP (and they’ll have to spend millions more before they get it to “sort of” work). A system ill-suited for handling public works calls, it’s really stressing out any employee who has to use it “hands-on”. And you have to stand in awe of how the people at SAP have been able to blame the buyer (customer!) for its many failures.”

Well, SAP has been able to blame the City of San Diego, but they did so with some help. They could not have done so without this help.

Trying to Implement Too Much SAP Complexity?

It is a common thing for SAP implementations to be overrun with complexity. But there is such a thing as an appropriate level of complexity. That is a level of complexity that the overall implementing company and those at the implementing company can absorb.

SAP ECC and SAP APO as Examples

SAP ECC is well known to be one of the largest bundles of functionality that one can buy in an application. However, SAP usually stuffs all of its applications with large amounts of functionality. SAP APO has an enormous functionality footprint. However, one could argue that there is too much in SAP APO. 

Advanced functionality is a double-edged sword because if the advanced functionality is not correctly implemented, then the customer is worse off versus having used a simpler approach.

There are options to use easier or more advanced functionality in all APO modules, and I routinely recommend that clients start with the less complicated functionality. However, everyone seems to like the new “new sexy” even if they lack the internal resources to pull the implementation off.

SAP is different than other software vendors in that the functionality has higher variability in quality than in other vendors. Therefore testing and picking the functionality to be used is more critical than in any other software vendor I have analyzed.

Yet, many factors work against taking this more scientific approach.

Incentives to Choose the Sexy Over the Practical Functionality

The number of entities pushing towards less practical implementations is quite significant.

  • Consultants who are external to the company like to push the most complex solutions, which most often means the most consulting dollars.
  • Many internal IT employees want to put the most sophisticated and complicated methods on their resumes to be more marketable.
  • Executives decision makers tend to be optimists, so the brew is created for implementing too much complexity.

Example From the Field

I recently consulted with a company that had never been able to get MRP work and instead used the ERP systems to “record” what they had done rather than plan anything in advance. MRP is the simplest form of supply planning.

This same company decided to go forward with implementing SNP, a more advanced form of supply planning, and they bombed the implementation.

Injecting Reality into IT Decision Making

When reading books or articles that explain functionality, I notice a clear orientation to describe the functionality only in terms of its benefits. However, nearly all functionality implies some overhead, and a company can only activate so many areas of functionality within an application because there are limited resources on projects. Planners and planning departments have a limited capacity to learn and apply various functionality.

I was recently reading a book on SAP APO, and in the book, one area of esoteric and challenging to configure functionality was trotted out after another, and I began thinking.

“The author can’t possibly believe that clients will be able to implement most of these can he?”

Of course, that is the problem when an author also works for SAP, and the book is treated as much as a sales device as it is a mechanism to explain how to use SAP software. SAP consulting /implementation is entirely subordinate to sales and marketing. This is the problem with software vendors under the heavy pressure of continually making earnings numbers — it moves most of the organization’s power to those that can make the short-term numbers.

What is the Maximum Tolerable Functionality?

This “maximum tolerable functionality” level is quite evident when one reviews APO implementations live for years. In every case that I have reviewed, the company implemented some functionality that they could not maintain. Thus the functionality fell into disuse or was no longer active in the solution when I did the review.

Misperceptions About SAP’s Functionality

This is a problem I run into quite a bit with clients. Clients sometimes hire a consultant to see if they can get SAP APO to do something they have not yet been able to do. This request typically goes in two different directions:

  1. In many cases, a company is merely attempting to enlarge its use of the application and configure areas that have not yet been configured, skipped during the initial implementation due to time constraints. In these cases, the company’s attempt to get more from SAP may work out.
  2. In other cases, a company is bringing in someone new to attempt to get functionality working that has already had several people look at it. It has already had OSS notes opened for it and has been researched. But the people who have worked in it have run into a software limitation. In this case, it’s rare that a new person comes along and gets it to work because it is software, not knowledge-related.

I often run into the problem that several attempts have been made to get the APO, or the BW, or CRM, or PLM, etc.. to do something. And the actual issue is that SAP’s module is just not very good at it, or the functionality that is promised merely is defective. At a recent client, when I recommended an alternative solution that was a great fit with the company’s requirements, I was told that “we want to make sure we are getting the most out of SAP.”

  • PP/DS lacks the functionality for process industry manufacturing.
  • DP has not had real consensus collaborative forecasting functionality.
  • DP does not manage attributes or perform top-down forecasting very well.
  • DP cannot optimize forecast parameters (Alpha, Beta, and Gamma) except during the best fit procedure, but almost no one runs the best fit in production.
  • SNP does not perform inventory optimization
  • SNP does not fairly share the way companies want unless the stars and dates align

The Reality

Many parts of SAP do not work as clients think they do. That is simply a fact. I often deal with clients post-go-live, and the perspective post-implementation looks a lot different than when all the promises are being made at the beginning of the implementation. At the end of the implementation and years into using the application, all that is left is bringing in SAP Platinum Consultants. They most often cannot solve the issue or develop some convenient excuse as to why the promised functionality should not have to work in the client environment. This can lead to seemingly endless recursive conversations with a person with little SAP knowledge assigned to the SAP OSS Note system, who has difficulty writing or understanding English. It’s quite depressing.

What to Do?

There are so many things that SAP SCM (and BW, CRM, PLM, etc..) does not do that it’s essential to recognize that and learn on applications that can perform the necessary functionality. Trying to get more out of SAP can often mean not getting the business requirements met. But spending quite a lot of money recursively trying to get SAP to do something that another best breed vendor can do in its sleep (all of the examples listed above can be provided without issue by best of breed vendors). Using a best of breed vendor to augment a solution does not mean pulling out the original solution.

Conclusion

The City of San Diego case is a fascinating one. Interestingly after the failure, the City of San Diego commissioned a report to figure out what went wrong. But they chose a consulting group that lacked the integrity and or backbone to write an accurate statement. It’s hard to see the value that the City of San Diego received from this report. In the IT media, the story was convoluted by both vendor spokesman who sort of released meaningless information and then by at least one IT analyst who diplomatically essentially put all the blame on The City of San Diego.

Anyone reading this article because they have a problem with SAP implementation, I am an excellent place to contact first. I can provide the next steps, and I look out for the interests of my clients who have implementation problems.

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, “hover off” and then hover over the new bullet.