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.
The Itil Community Forum: Forums
ITIL :: View topic - Multiple problem tickets for one Incident?
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Thu Mar 23, 2006 9:41 pm Post subject:
Yes, assigning child parent relationships within incidents is a valid approach, and is a fairly common practice.
The purpose of the relationship between incidents is slightly different to the relationship between incidents and problems. The former is a process efficiency measure and simplifies and reduces the admin overhead, and helps prevent unecessary duplication of effort. It is based (as you indicated) on fairly straightforward attribute matching, and known information. The later is as much a creative application of experience and anaylsis as it is the application of 'rules'. Incidents will only be linked to problems when the assumption is made that they share a common root cause. But bear in mind, the assumption is that the root cause is not know, otherwise problem management isn't really required. So the situation of the 'known' error is actually the exception to the process, not the norm. And general process architecture should not be determined by the exceptions.
It is, however, only necessary to apply a relationship between a parent incident and the problem record, where strong (and accurate) incident duplicate identification is in place - and where you have systems to handle it.
On the issue of classifying an incident as a 'known error' I would not recommend it. (Unless you mean record it in a resolution code somewhere on the record - which is a good idea.) Incident classifications should show where your services are being disrupted. Because classifiaction answers the question 'what' first and foremost. And 'what' an incident is, is a disruption to a service. So Incident classification should show what the disruption was. Classifying an incident as a known error labels a process outcome, not an attribute of the incident. It will mess up your reporting and metrics.
Posted: Tue Mar 28, 2006 5:31 pm Post subject: Need info on this please!
Interestingly, we're facing a similar type of quandry at my work. What about the instance in which one reported incident gets multiple queries? For example; A customer calls for a software installation with an SLA of 5 days, and calls several times over the next two days to check status (when will I get the software?) until it is installed on the third day, ahead of SLA.
Now, do those status calls get logged on the original ticket or do they each generate another ticket? There is no way in the system being used to link the tickets together, by the way. A consultant is saying that ITIL would dictate that this generate multiple tickets which would all be closed on resolution? I would like to see if there is any documentation or "best practice" information on this? Doesn't seem to make sense and more like you are inflating volume (assuming you CANNOT link the tickets) but then again, even if you COULD link them, they are for the same issue, same root cause, same customer so why would you? Need some guidance here please!
One other issue while I'm here. Call systems for most businesses use selections to route calls and tell the call center what you are calling for. This can provide some useful correlation to the call center (for example, 300 outage report calls this week to correlate to 10 actual outages, or 40 password reset issues routed priority to agents which correspond to only 9 password reset 'tickets'). It allows getting the customer perspective on the issue they're calling for, routing certain calls to certain agents, and also gives SOME correlation of calls/types to tickets opened/types.
Is anyone aware of any documentation regarding this? I'm aware this is a 'best practice' type of setup and it's used by almost every business/call center out there, but how about documentation as to WHY or HOW this should be setup? I can't find anything other than vague mentions of call type routing being 'best practice' and not in a completely direct manner. Any golden documents out there?
BTW, this is a GREAT forum and the activity and input here is always thought provoking! Thanks!
Posted: Tue Mar 28, 2006 6:00 pm Post subject: Re: Need info on this please!
Jphuff wrote:
For example; A customer calls for a software installation with an SLA of 5 days, and calls several times over the next two days to check status (when will I get the software?) until it is installed on the third day, ahead of SLA.
Now, do those status calls get logged on the original ticket or do they each generate another ticket?
J
In the example you used, if the user is calling to literally check the status of the installation, then I would advise our staff NOT to log this as a new call (furthermore it's routine practice to check for existing incidents/requests as duplicates are my pet hate!). In our case we would update the call with a note that the user has asked for a progress report and send a notification to the assigned analyst/group. There's monitoring up until the time the call breaches, then at which point we invoke an escalation procedure.
All times are GMT + 10 Hours Goto page Previous1, 2
Page 2 of 2
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