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 we focus on SAP. However, it is a full-time job keeping up with SAP! At one point we asked the question of how many products SAP had.

At one point we asked the question of how many SAP software products does SAP have, and we just did not have a good answer to the question. Therefore we decided to take SAP’s product database and to code it and then count it to find out.

The Method of Counting SAP Software Products

Counting how many products SAP has is more complex 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 currently is 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 is six products, only because it is consistent with how SAP has broken out its products in its product database. When measured this way, SAP currently as 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 draw the distinction between 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 category they fall into. We applied out 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 fully 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.”

Reducing Sprawl or Increasing SAP Sprawl?

What is curious about this is how much in opposition 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 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.


SAP has the same issue which plagues supermarkets. They have too many SKUs. 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, which is its ERP system is no longer in a growth phase.
  • It has used the large profits from its ERP system to develop and to 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 on legal tricks, such as indirect access to meet is 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.

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 Content

SAP Contact Form

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.



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