Technical services level agreements

[zoe41]

I have a newly commisioned service platform which is being provided to a customer area within my organisation. Uniquely within the organisation this customer area has its own technical team whom are going to install and configure an application(s) onto this platform. So In effect I am going to create what I am calling a technical services agreeement between ourselves and the customer for this 'service' I have confused the hell out of some of my colleagues who are now questioning why we don't add just any old storage into the service catalogue. It did take a while to get technical folk to think of services and not components so I have shot myself in the foot a bit here. I think that because in effect this is an 'unusal' / specialised provision for this team it is justified. And I need to set expecations and draw up roles and responsibilites for this platform etc. There must be others that have been in this situation? have you managed to badge it an any other way that is more appropriate and not confused or muddy the water? The other thing is to set up a level of change mangaement to try and track any incidents which arise including platform availability issues with the 'infrastructure service' (we haven't got into change management yet thats somewhere down our plan.)

thoughts?

zoe

[BorisBear]

Zoe,

I have come across this situation on a couple of occasions and broadly there are a couple of approaches to this.

Where the customer has their own team who are involved in providing service you can differentiate and say that you just provide a 'hosting service'. This hosting service covers not just the infrastructure/hardware but also the service management processes (change, problem, incident, etc - you would of course expect the customer to adhere to established IT processes). The downside for the customer is no ownership of end to end service and you could easily get into a position where you are debating problems with the customers as to whether its your fault or theirs.

Another approach I have used for Services provided in a multi-vendor support environment (e.g. EDS for the Network, Accenture for the Data Centre, etc) is to have a joint working agreement where you define at a granular level what each is responsible for and how they will work together to create joint ownership of end to end service. When I have implemented this in the past I (with assistance from the key players) have hypothesised over the common support situations (e.g. major incidents) and documented the steps each party would carry out to establish whether the cause/resolution was within their supported domain.

This second option would be my preferred approach but I think you really have to look at who is involved. For instance if you question the competency of your customer's IT team then you might not want to have joint ownership of end to end service because you don't want to be dragged into matters created by their lack of capability.

[zoe41]

thanks for that it sounds like I am on the right track in effect I was going along the lines of doing both. i am surprised this doesn't come up more often that it does with multi vendor environments / outsourcing etc etc. thanks Zoe

[UrgentJensen]

Zoe, Boris,

To throw my two penneth in - and that's really all they pay me!

Boris - I think you're on the right in looking at this as a 'hosting' service. but I disagree that the most relevant KPIs are Incident, Problem and Change.

In that scenario you can wrap this all up with metrics around availability and capacity for the service. This would then consider the overall down time against all outage/degradation of service incidents etc.

IM, PM and CM are still entirely relevant but should remain sitting across the whole department.

The technical breakdown approach is viable if, as you suggest, you have third parties involved. This would then wrap up into an Availability & Capacity view for your end customer. Afterall, when it's down they don't really care who's caused it but how long it'll take to get fixed.

And of course as you well know, in true ITIL style, service agreements should start with your underpinning third party contracts, don't agree something with the customer and then work backwards!


Cheers,

UJ
_________________
Did I just say that out loud?

(Beige badge)

[Diarmid]

Zoe,

since you are not responsible for the delivery of the applications on this system, then your effective customer is the team that does this. They are responsible for service management and you are responsible for providing a platform that is available and works reliably.

If you let them share your Service Desk facilities, then all calls on this system are directed to them in the first instance.

Processes need to be rigorous to prevent mish-mash.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718