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: 64
Members: 1
Total: 65 .

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 - Precisely 'When' Do You Create a Probem Record & Why?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Precisely 'When' Do You Create a Probem Record & Why?

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


Joined: Nov 30, 2006
Posts: 15

PostPosted: Sat Dec 08, 2007 5:39 am    Post subject: Precisely 'When' Do You Create a Probem Record & Why? Reply with quote

We implemented an Incident Mgmt. (IM) process several years ago. We are now upgrading to a newer release of the tool. As we do so, we will also transition our formal Problem Mgmt. (PM) process out of a Notes DB into this same tool. The end result is common and integrated IM & PM Processes using the same tool and clarity among all involved in the processes about the differences (roles, goals & responsibilities) between the 2.

As we work to address and design the procedures for implementing IM & PM concurrently, we've debated at what point we would open a Problem Record. We discussed we would:

1. Need to more crisply (than we do now) define the criteria for identifying a Problem & communicate this criteria to the Service Desk folks.

2. At the time an incident is reported, if it met the criteria for a Problem:

a. A Problem Record would be created at that time. For example: A Priority 1 incident has occurred; i.e. the highest priority incident where multiple users are impacted and unable to perform their main job.

Although the incident will be assigned by the Service Desk to the appropriately skilled individuals to define and implement a workaround, a Problem Record would be created at this time Vs after the incident had been resolved.

This will enable the PM process to immedately become aware of the high impacting incident, and allow an opportunity for them to assist in the identification and the creation of a workaround.

Once service is restored, all relavent detail about the incident will be passed / updated within the Problem Record to facilitate root cause analysis.

The above ensures time and potential for resolving the incident is maximized while minimizing the transition of the details to begin the reactive Problem Mgmt. activities.

Does anyone have insight into why we would not want to manage the creation of a Problem record like this? Confused
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Sat Dec 08, 2007 7:22 am    Post subject: Reply with quote

Although having Problems open for the highest impacting Incidents is a good idea, I don't know that you should automatically open a Problem record for every Severity 1 Incident.

Let's say that the building loses power and all the users' non-ups systems go down. Yes, it met the conditions of Severity 1 Incident, but do you really want your PM Analysts doing facilities work to find the root cause of a power outage?

The idea is that the PM Analysts should be mining the Incident database for issues that are related and possibly have the same root cause. Once they have identified a set of potential Problems, they should do a preliminary cost/benefit analysis. Will the cost of investigating the Problem actually achieve a viable return on the investment of their time? If so, then they should definitely open a Problem Record. If not, maybe they should open a Problem record just as a tracker of similar Incidents. Or if the issues are so trivial and infrequent, it's not cost justifiable to open a Problem record at all.

At the point you open a Problem record, you are committing yourself to spending resources (money) to keep track, report, investigate, follow up on, etc the Problem.
Back to top
View user's profile
Cindi
Newbie
Newbie


Joined: Nov 30, 2006
Posts: 15

PostPosted: Sat Dec 08, 2007 7:52 am    Post subject: Reply with quote

Thank you for your prompt response. I get what you are saying about committing resources.

To clarify....I am not suggesting a Problem Record be opened for every Sev 1. I am suggesting that if the Problem Mgmt. team can crystalize the definition of a Problem and an Incident is recorded & it meets those requirements, then - at that time - open a Problem Record.

Does this change your response?
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Sat Dec 08, 2007 7:55 am    Post subject: Reply with quote

Hi Cindi,

Typically a problem would be initiated through an incident that has a major impact or reoccuring incidents exhibiting same or very similar symptoms.

From practice and experience, criteria for problems are not always clear cut and hence there should be a role that will make that very call: "Let's create a problem." Mind you they will one always use one same and very concrete criteria. Sometime the decision will be fact based and back up by data, already define criteria, etc. Sometime it will be more of a subjective call and based on a good dose of common sense, hunch and experience.

Your service desk or incident manager would typically be the source for originating the problem. If the role of a project manager exists in your organization, it will probably require his/her agreement and approval before proceeding with investigation. In my previous company we did not have that role defined and Incident Manager was activing as a SD manager and Problem Manager (so imagine that Smile )

Michael
Back to top
View user's profile
Cindi
Newbie
Newbie


Joined: Nov 30, 2006
Posts: 15

PostPosted: Sat Dec 08, 2007 8:27 am    Post subject: Reply with quote

Michael, thank you also for your prompt response. Really appreciate it.
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.