When To Open a Problem Record

[Liti]

Hello everybody,

at this time I write my diploma with the focus of imlementing service support procceses (Incident Management, Problem Management and Change Management and Release Management).
This service support processes should support an application.

I have following question. When do you create a problem record?

My opinion is, an incident goes through the 1st-level and 2nd-level. If it isn't possible to solve the incident, the incident became an unknown-error. At this point I would open a problemrecord.

Is these approach okay, or do you think there are other reasons to open a problem record.

Bye
Christian

[dboylan]

Christian,

There are three commonly accepted reasons of when to open a Problem Record. You mentioned one, but I would have put it differently.

You describe the instance where the Incident Management process is unable to resolve an issue. So in real world terms -

-Something is broken.
-The groups responsible for quick resolution (and this can be 1st-2nd-3rd-4th-5th-xth level support) are unable to determine a fix.
-The issue can simply not be ignored ("Sorry user, you really didn't need to be doing that anyway") so you must do serious root cause analysis to discover what caused the issue in the first place before a fix can be put in place.
-At this point you refer the Incident record to the Problem Management process for them to open a Problem record and prioritize the issue.

The other two times you would open a Problem Record are:

1) When you discover that many Incidents have similar symptoms indicative of a common root issue, and the Incidents keep reoccurring. You would open a Problem Record in the hopes that by eliminating the Root Cause, the Incidents will also stop.

2) Whenever an Incident occurs that is so costly (often called a Major Incident) that it is in the financial interest of the company to spend money to ensure that it never happens again.

Don

[dboylan]

I forgot to mention the proactive instance where you might open a Problem Record.

-You notice a failure in one Service for which the root cause is a failed component.
-You then realize that a duplicate of the failed component is also utilized in another Service
-You might open a proactive Problem Record to ensure that that a similar failure won't take down the second Service.

[Liti]

Don,

thanks for your extensive and detailed answer. Now I understand, how to handle the problemmanagement.

Thank you
Bye
Christian

[bonethug]

thats an interesting answer dboylan. thanks

[Titan]

Dboylan,

I completely agree with you. Just interested in your take. When do you determine that the Incident cannot be restored/recovered and it is necessary to engage Problem Management?

Do you have a standard for determining it, or does it vary from issue to issue?

Thanks!
_________________
-----------------
Kyle Hall
Bank of America
ITIL Practitioner (blue badge)

[dboylan]

Kyle,

There are two ways that it can work in the real world that I have seen:

First is when there is an SLA breach. If it is determined that resolution of an Incident is not within sight when a SLA breaches, then you need to start doing serious Root Cause analysis through the PM process.

The other is a more common sense approach, regardless of where the Incident is in relationship to an SLA breach. If the people working the Incident know that a resolution is not going to be forthcoming, they should have the authority to request that PM be engaged to determine root cause.

Don