Skip to Content

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?

 

image

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.

 

image

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.

 

image

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:

  1. All messages go to first line support in the first instance, and
  2. 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:

image

Fig. 4: Catalog configuration

 

In the service desk messaging processing, the selection of catalogue codes  looks like this in Fig. 5.

image

Fig. 5 Catalog code selection

 

 

The settings for a complaint to be sent to the CRM team are as in Fig 6.

image

Fig 6: Container entries for CRM responsibility

 

The settings for other codes to be sent to the Basis team are as in Fig 7.

image

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.

image

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).

image

image

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Tammy Powlas
    My initial thinking with Service Desk is to not configure the Workflow; there’s too much that the first level support needs to enter back into the service message, especially if it is created in ECC. 

    This is just my opinion (at this time) – subject to change, and the team I work with may disagree with me.

    Tammy

    (0) 
    1. Philip @Kisloff Post author
      Hi Tammy, thanks for this observation. I hope I understand you correctly (please put me straight if I haven’t).

      Just for clarification, the workflow I think we both mean is not the automated routing of messages, but just the responsibility table in AC13200137. All the messages are intended to be monitored from the CRM_DNO_MONITOR worklist, making use of the “my colleagues/my department” option (although email notification could be added, it’s not suggested here).

      I can’t say what extra burden classifying a message using the catalog would be, I guess that’s for individual support services to decide, and certainly two levels of support are an unncessary indulgence unless one gets to multi-tennacy hosting scenarios with high volumes…

      As I said, thanks for your comments, I appreciate them, and do correct me if I’ve misunderstood your point.

      Phil

      (0) 
      1. Philip @Kisloff Post author
        I’ve just had another thought. I’m too dogmatic in my wording about the 1st level support being simply a filter to route messages to 2nd level support. There’s no reason why 1st level support can’t be a “fat” layer that deals with >90% of the messages, and escalation to 2nd level is reserved for other issues (e.g. complaints or 3rd party contacts). The noteworthy thing about these settings are that they allow a two-level approach if required.
        (0) 
      2. Tammy Powlas
        I definitely understood you about the routing.  What is interesting to me is that we took a week long class in Service Desk/Charm @ SAP last month and they did not mention what you did in your blog – it is all definitely food for thought.  (your blog is very timely too to our team here at Fairfax Water).

        Many thanks,
        Tammy

        (0) 

Leave a Reply