This is probably a bit specific, but i'm wondering if anyone else here has had to deal with a situation similar to this. Or, even better, someone has published a process.

The Service Management tool we use has a very strict SLA clock on Incidents. The package we have does not include ITIL Change Management, so this process is modelled outside the Service Management tool.

The issue I have is that this week we had an Incident which was logged with a 5 day SLA. Turned out that the 3rd party supplier of the application at fault needed to develop a patch to fix a simple report saving error. This was submitted on an RFC after the patch was identified, but Impact Analysis dictated that this needed to go to CAB as it involved downtime across the business. Only problem is that the next CAB was being held outside the SLA for the Incident resolution.

This was in no way an Emergency Change because it was only a fault with saving a single report on an otherwise perfectly functioning service. In this instance I have advised that the Incident is going to have to go out of SLA and they will attribute it to the Change Management process.

The problem is fairly common. It's not your processes that are the issue here, it's the SLA.

SLAs need to be realistic and one of the golden things you learn with ITIL is that you need to take into account 'underpinning contacts' and OLAs before you can set the overall SLA. In otherwords you're kinda at the mercy of your supply SLAs when setting your internat IT 2 B SLAs.

Let's not forget some basics about SLAs, which I don't doubt you already know, but it's good to give context:

If you're 100% within an SLA then it's too easy, maybe it is perfect, but unlikely. So it's easy for complacency to set in an performance to dip.

If you're only hitting 50% then maybe it's too unrealistic, you get beaten up continuously and performance probably gets worse for it.

So whoever in your organisation agrees and sets SLAs needs to be pragmatic and cut their cloth to suit.

So interpret your example to mean that you need a specific, separate SLA for the scenario (and other similar ones) you've described, or you go back and renegotiate your third part SLAs though that's often a slow and painful process. In fact they might just not be able to offer you a better service anyway...

Now you've just got to get the customer/management to accept that reality.
Hope that helps a little,

That is reasuring, thank you. I've recently joined an organisation which seems to be trying to shake off a VERY reactive culture. Allowing an Incident to go out of SLA is seen as a mark against an individual. They are used to being able to tweak and change the infrastructure unregulated to get jobs done.

I am impressed at how the majority of people here have embrassed Change Management, but there are still some old practices which have trouble sitting nicely with ITIL.

you clould take another approach. Let is go out of SLA ...but have it clearly stated in the SLA and your CM process that any Incident that requries a change froma 3rd party and CAB approval will be removed from the SLA count if it goes out of SLA.

You should not be blowing an SLA becuase of another processes basic requirement - i.e. CAB review / approval and lead times.

Define it clearly and be able to identify the incidents so you can later remove them from the count._________________Mark O'Loughlin
ITSM / ITIL Consultant

Yes, whenever Incidents overrun their SLA you have to put a 'reason' code in there. I've asked that the back office teams start using 'Change Management' as the reason so these can be tracked. Senior Managers of these teams seemed to be more than happy to do this as previously these 'reason' codes have been used as an indicator to show Head Of level where processes are broken or individuals/suppliers who are holding the organisation back.

I'm hoping that I can use this indicator to either remove those Incidents from SLM, or address the issue that the Service Level is not set practically to start with.