- SAP license management companies display a lack independence.
- We cover this independence problem.
License consulting companies are probably one of the only groupings of advice offering entities that can really claim to be independent of SAP.
The Limitations of Scope of SAP License Management Companies
While SAP license management companies show much more independence from SAP than other entities that provide advice around SAP. It should be noted that licensing management entities are not active in that many dimensions of SAP. They focus on the contract side. While licensing is one dimension where there is more independence, there are far more dimensions that are uncovered by any entity providing independent advice. We would know as we perform the research in more non-licensing dimensions than licensing-dimensions of SAP, and the publications about (choose any topic) show remarkable consistency from publishing entity to entity. That is they don’t diverge from the SAP marketing message. And working on SAP projects, the advice offered on direct communications with the customer match the published information from these entities.
And of course, it’s not as if Deloitte. etc… are dying to provide honest information to its clients, but even if they wanted to, they are restricted by the partnership agreement they signed with SAP.
The Independence of SAM/License Management Software Vendors
There is one issue within the SAP license management space. So the license management/SAM vendors are partners with SAP. They have to be to get their software work with SAP. That means they have to watch how they step around SAP. If you look at the publishing around indirect access by the SAM vendors, they did not take the position that SAP’s position was untenable and it was cheating the customer, and even illegal — which we have written is the undeniable conclusion, but that indirect access could be managed with their software.
The licensing consulting companies rely on SAM software, so one could see some “tendrils” of SAP reaching out to the license management companies through the software that the license management companies rely upon. When SAP has a point of leverage, they use it. And their “partnership managers” are I think the best in the business. For those looking for training as “muscle” in enterprise software, the SAP partnership division provides the best training in intimidation tactics.
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 SAP Project Management Content
Enterprise Software Risk Book
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