Conference 7.286::digital

    Your note leads me to believe that this business plan is not
    well thought out.  If this is a material aspect of the plan I
    would suggest a detailed investigation and analysis.  Whatever 
    answer you develop in 2 days will be incomplete.
    
    The benefit of the "serivce feature" depends a lot on what that
    service feature is designed to deliver.
    
    For example, there is very good information that indicates having
    on-site error analysis for a device eliminates the need for diagnosis.
    How benefical this is depends on the complexity of the device.  For
    a VAX9000 you may have just saved Digital 4 hours of time that would
    have normally been spent in diagnosis.  Whereas a less complex machine
    perhaps you've only saved yourself 15 minutes.
    
    Another thing to consider is that sometimes the absence of a service
    feature can be catastrophic as was the case recently with one of
    the SCSI cab offerings from Digital.  There was no way physically
    to tell what drive failed.  Finally a microcode workaround was
    implemented that would lite the fault on the failing drive.
    
    I'd also suggest looking at service features as not just cost
    containment but also as a product differentiator.  For example,
    bad block detection and revectoring on DSA disk drives not only
    provides a pro-active indication of failure but it guarantees 
    higher availability of data.  This 'service feature' made
    Digital disk more salable.    
    
    On the other hand if everything is throw away, then all you need 
    for service features is some way to know when it's broke so that 
    you can trash it and get another.
    
    Without understanding the service environment, it's hard to say
    what value a particular service feature has.
    
    Hope this helps.  Good luck.  At least you're asking!  I can give
    you other examples of service features/strategies if you need.  The
    problem is that the target is moving on us rapidly and what may have
    been a good idea in the past won't fly in the future.
    
    It looks like the most needed service features (or the most asked for)
    are those that deal with configuration and revision management.  These
    features allow a user to pre plan things like upgrades and also allows
    them to keep up to date with patches and the like. 
    
    Russ
      
    
    
            

    re: .0
    
    We've crossed paths before in terms of solving product problems.
    
    Digital is an 'over the wall' engineering company.  Built to spec,
    throw out the door, and then go on to next project.  Over
    compartmentalized.
    
    I would go OUTSIDE of engineering, look at calls logged by CSC.  Count
    them and take a look at them versus product and you'll get an idea of
    the quality of product.
    
    For example, the DECserver line documentation explains various SLIP
    features....yet nowhere in the guides does it explain all the pieces,
    parts (i.e. modem connect, signal issues, security, etc.) in one
    step-by step process for setup.
    
    The DECnet/OSI initial implementation did *not* explain that you needed
    to define a logical for MOP to successfully download any DECserver/LAVC
    members etc.
    
    The shipping version of VTX requires a special procedure to be followed
    to unpack/use the MS-DOS components - you MUST have a manual to unpack
    and use it, there is no brief HELP.TXT file with the 3 sentences needed
    to unpack/use the product.
    
    The initial ordering for the Gigaswitch did not say if it did or did
    not come with a power supply. Power supplies were separately orderable
    so some customers ordered 2 extra by mistake.
    
    The DECnis product does not adequately document slot usage, many times
    customers order ones which cannot be used.
    
    The DEChub900 series has no adequate power consumption documentation,
    it is perfectly easy to order a hub that will be totally nonfunctional
    because of inadequately documented power requirements.
    
    Servicibility begins with engineering asking the questions:
    
      - Could somebody with no knowledge of this product successfully
        use it given the product design and documentation?
    
      - Does the design and documentation lead the user to discover how
        to fully utilize all of the features and functionality to the
        maximum advantage.
    
      - Does all of our work make this an easy-to-use product with
        MINIMAL in-depth product knowledge.
    
    Ask those questions - and get data from the CSC.  You will build better
    products.
    
    j
    

    	If you want an example of a product that really hurt us and
    continues to do so due to lack of serviceability features, look the 
    DECserver 90L+ (DSRVG):
    
    	- No facility to write a crash dump to a host.
    
    	- No console mode (ODT) hardware debugger.
    
    	- No loadable/ eraseable code- requires h/w ROM replacement.
    
    	- No TSM command file support until 3 years after the product
    shipped. 
    
    	- A management interface completely different than any other
    DECserver product we've ever built.
    
    	- Introduction of DEChub management bus support into new builds
    with no notice to the Field that this new feature is required to enable
    autodiscovery of the unit by DECagent 90/ DEChub900 management agents.
    
    	Other than that, what a great product. I'd like to see the
    cumulative labor expense of dealing with the above.
    
    	I concur with Jon in .2- ask the CSCs for call data to get a true
    reading on the hidden costs.
    
    Phil
    	 

    In the early 80's, a Fortran program called LCBM (Life Cylce Business
    Model) was developed to allow service to do exactly  what  you want.
    It was developed by the old Management Science group. It takes inputs
    such as reliability, MTTR, MTBF, MTTPR and develops a life cycle cost.
    
    I believe that the Mgmt Science group may have been disbanded.
    
    Gim
    
    
     
    

    RE .4:
    
    Yes, the Management Sciences Consulting Group was disbanded in
    December, 1992.  R.I.P.
    
    
    

    The base noter may not be trying to build a better serviceable
    product/get service costs down. He may be looking at selling
    serviceability expertise. The key argument to a potential taker of
    this type of consulting would be that it pays off in lower service
    cost/faster repair times.
    
    Al