- 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.
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)
- Custom Code Analysis
- Delta functionality capture for support packages
- Better performance data capture and visualization
- Improved access to web services consumption and exposure to allow integration with 3rd party applications like Heat or Remedy
- 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.
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.
Comments on the Article
The following are comments on this article.
From your comment on 12. October 2012 I get the impression that you actually enjoyed working with Solution Manager once you figured out how Solution Manager was intended to be used. Later however you continue to slam it for other areas.
I work with Solution Manager quite a bit at a number of clients. From my experience the main issue is to get an understanding and alignment of the overall concept and then start implementing the tool set bottom up with a focus on the areas where your company struggles most. Without a proper customized roadmap most Solution Manager implementations will fail.
Also, think of the Business Process Structure as the backbone for the Solution Manager. This structure enables you to reuse all of the information you add in the beginning of your project as you go along in the life cycle. Add to it the config objects, documents, test cases in the beginning of the project and all of this is readily available to you once you get this change request 2 years down the line. Combine it with the Business Process Change Analyzer and the system tells you which processes you have to test for this upcoming Support Package.
By attaching Change Requests to Business Processes, keeping documentation up to date becomes part of your change process and is not an all so often forgotten afterthought. Attach Incident Management and Business Process Monitoring to the business process structure and you see which processes are stable and which aren’t.
The process stopped working on Monday morning and everyone says nothing changed on the system? Use the Change Analyzer and find out about ALL changes within a certain time frame. Check the related Change Request and see who tested and what was the documented test result on this process step.
You don’t have your business processes documented? Use Solution Manager Documentation Assistant (SoDocA) to re-engineer your business processes based on actual executed transactions on your connected systems.
Not sure whether your documentation is complete? SoDocA can tell you which transactions are not or only partially documented.
I hope that gives an impression that Solution Manager is so much more than a simple CMS and hence it is also more complex to get it right.
Then there are a number of tools for which you don’t really need the Business Process Structure. One of the biggest value adds are the Business Process Analytics which help you to identify and drill down on document backlogs (e.g. goods delivered in the value of $500k but no invoice has been sent out, or you paid $400k too early and lost interest). This tool can be setup within 1-2 days and comes with over 800 pre-delivered key figures. The bigger part is learning the tool which takes you around 5-10 days.
Another example is the Custom Development Management Cockpit (CDMC). This tool provides you analysis capabilities to clean out code. The tool identifies clones, unused or broken objects (syntax errors) and gives you with this a quick win on things you can get rid off so you don’t have to bother adjusting them anymore for the next SP or upgrade. It also provides a cockpit to manage the actual work of removing the content (some basic project management capabilities and the assigned resources can work off a task list, jump into target systems directly into the code and maintain progress status).
Again, the tool is setup within a day (SAP Notes, RFC connections and authorizations need to be setup) but it takes two or three days to learn and understand the tool.
That brings me to my last point: In my experience one of the biggest challenges is that companies do spend the money on external implementation partners but not on training. SAP offers their customers free remote Expert Guided Implementation sessions which teach you how to implement certain building blocks. At the end of the session you will have a pilot running in your system. But as the admin you still need to invest time and effort to really understand and troubleshoot all aspects of the various tools and you need training for the users.
Getting an implementation partner in who sets up the tool and leaves without you and your users fully understanding the tool is not viable.
Of course there are 3rd party products out there which do a lot of these topics better or simpler, because they focus on specific aspects. But Solution Manager stands out for the integration of all the aspects it offers and the resulting re-usability of content. In terms of TCO SolMan probably looses against 3rd party products if compared against only one or two functionality areas (e.g. ChaRM / Incident management) even though SolMan does not need a separate license. You wont implement SolMan just to do Incident Management just as you won’t buy SAP if all you need and want is a payroll solution. But if you use Solution Manager to replace three or more 3rd party products you are most probably on the winning side if you do it right. – Chris Hohlstein
Our Response to Chris Hohlstein
In discussions with Basis resources, it increasingly appears that SAP is essentially forcing clients to use Solution Manager in order to do things. The only area where Solution Manager seems to be well rated is in a central location that stores transactions for the configuration. But SAP is not providing a compelling product, it is instead is using Solution Manager in a cynical move at account control. Really, who is any vendor to dictate what all the components that should be used by a company should be? SAP’s poor client treatment is off the charts — or should I say comparable to Oracle. As a configurator, I could mostly care less about Solution Manager, but the infrastructure people I know contradict the comments on this blog.
Solution Manager is not considered a competitive product with other offerings.
Obviously, SAP can only sell Solution Manager into SAP controlled accounts. Solution Manager should not be simply accepted by SAP clients, but actually chosen through a clear software selection process. My upcoming book will use Solution Manager as an example as to how ERP companies get their foot in the door and then begin dictating the IT spend of companies with various fear and false promises for improvement. How many years have I been hearing that the next release will solve Solution Manager’s problems?
These are quite interesting observations and comments on those. I think this discussion has been on since last year and I only got to it now. I agree with some users / implementers here that SolMan may not be a standalone solution for ALM anymore.
I am currently working advising on an integration with an external S/Desk with cloud interface, with SolMan for Service Request – Incident Management, Change Management, Problem Management and release planning. SolMan still is the strongest tool for managing SAP Transports and Changes through ChaRM.
We are recommending test management through HPALM. So I figure that SolMan is a necessary evil but when combined with other third party applications can render powerful support for any organization’s ITSM and SAP frameworks.
Please let me know your thoughts over it. – Akshit Balaj
Our Response to Akshit Balaj
I wish I had a comment on this question, but I am not familiar with HPALM.
However, you are right, because SAP has added so many things to SolMan, such as license keys — they have made SolMan necessary, but it is only through forcing people to do something which is quite inefficient — something of a specialty for SAP, they can drive the necessity of using SolMan.
Hello Shaun, we have read with interest all yours and other’s comments on this blog. We are currently investigating the pros and cons of SAP SolMan vs HP Quality Center for test management (SAP and Non-SAP). We would appreciate any comments/advice/experience you have on either product so that we can compare them fairly. We have more experience of HP QC than we do of SolMan for test management.
Would really appreciate your thoughts, thank you!
Tina – Tina Shaughnessy
Our Response to Tina Shaughnessy
Sorry it took me so long to get to this — I missed it for some reason.
I am not a fan of HP Quality Center either. HP is pretty much a non-entity in software — although they did have a great database years back called Image — which unfortunately got knocked out of the marketplace. I used Quality Center and another HP product on an account and thought they were both quite amateurish. I thinks its probably time to stop showing pictures of that garage in Santa Clara in advertisements because those days are long gone. Seriously, since Carly Fiorini gutted HP I barely hear about HP innovating.
However, I have not done an analysis of all the applications — however, I would look to see if there are some SaaS solutions. This would be a good area for a SaaS vendor to address.
I am a basis administrator and I am forced to use SOLMAN. The last two weeks I am reading notes, manuals and I am setting up the tool for monitoring, licensing and downloading patches…. I believe that for basis with extensive experience there are better ways to make things according to administration, upgrading etc… – Photos Antoniades
Our Response to Photos Antoniades
Thanks for your realistic comment. So many of the comments that have been left have nothing to do with the actual efficiency of the tool, but seem to have been left by people that work in SolMan that are intent on defending it for monetary reasons.
Interestingly, the story on SolMan keeps changing.
The argument seems to be
“Sure it is not good for what it was originally designed for, but it is good for this other thing.”
But is it actually good at that?
Your comments indicate that it really isn’t. However, the genius of SAP is that regardless of their previous historical record in any software area — they continually future sell that it will be good in the future. See some of the future selling in some of the comments —
“Now in 7.1 it is really great!”
SolMan simply is not a very relevant component of any project I have been on. It can do some things in a pedestrian manner, but the problem is that there are competing products that it replaces. So it is not a question of SolMan versus nothing, but SolMan versus another better product.
Could you please update how you configured the APO system through Sol man. IT would be really helpful for others Shaun.
Thanks. – Aks Sarhma
Our Response to Aks Sarhma
Yes, well Solution Manager has the ability to point out to any SAP system.
The way that we used it at one client was to add all of the configuration objects that we intended to configure into SolMan. One first goes into the configuration transaction by double-clicking the configuration object (which takes you to that module, without even having to login to that system — that is SolMan provides single sign on capability.)
After we performed out configuration, we saved it. Next, we wrote the configuration documentation, and then uploaded it to the same place in SolMan. Then when we would review our configuration, we could tell exactly what had been configured. We could, in fact, see for the entire project exactly what has been configured. This capability, along with the ability to set up workflows (for unit testing and prototyping — enabling consistent activities to be performed) are two of the strongest things that SolMan does.
I was recently working with an APO resource who knew quite a bit about SolMan and introduced me to a number of interesting things. I was quite surprised by how much SolMan could do. I would have to say that the gap between SolMan’s capabilities and what it is actually used for on projects is quite large. And here is part of the problem. SolMan is difficult to use, and configuration consultants don’t really have time to add on the overhead of mastering SolMan to configuring their own areas.
Also, SAP product management’s approach to SolMan has been entirely wrong.
By attempting to defend SolMan as a content management system, they degraded its credibility for the things that it can do. Because as I said it can do some good things. It also seems that there is a shortage in the marketplace of good Solution Manager consultants that really know how to get the best out of the system.
Being more than just an observer on the changing world of SAP Solution Manager over the years I think people are missing the point right now which is helping to create confusion on what the actual offering is.
Historically Solution Manager was pitched by SAP and partners alike as a technology offering, and a poor one at that since there was a thinly scattered understanding of the true capabilities of the product coupled with a maturity curve on the product itself.
Solution Manager, for the first time, is now clearly positioned as a toolset which underpins the Application Lifecycle Management approach for managing SAP and non-SAP solutions throughout the complete life cycle from project delivery through to operations. Nice words, but what’s changed?
1. recognition that you cant manage full lifecycle solutions with just a tool, it requires an appropriate framework, hence ALM
2. best of breed 3rd party tools, such as HP Quality Centre for test management, must be considered as true value add and hence the ALM framework is not limited to just pushing Solution Manager technology
3. the ALM position is now more around Business focused processes (11 in total at the moment) such as test management, upgrade management, change control management. Basically allowing a phased implementation based on business priorities, just like any other implementation understand the business case first
4. Product maturity. Solution Manager has been around for a while and is now a far more mature product to support ALM processes. Is it everything you could hope for? Well, how often is any product everything you could hope for? The key point is that it is a pretty comprehensive toolset, in most cases licence free, which implemented in the right way will provide value, reduce risk and help reduce cost. Maybe the fact that it is licence free has led to the poor and inconsistent way SAP have positioned Solution Manager in the past.
In response to your observation Shaun there is some truth that the positioning of Solution Manager as a stand alone product may be dead, but it certainly is a live and kicking toolset sitting under the ALM framework. We have had good success delivering the processes that are right for a Business rather than taking a technology approach.
Let us watch this space as see how things develop. – Kiran Patel
Our Response to Kiran Patel
Kiran, one thing you noted was that Solution Manager was free. The license may have been free, however, companies put a lot of money into implementing solution manager, and did not get at all what they were promised. Secondly, the major consulting companies and many smaller consulting companies went along with SAP in misleading their clients into using something that was obviously incompetent at its original task. They applied zero judgment in recommending Solution Manager to clients that they had to have known was a dog of a product, so this again what I have seen that the major consulting companies cannot be relied upon for software selection.
It needs to be recognized that Solution Manager was and is a worst in class CMS, and consulting companies recommended it anyway, as it maximized their billable hours pulled from clients (versus a non-SAP CMS). There are plenty of great CMS applications, and the consulting companies saw fit to recommend Solution Manager? Now let us all guess why that would be.
There is more to it than that was well. There is also all the wasted effort of those who worked on Solution Manager projects. I along with many other people were forced to use Solution Manager on projects and it undermined the ability of those projects to properly manage their content and was a major pain for years, and until it finally lost all credibility as a CMS. This consumed many resources and most companies ended up with a goose egg for their efforts, having to migrate the documentation out of Solution Manager. SAP also failed to use Solution Manager as a portal to provide feedback on documentation. This was just another marketing angle to get Solution Manager accepted by clients, that SAP never put the resources behind to make happen. John Appleby points out that 7.1 is really improved, but that does not make up for the terrible inefficiency that Solution Manager placed upon projects for years. I should say that I have often heard the next version will be great, in fact, the first time I heard this was from a Microsoft person who told me that I should wait for WindowsXP as it will solve many of Window’s weaknesses.
So when analyzing something historically, it’s important to recognize that SAP’s original intent of Solution Manager failed. They may have migrated to be more of an ALM tool, but what was Solution Manager’s original design intent, and how did it fare against this intent? Whether Solution Manager’s success in its second incarnation, I think needs some time to be proved out.
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. Let us take a guess at how objective any vendor is in recommending an application because another one of their applications is already used.
This is a problem across the SAP space.
- SAP tells customers what language to perform coding (choosing the inefficient ABAP)
- SAP tells customers what database they should be using in HANA (as we cover in How to Deflect That You Were Wrong About HANA).
- SAP tells customers what cloud vendors they should be using as we cover in the article How to Understand SAP’s Upcharge as a Service Cloud., and the article Our Comparison of SAP HEC with Virtustream Versus AWS Analysis.
One wonders if the original SAP customers ever realized that by buying SAP, they were going to be told what to do by SAP in every dimension of their IT spend decades later. Solution Manager is just another example of SAP pretending they have all the answers in an area that they do not.
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.
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 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
Enterprise Software Risk Book
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