STBs and Lost Shipments (long and somewhat specialized)

Doug Moran moran at warbucks.ai.sri.com
Thu Feb 9 15:39:23 AEST 1989


>Recap: Steve Harris (etnibsd!vsh at uunet.uu.net) asked about how reliably
>other people were receiving STB's (Software Technical Bulletins),
>noting that he was missing 5 from that year, and that he couldn't get
>replacements.

There are two issues here that I would like to address:  who should
receive STB's and "lost" shipments.  I have been round and round with Sun
on these issues, and have resigned myself to the current situation.
However, (1) some of the details below might be helpful to people new to
these problems, and (2) if other customers have similar problems, now is
supposedly a good time to highlight the problems to Sun.  Many of these
problems outlined are at least partly the result of Sun's MIS system -- a
system that is currently badly overtaxed and which is supposedly in the
process of being replaced.   Some of the problems may automatically get
fixed, but other may propagate from the old system to the new one unless
Sun realizes that the old way needs to be changed.


Multiple copies of STB:

My company has site-wide software and hardware maintenance agreements.
There are multiple groups within the company, and each major group has a
contact listed on the contract.  Sun sends only one copy of the STB per SW
maintenance contract and sends it to the "primary" contact, which in our
case is the buyer in the Purchasing Dept.  He then passes that copy on to
one of the groups, selected on a rotating basis.  Photocopying the STB
(assuming we could get permission from Sun) is not a viable option because
of internal bureaucratic problems.

I have dealt with three successive Sun sales reps on this issue over the
past 3 years.  The first two told me that nothing could be done at that
time -- the computer program that generated the labels could not handle
more than one addressee per contract -- but that the situation might
resolve itself in the "next 6-12 months".  The current sales rep did a
little better -- the person she talked to acknowledged that it was a
problem and needed to be fixed and projected that the impediment would be
removed in "60-90 days".  That was last June.  I think that the sales reps
did a good job in pursuing this issue -- my conclusion is nothing has
happened because Sun doesn't see this as an important issue to most
customers, and thus it doesn't warrant the resources that would be
required to fix it.

A major portion of the content of the STB is a list of reported bugs,
which I would find quite useful (even with the publication delays).
However, as someone else has pointed out in this list, it would be much
easier to search this list if we had an online copy, rather than hardcopy.
I raised this issue with Sun and was told that the STB would be available
only in hardcopy, and that for online searches, one should use the online
bugs database.  Unfortunately, that database is not indexed in a useful
way and I know of no one who actually uses it -- I know of a number of
people, including myself, who tried to use it once and said never again.

Which brings up the issue of what are the benefits of being a "point of
contact" on a maintenance contract.  The company I work for has multiple
groups and Sun charges us $50/month for having additional (>3) people
listed as contacts.  However, there is no apparent benefit associated with
this, except for being authorized to contact the "Hotline".  Since our
contacts are all long-term, highly experienced users of Suns and UNIX, our
use of the Hotline is largely to report bugs and to see if there are fixes
available.  Since I don't regard a vendor listening to customer reports of
defects in its product as providing an extra service to that customer,
being "authorized" has no real benefit for such users (unless one argues
that, like a tree failing in a forest with no one to hear it, a bug is not
a bug until reported by someone with a maintenance contract :-)).  If Sun
is going to charge for additional contacts, the very least they could do
is send those people their own copies of the STB.  Note: As part of this
last go-round, I was told that there would be an as-yet-undetermined
charge for any additional copies.

Lost Shipments:

>Recap: Mr Harris' message stated that Sun claimed that their records
>show that Sun had sent him the issues that he never received.

Based on my experience, it is quite possible that either:  (1) Sun didn't
ship it but the MIS system said that it did, or (2) Sun shipped it with an
inadequate or incorrect address and it went astray.

We have had repeated problems with Sun's shipping of small mass-produced
items (e.g., software distribution tapes purchased separately) and
especially things sent under a maintenance contract.  I am giving some
details of what I have learned so that others will not expend inordinate
amounts of effort convincing themselves that the problem is not theirs but
Sun's (but at the same time, do not automatically assume that the problem
is with Sun, check around first).

Some items have been shipped to us without the name of any person or a
purchase order (PO) number.  On other shipments, the PO number is on
there, but not identified as such, so our receiving clerks must go through
the various strings of digits on the label, looking for one that is of the
right length and in the range of active POs.  Failing that, they simply
guess which group to send it to.  Needless to say, we have a number of
misdelivered shipments.  To cope with this, we established a mailing list
of facility managers in the various groups so that a manager receiving a
package that isn't his can broadcast a query and thereby find who it does
belong to.

My suspicion is that the problem is often in Sun's administrative
software, and not in the entry of the order at my company or at the sales
office because I have seen the problem occur on part of a purchase where
the other parts had no problem or on one shipment of a maintenance
contract where a previous or subsequent shipment was just fine.

As recently as a year ago, I know that Sun was still having problems with
some of their databases, and believe that the problem was that the
shipping address was an attribute of a company rather than of a person
within the company.  At that time we had swap-by-mail hardware support
(what Sun now calls "customer assisted return service").  When I would
call in, the mailing address they had on file for me was invariably wrong.
Since it would always be the address of one of the other contacts in the
company, but not always the same one, I suspect that the address of the
last person to receive a shipment became the address for the whole company
(we quickly learned to check what address Sun would be using for each
shipment).  This inability to distinguish individuals within an
organization may not be a problem for a company with a single campus, but
it is a potentially significant problem when a company has groups
scattered around the country.

>>If a shipment goes astray, check not only with other groups within your
company but also with your Purchasing Dept and with whomever pays the
invoices.  I know of multiple occurrences where the address of one of
these people has been used instead of the person listed on the PO as
"deliver to".

This problem may well go away when and if the new MIS system is installed
-- the problems are characteristic of (1) inexperienced and overworked
programmers and (2) overloaded systems which don't permit adequate
debugging runs and cause the notion of "close enough" to recede further
and further from what is intended.

We have also had a number of occurrences of shipments that Sun claims to
have shipped that we are reasonably certain did not arrive -- some of
these shipments were big enough (e.g.  8+ sets of manuals, two boxes per
set) that they should have been remembered by the Receiving Dept (which
didn't) and big enough that they would not be easily overlooked if
misdelivered within the company (and we checked with all likely
recipients).  A possible explanation is that an item is recorded as
shipped when its mailing label is printed and there are inadequate
procedures for reconciling differences between what was scheduled to ship
and what actually shipped (e.g., labels "lost" when the printer jams or
runs out of forms, labels destroyed and misplaced in the shipping area,
...).  Reconciling these differences is non-trivial and my understanding
is that a fair number of companies deal with this problem by letting the
customers catch the errors (the reasonable ones send replacements without
hassling the customer).  Note:  this is typically a problem with
mass-produced items, such as manuals and release tapes, where labels are
being slapped on boxes.  It is rarely a problem with
individualized/configurable items, such as workstations, where the
shipping labels must be matched to the boxes.

>>From the number of instances of this problem I have heard of, I strongly
suspect that this is not a rare occurrence.  However, it has taken us
significant time and effort to convince Sun that certain shipments did not
arrive.  It may be that not enough other customers are aggressively
pursuing their lost shipments or that the reports of these problems are
not getting back to the MIS people, so they are unaware of it.

Shipments under maintenance contracts:

An ongoing problem is that all shipments under the software maintenance
contract go to a single point of contact, who must then redistribute them
to the various groups covered by our site-wide contract.  This problem is
compounded by two factors.  First, the tapes and manuals for a new release
rarely arrive as a single shipment -- typically they arrive over a period
of weeks/months.  Second, a number of the updates have arrived without a
mnemonic label, just a item code and part number (which, being new, appear
in none of the literature we have), requiring the primary contact to open
the boxes to determine what they contain and thus who should receive them.
These are individually minor inconveniences, but cumulatively they
significantly increase the effort required to get all the packages to the
designated groups.  We would like Sun to annotate the mailing label on
each box in a shipment to be "attention of" a designated contact.  Since
each line item in a maintenance contract corresponds to a separate box,
one would think that this would be easy to implement.  We have suggested
this to Sun, but have been told that it is beyond the capabilities of the
software currently handling maintenance contracts.

-- Doug Moran (with usual disclaimers)



More information about the Comp.sys.sun mailing list