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: LPalladin
New Today: 7
New Yesterday: 50
Overall: 146270

People Online:
Visitors: 56
Members: 2
Total: 58 .

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

Problem Record vs. Known Error Record

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


Joined: Apr 27, 2011
Posts: 2

PostPosted: Thu Apr 28, 2011 7:45 am    Post subject: Problem Record vs. Known Error Record Reply with quote

I wanted to confirm from you all on the following

A. Problem Record and Known Error Record are distinct records each residing in distinct databases PMDB and KEDB and have different purposes.
Purpose of Problem Record is to find the underlying root cause and then find a permanent solution to implement through RFC
and
Purpose of Known Error Record is to document validated workarounds and convey status of mapped Problem Record.

versus

B. Problem Record and Known Error Record is one and the same record. Once a problem record is created and as and when valid workarounds are added to that record, it is labelled as a Known Error Record. So PMDB and KEDB are not distinct databases but KEDB is just a part of PMDB where valid workarounds are documented.

Please let me know is statement A or Statement B correct and as per ITIL v3.

Thanks and Regards
Umakant
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Thu Apr 28, 2011 5:30 pm    Post subject: Reply with quote

As far as I'm concerned, known errors and problems are concepts. It matters not a jot whether they reside in a single "database" a pair of "databases" with a mechanism to relate entries in one with the related entries in the other, or half a dozen "databases" with all the relevant links in place.

The point is this: when you have an incident you want to discover as easily as possible whether its nature is already understood, in which case there will be a workaround defined for it in many cases (but a good workaround could actually be preventative of the incident).

When you have a problem identified then you want to get a workaround defined to prevent the kind of incidents you anticipate from the problem.

Workarounds should be validated processes or actions (including the avoidance of actions) that prevent, or ameliorate, or enable rapid (and inexpensive) recovery from, incidents.

Incident resolution may, if the risks are understood and managed (possibly through Change Management), apply an action to restore service that can later be evaluated as a workaround. But at this stage you will not waste days agonizing about the "best" workaround at a time that the service is down and needing restored.

The point I'm trying to illustrate is that you should not be looking for some rule in ITIL, but thinking about what information you want, how to organize it to meet your needs, how to be able to access it, and what to do with it (not necessarily in that order).
_________________
"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
BorisBear
Senior Itiler


Joined: Mar 10, 2008
Posts: 403
Location: Sunderland

PostPosted: Thu Apr 28, 2011 10:33 pm    Post subject: Reply with quote

Diarmid wrote:
As far as I'm concerned, known errors and problems are concepts. It matters not a jot whether they reside in a single "database" a pair of "databases" with a mechanism to relate entries in one with the related entries in the other, or half a dozen "databases" with all the relevant links in place.

The point is this: when you have an incident you want to discover as easily as possible whether its nature is already understood, in which case there will be a workaround defined for it in many cases (but a good workaround could actually be preventative of the incident).

When you have a problem identified then you want to get a workaround defined to prevent the kind of incidents you anticipate from the problem.

Workarounds should be validated processes or actions (including the avoidance of actions) that prevent, or ameliorate, or enable rapid (and inexpensive) recovery from, incidents.

Incident resolution may, if the risks are understood and managed (possibly through Change Management), apply an action to restore service that can later be evaluated as a workaround. But at this stage you will not waste days agonizing about the "best" workaround at a time that the service is down and needing restored.

The point I'm trying to illustrate is that you should not be looking for some rule in ITIL, but thinking about what information you want, how to organize it to meet your needs, how to be able to access it, and what to do with it (not necessarily in that order).


I agree with all of that.

Often I see organisations that treat known errors as being a status of a problem record
Back to top
View user's profile
Marcel
Senior Itiler


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

PostPosted: Thu Apr 28, 2011 11:30 pm    Post subject: Reply with quote

And another ditto from me. In fact, you will see that vendors of ITSM software have implemented these concepts in different ways. In some tools Problems and Known Error are indeed represented by separate record, while in others "Known Error" is just a status flag on a Problem record. ITIL will not say what to do. Both solutions are valid implementations. What matters is what you want in your process in your organization.

Now here is the practical caveat. Many organizations start with Incident Mgmt and Change Mgmt and select an ITSM tool to support those processes; Problem Mgmt is often not a consideration at this point). These tools typically include a module for Problem Mgmt, whether you asked for it or not. Next thing the organization gets to the point of adopting and implementing Problem Mgmt. Most people will say that the tool should follow the process. I wholehartedly agree, but .... you already have the tool. Unless you are willing to invest significantly in customizing your tool, you are pretty much forced to use the Problem and Known Error concepts the way your tool vendor implemented them. That is something to think about.

I have the most experience with a tool that follows the "separate records" approach. Both records are >90% similar in terms of recorded information. Documenting the workaround can be done in both records. Users in our organization have a hard time seeing the value of having separate records and I can't blame them. Besides tracking different statuses there is not much that you can accomplish with the Known Error record that you cannot accomplish with the Problem record (in our tool; this may be different in other tools). In our situation the "separate records" approach just seems to add complexity and confusion without a true advantage. I'm interested in changing the process so that we just have a single record. However, the cost of the needed customization (which would affect the very core of the tool's built-in workflow) will probably be prohibitive. Moving to another tool just for Problem Mgmt may also not be a viable option. This just goes to show that what may seem like an academic discussion about concepts and the freedom to define your process whichever way you want, may meet practical constraints that drive you to do what the tool dictates.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL Certified
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.