I'm new to this forum and i think it seems that some good knowlegde around Problem Mgmt. is gathered here. So i hope you can help me with following issue.

I'm working in a company which is now working for some years quite good with Incident Mgmt, but we have a real lack in problem mgmt.
Somehow Probelms are opened and solved, but at the moment we don't include Known Errors during our problem solving work.

Our aim is now to introduce Known Errors to our IT.
We started to look into the definitions of KE and were really confused about different definitons.

Meanwhile we decided to think about a Known Error as a Problem, for which a rootcause is found!

But now we don't know how to realize this in our service managment tool (in fact it's Open View Service Desk from HP, but it is adapted to our needs a lot!) Should we somehow show that the problem is a known error by using a new Status, or should we just put a flag on the problem???

So i would like to ask you, how you implemented the Known Error in your Service Managemnt tools?
What experiences do you have with this?

You need a knowledge base (I am not sure if Open view comes with that capability). That knowledge base will contain all known problems and their fixes.

Once a call is received at Service Desk (SD), the SD engineer will look up the problem described by the customer in knowledge base. If there is a fix available, that will be applied to get the customer up and running. Now here comes the interesting part. If that problem is marked as "Fixed", the SD engineer will need to find out what is that customer is missing, and why is not the fix described in Knowledge Base article is applied to his box.

Knowledge base is not something that you can have up and running in days. You are basically transferring the knowledge of your IT staff to a database. It takes time and persistence. The way I managed was to ask every Desktop Support Person to enter at least 10 articles per week. These articles were then reviewed and verified, and then made available to everyone.

Hello joeblough
Thanks for your answer. I know that an established knowledge Database is one basic issue to run a good Incident Managment. We are currently trying to build one common Knowledge DB in our Company.

But where we are uncertain is the "Known Error"-issue.
When does a Problem become a known error (we decided to couple this to a found rootcause) and how to show this? Which features differentiate a Problem and a Known Error?

going back to the V2 definition: a known error is a problem for which:
- the root cause is identified
- a workaround is identified

which means that when a related event happens, Inciment management just needs to apply the workaround to restore the service, while Problem management may still be looking for a permanent correctio (that will be introduced via change management).

So if you don't know the cause OR if their is no workaround, then it is NOT a known error

going back to the V2 definition: a known error is a problem for which:
- the root cause is identified
- a workaround is identified

which means that when a related event happens, Inciment management just needs to apply the workaround to restore the service, while Problem management may still be looking for a permanent correctio (that will be introduced via change management).

So if you don't know the cause OR if their is no workaround, then it is NOT a known error

rgds
JP

Hi JP,
We have many Known Errors in our problem dB. Our problem dB scope is for one large Enterprise app, what I mean by that is we are logging are problems into this dB for one app. A lot of the time problem management find the root cause, which is the application itself, so we have to note in the workaround that we are waiting for the new version/patch from the vendor to remove the Error. There isnt actually a workaround but it is a known error.
Would you agree with this approach ?