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.

Image 1.jpg

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.

Image 4.jpg

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).

Image 5.jpg

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 31st of December 2013 !

The time to move to release 7.1 is now…

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Lluis Salvador Suarez

    Great contribution Sebastien DUPREZ, i’m really interested on the adjustment that you did to be able to import data from old Service Desk to new Incident Management (ITSM) [ SLFN to SMIN ]. As i know there is not any standard migration tool from SAP to allow that.

    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.

    I miss information about the upgrade process for the System Landscape Infrastructure, old SMSY to new LMDB; for that part i get a lot of problems i will try to update that post with my own experience on that way.

    Thanks for your information Sebastien.

    Best regards,

    Luis

    (0) 
    1. Sebastien DUPREZ Post author

      Hello Luis,

      Thank you for your positive feedback. Regarding the data migration aspects, we have created a specific toolkit to perform it. Feel free to contact me via email if you are interested.

      Regarding transition from SMSY to LMDB, I’ll reply to your blog post.

      Regards,

      Sebastien

      (0) 
  2. FACS Basis Administrator

    Sebastien

    Great to hear some real world experinces.

    You mention that in the fresh installation scenario that you were able to migrate 100,000  Service Desk tickets into the new 7.1 system.

    Did you use a SAP standard tool or build your own?

    If it was SAP standard can you provide some more information.

    Do you know if there is a SAP standard tool to migrate Service Desk tickets from an existing SOLMAN 7.0x  system to new 7.1.

    Thanks

    Matt

    (0) 
    1. Sebastien DUPREZ Post author

      Hello Matt,

      Thanks for your kind feedback.

      There is no SAP Standard tool provided to migrate Service Desk tickets. Only Consulting Services by SAP.

      My company has developed a versatile Data Migration Toolkit to handle different migration scenarios. Read more here…

      http://scn.sap.com/community/it-management/alm/solution-manager/blog/2013/12/10/managing-itsmcharm-data-migration-on-solution-manager

      Feel also free to contact me directly via email.

      Regards.

      Sebastien

      (0) 
    1. Sebastien DUPREZ Post author

      Hello,

      More and more customers are using virtual machines. Not only for SAP Solution Manager but also for business systems.

      Virtualization offers a lot of flexibility.

      Regards, Sebastien

      (0) 

Leave a Reply