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: CMerriam
New Today: 48
New Yesterday: 79
Overall: 144683

People Online:
Visitors: 57
Members: 2
Total: 59 .

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

Problem Management

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


Joined: Sep 22, 2004
Posts: 1

PostPosted: Thu Sep 23, 2004 2:33 am    Post subject: Problem Management Reply with quote

Hello--While looking for information on implementing Problem Management, I stumbled across this site and immediately joined. This is a fantastic idea!

Currently I am the Change Management Coordinator for a small IT Company and have been tasked with implementing a more organized PM process. Our team meets weekly to discuss Service Level Exception Reports and we also trend level 1/2 incidents. We currently use Peregrine for Service Desk, Incident and Change, we do not have the Problem Management module yet and all of our activities are manual. My biggest challenge is there is a disconnect between our review of incidents and getting management support for resources to investigate problems.

Have any of you been in similar situations? What do you feel would be the best avenue to pursue? Any words of advice would be appreciated.

Thank you for your help!
Paul
Back to top
View user's profile
Guest






PostPosted: Tue Sep 28, 2004 7:36 pm    Post subject: Reply with quote

The only thing you can do is build up a known error database that highlights the impact of failures that need work on to sort out.
It would be up to the change board who should consider acting on these reccommendations. Assuming you have a change board with someone on it with clout.
MAKING A STRONG BUSINESS CASE FOR MAKING THESE CHANGES IS IMPORTAINT. if there is a strong case and its cost is justified I dont see how it could be rejected. Chasing changes to problems that can be lived with is something else. Stick a strong workround in place and keep recording the incidents. When resources allow put in a perm fix.
Hope this helps - please tell me if you dont understand or think this is rubbish?
Back to top
eisbergsk
Senior Itiler


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

PostPosted: Wed Nov 03, 2004 4:19 am    Post subject: starting Problem Management Reply with quote

Here's a rundown of some of the initial steps taken here.

When I started, we had an Incident tool, a Change process, and a basic CMDB. Our management knew they needed to implement Problem Mgmt, so they posted a job vacancy. No one applied, so they asked me to take it on.
Key #1- have someone dedicated to problem management

What incidents to investigate? "pick the top 5", they said. well, in order to pick the top 5, I had to read them all, and over what period of time? I picked 'monthly', because that's about how often mgmt wanted reports.
Key #2-pick a sample set and a time frame. (hint: pick something consistent, repeatable, and defensible)

Who on earth do I talk to to find out what the problem behind an incident might be? the same people that handled the incident! the Subject Matter Experts. They are a valuable resource. They are very busy. Their managers might not like that you take up their time.
Key #3 - schedule visits with the managers of the Subject Matter Experts, (and the Subject Matter Experts, too if you can) give them a brief overview of what you are trying to achieve, what you need from them, and ask for their permission.

At this point, you should be good to go to start asking questions.

I found that it helped to state my objective: "To identify changes that could be made to our infrastructure that would Prevent, Eliminate or Mitigate incident reoccurrence". Our infrastructure consists of Applications, Servers, computer Network elements, Procedures, and Hardware. Changes can be General (e.g. "have all staff take Word training") or Specific (e.g. "upgrade XYZ server from ver 1.a to 5.b"). I found it easier to get committment is I asked for which Quarter it would be done (4Q2004, 1Q2005, etc).
Key #4- Specific changes scheduled within 1Q of the incident have the highest possibility of being done AND being effective.

Be nice, diplomatic. Ask for help to understand. listen carefully. Write up which incidents turned into which problems, and what will be done to resolve them. send out your reports.

and then you get to do it again!

okay - this is a bit simplistic, but it seems to have worked here so far. Does it help?
Back to top
View user's profile Send e-mail
ITILsupport
Newbie
Newbie


Joined: May 11, 2004
Posts: 6

PostPosted: Sun Nov 07, 2004 7:24 am    Post subject: Reply with quote

You need to look at how to best adapt that part of ITIL framework in your organization. For example have dedicated resources handling incident management and other resources handling problem management. Problem management resources can work on creating problem records, doing root cause analysis and creating known errors if needed. They can be reactive and do what I described and also proactive - they can look at already existing incident data and check for patterns. Time is not as much of a factor in problem management as it is in incident management where restoration of service in quickest possible time is critical. That's why it is always good to have separate resources handling incident and problem managament.

Now your root cause analysts/problem managers based on indentified known errors can create requests for change (RFC). RFC is your basis for change management. Your change managers can then assess if it's a valid change, approve it or not, etc.

Your solved problems, workarounds, permanent alternatives (part of your known error information) should be available in your knowledge base (everything is part of CMDB so it shouldnt be a problem to enable your incident/change people to be able to look at that information).

Having incident data tied to problem data which in turn is tied to known error data and then change management request should be more than enough of a reason for your management to seriously look at the RFC. Based on provided information they can create a change request (or just like I stated above your known error people can create one) and set a proper priority/impact/urgency. This in turn would help for assessment on what type of resources are needed and should be devoted to eliminating known errors.
Back to top
View user's profile
leebc
Newbie
Newbie


Joined: Sep 14, 2004
Posts: 14
Location: Australia

PostPosted: Tue Nov 30, 2004 1:04 am    Post subject: Reply with quote

Would one use the same categories for Problem Management as for Incident Management?
Back to top
View user's profile
eisbergsk
Senior Itiler


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

PostPosted: Thu Dec 23, 2004 3:49 am    Post subject: PM categories Reply with quote

leebc wrote:
Would one use the same categories for Problem Management as for Incident Management?


In our organization, yes, and these actually match the high-level categories of the CMDB.
We keep it fairly simple. Our current 5 categories are: Application, Network, Server, Environment (includes printers, peripherals and other misc stuff that we look after) and Documents/Procedures.

What is interesting is that an incident is almost NEVER in the document/procedure category, and that 30% of problems may require a change to a procedure to resolve a known error.
I think some consistency in naming helps.
Back to top
View user's profile Send e-mail
Guest






PostPosted: Fri May 20, 2005 6:18 am    Post subject: Reply with quote

Anonymous wrote:
The only thing you can do is build up a known error database that highlights the impact of failures that need work on to sort out.
It would be up to the change board who should consider acting on these reccommendations. Assuming you have a change board with someone on it with clout.
MAKING A STRONG BUSINESS CASE FOR MAKING THESE CHANGES IS IMPORTAINT. if there is a strong case and its cost is justified I dont see how it could be rejected. Chasing changes to problems that can be lived with is something else. Stick a strong workround in place and keep recording the incidents. When resources allow put in a perm fix.
Hope this helps - please tell me if you dont understand or think this is rubbish?


Agree although it depends who is responsible for the Problem Management process. A Known Error database could show for example number of repeat incidents for a system/service by month. Dont forget that it is a acceptable to have a Known Error (problem with known workaround) if it is not possible resolve it for a justified reason, ie. too costly, against ethics, etc.

If you have a Problem Management team to manage the Problem Management process, they would perform the analysis and raise changes as required. Approval should always go through Change as I am sure you aware. Currently setting up whole ITIL process methology and mapping it to Etom/tom as our IS people only understand etom/tom and customer wanst ITIL...in 2 months in a Telecom environment = nightmare of acronyms, terminology (fault=incident=problem....yikes! first task was to clear up confusion of terms)....eek! luckily i have over 10 years exp, but like everyone....always learning!
Back to top
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.