Problem Record vs. Known Error Record

[umakantsenapati]

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

[Diarmid]

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

[BorisBear]

[Marcel]

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