Service Request Management with SAP CRM 7.0

[TinaGi]

Service Request Management with SAP CRM 7.0

With this blog I would like to make you familiar with the new “service request” in SAP CRM 7.0, which you can use in a variety of use cases, especially for – but not restricted to - The specified item was not found.. For example, if an employee calls the shared service center to inquire about a payroll issue, or if a client calls the IT service desk to have a password reset: In these cases, the service representative can use the service request to easily document the inquiry and – where relevant – dispatch it and track its progress.   A typical process flow could be like this:

 

From business perspective, the service request is a customer inquiry for provisioning of a pre-defined service. With the SAP CRM service request transaction you can document

• who has reported the issue and who is responsible for processing it


• the processing status and dates


• the impact, urgency, and priority of the request


• textual descriptions, e.g. a problem and a solution description as well as links to attachments


• which objects are affected, e.g. a device or office fixtures


• which other transactions such as problems, knowledge articles, etc. relate to the request


• which Knowledge Articles in SAP CRM were used to fulfill the request

 

Item and SLA Determination

Since service requests are about delivering pre-defined services, major features in service request management are the automatic determination of the relevant services as well as of service level agreements.

The service request is a one-order object with exactly one – usually hidden – item, and the service product for this item can be determined automatically based on the service request’s categorization. You can define in the configuration whether the categorization – and along with it the item determination – can be changed anytime during service request processing, or whether the initially determined item is valid no matter whether the categorization is changed later on or not.

To make the item determination based on categorization work, you need to assign the service products to the relevant categories in the Category Modeler. Then during service request processing, the system will automatically determine the service product for the service request. This is done by checking from bottom up, so for example, if the service request is categorized down to level four, but no service products are assigned to the categories on levels four and three, then the system will determine the service product which is assigned to the level two category.

If item determination according to the service request’s categorization is not sufficient for your use cases, you can implement your own logic in a BAdI (“Product Assignment for Creation of Service Items”).

For determination of service levels, that is service and response profiles, you have a multitude of options. Traditionally service levels could be assigned to service contracts and service products, and of course this is still valid, so the service levels the system determines could be deduced from, for example, the service product. When service levels are assigned to the service request, selecting a priority enables the system to calculate dates like “to do by” automatically.

But with SAP CRM 7.0 there are many more objects which can contain service level information and from which this information can be deduced during service request processing, namely: Installed base, installed base component, installed base text component, individual object, (reference) product, sold-to party, sales organization, service organization, and via “BAdI for SLA Determination” implementation.

In the configuration, you need to define SLA determination procedures so that the system knows in which objects to look up service level information and in which sequence. For example, if in your service requests there is often a reference to installed bases, you could maintain specific service level information in the most critical installed bases. The installed base service levels should take precedence over service level information of the service product. So in the SLA determination procedure you would define that the system first checks for service level information in installed bases, and only if no service level information can be found in the reference Ibase – or if there is no Ibase referenced in the service request – the service product’s service levels are used for the service request.

 

Multi-Level Categorization

The service request offers extensive multi-level categorization options by providing up to five categorization trees with up to ten category levels each. Of course it will be rarely the case that you need to make use of fifty categories in a single service request, but it is very common to use, for example, one categorization tree for “Subject” with three or four levels of categories, and another categorization tree for “Reason” with another two to four category levels.

As mentioned above, the categorization of a service request can serve for automated item determination. Further functions related to categorization are semi-automated proposals of related transactions, auto completion of service requests, and optionally rule-based dispatching:

 

• For the proposal of related transactions, you can get a list of problems (master service requests, see below) or knowledge articles for which the same categorization applies as for the service request.


• Based on the categorization the service request can be “auto completed”, which means that based on the categorization a pre-defined template can populate the service request automatically. This reduces the processing time of standard service requests significantly.


• When setting up rules for automated dispatching of service requests, those rules can contain categorization information, so that you can, for example, automatically dispatch a service request with categorization “Payroll inquiry” to the HR support team.

 

Master Service Requests

Along with the service request, a very similar new one-order object has been introduced with SAP CRM 7.0: The “master service request”, also named “problem” (based on the IT Infrastructure Library’s terminology). A master service request, or “problem”, is usually created if an issue needs to be investigated in detail, and it can refer to multiple service requests or incidents related to the same underlying reason.

The master service request offers functions which are mainly identical to the service request’s functions, but in addition it allows you to bundle service requests and close the linked service requests automatically once the issue is solved. When automatically completing the linked service requests, the system can not only set an appropriate status (e.g. Solution Provided), but also copy textual information and attachments from the master service request to the service requests. In addition, if a solution or workaround has been found for the issue, the service representatives often want to publish the investigation's result to other colleagues. In those cases they can easily create a Knowledge Articles in SAP CRM as a follow-up of the master service request, which can then be used by other service employees to resolve similar issues more easily.

More Details

Last but not least some technical details:

• The service request is based on a new BUS type 2000223 (Service Request), and per default a transaction type “Service Request” (SRVR) is delivered.


• The master service request (“problem”) is based on a new BUS type 2000224 (Master Service Request), and per default a transaction type “Problem” (ITPR) is delivered.


• The (master) service request is a one-order object with exactly one – usually hidden – item.


• If required, the item information can be easily made available on the (master) service request’s header, so that the service product, its quantity, as well as information such as, for example, net value, is always visible for a user. To do so, you need to access the (master) service request’s header view in the Component Workbench and switch the relevant fields of the BTADMINI group to visible.


• In Customizing, you can set up the (master) service request transaction type/s you need similar to other one-order transactions. Service request specific customizing can be found under Customer Relationship Management → Transactions → Settings for Service Requests.


• Like for the service order, you can also create service confirmations as follow-up documents of (master) service requests so that you can create invoices for them and/or automatically transfer the recorded working time to SAP ERP cross-application time sheet.


• For analytics, the infocube 0SRQ_C10 is available for the service request and 0SRQ_C11 for the master service request (“problem”).


• Since SAP CRM 7.0 SP04, the (master) service request is also enabled for ERMS (E-Mail Response Management System) processing. See also SAP note 1388347.