On the next series of blogs, I’ll be reviewing the areas that need to be taken into consideration when perfecting the art of service level agreements (SLAs).
Service Level Management (SLM) is the process responsible for the management of SLAs. The process falls within service design of the ITIL® lifecycle. However, the SLAs will have an impact across the lifecycle.
I’ve found in my experience to get involved as early as possible when the new service requirements have been identified, whether that be related for changes to existing services, creation of a new service or potentially decommissioning of a service (and retiring the SLA attached with it).
SLAs will go through many drafts to ensure that it meets the business requirements. We have to be prepared for many revisions before it may get signed off. Templates are crucial and so I would advise that when the SLM process is introduced to the organization, that you consider creating templates for SLAs and operational level agreements (OLAs) to aid you during the SLM process.
The service design publication gives you good guidance as to what an SLA should contain, in terms of fields. However, the model of the template must be aligned to your position within the organization, so for example if your IT department charges for all IT services, then you will need a larger focus on charging within your SLAs but if it didn’t, then the charging element would be removed.
The most common headings that you expect to find in an SLA would be the service name, description, scope of what the SLA covers, targets in terms of availability, capacity etc., and relevant roles and responsibilities. However, I’ve found including headings around risk and supporting processes very useful with the clients that I’ve engaged with.
Why risk? The customer is not only signing off the SLA in terms of what the service being offered is (with the relevant targets) but they should also be signing off any risks as part of the service (which they agreed to accept during the service design). To avoid unnecessary issues later, it’s best to confirm the sign off of risks accepted by the customer as early as possible.
Why supporting processes? To avoid confusion as to what the IT processes cover, I’ve found having an appendix attached to the SLA with a very high level description of the key processes that support this service to be very useful. For example, this would be the opportunity for the IT service provider to clarify what change management actually covers in terms of scope to avoid any confusion when the SLA goes live.
The areas within the SLA will solely be dependent on the organization, the stakeholders it serves and the services being offered to its organization.
On the next blog, we will look into the key challenges faced when creating SLAs.
*ITIL® is a registered trade mark of the Cabinet Office