Known Error Database / Knowledge Base

[asbalaji]

Hi All,

Has anyone successfully implemented KEDB / Knowledge Base in their organization as part of problem management process.?

If yes, could you pls explain the major steps involved in creating a successful KEDB / knowledge base..?

Thanks in advance

Balaji

[alanlm143]

Hi there. There are no quick answer to your question. I have been in the ITIL organisation for 2 years now and guess what, we are still using microsoft excel as our problem knowledge database.

But soon, we will be implementing our problem knowledgebase next month. I am pretty excited about it because I am the one who developed it. I used Lotus Notes for the PM DB because of the cost issue. Well, If you are not fussy, you can try to develop a web based knowledgebase by using html.

I believe the biggest challenge for the PM DB is the content itself. If you first started it, you will find that helpdesk will hardly use it because of the information available in the DB. Also, you must create a control point for 2nd/3rd level to dump in the resolution. For example, you must ensure all problem record will generate a resolution and put on the database. If you are familiar with ITIL, not all Problem has a resolution, they might be a workround. So, you might want to include the resolution in the PM DB.

I am in a decent size company supporting client from more than 150 countries and 30,000. Still, we are still using excel spreadsheet. Again, it depends of the budget that you have. Microsoft Technet is a very good example for knowledgebase.

I hope this info helps.

[taiger]

Hi,

we're fortunate to have an itil tool with an intergrated knowledge-base.
in this tool you can tranfer a solution ( or workaround ) of a known
error into the knowledge base.

Incident management can use te KB-items becouse they are sorted
in the same order as the incidents ( we have a group called detection in
wich the incident en they KB-items are sorted ) in an incident with a
certain detection you can drill through to a KB-item with the same detection.

if you're making a KB in excell it could be uselfull to use the
same "detection" fields as in the incidents so you easely can
look up the desired KB-item.

regards
Frank
_________________
"if you aim at nothing, that's what you're likely going to hit"

[rjp]

A note of caution (brief - I have posted on this in otyher threads).

A knowledge base and a KEDB are two distinct things - with different functions, costs, and requirements.

The KEDB is for the current 'live' errors found by problem management - once they have been corrected, the entry should be removed form the KEDB.

I.E.: A KEDB is an operational information source that provides a critical process control point between problem and change management. A Knowledge base is a much more persistant (and complex) information architecture.

A "known error" is simply the faulty CI discovered in the Incident/Probelm resolution processes.

I would like to suggest that what you are really discussing is simply a technical knowledge base.

[martyboy]

Hi,
I know its a while since this topic has had a reply but I thought I wuld share what I do...

I simply have a new field in the Problem form that is a checkbox called "Known Probelm" when this gets ticked it means its a know problem and the workaround is contained in the form.
Users of the database can create views the show only problems with the "known Problem" checkbox ticked.
And when the root couase has fdixed the probelm it is closed and the checkbox automatically cleared.

works well, just have to educate the users on when and why to tick the checkbox.

[Guerino1]

Marty,

This is what we do for our customers, in our product, too. They seem to be more than happy simply having this identifier on their problem records.

Regards,
_________________
[Edited by Admin to remove link]

[nr_vinod]

Hi,

A problem is given the "KE" tag after a RCA has been done. Once its done add the KE to the KEDB.
We are planning to implement the KEDB in this fashion. Please guide me if I am doing something wrong here.

Regards
Vinod
_________________
"The hardest work of all is to do nothing”

[arnoldmram]

Hi Vinod,

A lot of service management tools in the market today, also implement KEDB the way you have mentioned - by simply giving that tag of root cause identified and RFC raised. A word of caution would be that while you upload this Known error into the Excel sheet, it will be equally important to delete it from the excel sheet once the RFC has been implemented successfully.

[neopunk]

Hi Arnold,
As u said earlier..

[ranjithraghunathan]

Why would I need to delete the KE from teh excel sheet?

A KE is the known error. And when there is a known error a problem request could be raised to permanently resolve the problem if the frequency of this problem is high. Then a Change Request will be raised called as a Request for Change (RFC).
The resolution that is provided till then could be either temporary or a workaround.

If the Change Advisory Board approves the change as the change is within budget, has a significant impact on the user satisfaction, makes business sense to implement the change etc then the Change will result in the permanent fix of the problem.

When the RFC is now implemented successfully, the initial problem ceases to be a problem, and thus becomes redundant on the excel sheet and needs to be removed.

Ranjith Raghunathan
ITIL Foundation Certified

[jpgilles]

[ranjithraghunathan]

I agree that the problem will be closed and not deleted.

The initial question on this post was about maintaining a KEDB and suggestions were to have an Excel sheet with the list of known errors.

I was saying that once the problem request is closed, the known error should be deleted from the excel sheet to remove redundancy of information.

Also post the RFC implementation if the incident recurrs, then the Problem team should be pushing back the earlier resolution/workaround that existed back into the excel sheet through the owner of the KEDB (in this case the excel sheet). This is because there could have been resultant change in the configuration of the IT components which may have adverse consequences if the earlier known error is prescribed to the user.

Hope I have made my idea clear, but willing to see any inputs with respect to the same.

Ranjith Raghunathan
ITIL Foundation Certified

[BB]