NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/database/sybase/755

Text File | 1993-01-28 | 11.8 KB | 210 lines

Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!agate!ucbvax!mtxinu!sybase!ben
From: [e-mail] (Benjamin von Ullrich)
Newsgroups: comp.databases.sybase
Subject: Re: Sybase Support
Message-ID: <[e-mail]>
Date: 25 Jan 93 04:13:25 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Global Support Information Systems, Sybase, Inc.
Lines: 198

i'm writing to try to assuage any image that sybase technical support is less
than professional and dedicated.  i'm not sure what the "telephone operators"
label was supposed to mean (as i happen to think of telephone operators as very
important/useful/knowledgeable people), it does not appear to be positive.
there are good reasons support may have appeared in a bad light, and i think it
is useful that all customers and potential customers know why.
i'm speaking unofficially and personally on my observations of technical
support from my close employment with them.  these are my personal views.

In article <[e-mail]> [e-mail] (Jay Twery) writes:
>In article <[e-mail]> [e-mail] writes:
>
>....
>
>>Coupling this with my recent experience with Sybase technical support really
>>gets me.  I have spoken directly with 5 different technical support people over
>>the last week.  Only one of which displayed any knowledge of what PPP/SLIP really
>>is and this knowledge was minimal.  I was informed that either phone calls or email were
>>exchanged between all the "right" people and they came up with nothing -- not even
>>a suggestion of what to try next.  They obviously didn't try hard enough if someone
>>from Sybase addressed a similar issue on the net recently.
>>

This is not so, as there are several thousand employees here, and hundreds are
added each year.  those old and new have a hard time keeping up with knowing
who knows what, and who wants to know.  ignorance is not laziness.

attempts have been made to record employees' skill levels, but these
systems are not often used by the contributors nor the investigators,
since the phones and their resulting issues come first.  we are working
on both problems, in between phone calls (:-|).

>>At this point, technical support was trying to explain to me why this problem was not
>>major enough for them to try and solve.  The basic response was that Sybase did not
>>have the resources to "support all third party products".  I offered to send them
>>(or email) an installable version of PPP with step by step instructions.  They
>>refused because of the resource issue.  Also, they said they would need to look at
>>source from Sybase and the PPP product to see what was going on.  I had mistakenly
>>assumed that an engineer had already checked into Sybase source -- silly me.
>>

as a close companion to technical support (i design and support their business
systems), i think cormac burke's comments are very a very accurate assessment
of the way general sybase resources are applied to these type of products.
i would expand to say that our engineers are already busy fixing hundreds of
bugs in our hundreds of products, ones that can affect each and every user of
sybase software.  they're also responding to your requests for more features
and compatibilities, like ANSI 89 SQL, faster and more configurable backups,
and easier duplication of databases on multiple servers on the network.
i expect products answering these example feature areas will be released this
year.  most of the engineering talent i see flying through tech support every
day, or working from home all weekend on serious customer problems at all hours
of the night, is very busy trying to track down seriously difficult bugs in
our very complex software.  if you think about how complex a 4.5MB executable
program must be, well, it's no wonder their attention is stretched.

it's always been my experience that businesses in general tend to focus their
resources on the most serious problems (by number and complexity) they or
their customers face.  software companies in particular further focus first on
defects in non-functionality in their products' stated supported platforms
before the 'extras' of new, third-party, or compatibility-based clone products.
[REMINDER that i am speaking strictly personally here, as i'm not directly
involved in the issues at hand, and am responding unofficially/personally on my
own accord]
PPP and SLIP, while stated clones of TCP, apparently are not in some critical
way that seems to confuse Sybase.  It would be worthwhile, probably, to be
compatible with these products, but i think such ventures into new capabilities
are limited to specification by a marketing organization.  i know marketing has
a pc certification lab for vendors to come through and test their products with
our to insure compatibility; i'm not sure any SLIP or PPP software has been
tested.  Since it is PPP's job to be compatible with applications running in
your platform's TCP/IP driver, it would be worthwhile for you to ask your PPP
vendor why this connectivity doesn't work.

one other thing that i know engineering spends a lot of time on related
to dealing with new supporting software is certifying our products for
use with new versions of currently-supported operating systems.  this
can be a very involved process, since the penalties for missing
something are very great.  we take compatibility very seriously, and making
things work can take a lot more than a phone call.

from my vantage point (admittedly outside engineering), what this boils down to
is that engineering resources are focused on what brings the most utility to
the most existing and potential customers.  exclusive of any particular company,
including sybase, i think this is a wise policy when one doesn't have infinite
engineering resources.

>>I started wondering what my umpteen thousand dollars of support actually bought.
>>Perhaps I don't have enough Sybase licenses to worry about...

i can tell you for certain that virtually no one outside of a small group in
accounting knows what anyone pays for support.  that info is available, but the
schema for the database is beyond most anyone's comprehension.  i wrote the
access Tech Support uses to that database, so i know what they see and how
difficult it is to find.  we are not a cost center within the company, so money
is not the issue.  trust me, we're trying to find time to talk to everyone at
once; there is no time to worry about how much anything costs.

>>IMHO, Sybase technical support is only an elaborate setup of telephone operators:
>>there is NO technical expertise and these operators show quite a bit of reluctance
>>to "bother" the engineers.  I really don't understand this.  I'm a software development
>>manager.  When there's a problem with "my" software that our tech support can't
>>handle, I WANT to know.  I have no problem devoting a development resource to fixing
>>a client bug.
>>
>>Well this was my first contact with tech support, if my next contact remotely
>>resembles this one you can be sure I will seriously reconsider any database decisions
>>of my company.

>>dave st clair

i think you should give sybase more than ONE chance to support you before you
write off the whole department as ineffective or stupid or whatever you are
trying to say, simply because we don't support what your sybase support
and license agreements say we don't, or don't do things the way you do.
we do the best we can.
you may be interested to know that just about every dedicated
hardworking PROFESSIONAL in tech support got to read that quote about
"telephone operators." it was not ..  pleasing news.

with the client / server RDBMS market very hot now as other vendors are
trying to catch up with something sybase started, release dates are
consequently very important to keep, as we can't afford to break our
promises to thousands of customers and SHAREHOLDERS to have development
worry about an unsupported platform.  it isn't that black and white, and i
don't know personally how engineering sets its priorities, or how the project
managers think, but from my vantage point (7.5 years in the making), that's
how it looks.  while worrying about customers' views of our products'
defects and shortcomings is important to development engineers, they
jury is still out on sybase and SLIP/PPP, and there is no time in the
release schedule to embark on something unscheduled.  our priorities
are different, that's all.  this is not from a payment or support level
standpoint, but from a greater responsibility / usefulness one, in my
personal opinion.  System 10 will be much more fun than Sybase on
SLIP.
i'll also be working on a side-project (on my own time and initiative) to bring
more engineers into the issues faced by customers with the code they write.
i personally feel this is very important.

>Your experiences have mirrored mine for about 60 - 70% of the times I have contacted
>Sybase support.
>Why do I consistently see messages like this posted to various newsgroups?
>While there are a FEW highly qualified people at support, most seem to be of the
>right out of school variety. It appears to me they send the engineers to a couple
>of internal classes and they are then "fully trained support engineers".

I think the reason is more that technical support by nature burns people out.
i hear screams on the floor very often, along with slamming doors and weeping.
tech support is a very draining job, i think.
no one can talk on the phone forever.  career paths lead knowledgeable people
elsewhere (fortunately, none have gone to an insane asylum).  This is a support
industry phenomenon, not sybase's fault.

>The reason (I feel) they can get away with this is that sites like ours that have large
>databases that are crucial to operation. We MUST have support no matter how poor
>the quality and overpriced the charges are. While $7,000 is a ridiculous amount to
>charge for telephone support, if the support was of good quality I would bother me
>so much. Since Sybase is charge an additional fee for phone support, it should
>be an option to be charged by the call instead of just a singe fee. It makes no sense
>to charge a small company like ours the same fee for 2 or 3 contact, as a large company
>have a few hundred contacts per year.
>

support is charged on the basis of number of contacts, not number of licenses.
several of our customers pay more than the median price for a house in the bay
aera (highest in the US) YEARLY for our support, and are completely
satisfied.  you are getting a BARGAIN at only $7,000.  our pricing
structure IS in line with your expectations, i think.

as i said above, the issue is never money, as most folks in tech
support could care less... they really do want to help customers out,
but there are often 50-100 of them per analyst to deal with, and juggling
everyone is not easy.  every quarter new programs are begun to better
deal with customers' problems, but every quarter more people call.  it
is a difficult problem, not being able to control nor keep up with
demand for your product (support).  you can be assured we are always
working on it.  every TS organization goes through this, i bet.  we're
not penalizing you for paying as little as you do.

>SYBASE SUPPORT WAKE UP!!

we never sleep.  we're open 24 hours a day.

>Your competitors are also reading these messages.

.. and the TS people at those companies probably aren't, as they don't have the
time.  they'd be nodding their heads if they did!
i wonder why none of them come to our defense, probably being in the same boat?
could negative press be beneficial?  do they get as bored as i do reading
comp.databases.oracle ?!

>Jay Twery

--
..ben
------
Benjamin von Ullrich         all words are those of the author, not Sybase.
[e-mail]                   {pyramid,pacbell,sun,lll-tis}!sybase!ben