Conference 7.286::digital

Let me take the opportunity to jump in first.

It would appear that your own assessment of the situation is that SPR's
are _NOT_ the answer. So, what would you suggest as a preferable means?

Should engineering be prepared to send a developer onsite at the drop
of a hat? Should the field be prepared to have a specialist go into
residence to assist in problem resolution?

What do you propose as an alternative to "Please SPR"?

Now, if the customers' concern is that engineering isn't sufficiently
responsive to SPR's, that's a separate matter. But is there any reason
why the mechanism, if properly attended to, is inappropriate?

-Jack

One other thing -

> Remember, customers pay mega-dollars for support contracts.

Remember, depending on the product and organization, some engineering groups
never see a penny of the support contract dollars from Services in terms of
funding to retain headcount. There are numerous examples of "products" and
software components which have decommitted engineering support altogether
simply because "the buck never gets passed all the way back to the source",
being diluted in too many pockets along the way. It doesn't do an engineering
organization any good to know that customers are paying top dollar for support
on their product if that organization doesn't receive sufficient expense
relief funding to cover their headcount.

I know. I'm part of an organization who's been fighting this battle, and losing,
for more years than I care to remember. I can cite you example after example
of products which we no longer engineer because the support contracts didn't
figure into our funding scheme.

-Jack

First of all, "SPR forms" are obsolete.  I haven't seen the "yellow paper"
for years.  Instead, customers call their local CSC and have the support
person investigate and, if necessary, file an SPR electronically.  (Users
with DSNlink can send in reports electronically.)  Engineering then gets the
SPR by E-mail and responds in kind.

Now - if there's any Digital product that "dies once a day", there's a
serious problem, and one that the local office should be involved in.  But
for the majority of our customers who find occasional problems, the SPR
mechanism "works".  Well, mostly.

The biggest problem is that there is great disparity in responsiveness
between engineering groups.  Some groups respond quickly to problem reports,
others let them languish for months and years.  Part of this, I am sure,
is the revenue issue Jack brings up.  Indeed, there seems to be a growing
trend towards our making software licenses cheaper but shoring up revenues
by raising support costs.  Guess who looks bad when the beancounters look
at the bottom line?

Customers will have varied reactions to the notion of "SPRs", though it may
be partly a matter of terminology.  Indeed, I no longer say "please submit
an SPR", rather I say "please report this problem through your Digital
software support contact".  And, at least, my customers seem to be happy
with how we treat them.

					Steve

Re: SPR forms obsolete.

According to the SPR admin person sitting down the hall that is not the case.
We still receive many handwritten/typed SPR forms and she is still asked to
send out blank ones to customers everyonce in a while.

Re:  Product dying once a day.

Well this did happen and is still an on-going issue at this moment but I don't
want to get into the gory details.

Abviously, customers who don't have support contracts have to resort to SPR
forms.  However the term "Please submit an SPR" comes out again and again
in our documentation and in various layered products' error messages when
they crash or fail.  When this happens, customers are in no mood to submit
SPR's.

Re: disparity between our engineering groups.

Tell me about it.  I submit an SPR for group A with 4 problems on it.  It comes
back with 4 answers a few weeks later.  I submit an SPR for group B with 4 
problems on it and it comes back with "please submit 4 individual SPR's".
Time wasted or time well spent re-submitting individual SPR's?  It took me
.5 hours.  It will take some time for our SPR admin rep to respond to them, 
etc...

Meanwhile, customer is waiting for his answers.

Back to my original questions.  Are we customer focused based on the above?

/Mario

    This is information from the manager in the USCSC that currently
    handles the SPR process.
    


		Information on SPR flow within the United States
		================================================

United States Customers submit Software Problem Reports (SPR) to Digital
through various methods:  paper, contacting Digital Multivendor Customer
Services (MCS) local office, contacting the US Customer Support Center
(CSC).  Regardless of which method is used, the analysis of the issue
reported is routed to the CSC, specifically to the team/group/vendor
that supports the operating system and/or layered product reported in
the content of the SPR. 

NOTE:  Customers who have valid contracts with the CSC should always log
SPRs by contacting the CSC via voice (1-800-354-9000) or by using one of
various electronic tools (DSIN, DSNlink for OpenVMS, DSNlink for 
ULTRIX) that are provided as a part of the support contract.  There will
always be some level of contract validation when a customer contacts
the CSC.

The CSC specialist or engineer supporting the product on which the
problem is reported will be an active participant in determining
that the SPR falls into one of the following categories:

	1. True product deficiency or non-conformance to Software
		Product Description (SPD)
	2. Documentation issue
	3. Suggestion for enhancement or functionality changes to
		future release of the product
	4. Something else

To help set expectations properly, here is what a customer can/should
expect from Digital and the US CSC for each category:

1. True product deficiency or non-conformance to Software Product 
   Description (SPD)

The issue ("bug") will be elevated to the Digital engineering group or
other vendor that supports the product.  Engineering and the CSC work
together to determine the severity of the issue based on the impact to
the customer's system/operation and whether a workaround is available or
not. 

Engineering further prioritizes the issue based on their current
work backlog and the component affected.  When the engineering group
answers the SPR, the customer will receive a call from the CSC with the
details of the answer.  

The CSC also makes a strong effort to document the issue (whether it has
a solution or not) in a customer-readable article available to customers
through DSIN or DSNlink.  What is turned on for customer viewing is
related to the overall severity of the issue and the perceived impact
level to the total customer base; that is, high-impact, high-volume
issues receive the highest priority.  

The CSC can/should give the customer a service request or log number for
future reference.  These are in a format of Annnnnn-mmmm or Cnnnnnn-mmmm
(CSC call-handling system).  For each SPR a corporate CASE-ID is also
assigned.  These are in the format of ICA-nnnnn or MST-nnnnn.  The
latter is for SPRs submitted before mid-1992. 

2. Documentation Issue

The issue is reported to the documentation group responsible for
updating the specific manual or documentation set.  There is no further
follow-up with the customer; that is, the call is closed on the CSC
call-handling system.  CSC guidelines request that a specialist contact
a customer and let him/her know the documentation issue has been
elevated.  

As Digital updates documentation, the group responsible reviews all SPRs
and corrects/enhances documentation as needed.  Electronic documentation
(Online Documentation Library CDROM or information/manuals shipped as a
saveset with a software release) is often updated sooner than hardcopy.
Most hardcopy documentation is updated when a release includes major
technical changes or a substantial portion of the manual requires
updating. 

3. Suggestion for enhancement or functionality changes to future release 
   of the product

The issue is reported to Product Management for a specific operating
system or layered product.  These suggestion SPRs are then reviewed as
potential for inclusion when a software product goes through the initial
phase review process for the design of the next or a future release. 
		
Usually suggestions are weighed according to such factors as:  total
number of customers who want to see the new/improved functionality, how
the changes fit or don't fit with the overall design of the product,
ease or complexity in making/effecting the change, etc. When a customer
submits a suggestion SPR, there is no commitment from Digital to follow
through with a response.  

Customers who need/expect a response for a specific suggestion (so they
can make decisions for their own application development or operation
design) should elevate the issue through their Multivendor Customer
Services local office to the correct Product Management group.  This
response is called a Product Management and Engineering Product Position 
Statement. 
		
The overall guideline is that Product Position Statements are given 
only for suggestions that have a high or critical impact on a customer's
application development or operational design.  The local office should
partner with the customer to assess the overall criticality or level of
impact. 

Often Digital and the CSC need the customer to help set expectations on
the criticality of the issue and level of impact of the content of the
suggestion.  If the customer does not specify an expectation setting,
the CSC will follow Digital's normal process for suggestion SPRs and
there will be no follow-up with the customer.

4. Something else

When the SPR falls into some other category, Digital will attempt to
give the customer advice/alternatives on how to proceed with the issue. 
This could result in a response that the resolution is: 

o Outside the normal limits or terms/conditions of a customer's 
  support contract (that is, would be considered consulting 
  or a non-contract service), and that the customer would need 
  to agree to pay an extra fee for Digital to continue pursuing the 
  issue.

o The responsibility of a 3rd-party or non-Digital related vendor.

o Not within the scope of the services provided by Digital; 
  that is, Digital cannot help provide a resolution.

Finally, if a U.S. customer wants/needs a status check of an SPR that
falls into category #1 (product deficiency or non-conformance to SPD),
he/she can log that request through the CSC or the local office. 
Digital Multivendor Customer services (CSC and/or local office) will
then try to obtain as much information as possible from the engineering
group that has responsibility for the resolution of the SPR.  To help
set customer expectations, the response time on status requests 
will be related to the severity of the issue and the current number of 
problems being worked by engineering.  Therefore Digital is not
able to commit to a specific response time.

If the software issue reported as an SPR becomes a "critical" issue,
then the customer should work with Digital Multivendor Customer services
to elevate the issue.  The criticality of an issue is decided via 
discussion and collaboration between the customer and Digital.  Digital
views the following as critical issues:

	o a system that is down or or severely impacted 
	o a software application that is down or severely impacted
	o a customer operational issue that is severely impacted

Please note that Digital may reduce the severity of an issue is a
temporary workaround is available. 
    

re: .4, Mario

> forms.  However the term "Please submit an SPR" comes out again and again
> in our documentation and in various layered products' error messages when
> they crash or fail.  When this happens, customers are in no mood to submit
> SPR's.

I can't speak for all products, however, in case it isn't obvious, which I
expect it may not be, the general reason for urging an SPR submission in
an error message at product failure or abend, is that an inconsistency
has been detected within the code and the designers need additional
information from the user in order to better understand the circumstances
under which the problem was encountered. While I recognize that this message
doesn't help the customer at that moment, the customer should understand that,
generally speaking, only through the information that they alone can provide
will engineering be able to resolve the problem over the longer term. A typical
case in which such an error occurs might be when an internal data structure
appears to have been "spontaneously" compromised or corrupted, and anything
other than an abort could lead to far more serious problems (e.g. file
corruption.) (Hopefully, in such a case, the user will also be provided with
a PMD, register dump, or other diagnostics which can be included in the SPR
to provide further insight to the engineers.) I haven't any way of knowing if
this example is germane to the particular product you have in mind, but that's
the general idea. Perhaps someone else can expand on that concept.

> Back to my original questions.  Are we customer focused based on the above?

Before I could answer this, I'd still need to know what you consider to
be an acceptable alternative to soliciting SPR's. Maybe there is something
else/better that we could do. Enlighten us.

-Jack

PS. You weren't looking for bug-free code, were you? :^)

(An engineer I once worked with drew a cartoon with a rather Lucifer-ous
 character on an analyst's couch saying, "Did he want Money? No. Did
 he want Fame? No. He wanted a thousand lines of error free code!!!"
 :^)

-Jack

The purpose of this note is to question the overuse of *recommending SPR's* by
everyone in Digital.  Sorry if that wasn't made very clear.  It would appear
that SPRs are still widely used accross the corporation and I guess that makes
them appropriate for a number of customers in various low-priority situations.

In some cases though, they are inappropriate and, in my opinion, everyone should
be careful when to propose SPRs to customers or to field support engineers for
that matter, when problems are that major.

BTW, I realize that it is inappropriate to send engineers to the field for 
major outages.  Isn't that the reason for the existence of our support
organization?

/Mario

    
    What ever happened to logging a CLD?  I ALWAYS told the field to
    
    			ESCALATE
    
    if they had a REAL problem that they couldn't solve and needed
    someone with more knowledge....It worked every time!
    
    

	RE: .9 Not every problem requires a CLD. Surely there is some middle
	ground between SPR and CLD? Isn't there?

			Alfred

    
    There is NO middle ground if the customer crashes DAILY and no one
    wants to help.
    
    	ESCALATE  ESCALATE  ESCALATE     PERIOD!
    
    

    Mario, it seems that everyone has opinions and folklore to share with
    us on how describe and report quality problems with SSB software.
    
    It's so typical that the focus of this discussion is _process_: "SPR?
    Threat or Menance" rather than identify and correcting software quality
    problems at different levels of urgency.
    
    I have opinion and folklore for every non-field person reading this:
    Many of the people in the "support organization" don't have "access to
    dollar sign", hence, we need engineers to solve problems that once were
    solved by field people.
    
    The continuity of expertise that stretched from the engineers to the
    field in the form of technically capable sales support people and
    consultants (52A* and 54A*) codes just doesn't exist anymore.
    
    With about one powered-up Alpha in the field for every 100 powered_up
    VAXstation II, VAXstation 3100's, and DECstation's, the technical
    capability of such support people is approaching irrelevance and
    obsolesence.
                

    re.10
    
>	RE: .9 Not every problem requires a CLD. Surely there is some middle
>	ground between SPR and CLD? Isn't there?
    
    No. Not really.
    
    SPR's are concidered to be used for low priority problems/suggestions.
    Customers with a Software Support contract are entitled to
    get the full range of support through there local CSC (Customer
    Support Centre). CSC specialists can raise a CLD when he/she
    is not able to fix the problem himself or with the help of 
    CSC's in his region (throught his Regional Exception Manager).
    
    Regards,
    
    Jan
    CSC Holland

    

I know of several engineering groups that tell their customers to submit
problem reports directly to them via the internet.  This, I assume, is due to
the many overhead/process problems with administration of SPRs, which cause
SPRs to be lost or sent to the wrong engineering group.

The SPR and CLD systems are being retired, so lets hope that the new combined
system is a whole lot better.  About 40% (my estimate) of the world is already
converted to the new system - the US should start within a month or so.  We won't
be using terms like "SPR" or "CLD", but "case" with as associated priority.

- Craig

re: .13

Your perception of SPR's and CLD's is very different from mine.  I wonder
if this difference has to do with differences between the ways we handle 
problem reports in different continents.

My perception:  SPR's aren't just low priority, they are (or were) for
everything except urgent situations.

CLD's are for urgent situations.  They're not for when the local or
regional folks can't solve the problem.  The SPR system is supposed to
work (but frequently doesn't) to allow you to communicate the problem 
back to the source, and get a response in a timely manner.  The distinction 
(to me) is one of customer priority, not one of who can solve the problem.
If a customer has a bug that needs to be fixed sometime in the next year,
then in theory (but not practice), the SPR system should be adequate.

   Gary

    CLDs evolved when the number of loudly complaining customers reache the
    point where we needed a process to handle them.  It was never thought
    out, and certainly is evidence of a situation that you don't ever want,
    i.e. very unhappy and dissatisfied customers.  It got out of hand when
    a flood of problems went directly to being CLDs bypassing the SPR
    process completely. In my mind you are failing miserably as a company
    if the number of highly dissatisfied customers reaches the point where
    you need a process to handle it.  The number should be small enough
    *and* serious enough that Bob Palmer could get personally involved in 
    each one.  If that isn't the case and we don't empower the account
    management team with the authority they need to satisfy their customers 
    then we will eventually go out of business.
    
    Apparently the SPR process failed to lead to satisfied customers.  If
    it had succeeded, we wouldn't be discussing CLDs because they never
    would have existed.
    
    Steve
     
    
    

    Re: .16
    
    >CLDs evolved when the number of loudly complaining customers reache the
    >point where we needed a process to handle them.  It was never thought
    
    	IMHO, it's gone from that to CLDs are _addressed_ when the number
    of loudly complaining customers is sufficient to validate the problem.
    
    Phil

    
    Re: .17
    
    >	IMHO, it's gone from that to CLDs are _addressed_ when the number
    >of loudly complaining customers is sufficient to validate the problem.
    
    Well, if it has truly gotten to this point, we should all be wearing
    lifevests all the time.
    
    Steve
    

My current understanding of *problem reporting* as it exists within GIA:

We use the IPMT tool which I guess will be implemented int he U.S. soon.  It uses
priorities 1 to 5.  When SPR's are received by customers, they're entered in 
IPMT, prioritized, screened by CSC, and forwarded electronically to appropriate
engineering group.

CLD - Critical level disruption

IPMT priorities:

	Priority 1 - Catastrophic outage, (customer down).
	Priority 2 - High impact problem (normal CLD)
	Priority 3 - Product issue, medium impact (ie like Prism/SPR)
	Priority 4 - Low impact product issue (SPR/Prism)
	Priority 5 - Product Sugguestion (documentation,SW improvements)

High-priority SPRs become priority 3 IPMT cases.
Mid-priority SPRs become priority 4 IPMT cases.
Low-priority SPRs become priority 5 IPMT cases.

Problems arise when different engineering groups treat the way SPR's are
filled-out differently.  A particular engineering group in the U.K. will accept
multiple problems on 1 SPR form.

Another one in the U.S. will be less receptive; refuse them and send them back
to us for re-submittal, despite the fact that SPR admin has already sent a 
letter of acknowledgement to the customer with 1 corporate SPR number.
Confused?

It's really not that bad but it causes problems when the field has to deal
with multiple engineering groups who all have different ways of dealing with
problem reporting.

This is not a unified approach yet.  Hopefully that will change.

/Mario

re: .19, /Mario

> 	Priority 1 - Catastrophic outage, (customer down).
>	Priority 2 - High impact problem (normal CLD)
>	Priority 3 - Product issue, medium impact (ie like Prism/SPR)
>	Priority 4 - Low impact product issue (SPR/Prism)
>	Priority 5 - Product Sugguestion (documentation,SW improvements)
>
> High-priority SPRs become priority 3 IPMT cases.
> Mid-priority SPRs become priority 4 IPMT cases.
> Low-priority SPRs become priority 5 IPMT cases.

Thanks for clarifying that. Now, I wonder why I have, here, sitting in front
of me, an IPMT elevation severity 2 (CLD) case for which the problem is that
the field does not want to relay the answer to the customer which was provided
by engineering, to wit, "the area you are concerned with is documented in the
following publication".

Oh, well - as it turns out, I needed to TFSO all of the engineers who had
been associated with that product as of last Monday anyway, so I suppose
it's someone else's problem to solve now, anyway . . . 

-Jack

    
    Hi,
    	Does the information here under .5, regarding the SPR process,
     still apply?  If not, I need to know what it is now.
    
    Thanks,
    mike M.

    Yup. Still applies.