5 common misunderstandings of Solution Manager

1. Solution Manager is free.

SAP put a lot of emphasis on the fact that Solution Manager comes for free. When SAP customers were forced to apply patches and generate installation keys through Solution Manager everyone was told that You don’t need to pay any license fees for Solution Manager, hence it is for free.

I do neither like nor agree with the fact that Solution Manager is for free. I don’t even think it is a good marketing position to be seen as a free tool. Personally I like Android phones, one of the reasons for that is the amount of free apps available for almost anything. But I also treat free apps as consumables, install them, try them a bit and then uninstall most of them in my 6 monthly clean up. However I never uninstall apps that I paid for. I even go the extra mile to try to find out about all possibilities those apps give me. So is it a good thing to be seen as “free”? In my opinion free things always carry the risk to be seen as low value.

But is Solution Manager really free? What about the hardware? What about the time and effort spent to configure and set up Solution Manager? But most of all: If it is free, then who is paying for the developers at SAP constantly developing and improving Solution Manager functionality in a breathtaking pace? You are! No matter if you use Solution Manager or not, if you utilize it to a high degree or a low degree. With every of you SAP licenses you also pay for Solution Manager. So given the fact that you pay for Solution Manager and most likely have an installation sitting somewhere in your SAP landscape: Why not have a closer look at that “App” that you paying for and find out what you can do with it?

2. Solution Manager is a tool for SAP Basis

Arguably a lot of the tools and functionalities within Solution Manager aim at supporting a SAP Basis team. The whole system landscape, Diagnostics Agents, Early Watch reports, Technical System Monitoring, Uptime / Downtime Management, Maintenance Optimizer, plus applying keys and patches are all tasks that belong into a day of life of a SAP Basis consultant or employee. Traditionally those functionalities are the main drivers to set up Solution Manager and usually these functionalities stay the only functionalities implemented (properly).

You will find that often ChaRM functionality is also completely implemented by a Basis team, often missing out on the full functionality and lacking incorporation of business requirements. But when it comes to Business Process Documentation, Customizing Documentation, Test Management, Component Based Test Automisation, Business Process Monitoring, ChaRM, Service Desk, Roadmaps, Documentation Templates or Custom Code Management, then we need to take a close look at the business requirements to get the most out of the functionality. I would even go further and claim it has to be owned and driven by the business to get useful results.

3. Once you set up Solution Manager all it needs is a bit of fine tuning

This might be related to the perception that Solution Manager is a tool set for SAP Basis. In fact it is true that a lot of the Solution Manager functionalities run in the background without much maintenance once they are set up. However most of the Business Related Functionalities need attention and ownership throughout the complete life cycle to stay up to date and reflect your current solution. The Business Process Documentation should be updated whenever a change or improvement changes the process. Larger pieces of work require projects to be set up, ideally processes to be checked out and updated during the “project” and then to be checked in again. I have set up the Change Request Management for one customer and never touched it in years. Despite the implementation being absolutely stable and virtually free of maintenance, ChaRM still requires you to monitor the progress of change documents. It is actually a great feature of ChaRM to report on stalled and abandoned change documents, to get the owners to reverse the code and / or customization thus keeping your system integrity as close to the production system as possible.

While Business Process Monitoring also does not need a lot of maintenance, it requires some housekeeping. Are the thresholds still up to date and valid? Are the monitoring objects still in place or should they be retired to improve performance? Are all extractors still running?

Like with all of your SAP modules you need functional owners who are interested and dedicated to get the most out of Solution Manager functionalities and keep on maintaining Solution Manager.

4. This is not the right time to start using Solution Manager

This is the most common answer that you might get when talking to companies about utilizing their Solution Manager. Some see it as not the right time, because they are in the middle of major projects, some consider it as the wrong time, because they fear the effort of retro documenting their Solution, some consider it the wrong time because a newer version of Solution Manager or major patch is imminent.

I think there is no such thing as the wrong time. Even if a newer version of Solution Manager with major changes is about to be released, there will always be components that undergo changes (or major changes) and other components that will be less affected by a newer version.

A good way to approach Solution Manager utilization is looking at what Solution Manager offers, which functionalities will be most useful for your situation and what is the effort to implement and maintain the functionality. Run a workshop first, identify quick gains and potential risks, then decide on a roadmap that suits you, but don’t postpone.

If there is an update announced also look at the impacted areas of the update and decide if you want to wait utilizing certain functionalities to avoid doubling up your effort. A good example might be implementing ChaRM on Solution Manager 7.0 while the details (and the fact that you need to re-implement ChaRM) for Solution Manager 7.1 were already known. In that case you might have postponed any ChaRM activities, while the Solution Documentation was virtually untouched by the upgrade.

Running a major project might be a good point in time to get your Solution Documentation up to date in Solution Manager, while if you are in a quiet phase will be a good time to look at all of the monitoring functionalities, ChaRM and especially the Solution Documentation assistant.

It is important to get started, no time is a better time than now.

5. Nothing will justify the effort of retro-documenting my Solution

If you aim for a 100% complete documentation of your Solution you might actually get away with that argument.

But first of all, what is the purpose of documenting your Solution? There are multiple reasons to do that, namely: Safeguarding the knowledge of your Solution in case key employees leave, reduce the dependency on a 3^rd party who does all the configuration for you, prepare major projects especially when it comes to a migration to S/4 HANA. If you are considering to migrate to S/4 HANA you should make sure that you are well aware of how you are using the systems right now, which user exits you are utilizing, which data concepts your custom code uses and how you are using current processes. All of that might change with S/4 HANA.

You can run the Solution Documentation Assistant for a start, pick your critical processes and modify the Solution Documentation Assistant results to your needs and requirements. Follow the 80:20 rule and focus on the important things first. You might even leave processes untouched until a project touches that functionality. Put up weighted matrix of business processes, grade of customization and importance for your business. Then try to make sure to cover the 80% of the weighted most important / customized processes.

The solution documentation will help you in all project, regression tests, upgrades and eventually in not only going to a HANA database, but implementing S/4 HANA.