by Mike Alley of Logicalis
The term service level agreement (SLA) has been around since the 1920s when it was used to hold data processing departments accountable for providing financial reports on a regular basis. That was back when data processing (the forerunner of IT) was considered an adjunct of the accounting department.
Now that IT has become the nervous system connecting all departments of an organization, as well as customers, partners and service providers, the term SLA is showing up everywhere.
Today, everyone recognizes the acronym, but not everyone understands what it has come to mean in its present context. This article looks beyond popular assumptions to the art and science of developing SLAs, shows how they are developed, and puts them in context at the back of a service contract.
Not your father’s SLA
First a look at what SLAs are not: It is a common myth that the more SLAs there are associated with a contract, the better the performance. In fact, SLAs establish minimum levels of performance. They are the small print at the back of a service contract.
The key performance indicators (KPI) of success of any kind of IT outsourcing are the relationship that exists between the customer and the provider, how well the customer manages the service contract, and the cultural similarities between the two companies. As a general rule, a well managed contract will perform much better than the SLAs in it.
The SLA is not a substitute for trust and it’s not a substitute for well managed partnership. If you don’t have confidence in your service provider, you are not going to be able to protect yourself with SLAs.
IT departments need to understand that keeping SLAs simple and focused is the best avenue to success.
Here are the basic principles that we apply when we develop SLAs (and we do a lot of them):
SLAs have to apply to a service that is controllable – I can guarantee that we can fix a technical device, but I can’t guarantee that you won’t break it. We can commit to a high percentage of uptime from our cloud platform, but we can’t promise high levels of availability from an IT infrastructure we don’t control.
SLAs have to be applicable – The level of service must support a client’s internal SLAs to their end users. There is no value in making commitments on services people don’t need.
SLAs have to be measureable – If we are going to commit to remediating a problem in a certain length of time, for example, we have to be able to accurately measure the time it takes. If we are going to commit to a level of service, the specific level must be quantifiable.
SLAs have to be reportable – The system used to provide the service needs to be able to produce the necessary reports automatically.
Service agreements are more of a partnership than a hand-off. Both sides have responsibilities to meet. The biggest responsibility organizations that are considering outside service providers have is to understand the internal SLAs their end-users require. A lot of times organizations transitioning to an outsourced service never had internal SLAs so they don’t know how to determine the levels they need to meet internally.
Organizations also have to understand that more stringent SLAs are going to cost more. The tendency is to want the most stringent SLAs, but its more important, and more affordable, to realistically match the level of service you require from a provider to the actual level of service you need. Remediating a problem within four hours instead of two, for example, may be soon enough.
As important as they are for establishing a benchmark for service, SLAs are too narrow a focus to evaluate a provider. You need to look behind the scenes to see how providers meet their SLAs. Find out what tools, and processes they use. Ask about the level of training of their people. Where do they gain efficiencies that allow them to meet the SLAs?
Due diligence should include determining if the service provider is financially sound, has a proven track record, and adheres to ITIL best practices. You also want to ensure that your provider partner’s culture is compatible with your company. You are, afterall, entering into a long-term relationship. You want to know if you and your provider can get along on a daily basis.
Failing to meet an SLA results in a penalty to be paid by the service provider. Generally, the penalties are meant to be an acknowledgement of a missed benchmark, and are more of a slap on the wrist than a kick in the head. The kick in the head comes if a service provider misses too many SLAs. A pattern of missed SLAs is grounds for defaulting on a contract.
Remember, though, nobody wins when SLAs aren’t met. As a result, the real value of an SLA is not what appears at the back of your contract, but the experience, toolsets and processes that stand behind them and propel the technology industry toward the goal of delivering IT as a service. The best SLAs are the ones nobody notices because, a far as your users are concerned, things just work.
Mike Alley is director of Managed Services at ITC outsourcing provider Logicalis.