Posted: Wed May 18, 2016 5:05 pm Post subject: Problem raised to investigate an incident
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?
Joined: Sep 16, 2006 Posts: 3589 Location: London, UK
Posted: Thu May 19, 2016 4:24 am Post subject:
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 _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
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
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum