Skip to end of metadata
Go to start of metadata

1 General Information

This guide describes how to configure Service Level Management in SAP Solution Manager 7.2 representing an integral process of the IT Service Management.

Service Level Management is used for automatic service time calculation based on defined service availability and duration profiles.

Following agreement scenarios can be achieved within SAP Solution Manager 7.2:

SLA - Service-Level Agreement

  • A Service-Level Agreement is defined as an official commitment that prevails between a service provider and the customer.

OLA - Operational-Level Agreement

  • The agreement describes the responsibilities of each internal support group toward other support groups, including the process and timeframe for delivery of their services.

UC - Underpinning Contract

  • An Underpinning Contract is a contract between a service provider and an external service provider that enables service providers to provide services to their customers.

1.1 IT Service Management

The SAP Solution Manager’s IT Service Management represents an ITIL compliant and certified management tool supporting the business processes that enable you to run every aspect of your service desk operations – from managing incidents and problems based on service level agreements, to properly implementing infrastructure changes to eliminate any negative user impact.

The ITSM platform is integrated in all Application Lifecycle Management processes of SAP Solution Manager, in any SAP Business Suite solution and could be connected to a non-SAP Help Desk application. Furthermore, it includes follow up activities like Change Management and Root Cause Analysis.

 

SAP Solution Manager’s ITSM Architecture

1.2 SLA Management

The SLA Management is off the shelf integrated within the SAP Solution Manager IT Service Management and is available after successfully performed system preparation, basic configuration as well as ITSM basic setup. It interacts directly with ITSM Incident Management representing a comprehensive service point which enables a centralized incident and issue message processing in multiple organization levels. The ITSM offers a communication channel with all relevant stakeholders of an incident, such as business user, SAP Service & Support and Partner Support employees.

The SLA Management allows managing and monitoring various defined Service Level Agreements. After activating and properly configuring this feature, the system is able to automatically alert responsible Service Desk Employees, whole Support Teams or IT Service Mangers in case that defined response and solution times of incident messages are violated. This is especially necessary to make sure that messages are processed within the defined period of time as contracted between both parties.

By setting up the SLA Escalation Management mechanism the system monitors when deadlines defined in the SLA parameters have been exceeded in the service process and which follow-up processes would be triggered. For example, email notifications will be sent to upper levels in the Service Desk organization like to responsible IT Service Managers to inform them immediately about expiration of deadlines and SLA infringements. Thereby, IT Service Managers are only involved in the ticketing process when it is really necessary.

Powerful Monitoring and Reporting functionalities support IT Service Managers to get a summarized overview about all ongoing incident messages in their department and to fulfill their key performance indicators (KPIs) as well as to prevent SLA infringements in the future (trend analysis).

Finally on business side, an introduced SLA Management helps to increase the customer satisfaction and to minimize losses resulting from SLA complaints for example in a Service Provider scenario.

This guide is about the fundamental configuration of SLA Management containing several steps. 
The following topics are handled by this document:

  • Creation of Service & Response Profiles
  • General configuration of SLA Management
  • Definition of the SLA Determination Procedure for various use case scenarios
  • How to set up the SLA Escalation functionality including the configuration of email notification
  • Description of SLA specific monitoring and reporting capabilities

 

Functionalities of SLA Management

1.3 OLA & UC Management via Processing Times

Besides the already available SLA functionality for message creators such as business users, the feature of Processing Times introduced with SAP Solution Manager 7.2 allows the realization of OLA and UC Service Level Management scenarios.

Following capabilities are provided:

  • You have the ability to define multiple service clocks by using comprehensive configuration possibilities, such as building of
    • Condition sets for business partners and incident status values 
    • Action sets for clock status, time and threshold calculations 
  • A graphical presentation is provided via a dedicated assignment block within the incident record which offers 
    • A list view of all specified service clocks with a comparison of the planned with the actual response times and durations 
    • A traffic light icon for the threshold indication
  • Sending of emails in case of threshold violations can be realized using the notification framework

2. SLA Management

A service-based SLA (Service Level Agreement) is used to agree modalities of the provisioning of services between different parties (generally a service deliverer and a service consumer). Such SLA modalities include for example content and scope of services guaranteed within certain tolerance limits for certain sizes within a predefined time frame.

The following chapter gives an overview about the concept of SAP Solution Manager’s SLA Management representing a part of the IT Service Management platform. Furthermore, the terminology used in this specific area is introduced for a better understanding.

2.1 Overview

2.1.1 Terminology

Within this section the most relevant terminology is described.

2.1.1.1 IRT

The IRT (Initial Response Time) represents the calculated point in time between the creation of the incident message and the first reaction by the processor contracted in the SLA. This is realized via the “First Response By” timestamp which clarifies until what point in time the processor’s reaction on the created incident has to be performed at the latest.

When the processor starts processing the incident then it is enriched with the timestamp “First Reaction” for actual first reaction by the processor.

 

   Please note that the IRT will be recalculated in case that the incident priority level is changed (refer to chapter “2.1.3 Concept of IRT & MPT Calculation” for further information).

 

 

2.1.1.2 MPT

The MPT (Maximum Process Time) represents the calculated point in time between the creation of the incident message and the total processing time of the message contracted in the SLA. The MPT is realized via the timestamp “ToDo By”. Until this timestamp the incident has to be processed at the latest by the processor.

When the incident is closed by the reporter (in the case that a newly created incident is withdrawn or a proposed solution is confirmed) then the incident is enriched with the timestamp “Completed” for actual incident completion.

 

   Please note that the MPT will be recalculated in case that the incident priority level is changed subsequently or when the incident is set to a customer time status (please refer to chapter “2.1.3 Concept of IRT & MPT Calculation” for further information).

 

2.1.1.3 Service Profile & Response Profile

Within a Service Profile the availability times of the service for incident processing are defined. The system supports any kind of scenario like 5x8 or 7x24. Multiple Service Profiles can be created for different purposes like single customers, IT Items or several Service Products.

Within the Response Profile the time duration until first reaction (IRT) and until service end (MPT) is specified for every type of incident priority. The system allows also the creation of multiple Response Profiles with different priority to duration dependencies for the realization of various scenarios.

2.1.2 Visualization of relevant SLA Times in Web UI

Relevant SLA time information of an incident message can be displayed in 3 different assignment blocks within the Web UI to the responsible message processor. Every assignment block offers different capabilities for the presentation of required information.

 

The following assignment blocks can be chosen by the processor for presentation of SLA Times:

  • Details – Section “Dates”
  • Service Level Agreement
  • Dates

 

   Please note that in Solution Manager 7.1 SPS 05 the SLA time information of an incident message is no longer displayed to the reporter by default.

2.1.2.1 Assignment Block – Details

IRT and MPT as well as its status information are given within an incident message in the “Dates” section of assignment block “Details”. The IRT Status and MPT Status are displayed as monitor icon (green, yellow or red) and calculated in percentage. This traffic light indication with percentage information gives the responsible processor directly a quick visual overview of IRT and MPT information when searching or opening an incident.

 

Cut-out of “Dates” section – Assignment block “Details” 

 

The following IRT and MPT Status information can be displayed:

Green Icon:

    • Defined service time is not reached and agreed service level is not affected

Yellow Icon:

    • SLA Warning à “IRT Warning” or “MPT Warning”
    • Defined service time is nearly reached what implicates that the agreed service level will be also affected

Red Icon:

    • SLA Violation à “IRT Exceeded” or “MPT Exceeded”
    • Defined service time is exceeded

 

   Coloring schema of IRT and MPT Status can be customized in relation to reached percentage (please refer to chapter: 2.2.8 IRT & MPT Status “Warning” and “Exceeded”).

2.1.2.2 Assignment Block – Service Level Agreement

The assignment block “Service Level Agreement” provides a detailed overview of all relevant SLA time information. Within the section “Dates and Duration” the processor is able to display all SLA date / time information (by selecting “Date Types”) or all SLA durations (by selecting “Dates and Duration”) from the dropdown list “Date Types”.

Furthermore, the assigned Service & Response Profiles are presented within the section “Service Levels”.

 

Assignment block “Service Level Agreement” with selection of “Date Types”

 

Cut-out of assignment block “Service Level Agreement” with selection of “Duration Types”

 

   If the assignment block “Service Level Agreement” is not available by default then it can be displayed by using the “Personalize” functionality (pencil icon) which is located at the top right corner of incident message’s menu bar. The “Personalize” functionality allows the adjustment of generic settings like data, time format as well as visible assignment blocks.

 

Cut-out of an incident message within ITSM Web UI – “Personalize” functionality 

 

  • Select the assignment block “Service Level Agreement” and move it to the “Displayed Assignment Blocks” section (make it visible). Use “Up” and “Down” to set the order, choose “Display Expanded” if required and save your settings.

 

Personalization – Displaying SLA assignment block

 

Following SLA date and time information are displayed by selecting “Date Types”:

Notification Receipt:

    • When an incident message is created by the reporter the system sets the timestamp “Notification Receipt" which represents the initialization of the service start.
    • This timestamp is the basis for all future SLA time calculations.

First Response By:

    • The IRT (Initial Response Time) represents the calculated point in time between the creation of the incident message and the first reaction by the processor contracted in the SLA. This is realized via the “First Response By” timestamp which clarifies until what point in time the processor’s reaction at the created incident has to be performed at the latest.

First Reaction:

    • When the processor starts processing the incident then it is enriched with the timestamp “First Reaction” for actual first reaction by the processor

ToDo By:

    • The MPT (Maximum Process Time) represents the calculated point in time between the creation of the incident message and the total processing time of the message contracted in the SLA. The MPT is realized via the timestamp “ToDo By”. Until this timestamp the incident has to be processed at the latest by the processor.

Completed:

    • When the incident is closed by the reporter (in the case that a newly created incident is withdrawn or a proposed solution is confirmed) then the incident is enriched with the timestamp “Completed” for actual incident completion.

Customer Status Changed:

    • The timestamp “Customer Status Changed” is set every time when the processor changes the status of an incident message to a customer status like “Customer Action”, “Proposed Solution” or “Sent to SAP”.
    • This information represents at what given point in time the incident was assigned to the reporter.
    • It is also the basis for IRT & MPT recalculation because customer times do not affect the SLA calculation.

 

Following SLA durations are displayed by selecting “Date Durations”:

Duration Until First Reaction:

    • This period of time is defined within the Response Profile and represents the basis for IRT calculation.
    • Based on the selected incident priority, you should see the same values as defined in the Response Profile (dependencies between Incident Priority Level and “Duration Until First Reaction”).

Duration Until Service End:

    • This period of time is defined within the Response Profile and represents the basis for MPT calculation.
    • Based on the selected incident priority, you should see the same values as defined in the Response Profile (dependencies between Incident Priority Level and “Duration Until Service End”).

Total Customer Duration:

    • The time duration when an incident message is assigned to the reporter (incident status is set to “Customer Action”, “Proposed Solution” or “Sent to SAP”) is added and visible via the parameter “Total Customer Duration”.

Total Duration of Service Transaction:

    • The time duration for the whole processing of the incident message is added and visible via the parameter “Total Duration of Service Transaction”

Work Duration of Service Transaction:

    • The time duration when an incident message is assigned to the processor is added and visible via the parameter “Work Duration of Service Transaction”.

2.1.2.3 Assignment Block – Dates

The assignment block “Dates” represents the most comprehensive form of presenting all SLA time information. Within one single assignment block all SLA dates, times and durations are displayed. 

Assignment block “Dates”

 

    If the assignment block “Dates” is not available by default then it can be displayed by using the “Personalize” functionality (pencil icon) – please refer to “2.1.2.2 Assignment Block – Service Level Agreement”.

     Please refer to chapter “2.1.2.2 Assignment Block – Service Level Agreement“ for a detailed description of all available SLA dates, times and durations.

 2.1.3 Concept of IRT & MPT Calculation

The IRT & MPT calculation is based on the configuration performed within the Service & Response Profile as well as of the defined characteristics of the incident message (e.g. Priority).

The table below presents all parameters which are involved in the calculation of IRT & MPT:

2.1.3.1 IRT & MPT Calculation

The following example is the basis for IRT & MPT calculation:

  • The Reporter creates an incident at 2 pm with the Incident Priority Level 2 (“High”).
  • The system sets the timestamp “Notification Receipt" which represents the initialization of the service start.
  • The system determines the right Service and Response Profile according to the specified SLA Determination Procedure (please refer to chapter “2.3 SLA Determination“ for further information).

Following configurations of the Service and Response Profile are taken into consideration:

  • Within the Response Profile the “Duration Until First Reaction” for Priority Level 2 is set to 8 hours.
  • Within the Response Profile the “Duration Until Service End” for Priority Level 2 is set to 14 hours.
  • Within the Service Profile the “Availability Times” are set to daily availability from 8 am to 6 pm.
  • The settings for “Availability Times” imply the “Off Times” configuration of daily service unavailability from 6 pm to 8 am.
  • In general, the offered Service Profile describes a 7x10 Support Contract (daily 10 hours). 

Timestamps for IRT (“First Response By”) and MPT (“ToDo By”) are calculated in the following way:

  • IRT (“First Response By”) is set to 12 pm next working day (4h actual working day ending at 6 pm + 4h next working day starting from 8 am).
  • MPT (“ToDo By”) is set to 6 pm next working day (4h actual working day ending at 6 pm + 10h next working day starting from 8 am). 

2.1.3.2 IRT & MPT Recalculation

IRT & MPT will be recalculated in case of changes of following parameter:

Incident Priority Level

    • The IRT and MPT are recalculated when the Incident Priority Level is changed subsequently according to the configuration of the Response Profile (dependencies between Incident Priority Level and “Duration Until First Reaction” / “Duration Until Service End”).
    • Specified “Availability Times”, “Off Times” and “Exceptions” of the Service Profile could have also impact on IRT and MPT recalculation when changing the Priority (e.g. if the Incident Priority Level is changed to a lower priority which includes an extended amount of time for responding, then defined “Off Times” are taken into consideration for the recalculation).

 

MPT will be recalculated in case of changes of following parameter:

Customer Time Status

    • When an incident is assigned back to the reporter (e.g. the incident message is set to a customer time status like “Customer Action” or “Proposed Solution” by the processor) the MPT is recalculated according to the time duration how long the incident was assigned to the reporter.
    • Specified “Availability Times”, “Off Times” and “Exceptions” of the Service Profile could also have an impact on the MPT recalculation.

 

   Please note that only MPT will be recalculated in case of changes of the Customer Time Status. 

 

The following diagram represents the MPT recalculation according to Customer Time Status in comparison to the previously described example “2.1.3.1 IRT & MPT Calculation”.

 

  • Before the MPT is reached on day 2 (in comparison to previous example “2.1.3.1 IRT & MPT Calculation”) the incident is assigned back to the reporter by the processor for requesting further information required for an adequate solution finding.
  • The reporter required 21h for providing the information to the processor which results in a MPT recalculation.
  • MPT by timestamp “ToDo By” is set to 3 pm next working day (4h day 1 + 4h day 2 ending with status change to customer status + 6h day 3 starting from 11 am).

 

2.1.3.3 Manual Re-Definition of IRT & MPT

IRT & MPT can also be adjusted in a manual way by using “Select date” and “Time Picker” functionality in the assignment blocks “Service Level Agreement” and “Dates”.

This functionality will abrogate the SLA calculation mechanism and should only be performed when the situation requires manual adoption of SLA time parameters.

 

                                                                         Assignment block “Dates” – Adjustment of IRT & MPT

 

    Please note that all manual changes on SLA times will be documented in assignment block “Change History” which allows retracing all changes by timestamp and user name.

2.2 SLA CONFIGURATION 

The following chapter contains an extended description of the basic configuration of SLA Management. Required notes that should be applied before are pointed out. Furthermore the definition of Service and Response Profiles are explained in detail. Additional optional functions and adjustments are described. 

2.2.1 SOLMAN_SETUP

You have performed the basic configuration of your Solution Manager via SOLMAN_SETUP:

  • System preparation
  • Basic configuration
  • Managed System configuration

You have performed the IT Service Management Basic Configuration via SOLMAN_SETUP.

Customization of Transaction Types: SMIN / SMIV (probably copied to customer namespace).

The configuration of the Status Profiles of the Transaction Types relevant for the Service Desk. 

2.2.2 Required Corrections

Please check latest version of following notes to Solution Manager SPS as they are essential for SLA Management to work correctly:

1681942 - SLA: Due date not updated with customer durations

    • Once a message is changed from a non-relevant status (e.g. “Customer Action”) back to a relevant status (e.g. “In Process”) the appointment for Due date is not updated with the customer duration delta.

1674375 - SLA: Customer durations not applied correctly

    • The customer duration is correctly recorded and cumulated. Anyway, when switching back to a relevant status (e.g. "In process") the percentages for IRT and MPT increase significantly.
    • When switching back from a customer status to an SLA relevant status the duration should be excluded so that the consumed durations should persist.

1659388 - ITSM: incorrect SLA calculation for time zones

    • Your users work in different time zones. This leads to incorrect results from the calculation of SLA durations.
    • Internally the relevant timestamps are converted into UTC time zone. Instead of using the date and time of the currently logged on user, the corresponding system date/time are used to determine the current UTC timestamp.

1654642 - SLA Escalation before message is saved

    • The calculation of IRT and MPT is starting right away, even if the message has not been saved yet.
    • The percentages are increasing and it seems that the message will reach an escalation level without being saved.

1691338 - SLA: IRT not stopped when message is closed immediately

    • When saving the message with status 'Completed' right after having it saved in another status apart from 'New', the IRT percentage continues to increase until 999%.

1705846 - SLA Escalation while not responsible or available

    • You have defined a status in which the calculation of IRT and MPT should get paused (e.g. "Customer Action"). However, the escalation is executed although the message persists on "Customer Action".
    • Escalation is also happening outside of your availability times, according to the definition from your service profile.

2.2.2.1 Note 1674375 – Maintain entries in CRMV_SRQM_DATSTA

The Note 1674375 contains manual activities in table “CRMV_SRQM_DATSTA” and is extremely important for a proper working of SLA Management. That is why it is explicitly mentioned in this section.

Assignment block “Dates” – Adjustment of IRT & MPT

Symptom:

  • The customer duration is correctly recorded and cumulated.
  • When switching back to a relevant status (e.g. "In Process") the percentages for IRT and MPT increase significantly.
  • When switching back from a customer status to a SLA relevant status the duration should be excluded so that the consumed durations should persist.

 Correction steps:

  • Implement the correction.
  • Once this is done, please adjust the customizing in table CRMV_SRQM_DATSTA via transaction: SM30.
  • Attached to this note you find the list of records that need to be added or deleted in the above mentioned table.
  • In case you are using a customized Status Profile in a customer namespace or even an own Date Profile please apply the changes accordingly.

2.2.3 SLA Management IMG Activities

The main configuration steps can be performed via dedicated IMG activities - please call transaction: SPRO and navigate to following IMG node: SLA Escalation

  • SAP Solution Manager Implementation Guide → SAP Solution Manager→ Capabilities (Optional)→  IT Service Management (formerly Application Incident Management (Service Desk))→SLA Escalation

IMG path for configuration of SLA Management

2.2.4 Service Profile

The Service Profile specifies the availability times of the service team for incident processing. The system supports any kind of scenario like 5x8 or 7x24. Multiple Service Profiles can be created for different purposes like single customers, IT Items or several Service Products.

 

Customizing Activities:

  • Choose “Edit Availability and Response Times” from above mentioned IMG path 
    (2.2.3 SLA Management IMG Activities) or call transaction: CRMD_SERV_SLA.
  • Create a new Service Profile entry
  • Go to “Edit Mode”
  • Select “Service Profile”, click “New Entries” and enter a profile name

Maintain the Service Availability Times for the newly created Service Profile

  • Start the calendar form by clicking the “clock” icon of the related Service Profile

Use specific rule sets according to your needs and define Availability Times

  • Daily periodic Availability Times
  • Weekly periodic Availability Times
  • Monthly periodic Availability Times
  • Additional Availability Times
  • No Availability Times

Define Variances by choosing the rule for exceptions

  • No Exceptions
  • Not on non-working days
  • On non-working days move to the next working day
  • On non-working days move to the previous working day

Define used Calendar for handling the exceptions

  • Factory Calendar 
  • Holiday Calendar
  • All Days are Working Days

   Calendar definition requires a valid factory calendar. Please check and adjust this by transaction: SCAL.

                                                                                       Cut-out of “Factory Calendar” and defined “Valid to” dates

 

  • Save the maintenance by pressing the “Copy” button
  • Reenter the maintenance mode for creating multiple definitions of Availability Times

 

      “Copy As” function for the whole Service Profile copies also all defined Availability Time settings and allows simple configuration of multiple profiles by only changing differences.

2.2.5 Response Profile

The Response Profile defines the time duration until first reaction and until service end for every type of Incident Priority. The system allows also the creation of multiple Response Profiles with different priorities. This makes it possible to have different duration dependencies for realization of multiple scenarios (please refer to chapter “2.3.3 Use Case Scenarios” for further information).

 

Customizing Activities:

  • Choose “Edit Availability and Response Times” from above mentioned IMG path (2.3 SLA Management IMG Activities) or call transaction: CRMD_SERV_SLA.
  • Create a new Response Profile entry
  • Go to “Edit Mode”
  • Select “Response Profile”, click “New Entries” and enter a profile name

Create Indicators for Response Times

  • Mark newly created Response Profile and double-click “Indicators for Response Times

 

  • Activate “Priority” check box and create entries for the single incident priority indicators (1 to 4). The Incident Priority is responsible for determining the Response Times. 

Create dependencies between Incident Priority Level and Response Times

  • Mark a created priority and double-click “Response Times” for definition of related “Duration Until First Reaction” (SRV_RF_DURA) as well as the “Duration Until Service End” (SRV_RR_DURA).
  • Enter required duration values for every combination
  • “Duration Until First Reaction” (SRV_RF_DURA) is responsible for calculation of IRT
  • “Duration Until Service End” (SRV_RR_DURA) is responsible for calculation of MPT

  • Repeat step 1 to 3 for all Incident Priority Levels

 

    “Copy As” function for the whole Response Profile copies all defined settings (Priorities with related duration values) and allows simple configuration of multiple profiles by just changing differences, e.g. differences in duration values.

2.2.6 Settings for Durations

In this Customizing activity you define which combination of user status profile, user status, and date profile will be used to calculate durations for transactions.

When you update the status of an incident message, the system automatically updates the date types and durations of the transaction according to the new status. For example, set the closing date when the user status is set to Completed.

 

The Settings for Durations can be maintained by choosing the activity “Define Settings for Durations” from IMG path “2.2.3 SLA Management IMG Activities” or via transaction: SM30 and table CRMV_SRQM_DATSTA.

 

    In general, no customization for this activity is required. Default values guarantee that SLA times are properly calculated in case of incident status changes.

    Please ensure that the correction 1674375 (Solution Manager SPS 04) is implemented for a proper calculation of SLA times (please refer to chapter “2.2.2.1 Note 1674375 – Maintain entries in CRMV_SRQM_DATSTA”).

2.2.7 Customer Time Status

Customer times are specified by the user status of an incident message. Defined Customer Times Statuses do not affect the SLA calculation (MPT calculation). This mechanism should prevent mainly for SLA escalations if an incident has to be processed by another person than the processor.

 

   The processor requires additional information from the reporter which is not included at the moment within the created message description. For an adequate processing, the incident will be commented with a request for providing additional information and assigned back to the reporter by the incident status change to “Customer Action”. The duration the reporter requires for enrichment of the incident should be excluded from calculation of SLA times because the processor is not able to take any influence on the time the reporter needs to provide the information (in the worst case the message is sent back to the processor and the MPT would be already exceeded). The period of time the message is on reporter’s side is added to the parameter “Total Customer Duration” and the MPT will be recalculated according to this value.

 

Following status types are already considered by default:

Customer Action / Author Action (VAR scenario)

  • When the reporter has to deliver additional information like login data, screenshots, descriptions, etc.

Proposed Solution

  • When the reporter has to check a proposed solution.

Sent to SAP

  • When SAP is responsible for providing a solution or information.

Sent to Ext. Provider (VAR scenario)

  • When the message has to be processed by a 3rd party.

 

The customization of non-default definitions could be necessary in following cases:

  • If customer specific incident statuses are not available in SAP Solution Manager by default.
  • If already included incident statuses should be considered also for MPT calculation (meaning exclude it from the list of Customer Time Status) like “Customer Action” should do have affect on the SLA calculation.
  • If not included incident statuses should be also excluded from MPT calculation (meaning add the specific incident status to the list of Customer Time Status).

 

Cut-out of incident status selection in ITSM Service Desk

Customizing Activities:

  • Choose activity “Specify Customer Time Status” from IMG path “2.2.3 SLA Management IMG Activities” or via transaction: SM30 and table: AISTATUS_SLA.
  • Add a data record to the list for each user status for a non-relevant (customer) duration
    • Go to “Edit Mode”
    • Click on “New Entries”
    • Enter the name of the Status Profile (e.g. SMIN* or SMIV*) and the Status Code (E*)

2.2.8 IRT & MPT Status “Warning” and “Exceeded”

The IRT & MPT Status “Warning” and “Exceeded” as well as the related icon color “yellow” and “red” will be triggered automatically in case that a defined threshold is reached. This threshold can be defined by the user as percentage to the overall IRT and MPT.

Following IRT & MPT Status values are configured by default:

  • “Warning” in case of 60%
  • “Exceeded” in case of 100%

 

Cut-out of IRT & MPT Status in ITSM Service Desk 

Customizing Activities:

  • Call transaction: SM30
  • Maintain table: AIC_CLOCKNAME
  • Change level of percentage of IRT & MPT Status

     Please note that the SLA Escalation mechanism (especially the email notification service) is based on the defined values which are defined in this customizing step (please refer to chapter: “2.4 SLA Escalation”).

2.3  SLA DETERMINATION

The topic of SLA Determination describes the mechanism to determine automatically the proper SLA (Service & Response Profile) for a created incident message according to the information maintained in the master data. Technically, it is realized by the definition of SLA Determination Procedures and their related Access Sequence.

At the Beginning of this Chapter you will find an introduction of all the offered determination possibilities by the SLA Management, followed by their application in the most common use case scenarios. Finally, additional functionalities for the VAR (Value Added Reseller) scenario are described.

 

   Please note that in case of changes to the SLA (Service & Response Profile), existing incidents with these assigned profiles will not be updated automatically. They will be updated if one the main parameter for recalculation (e.g. Priority) is changed manually.

2.3.1 SLA Determination Possibilities

You can determine SLAs for transactions (for example, incidents and problems) based on information maintained in the master data such as:

Service Contracts

  • On the one Hand a Service Profile as well as a Response Profile can be attached to a specific Service Contract. On the other hand the Service Contract can be assigned by contract determination to a created incident message. This means that both profiles will also be assigned to the incident.

   Please note that currently Service Contract Determination is just recommended for upgrading purposes to SAP Solution Manager 7.1 SPS 05 to support already defined configurations.  For enabling Service Contracts, the required customizing has to be performed (please keep in mind that usage of Service Contracts in SPS 05 are not supported at the moment by SAP – no adoptions and tests were performed for SPS 05).

 

Service Product Item

  • A Service Profile as well as a Response Profile can be attached to a Service Product. The Service Product can also be assigned to specific master data like to the category of a defined Multilevel Categorization. In case of selecting this category during the incident creation process, the correct Service Product will be determined as well as its defined Service & Response Profiles.

 

Cut-out of incident creation guided procedure in ITSM Service Desk

 

Reference Objects (IBase Component)

  • A Service Profile as well as a Response Profile can be attached to a specific IBase Component. This means, if this IBase Component is entered during the incident creation process, the related Service & Response Profile will be chosen.

 

Cut-out of incident creation guided procedure in ITSM Service Desk

 

Reference Objects (Objects)

  • A Service Profile as well as a Response Profile can be attached to a specific Configuration Item (e.g. IT Item). This means, if this item is entered during the incident creation process, the related Service & Response Profile will be chosen.

 

Cut-out of incident creation guided procedure in ITSM Service Desk

 

Business Partners (Sold-To Party)

  • A Service Profile as well as a Response Profile can be attached to a specific Sold-To Party (e.g. a Customer). This means, if this Sold-To Party is entered to the incident (manually by the Processor or automatically by a defined rule), the related Service & Response Profile will be assigned.

 

Cut-out of incident creation guided procedure in ITSM Service Desk

 

BAdI Implementation

  • You can also use the Business Add-In for SLA Determination (CRM_SLADET_BADI) to define your own logic for determining SLAs
  • IMG activity: Customer Relationship Management → Transactions → Settings for Service Requests → Business Add-Ins → Business Add-In for SLA Determination.

 

Cut-out of IMG activity for BAdI Implementation

 

   Please note that the following determination options are currently available in the selection list of the Access Sequence definition which are not in scope of SLA Management (not adopted or tested to the ITSM):

  • Reference Objects (IBase)
  • Reference Objects (IBase Text Component)
  • Reference Objects (Product)
  • Organizational Units (Sales)
  • Organizational Units (Service)

2.3.2 SLA Determination Procedure & Access Sequence

This Chapter describes the general Definition of a SLA Determination Procedure and the related Access Sequence.

The Access Sequence identifies where to search for the SLA and in what sequence. When first entry in the sequence met the criterion of a newly created incident than the related Service & Response Profile will be assigned directly. If the criterion is not met than next item in the sequence list will be processed and ongoing.

 

Customizing Activities:

  • Call transaction: SPRO and choose IMG activity “Define SLA Determination Procedures” from IMG path for SLA Escalation (please refer to chapter: “2.2.3 SLA Management IMG Activities“).

 

Cut-out of SLA Escalation IMG activity

Create SLA Determination Procedure

  • Go to “Edit Mode” 
  • Create a SLA Determination Procedure by choosing “New Entries”
  • Enter a name and a description  

Create Access Sequence

  • Select the newly created SLA Determination Procedure and double-click “Access Sequence”

 Define Access Sequence

  • Create new sequences by choosing “New Entries”
  • Build-up the sequence hierarchy according to your needs.
    Define a sequence number and choose your required determination option from the dropdown list (please refer to chapter: “2.3.1 SLA Determination Possibilities“).
    If a new incident message is created, the system will run through the Access Sequence and every entry will be processed from top to bottom until the first criteria fulfills the condition.
  • In the presented example below (step 2) at first a Service Contract is checked, followed by an IBase Component and finally a Sold-To Party. If no Service Contract is assigned to the created incident message the system analyzes in the next step the IBase Component. If the reporter entered an IBase Component for which a Service & Response Profile assignment exists than these profiles are chosen and all SLA times are calculated according to the defined parameters of these ones.

 

Assign SLA Determination Procedure to Transaction Types

  • In the next step the created SLA Determination Procedure has to be assigned to the Transaction Type (e.g. SMIN or ZMIN)

  • Call transaction: SPRO and choose IMG activity “Define Transaction Types” from following IMG path: SAP Solution Manager Implementation Guide à SAP Solution Manager à Capabilities (Optional) à IT Service Management à Transactions à Define Transaction Types

 

 

  • Go to “Edit Mode”
  • Select your Transaction Type from the list (in this case ZMIN)
  • Double-click “Assignment of Business Transaction Categories”

   

Select Transaction Category “Service Process”

  • Double-click “Customizing header”
  • Finally, assign your created SLA Determination Procedure to the Transaction Type’s Customizing Header

   

2.3.3 Use Case Scenarios

The following chapter describes the configuration steps for the most common use cases for which the SLA Management is applicable.

 

   All steps mentioned below require proper configured Service & Response Profiles (please refer to chapters: “2.2.4 Service Profile and 2.2.5 Response Profile”).

 

2.3.3.1 Standard SLA Management for Incident 

Use case:

This use case is addressed to customers who require a simple SLA Management without specific rules for building up a complex Access Sequence. In this case a single Service and Response Profile is created and attached to the standard Service Product “Investigation”.

    In SAP Solution Manager 7.01 the service product was called “Support Hotline”. This changed in  SAP Solution Manager 7.1 to “Investigation” to cover all CRM WEB UI related steps.

The SLA times (IRT and MPT) will be calculated for any created incident message according to the parameters set within “Investigation”. The Service Product “Investigation” can also be used as default set for SLA calculations when no previous conditions in the Access Sequence are fulfilled. In this case “Investigation” should be the last item in the sequence list.

 

   

Customizing Activities:

  • Run Upgrade Methods
  • Call transaction: SE38 and execute report: COM_PRODUCT_UPGRADE

  • If this is executed for the first time, following message will appear

 

 

       Following message will appear if this step was already performed before.

 

 

Creation of Service Hierarchy and Service Product “Investigation”

  • Call transaction: SE38 and execute report: AI_CRM_PRODUCT_SETUP

 

  • Select radio-button “Service”
  • Click on button “Execute”

Assign Service & Response Profile to Service Product “Investigation”

  • Call transaction: COMMPR01
  • Search for all product types and click on Service Product “Investigation”
  • Go to “Edit Mode”
  • Assign defined Service & Response Profiles to the Service Product in set type “Default Values for Service Contracts”

 

Define SLA Determination Procedure

  • Define a new Access Sequence with “Service Product Item” at the last sequence step. The Service Product “Investigation” is hardcoded in the system and will be chosen if no other determination criterion in the sequence is matched before.
  • For a simple SLA Management with one Service and Response Profile for all incident messages, select “Service Product Item” at the first sequence step.
  • Please refer to chapter: “2.3.2 SLA Determination Procedure & Access Sequence”.

 

     Usually the Service Product “Investigation” should be arranged as the last item in the Access Sequence so that a default Service and Response Profile is assigned to an incident message in any case. If an Access Sequence is build up with other conditions and “Service Product Item” is defined as first item in the list than the determination will stop always on the first step and “Investigation” is assigned. Thus, the system will never process another determination criterion. 

2.3.3.2 SLA Management by Multilevel Categorization

Use case:

This use case is addressed to customers who are using the Multilevel Categorization and want to have a SLA calculation based on different nodes (categories). In this case separate Service Products are created with different SLAs (Service and Response Profiles) belonging to the nodes in the hierarchy of Multilevel Categorization. In case of selecting this category during the incident creation process, the right Service Product will be determined as well as its defined Service & Response Profiles.

This makes the SLA selection very powerful and several combinations can be arranged.

 

Customizing Activities:

Creation of a new Service Product

  • Call transaction: COMMPR01
  • Search for all product types and click on Service Product “Investigation”
  • Go to “Edit Mode”
  • Click “Copy” for creation of a new Service Product by copying product “Investigation”
    (It is also possible to create a completely new one)

 

  • Define a name and a description for the new Service Product

  

  • Assign defined Service & Response Profiles to the newly created Service Product in set type “Default Values for Service Contracts” as shown below

  • Assign previously created Service Product to MLC categories
  • Open CRM Web UI by transaction: SM_CRM
  •  Select “Service Operations” from the side menu and search for available “Categorization Schemas”.

Usually one active categorization schema should maintain all the following: Incident, Incident Template, Knowledge Article, Problem and Problem Template.

In this example the SAP Solution Manager default schema “SAP_SOLUTION_MANAGER_TEMPLATE” is selected.  

  • In “Category Hierarchy”, navigate to your category and mark the entry
  • Go to “Edit Mode”

 

  • Go to Assignment Block “Service Products” (use the “Personalize” functionality if it is not available)
  • Assign the previously created Service Product with attached Service & Response Profile to the specific node by clicking button “New”

In case that “Authorization missing” is selected in category 4 during incident creation process then Service Product “MLC SLA” with its Service and Response Profile will be chosen.

 

Define SLA Determination Procedure

  • Define a new Access Sequence and enter “Service Product Item” to the sequence list. Other determination options can be entered additionally for completing the determination procedure with other scenarios.
  • Please refer to chapter: “2.3.2 SLA Determination Procedure & Access Sequence”.

 

    In case that a category with an attached Service Product is selected during incident creation process then this Service Product will replace the hardcoded Service Product “Investigation” and SLA will be changed accordingly. Please refer to use case: “3.3.1 Standard SLA Management for Incidents”. Otherwise, if no Service Product is assigned to a chosen category then default Service Product “Investigation” will be selected automatically.

 

2.3.3.3 SLA Management for IBase Components

 

Use case:

This use case is addressed to customers who require different SLAs for specific IBase Components. For example, some components are crucial for the customer’s business and require different reaction and process times. In this case single Service and Response Profiles are assigned to specific IBase Components and if one of those is entered during incident creation process then the related profiles are fetched.

 

Customizing Activities:

  • Assign previously created Service and Response Profiles to IBase Components
  • Open CRM Web UI using transaction: SM_CRM
  • Select “Master Data” from the side menu and search for available “Installed Bases”

 

  • In “Installed Base Hierarchy”, navigate to your component and mark the entry
  • Go to “Edit Mode”

 

  • Go to Assignment Block “Service Levels” (use the “Personalize” functionality if it is not available)
  • Assign the previously created Service and Response Profile to the specific component by using the dropdown list

 

Define SLA Determination Procedure

  • Define a new Access Sequence and enter “IBase Component” to the sequence list. Other determination options can be entered additionally for completing the determination procedure with other scenarios.
  • Please refer to chapter: “2.3.2 SLA Determination Procedure & Access Sequence”.

 

2.3.3.4 SLA Management for IT Elements

Use case:

An organization could have different SLA contracts with their hardware suppliers for their internal IT equipment. The reaction, repair and exchange times should be defined accordingly to the importance within the company’s IT landscape for ensuring business activities. For example, critical core routers should have fast reaction, repair or exchange times in case of malfunctions. The SLA Management provides the functionality to assign various Service & Response Profiles to CMDB or LMDB objects representing in this example network elements. In case of a malfunction of such an item, the internal IT department would create an incident message and enter the affected device in the “Configuration Item” field section. Based on this information the related Service & Response Profiles are fetched with the result that IRT and MPT are calculated.

 

 

Customizing Activities:

  • Assign previously created Service and Response Profiles to Objects
  • Open CRM Web UI using transaction: SM_CRM
  • Select “Master Data” from the side menu and search for available “Objects”

  • Select the object for which a SLA should be configured

  • Go to Assignment Block “Service Levels” (use the “Personalize” functionality if it is not available)
  • Go to “Edit Mode”
  • Assign the previously created Service and Response Profile to the specific object

Define SLA Determination Procedure

  • Define a new Access Sequence and enter “Reference Objects (Object)” to the sequence list. Other determination options can be entered additionally for completing the determination procedure with other scenarios.
  • Please refer to chapter: “2.3.2 SLA Determination Procedure & Access Sequence”.

2.3.3.5 SLA Management according to different Customer SLAs

Use case:

Several Customers have different Service Level Agreements with the responsible Service Provider (Partner). If an Incident is created by a Reporter then the system automatically determines the Sold-To Party (Customer) by its system specification as well as the assigned SLA (especially the defined Service & Response Profile). This use case is mainly relevant for a VAR scenario with different SLA contracts for several customers.

  

  Please ensure that a partner assignment between IBase Component and the Sold-To Party exists, so that the correct Customer is assigned after incident message creation(transaction: IB52).

 

Customizing Activities:

  • Assign previously defined Service & Response Profiles to dedicated Customers
  • Open CRM Web UI using transaction: SM_CRM
  • Select “Master Data” from the side menu and search for available Customers by clicking on “Accounts”

 

  • Open the Customer for whom the Service & Response Profile should be assigned

  

  • Go to Assignment Block “Service Levels” (use “Personalize” icon if it is not visible)
  • Switch to “Edit Mode” and select dedicated Service & Response Profiles

   

 

Define SLA Determination Procedure

  • Define a new Access Sequence with “Business Partners (Sold-To Party)” at sequence step 1, so that the system checks firstly after incident creation if there is a Customer assigned. Other determination options can be entered additionally for completing the determination procedure with other scenarios.
  • Please refer to chapter: “2.3.2 SLA Determination Procedure & Access Sequence”.

 

2.3.4 Test Use Case Scenarios

Open a created incident within the Web UI and check the chosen Service & Response Profile as well as the SLA durations for the assigned Customer in assignment block “Service Level Agreement”. Compare the entries with your performed configuration (Access Sequence, Service & Response Profile, applied entries during incident creation – e.g. Incident Priority, SAP Component, Customer, etc.).

 

Please refer to chapter: “2.1.2.2 Assignment Block – Service Level Agreement“.

Assignment block “Service Level Agreement” with selection of “Duration Types”

 

2.3.5 Additional Functionalities for VAR Scenario

Following additional functionalities for the VAR (Value Added Reseller) scenario have to be considered when setting up SLA Management as they could have an impact on the SLA processing.

  • 2.3.5.1 VAR: COMP_AUTO

Incidents can be sent automatically to the SAP Backbone by entering specific components during the message creation process. The automatic forwarding of messages is carried out regardless of the business hours, the customer or other criteria and is only applied when a new message is created. The status of a newly created message will be set automatically to “Sent to SAP” in case that the defined component criteria are met. The components for which the forwarding functionality is taking into account have to be defined previously.

 

   COMP_AUTO functionality abrogates the SLA Management mechanism by direct forwarding of messages to the SAP Backbone.

   All components starting with XX-SER are automatically forwarded to SAP by default. For components that are not supposed to be forwarded automatically, use the field name COMP_NO_AUTO and specify the components in the field value section.

   Ensure that Note 1571783 is implemented if you are using Solution Manager 7.1.

 

Customizing Activities:

  • Call transaction: DNO_CUST04 for starting the “Service Desk Customizing”
  • Go to “Edit Mode”
  • Select “New Entries
  • Enter the Field Name: “COMP_AUTO” and add the SAP Components to the Field Value section for which the automatic forwarding should be applied to:
  • Separation of several components by comma “,”
  • Sub trees of component hierarchy by wildcard character “*”

 

2.3.5.2 VAR: Incident Priority Level 1 & Out of Calling Hours

Incident messages which are created outside the “Calling Hours” of an assigned Sold-To Party (e.g. a Customer) and have Priority 1 (“High”) will be automatically forwarded to the SAP Backbone. The status of a newly created message will be automatically set to “Sent to SAP” in case that the mentioned conditions are met.

 

  Incident Priority Level 1 & Out of Calling Hours functionality abrogates the SLA Management mechanism by direct forwarding of messages to the SAP Active Global Support Backbone.

  Please ensure that the Sold-To Party’s Calling Hours have been maintained correctly in the system.

 

Cut-out of definition of Calling Hours in ITSM Service Desk

 

2.4  SLA ESCALATION

The following chapter clarifies how SLA Escalation is working including the configuration of the email notification service.

 

2.4.1 Concept of SLA Escalation

The SLA Escalation mechanism is used to inform responsible staff like IT Service Managers immediately about expiration of deadlines and SLA infringements.

In the case that an incident message reaches the calculated IRT or MPT timestamp, the systems sets the status automatically at first to “Warning”. If the timestamp is exceeded than the incident’s status is set to “Exceeded”. In both cases an email notification will be triggered to defined partner functions.

 

2.4.2 Maintaining SLA Actions

The email notification service is controlled via specific Actions of an Action Profile. Actions in CRM use the Post Processing Framework (PPF) which is a Basis component generating actions from the data for an application according to an action definition.

 

From SP04 onwards the actions below are available in SMIN_STD:

  • SMIN_STD_SLA_IRT_ESC
  • SMIN_STD_SLA_MPT_ESC

 

The main configuration steps can be performed via dedicated IMG activity - please call transaction: SPRO and navigate to following IMG node: Define Actions and Profiles

  • SAP Solution Manager Implementation Guide > SAP Solution Manager > Capabilities (Optional) > IT Service Management > Define Action Profile > Change Actions and Conditions > Define Actions and Profiles

 

Cut-out of IMG path for maintaining Actions

Customizing Activities:

  • Select Action Profile
  • Choose activity “Define Actions and Profiles” from above mentioned IMG path
  •  Select the Action Profile of related transaction type (in this case it is ZMIN)
  • Double-click “Action definition”

 

 

Select SLA IRT Escalation Action

  • Ensure that the checkbox “Inactive” is deactivated of action “SMIN_STD_SLA_IRT_ESC” 
    (in this case ZMIN_*)
  •  Double-click action “SMIN_STD_SLA_IRT_ESC” (in this case ZMIN_*)

 

   

Define SLA IRT Escalation Action

  • Check if option “Schedule Automatically” is activated
  • Check if option “Partner-Dependent” is activated
  • Define related Partner Function as receiver for emails in case of SLA Escalations.

In this case the Message Processor is selected but for example the whole Support Team by choosing “SLFN003” can also be notified in case of a SLA violation.

   

     Please note that no email notification will be sent in case of IRT or MPT threshold violation when the Partner Function “Message Processor” was selected and no processor is assigned to an incident message. For example this could happen when the incident is still in status “New”.

 

     Please note that sending an email to the defined Partner Function (Partner Determination for the Action) will only work when the email address is maintained correctly in the Business Partner.

 

Cut-out of maintaining Business Partner’s email address by transaction “BP”

 

Perform step 2 to 3 also for SLA MPT Escalation Action

  • SMIN_STD_SLA_MPT_ESC (in this case ZMIN*)

 

2.4.3 Schedule SLA Escalation Background Job for triggering Email Notifications

For examining SLA threshold violations within incident messages a periodic batch job of the report AI_CRM_PROCESS_SLA has to be created.

 

Please call transaction: SM36 for starting the general “Define Background Job” form. It is also possible to call transaction: SPRO and choose the following IMG node: Schedule Escalation Background Job

  • SAP Solution Manager Implementation Guide > SAP Solution Manager à Capabilities (Optional) > IT Service Management > SLA Escalation > Schedule Escalation Background Job

 

Cut-out of IMG path for SLA Escalation

 Customizing Activities:

  • Define SLA Escalation Background Job
  • Start “Define Background Job” form by choosing one of above mentioned possibilities
  •  Enter a job name and save created job

 

  • Enter report: AI_CRM_PROCESS_SLA and save again and go back (F3)

 

Schedule defined SLA Escalation Background Job

  • After the job is successfully defined, now the “Start condition” has to be set
  • Click on button “Immediate” (activated checkbox “Immediate start” appears)
  • Activate “Periodic job” and click on button “Period values” for defining appropriate period cycles according to your needs. For example “Other period” was chosen for definition of a 10 minutes execution cycle.
  • Go back by saving your changes in every step.

   

  It is recommended to define the SLA Escalation Background Job on a periodic basis to ensure that SLA threshold violations are discovered in near real time for protecting on possible SLA infringements. 

  Increase the period, depending on the frequency of messages.

 

Release newly created SLA Escalation Background Job

  • Press “Save” and the job status will be set to “Released” 

  A variant can be defined for the report “AI_CRM_PROCESS_SLA”

 

Clean-up trigger tables and Rebuild Index mechanism should be performed from time to time or if necessary for improving the performance (e.g. removal of obsolete entries).

 

2.4.4 Activate SLA Escalations

Finally, the SLA Escalation mechanism has to be enabled by following customization step.

 Customizing Activities:

  • Choose activity “Activate SLA Escalations” from IMG path “2.3 SLA Management IMG Activities” or call transaction: DNO_CUST04
  • Activate SLA Escalations
  • Go to “Edit Mode”
  • Set the attribute SLA_ESCAL_ACTIVE to 'X'

  • If there is no such record, then select “New Entries” and enter following values to Field Name “SLA_ESCAL_ACTIVE” and Field Value “X” 

  

2.4.5 Email Notification

In case that all previous described configuration activities were performed probably, email notifications will be sent automatically by following IRT and MPT status conditions:

  • Warning
  • Exceeded

 

Cut-out of IRT & MPT Status in ITSM Service Desk

 

A default email will be sent with following parameter:

In case that IRT is impacted (incident status “Warning” or “Exceeded”)  

  • Subject: “Transaction: <Incident ID> First Response Exceeded”
  • PDF attachment with the same file name like the subject

 

In case that MPT is impacted (incident status “Warning” or “Exceeded”) 

  • Subject: “Transaction: <Incident ID> Completion Exceeded”
  • PDF attachment with the same file name like the subject

 

   Please ensure that your SMTP server is configured correctly by using transaction: SCOT.

    Example of a PDF document which have been send:

   
 

    Own layout (attributes, text fields, etc.) can be defined by the creation of a specific SMARTFORM. 

2.5 SLA REPORTING & MONITORING

The following chapter handles an introduction about the reporting and monitoring capabilities of SLA parameter. For example this could support IT Service Managers to get a summarized overview about all ongoing incident messages in their department and to fulfill their key performance indicators (KPIs) as well as to prevent SLA infringements in the future (trend analysis).

2.5.1 Standard ITSM Monitoring

The ITSM includes an integrated monitoring functionality which can be used to list all incidents according to specific IRT and MPT parameter.

 

  The following example explains how the Standard ITSM Monitoring can be used to present all incidents which are in status “MPT Warning”. Thus, the IT Service Manager gets a quick overview of all endangered SLAs: 

  • Open CRM Web Client UI using transaction: SM_CRM
  • Select “Incident Management” from the side menu
  • Click on “Incidents” within the “Search” section


  • Start incident search with certain parameter:
  • Status = MPT Warning    

The Result List contains all  incidents which match the filter criteria

Click on button “Open Chart” to display the result in a pie or bar chart.

 

Move the mouse over a subset

  • Amount of incidents belonging to this subset is displayed
  • Click on this subset for presenting all related incidents in the Result List

 

 

2.5.1 ITSM BW Reporting

The ITSM BW Reporting is just described very roughly in this chapter as it is described more in detail (prerequisites, general setup, customizing activities, terminology explanation, etc.) in the ITSM Analytics guide.

 

This guide can be found at the SAP Service Marketplace:

 

   The following example shows how SLA relevant reports of ITSM BW Reporting can be presented:

  • Open Web Client UI with transaction: SM_CRM
  • Select “Incident Management” from the side menu
  • Click “ITSM BW Reporting” within the “Reports” section
  • Choose “SLA” from “Incidents” tab for creation of SLA relevant reports and define the time period for which the data should be presented within the report

  • SLA relevant report with IRT and MPT information is created 

 

 

2.5.3 ITSM BW Dashboard

SAP Solution Manager 7.1 offers a dashboard framework with a set of predefined standard apps. The dashboard apps are fully configurable and can be customized to customer requirements. They present data coming from BW of SAP Solution Manager as well as the status of individual KPIs for monitoring and optimization purposes.

 

Starting ITSM BW Dashboard:

  •  Open CRM Web Client UI using transaction: SM_CRM
  • Select “Incident Management” from the side menu
  • Click “ITSM BW Dashboard” within the “Reports” section

 

Following SLA relevant ITSM BW Dashboard is currently available:

  • Quality App for Incidents

 

 

The ITSM BW Dashboard is described in more detail (configuration, terminology explanation, etc.) in the ITSM Analytics guide.

This guide can be found at the SAP Service Marketplace:

Installation & Upgrade Guides > Sap Components > SAP Solution Manager > Release 7.1 > 6 Additional Guides

2.5.4 Interactive Reporting

CRM Interactive Reporting is a wizard-based tool for quick creation of CRM-interactive real-time reports for IT Analytics Professionals.

 

Features:

  • Leading edge user interface leveraging Adobe Flex
  • Drill down/through
  • Navigate to Overview pages
  • Export to MS Excel
  • Reports show real-time data
  • Deployment of reports to individual employees or organizations
  • Support of tables and graphical charts (Column Chart, Line Chart, Pie Chart, Bar Chart, Stacked Column Chart)
  • Easy to use creation / editing wizard with report preview

 

 

 

 

The Interactive Reporting is described more in detail (prerequisites, general setup, customizing activities, terminology explanation, etc.) in the ITSM Analytics guide.

The ITSM BW Dashboard is described in more detail (configuration, terminology explanation, etc.) in the ITSM Analytics guide.

This guide can be found at the SAP Service Marketplace:

Installation & Upgrade Guides > Sap Components > SAP Solution Manager > Release 7.1 > 6 Additional Guides

2.6. Additional Information

Detailed guides in regards to ITSM configuration can be found at http://service.sap.com/instguides

→ Sap Components → SAP Solution Manager →Release 7.1 → 6 Additional Guides

3. OLA & UC Management via Processing Times

3.1 Visualization of relevant Service Times in Web UI

To see Processing times block you needed to activate it in CRM Web UI: aic_incident_h > CRM_SRCL_H:

In following the Incident assignment block of the feature Processing Times is described:

  • Here you see the whole setting of a service clock

The columns in the list view represent service clock attributes such as:

  • The Clock Description

  • The Threshold Indicator

  • The Clock Owner

  • The Clock Status

  • The percentage of the reached end date

  • The planned time and duration information

  • The actual time and duration information

  • The time of the reached threshold percentage is stored in the threshold section

The SLM data can be used for following purposes:

  • Collect empirical values to improve your service portfolio and to have a valid data basis for your contract design
  • Optimize your services and the collaboration of your service teams
  • Monitor the response times within your service organization
  • Control the compliance with the agreements you have made with partners
  • Optimize the scheduling of your workforce planning
  • Informing the processors of services at a glance that critical thresholds have been reached

3.2 Prerequisites

For enabling the feature of Processing Times in the SAP Solution Manager, the related Business Function has to be activated:

  • Call transaction: SFW5 
  • Set the planned status for Business Function CRM_ITSM_PROCESS_TIMES_MGMT
  • Press button Activate Changes

 

3.3 Setup of Processing Times

The setup of processing times is explained by using an use case for underpinning contracts.

3.3.1 UC Use Case Description

An end user has some issue with the related equipment. 

The issue is reported by creating an incident. The incident has been classified as an IT-related issue and was forwarded to the responsible support team.

An internal analysis by the IT Infrastructure team is performed.

The root cause of the issue is identified as an hardware defect.

The support employee calls the responsible equipment vendor.

Both parties have contracted a Pick up & Return service for crucial equipment types.

Within the 'Processing Times' assignment block the time for pick up the device is measured.

The equipment vendor is picking up the device...

... and repaired it accordingly.

Afterwards the device has been returned to the customer. The time for whole return process is measured.

The end user is getting back the repaired device and the related incident can be finished.

 

3.3.2 Processing Times IMG Activities

The main configuration steps can be performed via dedicated IMG activities - please call transaction: SPRO and navigate to following IMG node: Settings for Management of Processing Times

  • SAP Solution Manager Implementation Guide → Customer Relationship Management → Transactions → Settings for Service Requests → Settings for Management of Processing Times

 

 

3.3.3 Processing Time Types

Define a new Processing Time Type for Underpinning Contracts:

  • Navigate to sub node Basic Settings
  • Start activity Define Processing Time Types

 

 

  • Create following new entry 
    • UC - Underpinning Contract 

 

3.3.4 Processing Time Owners

Define a new partner type for external suppliers:

  • Navigate to sub node Basic Settings
  • Start activity Define Processing Time Owners

 

 

  • Create a new entry for the Hardware Vendor - HARDWARE_VENDOR

 

 

   In this example a new Partner Function has been created Z0000001 - Hardware Vendor. This Partner Function has been assigned to the Incident's Partner Profile (ZMIN0001) as well as to the overview page as an input field for the Business Partner ID.  

 

 

  • Assign the Business Partner of the external supplier to the newly created Processing Time Owner

 

 

3.3.5 Status Categories for Processing Times

Define status categories which are used to start & stop service clocks:

  • Navigate to sub node Basic Settings
  • Start activity Define Status Categories for Processing Times

 

 

  • Create 2 new entries:
    • IN_PROCESS_EXT
    • SENT

 

 

  • Map the newly created status categories to the related user status of the Incident

 

 

 

 

   In this example the Incident's Status Profile (ZMIN0001) has been extended with additional status values which should signalize that the external party is involved in the incident resolution process. Those status values are also used for UC time calculations.  

 

 

  • Please check also the other status categories as following as they are used for changing the service clock status:

 

 

 

 

 

 


 

   Please ensure that there are no statuses which are maintained 2 times in the different Status categories. I.E. in example above status E0008 (Closed) Maintained in Statuses "Completed" and  "Confirmed". This is not correct, and some of the conditions would not recognise E0008 in "Confirmed" status. You can use table CRMC_SRCL_STCTMP to check that statuses are maintained only once.

3.3.6 Processing Time Service & Response Profile Settings

Define the Valuation Base:

  • Navigate to sub node Valuation Bases

 

 

3.3.6.1 Service Profile

  • Start activity Define Processing Time Service Profile 

 

 

  • Create a new Service Profile which reflects the availability times of the defined Underpinning Contract with the vendor required for service clock time calculation 
  • In this example, the agreement has been negotiated for 8 hours service availability (from 9 am to 5 pm) per working day

 

 

3.3.6.2 Response Profile

  • Start activity Define Processing Time Response Profile 

 

 

  • In this example, the response times for Initial Reaction and Maximum Processing in regards to the Incident priority have to be measured
  • For that, 2 related response profiles have been created
    • UC_IRT
    • UC_MPT 

 

 

  • Assign the contracted durations for every Incident priority which is required for the IRT calculation.

 


  • Based on the entered Time Units Processing time block will show time in Hours minutes or seconds (if no time unit is entered), this functionality introduced with note 2254340:



  • Assign the contracted durations for every Incident priority which is required for the MPT calculation

 

 

3.3.7 Determination Procedure for Response Times

This activity is required in case that a Service and Response Profile is assigned explicitly to a Business Partner ID.

Meaning: you have several different contracts with different vendors or suppliers.

  • Start activity Determination Procedure for Response Times

 

 

  • Create a new determination procedure and define the access sequence for profile determination. For BP-based determination the related entry needs to be included in the access sequence.

 

 

Assign this procedure to your Incident transaction type (e.g. ZMIN)

  • Start transaction CRMC_PROCESS_MA
  • Choose the used Incident transaction type
  • Double-click Assignment of Business Transaction Categories
  • Select entry Service Process
  • Double-click Customizing header
  • Define the created determination procedure

 

 

Assign your defined profiles to the supplier's Business Partner

  • Start the Web UI via SM_CRM
  • Navigate to the Account search in workcenter Master Data 
  • Open the Business Partner
  • Define the Service & Response Profile in assignment block Service Levels


 

3.3.8 Conditions &  Actions

3.3.8.1 Introduction

Conditions and actions are required for calculating timestamps and durations.

In following, the relationships of actions and the related time and duration information displayed within the Web UI are introduced by using an example.

Action Set for Time and Duration Calculation 

Following actions arranged in one action set are responsible for calculation of time and duration information:

  • SLA_IRT_CALCULATE_DATES

 

Related Web UI fields 

Action Set for Service Clock Status

Following actions arranged in one action set are responsible for changing the status of the service clocks:

  • SLA_IRT_SET_STATUS

 

Related Web UI fields 

In general Duration calculation follows below rules:

  • To set the dates and durations, Global agreement should be fulfilled:
    • Global agreements evaluated for all Service Clock attributes (except Status)
    • Calculations of the Service Clocks attribute performed when:
    • (Service Clock Status changed from "Intial" to "Running" ) OR
    • (Service Clock Status changed from '' to "Running" ) OR
    • (Service Clock Status changed AND old Service Clock Status <> "Initial" AND old Service Clock Status <> '' ) OR
    • (Service Clock Status not changed AND Service Clock Status = "Running" )
  • Actual start date: set when Global agreements are met + 
    • Not performed when Actual Start has already a value
  • Actual End date: set when Global agreements are met +
    •  Perform when: Old Service Clock status equals to Running OR 
    •  New Service Clock status equals to Running
    • Actual end cleared when service clock status = Running
  • Paused duration calculation performed when Global agreements are met +
    • Perform when Service Clock status changed from Paused to any status
    • Definition : Paused Duration(PSD) = Previous Paused Duration(oldPSD) + Current Paused Duration  
    • Current paused duration = Now - Actual End(AE)
  • Actual duration: calculation performed when Global agreements are met +
    • Perform when: Old Service Clock status equals to Running OR *              
    • New Service Clock status equals to Running
    • Actual duration will be cleared when service clock status = Running
    • Definition Actual Duration = ( Actual End(AE) - Actual Start(AS) ) - Paused Duration(PSD)
  • Actual duration RT: calculation performed when Global agreements are met
    • Definition : Actual Duration at Runtime(ADR) = (current time - Actual Start) - Paused Duraction (PSD)

All of the above rules, and the once which are not mentioned here, can be seen in the corresponding classes of package CRM_SERVICE_CLOCKS  

Action Set for Thresholds

Following actions arranged in one action set are responsible for updating the threshold information:

  • SLA_IRT_UPDATE_THRESHOLDS

 

Related Web UI fields 

 

IMG Activities

Conditions and actions can be defined in sub node Adaption of Time Calculation Rules 

 

  

3.3.8.2 Conditions

This activity is required to define customer-specific condition sets which are used for the following purposes:

  • Time and duration calculation
  • Changing the status of service clocks
  • Updating threshold information 

 

A condition set can include several conditions

  • Start activity Set Up Conditions

 

  • In this example, 4 use-case-specific condition sets have been defined:

 

 

ZCNDS000001

  • Status = In Process by External Party

 

 

ZCNDS000002

  • Status = Sent to External Party

 

 

ZCNDS000003

  • Status = In Process (by internal support)

 

 

ZCNDS000004

  • Status changed from In Process by External Party to In Process (by internal support)

 

 

3.3.8.3 Action Sets

This activity is required to define customer-specific action sets which are used for the following purposes:

  • Time and duration calculation
  • Changing the status of service clocks
  • Updating threshold information 

 

An action set includes several actions

  • Start activity Define Action Sets

 

  • Create action sets for the UC scenario by copying existing entries of IRT and MPT action sets.

 

 

 

Adapt the included actions with the newly defined condition sets:

IRT - Time and Duration Calculation

  • ZCNDS000001 - Status = In Process by External Party
  • ZCNDS000002 - Status = Sent to External Party

 

 

IRT - Changing Service Clock Status

  • ZCNDS000001 - Status = In Process by External Party
  • ZCNDS000003 - Status = In Process (by internal support)

 

 

IRT - Update Threshold Information

  • ZCNDS000002 - Status = Sent to External Party 

 

 

MPT - Time and Duration Calculation

  • ZCNDS000001 - Status = In Process by External Party
  • ZCNDS000002 - Status = Sent to External Party
  • ZCNDS000004 - Status = Status changed from In Process by External Party to In Process (by internal support)
 

 

MPT - Changing Service Clock Status

  • ZCNDS000002 - Status = Sent to External Party
  • ZCNDS000003 - Status = In Process (by internal support)
  • ZCNDS000004 - Status = Status changed from In Process by External Party to In Process (by internal support)

 

 

MPT - Update Threshold Information

 

 

  You can set up the trace for the conditions which you have configured. For this you need to set su3 parameter SRCL_TRACE_ON = X for your user, and with user parameter SRCL_TRACE_CLOCK_ID, you can restrict the tracing to a specific processing time ID. Then use the report CRM_SRCL_TRACE to analyse the trase.

  Trace data will be stored to the following tables: CRMD_SRCL_TR_HD, CRMD_SRCL_TR_ACS, CRMD_SRCL_TR_FLW - which can grow really big. If this would happen, you can just delete the content of this tables.

3.3.8.4 Action Flow

Action sets have to be bundled to an action flow:

  • Start activity Set Up Action flow for Processing Times

 

 

Create 2 new entries for the UC scenario:

  • UC_IRT_FLOW
  • UC_MPT_FLOW 

 

Assign the related action sets for IRT and ...

 

 

... MPT handling.

 

   Please be aware that the sequence of the action sets are extremely important here, and during the definition of the actions set. I.E. if you put Processing Time status after Dates calculation, then Current Paused Duration, used in PSD, would be calculated with Actual End(AE)=Now or Current Paused Duration = Now - AE = 0

3.3.9 Processing Times

3.3.9.1 Define Processing Times

After creating all required profiles, they have to be arranged together to a 'Processing Time':

  • Time Type
  • Service Profile
  • Response Profile
  • Processing Time Owner
  • Action Flow
  • Threshold Profile
  • Determination Procedure

Start activity Define Processing Times

Create 2 processing times with all related profiles:

  • UC_IRT
  • UC_MPT 

 

 

 

3.3.9.2 Define Processing Times Profile

Finally, the processing times which belong together have to be put into one single profile which can be assigned later on to your Incident transaction type.

  • Start activity Define Processing Times Profile

 

 

 

 

3.3.9.3 Assignment to Transaction Types

The processing time profile has to be assigned to your Incident transaction type (e.g. ZMIN).

  • Start activity Assign Processing Times Profiles to Transaction Types

 

 

 

    Only 1 Processing Time Profile can be assigned to 1 transaction type.

3.3.10 Threshold Update Report

The report CRM_SRCL_THRESHOLDS_UPDATE is responsible for updating the threshold and time information within assignment block Processing Times. This report should be scheduled on periodical basis as a background job.

Please check following notes in case of any issues with this report: 

  • 2301141 - CRM_SRCL_THRESHOLDS_UPDATE - performance improvement of the email notification
  • 2191551 - Processing Time: Report CRM_SRCL_THRESHOLDS_UPDATE not updating thresholds.

3.3.11 Scenario Demo

A new Incident has been created by Julie. 

In this scenario with the assignment of the affected configuration item the responsible Hardware Vendor is automatically determined. 

 

 

At the moment the Processing Times for OLAs and UCs are not calculated as the defined status condition is not yet fulfilled.

 

 

The message processor identified an hardware defect.

The internal support organization does have a signed contract with the hardware vendor regarding a Pick up and Return service.

The actual message processor is calling the maintained hardware vendor and performs a status switch to measure the negotiated Pick up time of the underpinning contract (UC).

 

 

The Processing Times for Pick up and Return have been initialized and set to status Running.

The Planned Duration of the clock profile is maintained and the Planned End Date is calculated accordingly.

 

 

After a while the threshold information of the clock is getting updated.

Detailed threshold information for the warning and exceeded clock status is displayed as well as the related timestamps of occurrence.

The timestamp for reaching the 80% mark is recorded.

 

 

The hardware vendor has picked up the device from the IT department.

To stop the related running clock the status has to be changed by the message processor.

 

 

With the status change the service clock has been Stopped.

Furthermore, the Actual Duration as well as the Actual End Date have been set.

The timestamp of the 100% mark has not been set which means that the threshold has not been exceeded and the hardware vendor fulfilled the agreement.

 

 

The hardware vendor has returned the repaired device and the support organization takes the incident back in process.

 

 

With the status change the service clock has been Stopped.

Furthermore, the Actual Duration as well as the Actual End Date have been set.

The timestamps for the warning and exceeded clock status have not been set which means that the hardware vendor fulfilled the agreement.

 

   Stored UC times can be also checked in CRMD_SRCL_H table.

3.4 SAP Notes

Please have a look to following SAP notes in case that you encounter any issues: 

  • 1956304 - Deleting Incidents/Problems with CRM_ORDER_DELETE, Proc.Time entries remain
  • 1798319 - ITSM Processing Times - 1O Event Callbacks
  • 1799577 - ITSM Processing Times - Wrong cardinality in BOL model rel.
  • 1893248 - Termination POSTING_ILLEGAL_STATEMENT in SAPLCRM_SRCL_H_DU
  • 2014033 - Error in mapping of 'Processing Time' datasource
  • 2046638 - All clock actions are processed if no clock in customizing
  • 2301141 - CRM_SRCL_THRESHOLDS_UPDATE - performance improvement of the email notification
  • 2191551 - Processing Time: Report CRM_SRCL_THRESHOLDS_UPDATE not updating thresholds.
  • 2254340 - ITSM Processing Times - Durations are not displayed using the time units defined in the Response Profile
  • 2188324 - ITSM Processing Times - Planned Duration display is not using the time units defined in the Response Profile

 

Notification Framework: 

  • 1819097 - ITSM duplicate entries in IMG for Notification Framework
  • 1818151 - ITSM Enhancement - Setup of Notification Framework
  • 2237536 - Notification on threshold level are not sent
  • 2225490 - Notification on threshold level is sent multiple times
  • 2271272 - Notification Framework: Able to save Subscriptions with filter on "Threshold Level" and none on "Processing Time"

 

 

 


  • No labels