Rick, some days, you're practically poetic. Maybe we should march on Houston in protest.
J Meyer -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Monday, December 11, 2006 6:50 PM To: arslist@ARSLIST.ORG Subject: Re: BMC Support Doesn't ** Shawn, you mentioned something that flicked a switch in my mind when you were talking about the KBs as part of an ITIL process. My ITIL foundations class featured the BMC Airport Simulator, led by Mr. Atwell Williams (both of which I heartily recommend). The entire point of the simulation was to show the value of pushing resolution data as close to the source of the problem as was practical, with the goal to minimize outage times. Given that, a stronger emphasis on self-service is a natural thing that is not at odds with ITIL, but is being hamstrung by the limitations on the self-service data we're allowed to see. BMC, if you're going to make us do more work ourselves, give us the proper tools with which to do it. Open up the KB, and make it more usable, starting with your base search criteria. Why on earth can I not select "Remedy Help Desk", or "CMDB" on the full product list? If I select Service Desk, I can only select v7.0, which must be what - 2% of the installed ITSM base? How am I supposed to know how to find the KBs for the other versions? For CMDB, I can only select products associated with it - not the CMDB itself. This is indicative of the BMC folks trying to do Remedy stuff - they just aren't up to the task. To do this the half-assed way it's currently being done serves neither the customers nor the support staff well. To be honest, to really make it work right, BMC would have to get out of the way of the Remedy people who were pretty much doing it right before you came along. Rick ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn Sent: Monday, December 11, 2006 4:57 PM To: arslist@ARSLIST.ORG Subject: Re: BMC Support Doesn't ** This is one of the flaws of most early ITIL adoptions I think. While in ITIL everything is initiated and communicated through the Service Desk as front line support, that doesn't mean that it has to be an organization structure. There's no valid reason for them to limit the KBs as tightly as another person in this thread mentioned, as that would help some of these issues. Additionally, I think with better categorization of incidents, they could probably route calls such as the bug you mentioned faster. I do agree with BMC's idea of not necessarily having all calls go automatically to the most experienced techs. You don't want to waste the time of a level 2 person or an engineer with questions about how to turn on log files or create users, that would be very inefficient and probably bore them to tears and make them want to quit. The idea of having some more detailed information on support users, a detailed profile to let them know that you are experienced enough to automatically route the ticket/call to level 2 or at least some of the more advanced level 1 people is good though. There was an ITIL-related session of the pre-tutorials at the UserWorld this year where the gentleman running the session discussed setting up the equivalent of the "ten items or less" express lanes for easy problems and the normal lanes for bigger ones. Detailed user profiles based on length of time as a user on Supportweb and previous calls could probably help out in routing tickets and calls in addition to categorization. There's a lot of room for opportunity, and I hope BMC changes things for the better. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza Sent: Monday, December 11, 2006 3:38 PM To: arslist@ARSLIST.ORG Subject: Re: BMC Support Doesn't ** This is more or less what I meant. As someone who has spent so much time on these systems, chances that you raise an issue that could have been resolved by reading the manuals are much less. Chances that you raise an issue without conducting preliminary checks to see if you have done anything wrong before raising that issue are even lesser. I personally think that anyone who has worked with the ARS for more than 4 or 5 years better know basic troubleshooting to eliminate obvious causes for problems he or she is facing. Such a person is a better candidate for having an almost on demand access for tier 2 support. Some of the tickets I have created in the past, were based on genuine issues or problems that I have faced that are not documented. They were either bugs in the install script or where my install crashed out due to network errors and I had to redo application install so I needed information as to what I needed to delete from the Share Property form etc. If these installations are on UNIX system using readable scripts I even go through the exercise of viewing the script to see whats happening before I raise a ticket. A recent example is a bug I noticed on the installation of the approval server on Sun Solaris version 5.10, where there is a bug with the min version varaible that is read and interpreted by the install script. I called support after reading the script and spotting the bug just to verify the modification I intended to do on that script. How much will frontline support be able to help me with that if this bug has not been reported and documented before? They had to pass it to engineering to verify it for me.. Frontline support staff usually aren't able to give me the sort of support I need to resolve such issues. So they end up using almost as much time I might have possibly spent troubleshooting stuff myself, if not more in going through the same checks on logs etc before they ultimately reassign it to backend support when they reach at the same point I was at when I had decided to call support. Thats where I fail to see why I need to spend that much time with them when I personally know that in the end its very likely to go to backend support sooner or later.. Joe ----- Original Message ---- From: Axton <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Monday, December 11, 2006 3:58:45 PM Subject: Re: BMC Support Doesn't ** "As an RSP I should be able to see more KB, enter KB's, update KB's and have a great deal more access to info on my incidents/bugs than the average customer. I have INVESTED a great deal of time to become "certified" in this stuff and that should mean that I am a good partner for BMC to work with. ( Not that I think I should be able to skip level one, but I should be granted more of what level one has than "just another customer" has too. )" Does this mean that those of us who have not gone down this path are somehow unworthy of additional content; tickets, kb, or otherwise? I too have invested a great deal of time in learning this stuff. Seems such a thing should be driven on individual merit (tickets vs. defects, etc.) instead of a piece of paper. Axton Grams On 12/11/06, Carey Matthew Black <[EMAIL PROTECTED]> wrote: Joe, I here you. I feel that frustration. However the most experienced developers do still make "newbie" mistakes from time to time. And wasting a "experts" time trying to figure out that you really did "leave the caps lock key on" is not good for anyone. (Even if it makes the customer on the other end of the phone feel like they are getting better support.) What I would like is a better "troubleshooting map" of what Level 1 will do when I contact them. That would allow me to complete more (or all) of the "level one steps" (and check them off the list) before I open the issue with BMC. If BMC could provide a "sure fire debugging process" that would let me "skip" level one contacts because they see that "all of those things are already done" would be GREAT in my book. I also fully expect my new incident to be routed through level one, where they verify that I did cross all my t's and dotted all of my "i's", but if it is all in order then they can focus on working with the level TWO and NOT working with ME to get details about what I see in my env. My bottom line would be: If they can not reproduce it, then either I have a local issue, or I did not fully describe it. (And level one needs to work with me to figure that out.) If they can reproduce it, and are unable to explain it, then I need to speak with level two. If they can not explain it, then the docs are lacking and level two has some explaining to do. And do NOT get me started on how RSP/RAC should be factored into this stuff. As an RSP I should be able to see more KB, enter KB's, update KB's and have a great deal more access to info on my incidents/bugs than the average customer. I have INVESTED a great deal of time to become "certified" in this stuff and that should mean that I am a good partner for BMC to work with. ( Not that I think I should be able to skip level one, but I should be granted more of what level one has than "just another customer" has too. ) However, there are days that I think that I am just certifiable for being certified in the first place. :) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 12/11/06, Joe DeSouza <[EMAIL PROTECTED]> wrote: > ** > > <snip> > What I think would work is if they were to set up level based profiles of > their customers.. What I mean is usually when you have an experienced Remedy > developer or administrator calling Remedy support on some issue, they > usually call when they have covered most bases, and are still at a loss at > solving their problem. What they do not want to deal with after contacting > support is wasting about 6 hours shooting emails back and forth with basic > logs that were already looked at several times before raising some of these > issues.. > > An experienced developer or consultant would rather have liked to talk to a > back end support personnel rather than dealing with the front end. With all > due respect to newer developers or administrators of the Remedy systems, I > think it would be fair to have the backend support more accessible to > seasoned developers and administrators, while the front end support could be > more dedicated to newer or lesser experienced developers and administrators. > <snip> > > Joe D'Souza > Remedy Developer / Consultant, > BearingPoint, > Virginia. ________________________________ Want to start your own business? Learn how on Yahoo! Small Business. <http://us.rd.yahoo.com/evt=41244/*http://smallbusiness.yahoo.com/r-inde x> __20060125_______________________This posting was submitted with HTML in it___ The information in this e-mail, and any files transmitted with it, is intended for the exclusive use of the recipient(s) to which it is addressed and may contain confidential, proprietary or privileged information. If you are not an intended recipient, you have received this transmission in error and any use, review, dissemination, distribution, printing or copying of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately of the erroneous transmission by reply e-mail, immediately delete this e-mail and all electronic copies of it from your system and destroy any hard copies of it that you may have made. Thank you. __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 ARSlist:"Where the Answers Are"
