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: Thomasdes
New Today: 35
New Yesterday: 152
Overall: 130931

People Online:
Visitors: 61
Members: 3
Total: 64 .

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 - SLA measurement
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

SLA measurement

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
tom_DE
Newbie
Newbie


Joined: Apr 27, 2006
Posts: 1

PostPosted: Fri Apr 28, 2006 5:53 am    Post subject: SLA measurement Reply with quote

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 ?

merci
tom
Back to top
View user's profile
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Fri Apr 28, 2006 8:58 am    Post subject: outside suggestion Reply with quote

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 Smile
/Sharon
Back to top
View user's profile Send e-mail
rajk
Newbie
Newbie


Joined: Apr 27, 2006
Posts: 2
Location: Bangalore

PostPosted: Fri Apr 28, 2006 4:24 pm    Post subject: Reply with quote

Hi Tom,

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.

Regards
Raj
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Fri Apr 28, 2006 4:45 pm    Post subject: Reply with quote

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?

Regards

Ed
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri Apr 28, 2006 5:58 pm    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
matrejekm
Itiler


Joined: May 11, 2006
Posts: 32

PostPosted: Wed May 17, 2006 4:45 pm    Post subject: react and resolution Reply with quote

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.
Back to top
View user's profile Send e-mail
smjohnson
Newbie
Newbie


Joined: Jun 21, 2006
Posts: 1

PostPosted: Thu Jun 22, 2006 7:25 am    Post subject: Reply with 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.
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Thu Jun 22, 2006 10:07 am    Post subject: Reply with quote

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 Smile.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.