Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: arazahn
New Today: 32
New Yesterday: 97
Overall: 141284

People Online:
Visitors: 78
Members: 0
Total: 78

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - Multiple problem tickets for one Incident?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Multiple problem tickets for one Incident?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Thu Mar 23, 2006 9:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Jphuff
Newbie
Newbie


Joined: Feb 23, 2006
Posts: 4

PostPosted: Tue Mar 28, 2006 5:31 pm    Post subject: Need info on this please! Reply with quote

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. Smile 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!

J
Back to top
View user's profile
itilimp
Senior Itiler


Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Tue Mar 28, 2006 6:00 pm    Post subject: Re: Need info on this please! Reply with quote

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.
Back to top
View user's profile Visit poster's website
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Tue Mar 28, 2006 6:38 pm    Post subject: Reply with quote

I concur with itilimp.

If it's the same customer it's a progress report.

If there a multiple customers calling then it is a matter of correctly reflecting impact - that may warrant additional incident reports.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.