Help - Problem Management Question

[missmcp]

Help!
I've recently taken on a Problem Management Role which is being started from scratch.

I've completed the ITIL Problem Management Course but this is the only real experience that I have.

I am looking at trying to create a known error database, but am not sure what headings to put in it amongst other things. I also have limited (as in none) database skills.

I'm just wondering if anyone can give me a heads up on where to start when creating a Known Error database. What the difference is to a Knowledge base which is what we already have here and also if anyone knows where I can find examples online.

Thanks in advance
Miss Mcp

[davyjimjam]

Hello.

In terms of Problem Management, a knowledge base would suffice in order to get you up-and-running and is some reflection of what a Known Error Db would consist of - however, with the disadvantage of the absence of a high-level view (for the purpose of the Service Desk) to enable a first contact resolution.

But...do you have Problem Management in place (just checking!!!) as the Error Control process may also help in finding a resolution to your query.

Davy Jim Jam

[highdiver_2000]

[jacob]

I have found that most known error databases are essentially human-based knowledge management systems. They typically comprise some high level description of an incident and a probable resolution path. In some cases, the incident may be defined with some specific characteristics, such as 'file xyz.exe causes system to crash'.

Well, good luck with incident matching As you're probably aware, most incident data is comprised of vauge symptoms as reported by the user. The probability of matching these symptoms (which may be reported or interpretted in various ways by different people) with data found within the knowledge base is slim. What ends up happening is that the same incidents will continue to be triaged, escalated, and potentially sent through the problem management cycle over and over again because of a failure to match.

Does this sound familiar to anyone?

[shajij@gmail.com]

Yes Jacob I have had some similar experience.
The Problem Management Systems does need to initiate an error control process, but does face challenges of multiple interpretations of the symptoms. The best way to take this forward would be to have any tool integrated system, where the knowledgebase is updated in relation to the CMDB and in turn with the Incident Management tool. Then when the Error is encountered the next time, Incident management knows about if from the Incident management tool itself.

Regards
SJ

[rjp]

Error control (and problem management) are much more dependent on Configuration Management than Incident Management is.

Problem Managent has two basic outputs - RFCs and Known Errors.
Errors are the only ITIL 'entity' defined in terms of a CI fault.

The Known Errors DB is intended to identify the work around for an Incident based on the prior identification of a faulty CI used somewhere in the end-to-end delivery of the service that is disrupted.

Which is useful, and simple, and not particularly difficult to implement except for two pre-requisites.

1) The CI in error needs to be under change control, and the status accounting procedures of Configuration Management.

2) Your CMDB service classification schema needs to know CIs used to deliver the Service against which an incident is being reported, (and show that to your service desk staff.)

Error control is dependent on the maturity and scope of the Configuration Management process.

If the Known Errors DB is a knowledge base, then it is a single-purpose 'knowledge' base of existing errors that allows incidents casued by faulty CIs to be quickly identified, and resolved through known workarounds - nothing more.

On the other hand Technical Knowledge Base supports the investigation and diagnosis of incidents where there isn't a Known Error (an identified faulty CI) - that is, where there is an 'unknown error'.

They provide sophisticated search capabilities across a very wide range of disparate technical information. And they are expensive both to aquire and to maintain.

Of course if you deploy a knowledge base, you will want to may move information from the Known Errors DB into it. And if you don't you may want your Known Errors DB to provide a little knowledge management at least through being able to deal with classes of CIs - as described above.

But don't over scope, or over sell the functionality of a Known Errors DB.

The ITIL model is a little austere in terms of the Error control process. The assumptions are that Configuration Management is quite mature, and comprehensive: i.e., every thing that needs to be under change control is.

It also doesn't clearly account for a couple of real world variations. For example:

Often there is a known 'risk' of failure for a type of CI The symptoms and workaround the Error may also be known. But you can't put the 'Errors' in your Known Errors DB because the CIs aren't actuallly in Error.

Also interesting is a CI in Error because it has been incorrectly altered. On investigation it the CMDB will show this. The question is: Does restoring a CI to the state recorded in the CMDB constitute a 'change'. Should an RFC be required too restore a CI to its known good state? (The answer is 'probably', becasue even unauthorised changes can't always be safely rolled back.)