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

Handling Problem tickets

Highlighted
amykoh
Senior Member

Handling Problem tickets

Hi all,

I have a question on how to handle Problem tics.

My scenario:
Multiple similar SC or Incidents will trigger a new Problem tic. Where SC or Inc will be related to the Problem tic.

If a problem can be solved, it'll be closed.

Else if may trigger a new Change Request tic.

My question is how is the deadline of a Problem managed as its not tied to SLA.

Should a Problem tic be 'loose' w/o a specified dateline or with one, based on severity?

Thanks!
Amy
5 REPLIES
Robert S. Falko
Honored Contributor

Re: Handling Problem tickets

Amy,

In theory, any service offered by IT could be subject to an SLA or an OLA. As problem management is generally an internal IT service, it is generally subject to an OLA. According to best practice, the deadline for problem resolution is generally based on its priority, which is generally determined by its impact and its urgency.

In practice with OVSD (at least, with 4.5), the out of the box functionality depends on using Service Calls or Incidents. The product does not really manage the OLAs that might govern Problem (or Change) Management. So you have to build the functionality yourself, typically with DB rules that send mail, change deadlines or reassign tickets.

The question of how you "should" manage this depends on the objectives of your organization and its level of maturity. Many organizations are happy just to have a Problem Manager and a Problem Management process. As they become more mature, problem management can be subjected to deadlines, typically based on priority, as mentioned above.

Good luck,
Josh
amykoh
Senior Member

Re: Handling Problem tickets

Hi Josiah,

I agree that the Impact and Priority should reflect the dateline, but if it is related to a change,then the dateline will burst.

How I intend to implement. Impact and Priority will reflect specified dateline. But if its in RFC status, it will be non-accountable.

How does that sound?

Amy
Robert S. Falko
Honored Contributor

Re: Handling Problem tickets

Amy,

That sounds pretty good to me.

Remember that while the work is being done on the change, the change managers ought to be accountable. When they close the change and return responsibility to problem management, the problem managers become accountable again.

In my experience there are two approaches to handling the closing of a change that has been triggered by a known error:

1. Change Management is reponsible for the Post-implementation review, followed by closure of the change. This is an elegant and consistent solution, but might not be logical from the point of view of problem management.

2. Problem Management does the Post-implementation review, which is logical, but makes the workflow for closing the change and the known error more complicated.

I suggest you do whatever your organization is most comfortable with. In any case, OVSD has no out of the box functionality to really support this. You need to create it yourself.

-Josh

amykoh
Senior Member

Re: Handling Problem tickets

Hey Josiah,

Thanks for sharing your experience. I've gotta mull over the crooks and canny of my process again...hehe...

I'll keep you updated on any findings...

Amy
Ken Briscoe
Honored Contributor

Re: Handling Problem tickets

Hi Amy,
Good question. The Problem Manager should be weighing up all the open Problems to determine which are most important (which causing most pain and cost). There will usually be more problems than resources to solve them so I don't believe it's practical to put a deadline on every problem the way you do with SC and IN's. And that's why you usually don't have SLA's around problem resolution. (Besides, some problems can't be resolved or aren't worth it). The Deadline should be determined individually for each Problem - that's were a good Problem Review Board comes in.
When you do have a deadline agreed, then that should include the time to apply Changes. We usually have a Change Deadline field as the "drop-dead date" - ie the latest time the Change must be implemented. Can be done earlier of course. So this would be set a short time before the Problem Deadline to allow for post Change review.
And wherever a Change is implementing a Problem solution, we say that the PIR would be done jointly. Either Change Manager or Problem Manage can chair but both are stake holders. This is an important point where the two porcesses come together.
HTH......Ken.
My email is kenilian@bigpond.com.au
//Add this to "OnDomLoad" event