Known Error Database

[realPM]

I have been formally implementing Problem Management for the past 6 month in my new organisation. After evaluating our current infrastructure and setting a PM process, I am now looking at a Known Error Database.

Has anybody used any specific methods of addressing this or specific software for this database? Do you recommend separating KB and KED?

[rjp]

Starting with the second question...

Knowledge Bases are bigger, and different things to Known Error Databases.

Whether you implement them indiependently is another question but some things to consider first...

ITIL defines a Known Error as a faulty CI. (Could be faulty due to mis-configuration, or 'cause there's smoke coming out of the back).

So there it is - gloriously simple. Known Errors get found and then you put a record in the Known Errors Database. If an RFC needs to be raised to fix the CI, you do so, and if you have a workaround you attach the details to the Know Error's record. Easy peasy.

What happens when you fix the error? Well - technically you don't have an error anymore - known or otherwise - so you close the record.

An error isn't a known error because we have learnt why a particular type of incident occurs. It's known becasue you have discovered a bung CI - you know an error exists.

Recording a Known Error is managment - ensuring that information is recorded, procedures followed, that other staff will easily discover somethings broken.

Understanding why a type of error occurs, and what the best thing might be to fix it, is called knowledge

Ta Da!!!

Ensuring that knowledge is communicated shared available throughout an organisation is what Knowledge Managment is about.

The Known Errors database, as described in ITIL is a llittle too simple, it has to take at least one step towards knowledge managment and allow known error records to store information on types. But it can do this if you allow accesss to past (closed) errors and half a decent search.

Knoweldge Managment is a whole different ball game - there are whole companies, software systems, and training and accreditation programs dedicated to it.

I think it is worth pursuing. But - before trying anything fancy with it, first deploy your Known Error DB as an error control mechanism and process managment tool only. Implement it corectly for its primary task.

Only then should you ask how you might use the information in it as 'knowledge'.

[realPM]

Thanks for the reply and information.

This is the process that I am taking to developing the KED. Unfortunately I am having this meeting later today but I will place the content here for your replies.

little bit of background:
ITIL is a new thing for the organisation. We have some 'old school' techies here that do not want ITIL as they feel that this is checking on their work. Unfortunately, this comes from some of the Team Managers and the Head of IT can't seem to control all of them. With this in mind, Head of IT and one below decided to bring us in to implement some of these methods and slowly we are getting to these managers....by constantly making request and asking for their input.

Around the KED, everbody has something in their own area and some managers think that no one else needs to know what and how you fix an error in their area because they are the experts! Problem!

KED development:
I have arranged a meeting to include at-least one person from every team, in some cases the Team Leader.

1 - Presentation content to include an explanation of the difference between a KED and KB.
2 - What we are using at the moment and why/not is it working?
3 - Diagrams and explanation of how I see the Known Errors being documented and the complexity of the information
3.a - where is it located?
3.b - who owns it?
3.c - how you get this information?
4 - How a KED should ideally look (central information location)?
4.a - who should be able to update and access?
5 - Samples of some KED and KB (that can be used in similar fashion)
6 - Request KED requirements from the meeting members
6.a - Must Have
6.b - Should Have
6.c - Could Have
6.d - Would Like
7 - Explain what will happen next with the information and requirements that they deliver.

If anybody responds and has some input into this process before hand that would be great.

This is to help anybody else in a similar situation to the one I am about to embark on on how/not to implement a central KED.

[rjp]

I guess one thing to bear in mind is that a KEB (as I have descirbed it at least) is a particularly ITIL beast.

The information it stores and the error control processes that use it, make sense in a broader process context.

In the situation you describe, the people you are dealing with will most likely look at it as a potential production resource, and judge its utility on that basis. And they will probably slide into knowledge managment anyway.

I'd say let them. Later if you start formalising problem and change management the KEB will be there, KB shaped or not. And that could be quite useful. If you ramp up into a serious application of the ITIL framework, there are going to be way bigger battles to win.

A commercial tip though - if you have, or are thinking about putting in an ITSM application, most of the enterprise scale ones have KEBs built in and additional KB modules for sale. Buying a stand alone KEB/KB mplementation could mean purchasing duplicate functionality.

Something else to think about to: (Probably a bit late for your meeting).

If you stick to a KEB, that is deployed just to track CIs (configuration items) in error, what happens if a record is out of date or incorrect?

Well not a lot that's going to hurt too much - process degradation (minor) and occassional wastage - something may get fixed twice

If you deploy KB functionaly what happens when a KBA is incorrect or out of date? Well it depends on the scope of the Article - but could be there-goes-my-job type problems. KBs have to be fed and watered - there is a bigger risk involved when they start to become authoritative for operational staff. And as they grow the feeding and watering gets to be a very big job.

So I would recommend you point out the risks of each approach, and the cost of managming those risks.

[Miri]

Hi,

i have a question about implementation tools, based in itil, in the company . If the Known Error database (KEDB) is owned by the Problem Management team then who's owned by Knowledge Base? when process (Incident, Problem, Change,..., is begining to implementation? is Problem team? why? why not service desk?
thanks for your answers.

[thechosenone69]

Miri? where did you learn your ITIL?

[Miri]

I know ITIL V2 (certification), but my company bought a tool that contains a module of knowledge. My boss says that the problem team should be responsible for the module in the tool, and I want to answer he, why the problem process that should not be the owner.

[HumanAfterAll]

[Miri]

Thank you for your answer.
I read about knowledge management in ITIL v3 Service Transition book ,
but there is no reference about process owner.
i know that ITIL is a set of concepts, but is very important understand the activities
of each process to have a good administration of them.
I think in some organizations may have this doubt implementing tools (software) with ITIL processes
and identify who is responsible for the knowledge module.
Again, thank you very much for your reply.

[Diarmid]

There is no simple answer as to who should 'own' your knowledge base.

Except to say that it has to be someone with an overall scope that covers what you will use it for. In big organizations it could well be a full time post reporting to, say, the IT Services Manager. Or it might be an IT quality Manager. Or it might be head of Applications Services or Help Desk Manager.

But, especially in a smaller organization, The IT Service Manager may delegate it to the person with the best fit for the task, irrespective of their primary role in the organization. In this case it does not become part of their primary role (such as Problem Management to take a case in point), but is a separate function with its own protocols and procedures.
_________________
"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

[Caperz]

Hi Team,

I would like to ask, for the guys that are using a well established KE tool out there today, can you please advise the recommended fields and information to have in a KE record ?

I would imagine that we would need :

- Date error was recorded
- Who recorded it
- What is the faulting CI / Service
- What the syptoms of the KE are
- What the work around is
- What the documented root cause is
- How many times has the KE been used
- Who has used the KE

Maybe also a link to the Problem Record and any RFCs that are implemented to try and resolve the Known Error.

Any assistance would be much appreciated... as I havent worked with a KEDB before. I only understand its concept out of ITIL v3
_________________
ITIL V3 Capability - Operational Support & Analysis Certified

[Bluesman]

Add a few fields:

Who has verified the Root Cause?
Who verified the Workaround?
What is the current status of the KE entry: current or archived (you will need this as your history, i e service packs will make KE:s obsolete)

Tip: only publish current KE:s that have verified workarounds, regardless if they have a RC or not. Heck, even flag it as a "Known Problem" in the RC field if it´s still under investigation.

The verified Workaround and the matching of incidents against this KE are the keys here.

This makes life easier on the Service Desk.
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr

[Caperz]

[SwissTony]

Simply put......Yes.

Known error - A problem that is successfully diagnosed and for which a work-around is known.

Doesn't matter if only the cleaner can implement the fix.

Is that an exam question?

[Caperz]

Hi SwissTony,

I understand what a Known Error is by ITIL definitions and that it belongs in a KEDB (if one is available) or at the very least the Problem Management tool. However the question was more about viewablility and useability of the KE records, by group /team. Take the following scenario :

- Users report slow application performance problem.
- The problem is diagnosed as a low available disk capacity due to a SQL transactional logging design issue.
- The work-around is to free space on the relevant disk. This can ONLY be performed by the Windows Server technician in the specialist team

Should this Known Error record be displayed in the KEDB to the Service Desk function or should it only remain viewable by the Windows Server team as they are the ones that will actually apply the work-around and this will directly benefit them.

This is one example... but there could be other examples where the knowledge of the workaround / fix could be a security breach if it falls into the wrong hands, etc.

Fellow ITIL'ers - Please comment on this and how it is handled in your organisation.
_________________
ITIL V3 Capability - Operational Support & Analysis Certified