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
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.
Posted: Tue Jul 07, 2009 1:47 am Post subject: Missed SLA reporting
We're struck and need to drive the process for handling missed SLA.Please share your thoughts on following items-
1. In a 8 hrs service desk based support(9am to 5pm), when an SLA is missed, is the time for the missed SLA calculated based on SLA support hours or is it the wall time?
2. In case an SLA is missed, there is an escalation mechanism in place. The problem is that many SLAs get escalated. Can you share what is the best practise to review these missed SLAs?
3. How is the analysis for missed SLA done and what are other corrective actions you have come across( other than escalations!)
Joined: Feb 27, 2009 Posts: 16 Location: North Coast, USA
Posted: Tue Jul 07, 2009 2:08 am Post subject:
We have a 24hr support desk. We have varying SLAs depending on the severity/criticality of the incident. For High and Medium our SLOs and SLAs are based on 24x7. For Low incidents, we are on a 9x5 clock.
Not real sure what you mean by "Escalating SLAs". An SLA is a measurement - you either hit it or don't. Tickets are escalated.
All support activity *should* be logged in the ticket. If an SLA is missed, there should be ample documentation in the support ticket to identify where the miss occured.
As CKing said you will have incidents and problems which maybe relate to a SLA breach. The escalation for these should be defined within the Incident & Problem Mgmt process documents.
The SLM should manage the review of SLAs, and report on breaches, which would then be discussed with the customer within the Service Review meetings.
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Tue Jul 07, 2009 3:20 am Post subject:
The answer is it depends on the contract / SL Agreemnt made with the customer
If the SLA is set to a 24 hours clock and you provide a 8 hour service (9a mto 5 pm), then you're screwed always. The people who signed the SLA from your company should be taken out, beaten up, down, charm and strange (quarks u know). and sent out to re-negotiate the SLA in line with the service provided
You have to clear all your tickets before the end of your day... Even ones that were raised at 1659:59:59
The other issue is what is the criteria of the SLA -
solve the issue or
respond to the ticket
if it is respond to the ticket, then as long as the activity shows that the SD has escalated to the right group w/in a time frame then you are OK
If the SLA and service are set to the same clock, then if a ticket is raised at 1600, then the next morning at 1000m, the ticket is 2 hours old. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
The context here is that we are very much in initial stage of SLA based support rollout, and a pattern observed is that many of the tickets are missing their SLAs. Have any come across this while moving to SLA based support model ?
Whats are the possible approaches here to move ahead with corrective actions ?
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Wed Jul 08, 2009 7:37 pm Post subject:
randonrings,
Analysis is the key here.
Were the SLAs based on analysis of incident resolution, or on identified customer requirement - or perceived customer requirement or perceived reasonableness?
If customer requirement is real (i.e. there is real customer detriment if services are unavailable/unduly slow for longer than a certain time) then this can only apply to incidents that have significant effect on service - so, are your SLAs selective about what incidents are critical?
Also, if customer requirement is real, has the cost of meeting the requirement been measured and appropriate resources put in place?
Are SLAs set against individual incidents (this is disastrous) or against averages or percentages over time - based on analysis of what is achievable?
Are you analysing the incident management process to determine whether the over-runs are due to the learning process (and therefore should go away very soon), the nature of the process (and therefore you need to improve the process), the nature of the incidents (and therefore you either need more resources or more time)?
One perspective you must obtain is a measure of the cost to the business of these breaches.
If they are "paper" breaches that have little effect on the business then you do not want to waste inordinate time bureaucratically administering an SLA regime that has unnecessary strictures.
If there is considerable cost to the business then you need to look at the cost of improvement to your incident management regardless whether it is more training, additional rersources or improved process. _________________ "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