Criteria for Opening Problem Ticket

[wkstan2001]

Hi,

I'm in the mist of defining a criteria for opening problem ticket guideline for our support engineer. Below are some of the criteria that I can think off. Perhaps the forumer can provide some best practice that has been implmented in your enviroment.

Criteria for Opening problem ticket

- Repetitive incident
- A workaround or temporary fix in place
- Real (root) cause of problem is unknown
- A permanent solution is required to be created and implemented
- A case has been open with vendor for further investigation

[m_croon]

Hi,

* A high(est) priority incident
* Monitoring events that might lead to an incident in the future: excessive disk/bandwith use etc.
* Anything that requieres extra management attention, such as failed backups etc.

[eisbergsk]

excellent criteria. I have a 'look at it backwards' suggestion: How big is your problem group (people available to investigate problems, and do PM)? After you come up with all the criteria, edit it down to the criteria that are important to your company (whatever that means) but also manageable by available staff.

short version: If you have 1 body, more than 50 problems a month might be too many to manage properly.

my experience: 1 body (me) + consistent criteria over a number of years = really awesome metrics, & defensible findings to dispell myths and assumptions and implement changes that really DO reduce incident volume by eliminating errors in infrastructure, and contribute to a more stable environment.
/Sharon E

[JoePearson]

A very good point, Sharon. The primary reason Incident Management and Problem Management are separate disciplines in the ITIL world is to allow for a management decision to dedicate some resources (like you) to in-depth or pro-active work. Thus it's a good test of the qualification criteria to look at the number of problems raised against the number of people in problem management!

[Guerino1]

Hello All,

This is more to address some of the comments in the last few posts, rather than the original question, but I figured I'd throw it out there as some extra info...

As a manager or as the owner of a company, I can say that I always want the cost of any function to be minimized, while the output of that service to be "good enough" to meet my needs (preferrably spectacular, but good enough is what you're typically looking for). A way to achieve this for Problem Management is to ensure that every Product, Service, and Process has a fully dedicated and accountable "owner" within the enterprise that runs it according to the traditional definition of what "Product Management" means. This ensures that you have someone that is totally accountable for these constructs. Once you have Product Owners that are running the strategies and implementations of these constructs properly, they will do Product-specific Problem Management, simply by tracking and managing the Problems, Incidents, Risks, and new Requirements that come in for their Products. (If they're not doing these things, they're not doing proper Product Management.) Their own development and support teams can do this. Once you have this in place, you make it the responsibility of the ITIL Problem Manager to manage the priorities and communication of Problems "across" all Products in the enterprise. If you make each and every Product Owner accountable for working with the Problem Manager, then you have a simply way of beefing up Problem Management without the extra headcount.

No executive or owner in their right mind wants to raise their headcount and/or associated costs unless their is a true business return on doing so. It's always important to understand that "ITIL" relates to the operational side of how a business runs, making it all an "expense", meaning no single ITIL function generates revenue but, rather, consumes revenue. And, it is important to always keep in mind that expenses are bad and must be held as low as possible, while ensuring the most "acceptable" return for that expense.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]