SolMan 7.2: More than the sum of individual tools

Time and again, I meet customers who have taken more of a best-of-breed approach to IT service management tools in the past. But this will inevitably lead to failure with Solution Manager 7.2.

As long as Solution Manager is only used as a pure vehicle for Early Watch Alerts, this of course does not pose any problems.

If the Solution Manager is only given this status in IT, then by far the advantage of the tool is not used and lies idle. In addition, users should then consider how they want to master the changeover to S/4 Hana and which tools should be used instead.

If you want to expand Solution Manager in a meaningful way, at least solution documentation and Change and Request Management (ChaRM) are mandatory.

In general, I only recommend SAP users in these areas if the SAP share and its importance within IT exceeds the fifty percent threshold. After all, forcing users and developers in the Java environment to switch to Solution Manager is not a particularly great pleasure.

If in the past you worked with two different tools in the area of change management or in the area of software documentation, this only makes limited sense in Solution Manager.

Some customers I have had the pleasure of consulting with in recent weeks have been looking for solutions to link a project management tool, separate cost and activity allocation, and an external documentation tool with the Solution Manager Service Desk and Change Management.

Such integration may be possible, but it opens up additional interfaces in numerous places that Solution Manager does not have in the standard version.

The only officially available interface is the coupling of an external service desk with the Incident Management of the Solution Manager.

The overall solution for managing IT in Solution Manager is not that far away with version 7.2. Due to the considerable improvement in the scope and functions, this also poses hardly any problems in implementation.

The biggest challenge is to calibrate the entire IT to the tool. Of course, this only makes sense if SAP is the majority in the IT environment.

In the overall context, everything starts with the solution documentation and the mapping of business processes and business process steps. In the first step, this does not have to be complete, but an approximation and post-documentation should be done just from the point of view of the S/4 conversion.

A test plan and a test procedure can only be mapped if the processes are mapped in process steps in a meaningful way and in accordance with reality.

In the context of change request management, the change is of course closely linked to the documentation and the processes and steps affected by it. Thus, it should and must be ensured that changes are not implemented productively without documentation.

If you want to manage your IT in a meaningful way in the SAP environment, you will inevitably choose Release Management, which builds on Change Management. If you want meaningful controlling here, you can link Release Management with Project and Portfolio Management in Solution Manager.

This means that changes can be managed not only at the individual level. Rather, the project management part can also be used to record task packages that do not involve any software-related changes.

If IT managers decide to use time recording based on cause, effort can be recorded directly on the task packages in the project. By comparing the planned figures, typical project management key figures can then be accessed.

In sum, this results in a sensible combination of individual tools. A separation of these tools always leads to maintenance efforts, complex interfaces and massive functional losses.