Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

Problem Management

SOLVED
Go to solution
Highlighted
Michelle Hall
Super Collector

Problem Management

We are currently using Service calls, incidents and work orders in the Service Desk and are planning implementation of problem mgmt.
Has anyone out there documented the details around problem classification scheme, known errors and problem categories. I have built the workflow process but was hoping that there would be some great example of what others have done already. Any assistance is greatly appreciated.
5 REPLIES
Robert S. Falko
Honored Contributor
Solution

Re: Problem Management

Michelle,

I am sure there are as many different ways to use these objects as there are organizations. Here is what we do :

1) Classification
There are two key things you need to know in Problem Management:
- Problem Control: the cause of the problem
- Error Control: the solution to the problem

We use Classification for the causes of problems. OVSD does not let us classify the proposed solutions.

2) Known error flag
When you search amongst problems to find a solution or a workaround for an incident, the assumption is that a problem with the Known Error flag set will be the best one to use (if there are more than one pertinent problems). Other than that, the flag is rather redundant with the status.

3) Category
If you look at What's This, you get the idea that the category has something to do with the cause. Well, we decided not to work that way. For us, the category principally determines the workflow of the problem. A Reactive Problem will have a different workflow from a Proactive Problem. We use this principle for all types of items, and find that it works really well. The category also determines which custom fields are active and we use it to determine the subform to display. These two things are almost always very closely related to the workflow, so it all works out fine.

Now, some general advice.

1) Unless your organization has a mature Problem Mgmt process in place for some time already, Keep It Simple!
2) In any case, Keep It Simple!
3) The way you analyze problems must be closely aligned to the way you analyze Incidents. Since you already have Incident Management in place, let that take the lead. Just remember that the whole purpose of Problem Management is to figure out why you are having incidents, and to decide what to do about preventing those incidents.
4) Keep It Simple!

Good luck,
Josh
Michelle Hall
Super Collector

Re: Problem Management

Hi Josh,

I am ITIL trained so I'm with you about keep it simple. My goal is how to leverage the tool the best way I can and do it simply. So your guidance does very much assist me.

Are you actually using the module in a production environment?
Michelle Hall
Super Collector

Re: Problem Management

Josh,

As I work my way through setting up the problem closure codes I wanted to ask you one more item, about you approach to reactive and proactive problem solving? What is the key differentiator? Do you manage reactive as incidents with work orders? Could you share any workflows with me?
Ashly A K
Honored Contributor

Re: Problem Management

hi!

We are using the Pronlem Managmnet and very much happy with SD with its capabilites.

Well, i think the categories should be realted to your business.

We realte incidents to problem, then change to problme. The first line people can refer the solutions/work around from the problem tickets.

Could you mail me at ashlymonak@yahoo.com ? I can share some more deatils.

-Ashly
http://www.geocities.com/helponhpopenview
Robert S. Falko
Honored Contributor

Re: Problem Management

Michelle,

For us, reactive problem mgmt. is where a problem is created from an incident, typically by the incident resolver or by the person who validates the incident resolution. The Problem is thus "the cause of" the incident. These problem records are then assigned to the problem manager. When the problem is resolved the submitter is informed. The problem manager will judge if this is indeed a new problem, and then go through classic problem control. During the life of the problem, additional incidents may be related to the existing problem.

Proactive problem mgmt. means for us that the Problem Manager creates the problem without first having an incident (or service call). It may happen that the Problem Mgr. will identify incidents that were due to the problem, but this is not essential to the process. Its workflow is similar to reactive problems, but there is no information sent to the creator of the problem.

In other words, reactive problem mgmt is quite separate from incident mgmt.

Regards,
Josh
//Add this to "OnDomLoad" event