SAP Solution Manager Service Desk Integration

Nowadays when you install SAP ECC 6.0 you get SAP Solution Manager (SOLMAN) as part of the deal – ostensibly for free (although it is really included in the purchase price).  SOLMAN provides a wealth of functionality to help manage the technical environment as well as project processes like testing.

Service Desk functionality is delivered to you for use as a ticketing system.  One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already.  In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP.  Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes which obviously reduces the risk of transcription errors.  And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management.

Here are some SAP Service Desk scenarios I’ve come across.

New SAP Installation

If you are a new SAP installation and have no ticketing in place Service Desk is a great place to start.  As mentioned the functionality available allows end users to create tickets directly from SAP and have workflow set up to manage ownership and eventual resolution.  Alternatively, a URL can be made available to allow trouble tickets to be logged via the SAP Service Desk web front end.

In this case end users and technical support personnel learn a new tool as part of their go-live experience.

Migrating Non-SAP System Support to SAP Service Desk

Rather than SAP being your sole IT application it is much more likely that you have an existing portfolio of systems and an associated ticketing tool and procedures for ticket management, escalation and resolution.  A conservative approach when bringing up Service Desk is to use it initially only for SAP related tickets and deploy a limited set of functionality.  This allows you to go through the growing pains and adjustments as you learn how to best make Service Desk work for you.

In the longer term migrating ticketing for non-SAP systems to Service Desk brings it all into one system.  Using the Service Desk capability to create custom components and to build an organization structure that fully supports your users and systems facilitates consolidated reporting and the ability to monitor Service Level Agreements (SLA).

This approach works best if you have a fairly simple environment where the level of disruption is limited when decommissioning an existing ticketing.  The impact on people, process and technology is carefully managed and the working environment has some tolerance for the time if and when things aren’t quite as expected at first.

SAP Service Desk Integration with an Existing Ticketing System

In situations where there is a well established ticketing system it is unlikely that that system will be easily displaced by SAP Service Desk and it may not make sense to do so.  In this situation you can choose to not use Service Desk and forgo the system capabilities and instead use the existing ticketing tool to manage SAP issues.  This gives up a lot of delivered SAP Service Desk capability.

Alternatively you can integrate the existing ticketing system and Service Desk and reap the benefits of both worlds.  In this case you need to decide which system is the primary ticketing system and which is the secondary.  DataXstream has worked with CA (formerly known as Computer Associates) to integrate the CA Service Desk offering with SAP Service Desk and now CA delivers a packaged solution for this integration.

SAP Service Desk is the Ticket Initiator

In the scenario where the SAP Service Desk (SAP SD) is primary tickets are initiated in SAP SD and categorized either as SAP related or as non-SAP related.

SAP related tickets are managed to resolution in SAP SD, including any communication with the SAP mother ship, and the secondary ticketing system, e.g. CASD, receives only informational updates on ticket progress, if required.  The complete ticket lifecycle is managed and closed in SAP SD.

Non-SAP related tickets are transferred to the secondary ticketing system, e.g. CASD, where they are worked to their resolution.  In this case ticket status changes and informational updates all occur in CASD and these updates are relayed to SAP SD.

In either case SAP SD and CASD can have a full picture of the ticket status throughout its lifecycle, the main difference being which system “owns” the ticket and has responsibility for working it and closing it out.

Overall the established ticketing system continues its original function and ticket resolution process, the key change being where a ticket is initially created.

SAP Service Desk is NOT the Ticket Initiator

In the scenario where SAP SD is the secondary ticketing system SAP-related incidents originate in the primary ticketing system, e.g. CASD, and are relayed to SAP SD.  Now the SAP related incidents are worked in SAP SD where ticket information can be supplemented with all the SAP unique information that would be useful for analysis and investigation.  Similar to the earlier scenario any significant status or informational updates in SAP SD are relayed to CASD and the ticket is ultimately closed out in SAP SD.

Any non-SAP related tickets are not sent from CASD, for example, to SAP SD.

A Natural Progression: from Island to Integration

SAP Service Desk can be deployed in a variety of ways in an organization: it can be a standalone ticketing and support system; it can be fully integrated with existing support applications.  The role played and the pace of adoption is very flexible and is driven by an organization’s ability to manage the change and adopt new tools and procedures.

The general progression I have seen is to bring up SAP Service Desk as a standalone tool and then after a settling in period one of two things happens:

  • Existing ticketing tools and functionality are migrated into Service Desk
  • SAP Service Desk is integrated with another ticket management tool

In either case the outcome usually allows SAP related tickets to be created directly from SAP in order to capture as much detail as possible at the time of the incident.

Add Comment Register



Speak Your Mind

*