Adrian Cronauer was right....

AC - "We've got a special man in the audience today right now. It's Mr.
Leo. He's a fashion consultant"

LEO -"Thank you, i'm just very happy to be here. I want to tell you
something."

AC - "What's that?"

LEO - "You know, this whole camouflage thing, for me, doesn't work really
well."

AC - "Why is that?"

LEO - "Because if you go in the jungle, I can't see you. You know, it's
like wearing stripes and plaid. For me, I want to do something different.
You go in the jungle, make a statement. If you're going to fight, clash.
You know what I mean?"

Similarly - if there is a protest, protest with some style: wear a hazmat
suit. It's catchy. It's what's in style from Paris this fall. Nothing says
that something stinks like a six foot, rubber, yellow banana walking
around. Hey, they even come in different colors! Blue. Yellow. Green. Buy
one! Buy two! Accessorize your wardrobe: Get the matching black boots and
gloves. A roll of duct tape is free with compliments of management on the
sale of accessories.

Then, after the party, head on over to Claire's place for the BBQ and a
chance to set the respirator pack down...



On Tue, December 12, 2006 10:26 am, Sanford, Claire wrote:
> If you do, the party is at my house!  I live about 15 mins from
> "HomeBase"!
>
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Meyer, Jennifer
> Sent: Tuesday, December 12, 2006 8:42 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: BMC Support Doesn't
>
>
> 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"
>
> _________________________________________________________________________
> ______
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> the Answers Are"
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

Reply via email to