> Where the RFE request goes after we hit "submit" really should not
matter to the customer.
Since support tickets can be submitted via the web and E-mail, all one
has to do is just create the support incident requesting that a given
enhancement request be submitted as an RFE. Support will do the rest.
Thus you can shoot off a request to support whenever the inspiration
hits...
> I have no problem with the "minimum" being raised to be able to submit
an RFE.
A more complicated form is available that one can fill out for RFEs that
asks more complete questions. Here are the questions we ask in that
document (examples and more explicit definitions are in the document -
I've edited those out for space here):
1. Instructions for Use
Please fill out this RFE template to the best of your ability. Why?
Because if you do (1) the Customer will have a more reliable
RFE process, (2) Account Managers will know that their RFEs are being
evaluated using consistent data, (3) Product Managers will have
more information from which to make scoping decisions, and (4)
Engineering will have a clearer idea of what needs to be implemented.
2. Information
Describe the RFE using a brief headline.
Provide a brief description for the RFE.
Pick a prototypical user (such as Clara the Customer Service Engineer).
First, describe the business problem s/he faces. Second,
describe what s/he needs the system to do for him that is new (within
the context of the existing product functionality).
How frequently will the functionality be used?
Frequently (hourly)
Often (daily)
Occasionally (weekly)
One time
Other -- please specify: __________________________________
How intensely will the functionality be used?
Many Users Concurrently
Several Users Concurrently
Few Users Concurrently
Administrator only
Other -- please specify: __________________________________
What is the technical severity of this issue? (Examples)
Severity 1 - Existing feature is unusable and no reasonable
workaround exists
Severity 2 - Existing feature is unusable but a reasonable
workaround exists
Severity 3 - Existing feature is usable as documented but does
not perform additional needed functions
Severity 4 - Improvement to existing and usable feature
Severity 5 - Cosmetic
What would be the impact on your business if this functionality were not
implemented? (Business processes can represent an application,
internal process (e.g. deploying a new server), external process (e.g.
sale of a solution) or other general goal.)
Business processes can not move forward without this enhancement
Business processes are severely impacted by this enhancement,
but continue to operate - albeit in a less than efficient manner
Business processes are moderately impacted by this enhancement.
Processes move forward at an expected but not exceptional rate
Business processes are slightly impacted by this enhancement.
Processes move forward at best possible rate, but could be
further improved with this enhancement.
No impact to existing business processes. RFE may represent a
possible future direction or enhancement to existing products
but without a definite business justification.
Other -- please specify: __________________________________
Provide additional customer expectations if they exist. This may
include revenue implications, competitive solutions, general
reaction to the current situation, etc.
In what time frame is this enhancement needed?
"There is an immediate need for this enhancement"
"This enhancement is needed in the next 3-6 months"
"This enhancement is needed in the next 6-12 months"
"This enhancement is needed in the next 12-24 months"
"This enhancement is needed in the next 12-24 months "
"There is no specific timeframe needed for this enhancement "
Thanks,
-David J. Easter
Sr. Product Manager, Service Management Business Unit
BMC Software, Inc.
The opinions, statements, and/or suggested courses of action expressed
in this E-mail do not necessarily reflect those of BMC Software, Inc.
My voluntary participation in this forum is not intended to convey a
role as a spokesperson, liaison or public relations representative for
BMC Software, Inc.
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller
Sent: Friday, April 20, 2007 3:11 PM
To: [email protected]
Subject: Re: Enhancement Request, anyone?
>I would even be interested in seeing BMC offer an ARS Server license
with enough fixed
>license for ARSList/ARSWiki to build such an application for them.
Sounds like an ideal subject for an RFE...
-Aaron
* Email: [EMAIL PROTECTED]
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Friday, April 20, 2007 5:42 PM
To: [email protected]
Subject: Re: Enhancement Request, anyone?
Rick,
Sigh... If I ruled the world.... Or more to the point...
Where the RFE request goes after we hit "submit" really should not
matter to the customer. If the request is first read by a "Level 1
support tech" where they go though it and verify that "all the needed
stuff is there" then that should be just fine to any customer. If the
request is not "quite right" then Level 1 can contact the requester and
"fix it together". However, if all the needed information is there, then
they can just "approve" it and forward it on to the Engineering team for
further review.
How much time Level 1 should spend on RFE review vs Trouble tickets...
well... that might be a different factor to add to the Support Contract
matrix. (or to let other customers help in this process...
see below.)
What is apparently absent from the discussion is what is the difference
(in data structure) between an incident and an RFE? I would bet that the
things that would be "required" are quite different between the two
requests. So if there are differences, then they should be handled with
separate forms (and/or) processes.
If 30% of the RFE's were not really RFE's then that says to me that the
data collected needs to be improved. ( For example: A customer should be
required to submit more than "a question" to create an RFE.
) I have no problem with the "minimum" being raised to be able to submit
an RFE. I would think it completely reasonable if multiple customers
(say... 5, or 50) had to all say: "Yes, I want that too"
before Level 1 OR Engineering was even bothered to go look at it.
(Just tell us what that number is. :) However that would require that
RFE's could be seen by ALL customers that own the product.
* Maybe a flag could be provided on the customer RFE submit page
that lets us publish the RFE to "all customers" and would allow it to be
"voted on". If the flag is not set then the request will be reviewed
based on the support contract effort they pay for.
* Maybe the number of votes a Support Contract has is limited and
varies based on the support level purchased.
* Maybe RFE's that are "voted on" could have more weight than the
"private RFE" requests after the vote count reaches..."x" (50 -100?)
<sarcasm>
Now where can BMC find a application development environment that could
be used to build such an application. You know, with multiple users,
required fields, row level access rights, approval processes, and
Status/life cycles. Hum...
</sarcasm>
I would even be interested in seeing BMC offer an ARS Server license
with enough fixed license for ARSList/ARSWiki to build such an
application for them. ( Provide the spec and lets see if you can get
some "open sourced" work going on such an application. Maybe the goal
could be as simple as to reproduce BUGZILLA in an ARS application. :)
They could even throw in a DSO license (or publish a web service) then a
clean interface could be defined by BMC and the user facing application
could do whatever it needs to do to meet the minimum requirement before
it is transferred to BMC. (Or customers could even host a
locked(deployable) "Customer side BMC support application" so that they
could extend it as to their own needs and BMC would get updates as the
workflow was defined by them. )
Am I nuts? Are there multiple developers out there that would volunteer
their time to build support applications so that they could be better
support from a vendor?
I know I would be willing to work a little extra so that I can get a
little extra. Especially if the work I was doing was open sourced AND
ARS based.
Please sound off and tell BMC if you think you would help on such a
project. (Assuming they would provide some resources (maybe just
licenses) to enable such a project.)
It appears to me that BMC is missing an opportunity to be responsive to
their customers and to USE their customers (and their own products) to
the fullest of BMC's advantage.
Again... If I ruled the world....
--
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 4/20/07, Rick Cook <[EMAIL PROTECTED]> wrote:
> David, while those are good points, it seems that if we as developers
> can create effective means of using Remedy to require data from our
> less-sophisticated end users that allows us to help them, then surely
> the smart folks at BMC can figure out a way to help us smart folks
> enter data that's actually helpful to them.
>
> I understand that this may be a priority/resource issue right now, but
> if/when it reaches the front burner, perhaps a meeting of the minds
> between engineering and the customers (us) would be in order, to
> ensure that the solution works well for both parties?
>
> Rick
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David
> Sent: Friday, April 20, 2007 1:11 PM
> To: [email protected]
> Subject: Re: Enhancement Request, anyone?
>
>
> > AFAIK, there is an internal effort at BMC to create and rfe
> > interface,
> but it doesn't yet exist.
>
> Actually, at this time, the plan is to continue to require a support
> rep to be involved in the process of opening an RFE. One primary
> reason is that over 30% of the RFE's opened directly by customers had
> errors of some kind (wrong product, support question vs. RFE, poorly
defined request, etc.).
> Including the support rep means the RFEs are now more correctly
> defined and can be processes much quicker than before.
>
> There are other benefits (e.g. bugs can now be converted to RFE's
> without the loss of tracking, customer incidents are linked to the
> RFE,
> etc.)
>
> While I'm not discounting the possibility that customers may be able
> to enter their own RFE's again in the future, there's AFAIK no
> internal effort to re-create that interface.
>
> Thanks,
>
> -David J. Easter
> Sr. Product Manager, Service Management Business Unit BMC Software,
Inc.
>
> The opinions, statements, and/or suggested courses of action expressed
> in this E-mail do not necessarily reflect those of BMC Software, Inc.
> My voluntary participation in this forum is not intended to convey a
> role as a spokesperson, liaison or public relations representative for
> BMC Software, Inc.
<snip>
> > From: Action Request System discussion list(ARSList)
> > [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller
> > Sent: Friday, April 20, 2007 12:42 PM
> > To: [email protected]
> > Subject: Enhancement Request, anyone?
> >
> >
> > **
> > Didn't there used to be a link on the support website to submit an
> > enhancement request?
> > Either it's just my Friday fog, or it's no longer there...
> >
> >
> > -Aaron
> >
> > * Email: [EMAIL PROTECTED]
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
SunCom is the wireless company that's committed to doing things
differently.
Things we want you to know.
This e-mail and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to whom they are
addressed. This communication may contain material protected by the
attorney-client privilege. If you are not the intended recipient or the
person responsible for delivering the e-mail to the intended recipient,
be advised that you have received this e-mail in error and that any use,
dissemination, forwarding, printing or copying of this e-mail is
strictly prohibited.
________________________________________________________________________
_______
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"
