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.

Introduction to a Formal Way of Blaming the Customer

After reading some articles on project failure, I have noticed 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. After reading so many of these articles of problematic implementations, it appears like an algorithm.

The Algorithm of Deflecting Blame

An algorithm is 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 then finally 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 vendor and the implementation partner advertise in these publications.

City of San Diego SAP Implementation

A good example of this is the case of the City of San Diego, 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, is simply too often mentioning that the client made errors, while 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 implementation,”

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 as a general statement true — that is 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 specific 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 important 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, a number of causes are pointed to.

Krigsman, who was neither on the project nor has 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 report. 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 report 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

Because reading the report it is evident that the people that worked on or controlled the report that Huron Consulting wrote were uninterested in getting to the bottom of anything. In fact, they made a great effort to obscure what should have been very basic facts of the implementation. One huge mystery, is who implemented this software for the City of San Diego?

One huge mystery, is who implemented this software for the City of San Diego? Why is that made plain in the report?

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? 

In fact, 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,” particularly when the culpability of parties 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 true 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 is off about the analysis in the Huron report, but I can’t find Huron’s motivation.

Using Krigsman to Deflect

It is clear that Krigsman’s statements have the consistent effect of deflecting the criticism of the client away from SAP regarding what they received for what is in this particular case a $50 million expenditure. It is clear that 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, in fact, they could not have done so without out 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 that work 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 normally 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 properly 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 of the APO modules, and I routinely recommend to clients that they start off with the less complex 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 a higher variability in quality than in other vendors. Therefore testing and picking the functionality to be used is more important 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 as it most often means the most consulting dollars.
  • Many internal IT employees want to put the most sophisticated and complicated methods on their resume so that they will 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 an implementation of SNP, which is a more advanced form of supply planning, and unsurprisingly they bombed the implementation.

Injecting Reality into IT Decision Making

When reading books or articles that explain a functionality I notice that there is a clear orientation to describe the functionality only in terms of its benefits. However, nearly all functionality implies some type of overhead, and a company can only activate so many areas of functionality within an application because there are limited resources on projects, and 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 difficult 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. In SAP consulting /implementation is entirely subordinate to sales and marketing. This is the problem with software vendors that are under the heavy pressure of continually making earnings numbers — it moves most of the power in the organization 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 that have been live for years. In every case that I have reviewed, the company implemented some functionality that they were unable to maintain, and thus the functionality fell into disuse or was no longer active in the solution at the time I did the review.

Misperceptions About SAP’s Functionality

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

  1. In many cases, a company is simply attempting to enlarge its use of the application and to configure areas that have not yet been configured, that were 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, that 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.

The problem I often run into is 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 either very good at it, or the functionality that is promised is simply defective. At a recent client when I recommended an alternate solution that was a high 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 fair 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, clients 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 in sub-blogs at scmfocus.com. 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 really left is bringing in SAP Platinum Consultants, who 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 actually.

What to Do?

There are so many things that SAP SCM (and BW, CRM, PLM, etc..) does not do, that it’s important to recognize that and learn on applications that can actually 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 of 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 be written to figure out what when wrong, but they chose a consulting group that lacked the integrity and or backbone to write an honest report. It’s hard to see the value that the City of San Diego received from this report. Then 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 are having a problem with a SAP implementation, I am a good place to contact first. I can provide next steps, and I look out for the interests of my clients who have implementation problems.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP Consulting Firm Management Content

References

Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model