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.

Start Date: April 2010

Duration: 7-8 months

Description:

DataXstream is searching for a highly qualified, experienced and deliverables focused SAP Functional Consultant with expertise in inventory management (IM) and warehouse management (IM) for a project starting in April 2010.  The position requires functional expertise with additional technical understanding and skills.  This position requires you to work with the client and the implementation team to design, configure, test and deploy an SAP-based solution.  The work will also identify and produce specifications for custom development objects.

The client expects to make informed decisions based on guidance from a proactive consultant who presents options for how to execute business processes and functions along with the pros and cons of those options.

The responsibilities of the position start after project inception and continue through go-live, user training and post go-live.  If you meet or exceed these standards and would like to be a part of a highly skilled SAP consulting team please attach your resume and your completed application form below.

Required Qualifications:

• SAP functional professional with hands-on experience with SAP ECC 6.0 WM/IM implementations
• At least 5 years implementation experience on medium to large scale SAP projects in complex, time-sensitive, global environments involving multiple countries and currencies, including US and Canada
• At least three full SAP implementation lifecycles completed
• Expertise in planning, organizing, implementing, and executing the following WM/IM functionalities:
  • SAP organizational element configuration (plant/site, company code, etc.)
  • End-to-end procure-to-pay process design, test and deployment
  • Goods movements (receipts and issues) and inter-company transfers
  • Cycle counting and physical inventory processes
  • International store-to-store transfers
  • Configuration of account determination procedures
  • Labeling requirements and processing
  • Experience with both lean WMS and full WMS functionality and recommending one over the other, including put away strategy, picking strategy, cross-docking, location strategy)
  • Import and export processing
  • Integration with sales order fulfillment processing
  • Integration with handheld devices
  • Master data creation and maintenance (especially materials/articles)
  • Experience creating and maintaining pricing procedures, including in accordance with international tax laws
  • Intercompany processing between company codes with different currencies and countries of operation
  • Experience with SAP Retail solution highly desirable
  • Project lifecycle experience: requirements gathering, blueprinting, construction, realization (including integration and regression testing), go-live and post-production support
  • Documenting use cases, requirements, activity diagrams, sequence diagrams, and data flow diagrams in a technical environment
  • Writing test plans and test cases
  • Assisting in identification, assessment, and resolution of complex problems within project scope
  • Bachelors degree in computing related field or 4 additional years relative work experience in lieu of degree
  • Excellent customer relationship skills
  • US citizens/permanent residents only

Apply For This Job

Personal Information

• First Name  *
• Last Name  *
• City  *
• State  *
• Postal Code  *

Contact Information

• Phone Number  *
• Email  *

Online Information

• Website 
• Blog 
• Linkedin Profile 

Job Information

• Date Available To Work*  
• Work Status* US CitizenGreencard HolderH1-BOther
• Travel Preference* 0%25%50%75%100%
• Willing To Relocate* YesNo
• JobType* Intern (Full-Time) Intern (Part-Time) Full-time Part-Time Contract

How Did You Hear About This Position?

•  Twitter Facebook Linkedin Craigslist DataXstream Other

  Other 

Additional Information

Submit Resume

* (Required Fields)