News: Content of this SCN Doc will be maintained now in wiki page https://wiki.scn.sap.com/wiki/x/Vo_rGg

 

Purpose

 

With the following hints you will be able to configure the use of Service Level Agreement SLA to make sure that messages are processed within the defined period of time.

For configuring SLA you should get this document SLA Management from SAP SMP.

 

Here I will try to give you some hints for SLA configuration.

 

The screenshots are taken from a Solution Manager 7.1 SP05 with a Incident Management standard scenario configuration.

 

Overview

 

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.

 

Definitions

 

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.

 

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.

 

 

Step 1. Copy transaction type SMIN -> ZMIN

 

We are going to work with ZMIN transaction type.

Insist here on the fact that you should copy all transaction types into your own namespace or <Z>, <Y> namespace before starting to use Incident Management, copy transaction types, copy status profiles, action profiles, etc…if not your modifications to the standard will be overwritten after the next support package import. This is really important in Solman 7.1!!!

 

After each Support Patch applications you have the option to use report AI_CRM_CPY_PROCTYPE “Update option” to update already copied transaction types with new shipped SAP standard configuration.

 

 

Step 2. Define Service Profile & Response Profile

 

Transaction: CRMD_SERV_SLA (/nSPRO ->SAP Solution Manager IMG -> SAP Solution Manager -> Capabilities (optional) ->Application Incident Management (service Desk) -> SLA Escalations ->Edit Availability and Response Times)

Example:

 

Factory calendar must be a valid one, see transaction /nscal and notes 1529649 and 1426524.

 

Note: The usage of Holiday calendar in availability time is not supported by SLA date calculation i.e. you MUST use the option “Factory Calendar” or “All Days Are Working Days”.

Pay attention to the System time zone & user time zone. Check in STZAC (note: 1806990).

 

Create a response profile:

I would suggest to maintain the times always in MIN.

Make the same for all priorities.

 

3. Define SLA Determination Procedure

 

SM34 : CRMVC_SRQM_SDP (SPRO -> SAP Solution Manager IMG ->SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations -> SLA Determination Procedure)

 

Create your own SLA determination procedure:

 

What is important here is to determine where are the response profiles and service profiles to check first, there are several alternatives:

Possible access sequence:

 

 

– Service Contracts

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.

 

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

 

– 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

 

The most frequently used are the SLA determination via Service Product item and Business Partners (sold-to party).

 

If you need your own SLA determination check BAdI Implementation CRM_SLADET_BADI  (IMG: Customer Relationship Management -> Transactions -> Settings for Service Requests -> Business Add-Ins -> Business Add-In for SLA Determination).

 

Now check that you linked this new SLA Determination procedure to ZMIN

 

4.Define Settings for Durations

 

Specify the times to be recalculated when the status changes, under “Specify Duration Settings”.

 

SM30: CRMV_SRQM_DATSTA (/nSPRO-> SAP Solution Manager IMG ->SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations ->Define Settings for Durations)

 

Note 1674375 is having two attached files indicated entries to be inserted and to be deleted.

 

For solman 7.1 until SP04 included these should be the standard entries:

 

For SP05 and above these are the default entries:

 

Date profile is not the data profile of the ZMIN transaction type, this is the date profile of the item category used, usually SMIP, we will see details about this in Step 9.

 

Note: For SMIV incidents in VAR scenarios status E0010 Sent to Support  means that the incident is at solman side so the correct entries are:

Status Profile Status Date Profile Duration type                     Date type

ZMIV0001 E0010 Sent to Support SMIN_ITEM SRQ_TOT_DUR
ZMIV0001 E0010 Sent to Support SMIN_ITEM SRQ_WORK_DUR

 

As summary, if the status means that the incident is at processor side the correct entries are:

Status Profile Status Date Profile Duration type        Date type

XMIX0001 E000X SMIX_ITEM SRQ_TOT_DUR
XMIX0001 E000X SMIX_ITEM SRQ_WORK_DUR

If the status means that in the incident is at  key user side the correct entries are:
Status Profile Status Date Profile Duration type Date type
XMIX0001 E000X SMIX_ITEM                          SMIN_CUSTL
XMIX0001 E000X SMIX_ITEM SMIN_CU_DURA
XMIX0001 E000X SMIX_ITEM SRQ_TOT_DUR
XMIX0001 E000X SMIX_ITEM SRV_RR_DURA
See the meaning of the Duration fields:

– 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”.

 

 

See the meaning of Date Types fields:

 

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

 

 

Step 5. Specify Customer Time Status

 

/nSPRO -> SAP Solution Manager IMG -> SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations -> Specify Customer Time Status

 

Identify non-relevant customer times in the step “Specify Customer Time Status”. That means the clock is stopped while time is spent in these statuses.

 

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.

 

Step 6. Create a product

 

If you decide to use the SLA determination based on Service Product Item you need to create a product.

Product INVESTAGATION will be created automatically when you perform in solman_setup for ITSM activity Create Hierarchy for Service products.

Execute transaction COMMPR01, find product ID  INVESTIGATION.

 

Note: Use Unit of Measure MIN

That avoids errors which could be caused be  time rounds.

Ensure that SRVP is entered in the Item Cat. Group:

Enter your service and response profiles.

 

Step 7. Check the Item Categories

 

SM34: CRMV_ITEM_MA  ( /nSPRO IMG -> CRM -> Transactions -> Basic Settings -> Define Item Categories)

You can use SRVP:

 

Step 8. Check the Item Category Determination

 

SE16:   CRMC_IT_ASSIGN (/nSPRO IMG -> CRM -> Transactions -> Basic Settings -> Define Item Category Determination)

You should see the relation between ZMIN, SRVP and SMIP.

 

 

Step 9. Check SMIP Item category

 

/nSPRO IMG -> CRM -> Transactions -> Basic Settings -> Define Item Categories

Pay attention to the Date Profile.

 

With these settings the SLA times (IRT and MPT) will be calculated for any created incident message according to the parameters set within “Investigation”.

 

 

Step 11. SLA Escalation

 

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

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.

 

Report AI_CRM_PROCESS_SLA is responsible for setting the warning/escalated status values once these thresholds are exceeded.

So firstly ensure that your incidents are receiving the correct status values (IRT/MPT warning/escalated).

 

Note that these are “additional” status values, which are not reflected in the main status of the incident. To view these status values, make the “Status” assignment block visible in the CRM UI, or view the Incident in the old CRMD_ORDER transaction.

 

If your incidents are not receiving the correct status values, the e-mail actions will not function correctly.

 

Then ZMIN_STD_SLA_IRT_ESC/ZMIN_STD_SLA_MPT_ES are intended to be scheduled based on the status of the incident, not directly on the evaluation of the respective durations.

 

11.1. Maintaining SLA E-mail Actions

In the standard SMIN_STD profile delivered by SAP, the following actions (smartform based) are responsible for generating e-mails once escalation conditions have been reached since SP04:

– ZMIN_STD_SLA_IRT_ESC

– ZMIN_STD_SLA_MPT_ESC

Please see the scheduling/starting conditions to ensure that they are appropriate for your customized transaction type ZMIN and ZMIN_STD action profile.

 

If you need to send also emails at warning times you will need to create actions:

 

– ZMIN_STD_SLA_IRT_WRN

– ZMIN_STD_SLA_MPT_WRN

 

Use the same settings than for the shown actions *ESC, the only difference is in the Start condition that you need to use IRT_WRN and MPT_WRN that do not exists by default, for fixing this:

1. Open BAdI implementation AI_SDK_SLA_COND in t-code SE19.

2. Change to Edit mode and deactivate this BAdI implementation.

3. Add Filter Values “IRT_WRN” and “MPT_WRN”.

4. Save and activate the BAdI implementation.

Then, you will be able to select IRT_WRN / MPT_WRN from the start condition list.

 

11.2. Schedule SLA Escalation Background Job for triggering Email Notifications

 

Since SAP Solman 7.1 SP04:

/n SPRO -> SAP Solution Manager IMG -> SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations -> Schedule Escalation Background Job

 

Schedule a job for report AI_CRM_PROCESS_SLA running every 10 minutes for example.

This job is updating the SLA data for the incidents setting the additional user statuses (IRT Exceeded/IRT Warning/MPT Exceeded/MPT Warning).

 

Note: It could happen that in sm_crm->Incident search the search result shows for example IRT warning at IRT Status text for an incident, however in the incident itself this additional status is not set. The search is making his own calculation. But the emails are only triggered when the status is really set by
this report in the incident document.

 

Before SAP Solman 7.1 SP04 you need to schedule report RSPPFPROCESS.

 

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

 

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

 

 

Step12. Activate SLA Escalations

 

/nSPRO -> SAP Solution Manager IMG -> SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations -> Activate SLA Escalations

 

In transaction DNO_CUST04 set the attribute SLA_ESCAL_ACTIVE to ‘X’

 

Related Content

Related Documentation

SLA Management guide

 

Related Notes

Always check the SLA notes relevant for your patch level and ensure that you have implemented the latest version of the notes.