Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: ILambie
New Today: 11
New Yesterday: 53
Overall: 145932

People Online:
Visitors: 55
Members: 3
Total: 58 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ģ ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - problem is open: incident service level does what?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

problem is open: incident service level does what?

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
tmack
Itiler


Joined: Jan 21, 2007
Posts: 20

PostPosted: Thu Jul 02, 2009 12:46 am    Post subject: problem is open: incident service level does what? Reply with quote

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?
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3313
Location: London, UK

PostPosted: Thu Jul 02, 2009 12:59 am    Post subject: Reply with quote

tmack

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
Back to top
View user's profile
thechosenone69
Senior Itiler


Joined: Jun 06, 2007
Posts: 268

PostPosted: Thu Jul 02, 2009 1:02 am    Post subject: Reply with quote

Hi Tmack,

I hope I understood your question right.

The Service Level clock will not stop ticking. If a problem was given a priority 1 then all related incidents will be treated as priority 1 as well as they relate to that problem.

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.

So the clock had started ticking when the service went down.

Kind regards,

A
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3313
Location: London, UK

PostPosted: Thu Jul 02, 2009 2:43 am    Post subject: Reply with quote

The clicking clock for incidents (SLA) is on a different scale (or should be) for those on a Problem

The incident SLA & OLA are linked to the processes and procedures for incident analysis and solving - ie restore the service

The problem SLA may not really exist (see comments about PM process in other threads.

There is a consistant issue where Problem processes and incident process are used for the same process (incident)

Problem management is trying to find out why something went wrong and whether it should be research and solved

Example:

Server hangs every 3 or 4 days. Incident mgmt records the error msg and restarts . Incident mgmt process

The 20 - 30 time the server crashes meets the criteria for PM review

The PM team dedicates some time to investigate the error msgs. The 10 hours that is dediciated to the issue may be done over a 2 week period as this is the standard practice for PM work

So there may be no OLA clock on PM. There is no SLA as PM is NOT customer facing
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Jul 02, 2009 2:48 am    Post subject: Reply with quote

thechosenone69 wrote:
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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.