Sorry, my earlier post was brief & not the full answer. My answer is yes, on the basis that:

1- While the Service Desk are the primary users of the KEDB, they are not the only users.

2- By documenting the fix within the KEDB the Service Desk agents are able to identify it as a KE, advise the user/s that there is a workaround & that it will be forwarded the the group who can resolve. Also, they are then able to correctly assign the ticket. Increasing time, efficiency, & customer satisfaction, etc etc.

I have my opinion on this topic, but am curious on getting input and feedback on how other organisations are working with Known Error records.

Does anyone see the benefit in setting up the KEDB so that a KE record is only accessed by the people that can actually apply the workaround in the document ? - In other words not allowing Service Desk staff to see KE documents where they cant apply the fix contained in the document

If the Service Desk - who manage incidents - discover an incident which meets the criteria for the workaround, how are they suppose to send the incident resolution team the work to be done if they do not that there is a workaround_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Do you see the any danger or harm of curious or adventurous Service Desk staff trying to snoop around systems that they shouldnt be, if they have some information in a work-around that needs to be applied by a specialist group ?

Remember - I have not said that I am for the questions that I have asked... I would like to just get an idea of how Known Error Managememt is being applied out there.

I must say I agree with your views, suggestions and feedback. I do see the value in all KE records being available and visible to the Service Desk team if they cant implement the work-around themselves.

How do you distinguish between work-arounds that are intended for the Service Desk (that they can apply) and ones that they cant ?

Does anyone have a sample or a suggestion for the fields that are included in a Known Error record in your organisation and/or what works well ?

Appreciate your help on this and hope the feedback helps others._________________ITIL V3 Capability - Operational Support & Analysis Certified

I agree with the idea that Known Errors and their documented workarounds should be visible to all, even though some may require specific skills/access rights to perform. The only exception I would make is regarding Known Errors that document security vulnerabilities. Depending on the content of your Known Error records you may want to be careful how much information and to whom you are willing to provide regarding the identified holes in your credit card database, for instance.

As far as making a distinction between workarounds that your Service Desk can apply and the ones they cannot, I would suggest to make that part of the workaround description. Like: "Replace config file X.1 with config file X.2. This requires root access and should be performed by a senior Windows System Administrator."

Regarding the data in your Known Error record, some suggestions beyond the items you listed in a previous post in this thread:
- Root Cause Category (e.g. code defect, design flaw, component failure, procedural flaw ... this can help you to take a deeper dive and for instance identify poor coding practices)
- Proposed solution (this is the permanent solution, not the workaround)
- Planned solution date (when do you think the error will be eliminated from the environment)
- relationship to the RFC that introduced the error into the environment (good to track, although in reality you will not always be able to find the flawed RFC nor will you be willing to spend the time finding it .... in the cases that you do find it, track it)
- relationships to the incidents resolved by the workaround documented in the KE (this would indirectly tell you how often it was used and by whom; no need to track this separately within your KE record)
- impact, urgency, and priority
- version that will include the fix for this KE (useful for software related KEs)
- date when workaround was identified
- date when workaround was last modified

One thing to keep in mind is that organizations deal with Known Errors in ways that are different from the strict ITIL definition of having a root cause AND a workaround. Some will record a Known Error when all they have is a workaround, while others (including mine) will record one only if they have a root cause, regardless of having a workaround at that point in time. This in turn may be driven in difference by the tools being used. In some tools KE is nothing more than a flag or status change on a problem record; in others (including ours) a KE is a separate record. These differences can influence the responses you get on any question pertaining to KEs and the KEDB._________________Manager of Problem Management
Fortune 100 Company
ITIL Certified