In the next IT-service related blog topics I’m going to post here, I’m going to look at Service Level Management (SLM). I'll assume that my readers are completely unfamiliar with this topic.
First of all, I’ll start with a definition. Service Level Management is a name given to management processes that include:
- Identifying and agreeing the IT service level requirements of the organisation
- Monitoring and reporting on actual service levels delivered to the organisation, identifying any weak areas in service levels achieved
- Identifying cost-effective ways to improve service levels delivered.
If the above sounds vague I apologise – I’ll be adding some detail to this in later posts when I think it will become clearer. The bottom line is this: what does the business need, what is IT delivering, how can we improve and bridge any gap?
Of course I can’t talk about Service Level Management without mentioning Service Level Agreements (SLA). If you are a novice Service Level Manager, you’ll be wondering how you write an SLA. Well there is no such thing as a standard SLA first of all, any more than there is a standard company. Generally an SLA will have some or all of the following items contained within it:
- Identification of services offered to users
- Identification of different user groups or communities
- Responsibilities of both the service provider and user
- Reporting intervals and key IT/business representatives or stakeholders
- Definition of service review mechanisms (usually face-to-face meetings)
- Underpinning contracts (such as those we have with suppliers)
(I’ll expand on these items in later posts).
If you are reading this, & then looking at your ITSM tool which (like Serio) probably has all sorts of SLA measurement and monitoring features (often based around simple response and resolve targets), you might be tempted into thinking that you have a SLM process or (more prosaically) ‘we do SLAs’. Maybe, but too often when I ask questions...
- the SLA targets have not been agreed with all (or in some cases any) of the key business stakeholders,
- key services are not identified,
- reporting is ad-hoc and unstructured,
- no proposals for improvement can be found.
These are all signs of an ineffective or non-existant SLM process.
My point is that SLM is a management process – the role of the ITSM tool is to help you manage your targets and monitor what you are delivering. The good stuff (meeting with business stakeholders and documenting what they need, costing this, documenting what you deliver, getting a statistic from your ITSM tool and interpreting it wisely, suggesting costed improvements) happens outside the tool. It’s the value-added things like this that tell how mature a Service Level Management process is, not how closely you monitor different alerts and warnings from your ITSM software.
What I’m going to do in future posts is expand on these ideas. I’ll be talking about Service Level Agreements to give you an idea of how you’d create one, the service catalog, and some of the benefits arising from SLM. Most of all I’m going to try to deal with specifics and practicalities.