Who Wants Honest SAP Advisement Business?

Executive Summary

  • There are plenty of firms that perform SAP advisement, but the advice ends up being rigged due to financial incentives.
  • Large companies use advisement to provide advice that leads to other business.


A large number of consulting companies provide advice and perform anything from software selection assistance to supporting various analytical initiatives. However, none of the larger, and very few of the others actually see themselves in the decision support business as a business. In this article, we will describe why this is such a problem.

The Financial Incentives at SAP Consulting Firms

In order to attain and retain a leadership position at an SAP consulting firm one must bring in roughly $2 million in revenues per year. There is no way to attain this quote by performing smaller projects, of which software selection and analytical initiatives would be examples. To attain this yearly quota, one needs to sell implementations. Decision support projects tend to smaller, shorter, and offer less stable consulting revenue. For a company with a significant overhead (offices, support staff, large senior member compensation) smaller projects of this nature are not sustaining.

Secondly, one of the best ways to sell implementations is to position oneself as a “trusted advisor” and then sell out the client’s interests by directing them to implement the most possible software. This means acting to promote SAP software, regardless of the fit with the client requirements, the cost, the maturity of the application, and another other factor related to things that make software a good match for a particular client.

The Implication of How Incentives are Structured

This means that SAP consulting companies are unreliable for providing software selection support as they have a massive financial bias. SAP consulting companies will claim major domain expertise as a reason for using them in an advisement capacity, but even the deepest domain expertise cannot overcome financial bias, and in truth, the decisions are normally filtered through the senior management of the consulting company, with little freedom given to the more junior members of the organization who possess most of the domain expertise.

An SAP consulting company may take the advisement or selection project, but only as a means to gain more future work. When they report back to their other senior members, success is measured by how much further business is obtained (at KPMG the catchphrase is “penetrate and radiate.”) The concept of providing objective analysis, and then rolling off of the project is only measured as a failure.

Having discussed this topic with several experienced consultants, we were told that recommending solutions on the basis of financial bias is “the way that it is.” And that further, it is a good thing, because the benefits flow to the consulting firm with the strongest relationship. The trick is not to tell the client that you are doing it. And this is considered perfectly normal in the SAP consulting field.


From an independence perspective, it is a concern how much “copy and paste” there is from consulting companies. This quotation below was off of the Infosys website. This is essentially directly lifted from SAP, and it shows the degree of copy and paste that occurs and the way that messaging is coordinated.

“At SAPPHIRE NOW and the ASUG Annual Conference, you will have the opportunity to explore the full array of Infosys’ winning solutions based on SAP S/4HANA, SAP Ariba, SAP Fieldglass, SAP hybris, SAP SuccessFactors, Concur, and Fiori, that have given our clients the competitive edge. Attend the joint sessions with our clients to understand how to jumpstart your own digital journey.” – Infosys Website

This means that when a customer talks to Infosys, Deloitte or any other consulting company, they are not offering their own views, but rather presenting SAP’s views.


There is no feasible way for senior members of SAP consulting firms to attain or maintain their positions without putting their financial incentives ahead of their clients. None of the major SAP consulting firms and very few of the smaller SAP consulting firms have a model that allows for anything but grabbing implementation business by any means possible. And one of the best means is to pretend to provide decision support.

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


Enterprise Software Risk Book

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

Rethinking 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.


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