Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Fri Apr 28, 2006 5:53 am Post subject: SLA measurement
Hi,
I have a problem with SLA measurement. In my company we have different SLAs (time to fix) for desktop service (SLA1) and SAP(SLA2).
If an user is opening an INCIDENT and our Servicedesk assigns this Incident to the desktop service, the counter for SLA measurement starts with 0 and counts on SLA1 base. Now the second level founds out, this problem is a SAP based problem not a desktop service base problem. Second level will change the assignment to SAP. In case of SLA, does the counter starts by 0 and counts on SLA2 base ? Or do we have to add the time from the desktop service group add to the SAP group, so that they not start by 0 ?
Does anybody has a good idea to solve this problem ?
Joined: Nov 01, 2004 Posts: 83 Location: Sask, Canada
Posted: Fri Apr 28, 2006 8:58 am Post subject: outside suggestion
I just can't resist, even though I don't know the impact of the counter values to your company..
There are often incidents that are called into the wrong help desk, or dispatched to the wrong group for a variety of reasons. That will probably not change.
From your description, I am assuming some kind of automated counter. If you can have one counter for SLA measurement, why not have 2? Create a counter to hold counts from transfered incidents, or an indicator that says the incident was transfered from another SLA. you will have the time count for the group that got it, plus the time count for the time it spent in the wrong queue. Add the 2 together for the 'Gross', and get brownie points for having identified mis-dispatched incidents as a problem, and work towards getting that one resolved.
Does that spark any ideas? interesting problem
/Sharon
If you look this from your customer point of view, he is not bothered about your time counters.He will look into the SLA which you agreed upon.So in this scenario if the problem is with the SAP then SLA2 should be applicable. My suggestion is once you change the Incident from SLA1 to SLA2,deduct the time spent on SLA1 (diagonosis) from SLA2 and then start the time counter. Ex if resolution time in SAL2 is 2 hours and you have already spent 1 hour on SLA1 then the time counter should show 1 hour as resolution time for SLA2 in this case.
In this way you will not breach the SLA agreed with customer.
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Fri Apr 28, 2006 4:45 pm Post subject:
rajk wrote:
If you look this from your customer point of view, he is not bothered about your time counters.He will look into the SLA which you agreed upon.
From the Customers point of view - If you cannot decide quickly upon what the problem is then he/she sees you as delinquent or useles or both. These are positions to be avoided, hence rajk 's point of view that you should deduct diagnosis time and therefore make yourself look better.
In reality, isn't it better to bite the bullet, acknowledge that you have problems with diagnosis and invest in more training, rather than hide the problem?
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Fri Apr 28, 2006 5:58 pm Post subject:
An incident is detected - it is given an initial classification. Somewhere in the investigation stage it is discovered the classification is wrong, so it is reclassified and sent to different support staff. This a normal and expected event in incident management.
It is, however, still the same incident. The time spent resolving that incident is a totally objective measurement, changing the record details does not in any way alter the time that elapses from detection to resolution.
You should only have one timer - which increments from detection to resolution. The SLA measurement is a measurement of, and response to the 'clock's' value. When you switch SLAs is should never adjust the clock. To extend the metaphor the SLA is when you have set your 'alarm', not your time. Changing SLAs should be the same as resetting the alarm on a clock - never the time.
And to thoroughly strangle the metaphor - you would change your clock if you switched time zones - but getting the wrong classification in the intial detection is not being in a different time zone, it's just thinking incorrectly that you are. Big difference.
Or from a customer perspective, imaging showing up hours late for an interview in New York, and then saying, "No I'm not late, I'm on LA time." How would that go down
Posted: Wed May 17, 2006 4:45 pm Post subject: react and resolution
I agree you should have one counter.
To mitigate the level of misassigned requests you can introduce a react/pickup time limit for resolver groups. Let say they have half an hour to react after they have a request assigned by Service Desk (and then they still have e.g. 3.5h to fix the problem). In most cases if engineer takes a glance at a request he can state whether it should be assigned to his group or not. (if not) Then, depend on your processes he can assign the request back to Service Desk or to proper group.
You can set a function of an engineer who will be watching incoming request, confirm they are in proper group (within react time) and assign an engineer to fix it.
Of course it doesn't eliminate this problem, but it helps.
Either way the customer should assume that your organisation is good enough to address requests correctly.
I wouldn't suggest resetting the clock. What you should do is use the time for the incident as the sum of both. That way you can report on how much time is being used for wrongly classified incidents. Using this, you can baseline the effectiveness of service desk's ability correctly classify an incident. Hopefully it will get improve.
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Thu Jun 22, 2006 10:07 am Post subject:
WRT:
Quote:
I wouldn't suggest resetting the clock. What you should do is use the time for the incident as the sum of both. That way you can report on how much time is being used for wrongly classified incidents. Using this, you can baseline the effectiveness of service desk's ability correctly classify an incident. Hopefully it will get improve.
Take care: Appart from the S.M.A.R.T. rule an equally important principle in metrics is that they should not encourage 'perverse' responses. That is based on the fact that behaviour changes because of measurement. So you look at a scenario like the one described here and think, OK, we can address that by applying this kid of measure and analysing the outcome. But when you apply the measurement the scenario changes, so you aren't actually measuring the situation you intended to.
Reclassification is a normal aspect of the incident management process. Lower reclassification rates indicate that you are utilising knowledge managment at a satisfactory level. But remeber in incident management the assumption is that the cause (error) is unknown, and that a workaround is the top priority, not identifying the root cause, which is the responsibility of problem management. Problem management develops the knowledge-base componenets of the incident management process.
Reclassification rates are actually a measurement of how well you problem management processes are supporting your service desk during incident management.
Measuring the effectiveness of one process and using it as an assessment of another, is a perfect recipe for generating 'perverse' behaviour.
I would also recommend to anyone considering using this metric, you should have audit trails on the classification fields, and assignement fields, and all audit trails should be time stamped. So to reset the resolution clock and add values up at the end is a clumsy solution - reporting will be complicated to as you could end up without a single field with a TTR value for each record. Talk to whomever writes your reports about that .
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
