How Many SAP Software Products Does SAP Have?

Executive Summary

  • SAP has an enormous product database of software.
  • We count and categorize the SAP software product database by how active or popular each of the SAP products is.

Introduction

At Brightwork Research & Analysis, we spend many hours per week researching SAP. However, it is a full-time job keeping up with SAP’s products and the constant flow of products they introduce. At one point, we asked how many products SAP had. Therefore, we decided to use SAP’s product database to code it and then count it to find out. You will learn the overwhelming number of products that SAP produces and maintains.

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 Method of Counting SAP Software Products

Counting how many products SAP has is more complicated than it might seem at first. This is because SAP has many different products, some of which are part of the same product. For instance, SAP’s ECC application is currently divided into the following individual products.

  1. SAP ERP
  2. SAP ERP Core Finance
  3. SAP ERP Core HR
  4. SAP ERP Order to Cash
  5. SAP ERP Plan to Product
  6. SAP ERP Procure to Pay

However, this is all counted as SAP ECC. So, is the correct answer to count one or six products?

We decided to count this as six products because it is consistent with how SAP has broken out its product database products. When measured this way, SAP currently has 309 products.

Categorizing the SAP Software Products

There are also many ways to categorize SAP’s software product database. We were most interested in the following categories.

  1. Product Status?: (which we coded as either Active, Niche, or on Life Support). Active is the assignment to products that are being sold at a good at a reasonable rate. These viable products made up common discussion points on SAP projects and are familiar sources of conversation among those in SAP. The Niche assignment is for sustainable products that are rarely implemented. The Life Support assignment is for products that don’t have any following.
  2. An SAP Product?: SAP acts as a reseller to several products. So, we wanted to distinguish SAP products owned by SAP and those it merely resells.
  3. A Driver of SAP Revenues?: One of the main reasons we performed this exercise was to determine how many of SAP’s products drive revenues.

There is undoubtedly some judgment in assigning these codes per product.

For instance, some products, like Business Objects, are definitively in the “driver of SAP revenues” category, while other products are more questionable as to which type they fall into. We applied our judgment from our longtime research into SAP.

The Categorization Results

We found the following features of these categories.

  • Total Product Status by Category: Of the 309 products, 123 were assigned to the active category, 31 were considered niche, and 154 were on life support.
  • Adjusted Active and Non-Reseller Portion of Product Database: However, that overstates the actual number of SAP products in the Active category because SAP is a reseller of 36 products that are “Active.” Subtracting the reseller products from the total number of Active products reduces that number to 87. This means that roughly (87/309) or 28% of SAP’s product database, is Active and not a resold product.
  • Products that are Drivers of Revenues: It made more sense to us to remove the products resold by SAP from the overall product database to develop this statistic. So, 273 of (309 – 36) “domestic” SAP products exist. However, only 52 products are substantial drivers of SAP’s revenues. This means 19% or (52/273) % of the product database contributes significantly to revenues.

Other Factors

This list does not adequately describe the complexity of SAP’s offering because, as explained in the book SAP Nation 2.0,

“Then there has been their own organic product growth, where SAP has released over 50 country specific SAP (ECC) baseline solutions in the latest SAP HANA enabled packages. SAP Business One, with over 50,000 smaller customers around the world is not exactly dead.”

“SAP may need to use its own inventory management system to manage its exploding list of SKUs. Customers complain that few of these products have been integrated to the core Business Suite, let alone with each other.”

SAP’s Growing Sprawl

SAP began as a company that offered an ERP system, but its financial success led it to sprawl into an unmanageable company. In this article, we will cover the issues with SAP’s sprawl.

SAP to Replace Sprawl

One of the arguments to sell SAP ERP was that it would eliminate the sprawl of mostly homegrown systems within companies. SAP sales reps often told customers that if they purchased SAP, it would be the only system they would ever need. This type of thinking is illuminated in the following quote from the book SAP Nation 2.0.

“SAP’s runaway success in the 90s came about because its R/3 product dramatically reduced enterprise sprawl. As Paul Melchiorre one of its most successful salespeople had noted in SAP Nation: “It was a truly transformation time for the technology industry. We replaced thousands of departmental and mainframe systems. We put MSA, M&D, and others out of business. We didn’t really have much competition. In deals it would be SAP v. SAP v. SAP — that is, SAP/Accenture, v. SAP/KPMG v. SAP/PwC.””

This quote came from a salesperson (so it should be viewed skeptically), but looking at SAP’s product list, what does one see but sprawl? Seen this way, it is apparent that SAP had no interest in reducing sprawl but wanted to replace their customer’s “legacy” sprawl with SAP product sprawl.

But did SAP reduce sprawl?

“According to Panaya, a tool vendor,”More than 50% of SAP shops have 40+ satellite applications. Of these less than 10 are SAP applications.””

It certainly does not appear so.

SAP’s Current Sprawl

The following quotation from SAP Nation 2.0 further explains this sprawl.

“Broadly, Rogow is pointing out that we do not have many independent thinkers in IT, especially considering how complex IT has become. The challenge is particularly acute in the SAP Universe with its fragmentation and sprawl. Many consulting and customer staff have spent their entire careers on SAP projects — in particular on older SAP products. They to the same SAP events year after year and repeat what SAP shows them.”

“At SAPPHIRE NOW, in May 2015, SAP Digital announced a new set of products including a CRM solution at $29 per user per month. SAP Claims to now have 17 million Jam users and 2,000 HANA start ups. The executives responsible for such SAP initiatives proudly brag about them, even though they contribute merely 1 to 2 percent of SAP revenues and they keep adding to the sprawl.”

Reducing Sprawl or Increasing SAP Sprawl?

What is curious about this is how much opposition to SAP’s massive product portfolio is versus the original proposal by SAP. Here is a quote from a salesperson from SAP from the book SAP Nation 2.0.

“SAP’s runaway success in the 90s came about because its R/3 product dramatically reduced enterprise sprawl. As Paul Melchiorre one of its most successful salespeople had noted in SAP Nation: “It was a truly transformation time for the technology industry. We replaced thousands of departmental and mainframe systems. We put MSA, M&D, and others out of business. We didn’t really have much competition. In deals it would be SAP v. SAP v. SAP — that is, SAP/Accenture, v. SAP/KPMG v. SAP/PwC.””

This quote came from a salesperson (so it should be viewed skeptically), but looking at SAP’s product list, what does one see but sprawl? Seen this way, it is apparent that SAP had no interest in reducing sprawl but wanted to replace their customer’s “legacy” sprawl with SAP product sprawl.

Conclusion

The number we have calculated here is just the significant products. If one counts the variants, then the quantity easily exceeds a thousand.

SAP has the same issue that plagues supermarkets. They have too many SKUs. This occurs when an organization is more sales and marketing-focused than operations-focused. Having so many SKUs in so many areas of enterprise software means that SAP lacks focus. But this is a natural occurrence when considerable software companies age. Oracle also has too many SKUs.

  • SAP’s second issue is that its most significant revenue producer is its ERP system, which is no longer in a growth phase.
  • It has used large profits from its ERP system to develop and purchase non-SAP software. However, that software does not provide the same returns as the ERP system. SAP increasingly relies on its support revenue and legal tricks, such as indirect access, to meet earning goals.
  • SAP is vulnerable, particularly in its non-ERP applications. This analysis helps us to gain insight into what SAP’s future behavior will likely be.

How SAP Contradicted Its Main Argument for Selling its ERP System with Sprawl

When SAP was selling its ERP system, it would often say that all of its systems were legacy, as we cover in the article How SAP Used and Abused the Term Legacy. They said that companies could replace all of their “legacy” sprawl with a single system — their ERP system, the last system any company would ever need. SAP told companies that everything would be integrated; the entirety of the ERP system would sit on a single database, and the ERP system would meet all of the company’s needs. There would never be a need to connect another system to the ERP system; therefore, integration as a function would disappear. (see the book at the end of this article that explains how each of the arguments used to justify ERP systems ended up being unsubstantiated sales pitches.)

The only people who say that SAP reduced sprawl are those working in sales or SAP project management. Right after SAP sold its ERP system based on reducing sprawl, it was found that SAP’s claims regarding sprawl reduction were false. SAP began aggressively increasing sprawl as it desired to sell more products to companies. This undermined the initial ERP sale’s entire argument that the ERP system was the only system that any customer would ever need.

SAP Product Fatigue

This issue intersects with the number of SAP products. By introducing so many products (remember, many of SAP’s new products don’t survive — and eventually fall off of the price list), it means that many consulting firms have no experience implementing many of the products they are being asked questions about. This issue arises on many SAP projects where applications that sound great but have minimal implementation history are sold.

This issue is demonstrated clearly in the Home24 failure we cover in The Hidden S/4HANA Home24 and KPS Failure. The sales BOM purchased by Home24 was highly risky. Many of the BOM items did not have an implementation history, and S/4HANA, the centerpiece product in the BOM, has had a very high failure rate in implementation. 

Implementing Lightly Implemented Applications

This means that on many projects, the consultants have never implemented various products. SAP gives the impression that these immature applications are far more widely implemented than they are. When SAP puts up a slide showing the customers that use the application, the customers have, in many cases, only recently acquired the applications.

This is why so many requests go out for SAP skills that do not exist in the market. SAP and the SAP consulting firm have given the customer the impression that the application is far more widely implemented than it is.