Conference 7.286::digital

    I have a comment: absolutely nothing (zilch, zero) will happen as a
    result of you posting that note in this file.
    
    If you have problems with product quality, tell the product manager.
    Complaining in random notesfiles won't help a bit.
    
    I'm not sure who VMS product management is, but you can find out 
    from VAXWRK::VMSNOTES.NOTE.

    I agree with .1........this is not a technical notes files....
    FWIW, the VMS product manager is Amy Becker @ ZKO DTN 381-2676.
    
    Depending on the hardware involved, you might want to get a
    Hardware Option Module list......it might not just be a SW
    problem....
    
    Karen
    

    Brian Breton is the VMS Product Manager.  Amy Becker has been doing
    something else for months.

    I think .1 and .2 miss at least some of the point of the base note.
    
    The way we do business, as exemplified by the base note, is NUTS. How
    do we expect customers to respect us, if we don't even respect each
    others "patches" or "upgrades"? What kind of message are we giving
    our customers if we ship products that don't work? [And let me tell
    you, I have taken part in discussions about shipping of broken
    software more than once, on both sides of the fence].
    
    What kind of message do we give ourselves when we say "it's ok to
    ship broken hardware, or broken software?" It is this one: "don't
    expect much of yourself, you can't change the system." After a
    very short while, you become part of the system, railing against
    people who want to "hold up the product" because of a "minor bug".
    We are so afraid of being embarrassed by a "schedule slip" that we
    minimize the damage it will cause to our already tarnished reputation.
    
    There is no excuse for LAT drivers that don't work. None. If the LAT
    driver didn't work, we should have pulled the VMS kit and replaced it,
    or done the equivalent thereof. We saw that bug here in PCSG, and
    were frankly astonished; we've come across other bugs before, but
    never something as major as a driver that makes a system unusable.
    
    Several months ago, the CEO of IBM - Akers - told a press conference
    that the reason he thought IBM was not making enough money is lousy
    quality software and hardware. He told the reporters that he was
    instituting a new quality approach in his company - Six Sigma - which
    he said was going to reduce the number of defects in his products
    by a FACTOR OF TEN THOUSAND. He pointed with pride to the division
    that produced the AS/400 - which is now the only minicomputer in
    the market that is making big money - which won the Malcolm Baldridge
    Quality Award for their approach to customer requirements (QFD) and
    its reduced time-to-market and defect rates.
    
    There is a major reorganization going on in VMS-land these days, and
    a friend of mine told me that we are going to focus on quality - first
    to reduce the overwhelming, enormous backlog of SPRs, and to carefully
    introduce new features into VMS, ending the wholesale replacement
    strategy of the 1980s. This is a hopeful sign.
    
    Now, if we could be a bit more humble and realistic about our faults...
    and admit when a kit is NFG.
    
    							Jon Campbell
    							PCSG

    Jon has a good point.  
    
    None of us "feel good" about contributing to delivery of a non-working
    product, be it hardware or software or delivery of a service that
    really doesn't satisfy the customer.  I am sure neither the CSC nor VMS
    development intended to break the other, but there was probably no
    communication between them.  
    
    One of the *first* steps in any quality or customer service effort has
    got to be to determine the requirements.  It seems rather obvious to me
    that the main requirement is that any product we deliver must have all
    of its basic functionality working.  When we deliver parts of a system
    independently, it is our job to assure that they work together to
    satisfy the customer.
    
    I don't care whether we call it six-sigma or qip or tqc or whatever, we
    as a company must get beyond the sloganeering to make sure that we can
    really satisfy our diverse customer base.
    
    It used to be that most of our customers were OEM's with engineers who
    understood our products as well as we did.  That is no longer the case.
    
    The technology has become so complex that some salespeople, even when
    fully supported by Sales Support and Engineering, freely admit they
    have given up trying to keep up with change.  The best salespeople do
    not give up, but its not hard to sympathize with the others.
    
    We need to escalate the attention level of this issue of complexity and
    customer service to make everyone aware that "special efforts" are
    necessary until our organization is straightened out.

re: .5 (and others)
    None of us "feel good" about contributing to delivery of a non-working
    product,

Indeed.  Unfortunately, we will continue to deliver non-working products
until MANAGEMENT changes its mind about "ship it now."  About twelve
years ago, I personally delayed the shipment of a fairly major product
(for which I had software support responsibility) by going to the release
meeting and signing the document "No."  That got them 6 more weeks of
field-test.  When the next meeting came around, my own management told
me that I was not to attend the release meeting.  They signed it and,
yes, it was not bug-free.  And, yes, I left the group a few months later.

About eight years ago, one of our new office word-processors was delivered
to KO's house.  He discovered the shipping box wouldn't pass through his
front door.  He also took it apart and was not pleased by what he saw.
Our packaging started to change after that.  (It should be pointed out
that the engineers who designed that word processor were told to use
existing packaging, so they did the best they could.)

It *is* possible to ship high quality software and hardware on time:
Dectalk contained over 15,000 lines of code (in C), and possibly
one bug that was hard to duplicate, if it existed at all.  However,
Dectalk was done by a small group of people who intentionally constrained
their task.  I'm not convinced that our techniques would scale up to VMS.

    It used to be that most of our customers were OEM's with engineers who
    understood our products as well as we did.  That is no longer the case.
    
    The technology has become so complex that some salespeople, even when
    fully supported by Sales Support and Engineering, freely admit they
    have given up trying to keep up with change.  The best salespeople do
    not give up, but its not hard to sympathize with the others.

Ahem.  I'm a reasonably competent engineer with 18 years experience in
Digital.  I have absolutely no understanding of many of the products
I use, and no idea how to fix them when they break.

    We need to escalate the attention level of this issue of complexity and
    customer service to make everyone aware that "special efforts" are
    necessary until our organization is straightened out.

I suspect the cure is worse than that:

-- on the one hand, the technical people may need to use formal escalation
   methods (Open Door) to get past the "ship it" people.  In a time
   when good people are getting the tap on the shoulder, this requires
   more courage than most folk should ever need.

-- on the other hand, we may need to decide the problem is unfixable;
   that the complexity of VMS (Ultrix, OSF, Motif, networks, and whatever
   else you have lying around) is so great that we can do little more
   than freeze the systems and hope that folk can work around the problems.

In this regard, I would recommend reading Charles Perrow's book, Normal
Accidents (Basic Books) -- while it isn't about computers per-se, you
will probably find some very familiar incidents.

Martin.

Re .5 and others:

>    really doesn't satisfy the customer.  I am sure neither the CSC nor VMS
>    development intended to break the other, but there was probably no
>    communication between them.  

	I'm at the CSC, but fairly new at the VMS support group.  From what I
    understand of the patch generation process, CSSE at least is involved in
    the generation and certification of patches.  At least some parts of VMS
    engineering know about the patches we generate.  From the CSC end of things
    we do our best to make sure we don't create new problems for our customers.
    
>    One of the *first* steps in any quality or customer service effort has
>    got to be to determine the requirements.  It seems rather obvious to me
>    that the main requirement is that any product we deliver must have all
>    of its basic functionality working.  When we deliver parts of a system
>    independently, it is our job to assure that they work together to
>    satisfy the customer.

	Yep, but determining what is 'basic functionality' is not as simple
    as you'd think.  Is the basic function to be able to communicate with the
    system console, any local serial port, or all serial ports anywhere?  
    The problems have been someplace between the first two options and the 
    third.  In other words, there is trouble in some of the more obscure and
    complex interactions where we (DEC) have to develop special tests to check 
    for the problems.  This is a LAT example, but the other sub-systems are 
    just as complex if not more complex.  In other words it's easy to say 
    there was a problem in a specific component after it has shown up but it 
    is next to impossible to say where the next problem will be.
    
>    We need to escalate the attention level of this issue of complexity and
>    customer service to make everyone aware that "special efforts" are
>    necessary until our organization is straightened out.

	Getting 'everyone' involved is hardly an appropriate use of company 
    resources.  This is a problem with SPS, CSSE and VMS engineering and those
    groups have to work togeather.  The problem in .0 points out that more
    cooperation is needed.  Since it's a cross functional issue, it needs to 
    be addressed by the upper eschelons, rather than grunts like me on the 
    front line.  The pointers to VMS product manager in the early replies were 
    exactly on target in this regard.

	Hey man, we know this is a problem and we are working on it.  The 
    comments in .0 were helpful.  The generalizations and non-specific 
    criticism in .5 are considerably less helpful.

    re .7 by Woodbury
    
    The generalization is intentional.  I believe this problem is far
    greater than the CSC and VMS, or any particular group.  It is systemic,
    that is, built into this company and its management practices, as
    Martin noted in .6.  I generalized, because I believe that the solution
    to the root cause is a *long way* off and we *as individuals* in our
    own way will have to take the big risks described in .6.
    
    Suggestion:  Can we use this network to redistribute some of the risks?
    
    Can we recruit from among ourselves people close enough to the
    perticular action (trying to ship a bug, for example) to have
    credibility but who have no direct links to the actors?  I have seen
    the "objective bystander" be a very effective brake on such abuses.  
    
    I propose this because I believe that the Open Door *can work* and that
    if we are persistent, we will ultimately be supported.  (Sure, I'll
    accept the adjective "naive".)  
    
    Regards,
    
    Dick

    re: .0
    
    Until such time as Digital <<whomever>> fixes the problems you
    described, Digital will continue to pay you your salary to be as
    inventive as you have been to resolve these sort of situations.
    
    I've worked in the field along time, and understand your frustrations
    very well!!  The best thing I've found is to tell the customer we will
    fix the problem(s) to the very best of our abilities, and being human,
    *will* err. I thank the customer that takes the time to point out
    Digitals failings so we can correct them (I say that to them, too).
    
    I also have come to realize that there will *always* be those customers
    that just plain old want to whine, or complain, and will abuse the
    situation and dump on you. The only meaningful solution is to shrug it
    off, and work to make sure the dumping gets stopped ASAP. I was
    extremely fortunate and had a good unit manager *and* District manager
    who helped me get some dumping stopped before I went non-linear.
    
    I also think you did the correct thing by at least reporting what was
    wrong, in this conference, and asking for help!!  Isn't it nice to know
    you have the implicit support of all these invisible noters!!! Good
    luck with all the previous suggestions....
    
    Bruce Evans

    Just being an anarchist, but:
    
    Sure, getting management buy-in to do things "right" would sure make
    the process a lot easier, and would also probably increase the
    probability of successfully getting those things "right".
    
    On the other hand, if your management isn't interested in quality, you
    can still do it yourself.  In a nutshell, you don't have to get your
    manager's permission to do a quality job.
    
    Sadly, everything involved in doing a quality job in the absence of
    managerial buy-in will be career limiting, but it does come down to
    priorities.  I've personally found it preferable to take the extra time
    to get something right, thumb my nose at the schedule (if it deserves
    to be nose-thumbed), and get my boss royally p*ssed at me in the
    process if it'll ultimately mean that I'll spend less time later on
    down the road participating in fire drills chasing down problems in
    something that was done wrong because I was spending too much time
    following orders.
    
    Interestingly, my manager was also always there afterwards to soak up
    the credit when things went right as a result of my rebellion.
    
    If any of us are really that all-fired interested in doing a quality
    job, then now's the time to start.  It's in the company's best
    interest, even if it isn't in your career's best interest.  For us
    software types, that means just a little more "midnight terrorist
    programming".
    
    We now return you to our regularly scheduled orderly world...

    re .-1   Nice reply...

Re .8:

	OK.  You were generalizing.  The problem is generally one of size.
    There are just too many people involved to let an easy solution work.  

	I won't tell you to stay out of it.  You probably wouldn't do it if
    I did, and your nosing around might do some good.  But I don't think it
    will.

	I don't know all the people in engineering who work on the products I 
    support and they don't know me.  I'm only one of (soon to be) 25-30 
    people dealing with customers and there is another group the same size 
    dealing with the same products and customers.  If there are more than a 
    dozen engineers working on our products, I'd be suprised.  I expect there 
    are no more than 5-6 actually working on the stuff I support.

	Now put yourself in one of those engineers place.  You can't get your
    work done and get to know the sixty odd people who talk to the customers
    at the CSC about your product, much less the hundreds at the various local 
    offices.  If I come in and start talking to you about a customer problem
    how are you to know if I'm talking about something significant and new or
    a problem that is the result of wistful ignorance.  To put it bluntly, you
    don't.  You've got to rely on your manager to set up the appropriate 
    channels.

	Now put yourself in the managers position.  You've got a couple dozen
    pieces of a product to manage and maybe that many people to do the work.
    For each person you manage, there are probably four or five at the CSC.
    You've got to set up communications between your people and the CSC staff
    and the CSSE group that handles field problems and the SPR screening office
    and ...  On top of that you have no budget and no staff to assign to the
    communication problem.  Is it any wonder you end up in seige mode?

	Now this note appears that says there is a problem.  Hey, you know 
    there is a problem, but the original note identifies a particular aspect
    of the problem that is impacting customers.  That's helpful.  Then there's
    this suggestion that a bunch of people start looking over your shoulder and
    start telling you how to do your job.  How would YOU react?

	I think that puts the right frame on the problem.  It's not one of
    shipping bugs.  It's not one of putting pressure on the managers.  It's a
    hairy communications and management problem.  The more noise in the 
    communication channel, the worse it will get.  The more people trying to
    micro-manage the issue, the worse it will get.  Now go back and read my
    second paragraph again.

Re .6:

>In this regard, I would recommend reading Charles Perrow's book, Normal
>Accidents (Basic Books) -- while it isn't about computers per-se, you
>will probably find some very familiar incidents.

Hmmm, it doesn't seem to be in the DLN catalog.
				/AHM/SIGH

    re: .12
    
    Let me describe how I addressed this problem.  I am a software engineer
    working on DECforms, a product that runs on VMS.
    
    When the product was announced I spent 2 weeks in the Colorado Springs
    CSC, over the objections of my management, teaching the specialists
    about DECforms and learning what it was like to "man the phones".
    In addition I got to know the people who would be supporting my
    product.
    
    After returning to the ZKO ivory tower I kept in touch with the support
    people by electronic mail.  There has been some turnover since I was
    there, so I no longer know everyone, but the senior people still know
    my name.  They permit me to examine the logs they keep of customer
    contacts, and I check the log about once a day.  Occasionally I can
    help with an "open call", and sometimes they send mail or post a
    problem in our notes conference.
    
    Thus, there is good contact between DECforms engineering and DECforms
    support.  Management is only minimally involved, though I keep them
    reminded by telling stories of the form ``Yesterday a customer called
    the CSC and complained about....''
    
    Although I wouldn't use the anarchic words in 1372.10, I have
    subscribed to something very like the philosophy described there for a
    long time.  My management isn't very pleased with me, but they do call
    on my skills when they are in a bind, and I have the satisfaction of
    knowing that I am doing a good job by my standards.  I wouldn't
    recommend the attitude in 1372.10 to anyone who is interested in
    getting promotions, though.
        John Sauter

    As one of the CSC specialists who supports DECforms, I would like to
    add that John's original visit and his continuing communication with us
    has been *very* much appreciated by all of us on the support team.

    -- Mike

    .14 says, in much nicer words, and in deed, what I was getting at.
    
    I know that the last time CSC related issues came up in a staff meeting
    (previous department), most of the talk around the table seemed to
    concern how to get those pesky CSC people off our backs.  I balked at
    this attitude and was given a refresher course in how much more
    important ZK engineers are, and how they shouldn't waste their time on
    CSC people.  After all, they'd constructed a firewall between
    engineering and CSC for that very purpose.
    
    I probably said a few career limiting things, ending with a blanket
    recommendation for each and every one of them to try a month on phones
    in the CSC, and talk to me about it again after they got out of the
    psych ward.  I guess what I'm saying is that I didn't, and still don't,
    go along with the attitude I was being presented.
    
    Sadly, that attitude still exists and still works against us.  I tried
    my best to be a liason between my previous department and the CSC.  I
    didn't quite do as good a job as .14 did.
    
    And, as for the statement that what I said can be counter to promotion: 
    Yes, I'm living proof of that.  In my entire (16 year) career as a
    software engineer (spread across four companies), I've never once been
    promoted.  You can therefore assume that any advice I give will, when
    taken literally, be quite career limiting.
    
    Oh, what the heck.  It's what I do.

Having had to mediate disputes between a large corporate account and our CSCs, 
I commend the author of .14 and think what he did should be standard operating 
procedure for interaction between engineering and our central support groups.

I only wish the communication and teamwork alluded to in .14 were true for all 
of our products.

Jim

    re: .17
    
    It can be made to come true.  See topic 752, particularly response 24,
    where I describe how I did it.  This is something that can be done
    by Individual Contributors, without management permission, which
    contributes significantly to the quality of our products.
    
    However, to underscore some previous references to sacrificing
    promotions: I have worked for DEC since 1975, and I got my last
    promotion in 1978.  I currently have no prospects for advancement.
        John Sauter

re: .18:
    However, to underscore some previous references to sacrificing
    promotions: I have worked for DEC since 1975, and I got my last
    promotion in 1978.  I currently have no prospects for advancement.

You too, John?  Maybe if we all wrote to DELTA that people who actually
support the stuff they did ...

Naah, we'd better concentrate on important stuff like water coolers
and Post-it's.

Martin.

John Sauter is not the only developer to have visited the CSC.  I have twice
travelled out there, at my own expense, and spent time with the support
staff, listened in on the phones and helped educate the staffers about
the product I work on (VAX FORTRAN).  Unlike John, I did not get the CSC to
help with my expenses, but I didn't mind.

Even before my visits, the FORTRAN developers and the CSC staffers have
worked closely, and each of them (Chris, Carol, Rick, Jan, Caroline,
Janet and probably some more whose names have slipped my mind) know that
any questions they have will be quickly and cheerfully answered by me or
one of my coworkers.  We don't insist on formal procedures, if that's what's
needed to keep the customers happy.

And I don't think FORTRAN is alone - many other TLE compiler development
groups have similar close ties with the CSC staff and don't stand on
protocol unnecessarily.

It's not as bleak a picture as some would paint.  Yes, for complex product
combinations such as VAX processors and VMS, it can sometimes be hard to
track down someone who knows the answer.  But it can be done.

As for sacrificing promotions, I don't believe that supporting one's product
prevents promotions.

					Steve

    Uh, what is it with this company that we have engineers paying
    their own fares to go and help support the products they work on?
    
    This doesn't sound like a good way to do business to me.

I certainly admire you guys for going to those lengths to ensure that there is 
competent support for the products you have developed, but if that is what 
individual engineers have to do, there is something VERY wrong with the system!

Jim

    Travel to meet people works in several directions. When I was
    in the field (a lifetime ago) we generally went out of our way 
    to meet the people (HOSS at the time) who supported us. Meeting
    engineers was also something we went out of the way for. It was
    a good part of the reason we wandered the halls of the Mill
    after hours. It usually paid off in better relations and better
    support for customers and products.
    
    One does tend to wonder why such things aren't pushed more
    formally though. Informally my Unit manager back then told
    us that such visits were expected, by them, and that if we
    wanted to treat our support people to meals that was fine too.
    It was concidered a good way to express thanks for the help
    they provided.
    
    Later when I was in a development group I also visited field
    offices on occassion while on personal business. It seemed
    like a natural thing to do.
    
    With regards to supporting ones product. There are some groups
    where that is important. When I was a developer in the RSTS
    group everyone was responsible for answering and correcting
    SPRs. If you wanted to do interesting new things you kept your
    SPR basket empty. I've heard of other groups where once you
    ship a version you aren't responsible for any bugs that showed
    up. It's hard to imagine having the same dedication to testing
    and careful design under those conditions. Perhaps some can do
    it but I know that if my program fails someone is going to
    walk into my office and say "fix it" I work harder at quality.
    It takes a little longer sometimes but SPRs, calls to the
    CSC, and CLDs cost a lot more then the time spent does.
    
    			Alfred

    With regard to the system being broken, sure it is. In 8 years in
    Customer Services, first in the CSC in the UK, now in CSSE, I've never
    seen the formal system work for more than 30 seconds in the light of
    day.
    
    Theories are very good. They survive only on paper because they can
    never adjust to the situation as real humans can.
    
    The *real* system is that we all do the right things (as we see 'em) to
    get problems fixed. Some damn theorist can write all the 'Problem
    Resolution Methodology" papers they like - the real answer is people.
    
    	- andy

Re .24:

Do you think this state of affairs is part of Digital's quality problem
(something which needs to be improved) or is it all OK with you?
				/AHM/THX

    I think Andy and even you, Alan, are in a like mind regarding this:

    (1) The bottom line is that we do our job driven to achieve excellence
    that will be recognized by the customer.

    (2) To the extent we can, we try to inspire others not to give up hope
    that the company will come around to this way of thinking.

    (3) To the extent we can and in an appropriate way, when our opinions,
    suggestions, etc. are sought, we'll freely suggest that "the system s
    broken", and offer something constructive.

    The idea is to seek a balance between the despair that we're all doomed
    and the naive view that everything is OK.  I still care, but it's
    important to know the limitations of my influence.

    Thankfully, I'm not in a group that plans "minimum affordable quality"
    and looks at tradeoffs between staff and dissatisfied customers.

    re: .20
    
    Steve and I both used to work for Tom Hastings on the VMS RTL.  Tom was
    Digital's first Software Consulting Engineer.  I wonder if that common
    experience has anything to do with our similarity of approach on 
    this subject.
    
    I should not have implied that supporting my product has prevented my
    promotion.  It could be that I have other traits which make me
    unpromotable.  I request that those who know me refrain from attempting
    to list those traits in this topic---if you must, use Email.
        John Sauter

	As regards suggestions that engineers spend a little time
	with the CSC folks that support their products....

	Steve Lionel's visits to our team when I supported FORTRAN
	were WONDERFUL.  The guy actually sat down on the phones with
	us and listened in.  It opened his eyes a bit, I think, and
	we benefitted greatly from his insights and just from 
	getting to know him.

	I subsequently posted a suggestion to DELTA that recommended
	that software engineers each spend a week each year with the CSC
	group that supports their product.

	Other than the form letter that says "Thanks for your suggestion",
	I have received zip, zero, nada in the way of response...

	Despite  proven value, looks like this one'll
	never happen....

	Steve H

    re: .28
    
    Following my experience I also posted an essentially similar suggestion
    to DELTA.  I have also heard nothing about it.
        John Sauter

RE: .20,.28

I have written this in notes file before but when I was a DEC customer
it was obvious that VAX FORTRAN support (Telephone, upgrade, and bug
fixes) was MUCH superior to that of any other product.

Maybe this is why.  Or maybe the folks in the FORTRAN group place much
greater emphasis on this area.

    re:30
    
    You're absolutely correct......this might even help the groups 
    doing pre-sales support.  The Infoserver 100 people were here in
    Atlanta a couple of weeks ago......sure they are doing some
    traveling around, but freely admitted that getting the bulk of the
    information to 60+ people was going to free their time to work on
    the next phase.
    
    Flying a engineer to support groups might seem expensive to some;
    but 60 people can off-load a lot of calls and free up a lot of time
    for a product manager.....
    
    K
    
    BTW, they didn't take US out to dinner......they didn't even buy
    	 us a Coke :-)
    
    

	Yup, and I'm the engineer who flew down.  To be honest, you got an
engineer only because the Marketing person who was supposed to give the talk
couldn't make it and they asked for volunteers.  I really enjoyed the trip,
and would be more than happy to do it again.  Maybe that's because I spent 
nearly four years in support for an internal product.

	There's always a tradeoff.  The InfoServer group is small, and there's
lots of work to do.  If you remember correctly, my reply to a lot of the
"can it do" questions was "that's on my work list."  Well, the list never seems
to get any shorter, but I'd rather spend a day flying and a day lecturing and
and occaisional phone call so you folks have the answers up front than have
to fight customer satisfaction issues down the line because someone got
sold a bill of goods.

	And as for buying you that coke, well, If I'd had a minute to do 
anything besides teach, eat, or sit in an airport, you might have lucked
out. ;-)

	And, if you're really stuck on an InfoServer question, well, I'm in ELF,
and if I don't know the answer, I stand a pretty good chance of either finding
it, or pointing you in the right direction.


						--Doug

	It works in the other direction too, sometimes.  Whenever I've been
    in the Greater Maynard Area, I do try to stop by and talk to the engineers
    who wrote the product I was supporting at the time.  I also try to read the
    code on the products I support so I don't have to bother them with stuff
    they have no control over and so I can talk intelegently with them.

	In some cases this has worked out very well.  In other cases I've
    hit a brick wall trying to find the people to talk to or in finding the
    code to read.  Most of the code I've read was well commented and, after
    some effort, understandable.  (There was one set of code that caused me
    to look for other products to support.)  Generally, the individual
    engineers seemed to like talking to me, provided I was nice to them and
    did not add too much to their work load.  The real problem I have had is
    with managers.  There are some that have flat out refused to let the
    support groups see the code, even when aproached through official channels.

re: 1372.28                upgrade and patchs on VMS                   28 of 33
>--------------------------------------------------------------------------------
>                     -< Suggested to DELTA ( black hole ) >-

>        As regards suggestions that engineers spend a little time
>        with the CSC folks that support their products....

I can't but help wonder what would happen, if .. every person who is 
aware of the "... value in doing.." this, each submitted a similar suggestion
to both : Their Supervisor and also to Delta ?

>        were WONDERFUL.  The guy actually sat down on the phones with

I can imagine the synergy that took place. In the past 5 years (my gosh, that 
long already?) since CSS/NSG (now T & N EIC / US-EIS) took over the entire
Modems business, including CSSE Maintainability  function, I've been part of 
the "Product Solution Team", which is an informal name for the folks from the
Customer Service Reps, through the CSCs, Area CLD Managers, and right to 
the heart of the Businesss Management Team.

The engineers have not only been to the CSCs, but have made many trips to 
Customer Sites, and provided product training to whomever had permission
to listen.


>        Other than the form letter that says "Thanks for your suggestion",
>        I have received zip, zero, nada in the way of response...

What if .. just suppose ... what if ..  we all input the suggestion, each from 
our own perspective, to inform the Delta Admin .. the long range 
"Value of Doing", of permitting the people who create and release (engineers)
these products, to become part of the "solutions team" for those same
products ..

By observing  first hand at the CSC "Hotline", and by actively participating
in folloup support to those "real tough questions" that send peope scurrying 
off to pull SPDs, read Notes, Scan STARS, review PRISMS and CLDs, and call
"old friends" in the hope of getting a clue to "whats the real question",
and "what needs to happen to make this customer happy?".

What better words to hear than "Thanks for everything. Its working now."

(Unless of course its: Here is my order for ..... ) 

Regards.

    Bob Early
    Senior Hardware Support Engineer
    T&N EIC Product Support Group
	US-EIS    
    

btw - feel free to forward an comments directly to me on this topic .

    re: .33
    
    I would love to have any of the specialists supporting my product drop
    by my office for a chat.  I'm in ZKO2-2, area N, next to pole B.7.
    I'm currently working on DECforms.  If you'll come by I'll introduce
    you to the rest of the group and even give you an organization chart.
    
    If you want to look at code I can call it up on my screen, or print
    selected pieces for you to take.  DECforms is over 300,000 lines of
    code, so I can't give you all of it.
    
    Don't go through management.  Just drop by.  Remember Grace Murray
    Hopper's motto: ``It's easier to ask forgiveness than to get
    permission'' (or something like that).
    
    I won't promise dinner, for fear of having all of CSC/CS descend one
    day and wipe me out, but if the crowd isn't too large I'll see what
    I can do.  ZKO isn't too far from Bedford or Merrimack, so try to
    schedule some Spit Brook time if you're in the area for training.
        John Sauter

Re .35:

John,

	Since I don't support DECforms, the offer does not apply directly to
    me, but I appreciate the thought.  I just wish there were more people in
    engineering with your attitude.

	Grace is very smart, but there are times when management really does
    have to do the right thing.  The interface between engineering and the
    support organizations has some serious problems.  Your good will makes 
    DECform support work and work well.  Unfortunately many DEC products do
    not have people like you in their engineering groups.  Other groups are
    too big to allow individual efforts to pay off.  There are a number of 
    engineers in VMS engineering who are willing to talk to the VMS support
    people, but the size and number of problems that VMS has to deal with
    dilutes their efforts to the point where problems like that reported in 
    .0 come up.

Re .24:

	The theorists arn't wrong in what they write; As far as they go they
    are probably correct.  It's just that they are writing about the wrong
    problem.  They are trying to design 'problem resolution METHODOLOGIES'
    when what is needed is problem solving ORGANIZATIONS.

	Seriously, DEC is not designed to solve customer problems, or even
    to sell products to customers.  It is designed to build hardware, software
    and services that we hope customers will buy.  If DEC were really serious
    about solving customer problems, the engineering groups and support groups
    would share responsibilities, at least at some level, which they don't now.

This note triggered an encouraging dialogue between Engineering and
CSC support. Within my 2 decades with DEC I spent about 1/3 as field
service engineer,1/3 as design engineer, 1/3 to now with support
(CSC), therefore I feel that I understand both "sides of the fence".
    
Now we got a handful of engineers who are willing to informally 
communicate with the field, a wonderful network and a few
support (CSC) folks interested.

Instead of trying the loooong DELTA route, would it make sense to
run a hacked up "John Sauter Support Model" as a pilot ?
    
The idea is sort of a totally informal, but definately limited
network of engineers and CSC support specialists.
Each engineer's "server node" supporting lets say an average
of 10 support "client nodes". 
It is obvious that the server can't support 100 clients !
(e.g a potential 100 CSC specialists calling one engineer!!!)
    
Given that there are 2/3 CSC's in the states, 3/4 support centers in
Europe, ??? in GIA, the magic number 10 could turn out suitable.
    
    I'd give the "server" (engineer) the right to accept or reject "client"
    canditates upon review of their actual activity, perceived competence and
    maturity as submitted in the resume of the candidate "client".

Once the HUMAN network configured, it needs no protocol to operate.
Querys asked by the "client" do not need to be "screened" nor 
"administrated". Mature and open minded people strongly sharing
a common (technical) interest do not need a formal protocol
to dialogue. NOTES is the best example. 
    
(I bet that if someone would make a study on how many problems 
have been solved at what cost in any "employee interest" Notes
conference as compared to official SPR, PRISM and CLD processes,
the results would blow the socks of more than one Services VP !!)

The tool to support such a networked support operations could be
NOTES to start with or later the more recent "On Line Consultancy"
feature within ULTRIX/ATHENA. 

Anyway, I am not so worried about the tool. If people really
want to dialogue, they sure find a way. I've seen ca. 2 years
ago an example of an attempt to create a worldwide support
network with NOTES upon initiative of GIA, but it failed
miserably as the HUMAN link and motivation was totally missing.

Is it worth trying with a few engineers and CSC support folks ?
If so, I'd be happy to help identifying the European 
"client node" candidates or with other support matters.
    
(My group does VMS, ULTRIX, PCSA, DECwindows, Graphics, RSX support
 to a large part of Euro front line customer support centers)
    
I'd insist on informality of the support net, otherwise it might
be viewn as an attempt to bypass/get rid of CSSE and the newly 
created Corporate Field Support who in my humble opinion are more
interested in the heavy CLD problem solving stuff anyway.
But you never know, it's easy to step an toes when there are so
many toes.
/fred
    
     

    As is the case with almost everything that is "wrong" with DEC these
    days, it sounds again as if our management-by-amateurs approach has
    come back to bite us.
    
    I've been the CSSE Service Product Manager for PDP-11 Software for the
    past four years, and I know that PDP-11 Management, Product Management
    and Engineers regularly visit with and work with the CSC.  This has
    been going on for a long time.  But, this has created one real problem.
    Some of the products have become so trouble-free that service income
    has fallen off dramatically.  Customers no longer feel they need
    support.  We've really gotta do something about that!!!

Re .39:

	Maybe it's time to put out a new functional release of RSTS?

	})8^)}

>	Maybe it's time to put out a new functional release of RSTS?
    
    Actually I believe that the latest release of RSTS, Version 10, is
    both quite recent and quite stable. Probably has  quite a bit of new
    functionality as well.
    
    			Alfred

Re .38:

	The informal network does exist already.  It would be nice if it
    were a bit larger, but adding too much to it too fast would make it fall
    appart and we would all be worse off than we were before.

	It does NOT threaten CSSE.  CSSE is as much a part of it as any other
    part of engineering.  If you're part of the net, you know that.

	Engineering management is still a key part of this.  They could make
    the current network much more effectively by acknowledging that it exists
    and serves a valid function.  They would have much better control if they
    did acknowledge it and condoned its existance.

	There also have to be careful (self) controls built into the net.  It
    can NOT be used to force engineering to work on a customer problem, which
    is something that the support people are tempted to do.  What it must be
    is a way to convey information about problems to and from engineering.
    This includes advanced warning that a new problem is entering the formal
    process resolution pipeline, how much a particular problem is impacting 
    customers, and ideas on the source and solution to the problems engineering
    is working on.  All this has to be GOOD QUALITY information, not just 
    random mutterings.  Mechanisms already exist to move this type of 
    information around, but they are too slow and focus on too few people.

	There is a LOT of dirty laundry in the support business.  I've nosed 
    through a lot of it, but I do NOT think airing it in public is likely to
    help.  In some respects management is like a bunch of alcoholics.  They 
    have problems, but trying to force them to face a particular problem is
    not likely to get results.  The problem will only be solved when they 
    admit that there is a problem to themselves.  There are strong signs that
    management is aware of the support problem and that they are working on a
    solution.  A lot of noise at this point will redirect their attention away
    from the problem and to the source of the noise.  This is NOT what is 
    needed.  (I've written a lot in anger on this subject and deleted it before
    putting it into this conference.  I am tempted to delete this paragraph
    as well since the analogy with alcoholism is so negative in some peoples 
    minds.  Please understand that it is NOT negative in intent.)

RE: .28, .29 (engineers visiting CSCs)

A more effective route than DELTA might be to send this proposal directly to
David Stone or Bill Keating, who are managers in a position to act on the
suggestion.


RE: .30 (FORTRAN support)

It has long been the philosophy of the VAX FORTRAN development team that fixing
customer-reported bugs takes precedence over new develoment work.

--PSW

>It has long been the philosophy of the VAX FORTRAN development team that fixing
>customer-reported bugs takes precedence over new develoment work.

This isn't standard practice in engineering??????

Unbelievable...

/mlm

As someone who has to deal with customers' desires for new and improved
products and also customers' demands that the products they have bought work
as advertised, my vote would be for Engineering to set the latter as their top
priority. 

Unfortunately, I think the Fortran support philosophy is the exception rather 
than the rule.

Regardless of the hand-slapping I receive in various technical notes 
conferences, I still consider them my (and my customer's) best source for 
information and problem resolution. The sooner this is an official support 
route, the better.

Jim
Sales Support
Rochester, NY

  
  Re .45
  
  > I still consider [notes conferences] my (and my customer's) best source
  > for information and problem resolution.
  
  I agree with this bit *for* *many* *products* but ...
  
  > The sooner this is an official support route, the better.
  
  gets a definite NO vote. 
  
  Certain product engineering groups are incredibly responsive and helpful.
  This is due to the nature of the people within them - the type illustrated
  in this note by John Sauter but there are many engineers of that ilk who
  are not seen by people outside of their product area. They do this without
  any official pressure, without any bureaucracy, without any enforced new
  methodology but simply due to their characters. Try to force an unwanted,
  unnecessary formality on these people (and the ones who rely on them !) and
  you risk breaking the trust, understanding and good will that makes
  everything run so smoothly at present. Note that the unofficial channels
  don't _replace_ official ones, they just oil the process and fill in the
  gaps so that the overall effect is a much smoother finish than you'd get
  otherwise.
  
  For the products which aren't responsive and don't help, no amount of
  extra officialdom will change anything. IMHO making notes conferences an
  official support route wouldn't help anyone but would probably harm.
  
  From my experience, the responsive group are the smaller, tighter
  organisations but I don't think that size is always the _problem_ ...
  I think size provides a convenient excuse for those who want one but makes
  no real difference to the people who simply want to do their job well.
  
  Frank
  [ Graphics Software Support - UKCSC Basingstoke ]

There is a topic either in this conference or maybe it is VAXWRK::VMSNOTES, that
discusses this very issue.  About a year ago, a memo came down from some muckity
-muck ordering field personnel to ask for answers to customer problems in
NOTES conferences BEFORE calling phone support.

I no longer have a copy of the memo, but Marge Davis-Hall<mumble> sent me
a mail message asking for a copy of the memo and I sent it to her.  She may
still have a copy.  I have never seen another memo retracting the first memo,
so I can only assume that it is still in force.

Now that I have probably made many people ready to go ballistic, let me say
that I think anyone would be stupid to condsider answers in NOTES to be an
official statement of position and/or commitments to customers.

However, in a legal sense, I suspect that the author of the memo has probably
exposed Digital to potential liability if someone made a commitment to a
customer based upon a response in NOTES and things turned sour and Digital
was sued.

Bob

    re: .44, .45
    
    Whether fixing current problems is higher priority than new development
    is standard practice I can't say.  However, my group has followed the
    lead of the FORTRAN group in adopting that philosophy.  I don't know
    whether is makes business sense or not, but it certainly makes me feel
    better.
        John Sauter

    The Bernie Gaines memo explaining the CSC $100 charge issue contains a
    "map" of where to go for information (for EIS).
    
    For help without charge, we are instructed to use DSIN and NOTES.  For
    help with a charge, we are to use FSIN.  This memo states that FSIN is
    the preferred method for the first line of support.  From what I
    understand, this fact came as a bit of a shock to the FSIN folks who
    were apparently unaware that FSIN had been named the new front-line
    support mechanism for EIS.
    
    I believe the CSC resource was supposed to be used following the
    FSIN/DSIN/NOTES route, if needed.
    
    -- Russ

Re .47:

>Now that I have probably made many people ready to go ballistic, let me say
>that I think anyone would be stupid to condsider answers in NOTES to be an
>official statement of position and/or commitments to customers.

Don't confuse the message with the medium, as the author of that memo apparently
did.  Some conferences are an official internal support channel for certain
products.  Why?  Because someone with authority to extend this service has
stated this commitment.  Other conferences are emphatically not support
channels, and the responsible developers may be forbidden from addressing bugs
reported therein, rather than through the official channels.  Why?  Because
someone with authority to refuse this service and direct the work efforts of
the developers has made this prohibition.

CSC members who post problems in the first kind of conference may indeed help
give customers speedy, effective service.  CSC members who post problems in the
second kind of conference are at best relying on the good graces of colleagues
across the network (including the developers) to help them solve problems
quickly.  A CSC member who posts a problem exclusively in the second kind of
conference to the exclusion of the formal support channels which the developers
have committed to use, can end up delaying the solution of problems by months or
years, thus lowering the value of our products and services.

The apparent neglect of this distinction in that memo makes it a flawed process
from the start.  Hopefully few problem reports are merely dumped in
non-responsive conferences and left to fester.  I wouldn't bet a wooden nickle
that it doesn't happen every day, though.

Likewise, anyone with authority to make position statements or commitments to
customers can do so in a conference.  It may be more likely in the "full
service" flavor, but even that is irrelevant - the measure is whether the person
writing has the authority to make a statement.

(How can you tell one kind of conference from the other?  Read the whole thing,
or get someone you trust to tell you.  Some disclaimers are well hidden.  It's
not enough to assume that if developers make contributions from time to time
that you've found an official "hot line".  Stinks, doesn't it?)
				/AHM
P. S.  I doubt you have the Law Department's permission to speculate about
legal liabilities here.  Whether you want to do so and risk having to seek their
forgiveness someday is a decision only you can make.

When I was responsible for RSTS/E software support (1976-78), I ran
into two opposite central-engineering philosophies of "support/bug-fixing."

-- RSTS/E had the philosophy of responding quickly to SPR's, and issuing
   "mandatory patches" for everything they found, including typo's in
   error messages.  Since they were responsive (and, it must be admitted,
   had more than a few bugs in their code), they received a lot of SPR's
   and issued a lot of patches.  They thereby got a very bad -- but
   completely undeserved -- reputation for quality among senior management.
   The buggiest of their releases, only about 10% of the patches were
   really crucial.

-- Other software was equally buggy.  However, their engineering group
   did not respond to SPR's and did not issue patches, commenting only
   "fixed in next release."  The result of this was that they stopped
   receiving SPR's (the customers quite reasonably concluded that there
   were more useful things they could be doing with their time).  Since
   they had a low number of SPR's and an even low number of patches, they
   thereby got a very good -- but likewise undeserved -- reputation for
   quality among senior management.

As long as we continue to manage by looking at numbers such as SPR rates
or patches issued, rather than taking on the harder task of looking at the
actual problem, it will be tempting to respond to management by making the
numbers look good, which, in many cases, means that one ignores long-term
concerns.  Of course, by that time, the responsible parties will have made
their reputations and moved on to bigger and better things.

A previous posting questioned whether "engineering" should be responsible
for "support."  I would argue that this is the case, but only as a
last resort.  The proposals to rotate engineering people through CSSE
(and CSSE people through engineering) would be one way make development
engineers aware of day-to-day issues.  Dec's old practice of sending
engineers to Decus is another way of giving engineers a useful (if
perhaps eye-opening) education in customer needs.  None of us should
be expected to work in isolation from the rest of the company; and
all us should assume we have responsibiliry for our products.

Martin.

    There are circumstances where development has higher priority than
    bug-fixing.  I've been on projects where that was explicitly part
    of the job, and for good reason.
    
    One was building a BLISS compiler for the (later cancelled) PRISM
    machine.  Development of that compiler took precedence over bug-fixes
    in the VAX BLISS compiler.  The crucial point is that existing
    applications were already working--that is, they did not require 
    fixes to new bugs, and the whole point of the new compiler was to
    port those existing applications.
    
    			-John Bishop

re:.51  Alan,

>Don't confuse the message with the medium, as the author of that memo apparently
>did.  Some conferences are an official internal support channel for certain
>products.  Why?  Because someone with authority to extend this service has

I'm not aware of any conferences that are official internal support channels.


>P. S.  I doubt you have the Law Department's permission to speculate about
>legal liabilities here.  Whether you want to do so and risk having to seek their
>forgiveness someday is a decision only you can make.

If you are saying that I could cause Digital some liability by speculating
that the memo could cause Digital some liability, it's real easy to come up
with a situation where the simple existence of the memo would be sufficient
to cause the liability.

For example, Joe Software is a resident at XYZ Corp.
Someone at XYZ asks Joe if product Q can be used to perform some function.
Joe doesn't know, but asks in a NOTES file.  Someone in the NOTES file says
that it can be done.  Joe tells XYZ that it can be done.  XYZ spends a lot
of time and money trying to get product Q to perform the function.  Finally,
it is discovered that product Q can NOT perform the desired fuction.  XYZ
sues Digital.  When poor Joe is asked where he got this information, he says
he got it from the NOTES file.  Ahah! Our lawyers say, that NOTES file isn't
an official support channel.  It says so in 1.0 of the conference.  During
discovery, someone comes across the EIS memo that states that NOTES conferences
are offical support channels.

Bob

    Re -1.....sorry, Nothing should take precedence or immediately dealing
    with customer problems.  Anything less is engineering arrogance.

Re .54:

>I'm not aware of any conferences that are official internal support channels.

TURRIS::SCA_V2_BUGS (q.v.) 254.0 (dated 5-Feb-91) looks like someone from a CSC
reporting a customer problem.  The .1 looks like a developer acknowledging
receipt of the problem and promising to investigate.  But I've been wrong
before...


>If you are saying that I could cause Digital some liability by speculating
>that ...

Read the following, and behave as you see fit.  From $ VTX GUIDE - an online
copy of the Internal Guide to Digital Organizations:

"
Chapter 9 - LEGAL SERVICES FOR ENGINEERING/MANUFACTURING
...
9.5.4  How to Avoid Legal Pitfalls When You Write

The outcome of lawsuits can be affected by correspondence written years
before by people who never thought about how their words would sound in
court. Whenever anything is written (either in hardcopy or electronically)
- a memo, a letter, a note - remember that your words might be read
some day by an unfriendly competitor or customer, or by an enthusiastic
government prosecutor who may interpret its language in the most sinister
way possible.

For this reason:

o  Don't speculate in writing about the legality or ethics of Digital's
   actions. While you should be concerned if you have any questions about
   the legality of any action, the way to handle this situation is to
   contact the Law Department, and to find out. Speculation might be
   thought (incorrectly) to be evidence that the company has recognized
   a law violation, and had tried to camouflage it in some way.
...
"
				/AHM

    I assume .55 is a response to .53?
    
    If so, you disagree with my management of the time, which is
    of course your privilege.
    
    On the other hand, BLISS is a bit of a special case, as we
    have almost no external customers.  The last external bug for
    BLISS was reported on the second of October 1987, and fixed
    on the fifth of October 1987.
    
    		-John Bishop

RE: .54

>I'm not aware of any conferences that are official internal support channels.

The LSE_BUGS conference was such a channel back when I was on the project.
There are other such conferences floating around on the net.  On the other hand,
there are conferences such as VMSNOTES that decidedly and emphatically are NOT
official internal support channels.

Each development group decides on its own whether using NOTES in an official
role is appropriate.  The volume of problem report traffic is often a key
factor.  If my project had to deal with the number of reports that VMS gets, I
wouldn't use NOTES as an official support channel, either.

--PSW

re: .58

It still is.  The LSE project now uses some database management tools to 
track notes in both its internal and external bugs conferences, as well as an
internal task-list notes file and the QAR system.  SPR's get tracked by
entering them into the internal bugs conference.  Periodically the project
leader distributes tasks lists to each of the developers, showing each of
the tasks from all the relevant notes files and the QAR system assigned
to the developer.  I rather liked the system when I worked on LSE, because it
helped me manage my tasks.

The only real problem with using Notes as a support channel is distingushing
the official responses from the project team from the unofficial and less
reliable responses from the the other users (especially us former developers
who think we still know all the answers :-).  I don't see any reason why
a response from a project member in a notes file is any more likely to be
wrong than a response in a QAR system or to an SPR.  Developers do need to be
careful in wording responses going to customers, but people posting problems
are pretty good about mentioning when the problem came from a customer.

   Gary

Re:  <<< Note 1372.54 by SCAACT::AINSLEY "Less than 150 kts. is TOO slow" >>>

> For example, Joe Software is a resident at XYZ Corp.
> Someone at XYZ asks Joe if product Q can be used to perform some function.
> Joe doesn't know, but asks in a NOTES file.  Someone in the NOTES file says
> that it can be done.  Joe tells XYZ that it can be done.  XYZ spends a lot
> of time and money trying to get product Q to perform the function.  Finally,
> it is discovered that product Q can NOT perform the desired fuction.  XYZ
> sues Digital.  When poor Joe is asked where he got this information, he says
> he got it from the NOTES file.  Ahah! Our lawyers say, that NOTES file isn't
> an official support channel.  It says so in 1.0 of the conference.  During
> discovery, someone comes across the EIS memo that states that NOTES conferences
> are offical support channels.


Well, I hate to burst your bubble, But I do this all of the time. Suffice it
to say I don't take everything I hear in a Notes conference as gospel, but it
is and will remain my #1 source for info. If we worried about liability, we
would never speak to a customer without a lawyer present. My job is to be a
business partner with my customer. That means sharing information and
responding to their queries promptly. 

My official source for info on product features is 1-800-DEC-SALE (Remote 
Sales Support). Now this appears to be set-up as an efficient system (with
touch-tone routing of your call, etc)... However, there doesn't seem to be
much more at the other end of the phone than someone with the DECdirect
catalog and the Systems and Options Document. Generally when I call Remote
Sales Support it is with an obscure or unclear issue after sifting through all 
of the product literature I can get my hands on. They try to be helpful, but 
they don't usually have the definitive answers I'm looking for. Its usually a
consensus between me and the support rep regarding our interpretation, based 
on the documentation available, of the product in question. And more than once
the Remote Sales Support people say they frequently garner information from
Notes conferences.

Jim

Jim -

Don't want to go off on tangent, or nit-pick here, since I work at
1-800-DEC-SALE......actually I guess this response could also fit in
Note #1371 "Sales at Digital"....but you mentioned RSS here :-)

>My official source for info on product features is 1-800-DEC-SALE (Remote 
>Sales Support). Now this appears to be set-up as an efficient system (with
>touch-tone routing of your call, etc)...

> However, there doesn't seem to be
>much more at the other end of the phone than someone with the DECdirect
>catalog and the Systems and Options Document. Generally when I call Remote
>Sales Support it is with an obscure or unclear issue after sifting through all 
>of the product literature I can get my hands on. They try to be helpful, but 
>they don't usually have the definitive answers I'm looking for. Its usually a
>consensus between me and the support rep regarding our interpretation, based 
>on the documentation available, of the product in question. And more than once
>the Remote Sales Support people say they frequently garner information from
>Notes conferences.

	Yes, a lot of us use Notes conferences, but I always alert my
	customers, and YOU would be one of my customers.....the source
	of the information, and that it's possible what is posted is not
	the "official" position......if you are being pinned to the mat
	by one of your customers, then I am going to try and reach product
	management for a "bottom-line" answer!!  I am *glad* you don't
	take everything you might read in a notes conference as the
	gospel....  There is a lot of good stuff in the conferences,
	but things have been posted with the best of intentions...then
	turn out to be totally wrong or only partially correct....we
	all know the road to ____ is paved with good intentions.


For those of you not interested in how to *use* 1-800-DEC-SALE, hit
next unseen.....


1-800-DEC-SALE has experienced almost a 200% increase in head-count over
the last year in an effort to shake those other nicknames such as 
1-800-DEC-DEAD or 1-800-DEC-HOLD.....with very few exceptions, all the
slots were filled by AHOD and C.O.D. people.......something that has 
been suggested time and time again in this conference.

Some (few) of us have had field experience; I am on the SW Services and
Licensing team.......our team does something NO C.S. organization does
at this point in time, we handle BOTH licensing and SW services issues.
Our new people are not new to DEC, they are new to DEC-SALE......these
people were promised in-depth training.......they didn't get it.  It
takes a lot of OJT to take a person from a manufacturing environment
and turn them into a services and licensing guru.

I see nothing wrong in our people using the S.O,C. or USPL to answer
questions....usually we are among the first to find discrepancies that
are printed in those publications.  Someone else, maybe you, pointed out
that sales reps can't remember everything.....neither can the specialists
at RSS.  PATHWORKS I can quote in my sleep....some UPI's the same....
but we all have to refer to documentation.....you wouldn't want us to
guess at the answer, right?

I can see where someone like yourself might be frustrated with us....
you are obviously someone who does their homework.....unfortunately,
if you call us with a "stump the expert" type of question....we prob-
ably aren't going to sound as all knowing as you would like.  For *now*,
the intent of our group is to off-load the typical or standard type of
questions that newer field people might ask.  The entire group averages
between 650-700 calls per day.....that's a lot of off-loading that *does*
free up local account support or sales support people.  Hopefully, in
time and if we are freed from the 7 hours per day we spend chained to
our phones, we might get some of that training that was promised...but
training has been put on a back-burner because *upper* sales management
is more concerned with the time it takes us to answer our phones than perhaps
the type of answers we are giving......we also get beat up if we spend
too much time with a sales rep on a call....if ya'll ever get to the
Atlanta CSC, you will see a number of us with flat heads (we get beat
up....long, slow and steady) :-) :-)

Our senior people are more than willing to research answers; but most
often that requires getting to a product manager......quite often we
are told "well, *I* could call the product manager myself". We off-load
a lot of frustration from reps also......many times for issues over which
we have no control......it's hard to sound pleasant and perky when you
are being used as a whipping post a good bit of the time.

I don't want to get started on DEC DIRECT....that could fill a conference
in itself.....those folks are order takers.....we are not.  We KNOW their
charter is to talk to customers.....I have spoken to several supervisory
people within that organization and tried to explain to them that WE know
they only want to talk to the E/U, but if they mail their catalogs into
a large installed base account, such as a Ford or GM.......if that customer
has a question, he is going to call his sales rep for any clarification,
not DEC DIRECT....so far the answers I've gotten fall into "well that's
just the way it is category".  I know if I were a sales rep *I* would be
embarrassed to tell one of my customers that they can get their answer if
they call DEC DIRECT, but I can't get their answer for them....DEC DIRECT
doesn't talk to people in the sales organization...period....end of 
sentence!!  I wish we could have some line of communication between our
two organizations.....but someone higher up the chain would have to make
that decision.  DEC DIRECT won't answer questions for DEC-SALE either :-(
So, if you call us about something you saw in a DEC DIRECT catalog; our
only option is the same as yours......look at the catalog and hope we
can figure out what they were trying to say or convey.

I really didn't mean to single you out Jim.....but a lot of good info
is obtained from Notes conferences......just thought I'd take this
opportunity via Notes to explain "how" DEC-SALE hopes to be of service :-)
Our HW engineers didn't design the equipment.....our SW people did not
write the code.....  We do a lot of hand holding and training over the
phone.....that wasn't part of our original charter, but that's what the
job entails more often than not.

Most of us who plan to stay with DEC-SALE (assuming DEC-SALE doesn't
go away) would like to become more technical, have the freedom _read_
time to "really" research some of the stickier questions and provide
a level of quality support that compares to none.  Again, that takes
co-operation of product managers, sales support & licensing people
at headquarters, etc.......  Most folks at headquarters are very
co-operative once we are able to contact them; but believe me, some
have dished out verbal abuse that is unbelievable!!!

Eveyone is under the gun and under pressure these days.....but if some
product groups *hope* to have their baby sell......they'd better make
sure those of us in a position to help a sale *understand* their product
inside and out.  Some of our printed documentation and Sales Updates
articles just don't hack it; when we try to nail down any ambiguity,
that's where a lot of verbal abuse has taken place.

Regards,

Karen_who_wrote_this_on_her_one_hour_off_phones_READ_lunch_hour! :-) :-)

Thanks for your insight Karen. To be honest with you I try to call you guys as 
little as possible since I have most of the tools you use at my disposal 
anyway (SOC, DECdirect catalog, Notes, VTX, Product Mgmt, etc). I do 
appreciate that your group exists as a resource, though.

I called DECdirect the other day because I didn't understand something in 
their catalog. As you guessed they wouldn't talk to me. I then called 
800-DEC-SALE and essentially used your people as a sanity check of my thinking.

You guys had a pilot where we could send you mail instead of calling. Is that 
service still available? How about setting up an RSS notes conference, too.
When I have a customer question I work to get the RIGHT answer quickly so I'll 
use whatever resources I can to get that answer, including going directly to
Engineering. Hey, I'm empowered by KO himself to do this and before you flame...
I'm not suggesting circumventing the official process, but when I need to
get help, its usually an expert I need...

Regards,

Jim

    
    re:.61  Reese_k
    
    "I know if I were a sales rep *I* would be embarrassed to tell one of
    my customers they could get their answer if they called DECdirect..."
    
    
    I'm *sure* your talking about 800-DIGITAL and *NOT* 800-343-4040....
    The 343-4040 (TCC) reps are trained 1/2 a day EVERY day and are not 
    order takers.....
    
    
    
    
    					pm

    re: .61, .62
    
    Couldn't an internal person who needs information from DEC DIRECT call
    the 800 number and claim to be a customer?

    
    re:.64   Eckert
    
    Employees can and do do what you describe. The TCC does support
    legitimate IEG calls.
    
    
    					pm
    
    

    Re:  64
    
    That is EXACTLY what most sales reps do......don't you think it is
    a little *silly* that they have to go through that charade?  The folks
    at 800-343-4040 probably have no idea of how many "customers" are
    actually sales reps :-) :-)
    
    Re:  63
    
    After I entered my note.....I remembered your division...but fact
    remains, you are still a part of the DEC DIRECT organization....your
    charter is to talk to customers (end users).......I realize that
    you are not order takers, but unless someone has changed your
    policy recently and not informed the rest of the world.......you
    *will not* provide technical pre-sales support to anyone in the 
    sales organization.
    
    Please understand, I'm not knocking *your* group.....I'm annoyed with
    the people who decide who we will and won't talk to.  The fact 
    remains that DEC DIRECT mails its catalogs (and there is a growing
    number of them) to everyone who has ever placed a direct order with
    1-800-DIGITAL......  That means these catalogs get into very large
    installed based accounts.  Now *I* know your charter is to speak with
    the cust/end user......the fact remains that for a large installed
    base account......the customer gets your catalog....something isn't
    clear....like it or not....far too many of the E/U's will *not* call
    you for the explanation, they are going to call the sales rep 
    assigned to their account.....the person whose "face" they know (and
    hopefully love). The sales rep will look at his copy of your catalog,
    say whoa..."that is this?"....but since that sales rep knows he can't
    call you for technical assistance, he calls us....so we're back to
    ground zero.
    
    The CSC's are just as culpable......God forbid a sales rep is on-site
    during an installation, and something out of the ordinary happens.  A
    disaster occurs......the customer runs to his sales rep....the sales
    rep calls 800-DEC-SALE to find out what has happened....we don't do
    end user level support....we're pre-sales....so it's another loop.
    We're supposed to tell the sales rep to have his customer call 
    1-800-DEC-8000 for end user level support...once again we've put one
    of our sales reps in an embarrassing position...and let's face it,
    they are the ones who have to look the customer in the eye.
    
    I hope others haven't been too bored with this.....I think this has
    been very positive....Jim has been gratious enough to admit he didn't
    have all the details as to what 800-DEC-SALE has to deal with, now
    you've pointed out what 800-343-4040 does.....maybe if we all keep
    talkin' in here.....if we have to live with our existing charters
    _read_ funding sources.....we can be easier on one another...and
    maybe....just maybe....make a decision to "do what is right" if some-
    one calls us in dire straits.
    
    I *know* our group isn't to provide E/U level assistance...but a
    number of us have been able to pull it off if we determined that the
    problem WAS NOT the fault of the sales rep....and we try to do 
    whatever it takes to "fix" the problem.  I have personally put other
    friends in the CSC on the spot helping me out (remember their charter
    is to support E/U).........
    
    Isn't this crazy?  Am I  the only one who finds this truly bizarre?
    That's why I tried to stress that I was not knocking all sales reps;
    there are a few sorry "few" who will let or get someone else to do
    their footwork if they can *charm* their way through it.  I would like
    to have the time/freedom to help those reps that I know are *truly*
    caught between a rock and hard spot (as we say in Atlanta) :-) :-)
    
    Karen
    
    
    

    
    re:.66  Reese_k
    
    Karen,
    
    First I'd like to clarify a couple things. The TCC is NOT part of
    DECdirect. We fall under the Direct Marketing Orginization (DMO).
    Although we do directly support DECdirect, we are a  different
    organization. Yes our charter says that we  support e/u's only and
    not sales reps, just as your charter says you will support sales reps
    and not e/u's. Sounds like it should work, doesn't it? I totally
    understand the frustration sales reps must go through and wish our
    organizations could communicate better to end shuffle and charades.
    	The TCC handles almost 7k calls a week. The whole idea is for us
    to *complement* the sales cycle. A sales rep who refers his customer
    to the TCC for answers/config assistance can now better spend his time
    on customer issues that cannot be resloved via phone support. The TCC
    can also provide quotes that a customer can review and hand directly to
    their sales rep without him/her even being involved.
    
    
    
    						pm
    
    
    
    

    PM:
    
    Please understand, I don't have an axe to grind with 800-343-4040;
    OK, so you are not part of DEC DIRECT.....however your 800# 
    appears in all their catalogs......most of the field assumes you are
    a part of that organization, again primarily because you won't 
    speak with a sales person (or one who identifies themselves as such).
    Maybe you folks have some advertising or educating to do  as far as
    what you will/will not handle....and who you can and cannot talk to.  
    
    I don't doubt the volume of calls you are getting; the point I am
    trying to make is that a "named" large volume account has a relation-
    ship with a sales rep or perhaps a sales team.  I don't doubt your
    group could answer some of the questions the customers direct to 
    their sales rep.....the point I'm trying to make is that we are
    placing sales reps who handle the major accounts to DEC in an
    extremely awkward position......
    
    As we've both pointed out......you and I know the charter of your
    group is to speak to E/U's.....however a contact at a large account
    would be offended "big time" if their sales rep said he/she couldn't
    answer a question that might have been generated by something they
    saw in a DEC DIRECT catalog and indicated the customer should call
    800-343-4040.  The whole idea is to STOP forcing the E/U to be calling
    another 800# to get specific info when they are ready to purchase, but
    just may have a few questions to ask....
    
    I'm not knocking the quantity or quality of the support your group
    provides.....but somewhere along the line, we've got to be able to
    utilize one another.  Yes, I have.....and others in my group have
    handled questions that fall under the category of E/U level support.
    It has been pointed out to us that we are taking a chance in doing
    so because WE  are not kept abreast of all the latest and greatest
    workarounds E/U reps are privy to.  As I mentioned before, when our
    management team becomes aware of this, we are called on the carpet.
    
    Jim Mikol made some valid observations, hopefully you and I have
    at least explained to him "why" we have been unable to be of service
    to him at times.....this still doesn't help him if one of his major
    accounts calls regarding something that has appeared in a publication
    and DEC-SALE hears about it the first time from Jim Mikol's lips.
    We still haven't resolved the issue that Jim Mikol would have ONE
    offended customer if he told them to call another number!!  Remember,
    this is "pre"sales we're talking about here.....the customer may
    be waiting in the wings.....P.O. or check in hand.
    
    When a sales rep calls us with what is clearly an E/U issue; usually
    it regards a new sale and the system itself is under warranty.....
    standard warranty gets that customer free telephone support for a year.  I
    think most customers can handle finding out they are entitled to
    unlimited free use of an 800 # for technical support a little more
    palatable to accept, (assuming the sales rep will explain it to them).
    Those very same customers possibly still might be offended in finding
    that they have to call another 800# to get technical info on something
    they wish to purchase......they are standing with money in hand....
    and they expect their assigned sales rep to answer those questions.
    
    I guess the three of us have just reinforced how difficult DEC makes
    it for the customer who really wants to buy something from us.
    
    I was hoping that we could all make clear our charters....but
    hopefully, each organization could have some interaction with the
    other, so if a customer calls his sales rep and REFUSES to call
    another organization.....we can have some channel to provide the
    rep with the answer he/she needs.
    
    Karen_who_is_starting_to_feel_like_a_hamster_on_a_treadmill!