For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
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.
Posted: Tue May 25, 2010 10:42 pm Post subject: Failed incidents?
Hello All,
Do we know if we have a concept of a failed incident anywhere? Something on the lines of failed change really. I am coming from instances where my infrastructure support teams couldn't resolve the medium priority incident and wanted to know if they can associate them to problem and the rectification could lie in the next release (change). What do I do with the incident? My system allows me to leave the incident opened while associating it with Problem and Change. However, does it beat the definition of Incident which is essentially about 'fix or restore' as quickly as possible? Do I close such incidents while getting the boys to work on the Problem? It doesn't matter to me to be honest, but the stats guy got issues with long living incidents. _________________ regards,
Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill
Joined: Sep 16, 2006 Posts: 3493 Location: London, UK
Posted: Wed May 26, 2010 9:59 pm Post subject:
Almost like an exam question as noted below
Who is buried in Grant's Tomb ?
Who were the combatants in the Franco Prussian War ?
Who were the combatants in the Russian-Japanese War ?
What country was fighting in the American Civil War ?
What country was fighting in the English Civil War ? _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
I know most of the answers expect the two. I don't know the names of all the French, Prussians, Russians and the Japanese. I think easier question (whilst I sought answer) would have been what/which countries. _________________ regards,
Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill
thats what they call Normal operation _________________ Ali Makahleh
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.
“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Thu May 27, 2010 2:55 am Post subject:
Viv,
once I stopped laughing at the wits on this site I had a look at your question.
Firstly: this is a customer issue and any of the ideas below need to be agreed with the customer and not just sorted out in IT.
1. If you are responsible for the functionality that is failing
The issue is very simple. The incident is open until service has been restored, by whatever means. The reason for this is that until service is restored the user is waiting to do something that. Until the user can do that thing the customer business is affected.
If the task is so non-urgent that it can wait undone for a few weeks. Then you just agree that with the customer (not the user). But you would not close the incident. The stats are valid and if it occurs often (even for very low priority things) you have an issue worth looking at and you will only know this if you have stats. (You can always give such incidents a special category to isolate them from other useful perspectives).
If the task has a short shelf-life (i.e. it becomes not needed if not immediately done) then all the costs of the failure have already been experienced, then you no longer have any resolution requirement (i.e. you can close the incident as no longer needed), but you do have a problem requirement to get it sorted before the next requirement for the task, and you may have a series of such incidents before you resolve it, each closed and each providing pain.
If the user/customer achieves their objective by other means, then that is a workaround (even if not by means of any service you provide) and the incident is closed (but no plaudits for IT services) and you proceed as above with the problem.
2. If a separate body such as a software supplier is responsibility for the functionality that is failing
If you can enable the software to run, it is only that function that has to be avoided, for example, then I would think you can raise the bug report and close the incident. The contract with the supplier is where the penalty will lie.
I told you it was simple.
All the above is just a quick off the top of my head idea and it could be rubbish. I think the practical answer is that you talk through the question with the customer and develop a protocol that is mutually acceptable for dealing with such circumstances. I think that there are many possibilities and the nature of the business, the contract and the relationship affect how you do it. What I think you do not do, is decide within IT what to do. It is a customer issue. I'm repeating myself. So I must have got to the end. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
