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: FHatley
New Today: 56
New Yesterday: 66
Overall: 142275

People Online:
Visitors: 91
Members: 0
Total: 91

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 - Incident to Problem Linking
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident to Problem Linking

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
FuITILity
Newbie
Newbie


Joined: Nov 03, 2010
Posts: 4

PostPosted: Wed Nov 03, 2010 11:41 pm    Post subject: Incident to Problem Linking Reply with quote

Hi All,

Quick question regarding linking incidents to problems.

Should all incidents be able to be linked to either an existing problem, known error, or solution? And in the absence of any of these, a new problem should be opened, correct?

Thanks!
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Nov 04, 2010 1:46 am    Post subject: Reply with quote

That is the view of many including some very knowledgeable and experienced people. However the word "should", in the sense of mandatory, cannot be properly derived from ITIL as it is not prescriptive.

(I take it that by "solution" you intend a known solution not yet applied?)

I am not fully convinced of this approach. There are practical issues to do with the overloading of the problem register for example. Sometimes the cause of an incident is obvious and, while this can be erroneous, assigning that judgement to a suitably experienced person can obviate the need for further investigation with little risk.

I suspect it may be a valid approach in a larger organization where formal recording often needs to be in greater detail to keep track of what is going on and to compensate for the longer communication chains.

Certainly it makes good sense to consider whether there may be a sufficient underlying problem each time an incident occurs, and going to the length of opening a problem record and performing formal problem analysis is one way to guarantee that you do this. But the issue should be considered as a balance of risk against cost, and I don't think these are the same in all organizations.

One other point, incidents that have had a significant (by your customer's definition) impact would require greater attention (e.g. always passing to problem management), but incidents with little impact are also good candidates if there is uncertainty about the cause and its other possible consequences.
_________________
"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
Back to top
View user's profile Send e-mail
FuITILity
Newbie
Newbie


Joined: Nov 03, 2010
Posts: 4

PostPosted: Thu Nov 04, 2010 12:36 pm    Post subject: Reply with quote

Diarmid,

Thanks for the response. Here is my dilemma. Our company has taken a "good faith" approach when a problem record should be opened. That is, we rely on a multitude of support groups to use their judgment when to open a problem record. We work in a complex and very busy environment and doing the right thing is often thrown out the window in order to stop the bleeding elsewhere. Nor can it be easily enforced. We've elected to place our problem management enforcement points within the support groups, rather than centralizing it at the service desk.

Sure, there are obvious incidents that don't need problem tickets (such as a circuit outage where the carrier is going to come back with a 'no trouble found' for an answer), but it would seem to me if we switched to incident matching as a source for problem tickets we would centralize our enforcement point for problem rather than distribute it to the support groups. Either there is a known error, open problem, or solution (and for the example above of the circuit outage the solution could be as simple as calling the provider).

I would think that a company adopting the ITIL framework would see a vast number of problems in the beginning of the program, and then these would eventually become known errors, solutions, or more importantly, resolved.

My major dilemma is trying to show the cost benefit of problem management, but right now I can't even be sure we have the problem tickets opened that we should have opened due to our faith-based approach.

Thanks. For what it is worth, our IT department is 2,000+ in size. It's hard to trust the guy in the next cube much less getting 2,000+ people to do the right thing. Smile
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3298
Location: London, UK

PostPosted: Thu Nov 04, 2010 4:41 pm    Post subject: Reply with quote

then you need the following

a problem mgmt policy
a problem mgmt process
a problem mgmt procedures

then you link it to the incident and the change mgmt problem
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Nov 04, 2010 7:26 pm    Post subject: Reply with quote

...
a problem evangelist
a big stick
and a problem budget!!!!

Adhocery on that scale is very expensive.
_________________
"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
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Nov 04, 2010 7:40 pm    Post subject: Reply with quote

FuITILity,

if I may go back to your use of the word "should".

In winning hearts and minds (probably your biggest problem) on such a scale it may not be wise to resort to ITIL as "authority". Rather focus on what Problem Management is for and what its value is.

Then work on the importance of control and of consistency. Place the responsibility for decisions on raising problems in a small subset of the staff (the Problem Management team, section managers, function managers, whatever works) and make sure these staff are focused on applying the policy that John advised you to set up, and are fully trained for the role.

As I said in my first post, formality is more important in larger organizations. Keeping the rules simple will also help. It is sometimes better (cheaper and less risky) to have overkill for some situations than to risk missing important issues. A highly focussed problem management team can sort out the mundane from the vital much easier than 2000 separate minds with their varying level of understanding of the bigger picture.
_________________
"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
Back to top
View user's profile Send e-mail
FuITILity
Newbie
Newbie


Joined: Nov 03, 2010
Posts: 4

PostPosted: Fri Nov 05, 2010 2:42 am    Post subject: Reply with quote

Once again, thanks for the feedback.

So we have process, we have policies, and we have policy. And I've got a big stick and executive management's approval to use it.

We do have a small problem team. We average bout 2%-3% problem-to-incident ratio per month. That seems low.

Diarmid - Are you suggesting the problem team should take a larger role in identifying problems/trends in conjunction with the support groups?

BTW - Our incident management process is half-baked so this doesn't help either.

Thanks everyone, appreciate all the help/suggestions. I've been told to fix this so that is what I aim to do.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3298
Location: London, UK

PostPosted: Fri Nov 05, 2010 3:36 am    Post subject: Reply with quote

You need to upgrade the Incident mgmt process so that the Problem mgmt process actually does PM

There are 2 kinds of PM

Reactive - find a incident/set of // that meets the criteria for PM and then trying to solve it

Proactive - finding things like .. hey O/S that is set to expire, single points of failure, systems, o/s and applications that are buggy and full of faults

PM can also be sub diovided into Application PM / Code mgmt
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Tue Nov 16, 2010 5:00 am    Post subject: Reply with quote

Let me start with echoing some of what Diarmid said. All incidents are indicative of having a problem. So from a theoretical standpoint a new problem should be recorded for every new type of incident. The reality however is that most organizations face constraints that don't allow them to do that. You will have to make choices and it is probably wise to provide some guidance for those choices.

For example you may say that a problem must always be open for:
    - incidents that have a single major impact (say Priority 1 and 2)
    - incidents that have a limited individual impact but that have occurred at least X times or that are likely to occur at least Y times per month if no action is taken

These would be the hard criteria for initiating a problem investigation. For all incidents that don't fall in these categories you could say that a problem investigation may be opened based on a case-by-case evaluation of cost/risk/benefit. You may even be able to provide some aspects that people should consider when they are contemplating opening a problem record. I believe it would be very challenging to catch all situations with hard criteria, but the more hard criteria you have, the less discussion there will be.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL Certified
Back to top
View user's profile
FuITILity
Newbie
Newbie


Joined: Nov 03, 2010
Posts: 4

PostPosted: Fri Dec 03, 2010 2:56 am    Post subject: Reply with quote

Thanks all. That is the approach I am taking. All high priority incidents are getting problem tickets, and chronic issues are also getting problem tickets.

One of the biggest challenges I do have is getting the right data available so chronic issues can be detected. We are looking at some new reports that might help.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
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.