3 – Developing Meaningful SLA’s: Establish specific goals and measure performance
In order to demonstrate “value” the IT service provider must develop an SLA that clearly defines what support services are being delivered and the level of performance required by the business customer.
SLA’s are developed for specific IT organization and business customer combinations. Different combinations require different services and performance levels. We need to consider these combinations carefully when developing an SLA because they can significantly alter the scope and content. For example, an infrastructure network support SLA would be different from a software application support SLA. The basic structure of the SLA would be the same but specific services being provided and performance goals would be different.
One of the most difficult issues in developing an SLA is: What do I put in one? The following sample Service Level Agreement structure will provide a good starting point. When developing SLA’s it is easy to easy confuse the difference between the terms SLA, SLG and SIG. A definition which helped me is that an “SLA” is the overall service level agreement which not only describes the services being delivered but also contains Service Level Goals (SLG) and Service Improvement Goals (SIG) which represent service performance goals required by the business customer. Both SLG’s and SIG’s are discussed in greater detail within the following sample SLA structure.
Absolutely agree with alosmt everything you wrote. And about time there was a voice of dissent as I’ve been alone in the wilderness for too long! ITIL v2 was pretty good as a framework but then v3 was a real mess. Also, when ITIL tried to move into App Dev rather than just Operations it missed the mark by a mile.I was always annoyed about the way that a bunch of helpdesk products suddenly called themselves “ITIL service management” products and bolted other components onto their Helpdesk software. For me the CMDB is at the heart of Service Management so you get this right – not just add as an afterthoughtI’ve always struggled with “service management” where the foremost document for interaction is an RFC! How does that work? The foremost document should be a Service Request and yet in v2 the notion of a Service Request was tucked away as a class of incident if memory serves me correctly. When you go to the garage to get your car serviced are you reporting an Incident or raising an RFC? No! You’re submitting a Request For Service (or Service Request)!Also the CMDB (certainly v2) never properly dealt with versioning which you really need to do. If you’re wanting to track software successfully anyway. Again this showed the roots of ITIL as coming from a hardware focused support environment with delivery of software not properly considered.I had high hopes for the evolution of ITIL and wanted to get involved at one point as I have spent a lot of my career architecting solutions and processes in this area. But when I saw the pre-release of v3 I realised that ITIL had lost its way and I switched off. And now I work in another area of IT where I am subject to other people’s naff interpretation of ITIL where they’ve actually used ITIL as an excuse not to think about how service should be managed and thereby implemented a compromised solution that is not fit for purpose or efficient “but we’re following ITIL”