Ofcourse that does make sense! ExpertDesk has OLA's for tasks (any tasks, being Change, Incident, Problem or Operations) since at least version 4 (we're heading for release 6.7). In our implementations, we turn things around: if you don't need any OLA's (but most customers do), we define a "generic" one. So I don't think it's a wierd requirement to have OLA's for tasks, in fact it makes perfect sense to me.
Hugo On Dec 13, 2007 3:09 PM, T. Dee <[EMAIL PROTECTED]> wrote: > ** What is so frustrating for me is that this feature is not "supported" > by Remedy. > > I don't understand who someone can have Change and not use SLAs for > "Tasks". > > Each Task(s) of Change have different timelines that they have to be done > within and I can't believe that most people don't track this to improve > their level of service. > > > > > On 12/12/07, Rabi Tripathi <[EMAIL PROTECTED]> wrote: > > > Funny that you guys are talking about SLAs on tasks. > > We will be building just that fairly soon (in ITSM 7). > > > > I am not sure if it's a good idea or a workable idea. > > It was not my idea. But it's going to be built. > > > > I've seen companies not want to use tasks at all, > > especially tasks that are assigned to an area outside > > of the Change's assignee's. The reason: change is at > > the mercy of tasks being completed on time. With > > change and its task(s) touching on multiple ... > > jurisdictions ...change's sla is not going to be > > meaningful or fair, in that it doesn't purely measure > > change assignee's performance. > > > > That is unless tasks themselves have SLAs (OLA is the > > more appropriate term, but the difference is trivial > > in SLM application). That's what has been requested > > this time and we will build it. But, I am not sure how > > it's going to work in practice. > > > > As I see it, slas have two purposes. One is > > operational...try to get things done on time, by > > setting clear goals & expectations, alerting parties > > etc before and after etc. > > > > Second one is longer term...trend analysis, which can > > provide feedback on organization's and process's > > performance and aid with streamlining, refining for > > better performance in future. > > > > First one...I can see happening by simply having slas > > defined on tasks. > > > > However, defining tasks' slas (or OLAs) will be > > trickier than for change. Tasks' schedule is at the > > mercy of change's. Timing-wise, I can not yet see what > > kind of slas will make sense on tasks. Change and its > > tasks are intertwined at more than one points...in > > terms of timing of planning, implementation etc. > > > > Second one...performance analysis thru historic > > reporting...it can be done on tasks...but if the goal > > of having slas on tasks is to measure change's > > performance more accurately by accounting for task's > > performance... > > ...I am not sure how tasks' contribution (or lack of > > it) to change's sla performance can be > > added/subtracted so that change's (or change > > assignee's) performance is isolated and measured...in > > cases there were tasks done by parties other than > > change's assignee. If there were tasks assigned both > > within and outside change's assigned area, it gets > > complicated. You can get overall performance of IT > > organization, but not groups. > > > > Well, it's going to be built, so I will update you > > guys later about the mechanics of building it. > > Conceptually, architecturally it's fairly simple. > > > > I am talking somewhat abstractly here. I have to warn > > you that in the past when I have done that it has > > sometimes turned out that I was talking non-sense...or > > that I was doing pointless analysis.:) On this front > > as well, I can update you guys...as to how well the > > goals (which I am not completely clear on yet) are > > met. > > > > > > --- "Lammey, Peter A." < [EMAIL PROTECTED]> > > wrote: > > > > > It starting to sound like an OLA may make more sense > > > to apply with the > > > Tasks. > > > Since tasks are needed for the success of a Change > > > Request that is > > > managed by another group internal to IT then OLAs > > > should be measured > > > against the tasks. Not necessarily customer facing > > > SLAs. > > > > > > > > > > > > Thanks > > > Peter Lammey > > > ESPN MIT Technical Services & Applications > > > Management > > > 860-766-4761 > > > > > > > > > > > > ________________________________ > > > > > > From: Action Request System discussion list(ARSList) > > __20060125_______________________This posting was submitted with HTML in > > it___ > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
