Service Level Management Best Practice PDF

Service Level Management Best Practice
Handbook:
Building, Running and Managing Effective Service

Level Management SLAs - Ready to use supporting
documents bringing ITIL Theory into Practice
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
review@emereo.org, 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
TABLE OF CONTENTS
INTRODUCTION ROADMAP........................................................................................ 5
SERVICE LEVEL MANGEMENT PRESENTATION........................................................... 9
SUPPORTING DOCUMENTS....................................................................................... 69
OBJECTIVES AND GOALS...................................................................................... 71
BUSINESS JUSTIFICATION DOCUMENTS ................................................................ 75
SLM SCOPE ............................................................................................................. 81
POLICIES OBJECTIVE AND SCOPE ....................................................................... 89
SERVICE LEVEL REQUIREMENTS............................................................................. 93
TECHNICAL SPECIFICATIONS .............................................................................. 101
FUNCTIONAL SPECIFICATIONS ........................................................................... 110
MULTI LEVEL BASED SLA....................................................................................... 119
SERVICE BASED SLA ............................................................................................. 127
CUSTOMER BASED SLA ........................................................................................ 135
UNDERPINNING CONTRACTS ............................................................................. 141
SERVICE OPTIONS ................................................................................................ 145
PRICE LIST .............................................................................................................. 151
SERVICE CATALOG.............................................................................................. 155
COMMUNICATION PLAN .................................................................................... 168
BUSINESS AND IT SERVICE MAPPING.................................................................. 176
REPORTS KPI’s AND METRICS .............................................................................. 192
BUSINESS AND IT FLYERS ...................................................................................... 198
EMAIL TEXT ............................................................................................................ 202
SLM PROCESS MANAGER ................................................................................... 208
IMPLEMENTATION PLAN AND PROJECT PLAN...................................................... 212
FURTHER INFORMATION .......................................................................................... 220
Page 3
Page 4
INTRODUCTION ROADMAP
Many organizations are looking to implement 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

Guide. The information found within the book is based on the ITIL Version 2
framework, specifically the Service Level Management process within the
Service Delivery phase.
The guide is designed to answer a lot of the questions about Service Level
Management and provide 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 will enable you to improve your organizations

methodology knowledge base.
The guide 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 Guide:
Flows logically,
Is scalable,
Provides presentations, templates and documents,
Saves you time.
Page 5
Step 1
Start by reviewing the PowerPoint presentation.
Service Level Management ITIL V2– This presentation provides a detailed

and comprehensive overview of Service Level Management in the specialist
areas of ITIL Version 2 and in particular, within the Service Level
Management process as part of the Service Delivery phase.
These presentations will give you a good knowledge and understanding of all
the terms, activities and concepts required within Service Level Management.
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, as well as
the slides, as references to further documents and resources are highlighted
here.
Page 6
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.
Service Level Management ITIL V2:

• Objectives and Goals
• Business Justification Document
• SLM Scope
• Policies Objective and Scope
• Service Level Requirements
• Technical Specifications
• Functional Specifications
• Multi Level Based SLA
• Service Based SLA
• Customer Based SLA
• Underpinning Contracts
• Service Options
• Price List
• Service Catalog
• Communication Plan
• Business and IT Service Mapping
• Reports KPI’s and Metrics
• Business and IT Flyers
• Email Text
• SLM Process Manager
Page 7
Step 3
Alternatively, continue by working through the Implementation 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 resources found within the book will help you
fill these gaps by giving you a focused, practical and user-friendly approach to
Service Level Management.
Page 8
SERVICE LEVEL MANGEMENT PRESENTATION
Please refer to Objectives and Goals on page 71 within this workbook

for more information.
Page 9
Please refer to Business Justification Document on page 75 within this

workbook for more information.
Page 10
These bullet points help to illustrate why it is that we need to introduce the
disciplines of effective and efficient Process management into our IT
environments.
Briefly discuss each, you can of course add or delete points according to your
own situation.
Page 11
ITSM is not something on its own, but closely linked to the business.
Explain difference between ‘effective’ (doing the right thing) and ‘efficient’
(doing the right thing the right way).
The objective tree is a useful way to help explain the importance of IT being a
supporting department to the business.
To meet organizational objectives, the organization has business

processes in place.
Examples of business processes are sales, admin and financial (who have a
“sales process”) or logistics, customer service and freight (who have a
“customer returns process”).
Each of the units involved in these business processes needs IT Services

(e.g. CRM application, e-mail, word processing, financial tools).
Page 12
Continued…
Each of these services runs on IT infrastructure that has to be properly

managed (Service Management). IT Infrastructure includes hardware,
software, procedures, policies, documentation, etc.
ITIL provides a framework for the management of IT Infrastructure.
Page 13
Traditionally we look at the IT department as a collection of specialists with

specialist skills. This is a functional way to look at IT and it puts people into
departmental SILO’s.
Page 14
Best practice processes will transverse functional departments and help to

break down the silo’s/walls/barriers to communication between them.
Explain the benefits of processes in general.

Other points to explain:
• A process is a set of activities with a common goal.
• A process can measure the input, output and activities.
• A process will link these measurements to targets.
Page 15
An IT organization needs to focus on all these aspects to deliver the right IT

services (effective) in the right way (efficient).
Generally, the technology perspective gets a lot of attention (time, budget,

people etc).
More and more people see the importance of processes (which is why ITIL is
getting so popular).
There is also an organization perspective: the alignment of vision, strategy

and goals with the day to day activities in IT. This is useless, if it is not
communicated (which is virtually always the case and finally, there is the
people perspective, which looks at the ‘soft side’: is your staff happy, do they
have the right skills, are you managing them effectively etc.
Page 16
Service Level Management is one of 10 ITIL processes. Here we get to see

the others and the one function (Service Desk). Security Management can be
included as well, due to its critical importance.
Service Level Management is not an isolated process, but:
• Is a process that is based around communication and monitoring

• Is a process that requires high client/customer liaison
• Provides information to all other processes (e.g. customer
expectations, financial information,etc.)
• Requires information from other processes (e.g. reports on
performance, trending information, customer satisfaction ratings)
• etc.
Page 17
Please refer to SLM Scope on page 81 within this workbook for more
information.
Page 18
Please refer to Policies Objectives and Goals on page 89 within this

Page 19
Explain the relationship between the customer – IT and Suppliers.
Also the higher level processes with the lower level etc.
In reality organizations have typically revamped the SLA’s every 12-18

months. The problem has been that the information used to update the SLA is
often incomplete or disparate.
Having the other processes in place provides a common focus for the SLA to
draw accurate information from which allows SLM to act as the interface
between the possibilities (IT) and needs (customer).
Page 20
Talk about how SLM fits in with the rest of IT.

What generic benefits does IT get from having the process in place?
What does the business get?
The acronyms in this slide are covered later:

UC = Underpinning contract (the agreement in place between Service Level
Management and external providers)
OLA = Operation Level Agreement (the agreement in place between Service
Level Management and internal providers)
SLA = Service Level Agreements (agreements that document customer
expectations regarding IT Service Delivery)
Page 21
Explain that each of these are either inputs to the process, outputs to the
process and in some cases both.
An understanding of these are necessary as we move into the six real

activities in the coming slides.
Note: you can gain more understanding on these terms from later slides or
supplemental information from www.theartofservice.com
Page 22
Please refer to Level Requirement on page 93, Technical Specifications

on page 101 and Functional Specifications on page 109 within this
Page 23
Please refer to Multi Level Based SLA on page 117 and Service Level
Based SLA on page 125 and Customer Based SLA on page 133 within
this workbook for more information.
Page 24
Please refer to Underpinning Contracts on page 139 within this

Page 25
This is a summary slide regarding the core activities of Service Level

Management.
Following pages expand on this one.
Page 26
This diagram has been split up over the following slides to allow for more
detailed explanation on each component.
Page 27
Once the first SLA structure has been agreed, a first SLA must be drafted. It is
advisable to involve Customers from the outset, but rather than going along
with a blank sheet to commence with, it may be better to produce a first
outline draft as a starting point for more detailed and in-depth discussion. Be
careful though no to go too far and appear to be presenting the Customer with
a fait accompli.
Please refer to Service Level Requirements on page 93 within this

Page 28
Please refer to Multi Level Based SLA on page 117, Service Level Based
SLA on page 125 and Customer Based SLA on page 133 within this
Page 29
Over the years, organizations’ IT Infrastructures have grown and developed,

and there may not be a clear picture of all the services currently being
provided and the Customers of each. In order to establish an accurate picture,
it is recommended that an IT Service Catalog is produced.
Such a catalog should list all of the services being provided, a summary or
their characteristics and details of the Customers and maintainer or each.
A dress of ‘detective work’ may be needed to compile this list an agree it with
the Customers (sifting through old documentation, searching program
libraries, talking with IT staff and Customers, looking at procurement records
and talking with suppliers and contractor etc). If a CMDB or any sort of asset
database exists, these may be a valuable source of information.
Page 30
Nothing should be included in an SLA unless it can be effectively monitored

and measured at a commonly agreed point. The importance of this cannot be
overstressed, as inclusions of items that cannot be effectively monitored
almost always result in disputes and eventual loss of faith in the SLM process.
A lot of organizations have discovered this the ‘hard way’ and as a
consequence, have absorbed heavy costs both in financial sense as well as in
terms of negative impacts on their culture.
Existing monitoring of capabilities should be received and upgraded as

necessary. Ideally this should be done ahead of, or in parallel with, the
drafting of SLA’s, so that monitoring can be in place to assist with the
validation of proposed targets.
Page 31
It is essential that monitoring matches’ the Customers true perception of

service. Unfortunately this is often very difficult to achieve. For example,
monitoring or individual components, such as the network or server, does not
guarantee that the service will be available so far as the Customer is
concerned – a desktop or application failure may mean that the service
cannot be used by the Customer. Without monitoring all components in the
end-to-end service (which may be very difficult and costly to achieve) a true
picture cannot be gained. Similarly, Users must be aware that they should
report Incidents immediately to aid diagnostics, especially if performance
related.
Where multiple services are delivered to a single workstation, it is probably

more effective to record only down time against the service the User was
trying to access at the time (though this needs to be agreed with the
Customer). Customer perception is often that although a failure might affect
more than one service all they are bothered about the service they cannot
access at the time of the reported Incident – though this is not always true, so
caution is needed.
Page 32
When completed, the catalog may initially consist of a matrix, table or

spreadsheet. Some organizations integrate and maintain their Service
Catalog as part of the Configuration Management Data Base(CMBD).
Page 33
Here are all six activities and the relevant outputs.

This slide can also be an invaluable check list for completion of SLM plans,
reports, contracts, etc.
Page 34
Page 35
This is a very busy slide and when you think about it like this that all these
things are constantly taking place, can be very confusing.
How can we make this as streamlined as possible?
It does portray the complexity and myriad of information flows however.
Create some examples for the group using your own experience. If you can
start the discussion with one example, others will quickly recount their own
experiences.
Page 36
Immediately the SLA is agreed, monitoring must be instigated, and service

achievement reports must be produced. Operational reports must be
produced frequently (daily – perhaps even more frequently), and where
possible, exception reports should be produced whenever an SLA has been
broken (or threatened if appropriate thresholds have been set to give an early
warning).
Page 37
The specific content and the initial targets to be included in SLA’s must be
agreed. It is difficult to be prescriptive, as each situation is unique, and
content varies depending up the type of SLA, but there are a number of
common features that often occur within the SLA’s.
Page 38
Notes:
Page 39
So what should be in this thing called an SLA?
What else could be or should be included in the SLA?
Please refer to Technical Specifications on page101, Functional

Specifications on page 109, Service Option on page 143 and Price Lists
on page 149 within this workbook for more information.
Page 40
Please refer to Service Catalog on page 153 within this workbook for
more information.
Page 41
More information on Configuration Management at www.theartofservice.com
Please refer to Service Catalog on page 153 within this workbook for
more information.
Page 42
While many organizations have to give initial priority to introducing SLA’s for
existing services, it is also important to establish procedures for agreeing
Service Level Requirements (SLR’s) for new services being developed or
procured.
The SLR’s should be integral part of the service design criteria, of which the
functional specifications is a part. They should, from the very outset, form part
of the testing/trialing criteria as the service progresses through the stages of
design and development or procurement. A draft SLA should be developed
alongside the service itself, and should be signed and formalized before the
service is introduced in to live use.
Page 43
An IT Service Management self-assessment scan can be downloaded from

www.itil.co.uk.
This is a self assessment scan and is therefore more prone to inaccurate

results as there is a lack of objectivity and an exposure to organizational
politics.
For information regarding an independent scan send an e-mail to

service@theartofservice.com
Page 44
Strategic alignment workshops should be conducted as part of an IT Service

Management SCAN to gain insight into what the IT Managers see as high
priority issues.
Please refer to Communication Plan on page 165 and Business IT

Service Mapping on page 173 within this workbook for more
information.
Page 45
Please refer to Communication Plan on page 165 and Business IT

Service Mapping on page 173 within this workbook for more
information.
Page 46
Page 47
Some organizations have chosen to adopt a multi-level SLA structure. For

example, a three layer structure as follows:
• Corporate Level
• Customer Level
• Service Level
Such structure allows SLA’s to be kept to a manageable size, avoids

unnecessary duplication, and reduces the need for frequent update.
Page 48
Using a draft agreement as a basis, negotiations must be held with the

Customer(s), or Customer representatives to finalize the content of the SLA
and the initial service level targets, and with the service providers to ensure
that these are achievable. Guide on general negotiation techniques is
included in the ITIL Business and Management Skills book.
Page 49
Management responsibilities include providing a point of contact for problems

related to the agreement, maintaining ongoing contact with the other party,
conducting service reviews, coordinating and implementing modifications to
the SLA, and assessing and reporting on how the parties can further enhance
their working relationship.
Page 50
The subjects and language in the service catalogue and SLAs should be clear
to the customers.
The guidelines to be developed should be applicable for all sorts of services;

IT services and other facilitating services.
SLA structure should make it possible to offer integrated services in one SLA.
E.g. unite services from various business units into one SLA.
Page 51
Page 52
How are KPI’s and Metrics used?
How can we improve this?
KPI’s
• % of services covered by SLAs?
• % of service targets being met?
• Are customer satisfaction ratings increasing?
• Are IT costs decreasing for services with stable service level
agreements?
• Is there documentary evidence that issues raised at reviews are being
followed up and resolved (e.g. via an SIP)?
Please refer to Reports KPI’s and Metrics on page 187 within this
Page 53
Service Improvement program is usually instigated where an underlying

difficulty has been identified which is adversely impacting upon service quality.
A Service Level Scan and the SLAs and Service Catalogue are important
inputs into the SIP. They provide a clear definition of the services being
offered and at what level they are being offered to allow comparison with the
current service levels being achieved. Do they still align with each other?
These two inputs will help provide an understanding of the gap that will exist
between services being delivered and services that need to be delivered
(Service Level Scan) and current description of services and service level
agreements.
The result of a gap analysis is a list of issues that exist, actions to be taken,
consequences, benefits and opportunities to be realized.
Page 54
Typically, IT departments measure the availability of individual components

rather than an end to end service.
This does not align IT to the business
Page 55
Notes:
Page 56
Typically, IT departments measure the availability of individual components

rather than an end to end service.
This does not align IT to the business.
Please refer to Reports KPI’s and Metrics on page 187 within this
Page 57
These are documents that are handy to have as templates.
See www.theartofservice.com for a range of documents and templates that

are available.
Page 58
These templates on screen give a very high level view.
The point needs to be made here that there is not one solution of a template
that fits all organizations because of the diversity of them.
What we can do is take ideas from all templates then do what is right for the
organization.
Page 59
Page 60
Please refer to Service Catalogue on page 153 within this workbook for
more information.
Page 61
SLA
•is a formal contractual arrangement specifying the required
service levels and the expected quality of service to be
delivered.
•It must state the mutual responsibilities of the customer and

provider ensuring that both parties are responsible for
monitoring, revising and evaluating existing SLAs.
SLM
•Puts in place Service Level Agreements with providers in order
to monitor and manage service levels, improving services to
ensure that end users are satisfied with the service they receive.
•Agreements with internal and external service suppliers

should be reviewed when significant changes to SLAs take
place and at least annually to ensure that they continue to
underpin SLAs.
Page 62
Continued…
THE LEVEL OF SERVICE

•Should be captured and base-lined, at least annually. This
provides a basis for measuring service improvement and
achievements using defined metrics for each service provided.
•The service improvement program should be monitored

regularly and appropriate action taken to correct any under-
achievements. All service level targets and results together with
their history should be maintained in an annual report.
•The foundations for service management must be put in place

very early during the acquisition process. This enables relevant
and realistic contract management and management of the
relationship with the provider following service implementation.
Page 63
The costs associated with Implementing and executing SLM included:

• Staff Costs (salaries, training, recruitment costs, consultancy – if
needed), both initial and ongoing.
• Accommodation Costs
• Support Tools (monitoring and reporting, plus some element of

integrated Service Management tools)
• Hardware on which run these tools
• Marketing costs e.g. Production of Service Catalog
Page 64
Please refer to Business and IT Flyers on page 193 and Email Text on
page 197 within this workbook for more information.
Page 65
Please refer to Communication Plan on page 165 within this workbook

Page 66
Please refer to SLM Process Manager on page 203 within this workbook
Page 67
Page 68
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 69
Page 70
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>>
Page 71
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 Met/Exceeded/Shortfall
objective for the process is to continue reporting ☺
metrics. This is an activity that is often forgotten Dates/names/role titles
over time or simply not done from the out-set.
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.
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).
Page 72
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)
(see www.theartofservice.com for more details
on the Configuration Management process)
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 Briefly describe the primary function of the

(Business) service.
(refer to Technical Use language that is business user friendly.
Considerations later in (e.g. instead of “NT Server, with 2Gb RAM and
this table) 500Gb of disk storage” – we would say “large
central server designed for all customers to
use and share information from”)
Service Breach(s) details The SIP will generally be based on broken

(refer to Problem & SLAs.
Availability Management Use this section to briefly detail in generic
issues). terms why this SIP is required.
Problem Management The SIP will be driven as a result of the need

details 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.
Page 73
Availability Management After the SIP is instigated the end users and
details 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 Briefly list any considerations regarding

Considerations 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?
SPECIFIC SIP This part of the SIP will outline actual steps to
ACTIONS 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 SIP Creation Date

Information 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 Catalog or Technical
Specification.
Notes & Comments
Page 74
BUSINESS JUSTIFICATION DOCUMENTS
IT Services
Business Justification
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:

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

Also review any yellow highlighted text
Page 75
Business Justification Document for Service Level Management

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.
This document was;
Prepared by:
On: <<date>>
And accepted by:

On: <<date>>
Page 76
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.
For example:
We say We should say
We have to increase IT security controls, Two weeks ago our biggest competitor
with the implementation of a new firewall. lost information that is now rumored to
be available on the internet.
The network bandwidth is our biggest The e-mail you send to the other national
bottleneck and we have to go to a managers will take 4 to 6 hours to be
switched local environment. 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 We are making the changes on Sunday
scheduled for a period of time when we afternoon. There will be less people
expect there to be minimal business working then.
impact.
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?”
Page 77
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. If you need assistance in writing business benefits for your
organization please e-mail service@theartofservice.com for a quotation.
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)
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.
Page 78
(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)
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
(for more information on Financial Management for IT
Services refer to www.theartofservice.com)
(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 79
Page 80
SLM SCOPE
IT Services
Scope Document
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:


Page 81
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 82
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:
• SLM1200 SLM Implementation Plan / Project Plan

• SLM1300 SLM Policies, Guidelines and Scope Document
• SLM1700 SLM Process Template
• SLM2200 Service Catalogue
Page 83
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:
The definition of a UC is:
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 84
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 IT Owner

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 85
For example:
Customer IT Service Service Level Agreements
Availability Capacity Disaster

Recovery
Marketing Email
Sales and Logistics

Support
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.
Page 86
Reports
Business Reports IT Reports

Customer Service
No. of % of CPU Transaction
Productivity Bandwidth
Incidents Availability Seconds Rates
Marketing Email
Marketing Internet
Sales Logistics
Sales Accounts
Transport Logistics
Appendices
Include any applicable appendixes that are needed.
Terminology
Make sure that all terminology is captured and documented correctly.
Page 87
Page 88
POLICIES OBJECTIVE AND SCOPE
IT Services
Policies, Objectives and Scope
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 89
Policies, Objectives and Scope for Service Level Management

be considered.
Policy Statement
A course of action, guiding principle, or procedure considered expedient,
prudent, or advantageous
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 focused on answering the WHY question for
this process.
The above Policy Statement was;
Prepared by:
On: <<date>>
And accepted by:

On: <<date>>
Page 90
Objectives Statement
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.
An objective statement any bigger than this text box, may be too lengthy to read, lose the
intended audience with detail, not be clearly focused on answering the WHERE question for
this process.
The above Objective Statement was;
Prepared by:
On: <<date>>
And accepted by:
On: <<date>>
Page 91
Scope Statement
The area covered by a given activity or subject
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 focused on answering the WHAT question
for this process.
The above Scope Statement was;
Prepared by:
On: <<date>>
And accepted by:
On: <<date>>
Page 92
SERVICE LEVEL REQUIREMENTS
IT Services
Service Level Requirements
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release Date:


Page 93
Service Level Requirements (SLR)

be 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 94
(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

Frame/Notes/Who
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 Briefly describe the primary

(Business) function of the service.
(refer to end of table for Use language that is
technical considerations) business user friendly.
(e.g. 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
Customer Information
(Duplicate the following table for as many services to be covered in this SLR).

Frame/Notes/Who
Customer Definition and Whether the customer is an;
date of discussion 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 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.
Service Security Briefly list any considerations

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
Page 96
service? (try to use role

descriptions – instead of
names).
Be careful of using generic
terms like “confidential”.
Confidential can be
interpreted different ways
(e.g. Confidential to the
individual or for the functional
group or for a peer group).
Service Target Response What sort of priority levels of

priorities 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)
Service Target Response Against the levels/priorities

time defined are there
corresponding response
times for the different
priorities?
(Eg. Group A needs
immediate response, Group
B needs a 2 hour response)
Service Support Hours What are the REALISTIC

(Availability) 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 given time period?
What would be an acceptable
number of errors or reruns?
Service Out of Hours Is after hours support

support procedure required?
To what degree is the
support needed (full support,
partial, best effort)?
Page 97
Service Charging policy 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? (e.g. Per user,
per transaction)
What is the customer budget
with regard to this service?
Service Metrics for Can the representative help

performance 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)
Service Breach Clause Does the representative have

any thoughts regarding
penalties that should be
imposed if the service cannot
be delivered according to
agreed expectations?
(Realistic!)
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 (e.g. 2
hours, 1 day, 1 week)?
Page 98
Non-representative Information
(Duplicate the following table for the number of services that data is being
gathered on).

Frame/Notes/Who
SLA Cross Reference Make a reference to any
existing SLAs that may be
able to be adapted or
modified to meet this
requirement.
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 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
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 99
Page 100
TECHNICAL SPECIFICATIONS
IT Services
Technical Specification
Service: <service name>
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:


Page 101
Document Control
Author
Prepared by <name and / or department>
Document Source
I:/IT Services/Service Delivery/Technical Specifications/
Document Approval
• <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
<<Organization name>> Business Unit Stakeholders
IT
Page 102
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.
Scope
• details of each service provided by IT Services including:
• description of service
• functional capabilities of the service
• user characteristics
• user operations and practices
• software and hardware interfaces
• service contacts
• 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>>
Ownership
Include in this section any related Service Level Agreement reference
• Relevant SLA and procedural documents

• Relevant IT Services Catalogue
• Relevant Technical Specification documentation
• Relevant User Guides and Procedures
Page 103
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 104
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
Page 105
organization, availability and capacity requirements and any relevant

agreements that may impact on the service.
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
(e.g. 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
Page 106
Describes other characteristics the service must have, that were not covered
in the prior sections.
Page 107
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 108
Page 109
FUNCTIONAL SPECIFICATIONS
IT Services
Functional Specification
Service: <service name>
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release Date:


Page 110
Document Control
Author
Prepared by <<name and / or department>>
Document Source
I:/IT Services/Service Delivery/Functional Specifications/
Document Approval
• <<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
<<Organization name>> Business Unit Stakeholders
IT
Page 111
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.
Scope
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>>
Ownership
Include in this section any related Service Level Agreement reference
Page 112
Page 113
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.
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 114
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 115
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.
Software Interfaces
Page 116
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/modeler, 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
Page 117
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.
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 118
MULTI LEVEL BASED SLA
IT Services
Multi-Level Based SLA
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 119
Multi-Level Based Service Level Agreement (SLA)

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.
This structure allows SLAs to be kept to a

manageable size, avoids unnecessary
Advantage
Multi-Level based duplication, and reduces the need for frequent
SLA updates.
It requires more time to negotiate and obtain
Disadvantage agreement than other structures.
Service A
SERVICE D
Customer Service B
Customer Service C
This document was;
Prepared by:
On: <<date>>
And accepted by:

On: <<date>>
Page 120
(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
Frame/Notes/Who
Description of the Brief description of the contents
“agreement” 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 Unique identifying number for

the SLA (for inclusion in the
Configuration Management Data
Base – CMDB)
(see www.theartofservice.com
for more details on the
Configuration Management
process)
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 121
Specific Service Information
(Duplicate the following table for as many services to be covered).

Frame/Notes/Who
Service Identification A unique reference number for this
Code service.
(this code can be cross-
referenced in the Customer
information table).
Service Name Preferably use a name that is
common language in the
name).
(refer to Technical Use language that is business user
Considerations later in this friendly.
table) (e.g. 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”)
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
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.
Page 122

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 If the SLA accommodates different
priorities priorities they must be listed here,
with a description on the type of
service that each priority level
should receive.
Service Target Response Here we document the agreed
time response time for the different
priority levels set.
Service Support Hours Consider marginally longer support
(Availability) hours (if less than 24)
Maximum number of accepted
outages.
Minimum percentage availability.
Maximum number of errors or
reruns.
Service Out of Hours Are the in hours support staff the
support procedure 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 What will be the performance
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
Page 123
stated metrics must be listed here.

If the SLA is not to have a penalty
focus, then simply remove this line.
Continuity Considerations If the agreed support hours cannot
(should be linked to the IT be met, then it is necessary to
Service Continuity Plan) 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.
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.
Version Control Information SLA Creation Date
SLA Last Modify Date
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
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 Catalog or Technical
Specification.
Notes & Comments
Page 124
(Duplicate the following table for as many customers to be covered).
Frame/Notes/Who
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 125
Page 126
SERVICE BASED SLA
IT Services
Service Based SLA
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 127
Service Based Service Level Agreement (SLA)

be considered.

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.
Just one SLA document could be agreed for

Advantage all Customers/end users of a single service.
Service based SLA Inability to satisfy the customers that have
Disadvantage differing requirements of the service being
addressed.
Customer A
Service Customer B
Customer C
This document was;
Prepared by:
On: <<date>>
And accepted by:

On: <<date>>
Page 128
The following form can be used as the Service Based SLA document. The
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).

Frame/Notes/Who
Description of the Brief description of the
“agreement” 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.

Data Base – CMDB)
(see www.theartofservice.com
process)

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)

name).
Page 129
Service Description (Business) Briefly describe the primary

(refer to Technical function of the service.
Considerations later in this Use language that is
table) business user friendly.
(e.g. 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”)
Service Expectation Level This is a unique concept to

this SLA design template.
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
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.

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 If the SLA accommodates

priorities different priorities they must
be listed here, with a
description on the type of
service that each priority level
should receive.
Page 130
Service Target Response time Here we document the

agreed response time for the
different priority levels set.
Service Support Hours Consider marginally longer
(Availability) support hours (if less than 24)
Maximum number of
accepted outages.
Minimum percentage
availability.
reruns.
Service Out of Hours support Are the in hours support staff

procedure the same as out of hours?
information will be required
when support is called.
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?

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?
penalties for poor
performance.
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 131
Continuity Considerations If the agreed support hours

(should be linked to the IT cannot be met, then it is
Service Continuity Plan) necessary to invoke a
continuity option for this
service.
invocation should occur will
be listed here.
Cross-referencing to the IT
Service Continuity Plan is
also required.
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.

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
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 Catalog or
Technical Specification.
Notes & Comments
Page 132

Frame/Notes/Who
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


CONSIDER THE MOST CRITICAL AREAS OF AN SLA and IT PROVOKES
THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED
ON INDIVIDUAL NEEDS.
Page 133
Page 134
CUSTOMER BASED SLA
IT Services
Customer Based SLA
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 135
Customer Based Service Level Agreement (SLA)

be considered.
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.
An agreement with an individual Customer

Advantage groups could cover all of the services they
Customer based SLA use.
An inability to deal with differing requirements
Disadvantage amongst users in the same customer group.
Service A
Customer Service B
Service C
This document was;
Prepared by:
On: <<date>>
And accepted by:

On: <<date>>
Page 136
The following form can be used as the Customer Based SLA document. The
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

Frame/Notes/Who
Description of the Brief description of the
“agreement” 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.

Data Base – CMDB)
(see
www.theartofservice.com for
more details on the
process)

who is responsible for this
SLA (who would participate
in a review of this
document?)
Representatives from
customer and IT.
document quickly)

customers that are
considered for in this SLA.
Page 137
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.
people’s names and use role
descriptions to avoid dating
the document.


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

Frame/Notes/Who
name).

(refer to end of table for Use language that is business
technical considerations) user friendly.
(e.g. 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”)
Service Expectation Level This is a unique concept to this

SLA design template.
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.
Page 138

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.

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 If the SLA accommodates

priorities different priorities they must be
listed here, with a description on
the type of service that each
priority level should receive.
Service Target Response Here we document the agreed

time response time for the different
priority levels.
Service Support Hours Consider marginally longer

(Availability) support hours (if less than 24)
Maximum number of accepted
outages.
Minimum percentage availability.
reruns.
Service Out of Hours Are the in hours support staff the

support procedure same as out of hours?
information will be required when
support is called.
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?
Page 139

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?
penalties for poor performance.
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.
Continuity Considerations If the agreed support hours

(should be linked to the IT cannot be met, then it is
Service Continuity Plan) necessary to invoke a continuity
option for this service.
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
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 Catalog or Technical
Specification.
Notes & Comments

NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF AN SLA
CONSIDER THE MOST CRITICAL AREAS OF AN SLA and IT PROVOKES
THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED
ON INDIVIDUAL NEEDS.
Page 140
UNDERPINNING CONTRACTS
IT Services
Underpinning Contracts
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 141
Underpinning Contract (UC)

be considered.

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.
This document was;
Prepared by:
On: <<date>>
And accepted by:
On: <<date>>
Page 142
(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:
Frame/Notes/Who
Link to parent Service Level Cross reference to the
Agreement “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)
(see
www.theartofservice.com
Configuration
Management process)
UC Owner Functional role
description of who is
responsible for this UC
(who would participate in
a review of this
document?)
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 If the UC accommodates
(reflected in parent SLA) 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 Consider quicker
(reflected in parent SLA) response time to allow
for delays
Page 143
UC Support Hours Consider marginally

(reflected in parent SLA) longer support hours (if
less than 24)
UC Out of Hours support Are the in hours support
procedure staff the same as out of
(reflected in parent SLA) 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?
UC Charging policy Do we require external
(reflected in parent SLA) 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?
UC Metrics for performance What will be the
(reflected in parent SLA) 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?
UC Cross references Reference number to
other closely coupled
UCs
OLA Cross references Reference number to
any closely coupled
agreements with internal
IT department
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.
people’s names and use
role descriptions to avoid
dating the document.
Version Control Information UC Creation Date
UC Last Modify Date
Notes & Comments
(Duplicate the above table for the number of UCs to be created)
Page 144
SERVICE OPTIONS
IT Services
Service Options
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 145
Document Control
Author
Document Source
I:/IT Services/Service Delivery/Service Level Management/Service Options
Document Approval
Amendment History
Distribution List
<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
Scope
• Service Options
• <<any additional items that you want>>
Audience
This document is relevant to all staff in <company name>
Ownership
Include in this section any related Service Level Management reference
• SLM1200 SLM Implementation Plan / Project Plan

• SLM1300 SLM Policies, Guidelines and Scope Document
• SLM1700 SLM Process Template
• SLM2200 Service Catalogue
Page 147
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 SLM2200 Service Catalogue.
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:
The definition of a UC is:
The definition of a service is:

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
SLM220 Service Catalogue
Page 148
IT Service: Business
Process:
IT Owner: Business
Owner:
Service Business
Criticality: Process
Criticality:
Service Service Options

Components
Platinum Gold Silver Bronze Default
Availability
Capacity
Response
SLA
Recovery
SLA
Service
Hours
Recovery
Options
Security
Pricing
Appendices
Terminology
Page 149
Page 150
PRICE LIST
IT Services
Price List
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:


Page 151
Price List Considerations for Service Level Management

be 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 Catalog (which is where summary pricing information is

presented).
This document was;
Prepared by:
On: <<date>>
And accepted by:
On: <<date>>
Page 152
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.
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.
Page 153
Chargeable Item (examples) Ancillary Services Cost basis

Sales transaction Network connection Simple cost per transaction,
Personal Computer or;
File server Cost per speed of
processing processing, or;
Cost per size of transaction
E-mail sent Network connection Per unit, or;

to mail server Stored limit, or;
Personal Computer Mail items in the “in-box”
Internet connection
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.
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 centers
to the IT department. This method can have a low impact; in that without
transferring funds, the affect on behavior may be negligible.
Page 154
SERVICE CATALOG
IT Service Management
Service Catalogue
<<YOUR LOGO HERE>>
Prepared by: <<PREPARATION NAME>>
Prepared for: <<RECEIPIENT NAME, GROUP, COMPANY>>
Date: <<DATE OF VALIDITY>>
Special notes:
e.g. Does the Service Catalog have a limited life span, if so, indicate
that here.
Search for any instance of << or >> as your input will be required.
Page 155
Version number Owner Location Date
<<Any industry associated logos or ISO stamp or other Quality system related
indicators (e.g. ISO Accreditation>>
Executive Overview
In the past organization’s IT Services have generally grown and developed

into large complex environments. Unfortunately this growth has not always
been as structured and pre-planned as it needs to be.
This has resulted in the IT department not having a very clear picture of all the
services they currently provide with no accurate profile of the actual
customers for each of these services.
Therefore it has become imperative for the IT department to establish an

accurate picture of the services it provides. This can be done through a
comprehensive IT Service Catalogue.
The Service Catalog must be developed in conjunction with customers, who

are better able to describe what they see as “services” than an IT person. If
there is an asset register or configuration management database (a concept
from the ITIL Configuration Management process) these are good sources of
information.
<<The specific reason for you to develop this document should be written in
this section. Was it a result of a customer enquiry?, is it because Service
Level Agreements are to be developed based on the service catalog?, is it
seen as a competitive advantage?>>
Page 156
The Executive Overview should establish the reason for this documents
existence and its benefit back to the business. The above words are generic
and can be tailored to suit your organization.
Scope
It is imperative to determine the scope of the document. What will be included

in the document and why, and what will not be included in the document and
why.
It is also advisable to establish a common understanding of some of the

terminology used throughout the document. For example, the scope section
should determine the definition of a Service.
The Service Catalogue will list all of the IT services currently being provided to
our organization.
The Service Catalogue will provide a summary of the service characteristics,

and details of the users and those responsible for ongoing maintenance of
each service.
<<Restrictions & Assumption – you may only be documenting services for a

specific business unit, or group of users, perhaps you have been advised to
write a service catalog on all services except those in a mainframe
environment. Any restrictions and assumptions you make in developing the
document should be listed here. Don’t think that everyone will be able to
clearly understand what you see as the scope of the document. List these sort
of things in bullet points for easier readability>>
Restriction 1
Text description
Restriction 2
Text description
Page 157
Restriction x
Text description
Assumption 1
Text description
Assumption 2
Text description
Assumption x
Text description
For the purpose of this document, a service will be defined as the following:
One or more IT Systems which enable a business process
<<To learn more about Business Processes SLM1400 - Business and IT

Service Mapping>>
<<Important note: This is a crucial document and information regarding this

document should be held in the company Configuration Management
database. Configuration Management is an ITIL process – refer to the Product
set CONMGT @ www.theartofservice.com>>
Service Summary Sheet
In this section list all Service and the customers that they apply to.
This section of the Service Catalog indicates the names of the services that
will be expanded in later sections and the end users of these services. This
page/s is a useful check list to take to negotiations regarding service delivery,
Page 158
to determine if there are new services or others that should be renamed to

more accurately reflect their purpose.
<<Description of Customers - The “customers” are generally described as

functional groups, but you may have alternative names for the user groups.
Don’t expand on the description of the services here, as that comes in the
following sections>>
Remember for each service listed here you need to duplicate the following
section (section 5) that number of times.
Customers
Service Accounts Sales Marketing Legal Production Retail
SERVICE A
Eg. Accounts
System
Eg. Email
Eg. Intranet
Eg. Internet
Service x
Service x
Service x
Service A
Description
In this section provide a detailed description of the Service being provided.

This description should be easy to read and written in a non-technical
manner.
Page 159
Customers
In this section provide a list of customers that currently use this service.
Options
Option Availability Response Capacity Recovery Service

Type Options Times
Gold
Silver
Bronze
Price List
In this section you should list all charging and cost information that makes up
this service.
<<Important note. Pricing is an area that most organizations try to avoid when
it comes to provision of IT Services. However, pricing can have some very
powerful behavioral change benefits. Have a look at the Financial
Management for IT Services (FINMGT) at www.theartofservice.com.>>
Dependencies & Contributors
List all other services that may depend on this particular service. PLEASE
NOTE THAT THE FOLLOWING TABLE CAN BE MODIFIED BY YOU OR
PUT ONTO A SEPARATE PAGE/SECTION AND PUT INTO A
LANDSCAPE VIEW FOR EASIER READABILITY.
<<List the dependencies for this service. A dependency can be either another
Service that is reliant on this service OR it can be the fact that THIS service is
Page 160
reliant on another service. In whole or in part the different dependencies

should be listed in this section>>
<<For example, if you are describing the accounts payable system/service,

then it may be likely that the Customer relationship database is used to
provide billing details for invoices. In this case the Accounts payable service is
dependent on the customer relationship database – it is dependent on it for
billing address details).>>
<<In the table below you can describe the dependencies (note that there
should always be a corresponding dependency relationship described in
another service description (e.g. in our example – the Customer relationship
database would describe how it is a contributor to the Accounts Payable
system). It is a contributor.
The final three columns of this table allow you to cross reference to any other
agreements that support the dependency or contributor relationship. Using
our Customer relationship database to Accounts Payable system, it may be
that the Customer relationship database is supported by a specialized group
of IT staff. In such a case we may create an Operational level Agreement
(OLA) with them so that they can understand the importance of the
relationship).
(Note the SLA, OLA and Underpinning contracts are all elements of the
Service Level Management ITIL process – refer to products SLM1901/2/3,
SLM2000, and SLM2100 at www.theartofservice.com>>
Dependant Description Impact Service Operational Underpinning

Service on Level Level Contracts
Service Agreement Agreement
A # #
Dependant
or
contributor
Page 161
Page 162
Functional Specification
Include in this section any references to additional Functional Specifications

for this service. This should be simple to read and understandable by non-IT
literate people
<<For relatively simple processes you can describe how different services
connect and work together, for more complicated relationships you would use
the Functional Specification template (ref: SLM2201 @
www.itilsurvival.com)>>
<<For instance you may have a system that holds information about
employees. It may have names, addresses, payroll numbers, tax codes and
other information. It may also be used as a source of names for the local
blood bank to contact for support. With this example, it is easy to see what the
primary and secondary functions of the service are.>>
Technical Specification
Include in this section any technical information that is pertinent to the

Service. This section may point to additional documentation.
<<Be cautious about the level of detail you include on the technical details of
the service. Think of describing the technical specification of the service to a
person who does not have a very good understanding of IT. For example:
Instead of You might use

WAN Computers connected together over long
distances
Server Central computer that holds information that can
be accessed by many people
RAM The ability of the computer to perform many
different functions at the same time
Page 163
MHZ The speed at which the computer should be

expected to perform different tasks.
etc.
Support Activities
Included in this section any supporting activities that need to occur to maintain
the service. This would include scheduled maintenance times etc.
Perhaps the service will be unavailable at certain times of the time or days of
the week. If there are major scheduled outages for this service, then they
should also be referenced in the Forward Schedule of Changes (FSC). The
FSC is a concept described under the ITIL Change Management process
(see product CHG7700 Forward Schedule of Changes Template).
<<You can simply list known times of outage or insert a table>>
<<You also need to list how the end-user receives support for this service.
Can they e-mail and phone? Is there a set Service Desk or Call Centre phone
number? Be cautious about putting an actual phone number in this document.
This is because if the number changes this document is out of date. You are
best of simply describing the number to call (e.g. Call the IT Service Desk)
and then rely on wall posters, other marketing, etc. to promote what that
actual number is).
Customizations or Variants
Within any organization there MAY BE scenarios where a particular service

will be delivered at different levels for different customers. For instance, in
some cases there may be an extension of functionality that other customers
do not require or use.
Page 164
In these instances it is best to capture all variants for all customers under the
original service. PLEASE NOTE THAT THE FOLLOWING TABLE CAN BE
MODIFIED BY YOU OR PUT ONTO A SEPARATE PAGE/SECTION AND
PUT INTO A LANDSCAPE VIEW FOR EASIER READABILITY.
REMEMBER HOWEVER THAT THIS SECTION CAN BE OPTIONAL.
This service has some variants from what could be considered as the
baseline.
Service Customer Description Availability Response Capacity Recovery Service
Version Options Times
Existing SLAs
Cross reference to any existing Service Level Agreements (SLAs) and

contracts associated with this particular service.
Contract SLA # SLA Type Customer

Corporate Based
Customer Based
Service Based
<<The type of SLA can be generally categorized in to one of these three

types. Descriptions are provided below. Whether you leave these descriptions
in the document is optional>>
Corporate Based: covering all the generic Service Level Management (SLM)
issues appropriate to every customer throughout the organization.
Page 165
Customer Based: covering all SLM issues relevant to the particular Customer
group, regardless of the service being used.
Service Based: cover all SLM issues relevant to the specific service, in
relation to this specific Customer group (one for each service covered by the
SLA).
Restrictions
If this service is restricted to a certain group or for use at certain periods of

time, week, month, etc. then you would detail those restrictions here.
Remember to keep the description brief.
Appendices
Terminology
Page 166
Page 167
COMMUNICATION PLAN
IT Services
Communication Plan
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 168
Communication Plan for Service Level Management

be 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 169
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 (to help develop specific examples contact
service@theartofservice.com for competitive quotation).
Generic Benefit statements Specific Organizational example
CM provides accurate information on This is important because…

our IT components.
Allows us to more carefully control the In recent times our control on IT has…
valuable IT infrastructure.
Helps us to more effectively manage Apart from the obvious benefits, the IT
our expenditure on IT. department in recent times has…
Assists with protecting against illegal or A recent example of … saw the

unauthorized software. individual and the company face severe
penalties.
The above Communication module (or elements of) was/were distributed;
To:
On: <<date>>
By:
On: <<date>>
Page 170
Service Level Management Goals
The Goals of Service Level Management.
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 171
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 skepticism.
Identification
• Analyzing current services and Service Level Requirements
• Recording the current service provision in a Service Catalogue.
Definition
Matching & customizing (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 organization)
Evaluation (review)
• Evaluate the service provision with the customer
• Match & customize: adjust service provision if required? (SIP, SQP)
• Match & customize: adjust SLA if required?
Information regarding activities was distributed;
To:
On: <<date>>
By:
On: <<date>>
Page 172
Service Level Management Deliverables
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 focused) and technicalities
(internally / IT organization focused)
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 realized
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 173
Service Level Management Planning
Costs
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.
Details regarding the cost of Service Level management were distributed;
To:
On: <<date>>
By:
On: <<date>>
Page 174
Page 175
BUSINESS AND IT SERVICE MAPPING
IT Services
Business and IT Service Mapping
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:


Page 176
Document Control
Author
Document Source
I:/IT Services/Service Delivery/Business and IT Service Mapping/
Document Approval
Amendment History

Distribution List
<<organization name>> Business Unit Stakeholders
IT
Page 177
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.
Scope
• details of each Business Process and the corresponding IT Service
provided by the IT departments within the organization:
• description of business process
• business 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.
The following documents may help you to complete or understand the
purpose of this document:

Page 178
• Relevant Functional Specification documentation

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.
Page 179
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.
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.
Page 180
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 (e.g. CRM application, e-
mail, word processing, financial tools) to function.
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?
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.
Page 181
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
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
Page 182
Services interact with other business process or

external organizations.
>>BUSINESS Process Description Department(s) Parent Triggers
Process Name Owner Process
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.
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.
Page 183
Page 184
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.
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
Page 185
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 delivery 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.
• 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.
>>
Page 186
This table should be used on a landscape page layout.
IT Description IT Service Hours of Contract Service Level Impact

Service Owner Availability Agreements
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 Hours of Contract Service Level Impact

Owner Availability Agreements
Page 187
Page 188
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 189
Business Process A Business Process B

Department Owner Business Department Owner Business
Rating Rating
IT Services Accounting <<Business Very High Admin <<Business Medium
Process Process
Owner>> Owner>>
Owner <<IT
Service
Owner>>
Service
Impact Very
A
High
Service 24 x 7
Hours
Owner <<IT
Service
Owner>>
Service
Impact High
B
Service Mon-Fri:
Hours 8am -
6pm
Owner <<IT
Service
Owner>>
Service
Impact Medium
C
Service Mon-Sat:
Hours 6am -
6pm
Owner <<IT
Service
Owner>>
Service
Impact Low
D
Service Mon-Fri:
Hours 6am -
10pm
Appendices
List any appendices needed in conjunction with this document.
Terminology
IT Infrastructure: includes hardware, software, procedures, policies,
documentation, etc.
Page 190
Page 191
REPORTS KPI’s AND METRICS
IT Services
Reports and KPI Targets
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 192
Reports and KPI Targets for Service Level Management

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 193
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 194
With regard to SERVICE LEVEL MANAGEMENT the following metrics and

associated targets should be considered:
Key Performance Indicator Target Value Time
Frame/Notes/Who
(some
examples)
The percentage of Underpinning contracts Expressed as a

and OLAs in place that are supporting percentage, it
Service Level Agreements. 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 A reducing

performance 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.
Page 195
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 196
Page 197
BUSINESS AND IT FLYERS
IT Services
Process: Problem Management
Business and IT Flyers
Stat In draft
us: Under Review
Sent for Approval
Approved
Rejected
Ver <<your version>>

sion
:
Rel
eas
e
Dat
e:


Page 198
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 199
Problem Management

IT Services Department

Key Wanted: Long Term Stability
Points: they occur. As of
The IT Department contains, for
example, IT <<mm-dd-yyyy>>
is embarking on a that will change.
Problem employees or
• Proactive Management business staff. New processes will
Approach
implementation The most exciting be in place to head
Program. element of the off potentially
program is the damaging, costly
• Removal Problem
Proactive and time consuming
of Known Management is a set
activities, errors in advance.
Errors.
of activities designed
Provide contact lists
to remove errors designed to
prevent errors for the IT
from the IT
Department as well
• Few er infrastructure. even before they
as the business
incidents
<<First, determine
occur.
Traditionally our managers that they
the audience of this can contact.>>
flyer. This could be focus has been
• Increased anyone who might on fixing errors as
confidence benefit from the

information it

• <<other
points>>

THE BENEFITS THE CONTACTS
PROCESS

List the benefits to
the intended Problem Control List the contacts
audience. To understand the
issue.
Input any graphics in
Keep it Simple here

Error Control
Use Bullet Points To identify the
cause
Proactive
activities
To prevent potential
issues
Page 200

Problem Management
<<Corporate Logo
or image of
IT SERVICE choice>>
IMPROVEMENT
PROGRAM
HELP US HELP YOU
Contact your immediate Manager to let them know what you

need to do your job better
INCREASED SERVICE AVAILABILITY THROUGH FEWER

PROBLEMS IS OUR GOAL
KNOW YOUR SERVICE RIGHTS
Sponsored by IT SERVICES
“Constantly improving and aligning to your needs”
Page 201
EMAIL TEXT
IT Services
Email Text
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release Date:


Page 202
Introduction
In the next section of this document is an example email text that can be
distributed across your organization.
Note, that this is just one piece of text for one email.
However, it is advisable to create a few different versions of the below text,

which you can store in this document, for future use.
This is very important, as each time you send an email regarding your Service
Level Management process it should be different and targeted to the correct
audience.
This document provides a method for also keeping track of your

communication that you have made to the rest of the organization, and to
keep in focus the promises that have been made regarding this process.
Page 203
Dear << insert audience here, for example, Customer, IT Staff, Marketing
Dept etc. >>
Service Level Management and Agreements
The IT Department <<give a specific name here if appropriate>> is embarking

on a Service Improvement Programme.
What does this mean to you?
The IT Department continually strives to improve the service it delivers to its

customers. The IT Services department provides internal support for <<e.g.
Business applications and equipment: Enter any appropriate details here>>.
In order to improve the IT Services and ensure that they are aligned with the
needs of the organization, we have decided to embark on a service
improvement programme. This programme will result in the implementation of
a process called Service Level Management.
What is Service Level Management?
This process is responsible for defining, recording, agreeing and improving IT

Services. It is a process that is there to ensure that service quality is kept to a
maximum.
We have defined the Goal for Service Level Management as follows:
<< INSERT YOUR GOAL FOR SERVICE LEVEL MANAGEMENT HERE >>
What is your involvement?
The IT Department will be creating a list of IT Services that it delivers. This will
be captured in a Service Catalogue (SC). The list of services will then be
Page 204
presented to the different departments within <<organization name>>. From

this list, each department will be able to pick the service(s) that they use, and
through our requirements gathering, make appropriate changes to meet the
specific needs of the department.
From this, we will be able to then formulate agreements on the services being
provided. These will be called Service Level Agreements.
This will help ensure that the IT Department is aligning its Services with the
business needs, provide a way to measure the services, set expectations of
the services being delivered, and more importantly provide an avenue for
discovery in service improvement.
We have appointed a Service Level Manager to help drive this process. The
Service Level Manager will be the interface between the IT Department and
the Department heads within the organization.
The Service Level Manager will work closely with the business in defining the
necessary services and agreeing their level of availability.
However, the process will still require users of the IT Service to call/contact
the Service Desk for support issues. This is vitally important, as statistics
regarding unavailability of IT Services will still be gathered from the Service
Desk. The more people that use the Service Desk, the better the information,
and therefore a better ability to discover service improvements.
The following can be considered a list of benefits to be derived from the

process:
<<
• List benefits applicable to your audience.

• For example: Benefits to the Business:
Page 205
o Improved relationship with customers

o IT and Customers have a clear and consistent expectation of
service
• For example: Benefits to the IT Department
o Better understanding of the level of service to be provided
o Reacting appropriately due to Service Level Agreements
o Operation Level Agreements reinforce communications
>>
The commencement date of the new process is scheduled for: << insert date
>>
OR
Completion of the process will be: << insert date >>
This is a detailed process and there may be some operational difficulties to

overcome, but with your support, I am sure we can provide an extremely
beneficial process to both the Business / <<organization name>> and IT.
If you have any questions regarding this, please do not hesitate to contact me
at << phone number >>
<< Your Name and Titles >>
Page 206
Page 207
SLM PROCESS MANAGER
IT Services
Roles, Responsibilities

Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release Date:


Page 208
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 Use the
expected content of Service Level Management related notes/Comment
documents (involving IT and Customers) s column in
AND different ways.
Coordinates any required Service Improvement If you are
Plans/Programmes to eradicate falling Service Delivery looking to apply
performance for a process
2. Will coordinate process reviews utilizing independent parties role, then you
to provide an objective view on the simplicity of the process can check
and areas for improvement. yourself against
Will be responsible for implementing any design the list (with
improvements identified. ticks or look to
3. Will establish, maintain and review: update your
Service Level Agreements with the business resume).
Customer (including a decision on SLA Structure).
Operational Level Agreements with the IT provider If you are
Underpinning Contracts with third party providers. looking to
4. Is responsible for the creation, maintenance, marketing and appoint a
distribution of the Service Catalog (which documents the IT process
Services offered by the organization) manager or
5. Will control and review: promote
Any outstanding process related actions someone from
Current targets for service performance within the
Performance against SLAs, OLAs and UCs organization
you can make
6. Make available relevant, concise reports that are both timely notes about
and readable for Customers and IT providers. their abilities in
the particular
area.
Page 209
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 Use the
interest. notes/Comment
Ability to use and apply valuable information gained from s column in
customers. different ways.
If you are
2. High degree of people/relationship management focus and looking to apply
an ability to deal with an administrative workload. Will also for a process
tend to be balanced in negotiations – almost to the point of role, then you
neutrality during discussions between the customer and the can check
IT Service Provider. yourself against
the list (with
3. The Service Level Manager will take an active interest in ticks or look to
learning about services offered by external and internal update your
providers. The manager will be interested in understanding resume).
how services are provided, rather than just accepting a
marketing statement. If you are
looking to
4. The Service Level Manager must have good oral and appoint a
presentation skills. They are a “champion” for this process process
and must display an air of confidence, without arrogance. manager or
promote
5. The Service Level Manager must be able to communicate someone from
with people at all levels of the organization; this is one within the
contributing factor that also will require a high degree of organization
understanding of human emotion and resistance. you can make
6. The process manager must be able to demonstrate ways to notes about
“do things differently” that will improve the process. their abilities in
They must not be risk adverse, but must be very risk the particular
conscious. area.
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).
Page 210
Page 211
IMPLEMENTATION PLAN AND PROJECT PLAN
IT Services
Implementation Plan/Project Plan
Skeleton Outline
Status: In draft
Under Review
Sent for Approval
Approved
Rejected
Release
Date:
Page 212
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 generic enough to suit any reader for any organization.
be considered for planning and implementation of this process.
Initial planning
When beginning the process planning the following items must be completed:
CHECK DESCRIPTION
☺ or 2
or date
Get agreement on the objective (use the ITIL definition), purpose,

scope, and implementation approach (e.g. 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 213
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.
Page 214
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 – 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

(e.g. 2 rings)
ServiceDesk to SLMMgt Details of irate callers
Page 215
Service Level Management Based on ITIL Version 2
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”.
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.)
Page 216
Initial During Ongoing

Personnel 0 /
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.
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 dependent on
the timing of the implementation and whether it is to be staged or implemented
as one exercise.
Page 217
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…
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/Commen
ts/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 218
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 (e.g. 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”.
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 219
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
Page 220

Service Level Management Best Practice PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Service Level Management Best Practice PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Service Level Management Best Practice

Building, Running and Managing Effective Service

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

Up to $99 RRP – Absolutely Free

How Does it Work?

What Happens When I Submit my Review?

Many organizations are looking to implement Service Level Management as a

This document describes the contents of the Service Level Management

Presentations can be used to educate or be used as the basis for

The additional information will enable you to improve your organizations

Start by reviewing the PowerPoint presentation.

Service Level Management ITIL V2– This presentation provides a detailed

Service Level Management ITIL V2:

Alternatively, continue by working through the Implementation Plan with the

SERVICE LEVEL MANGEMENT PRESENTATION

Please refer to Objectives and Goals on page 71 within this workbook

Please refer to Business Justification Document on page 75 within this

To meet organizational objectives, the organization has business

Each of the units involved in these business processes needs IT Services

Each of these services runs on IT infrastructure that has to be properly

ITIL provides a framework for the management of IT Infrastructure.

Traditionally we look at the IT department as a collection of specialists with

Best practice processes will transverse functional departments and help to

Explain the benefits of processes in general.

An IT organization needs to focus on all these aspects to deliver the right IT

Generally, the technology perspective gets a lot of attention (time, budget,

There is also an organization perspective: the alignment of vision, strategy

Service Level Management is one of 10 ITIL processes. Here we get to see

Service Level Management is not an isolated process, but:

• Is a process that is based around communication and monitoring

Please refer to Policies Objectives and Goals on page 89 within this

Explain the relationship between the customer – IT and Suppliers.

In reality organizations have typically revamped the SLA’s every 12-18

Talk about how SLM fits in with the rest of IT.

The acronyms in this slide are covered later:

An understanding of these are necessary as we move into the six real

Please refer to Level Requirement on page 93, Technical Specifications

Please refer to Underpinning Contracts on page 139 within this

This is a summary slide regarding the core activities of Service Level

Following pages expand on this one.

Please refer to Service Level Requirements on page 93 within this

Over the years, organizations’ IT Infrastructures have grown and developed,

Nothing should be included in an SLA unless it can be effectively monitored

Existing monitoring of capabilities should be received and upgraded as

It is essential that monitoring matches’ the Customers true perception of

Where multiple services are delivered to a single workstation, it is probably

When completed, the catalog may initially consist of a matrix, table or

Here are all six activities and the relevant outputs.

It does portray the complexity and myriad of information flows however.

Immediately the SLA is agreed, monitoring must be instigated, and service

So what should be in this thing called an SLA?

What else could be or should be included in the SLA?

Please refer to Technical Specifications on page101, Functional

More information on Configuration Management at www.theartofservice.com

An IT Service Management self-assessment scan can be downloaded from

This is a self assessment scan and is therefore more prone to inaccurate

For information regarding an independent scan send an e-mail to

Strategic alignment workshops should be conducted as part of an IT Service

Please refer to Communication Plan on page 165 and Business IT

Please refer to Communication Plan on page 165 and Business IT

Some organizations have chosen to adopt a multi-level SLA structure. For

Such structure allows SLA’s to be kept to a manageable size, avoids

Using a draft agreement as a basis, negotiations must be held with the