How to Understand The SAP Acquisition Playbook

Executive Summary

  • SAP gained cloud market share exclusively via acquisition. This playbook demoted in-house development into a second-class citizen.
  • We cover how SAP’s dysfunctional acquisition strategy works.

Introduction

Bill McDermott became CEO at SAP February 7, 2010.

His goal was to make SAP number one by market share in cloud apps.

He looked at the market and found lots of fragmentation.

Many smaller app companies waiting to be “consolidated”.

Bill went on a shopping spree in 2011 and never stopped.

 

The History

Between 2011 and 2018, SAP acquired

Crossgate, SuccessFactors, Ariba, Hybris, Fieldglass, Concur, Callidus, and Qualtrics.

In the same 8 years, SAP also acquired

Coresystems, Recast, Gigya, Abacus, Plat.one, Altiscale, Fedem, Roambi, SeeWhy, KXEN, Camilion, SmartOps, TicketWeb, Syclo, Datango, RightHemishpere, Crossgate, Cundus,  and Secude.

 

The Cloud Story

Every cloud app SAP sold since 2011 was acquired not developed internally.

 

The Problem

Acquiring three companies every year for eight years looks great on Excel sheets and sounds great in press releases.

Instant revenue growth, more market share, and more products. In reality, getting that many companies, teams, and products working together is absurd.

Too many apps that were never designed to work together.

None of the acquired cloud apps is integrated with SAP’s core.

The acquisitions just transferred the fragmentation to SAP’s product portfolio.

 

The Result?

Dozens of functional silos added to SAP and customer landscapes.

Tech stacks and technologies that don’t work together.

Duplicate apps and overlapping functionality.

High cost and failure rate of integration projects.

Internally, SAP sales targets were never achieved.

Product development and integration deadlines never met.

Eventually, SAP called in a “cleaner”.

Elliott Management convinced the board to remove top SAP sales and product executives and approve a massive restructuring plan to consolidate the exploding portfolio.

Multiple products to be “de-emphasized” then jettisoned, others combined or replaced by technology partner offerings.

Thousands laid off last January.

 

What’s Worse?

8 years of acquisitions (instead of in-house development) killed the engineering culture at SAP.

SAP in-house development still builds apps using ABAP and 4GL NetWeaver technology.

Other than that, great strategy.

The Problem: A Lack of Fact-Checking of SAP

There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

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 Acquisitions Content

References

https://www.bloomberg.com/news/articles/2019-04-24/sap-elliott-are-said-to-have-held-strategy-talks-for-months

AWS and Google Cloud Book

How to Leverage AWS and Google Cloud for SAP and Oracle Environments

Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.

The Top 3 Things to Look for In a Cloud Service Provider

Executive Summary

  • Companies often can use help in what to look for in a cloud service provider.
  • These are our top three items.

Introduction

Before moving into cloud service provider selection, it is important to establish some of the following principles for selection.

How Companies Tend to Approach Cloud Migration

Customers often approach cloud migration with an inappropriate framework, and this is right from the beginning of the evaluation process. Normally, they begin by comparing cloud service providers to each other (AWS versus Azure versus GCP).

This is a natural approach, but it is not an approach that will lead to the best outcome.

How We Recommend Setting the Framework for Selection

  • In our view, the best framework is to compare each service provider to their own IT.
  • Essentially, cloud adoption means that customers outsource IT service management. This is a viable option only if the service provider is more efficient than the customer’s own IT. If not, customers end up with less agility, less availability, and higher TCO.

Let us move to the three primary selection criteria. 

#1: Agility

If a company moves to the cloud, they expect their business agility to increase, and certainly not to decrease. We know a few customers who recently migrated to a cloud services provider in the US. After moving their applications, their support tickets are now measured in days instead of the hours it previously took their own internal IT staff.

Why?

Because problem tickets and change requests are handled internally on the provider side by multiple teams (product support and hosting operations). The operations teams have no product expertise and vice versa. Moreover, each team has its own set of SLAs. Each customer request triggers multiple internal change requests involving multiple teams operating in different locations and time zones.

#2: Availability

Consider release management. When the service provider applies a patch or upgrade, it gets applied by the operations group to all customers on the same application version. This causes days of downtime.

Why?

Because each customer has specific configuration and extension environment. These changes are not tracked by the hosting service provider.

  • In the past, application owners and administrators had to coordinate change management with their own IT who tracked all changes into their ITSM databases.
  • When customer IT released a patch or upgrade, they knew exactly the status of each specific application environment and they incorporated the latest changes into their release packages.

Another scenario is increased downtime compared to customer’s own IT service level agreement (SLA).

Why?

Because some cloud service providers have a dependency on their colocation facility provider. This means that customers have to deal with multiple sources of planned and unplanned downtime. We covered this in detail in the article The Problem with the Oracle Cloud and Colocation.

Moreover, customers have to deal with multiple SLAs instead of one SLA with their own internal IT.

Companies love using the term “one throat to choke.” However, whose throat do you choke for a 24-hour production outage?

#3: TCO

Customers often compare the TCO of different cloud providers to each other.

As we stated earlier, this is not the most helpful framework.

Why?

  • Because customers want lower TCO than their own in-house IT.
  • If a customer’s IT has lower TCO than a specific provider, they end up spending more not less.
  • A cloud service provider can deliver lower TCO than a customer’s in-house IT in specific scenarios. Customers should verify these scenarios as they plan their cloud migration journey.

Let’s look at some examples.

Example 1: Self-service (Automation) Versus Manual Service Provisioning

Service providers vary vastly in their service delivery capabilities. On one end, customers need to open a ticket to provision an instance or increase the capacity of an attached storage volume. In this case, the work is performed manually by teams that support hundreds or thousands of customers across dozens of time zones and the cost of labour increases with every new customer onboarded.

Example 2: The Cost of Labor Has to be Transferred to Customers.

On the other end, there are providers with mature self-service and automation capabilities. This means that less manual labour is needed for most customer requests. For example, with AWS CloudFormation, a customer can create an entire data centre (or VPC) using a single script file including all the resources needed across all regions and accounts. Labour-intensive service providers have higher TCO due to the increased cost of labour. Moreover, labour-intensive service providers have lower agility due to manual work and rework introduced by human errors.

Example 3: Right-Sizing Infrastructure Versus Rehosting (Lift and Shift)

Customers often assume, incorrectly, that the cost of cloud infrastructure must be lower than their in-house IT. In some cases, cloud infrastructure TCO can be much higher than on-premises for the same workload. The first factor is scale. If the service provider operates at scale, they can command the highest volume discounts from manufacturers and they can pass part of these cost savings on to customers. Niche providers lack the economies of scale and the associated cost savings.  

The second factor is infrastructure technology. Some service providers operate a single-tenant dedicated infrastructure where customers have to commit to a multi-year contract. In this case, customers end up with the same over-provisioned infrastructure footprint they had on their own premises and their TCO will surely increase not decrease, at least by the cost of the migration.

The hardware refresh cycle for most companies is 3-5 years. This means that when they procure infrastructure, they have to plan for maximum capacity projected over 5 years of user and data growth. Invariably, they end up with over-provisioned in-house infrastructure with all the associated capital and operational expenses. This, of course, is one of the major benefits of cloud service providers. 

The result.

Cloud service providers capable of rightsizing customer workloads elastically can provide significant TCO gains anywhere between 30% to 60%.

This issue with over-provisioning was covered in our book How to Understand On-Premises Proprietary Servers and Server Vendors, hardware vendors make their money selling servers, and they have overstuffed customers with servers, and have done little to enable their customers to improve the efficiency of their previous purchases? There is a little incentive as it would simply reduce the number of servers they could sell.

Conclusion

Agility, availability and TCO are the three most important criteria to apply when selecting cloud service providers. Our approach pushes against the comparison between service providers in the initial phase of selection. Instead, customers should benchmark cloud services against their own IT. If multiple providers are found to offer higher agility, availability, and lower TCO than the customer’s own IT, then we can move to comparing service providers against one another.

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 Cloud and Multicloud Content

References

https://www.bain.com/insights/rightsizing-your-way-to-the-cloud/

AWS and Google Cloud Book

How to Leverage AWS and Google Cloud for SAP and Oracle Environments

Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.

Is SAP a Cloud Provider or a Cloud Buyer?

Executive Summary

  • SAP presents itself as a cloud provider.
  • We evaluate whether this presentation matches how it operates its businesses.

This article focuses on SAP, but the lessons cloud just as well be applied to Oracle. 

Introduction

This article began as a response to the following quotation from Vinnie Mirchandani.

The Quotation

“After two decades of cloud applications (NetSuite and Salesforce were born in late 1990s) if you look at a grid of applications by industry, by geography there is only 20% or soin the cloud. Most cloud apps are concentrated in HCM, CRM, accounting areas, not operational areas or industry functionality. Even there, if you look for support for Brazil or China or the Czech Republic your choices drop off very quickly. These industry and regional white spaces won’t last forever. We are seeing startups target them, in industries like financial services, big banks are developing solutions to sell to others. The opportunities are limitless, but SaaS vendor investments have been grudging.” – Vinnie Mirchandani

Not true in SAP’s case.

But this gets to a basic question and a question that people tend to gloss over before jumping into discussions on SAP’s cloud offerings and strategy. And that is…

Is SAP a Cloud Vendor?

Our conclusion is that SAP is not a SaaS vendor. SAP is a SaaS buyer. Let us take a look at the evidence.

  • Buying SaaS Applications: Every single SaaS application SAP sells is acquired. Their choices are therefore limited to SaaS companies they can buy since they don’t internally develop any SaaS apps. In November of 2018, SAP spent $8 Billion on Qualtrics, which we covered in the article Does SAP’s Acquisition of Qualtrics Make Any Sense? and another $2.2 Billion on Callidus in April 2018. And no one really has a very good handle on how these applications complement what SAP offers and in our view, both acquisitions just added more noise to SAP’s offering and increased their cost and management overhead. We analyzed C/4HANA (which Calladus has been rolled up into) and found the overall solution to be lost in space as we covered in the article How Accurate Was Bluefin Solutions on C4HANA? Overall, none of these acquisitions looks like they are actually for SAP, rather they are made to boost the stock price in the short term and to increase executive compensation. That is the major misinterpretation of many software acquisitions, many of them are for the executives, not for the company. 
  • The CEO said they want to focus on CRM and front office. So SAP is investing in front office technologies at a time when CRM is already saturated and dominated by Salesforce. Now SAP must integrate all their front office and SaaS apps with their back-office ERP to deliver the promised complete customer experience combining X data and O data.

Remember X and O data? This was all the rage back in November when SAP acquired Qualtrics and trying to tell investors, customers and the media what a great acquisition Qualtrics would be, but it will probably be an expired concept by the time you finish reading this sentence. SAP’s marketing department may be on to a new slide. 

Where Are We Again?

SAP also invested in HANA and now they are competing with Oracle and Microsoft as a databases company and they are competing in IaaS and PaaS with AWS, Azure, and GCP as a cloud company. And they are competing in AI and ML and RPA and and and… Don’t forget that SAP also acquired SuccessFactors for $3.4 Billion, Ariba for $4.3 Billion, and Concur for $8.3 Billion.

That’s a lot of investment. A lot of investment for applications that don’t have much to do with SAP’s primary offering. We found this quote of interest with respect to SuccessFactors. 

“In the SAP Universe, SuccessFactors is no longer really new, but integration in perfect ERP / ECC 6.0 (E2E) processes has not been successful to date. “We are working on it and know exactly about our deficits,” – E3

SuccessFactors was acquired in 2011 — how can we still be discussing integration deficits in 2019?

They even invested in Ticket-Web: A ticket system for sports and entertainment. This is because ticketing systems are……naturally connected to ERP? 

SAP has a strategy for all of these applications. Follow me on Twitter and be informed when we figure out what it is. 

The Strategy is Everything

The one-stop shop for everything model, as proposed by SAP and so many SAP consulting firms? 

How is IBM doing with this model? 

SAP spent $10 Billion on Qualtrics and Callidus to go after the CRM market and integrate back-office ERP with front office apps and upgrade hundreds of thousands of ECC customers to S/4 by 2025 and become the best database in the world and the best cloud platform and the best AI and make the best vertical apps in specific industries to compete with HP in telecom and Bosch in IIOT.

And that is a lot of “ands.”

However, Volkswagen Group and Amazon Web Services just announced they are developing the Volkswagen Industrial Cloud together.

  • Where was SAP when this happened?
  • What about the SAP Cloud that SAP has spent so much time promoting? 
  • How likely is it that SAP pitched SAP Cloud to VW for this initiative and lost this opportunity to AWS (hint..very)

VW is a German company and SAP is right around the corner and they have a long-standing relationship. Why did VW reach out to far geographies when they can’t see opportunities in auto manufacturing inside Germany? 

Conclusion

SAP poses as a cloud provider, but they really aren’t one. They are a cloud buyer.

SAP feels they need to try to maintain the illusion of being a cloud provider because their cloud strategy for cloud services is to coerce (often through broadscale application discounts) customers to buy cloud services through them. This is so SAP can upcharge the actual cloud services providers as we covered in How to Understand SAP’s Cloud Upcharge on AWS Storage.

This is ultimately a short term strategy. But to pull it off, SAP will continue to pose as a cloud services provider, so this is what they will do. As with Oracle, there will be a lot of discussion around the cloud, but not much cloud.

As for SAP’s SaaS acquisitions, none of them is important to SAP’s strategy or to their long term viability.

The Problem: A Lack of Fact-Checking of SAP

There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

Being Part of the Solution: What to Do About SAP

We can provide feedback from multiple SAP accounts that provide realistic information around SAP products — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

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 Cloud Content

References

https://mailchi.mp/b4bmedia/die-meinung-der-sap-community-1707-315765

AWS and Google Cloud Book

How to Leverage AWS and Google Cloud for SAP and Oracle Environments

Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.

Brightwork Advisory Note: A Change in SAP Development Strategy

Executive Summary

  • SAP is now making significant changes in product development strategy.
  • In this advisory note, we cover the reasons for this strategy shift and what it means for the future of SAP developers and customers.

Introduction

SAP’s board has recently come to terms with two important realizations. First, customers are moving to cloud with or without SAP. Second, that the biggest force holding SAP back in the cloud race is SAP’s own development organization. Clearly, a decision was made to put SAP on the right track.

The Cloud Journey

SAP’s cloud journey started in 2011 with the acquisition of SuccessFactors. This cloud acquisition strategy continued for a decade. SAP acquired Ariba in 2012, Hybris in 2013, Fieldglass and Concur in 2014, Callidus in 2018, and Qualtrics in 2019. At the same time, SAP made a number of acquisitions in IoT, AI, big data, and RPA. Fedem, Altiscale, and Plat. One in 2016, Recast.ai and Contextor in 2018.

Over the past decade, every SAP cloud application was acquired NOT developed internally.

SAP favored cloud acquisitions over in-house development for a number of reasons. First, developing enterprise cloud apps takes years. An acquisition, on the other hand, delivers an instant new product, instant new revenue stream, and instant new customers.

In a press interview a few days following the Callidus acquisition, SAP’s CEO Bill McDermott said:

“It would have taken too long to build it”

and…

“We did that to get another cloud revenue stream in the mix” [1]

The Cloud Acquisition Side-Effect

SAP’s cloud acquisition strategy had an unfortunate side-effect. It robbed SAP’s own product organization from the opportunity to evolve beyond the monolithic, ABAP, NetWeaver application server and embrace modern cloud methodologies, architectures, and tooling.

With SAP’s cloud apps being exclusively acquired not developed internally, the development organization was effectively kept in the dark ages for too long. Developers had no compelling reason to upgrade their skill sets and remained focused on doing things the old way.

Moreover, The acquired cloud properties continued to operate as independent entities with their own siloed development organizations and none of the “cloud DNA” was infused into SAP’s own development organization.

The Pull of the Monolith

The monolithic development mindset at SAP made it practically impossible to build services. Cloud services (IaaS, PaaS and SaaS) are distributed, multi-tenant, loosely-coupled, API-driven, independently and horizontally scaled. Monoliths are massive, centralized, single-tenant, tightly-integrated, vertically-scaled systems. SAP HANA and Leonardo are examples of how this monolithic development mindset handicapped SAP’s cloud transition.

HANA  was born as a specialized OLAP appliance. Later, the product included an OLTP database, an application development platform, and an application server supporting the world’s most sophisticated ERP application suite.

Can you imagine the complexity of making the smallest development decisions for a product with this many design goals? More importantly, this monolithic approach is completely incompatible with how cloud services are consumed. How do you charge a customer who wants to use Search and Streaming services only? How do you scale the mobile service only?

SAP Leonardo also started life as an IOT platform then grew to include analytics, machine learning, big data, data intelligence, and blockchain! The same monolithic development mindset that wants to build large, complex, tightly-coupled, single-tenant systems instead of smaller, specialized, lightweight, API-driven distributed services.

By comparison, consider how AWS AI products are designed and offered. Specialized, single-purpose, fully managed services each covering a specific AI use case.

Mission Impossible

As an ABAP developer, how do you make the transition to the cloud? Here’s a slide from SAP TechEd 2018. SAP expects ABAP developers to learn: UX, SAP HANA, State of the art development, and Cloud. A piece of cake, especially when all cloud apps were acquired!

The New SAP Cloud, IoT, and ML Strategy: Less Proprietary, More Technology-Agnostic

  1. The board recently approved key personnel changes at the top echelon of the development organization including the CTO, product development leadership, and teams.
  2. The NEW SCP IaaS and PaaS strategy will be significantly less SAP proprietary and more technology agnostic. SCP/Neo and Leonardo IoT will move to Azure by the end of the year. [2]
  3. SCP/CF will expand its PaaS offering with more investments placed on open source.
  4. SAP HANA will expand into smaller, more specialized product groups. Expect a fully-managed AWS RDS for HANA by mid-2020 similar to AWS RDS for PostgreSQL, Oracle, and SQL Server. The service will support automated provisioning, scaling, backup, and recovery.
  5. Going forward, product development will be increasingly collaborative with technology partners (AWS, Azure, and GCP). The goal is to integrate SAP products into third-party platforms as discrete, specialized, and metered services allowing administration and consumption via native admin consoles, standard API calls, and a broader portfolio of IaaS/PaaS services.

Conclusion

The success of Microsoft, AWS, and Google as technology companies was driven by their focus on developers. Their go-to-market has been B2D2B. Once developers adopt a new product, they do the internal selling on behalf of vendors. It’s a bottom-up, social proof strategy.

SAP’s traditional approach has been top-down targeting senior executives and budget owners. This approach has limited success in technology-driven categories like IaaS and PaaS where the value is more evident to developers, architects, and product owners.

Outside of SaaS, which is purely acquired, SAP’s internal developer culture needed an immediate and radical transformation. The first pragmatic phase of this transformation is now underway.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

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 Custom Code Content

References

https://www.philly.com/philly/blogs/inq-phillydeals/software-sap-ceo-bill-mcdermott-ma-callidus-hana-s4-spm-william-20180202.html

https://azure.microsoft.com/en-us/blog/mwc-2019-azure-iot-customers-partners-accelerate-innovation-from-cloud-to-edge/

AWS and Google Cloud Book

How to Leverage AWS and Google Cloud for SAP and Oracle Environments

Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.

Categories SAP

How to Understand SAP’s Cloud Upcharge on AWS Storage

Executive Summary

  • SAP is marking up AWS storage.
  • In this article, we provide a specific example of the upcharge and the percentage.

Introduction

SAP’s strategy of charging AWS, GCP, Azure and private cloud providers like HPE give customers an excellent reason to never use the SAP Cloud (which we refer to as SAP Cloud UaaS or Upcharge as a Service).

The Storage Example

AWS sells storage in Europe/Frankfurt for $2.3 per 100 GB/month. SAP resells the same storage block in the same region for $7.86. That’s a %342 premium. Storing 1 TB on AWS costs $276/year. The same 1 TB on SAP using AWS as a provider in the same region costs $943/year.

See the following screenshot.

Conclusion

This is consistent across all of AWS services when they are activated through SAP’s UaaS. This is why the SAP Cloud UaaS is so dangerous. SAP’s strategy is to markup the cloud infrastructure of other providers while doing very little work itself.

The Problem: A Lack of Fact-Checking of SAP

There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

Being Part of the Solution: What to Do About SAP

We can provide feedback from multiple SAP accounts that provide realistic information around SAP products — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

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 Cloud Content

References