Conference 7.286::digital

	Well, I don't know much about CLD's and SPR's (except I haven't
	received any, which is good enough for me:-), but I see the
	same problems Mike does with QAR's. Response times are way
	down - this may be a result of the growing gap between
	engineering work and engineering resources, but dealing with
	problem reports (particularly from customers) should be
	the last thing to give when setting priorities. 

>It all boils down to the
>    reputation of Digital's response to an SPR.

	One aspect of it is customers having to shout louder to
	get something done. Worse yet, though, is when they give up
	on reporting problems. A recent example was when a group
	submitted several QARs to different products, ours included.
	We responded to ours promptly - some other didn't. The group
	submitting the QAR's didn't notice the difference in response
	rates for the individual components, and gave up on the QAR
	system. Result - problems that should have and could have been
	fixed for the latest release weren't, because we didn't hear
	about them until too late. This is with an internal group, which
	can easily submit electronic QARs - consider how the
	disincentive to take the time is magnified for customers dealing with
	paper SPR forms! I shudder to think how many problems are
	out there that we'll never hear about until it's too late...

	Mike

    According to my customer, the whole SPR system is a waste - they
    have filed SPR's and in some cases never gotten an answer, or worse
    gotten a "we're looking into it" answer which does nothing to solve
    the problem at hand.  As for CLD's, pardon the ignorance of an 8 year
    veteran of field SWS, but what is a CLD??

    SPRs are falling out of favor, but the replacement is not necessarily a
    CLD (which stands for Central Logging Desk).
    
    The CSCs, Customer Support Centers will now take a customer problem
    over DSIN (Digital's Software Information Network) or over the phone
    and prepare a TIME case directly from the information.  This alleviates
    a great deal of the data entry that accompanies the hardcopy SPR
    (Software Performance Report) process.
    
    If everyone that submitted an SPR in the past were now to open a CLD
    instead, it would quickly defeat the purpose of the CLD system.  CLDs
    should be used *where warranted* and one shouldn't hesitate to use one
    under those circumstances.  But if the system becomes clogged with
    unwarranted escalations, it will quickly break.
    
    Quoting from the CLD agreement that CSSE (Customer Service Systems
    Engineering) has developed with each of the geographys:
    
    "1.0 Definition of CLD Process
    
    	Definition of a CLD (Central Log Desk) call:
    
    	'The management escalation of a critical customer situation which
    warrants the highest priority attention by the appropriate Corporate
    group.'
    
    	THE CALL IS CLASSIFIED AS 'CLD' BY MANAGEMENT
    
    	- The call is classified as a CLD call by an "Area" Support
    Manager, Corporate Support Manager, or a Corporate Customer Relations
    Manager.
    
    	The following is provided as example and is not a definitive list:
    
    	- The call is escalated from one Corporate group (i.e., VAX
    hardware) requiring another Corporate group (i.e., Networks) assistance
    for problems originally escalated within their organization.
    
    	- The call is for Corporate supported Products/Services.  (Product
    Safety, Environmental Support, Specified CSS products).
    
    	- This is not limited to "Engineering" only problems. (Political,
    Legal, etc.)"
    
    The document continues on how to log a CLD, the flow of a CLD, etc.
    
    regards,
    Marge

RE: .2

One thing they don't tell the SS folks is that it seems to be Field
Circus's responsibility to handle problems when a customer's system is
"broken". It does not matter if the problem is hardware or software. 

My interpretation of a CLD (your mileage may vary) from the software
perspective (I assume the FS has CLDs for hardware?) is that if you have
a customer who is having a problem that is preventing him from doing
work (the software equivalent of a Disk crash or memory failure) then
you do a CLD (SPD noncompliance problems without a usable work around).  

CLDs are done through FS so if you have a customer with potential CLD
type problem it is a nice idea to let the FS manager know about the
situation so he isn't completely surprised when you ask him to turn in a
CLD. 

Don't expect miracles, CLDs are often just a fast as SPRs and once you
do a CLD the problem is in someone elses hands so you are no longer in
control.  On the other hand at least someone does look at CLDs.  Rumor
has it that the address people send SPRs to is a landfill.

John

    I ran the CLD software system for 2 years so maybe I can shed some
    light.  First and foremost, the CLD system is NOT available to
    customers.  It is an internal call handling system for Field Service
    Personnel to use when escalating a critical call to Corporate.
    
    Initially, the customer had to be down in order for a corporate
    CLD to be logged.  That has since been expanded to include what we 
    used to call, "customer pain".  But as far as who logs the CLD, nothing
    has changed.  The chain of escalation is a logical one.  The Field
    Service Engineer tries to solve a problem, can't and involves the
    district office.  An engineer from that office, (the districts
    used to share expertise and I believe still do), visits the customer
    and also cannot resolve the issue.  The district person involves
    the CSC, (or there may be one other layer in there - it's been a
    while!).  The CSCs, (Atlanta, Colorado, Kanata, Munich, Westboro,
    Valbonne, Basingstoke and one or two more), have their own level of 
    expertise, (also shareable), and make an attempt to solve the
    problem.  Time obviously passes here and if nothing has worked, the 
    level of customer pain is increasing.  If/when the situation becomes 
    critical, (and even political issues can become critical), the CSCs 
    log a corporate CLD.  I got them.  I had a list of every single expert 
    in every single area of Digital which I kept current.  When they heard from
    me, there were often heavy sighs and "oh nos", but a corporate CLD
    means drop everything.  And they do.
    
    To keep CSCs from "crying wolf" and lowering the value of the CLD
    as a flag revealing a hot, hot, HOT situation, we were vigilant in turning
    away any CLD that was not critical.  I don't know how "clean" the
    current CLD person keeps the system, but I doubt it's changed. 
    A CLD has to come to corporate with a complete history and an action
    plan to avoid a level simply saying, "I dunno, YOU try".  I remember
    the first Xmas Eve I worked at the CLD desk.  Escalations came thick
    and fast as engineers simply passed on the problems and went home.
    We took care of that in short order!
    
    Bottom line is, CLD versus SPR is NOT an option.  The case itself
    determines which system is used.  If it isn't burning hot, you won't get
    a CLD logged.  Intermediate systems are PRISM, (originally for hardware
    problems), and TIME, (for software).  Confidence in PRISM was very
    low when I started but by the time I left, PRISM had become respectable
    and plans were in place to use PRISM for both hardware and software
    and to do away with TIME.  Where that stands now, I don't know, but
    I do know PRISM is still working and has expanded to include not
    only software, but documentation issues, diagnostics issues and
    is even being used by manufacturing to capture installation information
    so that manufacturing can see bad trends and correct their processes.
      
    You might decide between logging a PRISM and an SPR but the CLD option
    isn't so available.  Every district office should have a PRISM server
    and a trained administrator.  As for SPRs, well, I just didn't have
    any dealings with those but I did hear often that the system was
    somewhat lacking.  Give PRISM a try.  It does work.  Recipients
    of cases have response time limits and we at the PRISM office enforced 
    them.  I know.  I wrote the book on it!
    
    Sandy

    I don't have any complaints about the CLD system---the little contact I
    have had with it has been positive.  The SPR system, however, appears
    to be almost completely broken.
    
    It can take weeks, or even months, for an SPR to get from SPR
    Administration to the engineering group responsible for the product.
    I've tried to find out why, but I don't know where to look in SPR
    Administration.  I have tracked SPRs for my product from the Colorado
    Springs CSC to SPR Administration, but after that they seem to fall
    into a black hole.  There must be somebody at SPR Administration,
    because we do occasionally get an SPR.
    
    Can somebody give me the name of a responsible person in SPR
    Administration?  I don't know if I can fix this problem, but I'd like
    to at least complain in the right place.
        John Sauter

    SPR system broken ? Not for everybody. We still have Engineering
    groups that take support seriously. 

    	drum rolls .... THE WACE engineering in Reading.

    SPRs get answered , turn around times are reasonable, I was getting a
    weekly list with the statuses of opened SPRs for VAX PSI. DEC/X@%router
    WDDK, VOTS and OSAK. 

    But it really doesn't matter how is it called, every engineering group
    needs a system to trace reported problems. Some chose the obvious, the
    SPR system , some re-make the world to their own view of the things
    and QAR everything. Others do it very differently... [ icon for
    wastebasket here ]. But everybody waits for  ( TIME ?)  one problem
    reporting system for everybody. It is difficult to believe but we don't
    have any.

    We need a QAR system for FT problems and SPR for customer problems.
    SPR system did broke for some products, because of too many bugs...

    BUT, the SPRs and QARs are for reporting technical problems.

    CLD is a system for reporting and monitoring escalation within
    DEC. 

    SPRs "solve problems" . CLDs make sure that resources are
    applied to solve problems. SPRs carry technical info, CLD describe
    actions taken to resolve the problem.
    So, a CLD is not an alternative to an SPR. Problem reported via SPR
    may result in a CLD if solution is not provided on time.

    CLD, there are two types of it. The old ones OCLD and new ones NCLD.

    OLD CLD is the one described in .5, a critical customer situation.
    DEC is on the line, drop everything to work on it etc.

    The NEW CLD is just another SPR . This is the only way some areas may
    access what is left of corporate support. So, the system got broken
    some time ago, now there is some effort to put it back in shape.
    Eventually some people understood that there is a need for technical
    escalation ( SPRs + any internal escalations we have , like ECSO in
    Europe) and a system for handling truly critical situations ( CLDs).

    Unfortunately this is not clear to everybody. With the NCLD, there is
    still a system for exceptions, call to VP, something everybody wants
    to avoid. 

    					wlodek

    In saying that the SPR system was broken I was not referring to
    the product groups that answer SPRs being unresponsive but to
    the administrative group that conveys SPRs to the product groups
    being inefficient.
    
    The "new" CLD process described in 1026.7 is news to me, but I don't
    find it surprising.  It appears to be a response to the breakdown of
    the SPR distribution process.  I wonder how long the new process will
    have to be in place before we formally retire the old one?
        John Sauter

	Easy:

	File an SPR when you need a response within 3 years.

	Start a CLD if you want it handled within 3 weeks.

	SCH

    	Look at it this way:
    
    	An SPR is a mechanism of reporting a problem, comment or
    	suggestion to engineering.  Engineering is committed to a 
    	response but realistically the speed of the response is 
    	typically a function of how the commitments of individual
    	engineers get prioritized.
    
    	A CLD is a Field Service mechanism for giving visibility to
    	critical problems, identifying the responsible parties and
    	setting up a means of providing problem resolution status.
    	This mechanism is often helpful in prioritizing the commitments
    	of individual engineers.
    
    	Summary:  These are two different mechanisms controlled by two
    	different organizations within Digital.  Although there is an
    	overlap in interests (the primary one being customer satisfaction),
    	critical problems should be reported using both processes.
    	Their function is not the same.
    
    		- ken

    re: Sandy
    
    They never made PRISM take on software... still looking at changes
    to TIME tho.
    
    grins,
    Marge
    
    p.s. Christmas Eve hasn't changed a bit :^)

    I have it on semi-reliable authority that SPR ADMIN has a 3 month
    backlog (or was it 3 weeks, I think 3 months) of SPRs to enter into
    TIME.
    
    That's why when you tell the CSC to SPR something you don't see the
    SPR for AGES.
    
    Also engineering (at least that is our group) respond to CLDs before
    SPRS. Yes even priority 1 SPRS. If the SPR is truly a priority 1 SPR
    the customer will get his F/S person to turn it into a CLD. Then it
    goes in the CLD queue.
    
    SPRS unfortunately I now used for little more than info to engineering
    and engineering sets the timescale to answer them CLDs on the other
    hand are driven by F/S and if engineering don't appear to be moving
    fast enough F/S and NCSS/CSSE seem to be able to influence engineering
    priorities to get the problem fixed.
    
    Dave

It seems to me that the distinctions drawn between SPRs and CLDs are
logicaly incorrect.  

From the CUSTOMER's point of view, SOMETHING doesn't work.  The first
DEC person he sees about it is the FS engineer.  In the customer's view 
this FS person owns, ON BEHALF OF Digital, the customer's problem.  How the 
problem gets fixed is irrelevant to the CUSTOMER, as long as it gets 
fixed ASAP.  After all, that's the kind of service he THOUGHT he bought 
when he purchased Digital systems.

Starting with the first FS person, the PROBLEM should get Digital's attention,
with the CSF (critical success factor) of fixing it to the CUSTOMER's 
satisfaction.  This implies that Digital engages the correct resources 
to analyse and solve the problem in a TIMELY manner.

From this analysis of the process it's clear that the SPR and CLD processes
(ie. problem analysis and resource allocation) are the two parts of the same 
process, namely problem fixing, and that their artificial separation can only 
serve to satisfy Digital's INTERNAL PROCEDURES, without regard for the 
original CSF of CUSTOMER SATISFACTION.

The discussion about which computer system (TIME, PRISM,...) appears to
be Kafkaesque (re. The Trial).  It seems to me that the CSF of customer
satisfaction has been lost in Digital's administrative procedures here.

David Goldblatt - Europe I.M.

    David, you have a lot of support for your position in Stow.  They are
    currently working to merge the problem resolutions systems into one,
    while retaining a "priority" code which would reflect the customer's
    sense of urgency.  What we have today is a tangled mess.
    
    regards,
    

    CLD is a component of a bigger process called MAP (Management Action
    Planning).  MAP is the internal process used by CUSTOMER SERVICES
    to manage a customer outage and to insure the correct resources
    are involved.  Within MAP is a hard and fast communication schedule.
    Management at all levels end up communicating daily.  The system,
    as it id written, looks good.  If used correctly and not abused
    or used as a weapon between functional groups, I have seen MAP become
    a useful tool.  It even causes all of the parties involved to know
    what the rest of the problem resolution team is doing!  
    
    As far as hardware vs software problems, the distinction has been
    removed at the field (customer) level.  Customer Services, as it
    has been renamed, manages both types of problems and has the charter
    to resolve hardware as well as software problems.  I can attest
    to this being the way it is because I have personnaly been responsible
    for the resolution of both types of problems.  Hardware CLD's usually
    start within a Didtrict office and proceed upward until they are
    resolved or reach an engineering group at corporate.  Software issues
    usually become a CLD through what is called an LOR (Local Office
    Referral).  This is a process through which a CSC group can document
    a customer software complaint and, if not fixable at the CSC level
    AND it appears that the problem is having a seroius impact on the
    customers ability to do business, a Local Office Referral is initiated.
    The LOR will be logged at the district office level and if it can't
    be resolved/patched/worked around within a short (usually 48 hour)
    time, the district office will take all of the LOR information and
    build it into what becomes a CLD at the area level.  From there
    on up, the flow is the same, just that different people are involved.
    
    Where the problems pop up are when one of our more vocal customers
    catches on to this internal process.  The can circumvent the
    established SPR and problem resolution procedures by making the
    business impact of a problem sound MUCH more severe than it really
    is.  I have been involved with these types of "severe" problems
    where the customer, when we hit the site, don't really have time
    to work with us on 'that issue' because they really are not using
    that product at this time!  (This was the response we got on the
    last LOR I was involved in)  They just seem to feel better if they
    get to the CLD point because now Digital is calling them almost
    daily and they know the problem is being addressed.  Maybe we could
    take an honest and objective look at WHY our sophisticated customers
    try to do this.  Is it because SPR's don't get a verbal response
    in a timely fashion?  Is it because they feel better when Customer
    Services manages the issue (because we are good at it!)?  What is
    the REAL issue?
    
    Rich
    Area Service Delivery Support
    		or
    Customer Services
    		or
    .......Todays title here........
    
                Q   Q
                  
                  |
                \___/ 
                  
    

    Having noticed a few familiar names in this topic, which whom I had
    the pleasure to "fight out" a few CLD battles, (Hi Sandy, Marge, Wlodek
    Annibal....), I cannot resist to add my two centimes worth of former
    Valbonne "CLD manager" experience:
    
    1- Yes, the SPR process is broken
    2- Yes, the sacred CLD process started to suffer from it.
    
    Inventing a new "super CLD" or other process makes no sense as long as:
    
    1-The powers who fund engineering do not feel the pain of bad
      product performance more direct.
      The fact that CS, including CSSE who feel the pain take their
      "revenge" by tightening maintainability specs for the next
      version, next product... doesn't really help.
      How about "measuring" a business unit's performance not only
      by product revenue, but product revenue divided by number of
      CLD's or similar ?
    
    2-The field claims to be self-sufficient to fix themselves all
      of our products (unless a true engineering problem is the cause)
      This is true, but only as long as the many support centers
      be it regional, CSC's whatever... are ready to accept sharing
      the resources. With tight budget control and mini-cost center
      focus, this is less and less the case.
    
    3-The real problem is not problem management. We deserve
      Excellence awards in this domain. The real problem is
      PROBLEM FIXING ! There are less and less people "chartered"
      and/or motivated to do so. A high level support engineer who
      likes and knows how to fix things this days isnt "in"
      anymore. The fashion is "proactiveness" and its not only a fashion
      it's also rewarding and promotion generating.
    
    Just a few thoughts (I have a few more)
    Fred

    re: .15---I believe the problem is that SPRs aren't getting timely
    answers.
    
    re: .16---I don't think the problem with responsiveness is with the
    product development groups (or its management) not feeling the pain
    of poor quality products.  We do feel it!  The problem is that the
    people who know how to fix problems ("high level support engineers"
    of your third point) aren't learning of the problems quickly enough
    to fix them soon enough to meet customers' expectations.
    
    When I worked on EDT, a very popular product, in 1980-1983 we averaged
    one SPR per working day.  The SPRs were delivered to us daily, and
    we generally turned them around in 24 hours.  Sometimes turnaround took
    two days, but never as long as a week, even for the hard problems.
    
    By comparing the date that the customer wrote on the SPR form to the
    date we received it, and then doubling that interval to account for
    the return time, we could estimate the time from when a customer
    wrote an SPR to when he got the response back in his hands.  I no
    longer remember for sure how long that was, but I believe it was less
    than a month, at least for U.S. customers.
    
    In those days there was no abuse of the CLD process.  Perhaps if we
    could get the turnaround time back down to a month, the abuse would
    cease.
        John Sauter

    What happens with the technically difficult SPR pri 3 problems 
    ( serious itching ? ) ?

    Typical CSC can't fix it and can't escalate it , so the itching
    develops to a serious infection. And then BANG , CLD arrives.
    I have seen it few times. There is no way to really escalate
    based on technicality of the problem, so the system tends to keep
    the customer "reasonably" unhappy.

    SPR admin doesn't seem  to be a bottleneck.
    I've just checked the few SPRs I had sent, and corporate admin at
    ICARUS takes 5-10 days to confirm an SPR. By this time, the problem
    should have been sent to proper engineering/CSSE group.

    Reading WACE had own SPR Admin ( now centralized to ICARUS (Stowe)),
    it took typically 1-3 days to have an SPR confirmed .

    				wlodek

    Without any real familiarity with either the SPR system or the CLD
    system, I can't comment on the words written here.  But I can comment
    on the music I hear.
    
    Many people say the SPR system is broken, based on the intolerably long
    response time as perceived by customers.
    
    The CLD system, I gather, was implemented to "fix" the broken SPR
    system.  Instead, it only added a level of bureaucracy, thus confusing
    some people as to which to use, and creating a loophole for other
    people to use to avoid the SPR system.
    
    Now, it would appear, the CLD system is broken too, based on the calls
    for yet another reporting system, presumably to be added on top of SPR
    and CLD.
    
    You can't build new systems on top of broken ones.  Fix the SPR system!

    
    " Without real famil...."
    
    	so why bother ?
    

    Hi, Fred :^)  Hi, Sandy !
    
    re several:
    
    The problem of the multitude of problem reporting/escalation systems is
    due to go away, I've been told.  The folks in Stow are trying to come
    up with a single system with customer priority codes.  That way, all
    you need to do is list the priority code, not determine which system to
    use to escalate the problem, and then set priority.  The interface to
    this single system will be published so that folks who have developed
    their own, home-grown problem tracking systems can write a bridge.
    
    Also, some of the delays that Engineering and the CSSE support groups
    are seeing in the routing of SPRs will not be evident in GIA and
    European SPRs because they come in to SPR Admin pre-screened.  The
    screening time/effort does not show up in the TIME system.
    
    fyi,
    Marge

    The SPR system as we knew it (few years ago), cannot work anymore and
    this is why we have changed it in Europe.

    The system was that customers were sending SPRs via local SPR
    administration to CSSE/Engineering. With the huge customer installed
    base, thousands of SPRs were generated. Some very popular products, like
    ALL-IN-1 ( did I get the spelling right, you all-in-one bigots out there.-)
    grew much faster ( and had some initial teething pains) then the
    central support resources. So, there was/is no chance to take care of
    such SPR mountain unless engineering/CSSE group grows out of
    proportion. Also, recipient of the SPR is too long away from the
    customer, any additional piece of information, etc took too long time
    to get. Clearly, the sheer size of our installed base is such that a
    central SPR system could not handle it.
    The answer to the problem is decentralization.

    In Europe, all SPRs ( apart from pri 4, "suggestions") are turned into
    CSC calls and handled as such. Some of these are escalated further to
    Engineering. No European SPRs should go directly to CSSE/Engineering.


    If US customers still send SPRs directly to CSSE/Engineering, then 
    there is a risk that US organization uses more central resources
    then other areas. Sooner or later Central Engineering will get
    tired of running CS operation for US CS .
    						wlodek
    					wlodek

I work in Spitbrook (ZK) in the VMS development group.  Specifically, I work on
DECwindows.  Did you know that VMS/DECwindows is perfect?

What I mean is that we have NEVER gotten an SPR.  And I've been in the group
for almost 3 years, and we've had a product out for 2 years.

When I asked about this, the first answer was "Well, we're perfect."
I pushed back.  Then they said, "Well, don't worry about it."  Then I yelled.
They said, "We'll check into it."  A couple of months later, "We found out
where the SPRs go.  They go to the mumblemumble group in mumble (3000 miles
away)."

I said, "Well, what good does that do us, and what good does it do the
customer?"  They said, "Well, mumblemumble's job is to act as a clearinghouse
and keep development free to do development."  I said, "Well, can we
at least get to *see* the SPRs?  Even if we're not allowed to answer
them?"  Apparently, by this time there had been thousands of calls and
SPRs on DECwindows.  We still had yet to see one of them here in ZK.

The end of the story?  We still don't get to answer SPRs, we don't get
to see them, and we don't get a summary, and now we have the mumblemumble
group mad as us because they think we are trouble makers and are trying
to put them out of a job.

And the customers?  I'll leave that part of the story to your imagination.

And me?  Believe me, I was the only one in the group who even seemed to care
about this, and I certainly didn't earn any brownie points by making
it known.  By now, my management has quietly forgotten about the
whole thing.  After all, we "so overloaded we can't be taking time to
respond to hundreds of individual customers [who send SPRs]."

IS THIS RIGHT?  CAN YOU BELIEVE IT?  BELIEVE IT OR NOT, THIS IS DIGITAL!

-steve-

PS.  This isn't how we did it at "DEC".   :?

re: -1,

	This only confirms my suspicions that we really do have a *major*
    problem here.  Good job questioning authority!

				    -davo

I find the idea of engineering not getting (even filtered) customer reports
to be rather frightening...

Charlie

    I am not involved with support, but participated in the early
    definition of the VMS problem reporting process.  I believe that the
    following is still the case:
    
    VMS SPRs still get to engineering, but not on the paper form known as
    an SPR.  They are screened to ensure that engineering only gets one
    copy if there are multiple reports.  This is done at the request of VMS
    engineering.  The SPRs are also screened to ensure that they are really
    problems and that there is no known solution, also done at the request
    of VMS engineering.  Then all problems, whether from calls to a support
    center or from paper SPRs are entered as TIME cases, also at the
    request of VMS Engineering.  Once engineering provides solutions, the
    support center provides the solution to the customer.

  
  Going back to some of Wlodeks' points in .22, he raises some 
  interesting issues around resources and bottlenecks that I used to 
  worry about when I was in CSSE. Somehow or other I hope that this 
  new system/process (.14,.21) can try to address them... ?
  
  If you are in the situation where there are more problems reported than 
  Engineers to fix them, then no matter what vehicle you use to flag a 
  problem, it will only end up in a queue. At that stage you really do 
  have to look at the quality of the product, or the resource levels 
  within the Engineering group looking at problem solving. You then start
  into the age old problem of development work vs fixing current problem.
  				
  If the level of problems reported into Engineering was at a containable
  level, then SPRs and CLDs did seem to work well together (once they 
  reached Engineering). One would flag the technical priority level 
  (SPRs), the other the political pain that the customer was feeling 
  (CLDs) - however insignificant in a *technical* sense to Engineering. 
  
  If the mechanisms now get replaced by a process that can emcompass 
  the two (?) current procedures then all well and good. The problem that 
  you are still faced with and cannot get away with is the overload
  scenario. That has to be delt with at a different level. Anyone know
  any good magicians?
  
  So, given a finite amount of resources in Engineering, and different
  Areas sometimes competing for those same resources (as Wlodek pointed out) - 
  who is to be the arbiter of the most critical problem? Should it be the 
  business manager of the Product Development Team, ie the Product Manager ? 
  Or should it be a consensus of opinion of the Area support people from the 
  different Areas ? Or should it be Engineering ? Or should it be the 
  Account Managers battling it out ? Will everyone work by the same 
  escalation rules ?
  
  One further point - how does Drive or the "flattening of the pyramid of 
  escalation" structure fit into all this ? I may well be totally out of 
  touch with the theory here - so correct me where I'm wrong.. With 
  everyone in every country and every office theoretically able to open 
  the equivalent of a priority 1 CLD and have the attention of Engineering, 
  who is going to:
  
  1. Verify that the highest level or expertise in support have looked 
  at (and gone a lot of the way to fix) the problem? Someone said earlier 
  that resource sharing wasn't working too well.. (.16?)
  
  and 
  
  2. Again, arbitrate as to who gets first cut of the Engineering resources ?
  This time it won't just be Areas competing for the same resource, but 
  every office in every country.
  
  Angela (ex CSSE)	
                                                 

    Angela has some very valid points, we are only learning the new CLD
    processes in Europe and I think that "inflation" of CLD is something
    that we want to avoid. The word is "use all available resources
    before a CLD", so Area should be involved.


    SPRs/CLDs are essential pieces of CS business, which is "Customer 
    Satisfaction", this is what CS changes this process without actually
    informing other groups in he corporation that also use SPRs (Engineering). 
    This is pity. With the pre-screening of SPRs, there is definitely a
    piece of information about the life of a products that escapes
    Engineering. So, please listen to us field folks !

    IBM has an interesting system, part of development team goes out with a
    new release and supports it for a while in the field. I heard that some
    groups in DEC do it, but maybe one should generalize this excellent idea?

>   <<< Note 1026.26 by CSSE32::RHINE "Jack Rhine, Manager, CSSE/VMS Group" >>>
>                            -< There are VMS SPRs! >-
>
>    I am not involved with support, but participated in the early
>    definition of the VMS problem reporting process.  I believe that the
>    following is still the case:
>    
>    VMS SPRs still get to engineering, but not on the paper form known as
>    an SPR.  They are screened to ensure that engineering only gets one
>    copy if there are multiple reports.  This is done at the request of VMS
>    engineering.  The SPRs are also screened to ensure that they are really
>    problems and that there is no known solution, also done at the request
>    of VMS engineering.  Then all problems, whether from calls to a support
>    center or from paper SPRs are entered as TIME cases, also at the
>    request of VMS Engineering.  Once engineering provides solutions, the
>    support center provides the solution to the customer.

Sorry, but our group has never gotten to see any of our SPRs.  Or call
reports.  The most recent excuse was "there is no mechanism in place for that
information to be exchanged."  This may not be true for all VMS projects,
but it is for VMS/DECwindows.

The screening of SPRs at the request of "VMS engineering" sounds like
the proverbial "THEY told us to do it that way."  By now, THEY are
nameless, faceless people (I'll bet this was decided by a committee -
tell me I'm wrong), and the procedures they invented are preventing
us from getting the information we need to improve our products.  And
it seems there's no way around it, since so many jobs are now involved.  And
the committee has undoubtedly been disbanded.

I know of no way to access the TIME database, so I can't check on whether
our SPRs and calls are, in fact, entered there.  The last answer I got
when I asked about that was, "maybe someday, when the new QAR system
is implemented."  I wouldn't even know where to begin.

As far as needing someone to filter customer input because I am overloaded,
I am not that overloaded and never have been.  I do not appreciate the
efforts of management to protect me from information overload.  I'm a big
boy now.  I'm a fast reader.  And typist.  If there are so many bug
reports that I can't even find time to answer them, then the solution is
not to hide them from me.  [I do not believe that this is, in fact,
the case.  But it probably was part of the original justification for 
putting this procedure in place.]


RE: John Sauter:

I will not go out to mumble-ville for a week and beg to be allowed
to see what the customers are saying about my software.  It is part of my
job to be involved in the loop.  Now that I think about it, one of our
team members did meet with the mumble-mumble group and came home
with a bunch of promises - none of which have been fulfilled.  And
that was about a year ago.


It all makes me wonder why I bother.

-steve-

    Anent .20 (WLODEK):  Thank you for your snide reply 8^)
    I would consider Reply .23 to be sufficient for an indictment of the
    SPR system.  In fact, I think .23 is sufficient to get a conviction.
    The prosecution rests.
    
    I urge Mr. Klein to forward his note to his vice president.

    I once had it explained to me in the following manner:
    
    SPR's are a carry over from the SWS days, prior to Customer services
    taken on the responsibility for SPS.  SPR's were to be used to report
    any discrepency against the SPD. That is the software works as
    designed, but the way it is designed is not in line with the Softward
    Product Description.  The SPR is used to notify the Company that the
    product is not meeting specs.  There was never a commited response of
    an answer to the customer.  This is understandable as many SPR's could
    be generated over the same issue.
    
    CLD's are indeed the Customer Services mechanism for technical and
    managerial escalations.  A normal Customer Services call should be
    logged is a software product is indeed "broke".  That is it used to
    work but now it does not.  Once a call is logged it can be transferred
    to the local district either as a normal call or as a variety of LOR's
    (local office referals) depending on the priority.  Once in the hands
    of the local Customer Services group it should be handled or escalated
    as per the MAP strategy.   
    
    Unfortunately,  the transition of SPS to Customer Services was done in
    a haphazard manner and the customer was left hanging and not knowing
    the mechanism for satisfaction.  A call logged to Customer Services
    will get the visibility necessary to have whatever resources necessary
    put on the case.  Unfortunately, we have not gotten this information to
    the customer nor to our own employees.  There is currently a new SPS
    introduction Course available (mandatory) for all Customer Services
    Unit Managers.  A proper way of temporarily fixing this is to have
    every SPR prescreened to see if it is really "broken" so it can be
    transferred to Customer Services in a timely manner.  Real SPR's can
    then be worked by the correct group.
    
    
    Again this is not "gospel according to Joe" but just they way I was
    told it was supposed to be.
    
    
    Joe

re .27:

>>>  If you are in the situation where there are more problems reported than 
>>>  Engineers to fix them, then no matter what vehicle you use to flag a 
>>>  problem, it will only end up in a queue

	This is true until you start to structure or prioritize the
	problems. That is, all problems that can be finally fixed
	only by a product modification must go in a queue. But that
	is not necessarily the only way to solve a customer's problem.
	"The thing is to fix the customer". That's not cynical, it's
	true. So FMS with Datatrieve doesn't do something right, maybe
	there's another/better/different thing the customer can do.
	What he really wants is a given screen format, maybe. Remember
	Ken Olsen's story - "what the customer wants is a hole".

	As a veteran of Field Service, Remote Diagnosis, TSC and
	Country Support, now working for EIS in a Marketing Support
	role, I have a fairly wide perspective over this problem.
	Here are some suggestions:

	(1) Over and over, every day, we have to remind ourselves to
	    adopt a customer viewpoint. The customer is the centre,
	    the source of all our revenue, the reason for all our
	    efforts. Our processes should ALL, without exception,
	    be freely adaptable to the customers' needs. That's the
	    only way we can be successful.

	(2) We provide a Customer Support Centre where customers can
	    report their problems to a single point of contact. So far,
	    so very good. (Note - it will be very good IF the CSC
	    presents a friendly, sympathetic, pleasant, understanding,
	    positive, flexible and helpful aspect to the customer. If
	    it behaves like a public utility or Ma Bell, we will lose
	    a lot of the credit we have earned.)

	(3) Customers report different things. The SPR system acknowledges
	    this with the varying levels of severity, but I don't believe
	    we have fully accepted the consequences. There are three separate
	    activities which may be necessary in dealing with each customer
	    call:

		- Fixing the customer's real, immediate problem. The
		  criterion for having done this is simply "The customer
		  is completely satisfied with his solution and is pleased
		  with the manner in which it was delivered - quick,
		  friendly, professional and responsive."

		- Queueing and arranging to fix the long-term bug or
		  deficiency. This must be dealt with as soon as practical.

		- Collecting all customer suggestions, requests for
		  enhancements, perceptions that a product is "pointed
		  in the wrong direction", perceived difficulties in
		  using the product(s) to accomplish his goals. These
		  should be eagerly sifted through and queued to
		  Marketing and the engineering groups responsible for
		  planning future products and releases of existing
		  products.

The first activity is really critical, and must be given the highest possible
priority. The second will clearly take weeks, months, or in some cases even
years. The third is often not recognised, but is very IMPORTANT although
not URGENT.

Our problems mainly stem from confusing these different activities. When
activity (1) has to wait for activity (2), we get a really mad customer.
Moreover, the support people are not funded for activity (3), so they
may impatiently reject or "bin" these precious insights into what our
customers really want, because they are not funded for them.

As usual, all of this happens because process has become institutionalized
and turned to stone. People cease to ask "why are we doing this"? Managers
do not measure and reward people for doing the right things, but for
excelling along partial and inappropriate metrics.

/Tom

    re: .30
    
    I have a different attitude.  Maybe in an ideal world I wouldn't have
    to beg, but Digital is the way it is, today.  My job is to develop a
    product that meets customers' needs, so they'll buy it.  I'll do what
    I need to in order to get the information that is necessary for me to
    do my job.  Just getting promises isn't good enough---you've got to
    follow up.  If necessary, make a nuisance of yourself until they give
    you what they promised so you won't bug them any more.
    
    re: .32
    
    In my opinion, a customer who is motivated enough to write an SPR is
    pretty motivated.  It's the equivalent of a voter writing to his
    Senator.  I believe that every SPR we receive from a customer deserves
    an answer, just as Senators are scrupulous about answering every letter
    from their constituants.  It can be a "form" answer, as long as it
    addresses the points brought up in the SPR.  When I worked on EDT I
    maintained a file of previous answers and some standard paragraphs.
    Frequently, an SPR response could be constructed from paragraphs
    taken from previous answers.  I wouldn't be surprised if Senators used
    a similar system.
    
    I don't object to "pre-screening" SPRs to see if the product is "really
    broken".  I do object to not responding to SPRs, and I do object to not
    letting the product groups see the SPRs.  The product groups need to
    see the SPRs so they can get a feel for how customers are reacting to
    the product.  This feel is vital during planning for the next version.
    
    re: .33
    
    In my experience, the specialists at the Colorado Springs CSC are, in
    fact, friendly, sympathetic, pleasant, understanding, positive,
    flexible and helpful.  They are also very good at holding a customer's
    hand without offending him.  I once heard a specialist tell a customer
    to open a certain manual to a particular page, and then practically
    read to him from the manual, without offending him in the slightest.
    That takes a lot of skill.
    
    I agree with your 3-level categorization of customer problems.  I
    thought that CLDs were for the first class, normal SPRs for the second,
    and suggestion SPRs for the third.  Perhaps that isn't the case any
    more.
        John Sauter 

    Customer SPR is something we carry over from the times when 
    we didn't have software support contracts. Back then, SPR was the
    only way to talk to DEC about problems ( just about the only one...).
    So, at this time, SPRs did really reflect customer reality.
    Today, SPRs report probably a tiny minority of problems, often for the
    out of contract customers. It's so much easier to dial into DEC
    ( if you have the right contract) and enter a problem directly or
    just call CSC. 
    So, if you need to know where is the product and what are problem
    areas, I don't think there is any replacement for a visit to CSC and
    a chat with specialists there. Or sending an engineer to help out
    during product introduction. 

    				wlodek

    I have my doubts about pre-screening of SPRs. I guess that's because
    back when I was an engineer in a group that shipped product to
    customers I saw a lot of SPRs that should never have gotten past
    anyone with any understanding of the product at all. But that is
    6 year old data so I'm willing to assume things are better now.

    The more I read in this topic the more I wonder if we're addressing
    the right problem though. What is it the customer wants? Is
    it fast accurate fixes to bugs or is it software that works?
    When I was a customer the latter was what I was interested in.
    Has that changed?

    Most of the process problems with SPRs or CLDs would ease up
    quite a bit if we had fewer bugs to fix. Seems to me we'd be
    better off working on that problem than the SPR/CLD process.

    		Alfred

    re: .36
    
    I agree that the customer wants software that works.  However, there
    are two classes of "doesn't work":
    
    	1.  The software doesn't do what the developer intended it to do
    	    (e.g., ACCVIOs).
    
    	2.  The software doesn't do what the customer wants it to do.
    
    In the first case it is easy to understand what needs to be done: there
    is a "bug", in the traditional sense (Grace Murray Hopper's sense) in
    the program, and it needs to be fixed.
    
    The second case is usually harder to understand, but is no less
    important to the customer.  If our products don't meet his needs, no
    matter why, he will buy others' products that _do_ meet his needs.
    Part of the reason for the SPR process is to understand the second
    class of bugs, and be able to fix them.  I would hate to see that lost
    in the name of "more efficiency" or "making better use of developers'
    time".
        John Sauter

    
    
    Ok, I've been reading this for the last week or so. Here's my perspective.

    I work in the VIA group of the CSC in Britain. We get loads of calls
    each day and fix most of them. If we can not fix the problem, and
    we can reproduce it on our machine, and it is still happens on the
    field test version of the software on the field test cluster, then
    WE (eg the Support peep) raises an SPR. This is an electronic SPR
    that we write using a .EXE in SYS$MANAGER. I mail this to our SPR
    person who gives it a 'field number' and then mails this to the
    SPR administrator in CSSE. They farm it out to whichever group looks
    at SPR's for that product. This is slightly different if there are
    tapes/printouts to accompany an SPR. These are mailed seperately.
    
    When I started here 18 months customers hated raising SPR's. They
    would write the SPR on a 6 part carbon form and post it to us. This
    would get typed in by our secretary and we would screen it. Then
    it got printed off and posted to the States. Getting a response
    was a standing joke, customers knew they were sending stuff into
    a blank hole.
    
    Thats the bad news! Now that SPR's are logged by the Support Centre
    and go straight through to the administrators things happen much
    more smoothly and there is no rekeying involved at all.
    
    Case in point. About a month ago a customer phoned in with a problem
    on Rdb. We couldn't fix it, the same problem was on the production
    software. We didn't have the field test software available so raised
    an SPR. Next morning I got the SPR number returned to me. Two days
    later an RDB person called for more details. Two days later, via
    a distribution list, I saw the SPR was closed with 'fixed in next
    release'. A week later, the official replt to the SPR hit my desk
    for reviewing before being returned to the customner. Total time,
    from logging a call to getting an answer, about 2 weeks!
    
    Methinks a lot of problems exist not with the way SPR's are raised,
    but with what happens after they hit the SPR admin people. I've
    also heard the rumour that suggestion SPR's are ignored because
    SPR admin are over-stretched. Any body know more
    
    my 2p worth,
    
    Simon

Yes, correct, functioning software is what we must deliver.
But I can't help asking what good is perfectly bug-free software
that nobody will buy because we're too out of touch with what
the customers want?

    I was in Engineering for years before I transferred to CSSE.
    This is my current understanding of the situation.
    
    The GOAL in the US is to act more like the European CSCs do.  That is,
    screen ALL customer calls - SPRs or phone calls - and try to solve
    the problem in the CSC.  If they can't, then the 10 or so world-wide CSCs
    elevate the problem to CSSE, who uses their expertise to try to solve 
    the problem.  Again, the solution for the customer may be a work-around
    or alternative that gets him going again.  If CSSE can't come up with
    the solution, then Engineering is contacted and together we try to
    come up with something.
    
    All along the way, the original technical problem should still end up
    in Engineering.  If a CLD is involved, this says that this technical
    problem is critical to a customer, and needs to be looked at right
    away.  The solution may still be a work-around, and a fix in the next
    version that comes along.  Otherwise, it goes in the queue of things
    to work on.  A CLD may require a patch or point release to fix.
    
    It's the CSSE Technical Maintainability Engineer's job to make sure that
    serious problems get fixed in the next release, and to make those fixes
    part of the exit criteria for the next version.  This may involve some
    negotiation with Engineering due to resources or marketting constraints.
    
    Given all this working ideally though, you still can end up with the case
    that there may be too many minor bugs to be all fixed in the next
    release.  The problem I see is that Engineering management is not being
    measured on the right criteria.  I'm not sure, but they may only be
    looking at SPR rates, and customers may have given up submitting those
    long ago.  What they should be looking at is the raw call rates at the
    CSCs.  I think that this would be a real eye opener for some managers.
    Maybe then more resources would be allocated to maintenance. 
    
    Since minor bugs may not get addressed in the next version, quite some
    time may elapse before a customer sees the fix.  However, it's my 
    understanding of the policy, that Engineering should acknowledge the
    SPR as a valid problem, whether or not it gets fixed soon.  Some groups
    put all the problems into one maintenance database, whether they come
    from SPRs, QARs, internal customers, or CSC elevations.
    
    As I stated, your customers will get better results from calling the
    CSC than submitting a paper SPR.  They're really quite good out there.
    They can answer more than 90% of the problems without elevating them,
    I believe.

    This note is in reply to note #1026.23, entered by Steve Klein on
    14-FEB-1990.
    
    My name is Sue Clavin, and I am the unit manager of the group that does
    initial screening of VMS and DECwindows SPRs at the Customer Support
    Center in Colorado Springs.  This note was brought to my attention
    by one of the specialists in my district.
    
    From our records, we have sent 18 DECwindows SPRs (via the TIME::
    system) onto CSSE/Engineering for additional review/screening.  We try 
    to send only the first or unique occurrence of a problem if we cannot 
    close the issue locally at the CSC.  Steve's note may indicate there is 
    either a hole in the process between us and DECwindows Engineering or 
    the process hasn't been communicated to everyone properly.
    
    Rather than document that process here, I am checking the links of
    the chain of the process to ensure things are going where we are
    expecting them to or to give some feedback to help correct the
    process.  For Steve's information, I've sent Bryan Jones at VMS
    Systaining Engineering at ZKO a list of the SPR numbers, the date we 
    forwarded each of them through the TIME:: system, and an abstract 
    (one line long) of the problem title.  Byran says he is aware of your 
    note and will get the information to you.  Please feel free to contact me 
    at BSS::CLAVIN if you have further questions on this reply or on the 
    process.
    
    Regards,
    Sue

Thank you, Sue, for responding to my note.  I am glad that someone is
out there listening.
    
>    From our records, we have sent 18 DECwindows SPRs (via the TIME::
>    system) onto CSSE/Engineering for additional review/screening.  We try 
>    to send only the first or unique occurrence of a problem if we cannot 
>    close the issue locally at the CSC.  Steve's note may indicate there is 
>    either a hole in the process between us and DECwindows Engineering or 
>    the process hasn't been communicated to everyone properly.

Is that 18 out of 18, 180, 1800 or what?  We don't even know how many
SPRs are coming it.  I would like to be able to see *all* the DECwindows SPRs.
I don't want to have to wait for someone else to answer them before I can
even see the customer's questions.

Filtering is not necessarily beneficial.  Knowing how many "duplicates" for
each problem and hearing many different descriptions all give engineering
useful information.  Whatever else, duplicate SPRs convey a strong
reinforcement when it comes to setting priorities.

In the projects I previously worked on, it was part of my responsibility
to maintain the code I was working on.  This meant answering SPRs among
other things.  I tried to code carefully so that maintenance did not take a
lot of time and I could do other, more interesting, things, too.

Now, this motivation and feedback is missing.  And we are suffering for it.

I believe that every engineering group should be responsible for answering
SPRs having to do with their products.  This form of accountability is
a crucial factor in the battle for quality.  If a group cannot keep up,
then there is a quality problem that must be solved within the group, not
by "selling" the problem to another group.

I understand that there was a "process" put in place a few (2 or 3?) years ago
to help offload VMS engineering by moving SPR accountability to another
group.  I think that was a big mistake.  From what I have heard, not all
groups in ZK have implemented this new process and many engineering groups
deal with their own SPRs.

I know the futility of trying to dismantle process.  But there are too
many levels of indirection and too many filters between us down here
and our customers.

I do not question the good intentions of all those involved.  But we're
running blind.  Every SPR has a message.  Please don't keep them from
us.  And we should see your answers as well.  How are we supposed to
know what's going on if we're not included?

-steve-

    One thing for the SPR screeners to know is that VMS and
    layered products have quite different experiences with SPRs,
    and different desires.
    
    VMS has a huge number of SPRs coming in, and a huge backlog.
    This is not a reflection of bad code, but of the sheer size 
    and variety of the software, and the number of customers.
    I'm sure that some "popular" problems are reported hundreds
    of times.  In that environment, screening for already answered
    problems and removal of duplicate reports makes sense.
    
    The layered products I've worked on (VAX Pascal and VAX BLISS
    compilers) have a much smaller number of SPRs, and fewer
    duplicate reports.  We want to see _all_ of them, every single
    one.  Even dumb user errors are valuable to us--they tell us
    where we need to improve the documentation, the release notes
    or the error messages the compiler issues. Screening is less
    useful for SPRs on such products, and mostly just makes the
    process take longer.
    
    BLISS used to get around ten SPRs a year.  Now we get none.
    The last SPR I got for BLISS came in February 1988!  Maybe
    there are a lot fewer users, or maybe we really did fix that
    last bug--or maybe real problems and interesting suggestions
    are getting lost in the process?
    
    				-John Bishop

re: .42

>  ...
>  I believe that every engineering group should be responsible for answering
>  SPRs having to do with their products.  This form of accountability is
>  a crucial factor in the battle for quality.  If a group cannot keep up,
>  then there is a quality problem that must be solved within the group, not
>  by "selling" the problem to another group.
>  ...  

I haven't heard much about our quality program lately -- remember those black
posters with the gold Q on them?  The most important thing in any quality
program is that the person who produces something is responsible for all
aspects of the quality of their work.  They can't fulfill that responsibility
and have the opportunity to take pride in their work if they don't get _all_
the feedback available.

/Peters

    Is there a separate maintenance group for DECwindows?  Who are they? 
    Where are they?  How can Steve Klein and others develop new code for
    something maintained by another group elsewhere?  And who is keeping
    track of the total number of SPRs filed against our products?

re .44:


>>  I believe that every engineering group should be responsible for answering
>>  SPRs having to do with their products.  This form of accountability is
>>  a crucial factor in the battle for quality.  If a group cannot keep up,
>>  then there is a quality problem that must be solved within the group, not
>>  by "selling" the problem to another group.

	Accountability is a great concept, but the trouble we have today
	is that "some people are more accountable than others" (to misquote
	"Animal Farm").

	If a group cannot keep up with their SPRs, it may be that someone
	has given that group too much to do, and something has to give.
	See my next comment, below...

> I haven't heard much about our quality program lately -- remember those black
> posters with the gold Q on them?  The most important thing in any quality
> program is that the person who produces something is responsible for all
> aspects of the quality of their work.

	This comment, especially the first sentence, reminds me powerfully
	of reading Phil Crosby's book "Quality is Free". He speaks often of
	managers who start up "quality programs" and then wonder why they
	just "run down" and stop. Crosby explains that managers usually
	think a "quality program" is a way to motivate employees and make
	them "stop doing things wrong". They don't usually know (or want
	to know) that THEY THEMSELVES are the chief quality problem, because
	whenever time-to-market, or costs, or reorganisation, or prestige,
	or any other thing strikes them as important, they put that in front
	of quality.

	Thus, if you say that "the person who produces something is 
	responsible for all aspects of the quality of their work", that
	can only be true if the managers who have set up the process have
	made it possible for an ordinary person to handle everything. Too
	often an employee or group is told "dig a hole to China within
	24 hours", and then blamed when it doesn't get done.

	The saddest thing is that managers usually perceive quality as
	being "too expensive", failing to understand that, in Crosby's
	wonderful phrase, "QUALITY IS FREE". It's doing things wrong
	that comes expensive.

	The Corporate Philosophy makes it clear that Digital is intended
	to be a quality company. Paragraph 3 says:

		"Growth is not our primary goal. Our goal is to be
		 a quality organisation and do a quality job, which
		 means that we will be proud of our product and our
		 work for years to come".

	Unfortunately, too many managers have the "Harvard Business
	School" MBA mentality, which says "reduce everything to dollars,
	employees included". This is a sure way to ruin.

	/Tom

    Jack Smith had the right attitude to MBA's....

    RE: -.1
    
    Which is?
    
    			Alfred

    'Who needs 'em?"

    	At the great risk of stirring things up more, I am willing to
    provide some background.  Much of what has been said regarding the
    differences between SPRs and CLDs is absolutely correct.  The SPR is
    the "standard" mechanism for a customer to give input on problems,
    suggestions, documentation errors or anything else (on software).
    The CLD is used to get immediate access to the right level of resourse
    to solve the customer problem - NOT necessarily to fix the bug, but to
    solve the problem.  Workarounds are often used in the short term.
    
    	Quite some time ago there was a fairly important meeting between
    certain engineering and support managers.  The result was an agreement
    in principle on the division of labor between engineering and support.
    I believe that the agreement is still in effect, and it has resulted in
    much of the support structure that we see today.  Basicall engineering
    agreed that it owns responsibility for the fixing of the software. 
    Full responsibility.  And they will fix bugs "for free".  But customer
    services owns responsibility for feeding engineering ONLY unique new
    problems from the field.  And customer services owns the process of
    getting answers to SPRs back to the field.
    
    	This fundamental agreement caused many things to change.  In
    particular, it is partially responsible for the various support centers
    screening SPRs.  It causes only one copy of a problem to get through
    (ideally!).  The last time I looked, approximately 90% of the calls to
    the Colorado CSC are closed out WITHOUT an SPR coming through!  This is
    much to their credit!
    
    	I have been involved with a second level of screening for some
    SPRs, and can attest to the fact that every effort is made to see that
    only new, real problems (bugs) should be making it "into" engineering
    for the products that I have been associated with.  I cannot speak for
    what happens afterwards, although I have observed that some groups are
    very good at closing things out quickly.  In fact, some groups can
    handle not only SPRs but bug reports coming in through NOTES files with
    fascinating speed!
    
    	So where is this all taking me.  Well, let me suggest the
    following: don't drop the ball!  If you are in a screening group, make
    sure that the SPR gets through PROPERLY to the appropriate engineering
    group for resolution when you cannot answer the SPR yourself.  Find out
    HOW the SPR will get answered - are you the expected answerer?  Even if
    a bug fix is required?
    
    	For engineering groups: find out where the SPRs are going.  They do
    NOT get thrown away, but they may get to some strange places...  If you
    don't know where they go, FIND OUT!  I assure you that engineering has
    the responsibility for fixing the problems (and possibly for seeing
    that an answer gets generated).  If you are having problems finding out
    where things go, start with SPR administration - they forward SPRs to
    a list of contact folk based upon product.
    
    	But, for heaven's sake, don't just ignore the problem!  I have
    observed MANY instances when an "ignored" SPR becomes a CLD.  It then
    costs much more to address, and is far more unpleasant for everyone.
    
    Hang in there!
    
    Dave Eklund
    

    re: last several on quality

    Yes, holding someone responsible and enabling them to _be_ responsible
    are two different things at Digital.  For us to be a "quality" 
    organization, management has to make the commitment to delegate authority
    along with responsibility.

    I can see where it makes sense to screen and respond to SPRs without
    needing to send them on to engineering. Like ones where customers try to
    print with the "/TIFY" flag set (the negation of /"NO"TIFY). It also
    makes sense though, to pass on statistics on what duplicates were
    screened for which existing opened/closed SPRs. This would raise the red
    flag for other possible areas which may need to be addressed, like
    documentation, desired system/user features, etc.

    /peters

My name is Sheryl Caissie and I supervise the SPR Administration group in 
Stow.  SPR Administration is in CSSE under the Problem Mangement group, 
managed by Ken Tilton.  Here's is an org chart of the Problem Management 
group:


                             Ken Tilton
                       Problem Management Group
                               Manager
-------------------------------------------------------------------------------
|                |             |             |             | 
Sheryl Caissie   Bruce Judson  Ann Symes    John Degen   Joan Keane
SPR Admin.       CLD/PRISM     Project Mgr. Project Mgr. Security & Liabilities
Supervisor       Manager 
    |                |
  Karen Carroll     Tod Holmes
  Paul Davies       Prism/CLD Administrator
  Marge Kelley
  Randy Parker
  (SPR Administrators)




I would like to reply to some of these notes in order to clear up any rumors or 
misconceptions about the SPR Administration group and to inform you of the 
facts of the SPR process as it is today, and our future goals.  This will be 
a one time reply in the notes file; after that, if you have any questions or 
concerns about the SPR process, please contact me directly on 
CSSE::CAISSIE, DTN 276-8826.


RE: .6

John, in all your replies I have not been able to determine which product 
group you currently represent.  If you would contact me directly, and identify 
the product(s) you're responsible for, I can thoroughly investigate the 
activity of your SPRs.  I'm sure we can alleviate your concerns if you 
would contact me and give me some details with which to work.


RE: .8

Regarding "...the administrative group that conveys SPRs to the product 
groups being inefficient."   Perhaps it would be better to say that the SPR 
process is inefficient - the SPR coordinators in the group have little 
control over the process they're dictated to follow.  Management has that 
control and we're working towards bettering the process.

Today, SPR Administration has 3 SPR coordinators and 1 Project Specialist.  
Their job is to process incoming SPRs and SPR answers into the Corporate SPR 
database (TIME), to route SPRs to the appropriate product groups, and to 
process and route SPR answers to the CSCs for closure with customers. Though 
we share responsibility within Digital for getting SPR answers to our 
customers, we do not own total responsibility of those SPRs which we've routed 
to CSCs, CSSE Support, and Engineering for resolutions.  We as a company are 
responsible and we need the cooperation of all organizations to improve the 
process.


Here are some facts which you might find interesting:

- In 1989 we handled almost 9000 SPRs.
- There are currently 3710 SPRs open in the corporation (owned by either
  a CSC, CSSE Support, or Engineering group).
- There are currently 366 unprocessed paper or E Mail SPRs backlogged in
  SPR Administration.
- Last year we had 9 people in SPR Administration.  Today, we have 5.
  Though the resources were decreased, the workload has not changed.


RE: .32

Regarding "...There was never a commited response of an answer to the 
customer..."  As I understand it, Digital is commited to reply to every 
submittal, providing the customer has a valid support contract.  However, 
there are no corporate metrics in place today for response time back to the 
customer.  Some groups have very strict metrics and are very conscientious 
about following them; other groups have none.  My manager is currently 
chairing a task force which, among other things, involves incorporating 
metrics into the new nonurgent problem escalation process which is 
currently being developed.



RE:  .38

Suggestion SPRs are not ignored by SPR Administration.  However, we have 
recently changed our procedures for Suggestion SPRs.  Formerly, we entered 
every SPR into the corporate database (currently, TIME).  Due to our backlog of 
unprocessed "problem" SPRs, we decided not to enter the SPRs into TIME, but 
to quickly forward them as FYI ONLY to the CSSE Support or Engineering 
contact.  (It takes an average of 30 minutes to enter one paper SPR
into the database.)  

When a CSC forwards a Suggestion SPR to SPR Administration, they 
have already "closed" the submittal with the customer as a suggestion.  The 
customer does not expect any further formal response; therefore, it is not 
necessary for us to log the SPR in our database.  We do, however, 
understand the importance of forwarding the information along to Engineering, 
and we forward all submittals in their orginal format (either paper 
or E Mail) to the contacts we have identified by product.  They should 
manage the information as appropriate.

Therefore, the only real change to the process is that the problem is not 
logged and closed as FYI on the system and given a corporate SPR number; it 
is merely forwarded to CSSE Support or Engineering for their information 
and their action as appropriate.



General:

As outlined in the org chart above, CLD, PRISM, and SPR processes are now 
under one group, the CSSE Problem Management group.  As stated in some of 
these notes, we are working towards one process, one tool for escalating 
problems.  We hope to have a new process in place within the next 12-18 
months which will allow the Geographies to escalate a problem (phone call, 
DSIN, paper, hardware, software, whatever) to one process, identify the 
product and severity, and have a tool automatically route the problem to 
the appropriate CSSE Support group for resolution.

The new process flow would be as follows:

Customer --> CSC --> CSSE Support --> Engineering


At any time in the flow, if a resolution is identified, the flow would 
reverse and the customer would be notified by the CSC of the answer.  It 
will be CSSE Support's responsibility to "manage" the problems into 
Engineering, so that only unique problems are escalated, and so that all 
problems resolved at a previous point in the flow are reported to 
Engineering as appropriate.

The Problem Management group is currently a driving force to implement this 
process flow, on a product by product basis; the process is currently being
followed by the VMS group and few others.  When the new tool is developed, 
we expect this process flow to be fully implemented for all products worldwide.

We, in the Problem Management group, consider our primary concern to be 
Customer Satisfaction.   We are well aware of the problems with the current SPR 
process and believe me, we are as frustrated with it as the rest of Digital 
and our customers.

The number of SPRs used to be very small and the processes and procedures 
which were in place probably made a lot of sense at one point.  However, as 
Digital has grown, and as our customer base has increased and the number of 
SPRs they're submitting has grown, the process outgrew itself and got quite 
out of hand.

Aside from the volume of SPRs we have to deal with, we are faced with 
limited resources, and inefficient tools.  Currently we are using the TIME 
database.  TIME is a distributed database with nodes in several locations.  
Information is updated to appropriate nodes on a daily basis, and the 
Corporate ICARUS TIME database is updated on all activity.  The U.S. CSCs 
interface to TIME with the CHIME interface.  Due to problems with the 
interface and additional update delays, an SPR can take up to 10 days to be 
routed from one node to another.  This is unacceptable and we are 
currently working with the CSCs to implement some interim procedures to 
eliminate these delays until the new tool and process are fully 
implemented.

I became supervisor of SPR Administration about a year ago; we've been 
reorganized twice since that time.  The most recent reorg was in December.  
Even in that short time I've seen incredible improvement and sincere 
dedication to improving the process and to doing what is ultimately the best 
thing for the customer.  With the help and hard work of the members of the 
SPR Admin. group, and with the support of upper management and the 
organizations with which we interface, we are working towards great
improvements and I believe we will meet our goals.

Some of these improvements are interim procedures to "workaround" the problems, 
until THE GOAL (12-18 months away) is reached.  Improving this process will be 
no easy feat and we cannot do it alone.  We need the cooperation and support 
of the Field, the Geographies, CSSE, and Engineering.

To summarize, SPR Administration and its management is well aware of the 
process problems and their implications.  In SPR terminology, we are working 
hard at providing workarounds and we are continuing to work towards a 
permanent fix.  If you have specific questions or concerns about the 
process or about particular SPRs, please contact me or any of 
the other Problem Management group staff directly.  We'll be happy to work 
with you to identify and resolve any problems that do exist.

Regards,

Sheryl Caissie

    re: .50
    
    If 90% of the calls are handled without an SPR, and that's a good thing,
    how does a writer of product documentation, for example, get the info 
    needed to improve the books?   I'm imagining a gold mine of clues in those
    well-handled calls.  Does anyone forward the gold dust?  Or do we
    just get the SPR-sized nuggets?  It's all gold to me.
    
    Scott
    

    re .53:
    
    Ask the appropriate CSC people to review the documentation. Encourage
    them to mark up current copies as input to the next cycle.
    
    We (DECtp engineering) have found the CSC folks more than willing to
    provide this kind of input, as it makes their jobs all the easier the
    next time around.
    

    Hi,
    	I'm Peggy Annin and I work at the CSC in Colorado Springs for
    Sue Clavin screening VMS SPRs.  (VMS includes all products 'bundled'
    in with the VMS operating system when VMS is shipped to a customer).
    I've been screening SPRs for 5 years now and it is a strange and
    wonderful job.  I'd like to address a few issues that have been 
    raised:
    
    	1) an engineer wants to know how often a problem is seen
    	- we keep a database for just this purpose and each new problem
    	is given a unique "bug-id" - whenever anyone at the CSC sees a
    	customer with the problem they run a procedure to increment the
    	"bug counter".  We generate reports of this information and forward
    	it out regularly.
    
    	2) documenation improvements - not only have we at CSC/CS gladly
    	reviewed documentation when it is revised, but we have procedures
    	for VMS that allow CSC specialist to easily report documentation
    	errors or improvement suggestions.
    
    	3) all VMS SPRs are kept on-line in a STARS database.  STARS is
    	an AI tool that allows you to enter english type queries and
    	find related articles.  If an engineer wants to see all his
    	SPRs, then I'm sure access or a copy of the database can be
    	arranged and he could select and read all the text.
    
    	4) Reasons we screen SPRs:
    		1) we can quickly answer a high percentage by phone,
    			this is cheaper than the old "written answer"
    			and the customer can interact with the specialist
    			delivering the answer
    		2) many SPR problem statements are NIGHTMARES - I think
    			some of our customers are computer literate and
    			English non-literate.  Some are just incomplete.
    			Some are just vague.  We pride ourselves on
    			elevating WELL-WRITTEN, COMPLETE, CONCISE
    			problem statements.  By complete, I mean we have
    			enough information to work the problem.  Customers
    			send us paper listings inches thick, no examples,
    			etc. etc. etc.   We also try to isolate the problem
    			to be sure it is routed to the correct maintainer
    			the first time.  Customers often submit problems
    			against COBOL that are RMS or RTL issues. We are
    			in the unique position of being able to talk to
    			the customer, be sure that we have correctly
    			identified the issue, help him with workarounds,
    			etc.    
    			
    			We also take our problems and populate customer
    			readable databases (very carefully wording these
    			articles) so that customers can solve their own
    			problems and perhaps avoid problems.
    
    Well, I hope this helps.  We really are here to be a positive force
    and we have been working on improving our service and our processes
    ever since I've been here.  
    
    
    Have a good day,
    Peggy