The Information Technology Infrastructure Library (ITIL) provides guidelines to help IT organizations improve their processes to better align themselves with their companies’ goals. You can incorporate those standards into a company’s Service Management Service Desk implementation to develop a 10-step process for handling employee IT requests.

Although SAP does not yet deliver a preconfigured process to support an ITIL Service Desk, IC WebClient includes all of the functionality you need to build one. This is what I did in my latest project. You can now use Interaction Center (IC) WebClient to support the entire process for an ITIL Service Desk from the initial incident report to closing out the incident. This is a more straightforward process that the traditional method of using a collection of Business Server Pages (BSPs) or transactions to handle incidents.

I’ll show you how to adapt what SAP delivers in IC WebClient to use it for incident management. Even if you do not plan to use IC WebClient for a service scenario, you can apply this information in any IC WebClient implementation, such as a facility help desk or Employee Interaction Center.

I will offer tips based on relevant experiences from this project. I’ll show you what the standard IC WebClient system offers, where you need to make enhancements, and how to configure the tool for this process. For additional information, I listed relevant SAP Notes, SAP Best Practices, SAP Help Portal links, and CRM Expert articles in the sidebar, “Additional Information.”

Help Desk Processes in IC WebClient

SAP delivers two standard processes that you can use as a starting point — Information Help Desk and IT Help Desk. Both processes run in IC WebClient. They focus on a typical CRM scenario, which means that a customer is the focus of the interaction. To use IC WebClient for an internal scenario, such as the ITIL Service Desk in which employees are in the customer role, you have to change some of the settings in the system. Based on the two delivered processes, and in accordance with the ITIL framework, you could process incident management as shown in Figure 1.

Figure 1

Process for handling an incident (Source: SAP)

I will use this sample process to walk you through the 10 steps you must follow. In this process, an employee contacts his company’s service desk with an issue. The service agent performs several tasks that culminate in a solution for the employee. The employee implements this solution and accepts it. At this point the service agent closes out the incident.

The Process

The 10-step process shown in Figure 1 takes you through the steps you follow to handle an issue sent to the service desk. With each step, I’ll include the necessary customizing settings and mention, where possible, additional documentation or important things to consider, as well as experience from my latest project.

Step 1. Identify employee. SAP delivers three profiles for account identification:

• Business-to-business (B2B)
  
  
• Business-to-consumer (B2C)
  
  
• Employee

For the sample process, I cannot use the employee profile — although it would fit — because the view set used for the employee scenario contains views for email preview instead of the registered product view. For my process, incident management, I need the registered product views that allow me to search and select the configuration item, an equipment record that you download from mySAP ERP Central Component (ECC) or R/3. If you don’t want to use the equipment download, you can create the data directly in mySAP CRM. The system stores the equipment as an individual object (iObject) within mySAP CRM and then assigns it to an installed base (IBase).

This leaves us with the B2B or B2C profiles. Which one to use depends greatly on your requirements, so I cannot make a general recommendation. B2B focuses on the business partner relationship between a sold-to party and a contact person. In contrast, B2C works with just one business partner without relationships (Figure 2). In my last project, I used the B2C profile and filled the sold-to party via the partner determination procedure.

Figure 2

View set for account identification (B2C) Click here to view a larger version of this image

Keep in mind that in this B2C scenario, I am working with a business partner in the employee role. To run the incident management process, you need to have sales area information; otherwise, all of your transactions will have errors due to missing data. One way to ensure this would be to enhance every employee with the sales data. However, it is better to maintain a separate sold-to party (e.g., an existing organizational unit) with all of the necessary data. Then you can use an access sequence within the partner determination procedure to fill the sold-to information into the transaction based on the identified employee, such as I did in my last project.

You probably want to use other terms on your views — for example, Employee instead of Account — and enhance them with the personnel number as search criteria instead of using the account ID. Refer to the “Consultants Cookbook Interaction Center (IC) WebClient” for information about how to copy and replace views without modifying them. You can review this document by following menu path SAP Support Portal>Release & Upgrade Info>Installation & Upgrade Guides> mySAP Business Suite Applications> mySAP CRM>mySAP CRM 2005> CRM Core and Standalone Components. To go directly to the document, follow URL https://service.sap.com/~sapdownload/011000358700003057372006E/ICWC_Cbk_CRM50_290306.pdf.

You can find the customizing for IC WebClient in the IMG by following menu path SAP Implementation Guide>Customer Relationship Management>Interaction Center WebClient or by using transaction code CRM_IC_IMG. You can view the settings for the Account Identification profile by following menu path IC WebClient IMG>Master Data> Accounts>Define Account Identification Profiles.

Select the profile that is closest to your requirements, in my case B2C, copy it, and give it a name such as Z_B2C. For example, you can customize the maximum number of hits when you search a customer with the criteria ‘Last Name’ = ‘Re*’. The system stops the search after it finds your maximum number of hits and returns them with a message that the search was limited and you should refine it further. In my last project, my team limited this to 20 to get a faster response time and because nobody would scroll through a list of 100 result hits to find a particular one.

Another interesting setting is Navigation. In this area you can set up an automated navigation after the user confirms the account and product. I used this to go directly to the interaction history to review the open incidents for the caller. This saved one additional click for the user.

Step 2. Identify the configuration item. To identify configuration items, use the standard views for registered products. The search screen for registered products contains ID fields for Product ID, Optional Component ID, Optional IBase ID, the IBase description, and address information. The search result shows you the same information as the search screen plus Object Family, and the IBase Component Description. After you confirm the business partner from step 1, the system performs a search for the confirmed business partner within the partner information of the IBase component. It displays all of the equipment records related to the caller automatically, for example PC, laptop, and monitor. To ensure that the search is working correctly, make sure you store the partner information on the IBase component level.

You perform the configuration settings for IBase in the account identification profile as well (see step 1). In the IBase setting, you select which partner data the system should use to perform the automated search. Alternatively, you can select a blank entry to turn off the automated search. This entry is of special interest for the B2B scenario, because in this scenario you have two partners (Customer and Contact Person) available.

Step 3. Create the interaction record. IC WebClient always creates a transaction when the user confirms a business partner. In the business transaction profile, you can specify whether you want to work with one or two transactions for each contact. An example for just one transaction is the delivered business transaction profile HELPDESK. For two transactions, look at profile DEFAULT (Figure 3).

Figure 3

Use HELPDESK for one transaction profile and DEFAULT for two transaction profiles Click here to view a larger version of this image

I recommend you copy the DEFAULT profile and give the copy a name such as Z_DEFAULT. You should also work with two transactions. This is practical because then you have the interaction record to document the call itself and a second, dependent business transaction to record the incident. The system links all of the business objects (dependent on the configuration of the activity clipboard profile) that are involved during the call to this interaction record. A further benefit is that if the customer does not report a new incident (i.e., the customer calls for a status inquiry), you don’t create a new incident.

You can find the configuration for transactions by following menu path IC WebClient IMG: Interaction Center WebClient>Business Transactions> Define Business Transaction Profiles. Here you assign the transaction types you want to use to the IC WebClient profile. The DEFAULT profile uses transaction type 0010 (Business Activity) as the interaction record and TSRV (Teleservice) as the dependent business transaction for the service scenario. In my example, I used the service ticket views for the incident, so I used the transaction type TSVO (SAP Service IC) instead of TSRV.

Step 4. Create and update the incident. Based on the business scenario, you either look up an existing incident using the last interactions, the interaction history, or the inbox search, or you create a new incident (Figure 4). Technically, the system creates the incident when you navigate to the service ticket, which the system uses for the incident. The service ticket uses the same technical object as the service order, but displays it in a different view set.

Figure 4

View for the incident (service ticket) from IC WebClient

The system uses the transaction type to distinguish between service order and service ticket. In the standard delivery, the transaction type for the service ticket is TSRV. The distinction is made in Business Add-In (BAdI) CRM_ICWC_ SERVICE_NAV. This BAdI is also accessible by following menu path IC WebClient IMG: Interaction Center WebClient>Business Transactions>Service Ticket>Business Add-Ins (BAdIs)>BAdI: Navigation to Service Ticket and Service Order. The incident is set as Dependent Business Transaction to the formerly defined interaction record.

Step 5. Categorize the incident. You can use multilevel categorization not only to categorize the incident with four dependent levels, but also to suggest solutions and complete the incident automatically (auto complete). To use the auto suggestion of solutions, you have to link solutions to specific nodes within the category modeler.

If you select one of the categories that has a solution linked to it an alert appears indicating that solutions are available (Figure 5). The alert also serves as a navigational link to the knowledge search.

Figure 5

Auto-suggested solutions Click here to view a larger version of this image

To use the auto complete functionality, you must assign service order templates to specific nodes within the category modeler. If you select a category that has an assigned template, the Auto Complete button in Figure 4 becomes active. When you click on this button, the system copies the following values from the template order to the current incident:

• Description
  
  
• Priority
  
  
• Status
  
  
• Subject (this represents the classification)
  
  
• Texts (the system copies the same text types only, so make sure that template and incident use the same text determination procedure)
  
  
• Items

You define this in method SET_REQ_ TEMPL_ATTR of class CL_CRM_IC_ SERVHEAD_IMPL. This class is the superclass of the controller class from the view CRM_IC/SrvTHead.htm. You can redefine it if necessary. Find more details about how to do this in the “Consultants Cookbook Interaction Center (IC) WebClient.” You configure the multilevel categorization in the mySAP CRM BSP application CRMM_ERM_CAT (Figure 6).

Figure 6

Configure the multilevel categorization in the category modeler Click here to view a larger version of this image

Step 6. Prioritize the incident (impact and urgency). The ITIL framework uses the fields Impact and Urgency to prioritize incidents. SAP does not provide these fields as standard, so in my project I added them to the Business Object Layer (BOL) and put them in the user interface (UI). To do this I recommend using Easy Enhancement Workbench (transaction EEWB). With Easy Enhancement Workbench you can add new fields, including a value help to the business transaction data model. The value help generates a customizing table for the possible values. Use the IC WebClient wizards to copy the view and to add the fields (see the Consultant’s Cookbook for details).

Additionally, I implemented one more field on the UI to display the recommended priority, one additional customizing table for the mapping of impact and urgency to the recommended priority (Figure 7), and additional logic in the controller class to read the selected values for Impact and Urgency and fill the recommended priority accordingly. Every time you change either the impact or urgency, you trigger the logic. For the selected values, the logic then determines the recommended priority by looking up the corresponding value in the mapping table (Figure 7). The system then sets this value to the UI field for recommended priority.

Figure 7

Update the Urgency, Impact, and Priority

Step 7. Search for the solution or workaround. The solution database (SDB) is integrated into IC WebClient. It integrates the activity clipboard, multilevel categorization, and the ability to email solutions to the client. Find the configuration for the SDB by following menu path IC WebClient IMG: Interaction Center WebClient>Basic Functions>Define Knowledge Search Profiles.

Step 8. Dispatch the incident. If service desk agents are unable to solve incidents at the first level, they forward them to the appropriate organizational unit. You do this either manually or by clicking on the Escalate button. The Escalate button accesses the rule modeler to determine the right recipient (organizational unit or person) for the escalation. Within the rule modeler you can use the following attributes (either individually or a combination) to find the right recipient:

• Transaction type
  
  
• Priority
  
  
• Product
  
  
• Status
  
  
• Account
  
  
• Category
  
  
• IBase
  
  
• IC WebClient profile

Use the mySAP CRM BSP application CRMM_ERM_RULES (Rule Modeler) shown in Figure 8 to create the escalation rules.

Figure 8

Create the escalation rules Click here to view a larger version of this image

Step 9. Provide a solution. If the service desk agents can solve the incident directly, they can use the integrated email client to email the solution to the client. Alternatively, they can use the auto-complete functionality to maintain all necessary data in the incident. You can find the configuration for the outbound email by following menu path IC WebClient IMG: Interaction Center WebClient>Basic Functions>Communication Channels. This is very straightforward so you can use one of the delivered profiles from SAP.

Step 10. End interaction. The last step is to end the interaction. After you finish the call with the customer, add the information in the incident, update the interaction record, and then click on the End button in IC WebClient. This saves all of the changed objects. The service desk agent is now ready for the next interaction.

Marcel Redinger

Marcel Redinger is a senior CRM consultant at SAP Consulting Germany. He earned a master’s degree in business administration at universities in Germany and the US. Marcel has more than five years of implementation experience focusing on CRM Service, PCUI, and most recently IC WebClient.

You may contact the author at marcel.redinger@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.