Conference 7.286::digital

    
    You have to understand that support that a customer isn't paying
    for (directly!) probably is too costly for our company to support.
    
    I see plans that require all kinds of training to support future
    business, but our districts cannot afford to pay for that training.
    
    I guess we'll have to hope that there will always be a core of
    people who are willing to study on there own time, buy books from
    a computer book store, and even buy there own systems to bring in
    to work to learn how to provide that support.
    
    I know there are many out there now, I talk to some of them in
    Internal Support, in CXO and ALF.  This was a company that one 
    could go the extra mile for, just because.  Will it be so in
    the future?  Beats me.  
    
    Remember one fundamental quality principle - The further a problem
    gets, the more expensive it gets.  I have a hunch that someone
    in this company feels that Digital can no longer afford to manufacture
    and sell products that require the level of support ours have 
    always had.  The only entity that should require support is the
    CUSTOMER.  And they should be happy to have someone fix THEIR
    problems, at a reasonable fee.
    
    I know its sounds unrealistic, but think about it.  Called any
    (900) numbers lately?
    
    Dennis
    

	Support is broken, broken, broken in this company.

	It stems, I believe, from the mistaken assumption made
	years ago that support should be a function of Field
	Service, rather than the product group that produces
	the hardware or software.

	Since engineering ( software and hardware ) can keep
	support folks at arms length ( "Shut up and read the
	Blitz", "Don't talk to me unless you have a CLD number",
	"Notes is not an official problem resolution channel", etc. ),
	support is left twisting, slowly, slowly in the wind.

	Much of this could be resolved if engineering paid all
	costs of support of their products.  Then, when they
	rolled up all those beautiful balance sheets each quarter,
	the turkeys and the disasters would be revealed.

	As it stands, Field Service absorbs the costs of 
	engineering sloppiness and ineptitude.

	Do I think this will change ? 

	No.  Our "consensus" driven company will allow this
	travesty to continue until we are a tiny outfit in an
	old wool mill, making chips and boards, again.

	Steve H

    
     re,.2  I'm in Engineering, I helped design some of those hardware
    products requiring support later, and I suppose we have to plead
    guilty.  But in mitigation, realize what the cycle is in hardware
    design.  In the ramp-up phase, we are performance/time-to-market/
    unit cost/driven.  If we see something that may be a service
    problem, we ask CSSE about it, and try to fit it in when we can.
    But if the project doesn't get to protos in time, it gets cancelled.
    
     At proto-build, the project reaches peak of staffing, funding,
    interest, top-people's attention, and activity.  Once the proto
    works, the rewards (if any merit them) are distributed, and the
    top people move on to the next project, the staffing falls, and
    the project limps slowly into FRS, at which point less than half
    the original funds/staff are still on it.  Any manufacturing,
    reliability, other service problems are handled by the 'B' team.
    I know, I've been on it.
    
     After FRS, it falls from interest, and from the engineering
    budget very rapidly.  Alpha AXP ?  Why are we still doing
    engineering on that, the hardware engineering manager asks.
    We should move the performers from that to the next system,
    and the non-performers out the door.
    
     So by the time the customer reports a field problem, the
    design team is usually gone.  This is not new - DEC was this
    way when it was very profitable also.
    

    
    re: .2
    
    Steve,
    
    	I think there are issues with service delivery's roles with support
    as well. Engineering's response will be better if the escalation path
    from the Field to Engineering is better defined and more efficient. The
    person providing a service is also providing a level of support in many
    cases. How good are our feedback mechanisms from the local Field level
    to corporate Engineering?
    
    - Jim K

    I agree that engineering should have to fund support of their products.
    From the engineering side we see the problem slightly differently
    though. We don't get to see all that SPS revenue from maintenance
    contracts on the P&Ls. This in the past has tended to cause engineering
    to short change the building of fully functional support teams. This is
    because support funding and development funding come from the same pot
    so guess where the cuts take place. If there was a defined pot for
    support this wouldn't happen.
    
    Dave

    seems to me that since most customers are loathe to pay us for the
    value of the support they desire but are quick to demand a higher level
    of support from DEC than anyone else they purchase from we are in a
    losing proposition.  The trick is to educate the customer and that is
    impossible to do, along the lines of teaching a pig to sing.

    Some customers know the value of support, they have been educated by
    making the wrong decision in the past and paying dearly for it.  But my
    experience is that they are a small minority.  Many customers talk
    about wanting to get good support and say they are willing to pay for
    it, but in the final analysis they wait till the end of the qtr and hit
    the sales person with some story about buying from a small vendor who
    would be lucky to be able to provide a little support never mind what
    the customer needs and the DEC rep ends up giving the customer a big
    allowance.  So no money is there to provide the support the customer
    thinks they are going to get.

    
    There are two forms of support.  One is supporting the products
    you sell (bugs, crashes, design faults, etc).  The other is
    technical support of the customer when they either don't know
    how to do something that they want to do, or when they enter
    uncharted territory with your products.
    
    Digital (as most companies) cannot afford the first, at the field
    level - too costly, because a customer shouldn't have to pay for
    our mistakes (although now they really do).  The second they
    should pay for, willingly, even if the SPD "doesn't say I can't
    do this", even if they're a "big customer".
    
    The "trick" is proper marketing of support services.  Nothing
    ever given away, but an army attacks the problem, if need be.
    We have given away far too much, to far too many, for far too long.
    
    dennis
    

    Support in DEC stinks and is getting worse!! As was stated in another
    note, after FRS it's just about everyman for himself...I do have ONE
    exception to that one.. Being involved before and after FRS on the 9XXX
    machines, I must say that these were the most dedicated engineers I
    have ever worked with in Digital!!! I was able to get hold of them at
    any time before and after FRS.. They never gave me the standard "log a
    CLD or Where did you get my number?" garbage that I have ALWAYS seen
    from Digital's prima donna engineering groups.. Now this is not to say
    that all of the people in engineering are this way... Ninety Five (95%)
    are though and that is what my generalzation is based on.. I am now
    presently working an LOR issue at a Major site. It has taken countless
    hours just to get a resource from engineering and when I do it will
    only be for 1-2 days... I am fortunate to have some real GOOD people in
    our Area support that can help us with this stuff.. Although they are
    overwhelmed alot also.. Our customers see this and I'm tired of having
    to go to Customer meetings to explain why CLD's are open for such long
    lengths of times.. Not on intermittent problems but ones that can be
    RE-PRODUCED..
    
    Joe
        

	First, there are two types of support:

	1) Remedial ( we fix our broken junk....Did I mention
			the recently-released product that had 200+
			oustanding QARs on it when it shipped ? )

	2) "How do I do <something> ?"  ( Note that some percentage
				of this support would be unnecessary
				with better-written manuals, but no
				manual can prevent dumb-bunny mistakes. )

	I believe it could work kinda like auto manufacturers
	handle their warranty claims.  Manufacturing defects, ECOs,
	and product failures are paid for by the car division that
	manufactures the product.  But if you want extras installed,
	tune-ups, or a different color, the dealer bills the customer.

	It's interesting to note the following from Jerry Pournelle,
	columnist, in BYTE Magazine, January 1993:

			--------------------------------

	"Microsoft has brought out a daring new product line -- at a time
	 when dealer and customer dissatisfaction with the cost and 
	 level of Microsoft support is at an all-time high.  If they 
	 can't support what they have, how can they take on all these
	 bold new products ?

	 Microsoft is aware of the problem, of course.  I was told that
	 one of four Microsoft employees now works in support services.
	 ( Cynics will say. "Yes, and they're all new employees who can
	 barely look things up in a database.")  There's also a bold 
	 new strategy: support costs are billed back against the
	 product manager's profits.  This gives the product managers a
	 strong incentive to make things work the first time."

			---------------------------------

	I rest my case.

	Steve H

    From a sales perspective, the critical problem support has never been
    good.  I have scars from several critical situations that took weeks or
    even months of finger-pointing to resolve.
    
    In the mid-80's we started saying we were an alternative to IBM, and
    actually started making some in-roads to a lot of MIS organizations,
    when our main strength had always been with end-users.
    
    Our momentum was high, the message was strong (one operating system
    from desktop to data center).  What happened?  Those MIS managers
    started seeing flaws in our support structure, and comparing us to the
    mainframe people.  We didn't know how to properly handle the
    inter-personal relations with a frustrated customer; we didn't know how
    to deliver full-strength support; we weren't as good as IBM and others
    at "doing the PR".  
    
    Our technical support people saw no value in responding to site with a
    whole team of people to work with the customer; they never understood
    that to some extent "perception is reality" with a customer.
    
    More damaging, the field support folks had to charge through minefields
    and past machine-gun nests to get Engineering people to pay attention.
    
    MIS lost interest.
    
    The core problem is that we've always been an engineering company (I
    speak as a former engineer).  Designing products is what excites
    engineers and their managers, not supporting products.
    
    Until metrics drive proper behavior for those engineering managers, we
    are trying to swim upstream while wearing concrete boots.
    

    
    
    These notes bring some thoughts to mind.  I work in Area (regional)
    Support for Digital Services and support many of DEC's products.
    Most employees (from engineering to the service employees) I work
    with are customer focused and will help to resolve support issues
    whether they are a CLD or not.  Maybe I have just had a lot of
    good experiences, but I don't think so.  People seem to understand
    that we are supporting paying customers, in most cases, and do
    their best.
    
    There are always exceptions.  We support people tend to get 
    involved with many of the calls where the process has broken down
    and miss many of the success stories that never get elevated.
    
    We must strive for continous improvement to be competitive.  I read
    one estimate that the software support market will triple by 1995.
    I (and my team) intend to help DEC capture as much of that market
    as possible by giving customers the best support for their money,
    REGARDLESS of any internal or external obstacles that we encounter. 
    
    What I want from a support vendor is the most for my dollar.  It
    doesn't matter if it's an appliance or an operating system; I'll
    keep my business with the vendor that I perceive is giving me the
    most value.  My (our) customers are not different.
    
    It's been fun reading the notes on this topic, keep 'em coming!
    
    -marty