Question about KEDB

[Oyeeeee]

Hello everyone,

I have read in the forums that we can implement PM with or without the Known error database. i.e. We can just change the status of the problem to a Known Error and leave it as is in the Problem DB(without actually creating a separate Know error record and saving the details in the KEDB) and then moving it to a KB, once resolved.

I was wondering, if we can do with or without an actual KEDB, what are the additional benefits or advantages of having a saperate KEDB? or what additional value does it provide?



Thanks.

[UKVIKING]

It depends

What benefit do you think you would have running a service desk when a customer calls and you have a Known Error Database ?
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[JoePearson]

I don't think this is your whole question, but I'm reading it as this:
You could store all information on a known error in your problem database, rather than creating a different database.

The advantages of storing information on known errors - including matching and workarounds - are huge; if your problem db is restrictive, you might not be able to store the right info or make it available to the Service Desk, and you would lose out; but let's assume you didn't invest in a restrictive system.

The advantages of storing known errors in a different db from problems - I can't think of any. I always regards known errors as a lifecycle state of problems; you can't have a known error that is not related to exactly one problem. If your process doesn't agree with those claims then you would not agree with my conclusion. It's a data design issue.

But if you just flag the problem as a KE, you are not doing problem management properly. You need the service desk to be able to find and match it, and you need to provide a workaround.

[Diarmid]

Hello Oyeeeee

I presume you are gagan at the itsmfi forum. Joe has covered it, but I will just paste in my response from there to let other people here see what you are seeing, and to dispute or qualify my points as they see fit.

Separate Databases do not provide additional benefits. an integrated database is a means to easily access linked information and to control the quality of the information.

The real question is not can you do things with or without particular databases; it is what information do you need to gather and use to provide the service. In the case of Known Errors, you will want know the workaround, the progress of the resolution, who is working on it etc.

Working on a small scale all this can be held in any simple computer system, but on a large scale a database becomes a practical necessity and the more complex, the more important that it should be an integrated database.

If you start with a bare bones system, you can plan to build in additional elements over time and, if you wish, you can be driven by perception of next best improvement to make based on the amount of pain you are experiencing in given areas.
_________________
"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

[MVPS]

All these databases (KEDB, PDB, KB, CMDB, etc...) are separated more for a didactical approach.

You can have them all together (or not), that depends on your case. But you should have them all !

Regards