Have We Reached the End of the Line for SAP Solution Manager?

Executive Summary

  • What is the downward slope for SAP Solution Manager or SAP Solman?
  • The changing story of SAP Solution Manager or SAP Solman.

This article was updated as of October 2019. Solution Manager has now moved into decommissioned status. 


SAP introduces products with great fanfare but does not do a very good job of communicating when a product has dropped from being viable or when they stop actively putting effort behind a product or a program. So far my predictions of the downward slope of SAP products has been quite good. My track record is as follows:


This article states that the xApp program should be terminated, and does not predict it, so I can’t take credit for this, however, how often do you now hear the term “xApp?” The xApp program ended up generating very little sales for the best of breed vendors and was primarily a Trojan Horse that SAP used to obtain access to the intellectual property of best of breed vendors so they could backward engineer their products.


SAP PLM bombed very heavily in the marketplace. There is a good reason for this.

SAP did not have a solution. PLM amounted to functionality that was already distributed across different SAP modules and conceptually described as integrated by “creative marketing” individuals working at SAP.


One of the extreme scams ever introduced as a “product” by SAP, this horrible “application” was rolled out to hundreds of SAP customers at the height of the panic regarding master data management and master data “governance.” It was a time when consultants were paid to utter the term “taxonomy repeatedly.” MDM projects with SAP software, along with MDM projects from vendors like IBM all went down in flames, and at great expense. So much wasted effort and consulting jawboning without and corresponding output had not been seen — until SAP BW. I cover SAP’s offering here.

MDM is something that it would prefer that its customers not remember it pitched them. MDM is not used as a product in companies currently. None of these large vendors grasped that MDM is much more about basic blocking and tackling than esoteric concepts or about the bizarre infatuation these vendors had with the removal of duplicate records. There is a good book to be written on the topic of the MDM phenomena of the late 2000’s.


After failing at all of its major accounts or being on some combination of life support, not many clients are talking about or clamoring for SPP. My articles on SPP’s functionality shortcomings from my direct experience and stories about failures at SAP’s flagship accounts continue to be popular.

SAP Solution Manager or SAP Solman

This is the appropriate time to declare the death of Solution Manager!

For years Solution Manager was a hot-button issue on implementations. Frequently I was told that SAP Solution Manager is the direction and the future. SAP’s concept was very ambitious. Companies would add project documentation to Solution Manager and SAP would have access to all it, and would use it to provide feedback back the clients. It was a direct line-in to SAP, except that SAP never seemed to be on the other end. Secondly, SAP Solution Manager or SAP Solman is a poor content management application. A far better solution us either Dropbox or Box.net. I can manage my content far better than the world’s biggest corporations because I simply choose better and less expensive share file applications.

The Changing Story of SAP Solution Manager or SAP Solman

Solution Manager is still used for some administrative activities like moving transports, but it has lost any impetus within companies to use it as the repository and CMS for that vast majority of projects. As Solution Manager continues to fail to be used by companies in the areas for which it is proposed, SAP keeps moving the area that Solution Manager is supposed to do. At this point, it is set to recede into oblivion, and possibly to be replaced with a new product. However, I can say that there is no reason for the CMS to be provided by your ERP vendor, the two software skill sets have zero crosses over.

Now CMS is only one thing that Solution Manager does; Solution Manager is grabbed back of functionality. In an earlier version of this article, one of the commenters criticized the fact that I did not bring up other features such as (and I quote from a commenter)

  1. Custom Code Analysis
  2. Delta functionality capture for support packages
  3. Better performance data capture and visualization
  4. Improved access to web services consumption and exposure to allow integration with 3rd party applications like Heat or Remedy
  5. Better/greater metrics for system administration and alerting functions

The Problems with SAP Solution Manager or SAP Solman Most Broadly

The problem is that when checking with Basis folks, is that Solution Manager does not score well against other applications in any area. Many Basis administrators consider Solution Manager weak at all the multiple things that it does do, and it is not a competitive offering in all these areas where it is continually promoted by proponents of Solution Manager. This really comes down to two categories of people — either those trying to get out SAP’s marketing message or consultants who are staffed as Solution Manager resources on projects. This is covered in the book SAP Nation 2.0.

Solution Manager’s Adoption?

“Today, the real lasting remnant of NetWeaver is Solution Manager. SolMan has some adoption in big SAP shops but is really a heavy set o system management tools that work only for SAP shops willing to invest in a complex tool kit, and are a hindrance, a curse or afterthought in most others.”

Solution Manager for Improving Implementation Speed?

There is also the question of how well Solution Manager does what it says was supposed to do with respect to speeding implementations.

“Previous SAP attempts with tools like Solution Manager, however, have not significantly improved performance in its ecosystem.”

Outside of those that sell consulting services for Solution Manager or bill hours for Solution Manager, no one else is impressed with Solution Manager. (In fact, most of the commenters on this article in some way make money from Solution Manager, which explains why they will come up with any excuse to defend Solution Manager) The approach at SAP is to essentially force clients to use Solution Manager by making it mandatory to do certain functions rather than getting clients to use it because it is good. According to some Basis administrators, they simply use Solution Manager just to do the necessary functions and try to use it as little as possible. If it weren’t for SAP making Solution Manager a mandatory application, it would be dead already. SAP can keep Solution Manager alive this way in perpetuity but is it the right thing to do.

Solution Manager Jammed Down Customers Throats

In many cases, Solution Manager was made mandatory on projects in order to increase its adoption. At one point, OSS notes had to be filed through Solution Manager. This is explained in the following quotation.

At first, SAP could not force their customers to use SolMan because the range of features was faulty and incomplete. However, Gerd Oswald and his team worked tirelessly until one day, it was absolutely certain that SolMan would now be obligatory.

The outrage in the SAP community was enormous as well as understandable, because this obligation of using SolMan was tied to high costs. Of course, SolMan was still free of charge, but training courses, the development of a new IT infrastructure and the adaptation of basic processes cost customers a lot of money.

The Solution Mananager finally arrived in the SAP community. The initial outrage has quieted down. Now, a lot of existing SAP customers have recognized the advantages of SolMan, and even in the E-3 community there was a lot of praise for the Solution Manager. – E3Zine

This last part of the quote is the opposite of our experience. We have found Solution Manager to be increasingly irrelevant on SAP projects.

Stop Allowing SAP to Dictate to Customers

All applications must be able to stand alone, once a software vendor begins dictating other applications that must go along with the main applications that the implementing company is buying its time to start reducing the usage of that vendor. SAP tells customers what language to perform coding (choosing the inefficient ABAP), what database they should be using in HANA (as we cover in How to Deflect That You Were Wrong About HANA), among many other recommendations. And at every turn, SAP is supported in their self-centered recommendations by a corrupt coterie of SAP consultants and advisors who could not care less what is true and will repeat any falsehood uttered by SAP.


So, will I be right again? Only time will tell. This post will stay regardless of the outcome. If Solution Manager rises again, anyone is free to comment on this post and lampoon me.

However, I have to say, at this point, I am feeling pretty confident about this call.

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



SolMan Is Not Enough

Enterprise Software Risk Book

Software RiskRethinking 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