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: ASisco
New Today: 8
New Yesterday: 54
Overall: 146221

People Online:
Visitors: 51
Members: 1
Total: 52 .

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 - How technical should a Known Error Record get?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

How technical should a Known Error Record get?

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
Katherine
Newbie
Newbie


Joined: Apr 17, 2008
Posts: 9
Location: South London

PostPosted: Thu Apr 17, 2008 5:42 pm    Post subject: How technical should a Known Error Record get? Reply with quote

Hi, I've recently taken on the role of Problem Manager and have implemented a problem management process of problems and known errors (its still not quite there yet) and I'm having a few issues.

How technical should Problems and Known Errors get?

ITIL Problem Management is being used here purely for the support of a database system so I'm talking about where there are bugs in code rather than network issues.

For instance, an error message appears to the user which is reported to the service desk and it goes through the usual places and results in a Problem being logged.

On investigation I find out that the reason for this error message is that a field is blank and the code is trying to use data from this field and so falls over.

Do I describe the underlying problem in the Known Error as above, going into detail on the field name etc or do I list the actual line(s) of code that is falling over?

How much techie detail should be recorded in the Problem and Known Error records?

Thanks in advance.


Last edited by Katherine on Thu Apr 17, 2008 8:24 pm; edited 1 time in total
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3313
Location: London, UK

PostPosted: Thu Apr 17, 2008 6:17 pm    Post subject: Reply with quote

Katherine,

How long is a piece of string that is in the pocket ?

It depends on whose pocket

The level of detail for a Known Error, Problem, incident... etc record

should be where there is enough information that explains/conveys / highlights/illustrates the issue for the 'norm' of people.

====================
I compare it to the old joke about the prisioners in jail telling jokes. Because they have a finite list of jokes and the fact they have told the same jokes over and over, the prisioner came up with a numerical list

42 says one people laugh
18 says another people laugh
76 says the new prisioner.. no one laughs.
what's wrong he asks his cell mate. the cell mate replies /... you cant tell a joke very well can you

=========

There is no hard/fast rule how many characters, words, phrases etc that should go into the record. It should be enough so that when some one who was not involved with the creation / discovery etc reads it, thaty they will understand fully what it was about... without having to go somewhere else
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Thu Apr 17, 2008 6:40 pm    Post subject: Reply with quote

Hi,

it has to be as deatiled as you need it to be.

If you just want a KE list - then not very detailed
if you want to provide user of the KEDB with the "what to do in this situation" type information then you need to add this i.e. for apply a possible workaround
If you need the KEDB to assis tin the resolution of the KE then you need to get technical.

You can resord this information in seperate sections i.e. keepthe techie stuff in a seperate section that the workaround information for ease of reading / finding information
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
Katherine
Newbie
Newbie


Joined: Apr 17, 2008
Posts: 9
Location: South London

PostPosted: Thu Apr 17, 2008 6:51 pm    Post subject: Reply with quote

Hmm, there is already a seperate system for the design of a bug fix.

I guess what I was trying to ask is who is the audience of the Problem Log and Known Error documents? They are used as basis of the RFC which is impacted and then sent off for approval. Once approval has been received a developer then starts work on the design of the bug fix.

I assumed that the audience was a business audience and so described the problems & known errors but the head techie has complained that there isn't enough detail in the logs.

As you say Mark, perhaps a new section on the KE record for the techie stuff is the way to go.
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Thu Apr 17, 2008 6:52 pm    Post subject: Reply with quote

Katherine,

it's about what you are going to do with the information and about who is going to (or needs to) see the various bits.

The main reason for the known error log is to help in dealing with incidents. Probably it needs to contain a description of the symptoms; what needs to be done to recover from further occurrences the incident; what the user should know in terms of workaround or avoidance; what explanation should be given to the user as to the cause and expected clearance date. Obviously also a link to the problem record and any special reporting or other action when the incident re-occurs; technical and customer contacts related to the problem and its resolution.

From the Problem Management perspective, you might need impact of occurrences; the root cause analysis report; link to the change request that is going to fix it; link to the known error record; history of related incidents; technical and customer contacts related to the problem and its resolution not necessarily identical to the KEL contacts).

There is probably stuff like this in the books, but I don't have access to them these days. To address your question about technical detail, that would start in the root cause analysis report and continue or be referred to in the detailed change requirement specification. There is nothing to stop you putting all that in the KEL if that is practical for your purposes, but everyone should understand the purpose of the different information sections.
_________________
"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
Diarmid
Senior Itiler


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

PostPosted: Thu Apr 17, 2008 7:06 pm    Post subject: Reply with quote

Katherine,

Katherine wrote:


I assumed that the audience was a business audience and so described the problems & known errors but the head techie has complained that there isn't enough detail in the logs.



my first reply was composed before your second post. So not quite the picture you want.

I don't think the problem log or known error log is for a business audience (as you might glean from my response). There should be completely separate reports for IT management and for service review (i.e. talking to customers) about problems.

These need to talk about problems in terms of impacts, resolution times, impacts of resolution, ability to resolve (in extreme cases). There would be some narrative to describe the problem, but certainly not in technical terms.
_________________
"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
Katherine
Newbie
Newbie


Joined: Apr 17, 2008
Posts: 9
Location: South London

PostPosted: Thu Apr 17, 2008 7:08 pm    Post subject: Reply with quote

I've assumed the audience is a business one rather than technical as I have to report on what the problems and KE are to management. Also, the incident team themselves have a workaround database that they use which is outside of Problem Management.

Hmm, perhaps a new section on the KE for Root Cause Analysis where technical info can be held and the Underlying Cause and Solution sections for the business audience?

Btw, thank you for helping! I've been on the Foundation course and the Problem Management Practitioner course and then been told to get on with it and there is no one here I can turn to, so thank you again Smile
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Thu Apr 17, 2008 7:19 pm    Post subject: Reply with quote

Katherine,

Katherine wrote:

the incident team themselves have a workaround database that they use which is outside of Problem Management.



who is responsible for ensuring that all problems have an entry (even if it is a null entry in some cases) in the workaround database, if it is does not come under problem management?
_________________
"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
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3313
Location: London, UK

PostPosted: Thu Apr 17, 2008 7:23 pm    Post subject: Reply with quote

katherine,

Ideally, the same source should be used for the incident mgmt use ofthe problem records and the business use of the problem records and the user use of the problem record (FAQs)

The incident mgmt section would have the techie level detail of detail which could be very verbose etc etc etc

The business mgmt section would have the mgmt weenie sort of information
KPIs, statistics, summary, impact etc

The user section may have the following

what to do if
what not to do to
how the problem occurs
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Katherine
Newbie
Newbie


Joined: Apr 17, 2008
Posts: 9
Location: South London

PostPosted: Thu Apr 17, 2008 7:30 pm    Post subject: Reply with quote

Diarmid wrote:
Katherine,

Katherine wrote:

the incident team themselves have a workaround database that they use which is outside of Problem Management.



who is responsible for ensuring that all problems have an entry (even if it is a null entry in some cases) in the workaround database, if it is does not come under problem management?

This is yet another issue that I have as I'm pretty sure that it is done on a 'relaxed' basis by the incident people themselves and I'm not allowed access to it. When I tried to explain that it comes under Problem Management I was told that as it works ok, it would stay with the incident team.

Unfortunately, I've been given the PM role without a great deal of management support where everyone is resistent to change.
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
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.