knowledge base help needed

[Vicstr]

I am having a difficult time on knowledge database. In ITIL is it part or same as the known error database?

Thanks for any information you can provide.

Vicky

[Guerino1]

Hello Vicky,

ITIL refers to Knowledge Bases (KBs) very loosely. Every time it refers to a repository of data, it loosely refers to it as a KB. They're not wrong in doing so. To the Incident Management team, the inventory of Incidents and their histories are a relevant KB. To Problem Managers, the inventory of Problems and their related histories are a relevant KB. To many people the inventory of Known Errors is a KB. And so on...

So, yes, the Known Error DB is a KB but it is not the only KB. Every repository of data/information is a KB to the people that care about it.

The problem is that there are cross functional needs for the the same knowledge, many times in different forms. For example, development teams need to have access to all of the Incidents and Problems being tracked against their Products. Problem Managers need to have access to work being done by developers and, therefore, need access to development KBs. It's a never ending mess.

My background is in Knowledge Management. In my experience, a KB is a repository that holds whatever information is important to that particular stakeholder, at that particular point in time.

A Knowledge Management System (KMS) is a master system that simply and cleanly combines and correlates the information across multiple KBs, for quick and easy reuse.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[rjp]

Vicky,

as Frank points out the term 'knowledge' doesn't simply define a particular type of data, information, retrieval architecture.

The meaning of 'Knowledge' really rests on the manner in which information is applied by people. That is it is about 'use'.

That, however, can still help clarify your question:

What people generally intend by the term 'Knowledge' in the context of comupter supported knowledge management, or 'knowledge centred support systems' is not the same thing that ITIL intends by the Known Erros Database.

Known Error records as intended by ITIL are operational records that represent a particular state of affairs at a particular time: Where there are errors currently in the infrastructure for which the cause has been found.

So as far as it lets us know that, it is a KB - but of course that is not what most people are getting at when the talk about KBs. What most people really mean by 'Knowledge Management' is being able to extarct information from one specific case that is applicable in another - formalised capture of an organisation's 'learning'. The Known Errors database is not intended to fulfill this second 'knowledge' function - in fact it's primary function could easily be inhibited by attempting the second.

Additionally, the class of events which removes a Known Error record from your system are completely different to the cloass of events which would remove a record whose primary purpose was to capture, represent and make knowledge available. Which means there are different data-management steps required that can cause problems for a single repository.

More specifically, a Known error, being a state record, goes away when the error has been remedied - because the state it records has changed.

The Knowledge record goes away when it is obsolete - eg, the technology it refers to is retired - in state terms it should stay current as long as the 'states' it addresses are possible.

Now you could say, but the both are retired when they have no further use - but the use is different.

The inverse is also true: Known errors are created only when the cause of a recorded problem is identified.

Knowledge that may pertain to any future occurance of a particular state should be created as soon as it is discovered.

It doesn't change when you add the phrase 'and workarounds' as in Known Errors and Workarounds Databse. Workarounds are specific responses to known errors and likewise go away when the error does.

It is however important to realise the these Error records definitely have a 'knowledge' function - while the records are 'live'.

There is also value in being able to recognise classes of errors, workarounds, etc. that may occur again. Ideally you don't want to loose this. And it is the 'mining' of operational records for representation and storage as persistant and searchable repositories of generally applicable inforation gathered in operations that is meant by 'knowledge management'.

It is a good thing to capture and utilise knowledge across all your processes. And at a minimun you should do as much as your technologies, and resources allow. In a simple case for example by filtering, keywording, archiving and indexing your operational data.

The main thing to be careful about is what you might call a heirarchy of objectives. The first objective for you KEDB is control of the current error state. Derriving further value by extracting the generally applicable knowledge from the specific data is the second objective.

You don't put your first efforts into your second objectives. Get the KEDB working as a process control information repository first. When that's solid you should look for value adds in knowledge capture.

There is a movement(?) in serivce management called Knowledge Centred Support which does to some extent reverse these priorities by making the case that control records are just a subset of knowledge records.

I am not arguing here for or against that philosoophy. It's an option - and really a very interesting trend.

Getting too far into the whole Knowledge Management area however, does tend to obscure the primary function of the ITIL KEDB.

[Guerino1]

[Vicstr]

This has helped clarify how I read a KE DB really is in terms of ITIL.