Incident Ticket Closure

[AndyW]

Hi Group,
one question regarding the Incident and Problem MGT process.
We have over here an INC process in place. Every opened ticket has 4 urgency levels behind it.
Question: when should the ticket be closed?
Scenario: User reports a defect in the application. The appropriate resolver group identifies that the defect can be solved by a code change and triggers off a RfC. The RfC runtime is approx. 2 days (incl. Testing, documentation etc.)
Should the INC ticket be closed after successful implementation of the RfC or after successful identification of the root cause?

[UKVIKING]

This seems like an exam question rather than a work question.

The problem ticket should be closed when it is confirmed that the RFC successfull fixed the error by the resolver team (dev team ?)

The incident ticket should be closed after the implementation of the rfc and the successful confirmation that the inicident conditions no longer exist by the user who raised the incident
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[AndyW]

Thats what I have thought as well. But I had this morning a discussion with one guy of the resolver group. According to them - waiting for a successful implementation would bring them into troubles with their SLA targets regarding ticket solution times.

[LizGallacher]

If there is no workaround to allow the user to achieve their requirements, then the incident is open until the RFC is implemented. You cannot tell the user that their incident is closed just to avoid breaching an SLA. The SLA IS breached, if it tales that long to overcome the issue. To pretend otherwise by fiddling the figures would not serve any purpose.
That said, it is possible to agree with your customer that the current state of the application does not include the facility in question, but the next release will. In that situation,the user will have to live with the lack of functionality until the Release happens. The Incident may then be closed (with the agreement of the user) with the explanation "User informed that this is not part of current functionality". This prevents tickets being open for 6 months, waiting for a release.

So - be pragmatic!
_________________
Liz Gallacher,
ITIL EXPERT
Accredited ITIL and ISO/IEC20000 Trainer and Consultant - Freelance

[UrgentJensen]

Hi,

I tend to agree with both of you and yes, it's likely that this will change the reporting for that team.

Incidents are about restoring service so if one requires a change to fix it then it has to stay open until the change is confirmed as successful. Tough luck! If they were able to put in place a suitable work around that still means that a problem ticket remains open until an rfc is successfully implemented.

Realistically then it might be that that team requires a different SLA metric looking at incident handling e.g. 'time to promote to Problem' etc. I hope that makes sense.

Cheers,

Urgent

[Mark-OLoughlin]

Agree with all

A Liz says " be pragmatic". It boils down to that in the end.

SLA's are there for a reason. Sometimes it is actually good if they breach once in a while - it tells you the reality of the situation. If they are fudged by closing tickets early - nothing will change. What people forget also is that SLA's can be re-negotiatied if required - an oftern under performed task.

So agree with all - incident stays open until a fix or workaround is put in place - even if this takes 2 days - what will happen is you will then have to investigate why they brached and you may find some intersting things. Why 2 days to put in a change for a number of incidents - can your emergency change process not get this through quicker - are you looking for too much admin , testing etc of an emergency change - do you even have an emergency change system?
_________________
Mark O'Loughlin
ITSM / ITIL Consultant