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: B68N
New Today: 25
New Yesterday: 55
Overall: 148147

People Online:
Visitors: 49
Members: 3
Total: 52 .

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

Problem Record Criteria

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


Joined: Sep 26, 2005
Posts: 44
Location: Sweden

PostPosted: Thu Nov 09, 2006 11:08 pm    Post subject: Problem Record Criteria Reply with quote

Hi all,

I'm trying to figure out how to get started with Problem Management, and I figured that the Problem Record criteria would be a good place to start. I thought it would perhaps be the way to start thinking about when we need a PR. Then we would know how many PR's we might expect and if we have the resources to cope.

Does anyone have any thoughts on this?

cheers, Matt
Back to top
View user's profile
JoePearson
Senior Itiler


Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Fri Nov 10, 2006 1:06 am    Post subject: Reply with quote

Hi Matt
If I read you right you are thinking of defining the criteria for creating a Problem Record. That's a good step, but you'll have to steer it to answer how many resources you need.

Why does ITIL recommend distinguishing incidents and problems in the first place? So that you (management) can make a decision to split resources between getting incidents (user service) resolved as quickly as possible and getting problems (root causes) resolved as well as possible.

You could look at your incident logs and identify
1 - incidents that were fixed with workarounds. These are obvious candidates for raising as problems. There may be similar but less obvious cases where the incident was fixed, but there was some concern about quality - basically any case where the incident staff know or suspect that a root cause has not been addressed.
2 - repeat incidents. They may be a better resolution to some incidents than frequent password resets or frequent server reboots. An issue you may face here is that identifying repeat incidents is itself a Problem Management activity that you might require some planning to justify
3 - trends of incidents. Similar comments apply.

You can also look at proactive problem management, like analysing stats and logs for quality issues that could be raised as problems even when there has been no Incident yet. But the above could be enough to start with.

Take care with how you go forward - don't raise all of these as problem records if that will create the expectation that they will be worked on (ie enter problem control, the process of finding the root cause). Maybe you don't have enough skilled staff to do that. And that's your final criterion: a Problem is something the organisation decides to invest resources in fixing to a better quality and depth (root cause) than incident resolution.

Joe
Back to top
View user's profile Visit poster's website
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Fri Nov 10, 2006 8:38 am    Post subject: Reply with quote

Hi there...
I've mentioned this in other posts, but I love the sound of my own typing Wink

Based on the incident volumes recorded in your Incident mgmt DB/Service Desk tool, bite off a chunk you can chew.
Here, that translates to 'Severity 1' (high severity) incidents, which works for a number of reasons (high enough profile that you can stress the company's business and deflate 'why are you picking on me?' and other silo-like attitudes.) Based on the past 6 years of doing this I can say that it pays off, too. And yes, I'm it for PM.

If I ever get this chunk chewed and swallowed, I'd like to address incidents that cannot be solved at first point of contact. These are more expensive to the company than incidents handled at 1st point. These can be divided by region, group - whatever it takes to reduce it to reasonable size. I also have an established process that can be followed if the role is ever expanded to other people doing this. but hey, I'm an optimist. Smile
Best regards,
/Sharon
Back to top
View user's profile Send e-mail
tolman101
Itiler


Joined: Sep 26, 2005
Posts: 44
Location: Sweden

PostPosted: Fri Nov 17, 2006 5:56 am    Post subject: Reply with quote

Thanks for the tips guys. I have searched through the PM section a little closer and picked up quite a few tips to get going. I thought I would start with the following criteria and then expand on it as we move forward...

High impact/urgency Incident is recorded
Monitoring events that might lead to a future Incident
Workaround or temporary fix is not available
Repeat Incidents
Unsustainable workaround

Also something that sounded very interesting was a post from Frank Guerino suggesting a cooperation between the PM and the Product/Service Owners to add some strength to the process.
Back to top
View user's profile
Marcel
Senior Itiler


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

PostPosted: Mon Nov 20, 2006 3:03 am    Post subject: Reply with quote

Matt,

Before you start working on your criteria to raise a problem ticket, you should decide how incident and problem management link together. As you can surely find in other posts on this forum, there are different approaches. The main scenarios (with combinations in between) are:

A) An incident is resolved by incident management, all the way till service restoration, even if this means that incident management has to develop a solution or work-around, or even has to find the root cause. Problem management is an "after-the-fact" thing that starts once the service is up and running again and that is mainly focused on preventing the incident from happening again.

B) Problem management can kick in at various points during the incident management process, e.g. when it is a major incident (requiring the best-skilled staff to work on it), or when no work-around or solution is available. The incident ticket remains open till problem management comes back with the work-around/solution (i.e. the problem control part of problem management has been completed; there is a known error with a work-around/solution), which is then implemented, after which the incident ticket can be closed. Problem management then continues with error control to eventually eliminate the root cause.

Based on these scenarios, you will probably see that different criteria apply. In scenario A, you will only raise a ticket after a single incident with a major business impact (high severity), after repeated incidents that have a significant accumulated business impact, or when proactive measures are required to prevent incidents from happening (e.g. based on trends found by event management). The criteria you listed with regards to the availability of work-arounds or temporary fixes, would only be relevant if you implement incident and problem management in accordance with scenario B.

Bottom line: determine your scenario and then define the relevant criteria.

Marcel
Back to top
View user's profile
tolman101
Itiler


Joined: Sep 26, 2005
Posts: 44
Location: Sweden

PostPosted: Tue Nov 21, 2006 2:46 am    Post subject: Reply with quote

Hi Marcel,

Thanks for your input. I would be say that senario B is the way that IM and PM would link together in our organisation. The two processes would run in parallel. I believe that this is the ITIL way too.

Best regards, Matt
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.