Incident or Change?

[martin_d]

If a change is implemented, signed off by the customer and later they report that something is not functioning that is related to the change, should the change be re-opened or an incident be raised?

Many Thanks

[m_croon]

Martin,

ITIL will not give you a definitive answer, ask this question to 10 people and you'll most likely get 11 answers. ITIL is merely a guideline, not a set of definitive and precise rules.

Never forget the practical side of this (minor) issue:
When an incident occurs, prio 1 will be to get the service back online for the customer / user. Prio 2 is to analyse what went wrong.

If you'd reopen the change, chances are that it is a CAB change. Your organisation will probably not be as focused on the immediate monitoring of CAB changes as compared to incidents, i.e. incidents are the proper vehicle to work on prio 1 (get the service reinstated).
For prio 2, it should be enough to relate the incident to the change ("caused by", most tools can provide this), where the change can be left with the state it already has. At the end of the week / month, you simply monitor within your tool how many changes have this type of relations ("caused by") and how many incidents are related.

The point I am trying to make, is that this is much more a matter of your organisation making a decision on how you want to do this and sticking to it, than "living according to ITIL" (whow, good filmtitle: "the world according to ITIL").

Hope this helps,

Michiel

[itilimp]

I'm with Michael on this one.

I've log an incident for the end user and associate it with the RFC. That way you can monitor which RFCs are causing the most incidents, and hopefully analyse the cause for this leading to, hopefully, an improvement in the release process.

[Guerino1]

Hi Martin,

I don't know if you have your answer, yet, but I wanted to simply add that our customers & partners would normally not reopen the Change ticket. They would create a Change Related Incident and also update the post mortem information on the Change, itself, to reflect that there are one or more Incidents against it. This way, you can get at the Incident data from both directions, the change and the incident.

Regards,
_________________
[Edited by Admin to remove link]

[ChipPanFat]

I'd say log them as incidents as your ServiceDesk might have problems relating it to a specific change, maybe during problem management you can classify it as related to a change.