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.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Fri Jul 10, 2009 6:08 pm Post subject:
Is the service confirmed as restored to the child incident? Your only criterion for closing an incident is effective restoration of service. It really doesn't matter whether you think ITIL 3 or ITIL 1a or anything else; the concept applies. _________________ "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
Is the service confirmed as restored to the child incident? Your only criterion for closing an incident is effective restoration of service. It really doesn't matter whether you think ITIL 3 or ITIL 1a or anything else; the concept applies.
Hi Diarmid,
Thanks for replying. I did not understand what you mean by:
"Is the service confirmed as restored to the child incident?"
I see that the parent incident get closed and the child incident gets closed as well.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Fri Jul 10, 2009 8:42 pm Post subject:
Okay. I do not like universal statements.
When you restore the service related to the parent incident, you cannot always assume that child reports are exactly the same and therefore also restored.
The child incident is created because it is believed to be another instance of loss of service due to the same incident.
However, this could turn out to be untrue in some circumstances. In this case the user who reported the "child" incident will still be without service.
Even if it is the same incident, there can be circumstances in which the restoration of service does not work for all users, perhaps because they have different local configurations that fail to reconnect properly or because they do not properly understand how to restart using the service.
It is probably a matter of confidence. In many cases you will be pretty certain that the fix will work universally and therefore you can close all child records at the same time, globally inform the user population that service is restored and take the small risk that someone might still have a problem.
There will be times when you cannot legitimately have this confidence and you will want to confirm cases individually.
Therefore it is not wise to make the universal statement. It is far better to treat each case individually even if 99% will meet the criteria. After all it is only a judgement call should not take long to make. _________________ "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
Posted: Sun Jul 12, 2009 3:00 am Post subject: Incidents - Parent/Child relationship
achiever01,
Its also important to know how do you do the parent-child relationshiop? There are a lot of examples where the ticket of the first caller becomes parent ticket and the rest of the users become children. The parent-child relationship has to be CI based and not user based. If you consider that the all the child tickets are of the same CI as the parent ticket with the same issue, then you can jolly well go ahead and resolve the rest. However, look at a scenario where a server X crashes. The server hosts applications A, B and C. While the parent ticket will have a CI as X, the child tickets might have different CIs. Once, you are sure that the rebooting/patching/hotfixing of the server X has brought up the server and as well as the applications A,B and C, you can close the ticket.
However, the answer is the child tickets can't be closed automatically once the parent ticket is closed. The helpdesk should go back to all 'child' users to confirm about the applications A,B and C.
Lastly, ITIL doesn't say anything about it. Its descriptive and not prescriptive. Did I sound like UKVIKING or Diarmid ? I am a big fan of you guys.
Joined: Mar 10, 2008 Posts: 403 Location: Sunderland
Posted: Mon Jul 13, 2009 8:59 pm Post subject:
There is no generic answer to this and certainly nothing prescribed by ITIL. If you want to close your child incidents when you resolve the parent then go for it if it suits your organisation. If you prefer to be customer friendly and check with the orginators of the child incidents then thats also cool.
Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Sat Oct 03, 2009 6:57 am Post subject:
It may be a judgemental call, or it may not be. Your Incident Management process can specify specific conditions under which a child ticket is created, hence, depending on these conditions you may (or may not) automatically close child ticket when parent ticket is resolved.
How likely it is to have conditions for creating and resolving child tickets satisfied, that I don't know.
Personally I would avoid closing child tickets before confirming that the issue has been addressed, regardless whether parent has been resolved or not.
whenever a child ticket is opened, some basic informaiton must be obtained such as user, time if incident, basis error message.
subsequent to the parent closure, to close the loop of good service management and user / customer expectation management, the user who logged the child tickets should be contacted for confirmation of incident closure. this will increase user satisfaction, and will also identofy any incidents that may have had the same symptoms as the parent, but are actually different incidents
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