Are the metrics / SLA below a good indication to get a problem resolved. Or is the metric below related to the incident ticket? Can the SLA'S assigned to an incident be the same for resolving a Problem ?
How can you put a time line on getting a problem resolved?
o (Very High) up to 1 Day
Multiple Incidents to critical Business System or infrastructure
No workaround identified
No Root Cause available
o (High) up to 3 days
Multiple Incidents to critical Business System or infrastructure
Workaround identified to restore service
Root Cause not available
o (medium) up to 5 days
Multiple Incidents to Business System or infrastructure
Workaround identified to restore service.
Root Cause Available
o (Low) Over 5 days
Non-service impacting, workaround in place with Root Cause available
Example of Problem SLA / Priority
Fulhamm
As Incident Management is to resolve the incident and restore the service a SLA is used to determine how quick the service is restored against what would be the norm for fixing that type - classification - of an incident
However, Problem management is about finding the cause of the incident - which may takes days. weeks months years or never
SLAs is not recommended then
As Incident Management is to resolve the incident and restore the service a SLA is used to determine how quick the service is restored against what would be the norm for fixing that type - classification - of an incident
However, Problem management is about finding the cause of the incident - which may takes days. weeks months years or never
SLAs is not recommended then
John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Resolving problems is a bit complicated then restoring service, as you might need to work with different support teams or even vendors.
So a definitive SLA for problem management is quite difficult.
But we do track the problem with an aggressive way if it causes a severity 1 or severity 2 issues, e.g. system downtime, performance degradation:
1) We need update every day initially until a clear and detailed follow-up plan is in place.
2) And then we need update every week to check the progress.
3) If the issue happens again, we'll then change the weekly meeting to daily meeting with incident / problem support on the same call.
So a definitive SLA for problem management is quite difficult.
But we do track the problem with an aggressive way if it causes a severity 1 or severity 2 issues, e.g. system downtime, performance degradation:
1) We need update every day initially until a clear and detailed follow-up plan is in place.
2) And then we need update every week to check the progress.
3) If the issue happens again, we'll then change the weekly meeting to daily meeting with incident / problem support on the same call.
Luo, Tian-Hong (Ken)
Regional Operation Lead
ITIL Expert Certified
Regional Operation Lead
ITIL Expert Certified
Agree, also company politics might come into consideration.UKVIKING wrote:Fulhamm
As Incident Management is to resolve the incident and restore the service a SLA is used to determine how quick the service is restored against what would be the norm for fixing that type - classification - of an incident
However, Problem management is about finding the cause of the incident - which may takes days. weeks months years or never
SLAs is not recommended then