Page 1 of 1
Problem raised to investigate an incident
Posted: Wed May 18, 2016 3:05 am
I'm new to ITIL and I'm currently working in reducing our huge queue of open problems.
I've noticed that a lot of these problems were raised after a single incident only because the user was not happy with closing the incident until more investigation was done regarding the root cause.
Is this the right way to proceed? These are usually low priority incidents so the problem never gets any attention and it just sits there forever.
It seems like the problems should not have been created in the first place and maybe the user should have been told that sadly other incidents have a higher priority and we just can't do a root cause analysis on this at the moment.
Any advice on how to tackle this type of situations?
Thanks for your help
Posted: Wed May 18, 2016 2:24 pm
You have been hit by one of the most common mis usages of ITIL processes.
First. :Lets talk about Incident Management (IM)
IM goal is to restore the service. Not provide an explanation as to why it happened.
The action that is taken to restore the service is usually all that is required
Service disabled.Server rebooted.
Done. next Incident
Problem mgmt is time consuming and may not result in a solution as the reason may never be known.
The process for PM is in two parts - Reactive and Proactive
Proactive - is when yo look at tyour infrastructure and find Single points of failures or weak IT assets that can or will cause incidents and replace them
Reactive is taking the conditions of a incident (set of incidents) and try to find out the why it is happening.
The way it should go is as follows
An incident is created - the team working on it works to restore the service.
As part of that - they say.. hey this incident should be looked into as a problem.
This is a problem record candidate
The PM Manager would have a set of criteria as to what Problems are going to be worked on - and how much time is to be spent on each and record how much time has been used trying to find the underlying root cause.
Incidents have SLAs
So if there are 200 PM candidates, the PM manager - says you work on these 3 or 4 and rejects the rest.
This should be stated in your policy documents
Posted: Thu May 19, 2016 12:56 am
Thanks a lot for the reply, UKVIKING
It all makes sense, and hopefully we'll get to a point where we'll be able to work like that.
For now the main question that I have is about managing the user's expectations.
Should the team push back and let the user know that finding the cause for a low priority one-off incident will not happen?
Or should problems be automatically raised as soon as the user request it and then the Problem Manager have the task of communicating with the user in the case that their problem will not be worked on?
In this case all the users are within the same company, so I would expect them to understand if they are not at the top of the priority list, but maybe that's just wishful thinking
Posted: Thu May 19, 2016 1:55 am
First, are you an internal service desk or do you provide services externally.
Either way, you need to produce a document explaining the purpose and goal of IM and PM
In addition, PM work should be well defined