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: BMaria
New Today: 29
New Yesterday: 83
Overall: 141551

People Online:
Visitors: 60
Members: 1
Total: 61 .

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 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
arnoldmram
Itiler


Joined: Mar 08, 2005
Posts: 36

PostPosted: Fri Feb 03, 2006 12:46 pm    Post subject: Multiple problem tickets for one Incident? Reply with quote

Hi,

We are trying to implement ITIL Incident and problem management process in our organization. We are faced with a "problem" (well no, incident?)

We are using Remedy for implementing the workflow. Can one incident ticket have multiple problem tickets attached to it?

My thoughts are "NO". Ideally, the Problem management is done for the purpose of root cause analysis, so for a given incident, there would be only one problem ticket (and multiple other Incident tickets related to it).

My technical guys argue that we should allow multiple problem tickets to be opened with a single incident ticket.

Would like to hear your thoughts on this.
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Sat Feb 04, 2006 12:29 am    Post subject: Reply with quote

The short answer is it is 'better' to relate any incident to one problem.

This is because you create problems based on the incidents for whose root cause you are searching. If it turns out that a the root cause of a problem was not responsible for any of its 'child' incidents you remove the association.

But the real answer to the underlying conundrum is the 'known error' - a KE is not a 'type' or a 'class'. It is process control information and records the fact that a CI has been found in a state that causes the problem (as your defined it). The key is that one problem may lead to the discovery of any number of Known Errors. Eg. you may discover that 12 CIs are in 'error' - all in the same way, or, you may discover that 12 CI's are in 'error' - but all in different ways. In each case you raise 12 known error records - one against each CI, and RFCs to rectify those errors. When this has been done you close the KE records and set the problem to resolved. (Actually I prefer using the term 'solved' for that state.)

Known Errors however may be the children of more than one problem. So ideally you would be able to support many to many relationships between known errors and problems.

(An interesting aside here is: For Problem A you may discover and fix a CI in error. It turns out that when you do you have also rixed the root cause of another set of incidents which have been associated with a different Problem record, Probelm B. You then go on to investigate Probelm B but never find the error because it has gone. The Problem may then remain open for a long time - but the incidents don't recur. What to do.....?)

Don't know if Remedy supports this - I actually think no toolset does.

Hope that helps.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
arnoldmram
Itiler


Joined: Mar 08, 2005
Posts: 36

PostPosted: Sat Feb 04, 2006 3:44 pm    Post subject: Reply with quote

rjp
thank you for that wonderful explanation. It was clear and I think, i understand.

for the situation, that you just mentioned in the last paragraph, I am not sure too how Remedy handles this.

Nevertheless, thanks a ton for your thoughts on this post.
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Sat Feb 04, 2006 5:29 pm    Post subject: Reply with quote

It's nice to know I occassionally make sense Smile

Having had a few years experience with Remedy (including development experience) I am absolutely sure it 'can' be done. Having also dealt with BMC and one of their channels I would adivse you make doubly sure that they understand what you are trying to do and why if you go for a customisation. Specify it up the wazzoo and make sure you get a very accurate SOW and costing. Make them provide a well analysed test dataset and ensure that they quote for, do, and document at least partial regression testing on the app prior to updating your production environment.

Cheers Smile
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Thu Feb 09, 2006 2:13 pm    Post subject: Reply with quote

Hi Arnold,

Many of my clients work by the paradigm that a Problem can possibly be a "defect" or bug that needs to be fixed. Therefore, in their opinions (and I'd have to say that I lean in this direction), one Incident can definitely have more than one Problem if it allows for the discovery of more than one defect or bug as a result of root cause discovery for that one Incident. It's rare but it can possibly happen.

In a case like this, development teams will use a Problem list as a checklist of things that need to be addressed for their next Release (or next few Releases) and will plan their Changes for that Release, accordingly. Therefore, many development teams may see multiple Problems that need to be addressed to avoid having that one Incident re-occur in the future.

I hope this helps,

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
arnoldmram
Itiler


Joined: Mar 08, 2005
Posts: 36

PostPosted: Tue Feb 14, 2006 5:08 pm    Post subject: Reply with quote

Hi Frank,

Thank you for your thoughts as well.

I, however, have a question for the scenario you have mentioned. In the case where mutliple development teams are involved, the possible things to be fixed so that "that one Incident" does not recurr could be multiple. However, does it qualify for multiple problem tickets?

In my opinion, you could have one problem ticket and multiple links to the related Configuration items that may have to be fixed in this scenario.

Let me know your thoughts on this.
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Tue Feb 14, 2006 8:29 pm    Post subject: Reply with quote

Hi...(not answering for Frank of course),

It does help to remember the 'temproal' aspects of any process.

The state of a problem record (and therefore it's relationships to other records whether incidents, CIs, RFCs, whatever) is often going to be different at the beginning and end of its 'lifecycle'.

When problems are initially raised (for example by looking at incidents) there is a certain arbitrary nature to how the problem is defined, and it usually looks more like an incident (description or labelling of symptoms or effect) than an error (describing the identifies root casue of the incidents).

So it is certainly the case that more than one error may be found and require attention to prevent recurrance of an incident. Where you go from there depends on your tools, and how you set up related aspect of the process.

Some tools / sites implement known errors by changing a status on the Problem record (in a way turning a 'problem' into an 'error'). If you do this then definitely you should allow for the creation of multiple problems for any related incidents.

This will entail (most likely) setting up one to one (final) relationships between probelms and CIs.

Another option (the one I suggested at the top of the post) is to allow Probelms to be arbitrariliy defined, and pretty much keep them that way, but to create specific 'known error' states related to the problem in a 1 Probelm to many Errors relationship. (In this case the known error could be implemented as an error state on the CI with the CI record linked back to the Problem, or you could have a separate KE table.

I prefer this second approach because I think it suits the way people work and gives better management control. And especially becasue it gives error control (which is a critical child process of problem mangement) its own 'entity'.

But even using that approach the state will change as investigation progresses, incidents may be dropped or added to the relationship, as may errors. The probelm definition may change also but will be more stable if it is not simply a representation of an error. And the cardinality will be more manageable being many-to-one-to-many instead of many to many (which to my mind is always a nightmare situation).

Still a lot of people will really just have to go where their tools take them....

Frank?
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
arnoldmram
Itiler


Joined: Mar 08, 2005
Posts: 36

PostPosted: Tue Feb 14, 2006 10:39 pm    Post subject: Reply with quote

RJP,

Have to totally agree with you on this. I am aware that Remedy handles problem management in the first way you mentioned i.e. "changing a status on the Problem record (in a way turning a 'problem' into an 'error')." Remedy actually does not seem to have anything called as Known Error Database. It only uses the solutions database to pretend to be the Known error database.

Are you aware of any other Service management tools(such as HPSD or unicenter SD) which allows to handle problems in the second way you mentioned i.e actually being able to create an error out of the Problem ticket and linking mulitple errors to the Problem ticket.

Your thoughts on this would be helpful
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Tue Feb 14, 2006 11:26 pm    Post subject: Reply with quote

And the thread rolls on....Smile

I don't know for certain whether any of the tier one app do this out of the box. But I might ask and get back to you if I get an answer. I have some vendor contacts but they can be shy about saying no it doesn't do 'x'.

I can tell you that FrontRange's ITSM doesn't. Errors are simply PRoblem records with a status change.

(Mind you ITIL PM chapter explicitly says it can be a simple a 'changing that status on a problem record'. So the status change approach is technically ITIL complliant.)

In Remedy you can implement the incident - problem - error relationship with some careful customisation. It would be fairly simple to create a Known Error form with the fields you wanted. Then if you add a table field in a tab to the problem record that displayed linked records based on a dynamic seach on the parent problem ID (mandatroy field 1). To activate the link you would need a) an active link sequence to create a new known error record, open it in a new record, push the problem ID onto it, and on-close action to refresh the table field. These would be attached to a create/add button on the tab. Enabling drill down on the table would allow you to open and look at the records. All up this should take an experienced consultant about a day if it is specified correctly. (Oh and a couple of housekeeping filters maintaining the relationship if Probelm records with linked errors are updated or deleted by workflow.)

The shortcoming here is that it will be considerably more difficult to link the errors to CIs - and very tricky to override or replace the OOTB relationship between CIs (or Assets) and the Probelm Record. So it is a partial implementation. Really if you create an Error object it is the error not the probelm that should then be related to CIs. Relating the Error rather than the Probelm to the RFC would also be tricky. But you might be able to work backwards and basically do the same link on RFC records, but use filters to search for Errors linked to the Probelm and add the same relationships to the RFC. Basically you would have to find all workflow (Links and Filters) that are used to a) create an RFC from a Problem b) Link Problems and RFC. YOu would then add workflow using the same execution conditions that found all the error linked to the problem and made the same links to the RFC.

But...if it is just a matter of displaying the data you can - do the Problem error linking workflow and have a table field on RFCs that on open uses the problem ID to return the same subset of records to the table that the search on the problem record uses. This will disply all linked errors but not require a relationship.

This method will only add workflow and data, not change or remove any out of the box objects - an important thing in Remedy.

That's pretty rough, but it should give you a thumbnail sketch of what is involved.

Taking it one step further - a poorly applied principle is that errors are specific process instances. When the RFC is carried out and the error repaired the known error should 'go away'. The Known Errors Database is supposed to show current, actual errors, not be a knowledge base of error classes. So closing out, or deleting the known errors once fixed is also going to be required.

I really wish ITIL didn't refer to known errors and workarounds as if they were the same thing, and belong in the same data repository Sad

(That is not to say that past known error records cannot be 'mined' as input into a Knowledgebase.)
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Feb 15, 2006 6:47 am    Post subject: Reply with quote

Hi Arnold,

Just to answer your original question to me about my own specific example, where multiple development teams are involved. The scenario is that a Change or (Request for Change) is the logical entity that can be mapped back to one or more Problems.

Therefore, you can have one or more Incident(s) that cause and/or drive one or more Problem(s) that cause and/or drive one or more Change(s) that are part of one or more Release(s). So in this example, development teams can be spread across one or more Changes and/or one or more Releases.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Feb 15, 2006 7:17 am    Post subject: Reply with quote

rjp wrote:

The state of a problem record (and therefore it's relationships to other records whether incidents, CIs, RFCs, whatever) is often going to be different at the beginning and end of its 'lifecycle'.


One thing we try to never do is allow Problems to tie directly to CIs. We have Problems drive Changes and Changes act as abstractions to one or more CIs. CIs can also be part of one or more Releases.

rjp wrote:

I prefer this second approach because I think it suits the way people work and gives better management control. And especially becasue it gives error control (which is a critical child process of problem mangement) its own 'entity'.


I agree that either way works. I personally prefer the former description provided by RJP, not this latter. But, honestly, what's important is tracking the details.

rjp wrote:

Still a lot of people will really just have to go where their tools take them....


This is very true. The tools you use, unfortunately, may dictate your process.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Feb 15, 2006 7:45 am    Post subject: Reply with quote

I'll take a shot at describing what we do for our customers. I'm hoping that the powers that be don't eliminate my post as I'm not trying advertise our tool but rather describe the processes that are typically implemented around its use. I'll take a chance anyway...

We allow you to create and manage Incidents independently of any other entity. This is because you may close Incidents without ever generating a Problem. We also allow you to create and manage Problems independently of any other entities. This is because you may find and record a Problem before any related Incident might occur. If you specify a primary Incident, when you create a Problem, an automatic relationship gets created between that Incident and the Problem, where you can track the Incident as a driver of the Problem. If other Incidents occur, later, you can bind each of them, independently, or in bulk to the Problem so you can later have full traceability between Incidents and Problems. It works the same with RFCs. We use Problems, Risks, and Requirements to drive RFCs, allowing full traceability between the drivers of change and Changes, themselves.

When a Problem needs to be classified as a "known error" or "defect", we allow you to select a field on the Problem to mark it as such. When a developer or engineer knows the Root Cause and what needs to be done to fix the Problem, they put that information into the Problem entry as a record for the resources that will later implement Changes to fix it. Evenutally, that Problem will be scheduled to be fixed in a Release, where the system will relate the Problem as a driver to the Release. Eventually work on the Release starts and logical Change entities are created, within the Release. One or more Changes may be needed to fix a single Problem. Therefore, a Problem can be related to one or more Changes. In order to implement the Changes, CIs are modified and, therefore, the CIs themselves become related to the Change that drives them. After the Changes are implemented to fix the Problem, the original Problem's state should be marked "Closed".

The fact that a Problem in the system is marked to be a Known Error, with a scheduled Release, with a Closed state, and with Changes that it it is bound to as a driver allows the Problem to act as a knowledge record. This is because a user can bring up the problem and very simply see all related entities that drive the Problem and/or that the Problem drives.

While we know there are many ways to implement this, the above seems to work and be very adequate for most companies we speak with.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
arnoldmram
Itiler


Joined: Mar 08, 2005
Posts: 36

PostPosted: Tue Feb 21, 2006 9:34 pm    Post subject: Reply with quote

Frank and rjp,

Thank you both for your valuable thoughts on this. It is indeed very enlightening on problem management as a topic.
Back to top
View user's profile
Nikhil
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 17
Location: India

PostPosted: Wed Mar 22, 2006 5:55 pm    Post subject: Relating multiple Incidents to a single incident Reply with quote

Guys,

This was an interesting discussion about multiple incidents to be related to single problem.
Would like to note another way of doing it --
We can related multiple incidents to a single incident, which in turn related to a problem.. provided the incidents are based on the same problem.
Also about the error records to be created, can we not use the incident form itself to create and manage known errors error.
All we might need to do is provide a new incident type = Known Error, and modify the workflow to create RFC's and relate CI's only if incident type = Known Error.

Do provide your thoughts on this.
_________________
Regards,
Nikhil Kulkarni.
Application Analyst
cMango.. The Services Management Company

The taste of low quality lingers long after the satisfaction of low price.
Back to top
View user's profile MSN Messenger
Nikhil
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 17
Location: India

PostPosted: Thu Mar 23, 2006 5:22 pm    Post subject: Reply with quote

Guys,

It was such an interesting discussion that I messed up with the original requirement.
The original requirement was multiple problems for a single incidents.
My suggestion would be, to create a single problem(p1) for an incident(i1).
Then create the other related problems(p2,p3,p4) for problem p1.
But with this, you will need to specifically go and close all the related problems.

But certainly having multiple Known Errors to a problem case sounds interesting.
Will have a round of discussions with some guys here and let you know their thoughts.
_________________
Regards,
Nikhil Kulkarni.
Application Analyst
cMango.. The Services Management Company

The taste of low quality lingers long after the satisfaction of low price.
Back to top
View user's profile MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 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.