Cool Solutions

Service Level Management



By:

December 6, 2011 10:51 am

Reads:3,183

Comments:0

Score:Unrated

Introduction

A service level agreement is a business contract that specifies service level expectations around critical infrastructure and business services. Typically, they refer to restoration targets that the Service Desk needs to meet.

OLAs & UCs

Operational level agreements (OLAs) are similar to SLAs, except they communicate internal team-based expectations within specific stages of the Workflow process. Similarly, the obligations of external service providers are specified using Underpinning Contracts (UCs). Unlike an OLA where an appropriate Team Technician is assigned responsibility for servicing a request, it is the responsibility of a Service Level Manager to monitor the performance of the external service provider in relation to the business’s expectations as defined in UC Workflow States.

Workflows and Workflow States

Workflows define the sequence of steps that Service Desk staff are required to follow when managing customer requests. With the system, any number of Workflows can be personalized for the Incident, Problem, Change, Release and Service Request Management processes. Each step, or Workflow State, defines the activity, and if relevant the OLA, with Default Team, or UC contract required to successfully process the request at that step. Only after the nominated Team Technician has successfully concluded the activity does the request get routed to the next appropriate Workflow State. The Workflow is deemed complete once the request enters an Exit Workflow State.

Escalation

When a request enters a Workflow State, an appropriate Team is assigned to service the request. Within the Team, escalation layers are configured. Escalation layers manage the request’s flow by automatically guiding the request through a pre-defined escalation pathway. During its journey, the escalation engine monitors the request’s priority level and responds to . It also reacts if too many business hours elapse without contact with the Customer or if the request uses up the total time allotted to it for resolution.

SLAs and Workflow

The Service Level Management module allows service level expectations to be mapped to end-to-end business processes. In so doing, the system performs the following Service Level Management validation:

SLA resolution time >= Sum (Workflow States (OLA or UC resolution times)

When validating Workflows, the system disallows adding States to a Workflow that will force the sum of the Workflow State resolution timers for OLAs and UCs to breach the SLAs resolution timers. In such situations, the system will warn the service level manager to either increase the SLA resolution timers (targets) or select a more appropriate UC or OLA that will fall within the SLA targets.

Configuring SLM in the system

Before requests can be processed using SLM, a Supervisor typically needs to perform the following sequence of configuration steps:

  1. Define Technicians. Set Roles & Process permissions

  2. Define service level managers (Users > Users) To become a service level manager a User must be assigned the Service Level Management Process

  3. Establish business SLAs

a. Specify service level manager

b.Availability %

c. Warning and breach notifications

d. Set priority targets

e. Specify blackout periods

  1. Setup OLAs

a. Specify service level manager

b. Set service targets

  1. Setup Underpinning Contracts
    (UCs)

a. Specify service level manager

b. Specify Vendor

c. Set service targets

  1. Define ITIL process Workflows

a. Name the process and associate it with one of the ITIL processes

b. Optionally set default open and close states { you might need to come back to this once all states have been defined}

c. Specify SLA for the Workflow from Step 3.

d. For each Workflow State, specify:

i. Is the Workflow State active?

ii. Is the State an entry or exit state?

iii. The Contract Type: None / OLA / UC

          • Specify an OLA if the OLA Contract Type is set.

          • Select a default Team, that has been assigned the OLA.

          • Specify a UC, if the UC contract type has been selected.

iv. Should the SLA timer continue counting time when the request has entered this State?

v. Should the State be used to measure SLA restoration or resolution time (for reporting purposes only)

vi. Specify relevant next / previous States to define the end-to-end Workflow.

          • To prevent the SLA target from being breached, the contract time will be calculated when an OLA or UC is assigned to a State.

e. Update 6b) if required.

  1. Define the service Teams

a. Specify Technicians

b. Specify OLAs

c. Specify Workflows

d. Define escalation layers or work groups

  1. Make any modifications to the Workflow State

a. Specify a default Team to provide support for this State {review 6diii 1a)

Applying SLM to the process of raising an Incident

After SLAs, Workflows and Teams have been defined, the Service Desk is able to use the system to efficiently process Incident, Problem, RFC and Service Requests according to organizational standards and procedures.

The following steps outline the process of raising and managing an Incident in the system:

  1. Within the Operations > Incident tab select the New button:

a. Assign a Customer

b. Select a Configuration Item (CI), which include Services within Service Catalog

c. If prompted by the system, assign an SLA to the Incident as:

i. No Customer SLA exists or

ii. No Org Unit SLA exists or

iii. No CI SLA exists

d. Profile the Incident

i. Select a Classification

ii. Enter Description of the Incident

iii. Complete any custom fields

e. If the proactive analysis option is enabled, proposed solutions will be available within the Analysis Tab. If a relevant Solution is proposed, apply the Solution to close the Incident. Otherwise, click ‘Next’ to move to the Summary tab of the Incident screen.

  1. In the Incident Summary screen, confirm:

a. SLA

b. Workflow

i. A list of Workflows options is derived based on the SLA selected

ii. If a Workflow has not been assigned to the SLA, then the system default Workflow is assigned to the Incident

c. Team

i. A list of Team options will be derived based on the Workflow selected

ii. If a Team has not been assigned to the Workflow, then the CI’s default Team is assigned to manage the Incident

d.Technician

e. Incident Urgency / Impact / Priority

f. Notifications

g. Workflow State (= Incident Status)

h. Add Note(s), and apply private/public visibility and Customer email distribution options

i. Upload attachments

j. Access Audit trail details

k. Access Impact information (i.e., Service Targets, SLA breaches, Item Relationships, Planned Outages, Contract Monitor)

  1. Perform analysis within the Analysis tab

a.Allows the system to recommend a proposed Workaround or Solution

b. Search Workarounds / Solutions

c. Raise new Workaround / Solution

d. Raise a new Problem and link it to the Incident

e. Raise a new RFC and link it to the Incident

f. If the Incident is related to other Incidents, Problems, Change or Service Requests, view all related requests within the Incident > Related tab.

  1. Save the Incident

  2. Group similar or related Incidents within an Incident Group and manage the collective from the Incident Group tab.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading ... Loading ...

Tags: ,
Categories: Service Desk, Technical

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

Comment

RSS