We are just trying to understand the OOTB integration between SLM 7.1 and Incident Management 7.0.03.007, with the added feature that customer requests come in from Kinetic Request through the HPD:IncidentInterface_Create form. We have a global customer company, but all support staff including the helpdesk are contained in 24 operational companies. All of the SLAs I have built so far (24 in six agreements - Response and Resolution for each Priority level, for all Service Types except Infrastructure Event) operate on the main customer company ONLY.
What was throwing us was that the Response flag and Responded field on the Incident form were No/NULL on Kinetic requests, which have a Reported Source of "Web," and have not been changed by advancing the ticket in the Process Flow Status bar to Resolution and Recovery (shouldn't they be, or is this not automated?), so even if you worked on them they were busting response goals. Conversely, the fields appeared as Yes/Reported Date on Incidents created by support staff directly in the console (with Reported Source = NULL), which sort of negates the entire value of a Responded SLA. Of course, a response time of 0 seconds looks real good for your stats... Looking at William's response I guess my helpdesk staff can control this by what they set in the Reported Source field - a good job for their templates and decision trees. Milestones? They are being created again today; when I did a "by file" application of Patch 002 to ARS 7.1 last month they stopped, and when I ran the Patch 002 installer instead of replacing files they started again. I was seeing some sort of an obtuse java error in a new log file that I am not familiar with - arjavaplugin.log; it is riddled with errors on all of my installations - exactly what I expect from java. On this server it was clean until the hand-installed patch, and now is clean again. How that would break it, I don't know. I do not know if is an exclusive log to SLM or not - anybody? Notifications? So far we aren't seeing any notifications that SLAs are about to be missed coming from this system; I don't see them in the outgoing mail. I do see escalation messages, but those are not from SLM. All of the Service Targets used the OOTB templates for milestones. Have I missed a new knob that I need to turn to activate them? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of LisaD > Sent: Friday, March 14, 2008 3:46 PM > To: [email protected] > Subject: Re: Track time on how long the ticket was on a group's queue > > We had to build this exact same thing for a custom > application in the past. > We created a form that captured all changes in status by > assigned group, which worked like this: > Time Capture Record is created on first assignment of ticket > and logs Group, Person, Start Date/Time assigned, status, > ticket#, etc. > Time Capture Record is updated on assignment change, and logs > the End Date/Time, and creates a new Time Capture Record > using the End Date Time of the previous record as the Start Date/Time. > > You get the picture..... then I reported on this form using > Crystal Reports and I translated the Date/Timestamps into DD/HH/MM > > What isn't working with yours? I may be able to assist. > > > Rocky - wrote: > > > > I agree with you guys but I don't want to mess with that > for now :) > > Well technically we are open 24/7 including holidays so I > don't really > > have to worry about that for now and we do have a field on the form > > where the tech can input the time they spent on the ticket. > > > > Thanks, > > Rocky > > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) > > [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 > > CS/SCCE > > Sent: Wednesday, March 12, 2008 7:15 AM > > To: [email protected] > > Subject: Re: Track time on how long the ticket was on a > group's queue > > > > Good point...in my application I capture both--"wall clock" > time and > > business time. I've found, though, that in our environment, most > > people don't care about and/or understand the concept of business > > time, so the business time schedules aren't maintained very well. > > > > That's the catch with business time--in order for it to be of any > > value, someone must actively and aggressively maintain the > schedules > > each year and every time a new support group is created or > changed, etc. > > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) > > [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black > > Sent: Wednesday, March 12, 2008 9:10 AM > > To: [email protected] > > Subject: Re: Track time on how long the ticket was on a > group's queue > > > > Rocky, > > > > I hate to complicate things, but "wall clock time" may not be the > > right way to go. ( Maybe it is, but maybe it is not.) > > > > You may also need to consider "Business time" calculations in this > > math depending on your business needs. > > > > The classic example is this.... > > > > An issue is give to the help desk at 4:50 PM on Friday and it not > > resolved before they close that day. ( They close at 5PM and reopen > > Monday at 8AM.) Monday morning it is discovered that the > problem was > > resolved due to a network issue being resolved over the weekend and > > the issue is "Resolved" at 8:05 AM Monday. > > > > Did the ticket "stay" in the Help Desk for more than 2 days or for > > only 15 minutes? > > > > ( The same idea can apply for holiday hours too.) > > > > As long as the numbers are understood then they can be interpreted. > > But sometimes it is hard to "subtract non-working hours" after the > > fact. It can also be a challenge to identify what "business hours" > > should be applied to an incident too. The Help Desk only worked the > > ticket for 15 minutes, but the networking group spend 4 > hours fixing > > the network problem. So should the report actually show 15 > minutes or > > 4 hours and 15 minutes? > > > > You also have common conditions like the HelpDesk does not > update the > > ticket in the first 15 minutes of Monday AM. They are to > busy so they > > get to it around 4PM Monday. Again... should they be > "credited" with 7 > > hours of working on the issue? > > > > The details of how your business uses the data, and > actually operates > > will drive the value of the information obtained. > > > > -- > > Carey Matthew Black > > Remedy Skilled Professional (RSP) > > ARS = Action Request System(Remedy) > > > > Love, then teach > > Solution = People + Process + Tools > > Fast, Accurate, Cheap.... Pick two. > > > > > > > >> > -----Original Message----- > >> > From: Action Request System discussion list(ARSList) > > >> [mailto:[EMAIL PROTECTED] On Behalf Of Rocky - > Sent: Monday, > >> March 10, 2008 10:29 AM > To: [email protected] > > Subject: Track > >> time on how long the ticket was on a group's queue > > Please > >> help... This is for a custom application and I need to be > > able > >> to > >> > track how long the ticket is sitting on a groups queue in > > >> days:hours:mins > before it gets re-assigned or resolved. > I tried > >> creating a new > > form > >> > that > >> > supposedly will track the assigned time and reassigned > time and I > > just > >> > can't > >> > get it to work. > >> > > >> > Thanks, > >> > Rocky > > > > > ______________________________________________________________________ > > __ > > _______ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum > > Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > > > > ______________________________________________________________________ > > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > > > NOTICE: This e-mail (and any attachments) may contain PRIVILEGED OR > > CONFIDENTIAL information and is intended only for the use of the > > specific > > individual(s) to whom it is addressed. It may contain information > > that is privileged and confidential under state and federal > law. This > > information may be used or disclosed only in accordance > with law, and > > you may be subject to penalties under law for improper use > or further > > disclosure of the information in this e-mail and its > attachments. If > > you have received this e-mail in error, please immediately > notify the > > person named above by reply e-mail, and then delete the > original e-mail. Thank you. > > > > > ______________________________________________________________________ > > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > > > > > > ----- > Lisa D > [EMAIL PROTECTED] > > -- > View this message in context: > http://www.nabble.com/Track-time-on-how-long-the-ticket-was-on -a-group%27s-queue-tp15950817p16055586.html > Sent from the ARS (Action Request System) mailing list > archive at Nabble.com. > > ______________________________________________________________ > _________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
