Since starting configuration of the service desk, I’ve taken a workflow consultant's eye
to look in detail to see how the routing assignment of service desk partners is
supposed to work. One of the things that never made much sense to me was
the implementation of 1st level and 2nd level support teams.
Oh, I understand the concept, but how is it meant to work in practice? This is what I
found out, hope it helps everyone setting up a support office.
Some Service Desk Concepts
First some background, in pretty broad brush strokes. Service desk messages are
sent from within ‘satellite' SAP systems managed by Solution Manager. These
messages are in fact one type of CRM order, a transaction that carries information
between the two systems. One piece of information, apart from the obvious problem
description, are the partner functions. Partner functions are pre-defined place-holders
in the service desk transaction that are filled on message creation. The following
partner functions are defined:
- Sold-to Party (the provider of the service for billing purposes).
- Reported by contact
- Support Team
- Message Processor (actually, filled after creation when it is first actioned).
The partner functions are filled with Business Partners, master data objects that have
more relevant information for the CRM order scenarios (of which the service desk
messages are just one example) than the HR originated organisational management
objects such as organisation, position and employee.
Two levels of support: front desk and escalation
Since Solution Manager 3.0, a standard Organisation Model for the Service Desk has
been provided which is one of the three pieces of CRM master data required to
configure the Service Desk (the other two being business partners and IBASE, a simple
hierarchy of the satellite systems / clients that solution manager supports).
This Organisation Model, accessed through transaction PPOMA_CRM, shows how to
split support teams to manage the workload of incoming support messages. Support
teams are never sized to handle the number of messages expected without some
form of workload management, so this capability is not to be underestimated.
The standard model in Fig 1 below shows a Service Desk organisation unit, with a 1st
level support organisation unit and 2nd level support split into organisation units
based on different SAP areas. Fine in theory, but how would messages be escalated to 2nd level support from the 1st level front desk?
Fig. 1: Standard Service Desk Organisational Model
A choice of responsibility rules
Based on CRM scenarios, one could believe that the service desk scenario requires that one organisation unit be configured
in the attributes to have the “Object Permitted in Determination” flag set, with the country code maintained (see Fig. 2).
The implication being the partner function determination for Support Team will not work without both settings.
Fig. 2: Service Sceanrio Attributes
Actually, the attributes tab is irrelevant for partner determination in the Service Desk
scenario (but maybe not for other CRM scenarios, please note).
The workflow rule for delivering the responsible service organizations and service
teams based on the org. attributes in organizational data determination for the
Service scenario is AC 14000164 (CRM_DNO_2 - Service Org.Using Partner Attribute
Cnty). This has a check for table HRV1222SC that contains organisational objects with
“Object Permitted in Determination” flag set and a container entry for country code.
Nevertheless, this workflow rule is not used in any access sequence. It may have been
used in the now deleted (as of SM7.0 SP16) access sequence 0600 Organizational data:
Support team by org. model .
Even if you configured a new access sequence that made use AC 14000164, and
extended the containers to all attributes in the service scenario, there’s nothing there
that can be used relevant to the Service Desk scenario.
- Activity Reason (from Sales and marketing)
- Country
- Sales district
- Industry sector
- Correspondence
- Language
- Last Name
- Partner number
- Partner Function
- VIP Partner
- P.O. box
- Postal Code
- Product Group (e.g. normal or spare)
- Product number
- Region
- Responsible Organization (Service)
- Text module footer
- Text module header
- Text module sender
- Text module signature
The workflow rule that does work, although it has nothing to do with the service
scenario attributes for an organisational unit, is AC 13200137 (CRM_DNO_1 -
Responsibility CRM Transaction / Sup.Mess). This IS called, from the action profile
SLFN0001_ADVANCED, in the action definition SLFN0001_ADVANCED_FIND_PARTNER).
The container elements are much more promising:
- Catalog Subject
- CategoryCode Subject
- Subject Code Group
- Sold-To Party
- Country
- Transaction Number
- Priority
- Transaction Number
- Sold-To Party
- Region
- SAP Component
- Installation Number
- SAP Client
- SAP System
- Sold-To Party
The way the workflow rule works, however, is not initially aligned to the concept of a
two-tier support structure. Let me explain.
Setting up responsibility rules for true 2-level support
When a user creates a support message in a satellite system, as can be seen in Fig.3
below, the SAP component is automatically filled in and this can be used to determine
the responsible service team. SAP component is all very well for knowing one
parameter of the problem, and is indispensible for SAP AGS I’m sure, but it
distinguishes not a problem in the system, functional or development areas, for instance.
Fig. 3: Screen dialog for support message creation in the satellite system
First line support should be the “router” for all messages, the first port of call, where the problem is deciphered
from the description and the context before escalating as necessary. If the problem needs to be escalated,
it can be categorised using the catalogs and codes defined for this purpose. Simply by saving this message
with the appropriate catolog code should then cause determination of the appropriate team responsible.
Notice that the search help for the partner function “Support Team” does not have the ability to
interrogate the Organisational Model for the appropriate responsible team, as it is the business partner
that is the required input. The new business partner for the support team to be determined is
calculated only if the entry in the partner function is cleared first before saving.
If the message needs to be categorised WITHOUT re-determining the support team (e.g. it is to
remain the responsibility of 1st line support), simply leave the existing entry in the field, and the
support team business partner will not be over-written.
So, what are the entries needed in AC 13200137 to realise this process? As an example, the following settings can be made with reference to the
standard org model to determine that:
- All messages go to first line support in the first instance, and
- When re-categorised, the "complaint code" ME05 goes to the CRM-team, and all other codes to the Basis team.
The catalogue used for transaction type SLFN is called I1, and the Code group is MLDDGM1, as in Fig.4:
Fig. 4: Catalog configuration
In the service desk messaging processing, the selection of catalogue codes looks like this in Fig. 5.
Fig. 5 Catalog code selection
The settings for a complaint to be sent to the CRM team are as in Fig 6.
Fig 6: Container entries for CRM responsibility
The settings for other codes to be sent to the Basis team are as in Fig 7.
Fig 7: Container entries for Basis responsibility
The settings for 1st level support are as in Figure 8. Notice that the priority is set at 02, which is higher than the other two responsibilities, and so will be
considered first. Also the [subject] code group has "EMPTY" as the entry. This will ensure when the rule is first run and there is no catalogue entry
entered by the user in the satellite system, this responsibility is chosen first.
Fig. 8: Container entries for 1st level support responsibility
Simulating the rule AC 32000134 shows the results on the left with no entries as would be created in the satellite system, and on the right
with entries after changes made by 1st level support (in this case tested without a catalog code just to highlight the difference).
.
- SAP Managed Tags:
6 Comments
