Neven Zitek As part of my job responsibilities, I had the opportunity to assess and analyze many different IT organizations. Only a few of them have business expectations against the services they provide in written form, and others operate under a loose interpretation of what businesses might expect, which changes on a regular basis. Strangely enough, IT enjoys such an arrangement, disregarding the amount of confusion those changes produce, as there is no actual way to confirm success or failure. It’s like watching a never-ending game of chess in which the rules are changed after each turn, and neither side wants to bother with tracking them.
On the other hand, I haven’t met a single IT organization or business representative who doesn’t know what a Service Level Agreement (SLA) is. Among them, only a selected few have one in place for internal IT services, and even fewer of them understand the Service Level Management process (or even has one implemented). Since Service Level Management is a very (!) important process within the Service Design part of the ITIL Service Lifecycle (some may argue – the most important), why does it get neglected in so many IT organizations?
Service Level Management
Figure 1 – Service Level Management
The goal of ITIL Service Level Management is to ensure that agreed levels of current IT services are provided, and future services can be delivered within agreed targets. This is achieved by:
- defining, documenting, measuring, reporting and reviewing the level of provided services,
- maintaining good relationships with both business and customers,
- improving customer satisfaction,
- ensuring clear and unambiguous expectations of the delivered service levels, and
- implementing proactive measures for service level improvement whenever costs can be justified.
The main document, which describes the customer’s expectations and targets for the service provider, is called the Service Level Agreement (SLA). Note that the SLA is an “agreement,” and the foundation for a good relationship between customer and provider, and should not be used in any way that would favor a single party. The SLA can be service-based, meaning that a single SLA is used for all customers using that service, or customer-based, in which case the SLA covers all services used by a single customer.
It’s also common to use a multi-level SLA structure, where on a corporate level all generic SLAs are used covering all common services; on a customer level customer-specific SLAs are in place regardless of the service used; and on a service level all SLAs for each service are maintained with relation to the specific customer using them.
Sometimes the service provider has to include other organizational units within the company in order to deliver services within the agreed conditions. A good example would be the purchase of spare parts, or replacement equipment where the purchasing department has to be included. In such a case, the service provider (IT department) will sign an Operational Level Agreement with the purchasing department, thus ensuring that this part of the customer support process is also within agreed SLA terms, even though a different department effectively manages it.
If the service provided is dependent on an external third party (such as a WAN link provider), then any contract signed must reflect any service levels agreed within the SLA. Such contracts in ITIL terminology are referred as Underpinning Contracts.
Fit for purpose vs. Fit for use
Imagine your customer wants to purchase a large number of computers, in order to replace the old ones. In general, there are two options: a) desktop PC, or b) laptop. Both desktop PCs and laptops can be used to browse the Internet, send and receive e-mails, or create spreadsheets.
While desktop PCs will be more applicable in areas where raw processing power is required, laptops will be the choice for areas where mobility is required. At the end of the day, selection will be made depending on the “fit for purpose” principle, or in ITIL terminology: based on utility.
But, you need to understand the customer’s business needs in order to fully meet their expectations:
- Will a desktop PC to be able to perform highly demanding tasks with ease (capacity)?
- Will a laptop’s battery last for the full duration required for mobile work (availability)?
- Do computers include any sort of anti-theft system, data encryption and data loss protection (security)?
- Can they be replaced quickly enough in case of malfunction (continuity)?
Based on those requirements, you, as the provider, will offer several models of desktop PCs and laptops, effectively making a commitment that they are “fit for use,” or in ITIL terms – provide warranty.
Clear communication regarding requirements and expectations is a key feature for successful Service Level Management.
Customer satisfaction through review and benchmarking
Service Level Management is strongly dependent on other ITIL processes such as Business Relationship Management, Financial Management, and most importantly – Capacity Management. The latest is extremely valuable to the Service Level Management (SLM) team, as it provides up-to-date information about available capacity, which gets processed by SLM and compared with current service performance and/or interruptions. By comparing available data, SLM produces service gap analysis, which is passed back to Capacity Management for evaluation and implementation of required changes.
With all the benefits SLM brings to the table, it’s still a puzzle to me why SLM doesn’t get more attention within IT organizations. My guess would be that with the natural growth of service-based delivery models, IT organizations will eventually realize that technology itself doesn’t guarantee customer satisfaction. Happy customers are more important than the latest version of hardware, software or whatever, and this is where Service Level Management provides measurable value, for both the customer and the delivery.
Download a free sample of the Service Level Management process template to gain more knowledge regarding service level management.
