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: CCamarena
New Today: 29
New Yesterday: 67
Overall: 148331

People Online:
Visitors: 65
Members: 1
Total: 66 .

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 - Who Owns a Known Issues List?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Who Owns a Known Issues List?

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
ShhVance
Newbie
Newbie


Joined: Aug 29, 2005
Posts: 4

PostPosted: Wed Nov 16, 2005 10:15 am    Post subject: Who Owns a Known Issues List? Reply with quote

We are starting to think more seriously about publishing a 'known issues list' for our customer base to leverage. The known issues essentially contain information from problem tickets like symptoms, work arounds root cause analysis info, steps to reproduce, status (if resolved at some point what service pack is it resolved in?)

My question is, some say this is a support responsibiity, others say its Product Management and others still say its development.

According to ITIL where do known issues come from, where in the life cycle are they born and how?

I would think that known issues come from support but only after development has done root cause analysis on the problem...but then who has the final 'ok' on what gets published?
Back to top
View user's profile
rams
Newbie
Newbie


Joined: Nov 22, 2005
Posts: 8

PostPosted: Thu Nov 24, 2005 9:57 am    Post subject: Re: Who Owns a Known Issues List? Reply with quote

Create a role (or a group) of 'Known Issue List Owner'. This role would be final authority to manage and publish. They need not belong to any specific group like support etc. There reponsibility would be just to manage and publish the documents. In the large organization you might need full time person(s) for this task.

Input to this list may come from any where:
- Service desk & Incident Management - for repeated incidents they will record the incident details and work around
- Problem Management - details of known error, solution
- Application support - Technical details, root cause, work around etc.

Input to knowlede base may come from any where which is helpful but should go through approval process.

Ram
Back to top
View user's profile
taiger
Newbie
Newbie


Joined: Dec 28, 2005
Posts: 8
Location: The netherlands

PostPosted: Fri Dec 30, 2005 10:17 pm    Post subject: Reply with quote

hi,

i think the responsibility for publication shouldn't lei at a group but should
be assigned to a role as ram pointed out.

the responsibility for input should be assigned to the
diverse teams ;
support
product management
development

escpecially development could be interresting for they could
publish known errors that excist in new developed software
and so reducing the number of incidents

regards
Frank
_________________
"if you aim at nothing, that's what you're likely going to hit"
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Sun Jan 01, 2006 1:31 am    Post subject: Reply with quote

If this repository is intended to be used by customers then it is clearlt the responsibility of the Service Desk.

The Service Desk should own all communications with the community.

This does not mean they will author everything however.

Also: Stay oriented toward customner service and satisfaction. Slef-service in many contexts is code for transfer of effort. Customers aren't stupid - it frequently backfires. Anything provided to the customers to help them 'help themselves' should be of the highest quality and under constant review. If you can't ensure that - don't do it.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Mahmoud
Newbie
Newbie


Joined: Oct 08, 2005
Posts: 8
Location: Canada

PostPosted: Mon Jan 02, 2006 6:39 am    Post subject: Reply with quote

Known error database generated from incidents reported to Service Desk, the work around for such errors found by the support groups. A modern Service Desk provide support functions (1st & 2nd level support in some cases), to it's customer to ensure customer satisfaction. For some incidents it may be routed to 3rd or 4th level support to get a work around or resolution. So Service Desk is your SPOC.

As stated by RJP the quality of provided data and selfserve via a KEDB is vital to the customer, it must be accurate and up-to-date, otherwise your reputation will be on the bad boat.
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Tue Jan 03, 2006 11:48 pm    Post subject: Reply with quote

A correction Mahmoud (with respect - of course)...

Known errors are not generated from Incidents.

Error control and the creation of error records is the responsibility of problem management. Error records are (formally) an input to incident management. Under ITIL and error is a faulty CI (though this assumes config management is in full swing), a known error is a record against that specific CI, against which a corresponding RFC will be raised and handed to change management.

However, good service management processes will allow for the fact that a root cause may often be identified during incident resolution: In these cases other relevant records should be created - a problem record, and if it is a simple error, with an error record (and likely pre-approved standard change required) an RFC as well. The information requirements should be met consistently, but without slowing positive activity.

Known Errors, are process control data - not generic technical support information. A workaround is therefore of a different nature: It is either, a) A record of a specific action taken to get functionality restored (or adequatley replaced) - during the incident respones, or,
b) A knowledge record on how to deal with an incident of a particular type.

Resolution activity records on closed incidents do have an important knowledge-utilisation role to play (provided your tools suppport it.) By being able to match current incidents against closed ones, the resolution logs provide valuable information.

To further improve the value of this information, the resolution / activity logs should be reviewed and good (or commonly required) workarounds extracted.

But Known Errors and Workarounds don't relate directly - because:
Known Errors are specific, and transitory.
Workarounds (once abstracted) are generic and persistent.

(Which means the term "Known Errors and Workarounds Database" is a little misleading.)
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Mahmoud
Newbie
Newbie


Joined: Oct 08, 2005
Posts: 8
Location: Canada

PostPosted: Wed Jan 04, 2006 12:44 pm    Post subject: Reply with quote

That is true. Thanks for the reminder. However

Problem management team or group represents an advanced support role, investigating and providing solutions or workarounds. Yes we know the implementation has to go through RFC, change management and configuration management. We have to remember ITIL provide you with the concepts of wearing and changing hats, in some organizations all of this under Service Desk Umbrella, and this is working very well for many reasons mainly the economic one.

Applying what’s in the IT service management a foundation or Service support or service delivery book will not help in a practical operational IT service management organizations. I agree with your definitions and concepts in theory, as stated on the ITIL books, the practical world is totally different story, and remember ITIL depends on best practise and it’s not yet standard.

So far I haven’t experience one company who implemented a full operational CMDB process; from the other hand a lot of companies have a known error database, knowledge base and both are operational and working. Therefore you don’t need full swing CMDB process in place to create a known error database or knowledge base. This is proven practically.

One of the most important factor while implement ITIL processes is to understand “Service Culture” of the region, or country, on how they used to perform their business. As you have stated in your scenario notes, it may work perfectly in Australia, but not in Europe or North America. The objective of implementing ITIL processes is the three E’s. It depends on your customer, where you can save them some $$$ with respect to the quality.

I respect your statement "Known Errors and Workarounds Database" is a little misleading. But I don't agree with it why becuase it's been implemetend on large environment enterprise and it's working, remember Service Culture Concepts
Back to top
View user's profile
xitil
Newbie
Newbie


Joined: Jan 17, 2006
Posts: 13
Location: France

PostPosted: Thu Jan 19, 2006 7:40 am    Post subject: be pragmatic: the owner should be... Reply with quote

The owner of a known error list should be the one who benefits from it most...



so...



...



tadaaaaaa



...the support group!

But to own it does not mean to build it! It means controlling it, making sure it can be used effectively and that it achieves its purpose.

The input will be coming from Problem Management a lot (with the help from the development/research team), and straight from development/research when new releases are deployed/published, along with a few bugs.

These bugs should either be recorded as problems (ie: it does not work but we don't know why) or known errors (it does not work, but we know why) ...

In any case, the support team must make sure that its content will help them as expected. It is their responsibility.
_________________
Better have remorse than regrets Wink
Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.