Service Level Management (part 2/2)

Different ways of defining SLAs in ServiceNow

In this article we will describe different ways how SLAs can be defined in ServiceNow. We will focus on differences between the approaches and the situations where they are best used.

Default Plugin

If a company is providing only a basic set of service levels which are the same for all their customers and a specific service level is selected based only on a few conditions (e.g. type of ticket, incident priority, etc.) then it is sufficient to use the Service Level Agreements (SLA) Plugin alone. This can apply only to some tables.

See previous article on how to create SLA definition and how to specify which SLA should be used.

Pros & Cons

Pros (Advantages):

• Default plugin (already installed)
• Easy to define
• Serviceability (only one table, conclusively separated by target table) for a limited amount of SLAs

Cons (Disadvantages):

• Impact on performance (each condition of each SLA must be checked) if there are too many SLAs per table
• Confusing (which SLA will be applied) if there are too many SLAs per table

Contract Plugin

Companies which have their service levels defined per customer or contracts with these customers, can use SLA Contract Add-on plugin. This plugin extends the default SLA plugin by introducing a Contract as the master record that contains all the data needed for the SLA processing.

A new table is available after the activation of the plugin for defining service contracts (Service Level Management > Service Contracts). These contracts group together SLAs that relate to a single vendor or customer, as well as the CIs, locations, groups, users and child contracts that are related to the contract and define when this contract can be used.

The ‘Contract’ field must be added to the ticket form (this field is added to the Task table by the plugin), so the user can select the appropriate contract. Contracts are filtered by Caller, Assignment Group, Location and Configuration item (according to contract settings).

When a new ticket is created (or modified) on a table where this plugin is applied (see system property com.snc.sla.contract.tables), only the SLA definitions associated to the selected contract are controlled and recalculated. No other SLA definitions are used. All other actions are the same as in the case of the default plugin, so the only difference is the limited set of SLA definitions which can be applied.

Important System properties

• com.snc.sla.contract.tables

• defines tables on which this plugin should be used
• to disable plugin – put empty value
• value: fsm_service_order

Pros & Cons

Pros (Advantages):

• SLA is defined per contract with customer
• SLA is selected only from a limited list of SLA definitions (better performance)

Cons (Disadvantages):

• If the process (table) uses the SLA Contract Plugin there is no other way to define SLAs than to link them to a contract

Service Portfolio Management - SLA Commitments – Plugin

The Service Portfolio Management plugin can be used to define business services offered by the company in a standardized, structured format. Service offering is a new type of configuration item that is used to create levels of service for the existing business services. These levels are described by service offering commitments. Generally ServiceNow provides several types of commitments. From SLA point of view the SLA Commitments plugin is important. This extension enables the definition of commitments for services as SLA definitions. Because the Service Offering table is an extension of the Configuration Item table, these service offerings can be selected from any ticket (e.g. inherited from the Task table). The list of the offerings can be offered to the users in the catalog.

SLA definitions can be defined in a newly created table Service Offering SLA (Business Services > Service Offering SLAs > SLAs). This table is inherited from the SLA table and contains only SLA definitions that are associated with the service offerings. The creation of a Service Offering SLA is the same as the creation of a basic SLA definition. For creating new service offering please consult the Wiki pages of ServiceNow. To create a new SLA Service Commitment, navigate to Service Offering form and click New in the Service Commitments related list, or use module Business Services > Commitments. In the field “Type” select “SLA” and then select appropriate SLA definition. It is up to the user if she/he selects the normal SLA definition or the Service Offering SLA definition. The benefit of selecting the Service Offering SLA definition is that this SLA is evaluated only if the configuration item on the task is related to service offering. This way it is possible to define SLAs per service (more precisely per service offering commitment). On the SLA Commitment record it is possible to define the percentage of the required fulfillment of the SLA and penalty for breaching this commitment.

Once services and commitments are defined, ServiceNow will automatically start tracking the performance on these commitments. The new “Calculate SLA Results” scheduled job runs nightly and calculates the daily SLA results for the previous day. It also calculates the weekly, monthly and annual results after the last day of a week, month or year. These records are used by SLA homepage gauges.

Pros & Cons

Pros (Advantages):

• SLA is defined per service
• SLA is selected only from a limited list of SLA definitions (better performance)
• Default (per table) SLA definition is also used (consistency)

Cons (Disadvantages):

• Complex maintenance (many records associated to one SLA)

• Complex structure of SLA definition and relations
• Default (per table) SLA definition is also used (impact on performance)