This article originally appeared on the ServiceFrame website - http://www.serviceframe.com/BusObjinSLAs.aspx
Service Level Agreements need to change. Service Level Agreements, or SLAs as they are sometimes more commonly known, where traditionally seen as a convoluted document which a Chief Information Officer (CIO) would use to prove that they are providing a satisfactory service. They would make little sense to people outside the IT department and would only see the light of day during their annual review, if at all. However, with the growing trend in outsourcing, they are being utilised more frequently within industries not readily identified as IT-centric. With the emergence of more IT-based solutions to solve non-IT issues, it is becoming more common for more business-centric functions, such as HR, to be described in a SLA.
An SLA is an agreement document used in a sourcing agreement between the service-provider and the client which formally outlines the service that will be provided. The relationship could be a traditional outsourced relationship where the service is provided by an external entity or it could be an “in-sourcing” relationship, with the service provided by a different entity within the same organisation [Hyder]. As mentioned previously, these documents were often IT-centric, with system availability metrics and associated contingency plans. Although they do offer guarantees to business on the system performances, they offered little business benefit to the organisation. This view is verified by the problem CIOs are now facing in that they constantly have to defend their patch while at the same time witnessing the benefits the IT function is providing to the business behind the scenes. Bespoke projects implementing new systems and functionality are not captured in the SLAs and so not typically considered in the service review meetings.
In relation to SLAs in other industries, the service provided often utilises technology to provide the service. A common metric to find in HR SLAs may be how quickly the service provider can upload an employee’s details in the centrally stored employee record systems. Because technology is used to provide the service the temptation is to measure the performance of the technology. But HR has traditionally been a business-centric function. Just because the service is now being provided using an IT-based solution should not mean that the performance of the function should be measured using IT based metrics.
SLA metrics should take the business objectives for the function into consideration, if not reflect them directly in their measurements. This is applicable to IT functions as well as business functions. One of the keys to having a successful outsourced function is to have appropriately defined business objectives for the function from the outset. These could be the overall organisation business objectives such as reduce costs, however it should be applied consistently to the function. For example, functions are often outsourced to reduce cost, in that the service provider can provided the function at lower day-to-day costs. However, all of the costs of the relationship should be examined, such as the cost in transferring the service and possible losses as a result of the relationship such as Intellectual Property.
Measuring business objectives has another benefit in that an Executive can directly relate to their meaning. Executives often talk in objectives, the majority of the time they create them and encourage their accomplishment. Having metrics that directly show the performance of an objective has major benefits over metrics showing system availability performance.
Shifting towards SLAs with more business objectives also leads to what could be perceived as simpler SLAs. More often than not, business objectives are described in simple business language. This can help to set the tone of the SLA and move away from the convoluted technical documents they previously were. A simpler document is more easily read and with useful business objectives at a basic level they could be reduced to a number of bullet-points. This way more people in the service chain can understand them and see how they are providing or receiving benefit. However, basic metrics are still required to measure the service performance.
People are slowly coming to the realisation that the current face of SLAs is not providing business benefit. In their current state they offer few advantages apart from documenting the relationship for legal reasons. Greater transparency is needed to gain the full benefit of the SLA and the outsourcing relationship. Another reason to change the face of SLA is in how they are monitored.
According to Jim Longwood of Gartner, a hamper to the evolution of business-oriented objectives in SLAs is that there is a distinct lack of “dashboard” and “fuel gauge” tools to manage the performance [Colquhoun]. Tools are needed that can clearly show the achievement of the SLAs but to get to this level the content of the SLA needs to be examined. Measuring the performance of SLAs that make little sense to the client is not going to provide value just because it is being measured in a clear way. Once clear SLAs that incorporate useful business objectives are created, tools to measure these SLAs can be investigated.
A place to start in simplifying SLAs is to look at the breaking the content of the SLA down to Service Lines. Service Lines are lists of services under a grouping. For example, Risk Management could be a Service Line within a Project Development SLA. Within this Service Line there would be a number of Services, such as Risk Identification and Risk Mitigation. Within the Services you would then have Service Levels that would measure the performance of that particular service, for example in Risk Mitigation the Service Level could be “% of acute risks mitigated”.
Going back to the Service Line, within the SLA document you could discuss how successful Risk Management helps in achieving the business objective of “Reduce costs”. If Service Providers that you employ achieve the mitigate risk Service Levels above the required level it doesn’t just show that your Service Levels are being reached, it also illustrates how this is contributing to achieving your business objectives.
In relation to Jim Longwood citing the distinct lack of appropriate tools, although there is a lack of them, it does not mean there are none. If you decide to take the approach of breaking your SLAs down into Service Lines that can relate to your business objectives there is a tool on the market that can help: ServiceFrame™.
ServiceFrame™ is a web-based solution the captures the services being provided to your organisation along with gathering metrics on the performance of these services. It presents these metrics in up to date information using a traditional traffic light model, through a dashboard and customizable reporting engine. The information is presented to the client arranged by SLAs, giving you a view of all of the current SLAs that are held by your company. Within the SLAs the services are arranged according to Service Line, Service and finally Service Level. There is also the option to view “My Services”, which gives a view of all the Service Lines currently being used by your organisation. This is then broken down into Service Levels and the SLA the Service Line is associated with. These two different views allow you to view your Service performance information from two aspects: from each SLA and from the range of services you utilise.
The web-based approach also makes it very easy for service providers to update your metrics, all is required is a browser and internet connection. They also receive notifications of when an update is required. These two factors combine to ensure you have the most up-to-date metrics possible, helping you measure your business objective performance.
You can see a demo of Serviceframe here or start a free trial here.
Monday, March 23, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment