Welcome to the Blog
The articles here will help you to manage your IT projects effectively. Please feel free to comment and come back regularly for more.
If you have an RSS reader, there is a feed available here
Why Do Service Level Agreements?
Posted by Cathryn in : Supplier Management , trackbackI’ve been doing some procurement work lately, negotiating with a client’s supplier and putting a Service Level Agreement (SLA) in place for a new service. This morning, I found myself having a conversation with a colleague about what the point of all this work was.
After all, the arguement went, if you’ve got a good relationship with the supplier and they’re providing a good service, SLAs don’t really matter and, conversely, if they’re supplying a bad service, SLAs won’t fix that.
I believe good, acheivable SLAs that support the client’s objectives in buying the service are essential. Certainly, they won’t make a bad service good, but they do help to create a good service in the first place and, if managed properly on both sides, help to create and maintain a good working relationship.
Firstly, going through the exercise of agreeing SLAs gives both sides an opportunity to really understand what is required and what can be delivered. By setting a service level such as, say, stating that power in a data centre will be available at least 99.99% of the time, the supplier is forced to think about how they will actually produce that standard of service, and the client is forced to think about whether they’re prepared to pay the cost of that, what they will do about the remaining 0.01% of the time, and just how much it really matters to them.
Secondly, SLAs give a basis for monitoring a service and, if appropriate, improving it. If a service is considered to be ‘poor’ but there is no real measure of that, setting a realistic SLA can help both client and supplier to understand what ‘poor’ means, and work to improve it.
Finally, if an SLA is not met, then the fact that it is contractual with penalties attached can help to concentrate the supplier’s efforts to improve, and even help their service managers to get their own organisation to provide the support and resources they need. When buying services, and negotiating SLAs, I’m keen to make it clear that the best situation for everyone is for the supplier to be able to meet those SLAs. A good Service Level needs to have some sort of penalty for failure attached, but invoking service credits is a bad situation to be in both for the client and the supplier. If the client has unrealistic expectations, then it is better for both parties that these be flushed out early. Likewise, if the supplier is unable to meet reasonable SLAs, then it may be better that the contract is not signed.
Ideally, SLAs come out of well defined business requirements, and measure something useful. For instance, if the service is a network, an metric around network availability may be offered, but the real requirement is probably to have a high enough level of thruput rather than just to be able to connect.
I always find it useful to make sure I understand the supplier’s ability to meet their SLAs, by looking at the system design, asking for statistics for similar services they are providing to other clients or some other method. If a supplier is offering to fix hardware within a certain amount of time, where do they keep their spares and how long will it take them to get an engineer and part to site? If the service level is for a system to be up for a percentage of the time, is there sufficient redundancy built in so that if a particular component fails, it won’t bring the whole system down? If the network provider is offering 99.5% availability across all sites in a multinational network, what are their achieved figures over the last year for each country?
An SLA is a commercial agreement which should provide part of the design criteria for a service. By making the agreement early in the relationship between client and supplier, both parties will have a clear understanding of the service, and the supplier has its best chance of meeting the client’s expectations.
And just one final thought - to most people, using percentages to express time based metrics eg. the network will be up 99.5% of the time on 24*7, is rather meaningless. It is far better to explain this by saying that, if the network is meant to run all day, every day, it will be down for no more than just under 2 days a year. That will always get person using a computer to exclaim in horror ‘2 whole days!!’, and will remind you to add ‘and a maximum of 2 hours at any one time’
Comments»
no comments yet - be the first?