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.
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!
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?
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.