|
The
Key to Quality Service Level Management
by Karsten Smet KARSTEN.J.SMET@britishairways.com
© 2003, Karsten Smet All Rights Restricted
Introduction
ITIL has clear definition of Service Level Management and goes into great
detail regarding the process, implementation and the content of the key
deliverable the Service Level Agreement (SLA). The question is, is the SLA
really the key deliverable? ITIL does not go in to great detail of other
items that form the make up Service Level Management and in particular
Service Level Requirements (SLRs), Operational Level Agreements (OLAs),
Underpinning Contracts (UCs) and the Service Catalogue. This article
focuses in more detail on these items and aims to provide detailed guidance
on their production. The final outcome will be an understanding of whether
ITIL is too focused on the production of SLAs?
Service Level Agreements
Although this article will not focus on SLAs it is vital to outline what we
mean by an SLA. A Service Level Agreement is a documented agreement between
IT and its Customer (Internal to an Organisation), on the levels of a
service being provided. In my opinion the most important aspect of an SLA
is that it is an Agreement and hence bears no contractual weight to meet
these targets but it is still a commitment. The SLA should not favour one
side but be a fair reflection of what the business wants and what IT can
provide and not a smoking gun held pointing towards IT or a method of
avoiding providing an adequate service to the business.
It does however set expectations’ of what should be provided. The obvious
risk of missing Service levels is damage to the business however one of the
biggest failings of not hitting agreed Service Levels is the effect this
will have on Customer perception that can ultimately result in Customers
losing faith in IT.
Another common failing is the inability for organisations to create
agreements which are simple to read and concise. An SLA should not be
twenty pages long (and my experience this is not uncommon) but be simple,
easy to read and preferably no longer than 3 to 4 sides of A4. ITIL itself
identifies ways of making this work across large organisations with
multiple services. The use of Customer based SLAs (one SLA per Customer
across multiple services), Service Based SLAs (one SLA per service), and
multi-tiered SLAs where there will be Corporate based SLAs, Customer based
SLAs and then Service Based SLAs in three tier format all offer the ability
to enable the creation of simple easy to manage SLAs.
In a previous article I have mentioned the Mathematics of Service Management
and some simple rules to follow when creating metrics. These rules can be
applied to SLAs, OLAS and UCs. Many organisations spend far too long coming
up with encompassing SLAs that in truth are not measurable so never give an
understanding of how the service is performing, therefore all the work put
in to their creation is wasted.
Service Level Requirements
As mentioned at the very start of this article do we put too much emphasis
on SLAs? To begin to understand this, the first question one should ask is
where does this agreement come from? To ensure that an SLA can be drawn up
and be a fair reflection of business and IT it is vital the business
requirements for any service can be clearly understood and documented. In a
mature ITIL environment gathering the requirements will be supported by the
Service Desk where appropriate, who are speaking to Customers everyday, and
frequent liaisons with the Availability Manager to discuss the Customers
perception of the service but even in this environment the ability to
gather and document a true set of Service Level Requirements which can then
be made in to an SLA is far from simple.
The simple fact is that IT and the business speak a different language. To
enable requirements to be gathered it is vital that initially Customers are
simply asked what they need from a service avoiding the focus on SLA
headings such as ‘Availability, Throughput etc.’ as these will mean little
to an everyday User or Customer. In an ideal world where time is not an
issue it is useful to sit with Customers who use a service (or in a service
being created for the first time, through development, build, UAT etc) and
understand their requirements not just take what they say and translate to
‘what we think they want’.
Once it is clear what they want from a system and you understand what they
mean from their requirements it is possible to begin to transfer the
information into an SLA. The basic template should be derived from, and
maintained within Service Level Management. It may be that certain headings
of an SLA are not applicable and if this is the case there is no reason to
merely create requirements. This draft should be totally focused on the
Customer and reviewed with the business to allow them to understand the
translation of their requirements to an SLA and gather a picture of what
each section of the SLA means.
From this negotiations can then begin. IT should go away with the
requirements and understand if these can be met and where not be able to
offer reason and options. The best way to ensure the business can
appreciate why a requirement can or cannot be met is when it is put in
financial terms (extra cost of 24 hour availability). The negotiation
period will often result in multiple draft Agreements but the focus must
always be what is the most we can provide our Customer without
overstretching IT.
Operational Level Agreements
Now we understand where the agreement comes from how can we begin to ensure
that the levels are met within IT? Operational Level Agreements (OLAs) are internal.
The easiest way to look at an OLA is that it is an agreement within IT,
which does not include an external supplier or internal Business
Customer.
To ensure an SLA is met it is vital that IT works together to ensure the
targets can be hit. A vital piece of the Service Level Management process
is prior to implementation of an SLA is that any OLAs and UCs are reviewed.
What is the point in creating an SLA, which cannot be met because
internally, between support teams, there are no targets?
An OLA follows a very similar (if not identical) structure to an SLA. It
can be interested in the typical areas highlighted in SLAs such as Service
Hours, Responsibilities, Support details etc. however the requirements
internal support groups have on each other are very different to those
outlined in the SLA which encompasses a business perspective. This will
mean the language used in OLAs and focus will usually be more technical
than in SLAs.
It is acceptable to have OLAs that do not focus on typical SLA items such
as Availability and Service Hours but are merely a set of statements agreed
between IT areas because there is no specific Service to measure. This
could be between an IT area and IT procurement where there is no IT service
but without this in place IT kit may not be purchased in time to support
SLAs somewhere else in the business.
A common misconception of OLAs is that every SLA has a specific set of OLAs
in place to meet them. This would result in departments having multiple,
potentially duplicate, OLAs and become unmanageable and impossible to
measure. An example of an OLA that every IT organisation should have in
place is between the Service Desk and the support groups. This is vital in
restoring service and hence part of meeting all SLAs.
OLAs are notoriously difficult to get in place, as internal areas often do
not want to feel that one area is being pressured more than another. It
begins an interesting internal IT battle where it is vital that the Service
Level Management team are empowered to make decisions.
Underpinning Contracts
Underpinning Contracts (UCs), often called Schedules, are contractual
agreements between any third party suppliers of IT Support to your IT
Organisation. It is vital to keep these up to date and ensure that the third
party will provide required levels of support as necessary. This is
different to an OLA and SLA because it is contractual so these targets MUST
be met once agreed and failure for meeting these targets may well result in
legal action.
The UC will be full of legal jargon and hence will also be larger than an
SLA or OLA and is more complex to read. The important thing to remember
when writing and agreeing an Underpinning Contract is to ensure you aim the
targets at the correct level. For example if your Service Hours are too
high the Contractor may charge more for their service, if they are too low
an Organisation may incur large costs for out of hours support. This is a
fine balance but one which must be accurately managed by the Service Level
Manager and their team.
Service Catalogue
How do we know what Services we provide and hence what needs an SLA in
place? This is the one of the jobs of the Service Catalogue. The Service
Catalogue is often overlooked in its importance. The best way to approach
the population of a Service Catalogue is to understand what Services the
Customers perceive. It is not uncommon for a Customer to have a single
service that is made up from three or four separate applications where at
least one of these is invisible to the business.
By asking Customers (i.e. SLRs) you can begin to document what goes in to
the Service Catalogue, where the complete set of ITIL processes are in use
it will be possible to get some of this information from the Service Desk
who receive comments directly from Customers on the Services provided. Any
Service Management tools should also be audited as Services forgotten about
by IT may still be active and have had Incidents, Problems and Changes
logged against them. The Configuration Management Database will also
outline Services, but the key is always to understand the Customers
perception.
A Service Catalogue can appear in many different formats such as word
documents, spreadsheets etc. and ITIL does offer guidance on the sort of
information captured in the Service Catalogue, however expanding on this to
make a catalogue a worthwhile within an IT support Organisation I
personally feel the following items should be considered;
• Service Name
• Basic Service Description
• Key Business Users
• Importance of Service
• Key Support areas
• Planned Maintenance/Outage data
• SLA (in place and where it is located)
By providing slightly more information it is possible to use this resource
within a Service Desk to support the allocation of priority to faults and direct
Incidents to the relevant area alongside the Configuration Management
Database. This will also aid in the general support Service Desk staff can
give to improve Customer satisfaction through system knowledge,
understanding Customer usage etc. The Service Catalogue should also
facilitate the ability for organisations to ‘speak the same
language’.
Conclusion
I personally empathise with ITIL in its reluctance to detail how to use
OLAs, SLRs, UCs and the Service Catalogue because these subjects are not
simple to define. The techniques in writing and documenting SLAs are much
more prescribed than any of the other areas that are open to debate and an
Organisations ‘Service Level Management groups’ perception of the
framework. It could be a weakness that this is the case as many companies
have decided against OLAs and UCs and use SLAs throughout their IT support
structure which will often detract, and potentially destroy, the benefits
delivered by Service Level Management due to the prescribed format of SLAs
which will not fit third parties and internal support groups., however
every organisation is different and hence every OLA and UC format will also
differ from organisation to organisation.
ITIL is very focused on the production of SLAs but I do not believe that
they over emphasise this point. The framework is very much Customer based
and trying to improve the IT service that is provided to the business and
hence looks at how the production of SLAs helps support this. The important
thing to realise is that SLAs are pointless if they mean nothing and
without the deliverables highlighted within this article Service Level
Management will fail as a process. If SLAs are the key deliverable of SLM
then it is fair to say that the above deliverables are the locksmith
cutting the key to ensure it fits the Service Level Management lock.
Click here to return to the articles page.
|
