When to close the Incident ticket?

[Bodhi]

Hi there,

My first post so be gentle

I was just wondering, when an incident is raised that ultimately becomes a problem and a problem call is raised, at what point should the Incident call be resolved?

I understand that the Incident call can be closed when a workaround is implemented, but what happens if there is no workaround and the user/s must simply hang on until the undrlying problem (and thus it's associated Problem call) is resolved? Does the Incident ticket remain open? This seems a little illogical to me.

[_GrenDeL_]

The incident call should be always closed as quickly as possible. The main determinant is to restore the service for the User. It doesn't mater how (it can be workaround) but when. From my point of view it is rather not posible that user is affected longer time and there is no workaround. The problem call is opened to investigate the root cause of the incident (or group of incidents) and to find permanent solution. If the cause and action which allow to eliminate the problem are know the problem call can be closed. On that point the change call should be opened which can be closed after the implementation of change.

[rjp]

Remeber that one of the key metrics is 'Time to Repair' (and its aggregate Mean Time to Repair).

That is, it's not Time to Closure. Personally, I don't really like 'Repair' as it focuses the attention on break-fix incidents. I prefer 'Resolution'. And most tool sets use Resolved as a status value for an incidenet record.

Closure occurs after a predetermined lag and/or negotiation with the end-user / customer (depending on the classification, context, impact, SLA etc...)

So in the first instance, you should be looking at how quickly (and effectively) incidents move to resolved / restored / repaired / whatever...

As _GrenDel_ (is that a reference to Beowulf?) implied incidents that remain unresolved because there is no acceptable work around are likely to be rare. But they can occur, and even remain unresolved after a known error is registered against the underlying problem, because the ability to implement the required changes may be beyond current capability. For example, what if the problem is tracked to an error in the code base of a closed-source application, and you are going to have to wait until the vendors get around to providing a patch? There may not be much you can do - other than reaching for a loaded lawyer

When this happens you absolutely want to keep your incidents open. ITIL isn't just about Service Support - keeping things ticking along. It is also about Service Delivery - planning and improving. And that requires information that reflects what is actually happening. Never fluff the data - it isn't about getting 'sweet numbers' it is about getting accurate ones.

[Bodhi]

Thanks for the comments guys. Most helpful. However, for whatever reason I would suggest that the frequency of incidents that we get raised that we are not able to resolve either permanently or with a workaround within the allotted SLA is relatively frequent. In these instances we will raise a problem call in order to find an ultimate resolution, but until we do, often the users just have to wait.

We had a good example of this a couple of days ago when our exchange server developed a strange error whereby internal emails were not being sent or received. Nobody in-house could resolve the issue, and in the end we had to get Microsoft to assist. Obviously, whilst this was all going on we were logging multiple related incident tickets as users called the Service Desk.

My question, in light of the above expample, was should we have closed the incident tickets once we realised that there was a Problem and had subsequently raised a problem call? My gut feeling was yes, but in retrospect, and after having read your emails, I now feel that it should have been no. We should have left the Incident call open until a permanent resolution was found via the Problem investigation. That way our metrics would have reflected the real impact on the service rather than just the time it took to recognise that there was a problem.

Thanks again guys.

[_GrenDeL_]

From my point of view incident can be closed after restoration service for the user. Moreover user have to confirm that he happy and his issue is fixed After that the incident can be closed. This way which you have presented for me is not acceptable because you cheat SLA (if you close incident in order not to breach the time of resolution)
In the situation which you have presented the problem call can be opened simultaneously with incident and closed after revealing the root cause (probably at the same time as incident)

[rjp]

Bodhi,

your example is most illuminating.

Where ITIL based processes are mature they work in concert. In the early stages the requirement to get a workable definitions and clear concepts into the processes can obscure the practical imperatives a little - perhaps by creating an underlying either/or assumption.

What you describe, in my opinion is a Major Incident - and a Problem

It may be helpful to consider that a single event can be more than one 'ITIL entity' at the same time.

As a disruption to a service it is an incident. An accordingly _GrenDel_ is correct to say that leaving the incidents open is best because it reflects actual delivery.

As a failure in a system that is a constituent of the Service it is also a problem.

A large number of incidents will be caused by a fault somewhere, so a both/and understanding is helpful.

To me, you described a major incident that required escalation to vendor support. As no workaround could be found, the incident was immediately raised as a 'Problem' - something done implicitly when you went into root cause analysis - and an emergency change undertaken. But even though this was the case the disruption to the service remained, and therefore so did the incident.

Is this unecessarily 'officious'? Maybe in the case you described - but on average no.

As for the incident reports pouring in - it is customary with incidents, especially major ones, to designate one report as a parent incident, and relate all further instances as 'duplicates' - while recording the end users details against them there is no need to retake the details in each case.

Most of the better ITSM tools have assistance for efficient tagging of duplicates built in. And when the parent incident is set to 'resolved' they automatically propogate the status change to all the 'duplicate' incidents.