SLA vs OLA

[TarunSachdeva]

Hi,

Could any one help me with the difference between Service Level Agreement (SLA) and Operational Level Agreement (OLA)?
Where do these exist?
_________________
Thanks & Regards,
Tarun Sachdeva,
ITIL Foundation Certified.

[LizGallacher]

Very simply:-
The SLA is with the Customer, and states what services are to be provided, and the KPIs. In order to actually provide the service, the IT department needs to go to internal IT departments (Network Support, Service Desk, Application support , whatever) and External Suppliers (hardware Maintenance, WAN etc). The OLAs are the agreement by each internal group to supply their services, and the external organisations are covered by Underpinning Contracts (UCs or UPCs). Only when each element of the service is "backed up" by one of these OLAs or UCs, acan SLM know that they can actually provide the service. This is covered in detail in the relevant ITIL books.
_________________
Liz Gallacher,
ITIL EXPERT
Accredited ITIL and ISO/IEC20000 Trainer and Consultant - Freelance

[TarunSachdeva]

[LizGallacher]

It is a written document, and it is a good idea to have it as a CI, along with the UCs and SLA docs. that way, the CMDB will show the relationships between them, so if an SLA is to be changed (under Change Management), the affected OLAs and UCs can be identified, and the impact assessed.
_________________
Liz Gallacher,
ITIL EXPERT
Accredited ITIL and ISO/IEC20000 Trainer and Consultant - Freelance

[Andy_S]

Having produced a Catalogue, I have moved on to producing an OLA for the Services described in the Catalogue. The Services are provided by my function to another internal division of the same company and they face off to the customer, so the "Services" are Network Support, DBA, Applications Support, Incident Handling etc. Looking at the ITIL guidance for OLAs, I have started with the ITIL headings: Service Description, Service Levels/Hours, Service Availability (all fine), but then I have; Reliability, Customer Support, Service Performance, Procedures, Service Continuity, Charging and Service Reviews (Ok with this one). I can't say I can think of much to put in these sections - any ideas what I really need? I want to keep it as brief and simple as possible.

Any thoughts/ideas welcome!

[m_croon]

Andy,

My first thought would be: if you can't think of anything, skip it. ITIL is not about rocket science, keep it practical. When I look at the topics you mentioned, I would define them as follows:

* Reliability: how often will a disruption occur. This is different than availability. Many incidents (=low reliability) with short downtime may well result in lower availability than one big incident (higher reliability) with longer time to solve. From demands on reliability, things such as redundancy should be defined.

* Customer supt: how will the supplier act regarding training and documentation (manuals) for users.

* Service performance: the twinbrother of availability. How well/ how quick should the service be in terms of logging in etc.

* Procedures: how will supplier and customer (OLA-partners) work together, in other words: what does the interfacing on processes such as incident and change management look like.

* Service continuity: what to do in case of a defined failure of the service, such as through fire, earthquake etc.

* Charging: how often and in what way will the customer be billed? Fixed price? Usage? Once a month etc.

Hope this helps,

Michiel

[Andy_S]

Yes, think it's good advice to "skip it" where unsure. I have looked at the contract my internal customer has with the external customer and essentially the only contractual SLA targets they have to meet are:
- Availability
- Response times to Incidents
- End to End Response times
- Message Accuracy

So, from my catalogue of 19 internal services, I guess I only need to concentrate on those that underpin these contractual areas. It's just a bit difficult for me to know where "Server Management" or "Database Administration" underpins Service Availability. I guess its by keeping proactive monitoring of service and capacity levels/thresholds and component reliability that these contribute to Availability. Incident and Chnage Management kicks in when Availability is lost, or has the potential to be, whichis when our SLA targets for Incident response times kick in.

Ta for your help Michiel

[Lola]

What if you have a supplier that does not meet the agreed upon SLA's? Are there any penalites of any kind? We're running into this problem, we have the SLA's but we cant really do anything if the service levels are not met. We are currently limited to a single internal supplier.

[itilimp]

For internal SLAs, you'd need something written in to the agreement stating what the penalties would be for failiing to meet them (as you would in an Underpinning Contract).

In our case internally we don't get fines, but if we fall below the accepted variance we are required to investigate and report to the business (in our case councillors) explaining the reason for it and what is being done to address the issue. Last year for example, the report resulted in the agreement to lower our target to a more realistic one given the resources available.

[Andy_S]

The issue of penalties really depends on the culture of your organisation and whether there is an internal IT recharging mechanism in place.

If IT charges for its services and an internal money transfer actually takes place then you could implement "virtual" penalties whereby at the end of the year you assess what penalties would have been incurred had IT been provided externally. This will give you a benchmark of their performance (and here is where the culture of your organisation is important) which could be used to get senior management to look at the opportunities of externalising the service if perfromance is really impacting the business that badly. The benchmark can just be used to kick IT into action or drive them towards the implementation of a Service Improvement Plan to rectify the issues. The example quoted by itilimp, where targets were reduced as a result might work in Local Government, but most commercial organisations would not often countenenace a drop in targets due to previous SLA failures, but it is a valid argument where the organisation does not want (or have the ability to) spend more on IT to achieve the stated targets. It also possible the targets were wrong in the first place and by weighing up the virtual penalties against what the actual financial impact to the users of IT Services was gives you the opportunity to set the targets far more realistically. Ho hum, just my view anyway...

[highdiver_2000]

To meet the SLA with the customer, you need have back to back agreement with your vendors and staff.

For example if you have an SLA on say servers with 2 hr resolution, clearly you will need to have some kind of redundancy, eg clusters. or Gold support from the vendor.

Application you may need another SLA. Not all application vendors can observe the same SLA as hardware. Very few software vendors have 24x7 standby.

Another point I have just learnt. DR and maintenance contracts. Some contracts are silent on DR servers, some clearly don't support. If your DR application servers don't work during or out of exercise, whats next?
_________________
Highdiver