problem is open: incident service level does what?

[tmack]

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?

[UKVIKING]

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

[thechosenone69]

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

[UKVIKING]

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

[Diarmid]