the service level agreement sla guide - sla book, templates for service level management and service...

The Service Level Agreement SLA Guide:

SLA Book Templates for Service Level

Management and Service Level Agreement Forms

- Fast and Easy Way to Write your SLA

Notice of Rights: Copyright © The Art of Service. All rights reserved. No part of

this book may be reproduced or transmitted in any form by any means,

electronic, mechanical, photocopying, recording, or otherwise, without the prior

written permission of the publisher.

Notice of Liability: The information in this book is distributed on an “As Is” basis

without warranty. While every precaution has been taken in the preparation of the

book, neither the author nor the publisher shall have any liability to any person or

entity with respect to any loss or damage caused or alleged to be caused directly

or indirectly by the instructions contained in this book or by the products

described in it.

Trademarks: Many of the designations used by manufacturers and sellers to

distinguish their products are claimed as trademarks. Where those designations

appear in this book, and the publisher was aware of a trademark claim, the

designations appear as requested by the owner of the trademark. All other

product names and services identified throughout this book are used in editorial

fashion only and for the benefit of such companies with no intention of

infringement of the trademark. No such use, or the use of any trade name, is

intended to convey endorsement or other affiliation with this book.

ITIL® is a Registered Community Trade Mark of OGC (Office of Government

Commerce, London, UK), and is Registered in the U.S. Patent and Trademark

Office.

Write a Review and Receive a Bonus Emereo

eBook of Your Choice

Up to $99 RRP – Absolutely Free

If you recently bought this book we would love to hear from you – submit

a review of this title and you’ll receive an additional free ebook of your

choice from our catalog at http://www.emereo.org.

How Does it Work?

Submit your review of this title via the online store where you purchased

it. For example, to post a review on Amazon, just log in to your account

and click on the ‘Create Your Own Review’ button (under ‘Customer

Reviews’) on the relevant product page (you’ll find plenty of example

product reviews on Amazon). If you purchased from a different online

store, simply follow their procedures.

What Happens When I Submit my Review?

Once you have submitted your review, send us an email via

[email protected], and include a link to your review and a link to the

free eBook you’d like as our thank-you (from http://www.emereo.org –

choose any book you like from the catalog, up to $99 RRP). You will then

receive a reply email back from us, complete with your bonus ebook

download link. It's that simple!

Service Level Management Workbook

Page 3

TABLE OF CONTENTS

TABLE OF CONTENTS..........................................................................................................3

INTRODUCTION ROADMAP .................................................................................................5

SERVICE DESIGN .................................................................................................................9

CONTINUAL SERVICE IMPROVEMENT ........................................................................... 43

SUPPORTING DOCUMENTS............................................................................................. 55

Objectives and Goals ................................................................................................... 57

Policies Objectives and Goals ..................................................................................... 63

SLM Scope ...................................................................................................................... 67

Business Justification Document .................................................................................. 75

Organizing for Service Design – Roles & Responsibilities .......................................... 81

SLM Process Manager ................................................................................................... 87

Customer Based SLA ..................................................................................................... 91

Service Based SLA.......................................................................................................... 99

Multi Level SLA’s ........................................................................................................... 108

Business and IT Service Mapping ............................................................................... 116

Operational Level Agreement................................................................................... 130

Service Level Requirements........................................................................................ 136

Service Options ............................................................................................................ 144

Underpinning Contracts.............................................................................................. 150

Functional Specification ............................................................................................. 156

Technical Specification............................................................................................... 164

Price List ......................................................................................................................... 172

Communication Plan .................................................................................................. 176

Business and IT Flyers.................................................................................................... 184

Reports KPI’s Other Metrics......................................................................................... 188

SLM IMPLEMENTATION & PROJECT PLAN .................................................................. 194

FURTHER INFORMATION ............................................................................................... 204


Page 4

freya.dixon

Blank


Page 5

INTRODUCTION ROADMAP Many organizations are looking to implement a Service Level Management as a way to improve the structure and quality of the business. This document describes the contents of the Service Level Management Workbook. The information found within the Workbook is based on the ITIL Version 3 framework, specifically the Service Design and Continual Service Improvement phases which incorporate the updated ITIL version 3 Service Level Management process. The Workbook is designed to answer a lot of the questions that Service Level Management process raises and provides you with useful guides, templates and essential, but simple assessments. The supporting documents and assessments will help you identify the areas within your organization that require the most activity in terms of change and improvement. Presentations can be used to educate or be used as the basis for management presentations or when making business cases for Service Level Management implementation. The additional information and bonus resources will enable you to improve your organizations methodology knowledge base. The workbook serves to act as a starting point. It will give you a clear path to travel. It is designed to be a valuable source of information and activities. The Service Level Management Workbook:

Flows logically, Is scalable, Provides presentations, templates and documents, Saves you time.


Page 6

Step 1 Start by reviewing the PowerPoint presentations in the following order: Presentations 1 and 2 provide a detailed and comprehensive overview of Service Level Management in the specialist areas of ITIL Version3

1. ITIL V3 SLM Presentation - Service Design. 2. ITIL V3 SLM Presentation - CSI

These presentations will give you a good knowledge and understanding of all the terms, activities and concepts required within the Service Level Management process. They can also be used as the basis for management presentations or when making a formal business case for Service Level Management implementation. Make sure you pay close attention to the notes pages, as well as the slides, as references to further documents and resources are highlighted here.


Page 7

Step 2 If you did not look at the supporting documents and resources when prompted during the PowerPoint presentations, do this now. Below is an itemized list of the supporting documents and resources for easy reference. You can use these documents and resources within your own organization or as a template to help you in prepare your own bespoke documentation. ITIL V3 SLM Presentation - Service Design

1. Objectives and Goals 2. Policies Objectives and Scope 3. SLM Scope 4. Business Justification document 5. Organizing for Service Design - Roles & Responsibilities 6. SLM Process Manager 7. Customer Based SLA 8. Service Based SLA 9. Multi level SLA's 10. Business and IT Service Mapping 11. Operational Level Agreement 12. Service Level Requirements 13. Service Options 14. Underpinning Contracts 15. Functional Specification 16. Technical Specification 17. Price List 18. Communication Plan 19. Business and IT Flyers 20. Reports KPI's other metrics 21. SLM Process Manager 22. Organizing for Service Design - Roles & Responsibilities

ITIL V3 SLM Presentation - CSI


Page 8

Step 3 Alternatively, continue by working through the SLM Implementation & Project Plan with the focus on your organization. This will help you ascertain the Service Level Management maturity for your organization. You will able to identify gaps and areas of attention and/or improvement. The supporting documents and bonus resources found within the workbook will help you fill these gaps by giving you a focused, practical and user-friendly approach to Service Level Management.


Page 9

SERVICE DESIGN


Page 10

Service Level Management (SLM) is a process that is found within two Service Lifecycle phases. Within Service Design, Service Level Management is concerned with:

• Design and plan process

• Determining Service Level Requirements (SLRs)

• Negotiating and Agreeing upon SLAs, OLAs and UCs.

Within Continual Service Improvement, Service Level Management is concerned with improving services and processes through constant:

• Monitoring (executed within Service Operation)

• Reporting

• Evaluating

• Improving

The major focus of Service Level Management within Continual Service

Improvement is identifying potential service improvements.


Page 11

SLM is a vital process for every IT service provider organisation as it is responsible

for agreeing and documenting service level targets and responsibilities within SLAs

and SLRs for every activity within IT.

If targets are appropriate and accurately reflect the requirements of the business,

the service delivered will align with business requirements and meet the

expectations of the customers and users in terms of service quality.

When targets are not aligned with business needs, the service provider activities

and service levels will not be aligned with business expectations and therefore

problems will develop.

The SLA is effectively a level of assurance or warranty with regard to the level of

service quality delivered by the service provider for each of the services delivered

to the business.

The quality of the Service Portfolio and the Service Catalogue is pivotal to the success of the SLM.


Page 12

Service Level Management (SLM) negotiates, agrees and documents appropriate

IT service targets with representatives of the business, and then monitors and

produces reports on the service provider;s ability to deliver the agreed level of

service.


Page 13

Proactive measures are also taken to seek and implement improvements to the

level of service delivered.

More information is available within this workbook, in the following documents:

• Objectives and Goals on page 57

• Policies Objectives and Scope on page 63


Page 14

SLM is the name given to the processes of planning, coordinating, drafting,

agreeing, monitoring and reporting of SLA’s, and the ongoing review of service

achievements to ensure that the required and cost-justifiable service quality is

maintained and gradually improved.


Page 15

SLM must manage the expectation and perception of the business, customers and

users in order to ensure that the quality of service delivered by the service provider

is matched to those expectations and needs. In order to do this effectively, SLA

should establish and maintain SLAs for all current live services and manage the

level of service provided to meet the targets and quality measurements contained

within the SLAs. SLM should also produce and agree SLRs for all planned new or

changed services.

This enables SLM to ensure that all services and components are designed and

delivered to meet their targets in terms of business needs. The SLM processes

should include the:

• Development of relationships with the business

• Negotiation and agreement of current requirements and targets, and the

documentation and management of SLAs for all operational services

• Negotiation and agreement of future requirements and targets, and the

documentation and management of SLRs for all proposed new or changed

services

• Development and management of appropriate Operational Level

Agreements (OLAs) to ensure that targets are aligned with SLA targets


Page 16

Continued…

• Review of all underpinning supplier contracts and agreements with Supplier

Management to ensure that targets are aligned with SLA targets

• Reporting and management of all services and review of all SLA breaches

and weaknesses

• Instigation and coordination of a Service Improvement Plan (SIP) for the

management, planning and implementation of all service and process

improvements


• SLM Scope on page 67


Page 17

SLM is not only concerned with ensuring that current services and SLA’s are

managed, but is also involved in ensuring that new requirements are captured and

that new or changed services and SLA’s are developed to match the business

needs and expectations. SLA’s provide the basis for managing the relationship

between the service provider and the customer, and SLM provides that central

point of focus for a group of customers, business untis or lines of business.


• Business Justification document on page 75


Page 18

• Written agreement between a service provider and Customers), that

documents agreed Service Levels for a Service: Service Level Agreements (SLAs)

• Written statement of IT services, default levels and options: Service

Catalogue

• Contract with an external supplier that supports the IT organization in their

delivery of services: Underpinning Contract (UCs)

• Internal agreement which supports the IT organization in their delivery of

services: Operational Level Agreement (OLAs)

• Detailed recording of the Customer’s needs: Service Level Requirements


Page 19

More information is available, within this workbook, in the following documents:

• Organizing for Service Design - Roles & Responsibilities on page 81

• SLM Process Manager on page 87


Page 20

Service Based SLA The SLA covers one service, for all customers of that service.

Difficulties may arise if the specific requirements of different customers vary for the

same service, or if characteristics of the infrastructure mean that different service

levels are inevitable. As such, separate targets may be needed within the one

agreement. However, where common levels of service are provided across all

areas of the business, service-based SLAs may be the most efficient approach.

Customer Based SLA The SLA is an agreement with an individual customer group, covering all the

services they use.

Customers often prefer such an agreement, as a single document will cover all

their needs.


• Customer Based SLA on page 91

• Service Based SLA on page 99


Page 21

Multi – level SLA’s Some organizations have chosen to adopt a multi level SLA structure. E.g A 3

level structure such as;

Corporate Level: covers all generic SLM issues to every customer throughout the

organization.

Customer Level: covers all SLM issues relevant to a particular customer group of

business unit, regardless of the service being used

Service Level: covers all SLM issues relevant to the specific service, in relation to

a specific customer group


• Multi level SLA's on page 107


Page 22

The activity of determining the initial targets for inclusion with an SLR or SLA can

be very difficult. All other processes need to be consulted for their opinion on

realistic targets, such as Incident Management on incident targets. Capacity and

Availability Management processes will be of particular value in determining

appropriate service availability and performance targets.

While many organizations have to give initial priority to introducing SLAs for

existing services, it is also important to establish procedures for agreeing SLRs for

new services being developed or procured.

If can be difficult to draw out specific requirements, as the business may need help

in understanding and defining their needs, particularly in terms of capacity, security,

availability and IT service continuity. Several iterations of negotiations may be

required before an affordable balance is struck between what is sought and what is

achievable and affordable.


Page 23

The Service Desk, when linked to a comprehensive CMS, can be used to monitor

the customer’s perception of availability. It can also be used to monitor incident

response times and resolution times.

It is essential to ensure that any incident / problem handling targets included in

SLAs are the same as those included in Service Desk tools and used for escalation

and monitoring purposes. Some amendments may be needed to support tools, to

include the necessary fields so that relevant data can be captured.

Transaction response times can be a difficult area to monitor and can be dealt with

in the following ways:

• Include a statement in the SLA stating that any response time delays

experienced for more than x minutes should be reported to the Service Desk

• Agree and include in the SLA an acceptable target for the number of such

incidents that can be tolerated in the reporting period

• Create an incident category of ‘poor response’ to ensure that such incidents

are logged accurately

• Produce regular reports of target time breaches and instigate investigations

via Problem Management to find a solution


Page 24


Page 25

SLAs are just documents, and in themselves do not materially alter the quality of

service being provided. However, it must be noted that SLAs do affect the

behaviour and help engender an appropriate service culture, which can then have

an immediate beneficial effect and make longer-term improvements possible.

It is recommended that attempts be made to monitor customer perception on soft

issues such as opinions or feelings toward the service. Methods of doing this

include:

• Periodic questionnaires and customer surveys

• Customer feedback from service review meetings

• Feedback from Post Implementation Reviews (PIRs) conducted as part of

the Change Management process on major changes, releases, new or

changed services etc.

• Telephone perception surveys (perhaps at random on the Service Desk, or

using regular customer liaison representatives)

• Satisfaction survey handouts (left with customers following installations,

service visits etc.)

• User group or forum meetings

• Analysis of complaints and compliments


Page 26

Continued…

Where possible, targets should be set for these and monitored as part of the SLA.

Ensure that if users provide feedback they receive some return, and demonstrate

to them that their comments have been incorporated in an action plan, perhaps an

SIP. All customer satisfaction measurements should be reviewed, and where

variations are identified, they should be analysed with action taken to rectify the

variation.


Page 27

OLAs need not be very complicated, but should set out specific back-to-back

targets for support groups that underpi8n the targets included in the SLAs.

OLAs should be monitored against OLA and SLA targets, and reports on

achievements provided as feedback to the appropriate managers of each support

team. This highlights potential problem areas, which may need to be addressed

internally or by a further review of the SLA or OLA.

Before committing to new or revised SLAs, it is therefore important that existing

contractual arrangements are investigated and, where necessary, upgraded.


Page 28


Page 29

SLM should identify the specific reporting needs and automate production of all

reports wherever possible. The extent, accuracy and ease with which automated

reports can be produced should form part of the selection criteria for integrated

support tools.

Operational reports must be produced on a regular basis. This should be weekly,

or possibly more frequently and must produce exception reports whenever an SLA

has been broken or threatened.

Periodic reports must be produced and circulated to customers and appropriate IT

managers a few days in advance of service level reviews, so that any queries or

disagreements can be resolved ahead of any review meetings. These reports

should incorporate details of performance against all SLA targets, together with

details of any trends or specific actions being undertaken to improve service

quality. Other interim reports may be required by IT management for OLA or

internal performance reviews and/or supplier or contract management.


Page 30

Continued…

It is essential that accurate information from all areas and all processes are

analysed and collated into a concise and comprehensive report on service

performance, as measured against agreed business targets. Service reports

should not only include details of current performance, but should also provide

historic information on past performance and trends, so that the impact of

improvement actions can be measured and predicted.


Page 31

Particular attention should be focused on each breach of service level to determine

exactly what caused the loss of service and what can be done to prevent any

recurrence.

Reports should also be produced on the progress and success of the SIP, such as

the number of SIP actions that were completed and the number of actions that

delivered their expected benefit.


Page 32

Reviews should ensure that the services covered have:

• Relevant targets

• No significant changes

• Change Management control any agreed changes

• Include overall strategy documents.


Page 33

The Business Service Catalogue provides information on all the key business and

IT contacts relating to the services, their use and their importance. In order to

ensure that this is done in a consistent manner, SLM should perform the following

activities:

• Confirm stakeholders, customers and key business managers and service

users.

• Assist with maintaining accurate information within the service portfolio and

service catalogue.

• Be flexible and responsive to the needs of the business, customers and

users and understand current and planned new business processes and

their requirements for new or changed services, documenting and

communicating these requirements to all other processes as well as

facilitating and innovating change wherever there is business benefit.

• Develop a full understanding of business, customer and user strategies.

• Regularly sample the customer experience – providing feedback on

customer issues to IT

• Ensure the correct relationship processes are in place to achieve objectives

• Proactively market and exploit the Service Portfolio and Service Catalogue.

• Promote service awareness and understanding


Page 34

Continued…

• Raise the awareness and understanding

• Facilitate the development and negotiation of appropriate, achievable and

realistic SLR’s and Sla’s between the business and IT.

• Ensure the business, customers and users understand their

responsibilities/commitments to IT.


Page 35

Definitions of what constitutes a complaint and compliment should be agreed with

the customers, together with the agreed procedures for their correct management

and analysis.

All complaints and compliments should be recorded and communicated to the

relevant parties. All complaints should also be actioned and resolved to the

satisfaction of the originator. If not, there should be an escalation procedure for all

complaints that are not actioned and resolved within the agreed timescale.

Reports should also be produced on the numbers and types of complaints, trends

identified and actions taken to reduce the numbers received. Similar reports

should be produced for compliments.


Page 36


Page 37


• Business and IT Service Mapping on page 115


Page 38


• Operational Level Agreement on page 129

• Service Level Requirements on page 135

• Service Options on page 143

• Underpinning Contracts on page 149

• Functional Specification on page 155

• Technical Specification on page 163

• Price List on page 171

• Communication Plan on page 175

• Business and IT Flyers on page 183


Page 39

Objective:

• Number or percentage of service targets being met

• Number and severity of service breaches

• Number of services with up-to-date SLA’s

• Number of services with timely reports and active service reviews

Subjective: Improvement in customer satisfaction


Page 40


• Reports KPI's other metrics on page 187


Page 41


Page 42


• SLM Process Manager on page 87

• Organizing for Service Design - Roles & Responsibilities on page 81


Page 43

CONTINUAL SERVICE IMPROVEMENT


Page 44

Service Level Management (SLM) is a process that is found within two Service Lifecycle phases. Within Service Design, Service Level Management is concerned with:

• Design and plan process

• Determining Service Level Requirements (SLRs)

• Negotiating and Agreeing upon SLAs, OLAs and UCs.

Within Continual Service Improvement, Service Level Management is concerned with improving services and processes through constant:

• Monitoring (executed within Service Operation)

• Reporting

• Evaluating

• Improving

The major focus of Service Level Management within Continual Service

Improvement is identifying potential service improvements.


Page 45

This provides input into CSI activities and helps prioritize improvement projects.

Even though SLM is critical for many organizations it is often one of the least

mature processes.

Service Level Management can be described using two words: building

relationships! Building relationships with customers, the functional groups within IT

and the vendor community who provide services to IT.


Page 46

Even without any formal SLA’s or OLA’s, an organization can still strive to improve

the services they provide to customers.


Page 47

Explicit SLA: one of the goals of SLM, is to get a formal document that clearly

defines the services provided, levels of service, quality of service and cost of the

service. Everyone understands their responsibilities

Implicit SLA: based on how you have provided your service in the past. If you

provide good service the customers expect good service. If you improve on your

service, then this becomes the new minimal level expected. Also if you have

provided poor service in the past then your customers will actually expect poor

service. Implicit SLA’s are difficult to manage.

Psychological SLA: often associated with the Service Desk where we publish

information to the end users often b y putting a sticker on their monitor that states

‘if you need help call ######’. In the mind of end users this creates an agreement

that all they have to do is call the Service Desk to find a solution to their issues. In

realty there are some Service Desks and Help Desks that provide less than ideal

help!


Page 48

SLM is essential in any organization so that levels of IT service needed to support

the business can be determined, and monitoring can be initiated to identify whether

the required service levels are being achieved – and if not, why not!

Service Level Management is a cornerstone of CSI. Why embark on any service

improvement initiative if the customers and the business are satisfied with the

levels of service received? Because business requirements change!


Page 49

The Service Level Management process is created in the Service Design phase of

the Service Lifecycle. It is important that CSI is involved in the design of SLM to

ensure that measurable targets are created. These targets can then be used to

identify potential service improvements.


Page 50

Where an underlying difficulty has been identified which is adversely impacting

upon service quality, Service Level Management must, in conjunction with CSI,

using Problem Management and Availability Management, instigate a SIP to

identify and implement whatever actions are necessary to overcome the difficulties

and restore service quality.


Page 51

At any time, a number of separate initiatives that form part of the SIP may be

running in parallel to address difficulties with a number of services.


Page 52

If an organization is outsourcing its service provision to a third party, the issue of

service improvement should be discussed at the outset and covered in the

contract. Otherwise there is no incentive for the supplier to improve service targets

if they are already meeting contractual obligations and additional expenditure is

needed to make the improvements.


Page 53

This model emphasizes the fact that there are many opportunities for CSI.

The model illustrates a constant cycle for improvement.

Additional info for Items to consider list:

• Embrace the vision by understanding the high level business objectives.

• Access the current situation to obtain an accurate and unbiased snapshot of

where the organization right now. This baseline assessment is an analysis

of the current position in terms of the business, organization, people,

process and technology.

• Based on a deeper development of the principles defined in the vision. The

full vision can be years away but this step provides specific goals and a

manageable timeframe.

• Detail the CSI plan to achieve higher quality service provision by

implementing ITSM processes.

• Verify that measurements and metrics are in place to ensure that milestones

were achieved, process compliance is high, and business objectives and

priorities were met by the level of service.

• Finally, the processes should ensure that the momentum for quality

improvement is maintained by assuring that changes become embedded in

the organization.


Page 54

freya.dixon

Blank


Page 55

SUPPORTING DOCUMENTS Through the documents, look for text surrounded by << and >> these are indicators for you to create some specific text.

Watch also for highlighted text which provides further guidance and instructions.


Page 56

freya.dixon

Blank


Page 57

Objectives and Goals

IT Services Detailed Objectives/Goals

Process: Service Level Management

Status: In draft Under Review Sent for Approval Approved Rejected

Version: <<your version>>

Release Date:

Note: SEARCH AND REPLACE<<organization name>> Search for any << or >> as your input will be required Also review any yellow highlighted text


Page 58

Detailed Objectives/Goals for Service Level Management

The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization.

However, the reader will certainly be reminded of the key topics that have to be considered.

The detailed objectives for Service Level Management should include the following salient points:

Objective Notes

After they have been agreed upon a specific objective for the process is to continue reporting metrics. This is an activity that is often forgotten over time or simply not done from the out-set.

Met/Exceeded/Shortfall

☺ Dates/names/role titles

Appoint/Recruit the SLM team and provide on-going awareness, education and training for staff involved with the process and communication to non-involved, but affected personnel.

Setting schedules for reviews of Service Level Agreements and associated supporting documentation. Arranging the logistics of bringing the involved parties together (at intervals that are not considered to be a “nuisance” but will allow the process objective to be upheld.

Monitor customer and end-user satisfaction levels.

Monitor the marketplace for appropriate process tools and make recommendations.

Design, manage and implement an awareness/communication plan appropriate for this process.


Page 59

Use these objectives to generate discussion about others that may be more appropriate to list than those provided. Failure to meet objectives (or when service breaches are detected) should trigger a process for improvement. Under the Service Level Management process, we refer to this as a Service Improvement Plan (SIP). Service Improvement Plan (SIP) Where an underlying difficulty has been identified that has lead to a degradation in service quality it is necessary for the Service Level Management process to start a Service Improvement Plan (SIP). The SIP must be drawn together with input from other processes (in particular Problem Management) so that the action steps in the SIP do in fact contribute to improvements and eradication of poor performance. Areas to address Comments/Examples Time

Frame/Notes/Who SIP Reference number

Unique identifying number for the SLA (for inclusion in the Configuration Management Data Base – CMDB)

Owner

Functional role description of who is responsible for this SIP (who would participate in a review of this document).Representatives from customer and IT.

Service Name

Preferably use a name that is common language in the organization (not a technical name).

Service Description (Business) (refer to Technical Considerations later in this table)

Briefly describe the primary function of the service. Use language that is business user friendly. (eg. instead of “NT Server, with 2Gb RAM and 500Gb of disk storage” – we would say “large central server designed for all customers to use and share information from”)


Page 60

Service Breach(s) details (refer to Problem & Availability Management issues).

The SIP will generally be based on broken SLAs. Use this section to briefly detail in generic terms why this SIP is required.

Problem Management details

The SIP will be driven as a result of the need to improve degraded performance. It is likely that there have been continuing Problems that have led to the service degradation. From Problem Management we can gain a better understanding of the background to the SIP.

Availability Management details

After the SIP is instigated the end users and customers should expect a higher level of service availability than they have in the past. The SIP must directly address the issue of availability by reviewing the past, current and future availability metrics for this service.

Service Security Considerations

Briefly list any considerations regarding security considerations for this SIP.

SIP Validity period

Is there a life-span for this SIP; is the life of the SIP time based or driven by activities only?


Page 61

SPECIFIC SIP ACTIONS

This part of the SIP will outline actual steps to be taken to improve availability and eradicate poor performance. This section of the SIP can be run as a Project if large enough, or as a simple list of action items, responsible person and timeframe. Action items will centre on discussions, negotiations, communications, documentation (new and updates to existing), testing, reviews, training/education and reworking current procedures and work practices. (Note: don’t forget to track changes and ensure the Configuration Management database is updated).

Version Control Information

SIP Creation Date SIP Last Modify Date

Technical considerations

In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalogue or Technical Specification.

Notes & Comments


Page 62

freya.dixon

Blank


Page 63

Policies Objectives and Goals

IT Services Policies, Objectives and Scope




Release Date:


Page 64

Policies, Objectives and Scope for Service Level Management

The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization.

However, the reader will certainly be reminded of the key topics that have to be considered.

Policy Statement

A course of action, guiding principle, or procedure considered expedient, prudent, or advantageous

Objectives Statement

Use this text box to answer the “SENSE OF URGENCY” question regarding this process.

Why is effort being put into this process?

Not simply because someone thinks it’s a good idea. That won’t do. The reason has to be based in business benefits.

You must be able to concisely document the reason behind starting or improving this process.

Is it because of legal requirements or competitive advantage? Perhaps the business has suffered major problems or user satisfaction ratings are at the point where outsourcing is being considered.

A policy statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHY question for this process.

The above Policy Statement was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>

Refer to Implementation Plan - Project Plan for planning and implementation guidelines (that includes the Policy, Objectives and Scope statements) on page 193.


Page 65

Something worked toward or striven for; a goal

Use this text box to answer the “WHERE ARE WE GOING” question regarding this process.

What will be the end result of this process and how will we know when we have reached the end result?

Will we know because we will establish a few key metrics or measurements or will it be a more subjective decision, based on instinct?

A generic sample statement on the “objective” for Service Level Management is:

The Service Level Management process aims to improve, while maintaining, IT Service delivery quality. Actions to achieve this include the requirement to conduct repetitive actions that include reporting, agreeing and monitoring. The process must review Service Achievements against customer expectations and take steps to improve or modify Service Delivery accordingly.

Note the keywords in the statement. For the statement on Service Level Management they are “report, agree and monitor”. These are definite areas that we can set metrics for and therefore measure progress.

The above Objective Statement was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>

Refer to Objectives and Goals for detailed statements of process objectives/goals on page 57.

Refer to Reports, KPIs and Other Metrics for metrics on page 187.


Page 66

Scope Statement

The area covered by a given activity or subject

The above Policy Statement was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>

Use this text box to answer the “WHAT” question regarding this process.

What are the boundaries for this process?

What does the information flow look like into this process and from this process to other processes and functional areas?

A generic sample statement on the “scope” for Service Level Management is:

Through the use of agreements written in the form of documents the SLM process will manage relationships between providers of IT services that are both external to the organization and internal to the organization.

These external agreements shall be referred to as Underpinning contracts and the internal agreements will be called Operational Level Agreements.

An scope statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHAT question for this process.

The above Scope Statement was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 67

SLM Scope

IT Services Scope Document




Release Date:

Note: SEARCH AND REPLACE

<<Organization name>>

Search for any << or >> as your input will be required

Also review any yellow highlighted text


Page 68

Document Control Author

Prepared by <<name and / or department>> Document Source

This document is located on the LAN under the path:

I:/IT Services/Service Delivery/Service Level Management/Scope Document Approval

This document has been approved for use by the following:

• <<first name, last name>>, IT Services Manager

• <<first name, last name>>, IT Service Delivery Manager

• <<first name, last name>>, National IT Help Desk Manager Amendment History

Issue Date Amendments Completed By

Distribution List

When this procedure is updated the following copyholders must be advised

through email that an updated copy is available on the intranet site:

<<Organization Name>> Business Unit

Stakeholders

IT


Page 69

Introduction Purpose The purpose of this document is to provide the IT Organization with the

specifications of the IT Services that will be included within the scope of the

Service Level Management Process.

Scope This document describes the following:

• Scope of Service Level Management

• <<any additional items that you want>>

Audience This document is relevant to all staff in <<Organization name>>

Ownership IT Services has ownership of this document.

Related Documentation Include in this section any related Service Level Management reference numbers

and other associated documentation:

• Implementation Plan / Project Plan

• Policies, Guidelines and Scope Document

• Process Template

• Service Catalogue


Page 70

Executive Overview Describe the purpose, scope and organization of the document. Service Level Management Overview The document’s intent is to provide a scope for the Service Level Management

Process.

The definition of an SLA is:

<< Insert your organizations definition here >>

The definition of an OLA is:

<< Insert your organizations definition here >>

The definition of a UC is:

<< Insert your organizations definition here >> Process Scope The process scope details the scope of the activities that need to occur within the

Service Level Management Process.

Definition This activity helps define the services that you already deliver and can deliver. The

output from this activity is the Service Catalogue.

In this section determine the scope of the Service Catalogue.


Page 71

Specify This activity is about gathering the Service Level Requirements. This will be done

by a series of interviews with department managers and senior executives.

In this section determine the scope of the Requirements gathering.

Department Services Business Owner

IT Owner

<<

Department: The department to be interviewed

Services: The services being provided to that department

Business Owner: The department manager or other

IT Owner: The IT personnel who will be responsible for providing the

service

>>

Negotiate and Agree In this activity we create the necessary SLAs, OLAs and UCs necessary to support

the agreed services.

In conjunction with the above table, we can now set the scope for the SLA. In this

manner we need to determine what will be included in the SLA.


Page 72

For example:

Service Level Agreements Customer IT Service

Availability Capacity Disaster Recovery

Marketing Email

Sales and Support

Logistics

Monitor In this section we need to set the scope for which aspects of the services we are

going to monitor, and what tools we are going to use to monitor the services with.

This will be done in conjunction with the above table.

Reports Reports are an integral way of spreading information about IT Services back to the

business as well as to IT Departments for process improvement.

As such the reports should be written in Business English as well as Technical

English.

In this section, provide a list of reports necessary for each customer based on each service. The below table provides an example.

Reports

Business Reports IT Reports Customer Service

Productivity No. of Incidents

% of Availability Bandwidth CPU

Seconds Transaction

Rates

Marketing Email

Marketing Internet

Sales Logistics

Sales Accounts

Transport Logistics


Page 73

Appendices

Include any applicable appendixes that are needed.

Terminology

Make sure that all terminology is captured and documented correctly.


Page 74

freya.dixon

Blank


Page 75

Business Justification Document

IT Services Business Justification




Release Date:

Note: SEARCH AND REPLACE <<Organization name>> Search for any << or >> as your input will be required Also review any yellow highlighted text


Page 76

Business Justification Document for Service Level Management The document is not to be considered an extensive statement as its topics have to be

generic enough to suit any reader for any organization.

However, the reader will certainly be reminded of the key topics that have to be

considered.

This document serves as a reference for HOW TO APPROACH THE TASK OF SEEKING FUNDS for the implementation of the Service Level Management process. This document provides a basis for completion within your own organization.

Service Level Management Business Justification A strong enough business case will ensure progress and funds are made available for

any IT initiative.

This may sound like a bold statement but it is true. As IT professionals we have (for too

long) assumed that we miss out on funds while other functional areas (e.g. Human

resources and other shared services) seem to get all that they want.

However, the problem is not with them, it’s with US. We are typically poor salespeople

when it comes to putting our case forward.

We try to impress with technical descriptions, rather than talking in a language that a

business person understands.

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 77

For example:

We say We should say We have to increase IT security controls, with the implementation of a new firewall.

Two weeks ago our biggest competitor lost information that is now rumored to be available on the internet.

The network bandwidth is our biggest bottleneck and we have to go to a switched local environment.

The e-mail you send to the other national managers will take 4 to 6 hours to be delivered. It used to be 2 to 3 minutes, but we are now using our computers for many more tasks.

Changes to the environment are scheduled for a period of time when we expect there to be minimal business impact.

We are making the changes on Sunday afternoon. There will be less people working then.

Doesn’t that sound familiar?

To help reinforce this point even further, consider the situation of buying a new fridge.

What if the technically savvy sales person wants to explain “the intricacies of the tubing

structure used to super cool the high pressure gases, which flow in an anti-clockwise

direction in the Southern hemisphere”.

Wouldn’t you say “too much information, who cares – does it make things cold?”

Well IT managers need to stop trying to tell business managers about the tubing

structure and just tell them what they are interested in.

So let’s know look at some benefits of Service Level Management. Remember that the

comments here are generic, as they have to apply to any organization.

Notes/Comments/Relevance The most important aspect of Service Level Management is the monitoring and delivery of services that lead to increasing satisfaction levels of customers. (Note in ITIL terms the Customer is the person who “pays” for the IT Service)


Page 78

With Service Level Management we focus on meeting the Service Level Requirements specified to us by customers. The SLR gives us a blueprint to check our own Service Delivery against. IT Services delivered that have no corresponding SLR may in fact be surplus to business requirements.

Service Level Management forces us into the creation of targets and metrics against which we can measure performance. If it can’t be measured it can’t be managed.

Through the process of Service Level Management we can develop a common language of understanding between IT and Customers. The process of establishing and monitoring performance levels means that when IT and business people discuss IT related issues they are in fact talking about the same thing (and not – as often happens – talking at odds with each other. For example if a meeting is held to discuss the Service Level Agreement for the provision of E-mail services then there is common ground for discussion.

Service Level Management also ensures that we have clearly defined roles and responsibilities. This is a clear benefit in that we can easily identify those involved with negotiations, escalations, monitoring and reporting. Even if one person performs many different roles within the process we can clearly articulate what these are. (importantly, the process also allows us to document customer responsibilities as well as IT)

The monitoring aspect of SLM is the perfect way to discover weak or potentially weak areas of Service Delivery. Ideally, identified in advance so that remedial action can be taken (e.g. Service Improvement Plan – SIP)


Page 79

SLM underpins supplier management (and vice versa) - in cases where services are outsourced the SLAs are a key part of managing the relationship with the third-party - in other cases service monitoring allows the performance of suppliers (internal and external) to be evaluated and managed

When we create Service Level Agreements – the most widely known single activity of Service Level Management - we generally include a section on Pricing. The SLA then becomes the basis of charging for IT Services (Note that IT Service Managers must be able to clearly articulate the difference between cost and value – cost is discussed in absolute monetary terms; value is a discussion regarding potential business impact).

An important, but often overlooked part of this process is the identification of weaknesses in the use of IT Services from the organization end-user population. Monitoring the nature of calls for support and general communication can help us to identify such weaknesses and therefore suggest education programs that will address the lack of knowledge and skill.

Having a continuous improvement philosophy regarding IT Service delivery ensures that

the IT Department is (a) looking to reduce service disruptions and (b) decrease the

overall cost of service delivery (without compromising the quality).


Page 80

freya.dixon

Blank


Page 81

Organizing for Service Design – Roles & Responsibilities To enable the Service Design phase to be successful, it is essential that the relevant

roles and responsibilities are defined, within the organization of various activities.

When designing a service or a process, it is imperative that all the roles are clearly

defined. A trademark of high performing organizations is the ability to make the right

decisions quickly and execute them effectively. Whether the decision involves a

strategic choice or a critical operation, being clear on who has input, who decides and

who takes action will enable the company to move forward rapidly.

The RACI model is beneficial in enabling decisions to be made with pace and

confidence. RACI is an acronym for the main roles of:

Responsible – person or people responsible for getting the job done.

Accountable – only one person can be accountable for each task.

Consulted – people who are consulted and whose opinions are sort.

Informed – people who are kept up-to-date on progress.

Occasionally an extended version of RACI is used called RACI-VS, with two further

roles as follows:

Verifies – person or group that checks whether the acceptance criteria have been met.

Signs off – person who approves the V decision and authorizes the product hand-off.

This could be the Accountable (or A) person.

A third variation of the RACI model is RASCI, where the S represents Supportive. This

role provides additional resources to conduct the work, or plays a supportive role in

implementation, for example. This could be beneficial for IT service implementation.

The RACI chart shown below in Table 1 shows the structure and power of RACI

modelling with the activities down the left-hand side including the actions that need to

be taken and decisions that must be made. Across the top, the chart lists the functional

roles responsible for carrying out the initiative or playing a part in decision making.


Page 82

Whether RACI or some other tool or model is used, the important thing is to not just

leave the assignment of responsibilities to chance or leave it to the last minute to

decide. Conflicts can be avoided and decisions can be made quickly if the roles are

allocated in advance.

To build a RACI chart the following steps are required:

• Identify the activities/processes

• Identify/define the functional roles

• Conduct meetings and assign the RACI codes

• Identify any gaps or overlaps – e.g. where there are two R’s or no R’s

• Distribute the chart and incorporate feedback

• Ensure that the allocations are being followed.

Table 1 Example RACI matrix

Director service management

Service Level Manager

Problem Manager

Security Manager

Procurement Manager

Activity 1

AR

C

I

I

C

Activity 2

A

R

C

C

C

Activity 3

I

A

R

I

C

Activity 4

I

A

R

I

Activity 5

I

I

A

C

I


Page 83

Functional Roles Analysis

• Many A’s: are duties segregated properly? Should someone else be

accountable for some of these activities? Is this causing a bottleneck in some

areas that will delay decisions?

• Many R’s: Is this too much for one function?

• No empty spaces: Does this role need to be involved in so many tasks?

• Also, does the type or degree of participation for this role’s qualifications?

Activity Analysis

• More than one A: only one role can be accountable.

• No A’s”: at least one A must be assigned to each activity.

• More than one R: too many roles responsible often mean that no one takes

responsibility. Responsibility may be shared, but only if roles are clear.

• No R’s: at least one person must be responsible.

• Many C’s: is there a requirement to consult with so many roles? What are the

benefits and can the extra time be justified?

• No C’s and I’s: are the communication channels open to enable people and

departments to talk to each other and keep each other up-to-date .


Page 84

Skills & Attributes The specific roles within ITIL Service Management all require specific skills, attributes

and competences from the people involved to enable them to work effectively and

efficiently. However, whatever role, it is imperative that the person carrying out that

role has the following attributes:

• Awareness of the business priorities, objectives and business drivers

• Awareness of the role IT plays in enabling the business objectives to be met

• Customer service skills

• Awareness of what IT can deliver to the business, including latest capabilities

• The competence, knowledge and information necessary to complete their role

• The ability to use, understand and interpret the best practice, policies and

procedures to ensure adherence.

The following are examples of attributes required in many of the roles, dependent on

the organization and the specific role:

Management skills – both from a person management perspective and from the

overall control of process.

Meeting skills – to organize, chair, document and ensure actions are followed up

Communications – an important element of all roles is raising awareness of the

processes to ensure buy-in and conformance. An ability to communicate at all levels

within the organization will be imperative.

Articulate - both written, for reports etc., and verbal


Page 85

Negotiation – required for several aspects, such as procurement and contracts

Analytical – to analyse metrics produced from the activity.

More information about the skills and competences of these roles can be found within

the Skills Framework for the Information Age (SFIA – www.sfia.org.uk)

Service Level Manager

The Service Level Manager has responsibility for ensuring that the aims of Service

Level Management are met. This includes responsibilities such as:

• Keeping aware of changing business needs

• Ensuring that the current and future service requirements of customers are

identified, understood and documented in SLA and SLR documents.

• Negotiating and agreeing levels of service to be delivered with the customer

(either internal or external); formally documenting these levels of service in

SLA’s.

• Negotiating and agreeing OLA’s and, in some cases, other SLA’s and

agreements that underpin the SLA’s with the customers of the service.

• Assisting with the production and maintenance of an accurate Service Portfolio,

Service Catalogue, Application Portfolio and the corresponding maintenance

procedures.

• Ensuring that targets agreed within underpinning contracts are aligned with SLA

and SLR targets.

• Ensuring that service reports are produced for each customer service and that

breaches of SLA targets are highlighted, investigated and actions taken to

prevent their recurrence.

• Ensuring that service performance reviews are scheduled, carried out with

customers regularly and are documented with agreed actions progressed.

• Ensuring that improvement initiatives identified in service reviews are acted on

and progress reports are provide to customers


Page 86

• Reviewing service scope, SLA’s, OLA’s and other agreements on a regular

basis, ideally at least annually.

• Ensuring that all changes are assessed for their impact on service levels,

including SLA’s, OLA’s and underpinning contracts, including attendance at

CAB meetings if appropriate.

• Identifying all key stakeholders and customers

• Developing relationships and communication with stakeholders, customers and

key users.

• Defining and agreeing complaints and their recording management, escalation,

where necessary, and resolution

• Definition recording and communication of all complaints

• Measuring, recording, analysing and improving customer satisfaction.


Page 87

SLM Process Manager

IT Services Role, Responsibilities




Release Date:

Note: SEARCH AND REPLACE <<Organization name>> Search for any << or >> as your input will be required



Page 88

Detailed responsibilities of the Service Level Management process owner The Service Level Manager…..

Description Notes/Comments 1.

Will design, maintain and review a structure for the process that covers the interactions of the people involved and the expected content of Service Level Management related documents (involving IT and Customers) AND Coordinates any required Service Improvement Plans/Programmes to eradicate falling Service Delivery performance

2. Will coordinate process reviews utilizing independent parties to provide an objective view on the simplicity of the process and areas for improvement. Will be responsible for implementing any design improvements identified.

3. Will establish, maintain and review:

• Service Level Agreements with the business Customer (including a decision on SLA Structure).

• Operational Level Agreements with the IT provider • Underpinning Contracts with third party providers.

4. Is responsible for the creation, maintenance, marketing and distribution of the Service Catalog (which documents the IT Services offered by the organization)

5. Will control and review:

• Any outstanding process related actions • Current targets for service performance • Performance against SLAs, OLAs and UCs

6. Make available relevant, concise reports that are both timely and readable for Customers and IT providers.

Use the notes/Comments column in different ways. If you are looking to apply for a process role, then you can check yourself against the list (with ticks or look to update your resume).

If you are looking to appoint a process manager or promote someone from within the organization you can make


Page 89

Detailed skills of the Service Level Management process owner The Service Level Manager….. Description Notes/Comments 1.

The Service Level Manager will display a communication style based around listening and demonstrable genuine interest. Ability to use and apply valuable information gained from customers.

2. High degree of people/relationship management focus and an ability to deal with an administrative workload. Will also tend to be balanced in negotiations – almost to the point of neutrality during discussions between the customer and the IT Service Provider.

3. The Service Level Manager will take an active interest in learning about services offered by external and internal providers. The manager will be interested in understanding how services are provided, rather than just accepting a marketing statement.

4. The Service Level Manager must have good oral and presentation skills. They are a “champion” for this process and must display an air of confidence, without arrogance.

5. The Service Level Manager must be able to communicate with people at all levels of the organization; this is one contributing factor that also will require a high degree of understanding of human emotion and resistance.

6. The process manager must be able to demonstrate ways to “do things differently” that will improve the process. They must not be risk adverse, but must be very risk conscious.

7. Although not a highly numeric role, the selected person must be able to understand the basics of supply and demand, with a commonsense attitude to service charging and a grip on basic statistical analysis.

8. The process manager will need to be able to engage in technical discussions with technical people (to ensure credibility) and to engage in business discussions with business people, about those technical issues (of course in non-technical terms).

Use the notes/Comments column in different ways. If you are looking to apply for a process role, then you can check yourself against the list (with ticks or look to update your resume).

If you are looking to appoint a process manager or promote someone from within the organization


Page 90

freya.dixon

Blank


Page 91

Customer Based SLA

IT Services Customer Based SLA




Release Date:


Page 92

Customer Based Service Level Agreement (SLA) The document is not to be considered an extensive statement as its topics have to be



considered.

This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND THE CUSTOMER OF IT SERVICES (Covering all the IT Services they use). This document provides a basis for completion within your own organization. The customer based SLA is usually preferred by customers as it allows a single

document to cover all the IT Services that they use. It means less administration time

spent in negotiating different documents and generally only requires a single

representative to participate on behalf of the business.

An agreement with an individual Customer group, covering all the services they use.

For example, agreements may be reached with an organization’s Finance Department

covering, say, the Finance System, the Accounting System, the Payroll System, the

Billing System, the Procurement System and any other IT systems that they use.

Advantage

An agreement with an individual Customer groups could cover all of the services they use. Customer based SLA

Disadvantage

An inability to deal with differing requirements amongst users in the same customer group.

Customer

Service A

Service B

Service C


Page 93

The following form can be used as the Customer Based SLA document. The SLA does

not have to be in a lengthy written format and in fact it is more likely to be adopted if it

is kept concise, with only salient details.

With regard to Customer Based SLA the following points should be addressed:

Overall SLA Information

Areas to address Comments/Examples Time Frame/Notes/Who

Description of the “agreement”

Brief description of the contents of this SLA Note: the SLA may cover several IT Services. Use this section simply as an Executive summary. Do not try to describe each service here.

Reference number


Owner

Functional role description of who is responsible for this SLA (who would participate in a review of this document?) Representatives from customer and IT. (Special tip: Avoid using names as it dates the document quickly)

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 94

Customer definition

List and/or describe the customers that are considered for in this SLA.

SLA Validity period

Duration that this SLA is expected to remain in place before it is reviewed.

SLA Review Procedure

The process for reviewing the SLA and who is involved. Special Tip: Avoid using people’s names and use role descriptions to avoid dating the document.


SLA Creation Date SLA Last Modify Date

Specific Service Information

(Duplicate the following table for each service to be covered in this SLA).


Service Name


Service Description (Business) (refer to end of table for technical considerations)

Briefly describe the primary function of the service. Use language that is business user friendly. (eg. instead of “NT Server, with 2Gb RAM and 500Gb of disk storage” – we would say “large central server designed for all customers to use and share information”)


Page 95

Service Expectation Level

This is a unique concept to this SLA design template. Far too often we write descriptions of IT Services in a clinical fashion. These clinical descriptions set an expectation for the customer/end-user about the IT Service. Quite often the description is interpreted by the reader in a way not intended by the writer. Use this section to set the expectations of the reader. If you feel that there could be some interruptions to service delivery, because the service is relatively new, then document that here. However, remember that using the reason “new service” has only a limited life-span.


Briefly list any considerations regarding security considerations for this service. Are there any differences in the level of accessibility for different people/roles for this service? (try to use role descriptions – instead of names)?

Service Target Response priorities

If the SLA accommodates different priorities they must be listed here, with a description on the type of service that each priority level should receive.

Service Target Response time

Here we document the agreed response time for the different priority levels.


Page 96

Service Support Hours (Availability)

Consider marginally longer support hours (if less than 24) Maximum number of accepted outages. Minimum percentage availability. Maximum number of errors or reruns.

Service Out of Hours support procedure

Are the in hours support staff the same as out of hours? Phone numbers and what information will be required when support is called. What does the user do if the nominated person is not available?

Service Charging policy

Do we require external staff to only act if they have a validated cost code for work? Are there any special aspects of the work that has to be recorded for later charging?

Service Metrics for performance

What will be the performance numbers for the work performed under this UC? Will the expected performance be higher than negotiated in the SLA to allow a safety margin?

Service Breach Clause

Perhaps your organizational culture is built upon imposing penalties for poor performance. If this is the case, then the penalties for failing to meet the stated metrics must be listed here. If the SLA is not to have a penalty focus, then simply remove this line.


Page 97

Continuity Considerations (should be linked to the IT Service Continuity Plan)

If the agreed support hours cannot be met, then it is necessary to invoke a continuity option for this service. The definition of when this invocation should occur will be listed here. Cross-referencing to the IT Service Continuity Plan is also required.

UC Cross references

Reference number to related and closely coupled UCs

OLA Cross references

Reference number to any closely coupled agreements with internal IT department


In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalogue or Technical Specification.

Notes & Comments

NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF AN SLA THAT WILL COVER ALL SITUATIONS FOR ALL ORGANIZATIONS. THIS TEMPLATE HOWEVER, DOES PROMPT THE READER TO CONSIDER THE MOST CRITICAL AREAS OF AN SLA and IT PROVOKES THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED ON INDIVIDUAL NEEDS.


Page 98

freya.dixon

Blank


Page 99

Service Based SLA

IT Services Service Based SLA




Release Date:


Page 100

Service Based Service Level Agreement (SLA)

The document is not to be considered an extensive statement as its topics have to be



considered.

This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND THE CUSTOMER OF IT SERVICES, FOR A SINGLE SERVICE. This document provides a basis for completion within your own organization. The service based SLA is usually preferred by IT as it allows a single document to

cover a single service for all end-users of that service. It means less administration

time spent in negotiating different documents with different customers and less time

spent on worrying about accommodating different requirements amongst users.

Advantage Just one SLA document could be agreed for all Customers/end users of a single service.

Service based SLA

Disadvantage Inability to satisfy the customers that have differing requirements of the service being addressed.

Service

Customer A

Customer B

Customer C

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 101

The following form can be used as the Service Based SLA document. The SLA does

not have to be in a lengthy written format and in fact it is more likely to be adopted if it

is kept concise, with only salient details.

With regard to Service Based SLA the following points should be addressed:


(Duplicate the following table for as many services to be covered in this SLA).



Brief description of the contents of this SLA Note: the SLA will cover only ONE IT Service, but end users from many areas. Use this section simply as an Executive summary.

Reference number


Owner

Functional role description of who is responsible for this SLA (who would participate in a review of this document?). Representatives from customer and IT. (Special tip: Avoid using names as it dates the document quickly)

Service Name



Page 102










Page 103


Here we document the agreed response time for the different priority levels set.












Page 104



SLA Validity period






UC Cross references





In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalog or Technical Specification.

Notes & Comments


Page 105

freya.dixon

Blank


Page 106

Customer Information


Customer definition

List and/or describe the customers that are included in this SLA.

It is most likely that the customers will be all end-users of IT services in the organization. However, the SLA for this service may be only for particular function holders that are spread throughout the organization).

NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF AN SLA THAT WILL COVER ALL SITUATIONS FOR ALL ORGANIZATIONS.

THIS TEMPLATE HOWEVER, DOES PROMPT THE READER TO CONSIDER THE MOST CRITICAL AREAS OF AN SLA and IT PROVOKES THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED ON INDIVIDUAL NEEDS.


Page 107

freya.dixon

Blank


Page 108

Multi Level SLA’s

IT Services Multi-Level Based SLA




Release Date:


Page 109

Multi-Level Based Service Level Agreement (SLA) The document is not to be considered an extensive statement as its topics have to be



considered.

This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND THE CUSTOMER OF IT SERVICES, FOR MULTIPLE SERVICES. This document provides a basis for completion within your own organization. The multi-level based SLA is usually preferred by IT as it allows a single document to

cover a single service for all end-users of that service. It means less administration

time spent in negotiating different documents with different customers and less time

spent on worrying about accommodating different requirements amongst users.

Advantage

This structure allows SLAs to be kept to a manageable size, avoids unnecessary duplication, and reduces the need for frequent updates.

Multi-Level based SLA

Disadvantage It requires more time to negotiate and obtain agreement than other structures.

Customer

Service A

Service B

Service C Customer

SERVICE D

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 110

(The following form can be used as the Multi-Level Based SLA document. The SLA

does not have to be in a lengthy written format and in fact it is more likely to be

adopted if it is kept concise, with only salient details)

SLA Information



Brief description of the contents of this SLA Note: the SLA will cover only ONE IT Service, but end users from many areas. Use this section simply as an Executive summary.

Reference number


Owner

Functional role description of who is responsible for this SLA (who would participate in a review of this document?). Representatives from customer and IT. (Special tip: Avoid using names as it dates the document quickly)


Page 111


(Duplicate the following table for as many services to be covered). Areas to address Comments/Examples Time

Frame/Notes/Who Service Identification Code (This code can be cross-referenced in the Customer information table).

A unique reference number for this service.

Service Name







Page 112






Here we document the agreed response time for the different priority levels set.








Page 113







SLA Validity period







Page 114

UC Cross references





In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalog or Technical Specification.

Notes & Comments

Customer Information (Duplicate the following table for as many customers to be covered).


Customer definition

List and/or describe the customers that are included in this SLA. It is most likely that the customers will be all end-users of IT services in the organization. However, the SLA for this service may be only for particular function holders that are spread throughout the organization).

Applicable Services

Description of Service and/or Service identification code/s

NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF AN SLA THAT WILL COVER ALL SITUATIONS FOR ALL ORGANIZATIONS. THIS TEMPLATE HOWEVER, DOES PROMPT THE READER TO CONSIDER THE MOST CRITICAL AREAS OF AN SLA and IT PROVOKES THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED ON INDIVIDUAL NEEDS.


Page 115

freya.dixon

Blank


Page 116

Business and IT Service Mapping

IT Services Business and IT Service Mapping




Release Date:



Page 117

Document Control Author Prepared by <name and / or department>

Document Source This document is located on the LAN under the path:

I:/IT Services/Service Delivery/Business and IT Service Mapping/

Document Approval This document has been approved for use by the following:

• <first name, last name>, IT Services Manager

• <first name, last name>, IT Service Delivery Manager

• <first name, last name>, National IT Help Desk Manager

Amendment History


Distribution List When this procedure is updated the following copyholders must be advised through

email that an updated copy is available on the intranet site:

<<organization name>> Business Unit

Stakeholders

IT


Page 118

Introduction Purpose The purpose of this document is to provide IT departments with an understanding of

how the IT Services provided map to the organization’s business processes.


• details of each Business Process and the corresponding IT Service provided by

the IT departments within the organization:

• description of business process

• description of service

• business contacts

• service contacts

Note: It is assumed for each Business Process and IT Service described in this

document that the supporting back-end technology is already in place and operational.

Audience This document is relevant to all staff in <<organization name>>

Ownership IT Services has ownership of this document in conjunction with nominated Business

Representatives.

Related Documentation The following documents may help you to complete or understand the purpose of this

document:

• Relevant SLA and procedural documents

• Relevant IT Services Catalogue

• Relevant Technical Specification documentation

• Relevant Functional Specification documentation

• Relevant User Guides and Procedures


Page 119

Executive Overview In the past organization’s IT Services functions have generally grown and developed

into large complex environments. Unfortunately this growth has not always been as

structured and pre-planned as it should have been.

The result has been an IT department not having a very clear picture of all the services

they currently provide, and with no accurate profile of the actual customers for each of

these services.

With increasing demands being placed on IT services and increasing reliance on IT

systems, it has become imperative for the IT department to establish an accurate

picture of the services it provides and to whom it provides them.

This document describes an approach for mapping IT Services to the Business

Process. That is, mapping what services are provided by IT to the business areas that

use them.

Mapping Business Process and IT Service: An approach Most organizations now understand the benefits of having Information Technology (IT)

throughout their structure. Few realize the potential of truly aligning the IT

department’s objectives with the business objectives. However, more and more

organizations are beginning to recognize IT as being a crucial delivery mechanism of

services to their customers.

When the IT services are so critical, steps must be in place to ensure that the IT group

adds value and delivers consistently.

In line with this concept, the first step in mapping IT Services to the needs of the

business is to understand the organization.

An organization starts with a Mission Statement. The Mission Statement for an

organization defines its reason for being. Once we capture the Mission Statement, the

next thing to look at is the Vision Statement.


Page 120

The Vision Statement defines where it is that the organization wants to go. By

understanding where the organization wishes to position itself within its market space,

then we can start looking at how its short term and long term objectives align with this.

At this point we need to see the “objectives and strategy” of the organization. By

having this information, IT departments are more likely to be aware of the pressing

business issues and needs that may impact on the services that they provide. For

example, the organization may have an objective of expanding its business into new

markets within the next 12 months, requiring additional offices and staff. The direct

impact on IT departments would be the successful planning of capacity of new IT

Services, the successful planning of how to change our current services to meet the

demands of the business, and being flexible enough to meet these demands.

However, an objective is not sufficient enough to determine how IT departments

should be delivering its services. The organization will meet these objectives by

changing, enhancing or creating new business processes. For example,

Administration staff may need additional resources, a new ordering package may be

required, or perhaps a new billing process needs to be implemented to meet these

objectives.

Therefore, after capturing the organizational objectives, we need to understand how

these map to current business process, if the current business processes are

changing or if they are becoming obsolete and if there will be any new business

processes.

This is where the IT departments need to capture the Business Processes being used

by the organization.

Once the IT departments have a clear view of each of the business units involved in

the business process, we need to capture the fact that the business processes need

one or more IT services (eg. CRM application, e-mail, word processing, financial tools)

to function.


Page 121

Each of these IT services runs on IT infrastructure. This is where IT departments now

map the IT Services to those Business Processes listed above.

With this information IT Departments will now be able to clearly see how their IT

Infrastructure / IT Services supports the business. This allows IT to better deliver IT

aligned Services to the organization.

A simple model for this approach is illustrated below.

• What are the Objectives of the organization? What is its Mission and Vision?

• What Business Processes are in place or will be in place to meet these needs?

• What IT Services are needed or in place to service the Business Processes?

Business Objectives

Business Processes

IT Services


Page 122

Mission Statement A mission statement describes the reason for the organization’s being. Without an

understanding of the mission statement of an organization, it becomes hard to define

what it is that the organization is trying to achieve.

In this section of the document capture the mission statement of the organization. It is

important to show that the IT department is aware of the business.

Vision Statement In this section, document the Vision statement for the organization.

Below is a text example of what may be included in this section.

Listed below is the Vision Statement for <<organization name>>:

• Quality Care

• Convenient Service

• Good Experiences

• Care at Competitive Prices

• Service You'll Recommend to Friends and Family

These are the major goals of the staff at <<organization name>>. With over xxx

services and xxx staff, we constantly strive to provide the highest-quality service

throughout the xxxxxxxx. >>

Business Process Summary The below table is an example of a Business Process Summary Table. Columns and

Rows can be added as needed. A more detailed breakdown of each process name is

provided in the following pages.

<<

Business Process Name: The name of the process if available

Process Owner: The name of the Department head or Business

Representative for the process

Description: A brief description of the process


Page 123

Department(s): The Department(s) that is involved or uses this process

Parent Process: Any process that may be considered a lead into this

process or is seen has having a higher business criticality

Triggers: What causes the process to start? This is important as IT

can then determine if and how their Services interact with

other business process or external organizations.

>>

BUSINESS Process Name

Process Owner

Description Department(s) Parent Process

Triggers

Business Process A This section of the document should be repeated for each Business Process.

Department Name of the department

Process Name of the process, and official abbreviation, if any

Process Owner Name of the Department head or person responsible for ensuring the effectiveness

and efficiency of the process.


Page 124

Description Briefly explain the purpose of the business process.

Parent Business Activity/Process Name of the parent business activity or process, if any

Primary Product(s) List the primary product(s), and explain if necessary. Identify the customer for each

primary product.

Trigger(s) List the event(s) that trigger the process. (Triggers can be a calendar date, as well as

an actual event.)

Sub-processes If the process is subdivided, list the sub-processes here.

Standard Path Events/Activities List the important activities and/or events that occur as part of the standard path for

this process. If an activity or event occurs in a specific sub-process, identify the sub-

process that includes the activity/event. Note any locations where an alternative path

breaks off from the standard path.

Alternative Path Events/Activities List the important activities and/or events that occur as part of the alternative path for

this process, beginning with a note on where the alternative path breaks off from the

standard path, and ending with a note on where the alternative path rejoins the

standard path, if it does. If an activity or event occurs in a specific sub-process, identify

the sub-process that includes the activity/event.

Inputs List the inputs to the process, and explain if necessary. Identify the source of the input.

If the input is specific to a sub-process, identify the sub-process.


Page 125

Secondary Products List the by-products, or minor outputs that result from the process. Identify the

customer for each output. If the secondary product is specific to a sub-process, identify

the sub-process.

Participants List the participants (actors) in the process, and explain their function briefly. If the

participant is active only in a specific sub-process, identify the sub-process.

IT Services The following section provides a table for capturing those IT Services that help support

the business process described in this section.

<<

Fields:

• IT Service: In this field capture the name of the IT Service. A

likely source of for this information would be the IT

Service Catalogue.

• Description: Write a brief description about the service.

• IT Service Owner: List any responsibilities for this IT Service. This

would include the owner of the IT Service and any

additional support personnel that are involved in the

deliver of the IT Service.

• Hours of Availability: List the hours of support for the particular IT Service.

Eg. 24 hours x 7 Days per week, Monday – Friday:

8.00am – 6.00pm, etc.


Page 126

• Contract: Is the IT Service provided under the agreement of a

contract? If so, it is important to capture any

contracts that may be in place for the IT Service.

Contracts will have a direct impact on how the IT

Service is delivered.

• Service Level Agreements: List any applicable SLAs for the IT Service.

• Impact: If the particular IT Service was unavailable, how

would this impact on the Business Process.

>>

This table should be used on a landscape page layout.

IT Service Description IT Service Owner

Hours of Availability

Contract Service Level Agreements

Impact


Page 127

Business Process B

Department

Process

Process Owner

Description

Parent Business Activity/Process

Primary Product(s)

Trigger(s)

Sub-processes

Standard Path Events/Activities

Alternative Path Events/Activities

Inputs

Secondary Products

Participants

IT Services

IT Service Description IT Service Owner

Hours of Availability

Contract Service Level Agreements

Impact


Page 128

Business Process and IT Service Summary

This section provides a summary matrix table of the business processes and their

corresponding IT Services.

This is a comprehensive summary table designed to be tailored for your needs. If

necessary add or remove rows and columns as needed. A simpler matrix may be

just as effective for your needs.

The table breaks down the IT Services and offers you the ability to capture the

owner of the IT Service, the impact of the service on the business process and the

agreed service hours.

The impact is an arbitrary value that IT and the business need to agree upon.

These values may be defined within the Service Catalogue or the Service Level

Agreements.

The table also breaks down the Business Processes and offers you the ability to

capture the department(s) that are involved in that particular business process, the

business owner of the process, and the business rating.

The Business Owner may be hard to define in an organization, in this instance

there maybe a number of owners of the process which would generally be made

up of the Department heads.

The Business Rating is also an arbitrary value that the business needs to agree

upon. In most instances each department will rate their business processes Critical

or Very High. The easy way to determine the Business Rating of the process would

be to ascertain if the business could still deliver its services if that business process

was unavailable for a period of time.


Page 129

Business Process A Business Process B

Department Owner Business Rating

Department Owner Business Rating

IT Services Accounting <<Business Process Owner>>

Very High Admin <<Business Process Owner>>

Medium

Owner <<IT Service Owner>>

Impact Very High

Service A

Service Hours

24 x 7


Impact High Service B

Service Hours

Mon-Fri: 8am - 6pm


Impact Medium Service C

Service Hours

Mon-Sat: 6am - 6pm


Impact Low Service D

Service Hours

Mon-Fri: 6am - 10pm

Appendices List any appendices needed in conjunction with this document.

Terminology IT Infrastructure: includes hardware, software, procedures, policies,

documentation, etc.


Page 130

Operational Level Agreement

IT Services Operational Level Agreement




Release Date:


Page 131

Operational Level Agreement (OLA) The document is not to be considered an extensive statement as its topics have to

be generic enough to suit any reader for any organization.


considered.

This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND THE IT DEPARTMENT. This document provides a basis for completion within your own organization. There is a common misconception that the Service Level Management Process owner must be a member of the IT Department. This is not the case and quite often the best person for the role is someone with no bias towards IT. For example, a Human Resource Manager would do well in a role that has such a high degree of communication required.

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 132

(The following form can be used as the OLA document. The OLA does not have to

be in a lengthy written format and in fact it is more likely to be adopted if it is kept

concise, with only salient details)

With regard to OPERATIONAL LEVEL AGREEMENTS (OLAs) the following points

should be addressed:


Link to parent Service Level Agreement

Cross reference to the “parent” SLA.

Description of Service

Brief description (should be taken from SLA)

OLA Reference number

Unique identifying number for the OLA (for inclusion in the Configuration Management Data Base – CMDB)

OLA Owner

Functional role description of who is responsible for this OLA (who would participate in a review of this document) (Special tip: Avoid using names as it dates the document quickly)

OLA Parties involved

Within the IT department perhaps there are different functional parties involved. List them here with a brief description of their involvement.


Page 133

OLA Target Response priorities (reflected in parent SLA)

If the OLA caters for different priorities they must be listed here, with a description on the type of service that each priority level should receive.

OLA Target Response time (reflected in parent SLA)

Consider quicker response time to allow for delays

OLA Support Hours (reflected in parent SLA)

Consider marginally longer support hours (if less than 24)

OLA Out of Hours support procedure (reflected in parent SLA)

Are the in hours support staff the same as out of hours. Phone numbers and what information will be required when support is called. What does the user do if the nominated person is not available?

OLA Charging policy (reflected in parent SLA)

Do we require staff to only act if they have a validated cost code for work? Are there any special aspects of the work that has to be recorded for later charging?

OLA Metrics for performance (reflected in parent SLA)

What will be the performance numbers for the work performed under this OLA? Will the expected performance be higher than negotiated in the SLA to allow a safety margin?


Page 134


Reference number to other closely coupled OLAs

UC Cross references

Reference number to any closely coupled agreements with external suppliers

OLA Validity period

Duration that this OLA is expected to remain in place before it is reviewed.

OLA Review Procedure

The process for reviewing the OLA and who is involved. Special Tip: Avoid using people’s names and use role descriptions to avoid dating the document.


OLA Creation Date OLA Last Modify Date

Notes & Comments

(Duplicate the above table for the number of OLAs to be created)


Page 135

freya.dixon

Blank


Page 136

Service Level Requirements

IT Services Service Level Requirements




Release Date:



Page 137

Service Level Requirements (SLR) The document is not to be considered an extensive statement as its topics have to



considered.

This document serves as a GUIDE FOR ESTABLISHING THE NEEDS OF CUSTOMERS WITH REGARD TO IT SERVICES. This document provides a basis for completion within your own organization. The document is made up of 3 sections. The first section allows you to briefly describe the service. The second section is where you capture user specific requirements (duplicate this section the number of times required). The third section allows you to cross reference the requirements uncovered in this study with other agreements/documents that may already exist.

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 138

(The following form can be used as an SLR interview or data gathering document.

The SLR document does not have to be in a lengthy written format and in fact it is

more likely to be adopted if it is kept concise, with only salient details)

With regard to understanding SERVICE LEVEL REQUIREMENTS (SLR’s) the

following points should be addressed:

Service Information


Unique SLR Reference #

Useful to cross reference to related Service Level Agreements, OLAs or Underpinning Contracts

Related SLA Reference #

For cross referencing to the created Service Level Agreement (filled in after the SLA is created).

Service Name Preferably use a name that is common language in the organization (not a technical name).

Service Description (Business) (refer to end of table for technical considerations)



Page 139

Customer Information

(Duplicate the following table for as many services to be covered in this SLR).


Customer Definition and date of discussion

Whether the customer is an; Individual Individual representing a group of users A group meeting to discuss service requirements. It should be documented here. The date is an important consideration as requirements will definitely change over time. You can use this form or the SLA that will be derived from it as a starting point for the next review.

Customer Expectations



Page 140


Briefly list any considerations regarding security considerations that the representative has for this service. Should there be differences in the level of accessibility for different people/roles for this service? (try to use role descriptions – instead of names). Be careful of using generic terms like “confidential”. Confidential can be interpreted different ways (eg. Confidential to the individual or for the functional group or for a peer group).


What sort of priority levels of support need to be in place for this service? Are there categories of end user for the service that require differing levels of support? (Eg. Group A requires phone support only, Group B needs face-to-face support)


Against the levels/priorities defined are there corresponding response times for the different priorities? (Eg. Group A needs immediate response, Group B needs a 2 hour response)


What are the REALISTIC support hours required for this service? Impress upon the representatives understand that IT staff also have day jobs and do not automatically start work, after they have gone home!! Get numbers: What is the maximum number of accepted outages, in a


Page 141

given time period? What would be an acceptable number of errors or reruns?


Is after hours support required? To what degree is the support needed (full support, partial, best effort)?


Does the representative have any expectation regarding charges for Service Delivery? Be careful with this question as it may create some defensive reaction from the representative (what do you mean I have to pay for the service? I never have in the past!!) The question of charging is generally a more strategic decision made by business managers. How is charging to be implemented? (eg. Per user, per transaction) What is the customer budget with regard to this service?


Can the representative help you to define metrics for this service? Does the representative have a way that they classify the service? (that we may have missed – as our focus tends to be more on technical issues)


Does the representative have any thoughts regarding penalties that should be imposed if the service cannot be delivered according to agreed expectations? (Realistic!)


Page 142

Continuity Considerations

Does the representative have any expectations regarding how the service should be recovered in the event of an extended outage? Do they require immediate recovery, or can they work in a paper based mode for a period of time? Can the customer accept any loss of data? If yes, what is the roll back point (eg. 2 hours, 1 day, 1 week)?

Non-representative Information

(Duplicate the following table for the number of services that data is being gathered on).


SLA Cross Reference

Make a reference to any existing SLAs that may be able to be adapted or modified to meet this requirement.


In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalog or Technical Specification. You can use this section as a check that the service is in fact documented in the Service Catalog.

Notes & Comments


Page 143

NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF A DATA GATHERING EXERCISE FOR IT SERVICE DELIVERY REQUIREMENTS THAT WILL COVER ALL SITUATIONS FOR ALL ORGANIZATIONS. THIS TEMPLATE HOWEVER, DOES PROMPT THE READER TO CONSIDER THE MOST CRITICAL AREAS OF DATA GATHERING and IT PROVOKES THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED ON INDIVIDUAL NEEDS. (Duplicate the above table for the number of Services that requirements are to be gathered for)


Page 144

Service Options

IT Services Process: Service Level Management

Service Options



Release Date:



Page 145



I:/IT Services/Service Delivery/Service Level Management/Service Options


♦ <first name, last name>, IT Services Manager

♦ <first name, last name>, IT Service Delivery Manager

♦ <first name, last name>, National IT Help Desk Manager

Amendment History


Distribution List

When this procedure is updated the following copyholders must be advised


<Company Name> Business Unit

Stakeholders

IT


Page 146

Introduction Purpose The purpose of this document is to provide the IT Organization with a breakdown

of options for the Services listed in the Service Catalog


• Service Options

• <<any additional items that you want>>

Audience This document is relevant to all staff in <company name>


Related Documentation Include in this section any related Service Level Management reference numbers


• Implementation Plan / Project Plan

• Policies, Guidelines and Scope Document

• SLM Process Template

• Service Catalogue

Executive Overview Note:

The intent of this document is to provide a simple break down of options available

for IT Services.

This document is to be used in conjunction with Service Catalogue.


Page 147

Service Level Management Overview

Summarize the organization definition for crucial Service Level Management

components here.

The definition of an SLA is:

<< insert your company’s definition here >>

The definition of an OLA is:

<< insert your company’s definition here >>

The definition of a UC is:

<< insert your company’s definition here >> The definition of a service is:

<< insert your company’s definition here >> Service Options

The following table breaks down each service and the available options. This is a

template and is used to illustrate for the user of this document the available options

and structure to use when creating service options.

The below table should be created for each individual service offered in the

Service Catalogue.


Page 148

IT Service: Business Process:

IT Owner: Business Owner:

Service Criticality:

Business Process

Criticality:

Service Options Service Components

Platinum Gold Silver Bronze Default

Availability

Capacity

Response SLA

Recovery SLA

Service Hours

Recovery Options

Security

Pricing

Appendices

Include any applicable appendixes that are needed.

Terminology

Make sure that all terminology is captured and documented correctly.


Page 149

freya.dixon

Blank


Page 150

Underpinning Contracts

IT Services Underpinning Contracts




Release Date:


Page 151

Underpinning Contract (UC) The document is not to be considered an extensive statement as its topics have to



considered.

This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND AN EXTERNAL PROVIDER (THIRD PARTY) OF IT SERVICES. This document provides a basis for completion within your own organization. There is a common misconception that the Service Level Management Process owner must be a member of the IT Department. This is not the case and quite often the best person for the role is someone with no bias towards IT. For example, a Human Resource Manager would do well in a role that has such a high degree of communication required.

(The following form can be used as the UC document. The UC does not have to be

in a lengthy written format and in fact it is more likely to be adopted if it is kept

concise, with only salient details)

With regard to UNDERPINNING CONTRACTS (UCs) the following points should

be addressed:

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 152


Link to parent Service Level Agreement

Cross reference to the “parent” SLA.

Description of Service

Brief description (should be taken from SLA)

UC Reference number

Unique identifying number for the UC (for inclusion in the Configuration Management Data Base – CMDB)

UC Owner

Functional role description of who is responsible for this UC (who would participate in a review of this document?) (Special tip: Avoid using names as it dates the document quickly)

UC Parties involved

Within the external provider there may be different functional parties involved. List them here with a brief description of their involvement.

UC Target Response priorities (reflected in parent SLA)

If the UC accommodates different priorities they must be listed here, with a description of the type of service that each priority level should receive.

UC Target Response time (reflected in parent SLA)

Consider quicker response time to allow for delays


Page 153

UC Support Hours (reflected in parent SLA)

Consider marginally longer support hours (if less than 24)

UC Out of Hours support procedure (reflected in parent SLA)


UC Charging policy (reflected in parent SLA)


UC Metrics for performance (reflected in parent SLA)


UC Cross references

Reference number to other closely coupled UCs




Page 154

UC Validity period

Duration that this UC is expected to remain in place before it is reviewed.

UC Review Procedure

The process for reviewing the UC and who is involved. Special Tip: Avoid using people’s names and use role descriptions to avoid dating the document.


UC Creation Date UC Last Modify Date

Notes & Comments

(Duplicate the above table for the number of UCs to be created)


Page 155

freya.dixon

Blank


Page 156

Functional Specification

IT Services Functional Specification


Service: <service name>



Release Date:






Page 157

Document Control Author Prepared by <<name and / or department>>


I:/IT Services/Service Delivery/Functional Specifications/


• <<first name, last name>>, IT Services Manager

• <<first name, last name>>, IT Service Delivery Manager

• <<first name, last name>>, National IT Help Desk Manager

Amendment History


Distribution List When this procedure is updated the following copyholders must be advised


<<Organization name>> Business Unit

Stakeholders

IT


Page 158

Introduction Purpose The purpose of this document is to provide relevant Business Units with the

functional specifications of the range of services provided by IT Services to the

<<Organization name>> community.


details of each service provided by IT Services including:


• functional capabilities of the service

• user characteristics

• user operations and practices

• software and hardware interfaces


• details of procedures for the service

Note: It is assumed for each service described in this document that the supporting

back-end technology is already in place and operational.

Audience This document is relevant to all staff in <<Organization name>>


Related Documentation Include in this section any related Service Level Agreement reference numbers







Page 159

Executive Overview Describe the purpose, scope and organization of the Functional Specification

document.

Service Overview Service Description Describes briefly the reason for the service, and lists the most important features

and capabilities.

Also include the services relationship to the business processes.

Service functional capabilities This section presents a list of the functions that the service will be required to

perform.

Where the service comprises of several functional capabilities, a table may be

developed to illustrate these relationships. The list of functional capabilities may be

an updated version of the capabilities listed in the original “Service Level

Requirements” for this service.

(Refer to Service Level Requirements) User characteristics This section describes the intended users of the service in terms of job function,

specialized knowledge, or skill levels required.

This section should consider various user classes or profiles such as managers,

engineers, equipment operators, IT support staff, and network or database

administrators.

User operations and practices Describes how persons will normally use the service, and the tasks they will most

frequently perform.

Also covers how users might use the service on an occasional basis. Consider

using a formal “Use Case” to specify the end-users' expected use of the service.

This may also be derived from the Service Level Requirements.


Page 160

General constraints This section will list the limitations, user interface limitations, and data limitations of

the service. Includes items such as minimum availability, capacity, security needed

by the service to function.

It should also include maintenance requirements; more specifically the amount of

time and frequency the service will be unavailable due to maintenance and service.

Also, states if training is required for use of the system.

Assumptions This section lists any assumptions that were made in specifying the functional

requirements of this service.

Other services How does the service interact with other services?

Specific Function Descriptions This section is repeated for each function of the service. Some examples of

functions are: email sending or receiving, sorting or archiving email, virus checking

and scanning of email, and recovery of email services.

Description The description describes the function and its role in the service.

Inputs Describe the inputs to the function. Input validation strategy, allowed email types

and values are specified for each input.

Processing Describes what is done by the function. Cited here would be database definitions

where relevant, transaction algorithms or functions, flow of information etc.


Page 161

Outputs This section describes the outputs of the function. Where a user interface

description is relevant, it is included.

Reports generated are also defined.

External Interfaces The interfaces in this section are specified by documenting: the name and

description of each item, source or input, destination or output, ranges, accuracy

and tolerances, units of measure, timing, display formats and organization,

availability and capacity requirements and any relevant agreements that may

impact on the service.

User Interfaces Where necessary.

This section describes all major forms, screens, or web pages, including any

complex dialog boxes. This is usually best done via simulated, non-functioning

screen shots (such as PowerPoint slides), and may take the form of a separate

document.

The navigation flow of the windows, menus, and options is described, along with

the expected content of each window. Examples of items that could be included

are screen resolutions, color scheme, primary font type and size.

Discussion also includes how input validation will be done, and how the service will

be protected from security issues.

This section can be generic enough to describe simply the User Interfaces to the

functions of the service. Examples of items here would be client interface available,

web interface available, email interface available etc.

Hardware Interfaces Describes the components needed to provide the service, and also other output or

input devices such as printers or handheld devices.


Page 162

Software Interfaces This section describes any software that will be required in order for the service to

operate fully. Includes any developed software or commercial applications that

customers will be utilizing together with the planned service. Also describes any

software that the service will interact with such as operating system platforms

supported, file import and export, networking, automation, or scripting.

This section will also specify whether the users must provide the interface software

and any special licensing requirements.

Communication Interfaces Describes how the service will communicate with itself (for multi-platform

applications) or other software applications or hardware, including items such as

networking, email, intranet, and Internet communications, PABX, IP telephony etc.

Functional Design Constraints Any examples of constraints that will prevent or influence the ability of the system

to deliver the expected functionality will be listed here.

Attributes Security Describes where necessary the technical security requirements for the service. For

example, any password-protected access levels such as operator,

engineer/modeller, manager, database administrator and which functionality will be

accessible to each access level, firewall requirements and virus software.

This section should also describe all physical, organizational and procedural

security requirements for the service.

Reliability, Availability, Maintainability This section describes requirement items such as days or weeks of continuous

operation, strategy for data recovery, structuring of service for ease of future

modification.


Page 163

Installation and Distribution This section describes the planned method for installation and distribution of

releases for the service: done by the user independently, done by customer

company internal IT services, done by an external contractor.

The section should specify the handling of such items as data transfer from prior

releases, the physical storage of hardware and software in conjunction with

releases and the presence of software or hardware elements from prior releases.

Usability It is important to describe items that will ensure the user-friendliness of the service.

Examples include error messages that direct the user to a solution, user

documentation, online help etc.

Additional Requirements Describes other characteristics the service must have, that were not covered in the

prior sections.

Administration Includes any periodic updating or data management needed for the service.

• User documentation: Describes the user documentation to be delivered in

conjunction with the service, including both hard copy and online

requirements.

• Other requirements: Describes any other requirements not already

covered above that need to be considered during the design of the service.


Page 164

Technical Specification

IT Services Technical Specification


Service: <service name>



Release Date:



Page 165



I:/IT Services/Service Delivery/Technical Specifications/


• <first name, last name>, IT Services Manager

• <first name, last name>, IT Service Delivery Manager

• <first name, last name>, National IT Help Desk Manager

Amendment History


Distribution List When this procedure is updated the following copyholders must be advised


<<Organization name>> Business Unit

Stakeholders

IT


Page 166

Introduction Purpose The purpose of this document is to provide relevant IT Units with the technical

specifications for the range of services provided by IT Services to the

<<Organization name>> community.


details of each service provided by IT Services including:


• functional capabilities of the service

• user characteristics

• user operations and practices

• software and hardware interfaces


• details of procedures for the service

Note: It is assumed for each service described in this document that the supporting

functional awareness of the service is already known.

Audience This document is relevant to IT staff in <<Organization name>>


Related Documentation

Include in this section any related Service Level Agreement reference numbers







Page 167

Executive Overview Describe the purpose, scope and organization of the Technical Specification

document.

Service Overview Service Description Describes briefly the reason for the service, and lists the most important features

and capabilities.

Also include the services relationship to the business processes.

Service technical capabilities This section presents a list of the technical aspects that the service will be required

to perform.

Where the service comprises of technical aspects, a table may be developed to

illustrate these relationships.

User characteristics This section describes the intended users of the service in terms of job function,

specialized knowledge, or skill levels required.

This section should consider various user classes or profiles such as managers,

engineers, equipment operators, IT support staff, and network or database

administrators.

User operations and practices Describes how persons will normally use the service, and the tasks they will most

frequently perform.

Also covers how users might use the service on an occasional basis. Consider

using a formal “Use Case” to specify the end-users' expected use of the service.

This may also be derived from the Service Level Requirements.


Page 168

Assumptions This section lists any assumptions that were made in specifying the technical

requirements of this service.

Other services How does the service technically interact with other services?

Specific Technical Descriptions This section is repeated for each technical aspect of the service. Some examples

of technical aspects are: Processing, Backup, Archive, Restores.

Description The description describes the Technical aspect and its role in the service.

Inputs Describe the inputs to the aspect. Data feeds from other systems, human input or

automated timed activities are examples of inputs.

Processing Describes what is done. For example with regard to backups we would describe

the database close, backup and database restart activities.

Outputs This section describes the outputs. For example, if we are describing the archive

activity we would expect to end up with a media storage device that would be

stored in a secure location.

Reports generated are also defined.

Other technical considerations The interfaces in this section are specified by documenting: the name and

description of each item, source or input, destination or output, ranges, accuracy

and tolerances, units of measure, timing, display formats and organization,

availability and capacity requirements and any relevant agreements that may

impact on the service.


Page 169

Hardware details Describes the technical components needed to provide the service, and also other

output or input devices such as printers or handheld devices.

Software details Describes the technical aspects of the software used to provide the service (eg.

client server details), operating system levels, backup software used, virus

protection details, other supporting services and applications that contribute to the

service availability.

Communication details Describes how the service will communicate with itself (for multi-platform

applications) or other software applications or hardware, including items such as

networking, email, intranet, and Internet communications, PABX, IP telephony etc.

Performance Discusses items such as response times, throughput requirements, data volume

requirements, maximum data file size or problem complexity, maximum number of

concurrent uses, and peak load requirements (for web-based applications).

Includes expected response times for entering information, querying data files and

databases, performing calculations of various complexities, and

importing/exporting data.

Technical Design Constraints Examples of technical constraints that affect service design choices are items such

as memory constraints involving minimum and maximum RAM and hard disk

space, and limitations arising from hardware, software or communications

standards.

Additional Requirements Describes other characteristics the service must have, that were not covered in the

prior sections.


Page 170

Administration Includes any periodic updating or data management needed for the service.

• User documentation: Describes the user documentation to be delivered in

conjunction with the service, including both hard copy and online

requirements.

• Other requirements: Describes any other requirements not already

covered above that need to be considered during the design of the service.


Page 171

freya.dixon

Blank


Page 172

Price List

IT Services Price List




Release Date:





Page 173

Price List Considerations for Service Level Management The document is not to be considered an extensive statement as its topics have to



considered.

This document serves as a GUIDE FOR DETERMINING THE PRICE OF IT SERVICE DELIVERY TO CUSTOMERS. This document provides a basis for completion within your own organization. This document can be read in conjunction with: Service Catalogue (which is where summary pricing information is presented).

There are three considerations to review when looking to establish the prices for IT

Services that are delivered. It is the combination of these areas that will help the

Service Level Manager (along with the process owner for Financial Management

for IT Services) set and negotiate pricing for IT Service delivery.

These considerations are:

1) The degree of IT costs that are expected to be recovered.

Such a decision will generally come from a business policy regarding cost

recovery for other shared services. For example if Human Resources aim to

recover all costs from the departments or user groups it supports, it is likely

that this will also apply to IT.

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 174

2) The degree that IT wants to change consumption patterns of Customers and

Users

There is no surer thing. Once services start to cost, then behaviours will

change and demand will decrease. Of course, the major challenge of

looking to use pricing to influence (drive down) consumption is the major

resistance that can be expected.

3) Budget influence

Careful and well articulated pricing for IT Services allows better predictions

regarding the expected budget required for a future time period. This

positive influence helps to reduce the number of unexpected surprises that

can often happen, when budget funds cannot support requirements.

Use the following table with examples to help determine which IT Services will be

charged for in your organization and the basis upon which you will levy that

charge.

Chargeable Item (examples) Ancillary Services Cost basis Sales transaction

Network connection Personal Computer File server processing

Simple cost per transaction, or; Cost per speed of processing, or; Cost per size of transaction

E-mail sent

Network connection to mail server Personal Computer Internet connection

Per unit, or; Stored limit, or; Mail items in the “in-box”

An important point to consider regarding the pricing of services is the case when a

customer claims that they can buy the service cheaper from an external provider.

While this may be the case, the overall impact on the organization may be negative

– so it may be necessary to impose restrictions regarding purchase of external

services when suitable internal services are available.


Page 175

Once the pricing differential is identified a controlled process of (a) reducing costs

or (b) outsourcing to an external provider can be carried out.

The final point to consider regarding the price of IT Services is whether actual

funds transfer will take place or if charges are just imaginary (or “nominal”).

Nominal charging allows customers to see the costs of the IT Services they

consume, but they are not expected to transfer funds from their cost centres to the

IT department. This method can have a low impact; in that without transferring

funds, the affect on behaviour may be negligible.


Page 176

Communication Plan

IT Services Communication Plan




Release Date:


Page 177

Communication Plan for Service Level Management

The document is not to be considered an extensive statement as its topics have to



considered.

This document serves as a GUIDE FOR COMMUNICATIONS REQUIRED for the Service Level Management process. This document provides a basis for completion within your own organization. This document contains suggestions regarding information to share with others. The document is deliberately concise and broken into communication modules. This will allow the reader to pick and choose information for e-mails, flyers, etc. from one or more modules if and when appropriate.

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 178

Initial Communication Sell the Benefits

First steps in communication require the need to answer the question that most people (quite rightly) ask when the IT department suggests a new system, a new way of working. WHY? It is here that we need to promote and sell the benefits. However, be cautious of using generic words. Cite specific examples from your own organization that the reader will be able to relate to. Generic Benefit statements

Specific Organizational example

CM provides accurate information on our IT components.

This is important because…

Allows us to more carefully control the valuable IT infrastructure.

In recent times our control on IT has…

Helps us to more effectively manage our expenditure on IT.

Apart from the obvious benefits, the IT department in recent times has…

Assists with protecting against illegal or unauthorized software.

A recent example of … saw the individual and the company face severe penalties.

The above Communication module (or elements of) was/were distributed;

To:

On: <<date>>

By:

On: <<date>>


Page 179

Service Level Management Goals The Goals of Service Level Management

Service

The Goals of Service Level Management can be promoted in the following manner. Official Goal Statement: Through a process of continual negotiation, discussion, monitoring and reporting the Service Level Management process aims to ensure the delivery of IT Services that meet the requirements and expectations of our customers and end-users.

• Seek agreement on expected delivery of IT service by gaining an understanding of the Service Level Requirements from nominated personnel

(Special Tip: Beware of using only Managers to gain information from, as the resistance factor will be high)

• Oversee the monitoring of service delivery to ensure that the negotiations regarding the service requirements are not ignored and treated as a once off exercise.

• Provide relevant reports to nominated personnel.

(Special Tip: Beware of reporting only to Managers. If you speak to a lot of people regarding Service Delivery then you need to establish ways to report to these people the outcomes and progress of the discussions). Always bear in mind the “so what” factor when discussing areas like goals and objectives. If you cannot honestly and sensibly answer the question “so what” – then you are not selling the message in a way that is personal to the listener and gets their “buy-in”.

The above Service Level Management Goals module was distributed;

To:

On: <<date>>

By:

On: <<date>>


Page 180

Service Level Management Activities Intrusive & Hidden Activities

The list of actions in this module may have a direct impact on end users. They will be curious as to why staff have a sudden interest in trying to develop an understanding regarding what they need from IT. There could be an element of suspicion, so consider different strategies to overcome this initial scepticism. Identification

• Analysing current services and Service Level Requirements • Recording the current service provision in a Service Catalogue.

Definition

Matching & customising (with the customer) of the right service provision against the right costs:

• Service Catalogue • Demands of the customer (Service Level Requirements).

Agreement (Defining and signing SLA/s)

• Service Level Agreements, supported by: Operational Level Agreements (OLAs) and Underpinning Contracts

Monitoring Measuring the actual service levels against the agreed service levels Reporting Reporting on the service provision (to the customer and the IT organisation) Evaluation (review)

• Evaluate the service provision with the customer • Match & customise: adjust service provision if required? (SIP, SQP) • Match & customise: adjust SLA if required?

Information regarding activities was distributed;

To:

On: <<date>>

By:

On: <<date>>


Page 181

Service Level Management Deliverable Outputs of the Process

There are a variety of output documents that should be visible to the customer and end-user. Outlining these will allow the use of common terms – which enhances the overall communication process. SLR = Service Level Requirements

• Detailed recording of the customers’ needs • Blueprint for defining, adapting and revising of services

Service Spec Sheets = Service Specifications

• Connection between functionality (externally / customer focussed) and technicalities (internally / IT organisation focussed)

Service Catalogue

• Detailed survey of available services • Detailed survey of available service levels • Derived from the Service Spec Sheets, but written in “customer terminology”

SLA = Service Level Agreement The written agreement between the provider and the customer (business representative) Service Level Achievements = the Service Levels that are realised SIP = Service Improvement Programme / Plan Actions, phases and delivery dates for improvement of a service OLA = Operational Level Agreement (or SPA, Service Provisioning Agreement) A written agreement with another internal IT department to support the SLA UC = Underpinning Contract (=a written agreement with an external IT supplier)

News about the Service Level Management deliverables was distributed;

To:

On: <<date>>

By:

On: <<date>>


Page 182

Service Level Management Planning Costs

Details regarding the cost of Service Level management were distributed;

To:

On: <<date>>

By:

On: <<date>>

Information relating to costs may be a topic that would be held back from general communication. Failure to convince people of the benefits will mean total rejection of associated costs. If required, costs fall under several categories:

• Personnel – audit verification staff, database management team (Set-up and ongoing)

• Accommodation – Physical location (Set-up and ongoing) • Software – Tools (Set-up and ongoing) • Hardware – Infrastructure (Set-up) • Education – Training (Set-up and ongoing) • Procedures – external consultants etc. (Set-up)

The costs of implementing Service Level Management will be outweighed by the benefits. For example, many organizations have a negative perception of the function of the IT Department. A well run Service Level Management process will make major inroads into altering that perception. Failure to deliver acceptable services will only add to any poor perceptions and start business people questioning the value of IT.


Page 183

freya.dixon

Blank


Page 184

Business and IT Flyers

IT Services Process: Service Level Management

Business and IT Flyers

Status:

In draft

Under Review

Sent for Approval

Approved

Rejected

Version:

<<your version>>

Release

Date:

Note: SEARCH AND REPLACE<<Organization name>> Search for any << or >> as your input will be required Also review any yellow highlighted text


Page 185

Introduction The following pages provide 2 examples of flyers that can printed and

distributed throughout your organization.

They are designed to be displayed in staff rooms.

Note, they are examples, and your input is required to complete the flyers.

Remember, the important thing is to ensure that the message delivered in the

flyer is appropriate to the audience that will be reading it.

So think about how and where you will be distributing the flyers.


Page 186

Key Points:

•Agreed Levels of Service. •Easy to understand Service Catalogue. •Services You Need. •Services at the Right Time! •Improved IT Services •Less Disruption • <<any additional points >>

IT Services Department

The IT Department is embarking on a Service Level Management Improvement Programme. << Provide brief description of Service Level Management >> <<First, determine the audience of this flyer. This could be anyone who might benefit from the information it contains, for example, IT employees or business staff.

THE BENEFITS

<< List the

benefits to the intended

audience.

Keep it Simple

Use Bullet

Points >>

Where are you going to send this flyer? Which locations will the flyer be posted at?If you are posting the flyer in staff rooms, then the content needs to reflect the information that will be of use to them. For example, list a common set of services and the level that they are provided at. This helps set the expectations for the

services being delivered by the IT Departments. >> << What process do they need to follow when recording information about failures in IT Services? >> Provide contact lists for the IT Department as well as the business managers that they can contact. >>

THE PROCESS<<

List the steps

involved in the process

Keep it simple

Show steps

as necessary and

beneficial >>

CONTACTS

<< List the contacts

Input any

graphics in here>>

Service Level Management


Page 187

Service Level Management

IT SERVICE IMPROVEMENT PROGRAMME

HELP US HELP YOU Contact your immediate Manager to let them know what you

need to do your job better

We need to know about the Services YOU NEED.

IMPROVED SERVICE DELIVERY IS OUR GOAL

KNOW YOUR SERVICE RIGHTS

Sponsored by IT SERVICES

“Constantly improving and aligning to your needs”


Page 188

Reports KPI’s Other Metrics

�

IT Services Reports and KPI Targets




Release Date:



Page 189

Reports and KPI Targets for Service Level Management The document is not to be considered an extensive statement as its topics

have to be generic enough to suit any reader for any organization.

However, the reader will certainly be reminded of the key topics that have to

be considered.

This document serves as a GUIDE ON SUITABLE KEY PERFORMANCE INDICATORS (KPIs) and REPORTS FOR MANAGEMENT for the Service Level Management process. This document provides a basis for completion within your own organization. This document contains suggestions regarding the measures that would be meaningful for this process. The metrics demonstrated are intended to show the reader the range of metrics that can be used. The message must also be clear that technology metrics must be heavily supplemented with non-technical and business focused metrics/KPI’s/measures.

This document was;

Prepared by:

On: <<date>>

And accepted by:

On: <<date>>


Page 190

Key performance indicators (KPI’s) Continuous improvement requires that each process needs to have a plan

about “how” and “when” to measure its own performance. While there can be

no set guidelines presented for the timing/when of these reviews; the “how”

question can be answered with metrics and measurements.

With regard to timing of reviews then factors such as resource availability,

cost and “nuisance factor” need to be accounted for. Many initiatives begin

with good intentions to do regular reviews, but these fall away very rapidly.

This is why the process owner must have the conviction to follow through on

assessments and meetings and reviews, etc. If the process manager feels

that reviews are too seldom or too often then the schedule should be changed

to reflect that.

Establishing SMART targets is a key part of good process management.

SMART is an acronym for:

Simple Measurable Achievable Realistic Time Driven

Metrics help to ensure that the process in question is running effectively.


Page 191

With regard to SERVICE LEVEL MANAGEMENT the following metrics and

associated targets should be considered:

Key Performance Indicator Target Value (some

examples)

Time Frame/Notes/Who

The percentage of Underpinning contracts and OLAs in place that are supporting Service Level Agreements.

Expressed as a percentage, it indicates that SLAs are more than just a document, but have been extended into related agreements with internal and external providers.

Meetings held (on time) to review performance

A reducing number here may be a good indication or at least the number should be stable.

Costs of Service Delivery decreasing.

The percentage of targets relating to Service delivery being met.

The number of Service breaches recorded

Improvements in salient points from Customer feedback forms

Others

Special Tip: Beware of using percentages in too many cases. It may even be

better to use absolute values when the potential number of maximum failures

is less than 100

Reports for Management Management reports help identify future trends and allow review of the “health” of

the process. Setting a security level on certain reports may be appropriate as well as

categorizing the report as Strategic, Operational or Tactical.

The acid test for a relevant report is to have a sound answer to the question; “What

decisions is this report helping management to make?”

Management reports for Service Level Management should include:

Report Time Frame/Notes/Who Expected growth in demand for the service (will generally be high at start-up, but then plateau)

Serious Service breaches and remedy steps taken

Backlog details of process activities outstanding (along with potential negative impact regarding failure to complete the work in a timely manner) – but also provide solutions on how the backlog can be cleared.

Simple breakdown of new SLA/OLA/UCs created, simple notes on reviews of same completed.

Analysis and results of meetings completed

The situation regarding the process staffing levels and any suggestions regarding redistribution, recruitment and training required.

Human resource reporting including hours worked against project/activity (including weekend/after hours work).

Relevant Financial information– to be provided in conjunction with Financial Management for IT Services


Page 193

freya.dixon

Blank


Page 194

SLM IMPLEMENTATION & PROJECT PLAN

IT Services Implementation Plan/Project Plan

Skeleton Outline


Status: In draft

Under Review

Sent for Approval

Approved

Rejected


Release Date:


Page 195

Planning and implementation for Service Level Management

This document as described provides guidance for the planning and implementation

of the Service Level Management ITIL process.

The document is not to be considered an extensive plan as its topics have to be



considered for planning and implementation of this process.

Initial planning

When beginning the process planning the following items must be completed:

CHECK ☺ or or date

DESCRIPTION

Get agreement on the objective (use the ITIL definition), purpose, scope, and implementation approach (eg. Internal, outsourced, hybrid) for the process.

Assign a person to the key role of process manager/owner. This person is responsible for the process and all associated systems.

Conduct a review of activities that would currently be considered as an activity associated with this process. Make notes and discuss the “re-usability” of that activity.

Create and gain agreement on a high-level process plan and a design for any associated process systems. NOTE: the plan need not be detailed. Too many initiatives get caught up in too much detail in the planning phase. KEEP THE MOMENTUM GOING.

Review the finances required for the process as a whole and any associated systems (expenditure including people, software, hardware, accommodation). Don’t forget that the initial expenditure may be higher than the ongoing costs. Don’t forget annual allowances for systems maintenance or customizations to systems by development staff.

Agree to the policy regarding this process


Page 196

Create Strategic statements Policy Statement

The policy establishes the “SENSE OF URGENCY” for the process.

It helps us to think clearly about and agree on the reasons WHY effort is put into this

process.

An inability to answer this seemingly simple, but actually complex question is a major

stepping stone towards successful implementation

The most common mistake made is that reasons regarding IT are given as the WHY

we should do this. Reasons like to make our IT department more efficient are far too

generic and don’t focus on the real issue behind why this process is needed.

The statement must leave the reader in no doubt that the benefits of this process will

be far reaching and contribute to the business in a clearly recognizable way.

Objective Statement

When you are describing the end or ultimate goal for a unit of activity that is about to

be undertaken you are outlining the OBJECTIVE for that unit of activity.

Of course the activity may be some actions for just you or a team of people. In either

case, writing down the answer to WHERE will this activity lead me/us/the

organization is a powerful exercise.

There are many studies that indicate the simple act of putting a statement about the

end result expected onto a piece of paper, then continually referring to it, makes

achieving that end result realistic.

As a tip regarding the development of an objective statement; don’t get caught up in

spending hours on this. Do it quickly and go with your instincts or first thoughts –


Page 197

BUT THEN, wait a few days and review what you did for another short period of time

and THEN commit to the outcome of the second review as your statement.

Scope Statement In defining the scope of this process we are answering what activities and what

“information interfaces” does this process have.

Don’t get caught up in trying to be too detailed about the information flow into and

out of this process. What is important is that others realize that information does in

fact flow.

For example, with regard to the SERVICE LEVEL MANAGEMENT process we can

create a simple table such as:

Service Level Management Information flows

Process Process Information SLMMgt

to

FinancialMgt

Customer budget details

FinancialMgt

to

SLMMgt

Expected ROI calculations for new service

SLMMgt

to ReleaseMgt

Details regarding mandatory times for service availability

ReleaseMgt

to SLMMgt

Expected impact (+ve or –ve) of release

SLMMgt

to ServiceDesk

Client expectations regarding call pick up times (eg. 2 rings)

ServiceDesk

to SLMMgt

Details of irate callers


Page 198

Steps for Implementation There can be a variety of ways to implement this process. For a lot of organizations

a staged implementation may be suitable. For others a “big bang” implementation –

due to absolute equality may be appropriate.

In reality however, we usually look at implementation according to pre-defined

priorities. Consider the following options and then apply a suitable model to your

own organization or case study.

STEPS NOTES/ /RELEVANCE/DATES/

WHO

Produce the Service Catalog

Plan the SLA Structure

Establish the Service Level Requirements

Draft SLA and seek initial approval

Establish monitoring levels

Review agreements with internal and external suppliers

Define reporting standards

Publicize and market

The priority selection has to be made with other factors in mind, such as competitive

analysis, any legal requirements, and desires of “politically powerful influencers”.


Page 199

Costs The cost of process implementation is something that must be considered before,

during and after the implementation initiative. The following points and table helps to

frame these considerations:

(A variety of symbols have been provided to help you indicate required expenditure,

rising or falling expenditure, level of satisfaction regarding costs in a particular area,

etc.)

Initial During Ongoing

Personnel Costs of people for initial design of process, implementation and ongoing support

Accommodation Costs of housing new staff and any associated new equipment and space for documents or process related concepts.

☺

Software New tools required to support the process and/or the costs of migration from an existing tool or system to the new one.

Maintenance costs

Hardware New hardware required to support the process activities. IT hardware and even new desks for staff.

Education Re-education of existing staff to learn new techniques and/or learn to operate new systems.

Procedures Development costs associated with filling in the detail of a process activity. The step-by-step recipe guides for all involved and even indirectly involved personnel.

In most cases, costs for process implementation have to be budgeted for (or

allocated) well in advance of expenditure. Part of this step involves deciding on a

charging mechanism (if any) for the new services to be offered.


Page 200

Build the team

Each process requires a process owner and in most situations a team of people to

assist.

The Service Level Management process is perhaps the process in the Service Delivery set that has the largest amount of initial and on-going activity. The team size may or may not reflect this. Of course a lot will be dependant on the timing of the implementation and whether it is to be staged or implemented as one exercise.

Analyze current situation and FLAG Naturally there are many organizations that have many existing

procedures/processes and people in place that feel that the activities of SLM are

already being done. It is critical to identify these systems and consider their future

role as part of the new process definition.

Examples of areas to review are:

Area Notes Power teams

Current formal procedures

Current informal procedures

Current role descriptions

Existing organizational structure

Spreadsheets, databases and other repositories

Other…


Page 201

Implementation Planning After base decisions regarding the scope of the process and the overall planning

activities are complete we need to address the actual implementation of the process.

It is unlikely that there will not be some current activity or work being performed that

would fit under the banner of this process. However, we can provide a

comprehensive checklist of points that must be reviewed and done.

Implementation activities for Service Level Management

Activity

Notes/Comments/Time Frame/Who

Review current and existing Service Level Management practices in greater detail. Make sure you also review current process connections from these practices to other areas of IT Service Delivery.

Review the ability of existing functions and staff. Can we “reuse” some of the skills to minimize training, education and time required for implementation?

Establish the accuracy and relevance of current processes, procedures and meetings. As part of this step if any information is credible document the transition from the current format to any new format that is selected.

Decide how best to select any vendor that will provide assistance in this process area (including tools, external consultancy or assistance to help with initial high workload during process implementation).


Page 202

Establish a selection guideline for the evaluation and selection of tools required to support this process area (i.e. SLA Management tools).

Purchase and install tools required to support this process (i.e. SLA Management tool). Ensure adequate skills transfer and on-going support is considered if external systems are selected.

Create any required business processes interfaces for this process that can be provided by the automated tools (eg. reporting – frequency, content).

Document and get agreement on roles, responsibilities and training plans.

Communicate with and provide necessary education and training for staff that covers the actual importance of the process and the intricacies of the process itself.

An important point to remember is that if this process is to be implemented at the

same time as other processes that it is crucial that both implementation plans and

importantly timing of work is complementary.

Cutover to new processes The question of when a new process actually starts is one that is not easy to answer.

Most process activity evolves without rigid starting dates and this is what we mean

when we answer a question with “that’s just the way it’s done around here”.


Page 203

Ultimately we do want the new process to become the way things are done around

here, so it may even be best not to set specific launch dates, as this will set the

expectation that from the given date all issues relating to the process will disappear

(not a realistic expectation).


Page 204

FURTHER INFORMATION For more information on other products available from The Art of Service, you can

visit our website: http://www.theartofservice.com

If you found this guide helpful, you can find more publications from The Art of

Service at: http://www.amazon.com

the service level agreement sla guide - sla book, templates for service level management and service...

Documents