Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Fri Aug 18, 2006 11:14 pm Post subject: Incident or Change?
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?
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Fri Aug 18, 2006 11:24 pm Post subject:
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").
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.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Aug 29, 2006 4:30 am Post subject:
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]
Posted: Fri Sep 01, 2006 8:32 pm Post subject: incident
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.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum