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: JSager
New Today: 59
New Yesterday: 49
Overall: 146088

People Online:
Visitors: 68
Members: 5
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 - Known Error Database
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Known Error Database
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
realPM
Guest





PostPosted: Thu Oct 20, 2005 12:40 am    Post subject: Known Error Database Reply with quote

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?
Back to top
rjp
Senior Itiler


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

PostPosted: Thu Oct 20, 2005 12:39 pm    Post subject: Reply with quote

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!!! Smile

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





PostPosted: Thu Oct 20, 2005 6:45 pm    Post subject: Reply with quote

Shocked 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.
Back to top
rjp
Senior Itiler


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

PostPosted: Sat Oct 22, 2005 4:04 pm    Post subject: Reply with quote

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 Smile

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


Joined: Sep 18, 2009
Posts: 3

PostPosted: Tue Sep 22, 2009 12:09 am    Post subject: Reply with quote

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


Joined: Jun 06, 2007
Posts: 268

PostPosted: Tue Sep 22, 2009 12:16 am    Post subject: Reply with quote

Miri? where did you learn your ITIL?
Back to top
View user's profile
Miri
Newbie
Newbie


Joined: Sep 18, 2009
Posts: 3

PostPosted: Tue Sep 22, 2009 12:49 am    Post subject: Reply with quote

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.
Back to top
View user's profile
HumanAfterAll
Newbie
Newbie


Joined: Sep 22, 2009
Posts: 5

PostPosted: Wed Sep 23, 2009 6:24 am    Post subject: Reply with quote

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


The Known Error Database is owned by Problem Management.
The Knowledge Base, that holds customer documentation, processes and procedural fixes is managed under Incident Management, usually through Subject Matter Experts on the Service Desk.

The Service Desk should sign off new contracts through an onboarding process when sufficient information has been submitted to support the given contract. The information is then translated by members of the service desk to their preferred format and technique for indexing.

The Knowledge Base information should be supplied to the Service Desk through Service Delivery Management/Account Managers/Consultants/Support Teams etc.

The Knowledge Module in the tool that my company has is used for Known Error Records, because they need to be linked to incidents and Problems as part of the Problem Management process.

The knowledge base should be a separate repository for documents and articles.

I think you need to explain the above to your boss.

Good luck.


Last edited by HumanAfterAll on Thu Sep 24, 2009 8:01 pm; edited 1 time in total
Back to top
View user's profile
Miri
Newbie
Newbie


Joined: Sep 18, 2009
Posts: 3

PostPosted: Thu Sep 24, 2009 12:07 pm    Post subject: Reply with quote

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


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Sep 24, 2009 9:19 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Caperz
Itiler


Joined: Jul 24, 2009
Posts: 23
Location: Sydney, Australia

PostPosted: Mon Nov 30, 2009 2:34 pm    Post subject: Known Error Record Details Reply with quote

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


Last edited by Caperz on Wed Dec 09, 2009 12:44 pm; edited 1 time in total
Back to top
View user's profile
Bluesman
Itiler


Joined: Mar 19, 2008
Posts: 29

PostPosted: Mon Nov 30, 2009 10:03 pm    Post subject: Reply with quote

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


Joined: Jul 24, 2009
Posts: 23
Location: Sydney, Australia

PostPosted: Thu Dec 03, 2009 6:16 am    Post subject: Reply with quote

Bluesman wrote:
Add a few fields:

Who has verified the Root Cause?
Who verified the Workaround?


Gday Bluesman - Why would you want this information ?

Quote:
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 its 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.


Attention ITIL Team and World - I have a question around this - If you had a KE where you know that the work-around can ONLY be applied by a specialist team due to restricted level of access e.g Mainframe ... would you still publish this KE to the Service Desk ? Why or why not ?
_________________
ITIL V3 Capability - Operational Support & Analysis Certified
Back to top
View user's profile
SwissTony
Senior Itiler


Joined: Feb 26, 2009
Posts: 118
Location: Geneva

PostPosted: Thu Dec 03, 2009 6:54 pm    Post subject: Reply with quote

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? Wink
Back to top
View user's profile
Caperz
Itiler


Joined: Jul 24, 2009
Posts: 23
Location: Sydney, Australia

PostPosted: Thu Dec 03, 2009 9:08 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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.