At least someone agrees with me :-) Now for the big one million dollar question is how in ITSM 7 to create OLAs for Change Tasks using SLM.
Anyone out there done this? Thank you!!!!!!!!!!!!!!! On 12/13/07, Hugo Visser <[EMAIL PROTECTED]> wrote: > > ** 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___ > > > > > __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"
