SLA Commitments

SLA stands for Service Level Agreement and outlines a commitment between a two parties, most commonly a service provider and a customer, including details of the service, the standards the provider must adhere to, and the metrics to measure the performance.

The SLA Commitments are used to ensure that the Service Provider delivers the agreed upon services within the customer committed timeframe, but they can also be used for internal purposes, such as tracking KPIs, ensuring that a Request is Invoiced in time or to schedule work.

Event driven SLA Commitments

The events used for the SLA Commitments are either specific for Requests, Request Scopes, Request Work Tasks or not specific to any entity at all. These events can either be used to set the base date that will be used for the calculation of Due Date or to set the fulfillment date of the SLA Commitment.

More information about events can be found in About Event Management.

Manual and Template created SLA Commitments

SLA Commitments can either be created based on an SLA Template and Template Lines or manually. The SLA Templates can be defined on:

• Warranty
• Contract
• Contract Urgency
• Service
• Service Urgency
• Service Organization

Each Template Line can be used to create one or more SLA Commitments. For example if multiple Request Work Tasks are created on a Request, a single Template Line can be used to create an SLA Commitment for each of the Request Work Tasks. In addition to the SLA Commitments created from Template Lines, manual SLA Commitments can be added in addition. The manually added SLA Commitments can, similar to SLA Commitments created from Template Lines, be added to a Request, Request Scope or a Request Work Task. Multiple SLA Commitments can be created for the same Request, Request Scope, and Request Work Tasks and the same event can fulfill one SLA Commitment and trigger the Due Date calculation of another.

Manually created SLA Commitments can be set up to either have its due date calculated from a fixed start date, the due date to be on a specific date, or to be event driven in the sense that one event trigger the Due Date calculation for the SLA Commitment and another event is used to determine it was fulfilled in time.

SLA Start Dates for Template Lines

The SLA Start Dates are set in 3 different ways when SLA Commitments are created from an SLA Template.

• For a Request, Request Scope and Work Task, the SLA Start Date will be set to the creation date of the Request.
• For a Request, Request Scope and Work Task created from Recurring Services the Request Reg Date / Recurring Service Due Next Date will be set as the SLA Start Date.
• If a Triggering Event (Start Event) is defined on the Template Line, the SLA Start Date is set when the Event is created.

If a Request is created manually and an SLA Template is used, the Request Creation Date will be used as the SLA Start Date, assuming no Triggering Event has been specified.

If a Request is generated from a Recurring Service and an SLA Template is used, the Due Next Date (also visible on the Request as the Reg Date) will be used as the SLA Start Date, assuming no Triggering Event has been specified.

If a Request is created manually or through a Recurring Service and an SLA Template is used, where Triggering Event(s) are defined, the SLA Start Date will be set when the Triggering Event occurs. The lines will be created in status Planned if the triggering event has not yet occurred.

Status handling

• Planned - The initial state of the SLA Commitment. The commitment is Planned if no due date has been set.
• Active - When the SLA Commitment has a due date set and the fulfillment event has not yet occurred. For example, when SLA Commitments are created manually with the To Date or the From Date configuration, the status will be Active initially. If an SLA Commitment was created From Event, the status will change from Planned to Active when the triggering event occurs.
• Closed - When the fulfillment event occurs, the status will change to Closed. It does not matter if this occurs before or after the Due Date.
• Cancelled - If the entity (Request, Request Scope, or Request Work Task) triggering the start criteria or the fulfillment criteria of an SLA Commitment has been cancelled, the SLA Commitment will also be set to cancelled. This can also be manually set for Active SLA Commitments.

Status Handling according to already occurred events

For SLA Commitments from Template,

• If triggering event has already occurred, SLA commitment will be created in Active Status and SLA dates will be set accordingly.
• If Fulfillment event has already occurred SLA commitment will be created in Closed Status and SLA dates will be set accordingly.

For Manual SLA Commitments,

• If triggering event has already occurred SLA commitment will be created in Active Status and SLA dates will be set accordingly.
• If Fulfillment event has already occurred : User can create the SLA commitment in closed status or else after creation they do have the option to Fulfill it later.

Progress

The Progress of an SLA Commitment shows if an SLA Commitment is Pending, Ongoing, Overdue, Fulfilled, Exceeded or Cancelled.

• Pending: The initial state, when the Starting Criteria has not yet occurred.
• Ongoing: When the Due Date has been set, while neither Fulfillment Event nor Due Date has been reached.
• Overdue: When the SLA Commitment is overdue. If the Due Date has been passed and the fulfillment has not yet occurred.
• Fulfilled: When the Fulfillment Criteria was reached before the Due Date.
• Exceeded: When the Fulfillment Criteria was not reached before the Due Date.
• Cancelled: When the SLA Commitment is no longer valid.

Manually Add SLA Commitments

Manually adding SLA Commitments will be available through an assistant directly from the Request, Request Scope or Request Work Task.

When opening the Add SLA Commitment assistant, it is needed to define the Duration from the current time to when the due date for the SLA Commitment is, the calendar used for the calculation, as well as to define what event will trigger the fulfillment of the SLA Commitment, for example when a Request Scope changes status to Completed. This will allow the user to add an SLA Commitment to a Request, Request Scope or Request Work Task by simply filling out three fields:

• Duration
• Calendar
• Fulfillment Event

Customer Commitment and Commitment Type

SLA Commitments can be created for different purposes, e.g. measuring KPIs for internal purposes or as agreements with customers. To help keep track of this it will be possible to define with whom the commitment is. If it is committed to a customer, the Customer Commitment toggle should be activated. This will be visualized as badges (Customer Committed, Internal Only) in all other pages

Commitment Description

The Commitment Description is an optional field used to describe the SLA Commitment.

Entity and Entity Reference

Depending on from where the Add SLA Commitment assistant is opened, these fields will be auto-fetched differently:

• Applied to: If the SLA commitment should be created for a Request, Scope or a Task.
• Reference: What Request, Scope or Task the SLA commitment should be added for.
• Triggering Entity: If a Request, Scope or Task that should trigger the fulfillment event.
• Triggering Entity Reference: What Request, Scope or Task should trigger the starting criteria.
• Fulfillment Entity: If a Request, Scope or Task that should trigger the fulfillment criteria. This will be the same as in Applied to.
• Fulfillment Entity Reference: What Request, Scope or Task should trigger the fulfillment event. This will be the same as Reference.

If the Add SLA Commitment assistant is opened from the Request level, the Request information will be auto-fetched into these fields, if it is opened from the Scope level, the Scope information will be auto-fetched, and similarly for the Task level.

There are three options of configuring an SLA Commitment:

• From Date: When the Due Date is calculated based on a start date and a duration.
• To Date: When the Due Date is manually set.
• From Event: When a starting criteria is defined to trigger the calculation of the Due Date.

Configuration: From Date

When the Setup is set as From Date, the following fields will be visible:

• Start Date: The default Start Date will be set to the time when the assistant is opened in the time zone of the Work Owning Site, with the option to modify. This is the date from where the Due Date is calculated.
• Duration: This is set to the Duration between the Start Date until the Due Date.
• Time Unit: Is set as Hours as default and can be changed to Minutes or Business Days.
• Calendar: Is as default set to the calendar defined for the Maintenance Organization, but can be changed.

Configuration: To Date

Setting up manual SLA Commitments for Requests, Request Scopes, and Request Work Tasks can be done by defining the Due Date directly. This is enabled by selecting To Date option in the configuration. To create an SLA Commitment with To Date as configuration option the Due Date is manually set.

Configuration: From Event

Another option of setting up manual SLA Commitments for Requests, Request Scopes, and Request Work Tasks can be done by defining a triggering event from which the Due Date should be calculated from. This is done by selecting the From Event option in the configuration and filling out these fields:

• Duration: This is set as the Duration between the Start Date until the Due Date.
• Time Unit: Is by default set to Hours and can be changed to Minutes or Business Days.
• Calendar: Is by default set to the calendar defined for the Maintenance Organization, but can be changed.
• Cutoff Type: Does by default not contain a value, but can be set as Time or Next Day. Selecting Cutoff Time will enable the fields Cutoff Time and Cutoff Time Unit and is when the user wants to manually define the time after which an Due Date will not be calculated. Another option is Next Day. It will always calculate the Due Date from the next business day, without considering the remaining time of the reference day.
• Cutoff Time: The time remaining of a day after which a Due Date will not be calculated.
• (Cutoff) Time Unit: The time unit used together with the time to determine after which an Due Date will not be calculated.

Work Task Applicability

Work task applicable setup is used to define what work tasks can use the SLA commitment for execution due date. It can be also use to schedule work task if the Scheduling SLA type is defined.

It is possible to manually create connections between work tasks and SLA Commitments through Add SLA Commitment command and SLA Commitment Page. The following parameters can be used,

• Work Task Applicability which is used to specify whether the SLA commitment is used to set the execution due date of work tasks. 
  • Scheduling SLA Type specifies which Scheduling SLA Type to use. This will be connected to the SLA Commitment. Each Scheduling SLA Type defines the SLA curve shape used by the scheduling engine. The Scheduling SLA Types are part of the Scheduling Basic Data. If there are inherited connections with work tasks and scheduling SLA type, connected to an SLA Commitment, then the SLA commitment will be used to schedule the work task.
  • Start Based defines whether the start of the Work Task must be scheduled within the defined SLA period or not.

When SLA Templates create the SLA Commitments, and there is an SLA Template Line flagged as Work Task Applicable the following logic applies.

1. Work Task applicability defined on SLA Commitments with Fulfillment Entity Request will be applied to all Work Tasks created for the Scope.
   1. If Task Sub Group set to Work Stage, the SLAs will only be applied to Work Tasks with the corresponding Work Stage defined in Task Sub Group Value.
   2. If Scheduling SLA Type is connected, then the SLA commitment will be used to schedule the work task.
   3. Start Based defines whether the start of the Work Task must be scheduled within the defined SLA period or not.
2. Work Task applicability defined on SLA Commitments with Fulfillment Entity Scope will be applied to all Work Tasks created for the Scope.
   1. If Task Sub Group set to Work Stage, the SLAs will only be applied to Work Tasks with the corresponding Work Stage defined in Task Sub Group Value.
   2. If Scheduling SLA Type is connected, then the SLA commitment will be used to schedule the work task.
   3. Start Based defines whether the start of the Work Task must be scheduled within the defined SLA period or not.
3. Work Task applicability defined on SLA Commitments with Fulfillment Entity Task will be applied to only that Work Task which SLA Commitment is created on.

A few examples on how the Scheduling SLAs are selected:

1. A Request is created with four SLA Commitments (Fulfillment Entity Request), but only two SLA Commitments flagged as Work Task Applicable and a Scheduling SLA Type is connected to the commitments. No SLA Commitments are defined on the Request Scope or the Work Task. The Work Tasks transferred to Scheduling will pick up the two SLAs defined against the Request.
2. A Request is created with two SLA Commitments (Fulfillment Entity Request) flagged as  Work Task Applicable and a Scheduling SLA Type is connected to the commitments. The related Request Scope has two SLA Commitments (Fulfillment Entity Scope) flagged as  Work Task Applicable and Scheduling SLA Type is not connected to the commitments. No SLA Commitments exist on the Work Task. The Work Tasks transferred to Scheduling will pick up the two SLAs defined the Request and will use the two SLAs on request scope level only to set the execution due date of work tasks.
3. A Request is created without SLA Commitments on the Request or the Request Scope and the Work Task (Fulfillment Entity Task) has two SLA Commitments flagged as Work Task Applicable and a Scheduling SLA Type is connected to the commitments. The Work Tasks transferred to Scheduling will pick up the two SLAs defined against the Work Task.

Calculate SLA Due Date

For a manually created SLA Commitment created the Due Date of the SLA Commitment can either be manually set as a fixed deadline, but can also be set to be calculated based on a manually set start date or a triggering event. For when the Due Date is to be calculated, either from a start date or from a triggering event, a duration together with a time unit is required.

• From Date: When the Due Date is calculated based on a start date and a duration.
• To Date: When the Due Date is manually set.
• From Event: When a starting criteria is defined to trigger the calculation of the Due Date.

If the configuration option is From Date

The Due Date is calculated based on a start date, duration, duration unit used together with a calendar.

If the configuration option is To Date

The Due Date is set to a specific date and time i.e. a deadline of the SLA Commitment. The start date will automatically be set as the commitment creation date.

If the configuration option is From Event

The Due Date is calculated from when a starting event occurs. Similar to the From Date option, a duration, a time unit, and a calendar has to be defined. This option also allows the option the set up a cutoff type.

Time Unit

A time unit is in either minutes, hours or business days. Minutes and hours are used together with the working hours defined in the calendar.

The Business Days time unit is considering any day where working hours exists as a business day no matter on how many working hours that might be. The due date of the SLA Commitment will always be set to the end of a business day and 1 Business Day means the end of the next business day. When the Business Days is used, it will not be possible to use cutoff.

Example of Business Days calculations:

If a 8 AM - 5 PM Monday to Friday calendar is considered and the calculation of a due date is triggered at any time on a Monday.

• 1 Business Day: The due date is set to Tuesday at 5 PM
• 2 Business Days: The due date is set to Wednesday at 5 PM
• 3 Business Days: The due date is set to Thursday at 5 PM
• 4 Business Days: The due date is set to Friday at 5 PM
• 5 Business Days: The due date is set to Monday at 5 PM

Cutoff

A cutoff time is the time at the end of a shift after which a start date of an SLA Commitment will not be set. If the remaining time of the workday is less than the cutoff time of the reference date, the start time is set from the next business day. The units of the cutoff time can be hours or minutes. Another cutoff option is Next Day. When this is selected and the triggering event has occurred, the start date of the SLA Commitment will always be set from the next-coming business day.

Edit SLA Commitment

Once an SLA Commitment has been created it can also be edited. There are restrictions to what is possible to edit that is dependent on the status of the SLA Commitment.

If the status is Planned

Editing will be possible without any restrictions.

If the status is Active

It is possible to edit the Commitment Description, change the Customer Commitment / Commitment Type selection, change the Due Date, and change the Fulfillment Entity, Fulfillment Entity Reference and the Fulfillment Event.

If the status is Closed

It is possible to edit the Commitment Description, change the Customer Commitment selection, and change the Commitment Type from the SLA Commitment page.

If the status is Cancelled

All editing is restricted.

SLA Change Handling

SLA commitments created using SLA Templates as well as SLA Commitments created manually will be properly updated based on different changes happen in the Request Scope and Request Work Tasks.

• Adding new work task to the scope which is connected to an SLA Template
  • New Task will be evaluated against the SLA template and new Commitments will be created accordingly.
  • Work Task applicability of SLA Template lines will be evaluated and connections on the new work task will be created if applicable.
• Modify Work stage of the work task
  • Modified Task will be evaluated against the work task applicability of SLA template and connections will be created if applicable.
• Updating Scope Urgency, Contract,  Warranty
  • If New SLA template, revision & Source is not same as the previous SLA template, revision & Source, new SLA commitments are created accordingly.
  • Planned, Active, Stopped SLA commitments of the previous SLA Template will be Cancelled.
  • Already Closed SLA commitments will remain unchanged.
• Modifying a Service / Object - Results a different Scope and Different SLA Template
  • SLA Commitments created using SLA template :
    • New SLA commitments will be created according to the new SLA Template
    • Planned/Active/Stopped SLA commitments of the previous SLA Template will be Cancelled.
    • Upon creation, new SLA Commitments will be updated according to the events of old scope
    • Already Closed SLA commitments will remain unchanged
  • SLA created manually - will be updated if below criteria are satisfied:
    • If the SLA commitment is Active/Planned/Stopped and to be fulfilled by Scope event
    • If the SLA commitment is Planned and to be triggered by scope event but fulfilled by work task/request event (if the work tasks are cancelled, then SLA commitment should be cancelled)

SLA Revision Handling

Revision Handling of SLA Templates provides the possibility of retaining different versions of the same SLA Template. Any SLA Template can be revised without any restriction. Valid From Date should be defined to use SLA Template revisions on Request Scopes. To the Valid From Date,

• can set Current Date and Time: SLA Template Revision can be applied on Request Scopes from now onwards.
• can set Future Date: SLA Template Revision can be applied on Request Scopes after Valid From Date.

The Valid To Date will be automatically updated according to the Valid From Date of the next Revision, resulting a single chain of Revisions with no overlaps and no gaps.

According to the Validity Period, there can be 4 Revision types,

• Current: Current date is within the Validity Period.
• Planned: Validity period is in the Future.
• Out Of Date: Valid To Date has passed.
• Draft: Valid From Date is not yet defined.

When connecting an SLA Template for Request Contract Line, Urgency on Request Contract Line and Warranties, specific revision can be specified on the entity. But Revisions cannot be specified on Service, Service Urgency and Service Organization. If the specific revision is not saved on the entity, 'Current' SLA Template Revision will be applied when Request Scopes are created.

If there is an SLA Template applied on an entity when a scope is created, relevant SLA Template revision is applied on the scope according to the following logic,

• if Revision is saved on the entity, Validity periods will not be checked and that specified Revision will be applied
• if Revision is not saved on the entity, Revision is applied according to the Validity Period.

SLA Delay Handling

Once an SLA Commitment is in Active state, there can be various scenarios, which are not in control of the service provider but will impact SLAs; (e.g. Unplanned power interruptions, Customer unavailability, etc.). In such instances SLA commitments can be,

• Pause and Restart SLA clock - Address the unplanned work interruptions
• Extend the SLA due date - Address pre planned work interruptions

There are separate APIs to Pause, Restart and Extend SLAs.

Pause, Restart Extend will only affect the SLA commitments and will not affect Requests/Scopes/Request Work Tasks.

SLA Overview

The SLA Overview provides an overview of all SLA Commitments on the Request and its connected Scopes or Request Work Tasks and is accessed from Request Details. The SLA Overview is only available when one or more SLA Commitments exist on the previous mentioned entities (Request/Scope or Request Work Tasks). In the calendar, each SLA Commitment is located in correspondence to its Due Date. If the SLA Commitment does not have a due date, it will not appear in the calendar.

The SLA Timeline provides an overview of all SLA Commitments which have connections on a specific Request Work Task and is accessed from Request Work Task pages. In the calendar, each SLA Commitment is located in correspondence to its Due Date. If the SLA Commitment does not have a due date, it will not appear in the calendar

SLA on Request Bundle Tasks

SLA Commitments fulfilled by Request Bundle Tasks

Manually adding SLA Commitments will be available through an assistant directly from the SLA Tab of Request Bundle Task Page. This assistant is similar to Add SLA Commitment assistant of Request/Scope/Work Task with following differences,

• Applied To: Will be restricted only to Bundle Tasks.
• Reference: What Request Bundle Task the SLA commitment should be added for.
• Triggering Entity: Will be restricted only to Bundle Tasks.
• Triggering Entity Reference: Will auto fetch the reference of the Bundle Task which the assistant is open up from.
• Fulfillment Entity: Will be restricted only to Bundle Tasks.
• Fulfillment Entity Reference: Will auto fetch the reference of the Bundle Task which the assistant is open up from.

Connect SLA Commitments to Request Bundle Tasks

Work Task applicable setup can be used to specify which request work tasks can use the SLA commitments for execution due date. It can be also use to schedule request work tasks if the Scheduling SLA type is defined on commitments.

When a bundle task is created with request work tasks, there can be SLA commitments having such connections with those request work tasks. Such SLA commitments can be connected to the Request Bundle task and that can be done manually from the SLA Tab of Request Bundle Task page. If there are no such SLA commitments connected manually to the request bundle task when it is released, SLA commitment having a scheduling SLA type and a scheduling connection with any request work task in the bundle and having the minimum due date, will be applied on the request bundle task.

 Those SLA commitments on Request bundle tasks can be used,

• To define the execution due date of the Request Bundle task.
• To schedule the bundle task if the Scheduling SLA type is defined on the commitment.

SLA on Pickup Tasks

The Pickup Task in Request Management is used to execute pickup of material required for service work, prior to arriving at the work location. When a Pickup Task is created, a predecessor dependency to the request work task is automatically created, to ensure that the pick up task is scheduled and executed before the main request work task. There will be no separate SLA Commitments to Pickup tasks because of this dependency.