Ready for Hana with SAP Solution Manager

For many IT managers, the upgrade of Solution Manager 7.1 and the impending end of maintenance on December 31, 2017 is still a major bugbear.

In particular, SAP users who already use many scenarios face major challenges with the upgrade.

All the scenarios that have already been introduced need to be readapted, re-authorized, tested, trained and implemented. Here, it is important to start the upgrade project early in order to still have sufficient leeway.

First SolMan, then Hana

Users planning a Hana conversion in 2017 should consider upgrading Solution Manager in advance.

As part of a Hana conversion, but also in preparation for the new S/4 Hana Business Suite, there are some useful modules that massively facilitate the changeover.

IT departments always suffer the same fate at the beginning of a Hana conversion: tests have to be prepared and agreed with the business departments.

For many customers who only use Solution Manager in a very rudimentary way, these tests are stored as Excel documents on a file share and are mercilessly outdated.

Some customers have gone a step further and used the solution documentation to describe the processes and associated necessary test cases, but have not updated since the last Support Package update or even upgrade and are now looking back at outdated documentation.

Inventory processes

In both cases, it makes sense to use the new Solution Manager functionalities in the solution documentation to inventory all business processes as a first step.

The fact that the number of levels can now - unlike before - be selected at will by the user means that even the most complex process houses can now be documented.

Once this foundation is in place, it can be built upon wonderfully. If the pure structure is not enough, the new graphical editor can also be used to model the process diagrams and store them in Solution Manager.

Retreaded documentation

In the next step, the existing test documents, usually Excel files, are linked to the individual processes.

Here, one document may have to be split into several. From the created or retread process documentation, a meaningful basis for process documentation then results in the next step, which should of course also be continued.

An update of the process documentation can be enforced via the change management component.

In addition to these preparatory activities, it certainly makes sense - assuming enterprise support - to use the Custom Code Management Cockpit to eliminate unused coding.

Everything that can be removed from the system, of course, also reduces the test cases that have to be performed.

Training & test

While it is certainly the case that the new interfaces and tools mean that users need to be trained and the new techniques need to be learned.

However, the advantage for the topic of test management and the path to complete documentation are indispensable. The transition of solution documentation - as already described by me in another column - is certainly not an easy one, especially if documents already exist.

However, this path must be taken at the latest at the end of maintenance, as the "old" solution documentation will only be available in read-only mode after the upgrade.

Early planning of the project is essential.