SAP Acquisitions

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 popularity each of the SAP products.

Introduction to SAP’s Product Database

At Brightwork Research & Analysis, we place 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 the question of how many products SAP had. Therefore we decided to take SAP’s product database and 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.

Lack of Financial Bias Notice: The vast majority of content available on the Internet about SAP is marketing fiddle-faddle published by SAP, SAP partners, or media entities paid by SAP to run their marketing on the media website. Each one of these entities tries to hide its financial bias from readers. The article below is very different.

  • First, it is published by a research entity.
  • 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.

The Method of Counting SAP Software Products

Counting how many products SAP has is more complicated than it might seem at first blush. 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 right answer to count one product or to count six products?

We decided to count this as six products only 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 are viable products that made up common discussion points on SAP projects and are common 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 quite a few products. So we wanted to distinguish SAP products that are owned by SAP and those that 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 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 interesting features of these categories.

  • Total Product Status by Category: Of the 309 products, 123 were assigned to the Active category, 31 are considered Niche, and 154 are 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 both Active and not a resold product.
  • Products that are Driver of Revenues: It made more sense to us to remove the products that are resold by SAP from the overall product database to develop this statistic. So there are 273 of (309 – 36) “domestic” SAP products. However, only 52 products are substantial drivers of SAP’s revenues. This means that 19%, or (52/273) percent of the product database contributes significantly to revenues.

Other Factors

This list does not adequately describe SAP’s offering’s complexity 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 used 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 with skepticism), 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

This sprawl is further explained by the following quotation also from SAP Nation 2.0.

“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 with skepticism), 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 major products. If one counts the variants, then the quantity easily exceeds a thousand.

SAP has the same issue which 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 the natural occurrence when large software companies age. Oracle also has too many SKUs.

  • SAP’s second issue is that its most significant revenue producer is its ERP system is no longer in a growth phase.
  • It has used large profits from its ERP system to develop and purchase the non-SAP software. However, that software does not provide the same returns as the ERP system did. SAP is increasingly having to rely 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 the systems a company had 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, which was the last system any company would ever need. SAP told companies that everything would be integrated; the entirety of the ERP system sat 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, and 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 nothing more than unsubstantiated sales pitches.)

The only people who say that SAP reduced sprawl are those that either work 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, and SAP began aggressively increasingly sprawl, as it desired to sell ever more products into 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 comes up on many SAP projects where applications are sold that sound great but have minimal implementation history.

This issue is demonstrated clearly in the Home24 failure that we cover in the article 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 implementing various products have never implemented them before. 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 themselves.

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 actually is.