Who Owns a Known Issues List?

[ShhVance]

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?

[rams]

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

[taiger]

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"

[rjp]

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.

[Mahmoud]

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.

[rjp]

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.)

[Mahmoud]

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

[xitil]

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