Solution Manager 7.1 – Fresh installation or upgrade? – Some experiences from the field…

This blog is complementary to the one recently published (see below) by our Canadian colleague François Michel, depicting the typical paths to adopt SAP Solution Manager 7.1: installation or upgrade. The paper described the direct and hidden costs of the two approaches, and the present blog aims to provide remarkable customer cases.

Since the general availability of this product version in August 2012, my team has directly supported more than 50 customers of all sizes on their journey to release 7.1.

I would like to describe here the 3 main different “categories” of customer we have identified and to illustrate them by some real-life cases.

Any resemblance to actual events, or organizations, is not a coincidence. It is deliberate !

The “upgrading is a piece-of-cake” category:

For the great majority of customers, the usage of SAP Solution Manager encompasses scenarios like Maintenance Management (MOPZ…), basic System Monitoring (Early Watch Alert reporting) and Solution Documentation (creation of business process hierarchies and storage of documentation in SOLAR projects) or Solution Implementation (usage of Roadmaps for example).

Those scenarios do not suffer from any impact during an upgrade if the upgrade roadmap is well respected. Furthermore, the upgrade scenario ensures that valuable historical data (documentation, EWA sessions etc.) remains available.

Reference project:

Medium company turning into a multinational player in the Fragance and Flavor industry, with more than 3000 employees in 15 countries and € 638 Million turnover.

The upgrade project was achieved in a very short time (6 weeks), for 2 Solution Manager Instances. No impact was detected on the project documentation, test plans and all “historical data”. Only minor issue occurred on a Roadmap that became unmodifiable, because it relied on obsolete SAP content. A new Roadmap, based on an updated content, was created. Together with the technical upgrade, within those 6 weeks, a simple Incident Management process was put in place.

The “upgrading is a functional challenge” category:

Apart from the basic scenarios we mentioned above, two scenarios are widely adopted by the SAP Solution Manager customer base: Application Incident Management and Change Request Management.

For those customers, upgrading their system is usually the only option that makes sense, as they want to keep the history of all tickets created over the years of usage of Solution Manager 7.0/7.01. But unfortunately, the “old” tickets are retrieved and displayed in ABAP screen (or WorkCenters) whereas all the “new” tickets will be created and displayed in the CRM Web UI.

The new UI also brings a lot of new features, so upgrading a Service Desk or ChaRM solution based on Solution Manager 7.0/7.01 means to perform adaptations to existing customizing, to implement new customizing and on top of that to train the users to new interface and to the updated processes.

This suddenly turns what is usually seen as a pure technical (IT) project into a functional one.

Reference project:

Multinational company specialized in authentication solutions and services with approximately 7000 employees in 50 countries with a €12 Billion turnover.

The project overall duration was 6 months. The upgrade was performed on a system where Maintenance Management, Solution Implementation, Test Management, Incident Management, Change Request Management (no integration with transport tools) where used productively. And during the project, the Change Control was introduced (integration with transport tools) as well as Applications Operations (technical monitoring) and Business Process Operations (business process analytics and monitoring) but also Custom Code Management.

The IT Service Management (incidents…) and Change Management processes were fully redesigned, to be optimized and more integrated. Then, a full data migration was performed. All the “old” tickets have been recreated in the new CRM UI, with all the transaction history, logs and attachments. Even more: the open and released transport requests were reassigned to ChaRM cycles and ChaRM tickets.

At the opening of the system to the users, it would look like they had always used this tool. No loss of information, no complex transition period, but well integrated features to use and discover.

The “give me a new box” category:

Finally, we find a lot of customers that haven’t really leveraged the capabilities of Solution Manager but strongly consider reestablishing it in their organization. Those customers have instances that are not really well connected to the managed systems in their landscape. They use only compulsory features like MOPZ. Those instances are probably not updated regularly. The basic configuration is not complete. The master data (landscape definition, processes definition in particular) is missing or obsolete.

For those customers, an upgrade brings no significant value. The best way to establish a new, reliable foundation for a Solution Manager implementation: perform fresh installation of a clean Solution Manager landscape (at least 2 systems) with the latest possible release. It will be more efficient than performing a data cleansing on the platform.

Typically you will encounter this type of situation in organization that have decided to “reboot” their Solution Manager and made their choice to use it in replacement of one or multiple legacy tool. In most cases, to replace an outdated ticketing tool for Incidents, Service Requests or Change Requests. Or to setup a more robust monitoring (technical or business process oriented).

Reference project:

Multinational company specialized in Oil and Gas industry, with close to 100000 employees worldwide and a €180 Billion turnover.

The project aimed to replace a corporate IT Service Management solution (for technical and functional support purposes and used by internals and implementation partners) used for nearly 10 years.

The customer decided to adopt Solution Manager IT Service Management scenario (incident, problem and request for change management). Due to strict Due to strict planning constraint, the new Solution was designed, implemented, tested and delivered in 5 months only. And a full data migration was performed to extract 100,000 tickets from the legacy ticketing tools and recreate them in Solution Manager.

The implementation of ticketing features in Solution manager is actually the first step of a more comprehensive adoption plan of Application Lifecycle Management: Solution Documentation, Test Management, Change Control Management are the next steps.

In a nutshell…

• The “upgrade” scenario is always the first one to consider…
• But the complexity of the upgrade highly depends on the scenarios of Solution Manager you use already !
• If you perform a fresh installation, establish a rock-solid landscape with preferably 3 systems.
• For the Service Desk or ChaRM happy users, consider using data migration strategies in order to keep your historical data safe in your new Solution Manager 7.1

And remember that SAP Solution Manager 7.01 is running out of maintenance on 31^st of December 2013 !

The time to move to release 7.1 is now…