Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: TMFKaceyqi
New Today: 21
New Yesterday: 73
Overall: 150067

People Online:
Visitors: 71
Members: 2
Total: 73 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - knowledge base help needed
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

knowledge base help needed

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
Vicstr
Newbie
Newbie


Joined: Apr 17, 2006
Posts: 4

PostPosted: Fri Jun 30, 2006 6:20 am    Post subject: knowledge base help needed Reply with quote

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
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sat Jul 01, 2006 2:08 pm    Post subject: Reply with quote

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]
Back to top
View user's profile Send e-mail Visit poster's website
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sat Jul 01, 2006 5:07 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun Jul 02, 2006 11:58 am    Post subject: Reply with quote

rjp wrote:
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.


I agree with this philosophy. It is my opinion, based on my experience, that KM requires the control records and their entire history to be in place. Each record is a brick that helps create the house. The lifecycle of the control records is a way of understanding history, trends, patterns, who was involved, etc. All of this combined helps to contribute to the "knowledge" aspect of the information set. A record, by itself, is a very small subset of knowledge. However, it is knowledge, nonetheless, and without any one record the entire picture may be skewed.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Vicstr
Newbie
Newbie


Joined: Apr 17, 2006
Posts: 4

PostPosted: Thu Jul 06, 2006 2:26 am    Post subject: Thank YOU ALL for replying Reply with quote

This has helped clarify how I read a KE DB really is in terms of ITIL.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.