Conference ilbbak::us_sales_service

174.0. "How can 'reps' be made aware of Product Dependency info" by SMAUG::GARROD (From VMS -> NT; Unix a mere page from history) Wed Dec 16 1992 14:02

    I'm in NAC engineering and we're trying VERY HARD to make our products easy
    to order/configure but the systems aren't helping us. I'd like to share
    an example of what's happening and ask for feedback on which of the
    following solutions would be easiest for the sales reps.
    
    All of the people I've dealt with in DSPS, AQS and SLC have been very
    helpful but I'm still not sure what the right answer is so I thought
    I'd pose my questions to those of you on the front line.
    
    I was initially led to believe that SLC (Software License Configurator)
    was really smart and could handle software dependencies and working
    out the correct H kits to go with the QL part numbers. It was explained
    to me that AQS itself was deliberately dumb. Ie it was designed to be
    a system that you gave it a part number and it gave you a price.
    Configuration etc was handled by tools on top of AQS (SLC). After
    talking to the SLC program manager I'm told that SLC is not smart at
    all and certainly can't deal with a QL part number with a UPI of x
    needing a QA part number with a UPI of y. It also can't be made to tell
    sales reps that product x requires product y ie handle dependency
    information. This surprised me.
    
    So all you out there that quote, what tool do you use to work out
    dependencies and relationships between QL and QA part numbers?
    
    Also what has happened to XSEL. I was told by the person at AQS that
    SLC was really a replacement for XSEL. The person at SLC says he wasn't
    aware of this if that was the case. So does XSEL still exist? If so
    how do us product creators get rules of software configuration loaded
    into it for our products?
    
    Do you use SLC or XSEL for configuring software licenses and H kits?
    
    I attach the message I sent explaining our problem. With the reply I've
    got from the SLC program manager it looks like my option a) is not
    possible. I've removed names from the message
    
    Should we do option b) or option c) then. What's easiest for you. I've
    had several reps tell me they don't want to go looking at SPDs. If that
    is the case how do I get the sales tools to do the right thing and
    correctly configure quotes?
    
    Dave

From:	SMAUG::GARROD       "An Englishman's mind works best when it is almost too late" 15-DEC-1992 15:56:14.74
CC:	GARROD
Subj:	Question on how to handle H kit with different UPI to License

xxxx,

I'm in the Networks and Communications Group and we have just submitted
a couple of new products to the price book etc. Sales reps are having
difficulty configuring orders and I was given your name by zzz
in AQS as someone that should be able to help us. Ie make a recommendation
as to what way we should go. Let me describe the problem:

We have 2 products:

    a) 3270 Application Services Development ( UPI is MKJ)
    a) 3270 Application Services Run Time ( UPI is MKK)

The H kit (QA-*****-**) is the same for both of the above. At the moment
it has the part number QA-MKJAA-**. When salesreps come to configure quotes
for a) above using SLC all works fine. They go for the license and SLC
gives them the relevent H kit number.

The problem is that if they are ordering an MKK license SLC will give a
message something like:

    "can't configure media - refer to SPD"

or something like this. This isn't surprising because I presume by default
it looks for a part number of the form QA-MKKAA-** which doesn't exist.
Then of course they call RSS and or us. We have three possible suggested
solutions. I would like to understand your recommendation as to the best 
solution:

    a) Tell SLC that the H kit that goes with MKK licenses has a MKJ part
       number.

    b) Be clear in the SPD that the H kit that goes with the MKK license has
       an MKJ part number.

    c) Create a whole new QA-MKKAA-** part number that ends up shipping exactly
       the same tape as the QA-MKJAA-** part number.

Is a) the sort of thing that SLC is designed to handle. If so how do we go
about (ie what forms / submission process do we have to use ) to educate SLC
about the relationship between MKJ and MKK. I don't like b) only as an answer
because then it means SLC has been unable to completely configure a quote
for AQS.

a) seems like a better answer than c) to me. Do you agree? c) to me seems like
a kludge or workaround. But my question is, is a) feasible?

Next question I have is does SLC handle product dependencies. We have another
product UPI = 06C that is dependent upon MKK. Ie if a sales rep orders 06C
he must order an equivalent amount of license units for MKK. Is this something
SLC deals with? If so how do we feed this information into the system? We have
already had several salesreps who have ordered 06C but not ordered MKK and I've
had to provide temporary PAKs with expiration dates for MKK.

By the way I'm the engineering manager for the products referred to above.
I'm working with the product manager (yyy) who is out at present.
Any information you could send us would be most appreciated.

Thanks,

Dave
    

Hi Dave -

     I'm the developer for the Software License Configurator and
     I see no reason why we can't go with your "A" solution to
     the H-kit dilemma.  If you can provide me with UPIs that
     have a different UPI for the H-kit, I can add this to one
     of the SLC's supporting files.  The SLC would then read the
     file when it sees MKK (or whatever) and configure the H-kit 
     using the correct UPI (MKJ).  If you can provide me with a
     source to give me the information to update a table, I can
     add this functionality to the SLC.

     We could also display an informational message about product
     dependencies, if once again, I have the mapping information.
     We used to have a source for this, but the group was disbanded
     and we haven't found another source.

     I'd like to include this functionality in our next release,
     which is due to be released in mid-January.  If you'd like to
     talk to me further about this, please give me a call tomorrow
     at DTN 385-2557 or send me some mail.

     Thanks,
     Bonnie

	I hate to say this but I'm not sure we know what the SLC is ?
	Point me to more information.

	Our account team runs hundreds of quotes each month for one
	of Digital's largest CSOs.  So anything you can do to help
	with dependencies would be darn nice.  Hopefully you are aware
	that dependencies also include version numbers and sometimes,
	the letter.  It's not unusualy to see product v2.3 of product
	X require v4.1C of product Y.  So you need to be sure to
	allow for this level of granularity.

	SPDs are, generally, a pain in the rear .... we know we have
	to use them for accurate UPI and ordering info.  The trouble
	is that we pull SPDs off the net very often to be sure we have
	the current info.  There's no central filing system we can
	go to anymore.

	FWIW ... gerry