Posted: Thu Jul 02, 2009 12:46 am Post subject: problem is open: incident service level does what?
If a problem is open should an associated incident service level progress?
Looking for some feedback on this given senerio: If a problem is open with no current workaround as well as awaiting root cause and request for changes. Should the associated (linked) problems to the incident continue to progress in terms of their service level clocks.
Let me try to paint us an example to work with:
Problem: Email server is down making affecting all mail services.
Incident 1: Debra canít access email
Incident 2: Tom canít send email
Incident 3: Website inquiries arenít getting to the sales team
Should incidents 1, 2 and 3 continue to tick away at their designated priority service level resolution targets? OR move to a pending state (i.e. clock is paused) until the problem is either resolved or a workaround is established?
Joined: Sep 16, 2006 Posts: 3307 Location: London, UK
Posted: Thu Jul 02, 2009 12:59 am Post subject:
Why was a problem record created ?
Just because an incident is opened does not mean a problem is opened - even with 20 related incidents
As part of the incident resolution process, the incident(s) would handed to the email team.
If the solution to the incident is to stop and restart the email service, then this is done as part of the incident resolution and all incidents are closed as a result
If the email team finds a strange error that has never before seen, they would record it and then follow their standard processes and procedures in order to clear a hung email service. and restore service to the email service
The error msg that they found may become a candidate for a problem record if the problem mgmt team deems that the criteria for a problem has been met.
Just because there is an outage does not mean the problem mgmt process is needed
The incident must be analysed and determined what is the cause (checklist) and how to restore service _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Thu Jul 02, 2009 2:48 am Post subject:
So there will be 1 clock ticking which is the one for the Problem and any tickets that are linked with it will be synchronised to the same time of the problem.
This sounds a bit linked to a particular software regime, but I'm not sure I agree with it anyway.
The priority for each incident is related to the pain that incident is causing.
The priority to the problem is related to the pain threatening the service.
So, for example, if there is an easy workaround which removes 99% of the pain, then there may be no need to make the problem high priority.
Thus, incident 2 (Tom canít send email) may be easily resolved by allowing Tom another email account that is working, but incident 3 (Website inquiries arenít getting to the sales team) might require pulling out all the stops and incident 1 (Debra canít access email) may lack urgency if, say, Debra is about to go on holiday for a fortnight.
Back to the question of stopping the clock: raising a problem is not a reason for stopping the incident clock(s) ever.
In my view, if you want to stop the clock on an incident, then you go to the customer and demonstrate that you cannot resolve the incident until their staff do certain things and have the customer agree that these things can be deferred.
No, having written that, I have changed my mind. You should never stop the clock on an incident. Requiring users to perform actions to help resolve an incident in your service is part of the impact against the customer. If there had been no incident, there would have been no demand for user action.
The clock records how long it takes from the occurrence of an incident until service is restored. Full stop.
The only way round it (I'm thinking as I write) is if you build customer obligations (e.g. for prompt assistance) into the SLA and then they fail (or choose not) to meet them.
I'll stop rambling before I lose my argument to myself and vice versa at the same time.
Besides, now I see Viking has got in ahead of me. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
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