taylor@limbo.Intuitive.Com (Dave Taylor) (11/28/89)
Aaron Schuman, from HP's Information Networks Division, recently commented here in this forum that: > HP has an excellent service department with procedures to ensure that every > customer gets helped. There is a phone-in consultation service, a set of > regional response centers, and factory on-line support. Every defect report > and enhancement request gets catalogued and assigned to an owner. Employees > are evaluated on the basis of how effectively we resolve service requests. While this might well be the company line, it is *not* the reality of the situation. In fact, it's a wonder to me how HP can be rated so highly on customer support, frankly. I think that instead of showing that HP does it right, it demonstrates that everyone else does it even more poorly... When I was an employee of HP, for example, I encountered literally hundreds of bugs, quirks, documentation errors, invalid behaviours, &c &c while pushing the edges of the HP-UX operating system. Each time I encountered one I submitted a defect via the internal Defect Tracking System like a good employee concerned with the quality of the end product. NONE of them were ever resolved, and in fact it was almost traditional that "the owner" of the defect would assign it to someone else at least two or three times (each assignment having about a 5-6 week time lapse) and then it would just vanish, or be returned "unable to duplicate" a year or two later. Classic stories are those of my friends at HP Labs who submitted bugs in 1984 or 1985 and have only recently received a "bug closing report" that simply states "obsoleted by new release" when, ironically enough, they can go and duplicate the same bug in the most current OS release! Having gone from a position where I submitted bugs into the great black hole of HP customer support to where I work with HP customers, I can assure you that it is no better for people that are paying money. Even the so-called show stopper bugs don't mean that HP immediately mobilizes all their forces and solves it ASAP. I have heard of some sites that have been without use of their machines for many months while waiting for their SE, customer support engineer, assigned engineer, etc to actually FIX the problem and send them a patch or workaround. One of the problems that HP has with their customer support methodology, by the way, is that they want to keep the information on their defects as private as possible, so instead of doing something like, say, posting the workaround patch to the "-O" compiler optimization bug that everyone has been clamouring about for weeks here on the net, they simply have their SE's deliver the patch to those customers that ASK THE SE specifically about it (and actually its a further subset yet; you have to luck out and hit the SE that knows the HP-UX product line sufficiently well to be aware of the problem and the patch...) It would be an interesting experiment for HP to sponsor the creation of a new newsgroup "comp.sys.hp.patches" (or a mailing list, BBS, or whatever) and then use that forum for the dissemination of SSB's, the infamous software status bulletins where theoretically us HP-UX customers are informed of problems and solutions in the current release of the operating system. Unfortunately, the need for this sort of thing is increasing over time, not decreasing; while the core HP-UX product might be getting more and more solid, the operating system environment as a whole is getting much more complex and larger than originally, and therefore, not surprisingly, the number of defects will increase as the size and complexity of the product increase too (I feel like quoting Tom Peters here, but can't think of anything appropriate. Sorry :-). The most depressing thing to me is that HP is indeed one of the top companies in the computer industry when it comes to customer support! Further, in my opinion (and in the opinion of many others) HP makes the most solid and reliable computer equipment in the industry too, including their OS and applications. It's just "being best" isn't good enough. It's a fast moving world out there and if AT&T can promise guaranteed 30 minute turnaround on problem reports called in, why can't HP promise less than 2 weeks? (*) From the trenches, -- Dave Taylor (*) Actually, HP policy is a return call within 2 hours of the initial problem report arriving at the Customer Support Center(s), but I recall that the average time to resolve a problem is quite a bit longer than the two hours...and when you consider the number of people that the customer probably has to get through (including their FE, SE, customer support, who then has to track down and find the responsible engineer who has to fit it into their own busy schedule), well, two weeks is probably generous... Intuitive Systems Mountain View, California taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor
mart@ele.tue.nl (Mart van Stiphout) (11/28/89)
In article <203@limbo.Intuitive.Com> taylor@limbo.Intuitive.Com (Dave Taylor) writes: >private as possible, so instead of doing something like, say, posting the >workaround patch to the "-O" compiler optimization bug that everyone has >been clamouring about for weeks here on the net, they simply have their SE's >deliver the patch to those customers that ASK THE SE specifically about it I guess you'right but we've the same situation with Apollo. Apparently they produce patch tapes once a month or so but you never get to see them unless: 1. you have a problem 2. know there is a patch 3. ask them for it. I very much agree with you on a news or mailing service for this kind of trouble. Would be much faster and cheaper than sending patch tapes. -- Mart van Stiphout mart@ele.tue.nl (It's not the fall that kills you, it's the sudden stop)
frank@hpuamsa.UUCP (Frank Slootweg CRC) (11/28/89)
Dave, While I do not want to deny that there are still software quality and software support problems at HP, I think your experience as a HP employee can not be compared to that of the *average* *paying* customer. Like with software the quality of support is related to the price you pay. If you don't pay (i.e. you have no *support* contract but only a *materials* contract) then the support will be limited or none. If you do have a software contract then - You *do* know who to call (i.e. the Response Center, no need to chase Sales Reps, System Engineers, etc.). - We *do* (in *most* cases) respond within less than 2 hours. > I can assure > you that it is no better for people that are paying money. Even the so-called > show stopper bugs don't mean that HP immediately mobilizes all their forces > and solves it ASAP. I have heard of some sites that have been without use of > their machines for many months while waiting for their SE, customer support > engineer, assigned engineer, etc to actually FIX the problem and send them a > patch or workaround. If *paying* customers are getting this bad support then hit on the Response Center (or other) management. There are defined escalation procedures for this (upto the company president!). *No one* can ignore these procudure (Believe me, I have often felt the "heat".). > It would be an interesting experiment for HP to sponsor the creation of a new > newsgroup "comp.sys.hp.patches" (or a mailing list, BBS, or whatever) and then > use that forum for the dissemination of SSB's, the infamous software status > bulletins where theoretically us HP-UX customers are informed of problems > and solutions in the current release of the operating system. Perhaps this is a good idea (there is never *one* solution to a problem). However from experience I doubt if paying customers want this. They do not want to be *informed* about bugs they *don't* run into, they want *solutions* for bugs they *do* run into. To give an anology: If I have a on-line telephone directory then I don't need nor want a phone book. If a customer calls the Response Center we can quickly determine if the described problem is a known one. Remember the Software Status Bulletin is a printout (i.e. offline) of a database to which the Response Center has on-line access. Also support products are under development and partially already existing that give customers access to this database. Currently these support products are generic (i.e. for the same for 9000, 1000, 3000, etc.) and use dial-in terminal access. > It's just "being best" isn't good enough. It's a fast moving world out > there and if AT&T can promise guaranteed 30 minute turnaround on problem > reports called in, why can't HP promise less than 2 weeks? (*) Please rest assured that we are constantly reminded by management that because we do well and are successfull while doing it, other companies will improve their support (and software quality) too and we will have to do even better. I have a problem with the term "turnaround". In our terminology it means "time to fix" (or create a workaround for) the customers system. I doubt that AT&T can guarantee (or even on the average realize) that :-). As you write our *response time* is "guaranteed" to be less than two hours. At least in The Netherlands well above 90% of the calls fall in this window. Worldwide our next challenge is to shorten the *worst case* time-to-fix (the *average* time-to-fix is already good (hours to a few days) as is "proven" by our good support ratings (Datapro and others)). So again, our support needs to get better because it is not perfect and other companies are also improving their support. However I think your posting needed some balance. Frank Slootweg, HP-UX Support, Dutch Customer Response Center.
mck@hp-ptp.HP.COM (Doug_McKenzie) (11/29/89)
Dave, what are you saying? It seems what you're suggesting is that HP Support is terrible, the best in the business. It's like after insulting and accusing HP of almost malicious negligence, you feel apologetic?!? I think you should calm down. > When I was an employee of HP, for example, I encountered literally hundreds > of bugs, quirks, documentation errors, invalid behaviours, &c &c while > pushing the edges of the HP-UX operating system. Each time I encountered > one I submitted a defect via the internal Defect Tracking System like a > good employee concerned with the quality of the end product. NONE of them > were ever resolved, and in fact it was almost traditional that "the owner" > of the defect would assign it to someone else at least two or three times > (each assignment having about a 5-6 week time lapse) and then it would > just vanish, or be returned "unable to duplicate" a year or two later. You found "hundreds of bugs", "NONE of them were ever resolved"? Are you serious? With this 0% fix rate, I suppose your inescapable conclusion is that no bugs ever found in HP-UX by anyone, are ever fixed. I don't deny that bugs have been reported, and not fixed. Most of these have to do with being found too late to make it into the "frozen" release. Critical bugs found "at the last minute" ARE incorporated into the release, but they must BE critical, because incorporating a fix means re-running the fairly huge set of quality assurance tests all over again, and potentially delaying a release. Customers hate it when a release is delayed, just as they hate it when they find bugs. It's a matter of balancing timing with the criticalness of the bug. I wouldn't even deny that some bug fixes fail to make it into subsequent releases. Nobody's perfect, some bugs fall through holes. I do deny that it's common, much less "almost traditional ... [that] it would just vanish". Being returned as "unable to duplicate" can mean many things -- a defect submission of 10,000 lines with the comment "it doesn't work", a customer-modified or other non-standard HP-UX, lack of adequate configuration or other information in the submission, etc. I think your innuendo is that the bug "owner" is lazy, and this is VERY UNTRUE, in my experience. > Classic stories are those of my friends at HP Labs who submitted bugs in > 1984 or 1985 and have only recently received a "bug closing report" that > simply states "obsoleted by new release" when, ironically enough, they > can go and duplicate the same bug in the most current OS release! Maybe so. Care to name a few (bugs, not friends :-)? > Even the so-called > show stopper bugs don't mean that HP immediately mobilizes all their forces > and solves it ASAP. I have heard of some sites that have been without use of > their machines for many months while waiting for their SE, customer support > engineer, assigned engineer, etc to actually FIX the problem and send them a > patch or workaround. Well, once again I can't deny that this ever happens, but I don't know of any times that it has. I do know that HP has on occassion sent a new machine to a customer long before "many months" had passed, when the problem couldn't be locally resolved. Software fixes are usually much quicker to resolve, because the problem can be emailed. Everyone I know at HP recognizes that months-long delays in fixing problems loses customers, and is perhaps the worst way to run a business. > It would be an interesting experiment for HP to sponsor the creation of a new > newsgroup "comp.sys.hp.patches" (or a mailing list, BBS, or whatever) and then > use that forum for the dissemination of SSB's, the infamous software status > bulletins where theoretically us HP-UX customers are informed of problems > and solutions in the current release of the operating system. I agree about the patch BBS. Why is the SSB "infamous"? > The most depressing thing to me is that HP is indeed one of the top companies > in the computer industry when it comes to customer support! Further, in my > opinion (and in the opinion of many others) HP makes the most solid and > reliable computer equipment in the industry too, including their OS and > applications. Thank you. But I don't get how you can say this, after claiming that NONE of the bugs you found was ever fixed. > It's just "being best" isn't good enough. It's a fast moving world out > there and if AT&T can promise guaranteed 30 minute turnaround on problem > reports called in, why can't HP promise less than 2 weeks? (*) > (*) Actually, HP policy is a return call within 2 hours of the initial > problem report arriving at the Customer Support Center(s), but I > recall that the average time to resolve a problem is quite a bit > longer than the two hours...and when you consider the number of > people that the customer probably has to get through (including > their FE, SE, customer support, who then has to track down and > find the responsible engineer who has to fit it into their own > busy schedule), well, two weeks is probably generous... I don't think a simple average tells the story. If a company puts out terrible documentation, more calls will be received asking simple how-to questions. I have NO knowledge of AT&T's policy, but I seriously doubt that all problems can be RESOLVED within 30 minutes. Sometimes, a customer can call the (HP) Response Center, and receive an answer in 2 minutes. Other times, an HP support person may have to drive 150 miles to a customer site, to investigate a problem. It all depends. Doug McKenzie | This disclaimer is for legal purposes. No HP-UX Support | statement here is meant to express HP policy. mck@hpdstma.ptp.hp.com | I don't speak for HP, only for myself. I have or | no legal opinions. There, that should do it. hplabs!hpdstma!mck
davew@hp-ptp.HP.COM (Dave_Waller) (11/30/89)
mart@ele.tue.nl (Mart van Stiphout) writes: > In article <203@limbo.Intuitive.Com> taylor@limbo.Intuitive.Com (Dave Taylor) writes: > >private as possible, so instead of doing something like, say, posting the > >workaround patch to the "-O" compiler optimization bug that everyone has > >been clamouring about for weeks here on the net, they simply have their SE's > >deliver the patch to those customers that ASK THE SE specifically about it > > I guess you'right but we've the same situation with Apollo. Apparently > they produce patch tapes once a month or so but you never get to see > them unless: > 1. you have a problem > 2. know there is a patch > 3. ask them for it. > > I very much agree with you on a news or mailing service for this kind of > trouble. Would be much faster and cheaper than sending patch tapes. > -- > > Mart van Stiphout > mart@ele.tue.nl > (It's not the fall that kills you, it's the sudden stop) > ---------- The primary reason why HP and other companies don't post patches to a public forum like USENET is because of liability. This is not a cheap excuse. It is a fact of the business world. In contrast to say, most of Apple's customers, HP customers tend to be large institutions or companies with a legal department and alot of money. If HP distributes a patch BEFORE it has been rigorously tested, and the end user uses the patch in a critical production situation, and the patch fails to fix the problem, there are many people out there with the financial clout to sue the company that WILL. Even if they don't win, it ends up costing HP alot of money, time, and headache. If they do win, it could mean the end of HP. Furthermore, our exposure is dramtically increased through a distribution channel such as USENET because we have no control over who gets the patches, and therefore the liability issue is that much more dangerous. When we can deal with individual customers, proper expectations can be set before the delivery of an interim fix. I must take issue with Dave Taylor's comments that bugs don't get fixed. I have worked for HP for 5 years, in support, and my experience has been that the exception is the bug that gets completely ignored. I too have found numerous bugs, and submitted internal DTS reports about them. All of mine have been addressed, and most have been fixed. Sometimes it just TAKES a long time to resolve a particularly nasty bug. However, the statistics are that most problems are resolved within a few days. Granted, many of these are user misunderstanding problems, however customers get a pretty good deal from HP when purchasing RC support to answer these questions, when one considers what it would cost to pay a consultant to do the same -- and that is essentially the service they are getting with these type of questions. The tougher bugs don't take many weeks because people are lazy or ignorant -- they take a long time because sometimes they are VERY difficult to solve. One bug that I was working on with two other engineers over the last several weeks was particularly hard to find because its behaviour was timing related, so we were not able to reproduce it on every series 800 machine in the same way. Often the most dificult task is just reproducing the bug reliably, a task that many customers are uncooperative in helping us with because they don't want to share their software with us that produces the bug (in the aforementioned example, this was not the case, thank goodness!). Dave, I have sympathy with your frustrations. Would that HP had unlimited resources, we could probably fix everything that everyone wanted in the time frame they wanted. However, given the limited resources that we (and for that matter, any other vendor) have, hard decisions have to be made, thereby leaving SOMEONE's critical bug unfixed. These people are not going to be happy no matter how hard one tries to pursuade them of the reality of the situation. However, your experience is, as far as I can determine, the extreme exception inside and outside HP. It seems that you were incredibly unlucky. Dave Waller \ The opinions expressed are solely my own, and in no way Hewlett-Packard Co. \ represent those of my employer (but we all know dave@hpdstma.ptp.hp.com | hplabs!hpdstma!dave \ they should!)
taylor@limbo.Intuitive.Com (Dave Taylor) (11/30/89)
Frank Slootweg from Dutch HP-UX Customer Support Center of HP replies to my article on HP Customer Support with a number of well-reasoned thouhts and comments. Before I continue our discussion, though, let me state here how delighted I am that someone from HP Customer Support can join us in this forum and help clear the confusion out of the air!! Thanks a LOT, Frank, for participating here! Back to being the foil, however! You comment that "the quality of support is related to the price you pay". I understand the economic reality of this, but can't help pointing out that it implies that companies like General Motors or International Paper or other "major accounts" get better service on a per-computer level than smaller places like the Four Seasons hotel chain. And they get better service and support than HP divisions. Or do they? Similar to almost all other computer companies nowadays, HP has a thriving internal conferencing system where people from just about any area of the firm can post requests, simple, silly, or quite complex, and get speedy responses from some of the best technical people in the company. For the technical confusion issues, this can greatly ease the demands of the customer support organizations (and, of course, HP internal are customers too; they pay for the equipment and more often than not get support contracts too). However, the most active non-official forum that HP customers have is this newsgroup, and, as an unofficial channel, it's not necessarily the best place to get support. So instead customers use the formal and official channels (not unreasonably!) for their problems, questions, suggestions, enhancement requests, and so on. As Frank points out, about 90% of the calls received by the customer support center can be dealt with either while on the telephone with the customer or certainly within an hour or two, which is great. The problem is with the other 10%, those calls that require the assistance of a system architect, subject matter expert, or perhaps the original designer or programmer of the particular application. Those problems are really what I was referring to in my original posting, rather than the entire class of problems at once. It seems to me, whether or not the reporting customer is internal, that complex technical problems and difficulties should be fixed ASAP and resolved in a timely fashion. Further, it strikes me that many of the bugs and problems that external, paying customers encounter must have already been encountered by internal people (since HP distributed alpha and beta copies of software months in advance). If we accept this as the case, then there are two questions which arise in this context; 1. Do these problems get reported, and 2. If so, do they get logged and resolved in a timely fashion? I surmise that in fact most of the problems people encounter with new software internally does not get reported (for the reasons cited in my previous message; I know that most of my colleagues gave up reporting OS and application bugs years ago), because of #2. Again, one of the problems that we're circling around here seems to be the timely dissemination of patch and modification information. As Frank himself points out, " If I have a on-line telephone directory then I don't need nor want a phone book" which, to me, seems to indicate correctly that the information would be *more* useful if it were in an on-line format; e.g. through a medium like comp.sys.hp.bugs Of course, there is actually a formal channel within the HP customer support organization for the timely dissemination of SSBs, bug reports, patches, workarounds, etc, called the HP SupportLine. Last I heard, however, it was still just for MPE and MPE/XL customers. In any case, when it does offer assistance to HP-UX customers, will they use it? Do you, as an interested and (probably) technically sophisticated HP-UX customer and/or user, want to find the time to call up, peruse, and extract information from yet another BBS-type system? (actually, I do SupportLine an injustice; it's actually a very well designed dialup information service. It's just that it is something new, and something else to hassle with, alas). I'll step on some thin ice and disagree with Frank in his assertion that customers: > .. do not want to be *informed* about bugs they *don't* run into, they > want *solutions* for bugs they *do* run into. If nothing else, this doesn't agree with his analogy of the on-line telephone directory; one of the reasons that people probably don't want to be informed about bugs is because being informed implies having to read through the printed SSB document that comes out ?quarterly? If, instead, it were easily accessible and "grep"able, say, we might well find that site sysadmin folk might by default check that database before they even call customer support! That'd be cool, wouldn't it? The problem is how to disseminate this information. Using SupportLine is a nice idea, but I don't believe reflects the reality of the HP-UX customer base: most just aren't going to be interested in calling up to muck with a new system. Having it on their own computer system where they can have locally written browsers (say), or even just the relatively primitive search facilities of Notes, RN, or other of the netnews browsers, seems like a big win to me... and with the appropriate juggling, I can forsee a situation where, say, there's a group "comp.os.hp-ux.bugs" where articles expire as soon as the same SSB shows up on the CD-ROM SSB database coming to a computer near you (HP has already announced it, actually, scooping all the other vendors in the biz!) This is already getting too long as netnews articles go (curse this journalistic background! Getting paid by the word does some really horrible things to your writing style! :-) so I'll wrap up by again stating that: o While 90%+ of the people who contact HP Customer Support with problems have them resolved within an hour or two, the other 10% might find delays of a day to ?? in even getting a response to their problem, let along a fix or workaround. o Dissemination of patches, bug fixes, &c is an area that HP could put further effort into, perhaps bringing us HP customers to a point where we can know within hours of any bug report, and then later have the fixes/patches automatically associated with the problem reports. o If YOU, as a paying (or non-paying) customer of HP find that your problem reports go unresolved, ESCALATE! Call up some people in management and start raising a fuss. John Young has mentioned before that he's gotten calls directly from irate HP-UX customers, so you wouldn't be the first... Finally, I would like to reiterate that however critical I seem, I really am quite a fan of Hewlett-Packard, their people, and their products. It's a great lineup with some "room for improvement" in certain areas... Thanks again for your response, Frank! -- Dave Taylor Intuitive Systems Mountain View, California taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor
jsadler@bcstec.UUCP (Jim Sadler) (11/30/89)
In article <203@limbo.Intuitive.Com>, taylor@limbo.Intuitive.Com (Dave Taylor) writes: > Aaron Schuman, from HP's Information Networks Division, recently commented > here in this forum that: > > > HP has an excellent service department with procedures to ensure that every > > customer gets helped. There is a phone-in consultation service, a set of > > While this might well be the company line, it is *not* the reality of > the situation. In fact, it's a wonder to me how HP can be rated so > highly on customer support, frankly. I think that instead of showing that > HP does it right, it demonstrates that everyone else does it even more > poorly... After dealing with HP for over 8 years, I have to agree 150%+ with dave on this I think that the HP manuals are the best that I've used. But they still need considerable work. (Yes, I've filled out the comment cards, checked the please respond box and never received a reply) > Stuff about hp employees submitting bugs and being "resolved" only to have the bug show up again. > one I submitted a defect via the internal Defect Tracking System like a > good employee concerned with the quality of the end product. NONE of them Well I guess I can be consoled that what happens to me, happens to HP :-| > Classic stories are those of my friends at HP Labs who submitted bugs in > 1984 or 1985 and have only recently received a "bug closing report" that > simply states "obsoleted by new release" when, ironically enough, they > can go and duplicate the same bug in the most current OS release! I reported a bug with the way cu doesn't find a open modem in 85 I believe its still in the code. > and solves it ASAP. I have heard of some sites that have been without use of > their machines for many months while waiting for their SE, customer support > engineer, assigned engineer, etc to actually FIX the problem and send them a > patch or workaround. I hope to NEVER have this happen and it hasn't with any machine that I've supported. > been clamouring about for weeks here on the net, they simply have their SE's > deliver the patch to those customers that ASK THE SE specifically about it Unfortuneately this is true for several other vendors in the marketplace. It's almost "standard practice". It a very poor way for any vendor too treat customers in MHO. > > It would be an interesting experiment for HP to sponsor the creation of a new > newsgroup "comp.sys.hp.patches" (or a mailing list, BBS, or whatever) and then Sounds good the only problems is that instead of helping customers most vendors listen to their legal departments. Legal says "Be safe don't sell anything" > > The most depressing thing to me is that HP is indeed one of the top companies > in the computer industry when it comes to customer support! Further, in my > opinion (and in the opinion of many others) HP makes the most solid and > reliable computer equipment in the industry too, including their OS and > applications. I think most of the good reputation that HP has comes from the commercial side of the house and not the technical/unix side. I do agree about the reliability of the hardware that hp produces. The only disk drive I've seen go bad have been ones that were abused. > From the trenches, > > -- Dave Taylor Well that is my two cents worth. I think HP is getting better, it's like watching a glacier move. (I certainly can't say that my company is any better) jim sadler 206-234-9009 email uunet!bcstec!jsadler|root | hplabs!hpubvwa!b-mrda!jim
rer@hpfcdc.HP.COM (Rob Robason) (12/01/89)
In responding, let me say that the opinions here are my own, and not a statement of HP position. I will attempt to remain impartial, though this is difficult, so take what I say with a grain of salt. For background, I work in the HP-UX commands lab in Fort Collins and have for 4 1/2 years, before that I was a field SE for 4 years and supported HP-UX when it first came out, before that I was an HP customer. > Each time I encountered one I submitted a defect via the internal Defect > Tracking System like a good employee concerned with the quality of the > end product. The DTS system is an internal system for reporting defects and enhancement requests. Since HP first started shipping HP-UX (and before) DTS has been used for all kinds of things including enhancements, gripes about standard UN*X behaviour and how HP should "improve" it. It took us a while to mature to the point where we stopped "improving" the UN*X out of UN*X. DTS is not used for submitting Customer Reported defects, but a system called STARS (Software Tracking and Reporting System, I think) is used for that. DTS reports do not receive the same attention that customer reported (STARS) defects do, though we do fix EVERY serious or critical DTS and STARS defect before each release. We do not necessarily fix defects that are of low severity or an enhancement request, and many of these are resolved as "won't fix" or "won't do" because they break standard behavior or are stupid (yes, we don't come up with some dumb ideas, even in HP! I know: "hard to believe"). > Having gone from a position where I submitted bugs into the great black > hole of HP customer support to where I work with HP customers, I can > assure you that it is no better for people that are paying money. Even > the so-called show stopper bugs don't mean that HP immediately mobilizes > all their forces and solves it ASAP. I have heard of some sites that > have been without use of their machines for many months while waiting > for their SE, customer support engineer, assigned engineer, etc to > actually FIX the problem and send them a patch or workaround. "Show stopper" is a DTS'ism, and not something that applies to customer related problems anyway, but I'd like to set the record straight. A DTS "show stopper" does just that. No product is released, and in fact manufacture of a released product is generally halted, when a "show stopper" defect is filed against it. STARS defects of critical nature get much more attention. In the case of a customer site on support services where the system is unusable for its intended purpose, HP has a well defined "site escalation" policy which assures HP's resources to resolve a problem and get the system back up and operational. A site gets first local, then regional and then factory resources, when the factory gets involved we call it a "hot site" and it gets precedence over all other activity in the lab. Ask your support SE to review our escalation schedule policy. I know for a fact that hot sites get labbies assigned until the site is de-escalated. This system really works (when invoked)! I will admit, however, that some sites do not get escalated properly. I lay the blame in some cases to local HP people dropping the ball by underestimating the impact of a problem on the customer, and in others to failure of customers to inform HP that they are unable to function. This is one of those situations like marriage where both sides have to put 100% into making things work: never ASSUMING the other will do their part. If you assume HP doesn't know that you MUST HAVE this fixed, you'll stand a better chance of getting it resolved in a timely way. In our own lab, I have seen some real improvements in our handling of STARS reports, and where in years past STARS seemed like a black hole, I have seen a lot of improvement and there is more work being done. Unfortunately, some people already have their minds made up about our support based on previous problems. > One of the problems that HP has with their customer support methodology, > by the way, is that they want to keep the information on their defects > as private as possible, so instead of doing something like, say, posting > the workaround patch to the "-O" compiler optimization bug that everyone > has been clamouring about for weeks here on the net, they simply have > their SE's deliver the patch to those customers that ASK THE SE > specifically about it Well, nobody likes to air their dirty laundry. Obviously, if the public impression of HP-UX is that it is perfect, its better for sales than an impression of a product with 100s of defects. On the other hand, we publish all reported defects in the Software Status Bulletin (SSB) and still get duplicate reports of the ones that are there. My own experience is that customers (and SEs) don't read the SSB. That's not trying to pass the buck, but pointing out that nobody listens when every defect is reported because the noise level is too high. If you've ever read the SSB, you'll see why nobody does: it's pretty boring reading about the obscure bugs described. So a legitimate reason for waiting to supply fixes to customers until a next regular release is to reduce the inconvenience factor to the customer. The fact that fortran causes a core dump when multiplying complex numbers by the loop counter in a double nested do loop, or that bc core dumps when the stack grows over 4 Gbytes are things that most customers can get by just fine without knowing. And the fact that we reported the bc bug 4 months ago on notes will go unnoticed until someone at the customer site starts using bc next month and hits the problem. People just don't pay attention to problems that don't affect them. I agree that a nice solution would be some sort of on-line browse facility for customers on support services. It seems that HP is moving in that direction from some of the recent public announcements. > The most depressing thing to me is that HP is indeed one of the top > companies in the computer industry when it comes to customer support! I think this is a reflection of how complex the problem is. HP has been more successful in spite of the industry's immaturity in the area of customer support. I think a lot of this success is due to HP's historical culture: many of our top managers grew up in the HP instrument industry, where nothing less than perfection was acceptable. This culture has forced success in computer customer satisfaction by sheer determination despite lack of supporting technology and has driven development by HP of a lot of that technology that exists today. > Further, in my opinion (and in the opinion of many others) HP makes the > most solid and reliable computer equipment in the industry too, > including their OS and applications. Thanks. That's a kudo that *everyone* in HP has worked *hard* to earn. > It's just "being best" isn't good enough. It's a fast moving world out > there I'll agree that being best isn't good enough, though the old saying about "look at the past to predict the future" has some validity here. We're not resting on our laurels, that's for sure. > and if AT&T can promise guaranteed 30 minute turnaround on problem > reports called in, why can't HP promise less than 2 weeks? (*) > (*) Actually, HP policy is a return call within 2 hours of the initial > problem report arriving at the Customer Support Center(s), but I > recall that the average time to resolve a problem is quite a bit > longer than the two hours...and when you consider the number of > people that the customer probably has to get through (including > their FE, SE, customer support, who then has to track down and > find the responsible engineer who has to fit it into their own > busy schedule), well, two weeks is probably generous... As far as promises, HP has a good track record for *delivering* on our promises. I also think you kind of slanted the way you presented the data. I know nothing of AT&T's support, but I think HP's 2 hours is a reasonable MAXIMUM. I've had a support contract for some time and generally get called back much sooner than that. Anyway, "turnaround" is a pretty nebulous term, I'd be astonished if it meant "resolution". And in reaching HP you don't go through the FE or SE, but start by calling the response center immediately. If necessary, they track down the appropriate lab, engineer, etc and my experience is that they do a pretty efficient job of that. The customer has one contact at the response center until the site is escalated, when a more local escalation center takes over communications between the factory and the customer. If I've had any complaint in the past it's that we've sometimes left people wondering what, if anything, we're doing. When problems move into an escalated mode (hot site), they're often in the hands of a sharp labbie with poor communication skills. I've noted vast improvements in this area of follow up and communication back to customers in the last year or so. > taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor Rob Robason rer@hpfclg.hp.com
dlow@hpspcoi.HP.COM (Danny Low) (12/01/89)
>You comment that "the quality of support is related to the price you pay". I think this refers to the fact that an HP entity that buys a support contract from another HP entity only pays cost and pays it with accounting money. An outside customer pays "retail" with real money. Guess who has the higher priority on scarce SE time. >Similar to almost all other computer companies nowadays, HP has a thriving >internal conferencing system where people from just about any area of the >firm can post requests, simple, silly, or quite complex, and get speedy >responses from some of the best technical people in the company. This method is used because HP has no formal support method for internal HP users. The only formal method is to pretend to be an outsider and buy a support contract but that runs into the above problem. Danny Low "Question Authority and the Authorities will question You" Valley of Hearts Delight, Silicon Valley HP SPCD dlow%hpspcoi@hplabs.hp.com ...!hplabs!hpspcoi!dlow
gentry@kcdev.UUCP (Art Gentry) (12/01/89)
In article <1320019@hp-ptp.HP.COM> mck@hp-ptp.HP.COM (Doug_McKenzie) writes: I have only included those parts of the post that I have a response to, several paragraphs have been intentionally left off for brevity. >Dave, what are you saying? It seems what you're suggesting is that HP >Support is terrible, the best in the business. It's like after insulting >and accusing HP of almost malicious negligence, you feel apologetic?!? I >think you should calm down. > I would tend to agree with this statement. I've seen Dave 'go off' before and am starting to think he has a 'thing' about HP since leaving them. Yes, this will probably be classified as a ?friendly? flame. (are we still friends, Dave?) > >I don't deny that bugs have been reported, and not fixed. Most of these >have to do with being found too late to make it into the "frozen" release. >Critical bugs found "at the last minute" ARE incorporated into the release, >but they must BE critical, because incorporating a fix means re-running the >fairly huge set of quality assurance tests all over again, and potentially >delaying a release. Customers hate it when a release is delayed, just as >they hate it when they find bugs. It's a matter of balancing timing with >the criticalness of the bug. > Yes, I do HATE it when releases are way beyond the promised timeframe. But on the other hand, I am still smarting from an RTE release that went out so buggy, it looked like a shotgun was taken to it before it left the factory. After getting the product manager out here, with sources, spending 2 days fixing bugs, I found out that it left the factory without being QA'd. Not nice guys!! >I wouldn't even deny that some bug fixes fail to make it into subsequent >releases. Nobody's perfect, some bugs fall through holes. I do deny that >it's common, much less "almost traditional ... [that] it would just vanish". >Being returned as "unable to duplicate" can mean many things -- a defect >submission of 10,000 lines with the comment "it doesn't work", a >customer-modified or other non-standard HP-UX, lack of adequate >configuration or other information in the submission, etc. I think your >innuendo is that the bug "owner" is lazy, and this is VERY UNTRUE, in my >experience. > Here, I have to disagree!! Though I might change lazy to unknowlegable. Many a time, I have had to 'educate' the response center personell on just how the product/program/process is "supposed" to work, regardless of what the documentation may say. While it has gotten better, it still grates me that I get professional manual readers at the RC and not subject matter experts. The standard party line is, "I'll have to get in touch with the factory and get back to you". > >Well, once again I can't deny that this ever happens, but I don't know of >any times that it has. I do know that HP has on occassion sent a new >machine to a customer long before "many months" had passed, when the problem >couldn't be locally resolved. Software fixes are usually much quicker to >resolve, because the problem can be emailed. Everyone I know at HP >recognizes that months-long delays in fixing problems loses customers, and >is perhaps the worst way to run a business. > Emailed???? What an original idea???? When is the RC going to recognize that this is a valid option? Talk about cost savings!! Everytime I want a bug fix I have to wait for the RC to FedEx it to me or spend the time to TRY and get hold of my local SE to dial into the SE Support System in Fort Collins to download it for me. I have requested that the RC uucp patches to me several times, but they don't want to do this. > >I agree about the patch BBS. Why is the SSB "infamous"? > Very simple, it's impossible to use in it's current format. Unless you have the time to read through the WHOLE thing. I'd love to get it on disc/tape so I could load it onto my system for scanning through. -- | R. Arthur Gentry AT&T Communications Kansas City, MO 64106 | | Email: attctc!kcdev!gentry ATTMail: attmail!kc4rtm!gentry | | The UNIX BBS: 816-221-0475 The Bedroom BBS: 816-637-4183 | | $include {std_disclaimer.h} "I will make a quess" - Spock - STIV |
garvey@cmic.UUCP (Joe Garvey) (12/01/89)
1) I'm a paying HPUX support customer.
2) I've been on support for years.
3) I didn't know what the hell I was doing when I started. (I believe I've
learned a little bit since then :-)).
4) I agree there are some things about support that really need to be
improved.
I've been dealing with the Western Response Center for years. I really
appreciate the great lengths they've gone to for me. The folks there
a really something special. When I've had problems with them, I can talk
to them and they jump... they really have a commitment to service. I don't
think any of the criticisms in this news group really apply to these folks.
I assume the other response centers behave similarly with their customers.
The mission of the response center is to service that large number of HP
support customers that fall into the category of "beginners". I myself feel
I'm in that never-never land between beginner and expert (yes, I occasionally
call with a simple/stupid/RTFM type question). I also call, and
stump-the-panel often enough that I feel handling these calls is a problem
deserving HP's attention.
Actually after discussing this with the folks at the response center, I feel
that the problem is they target the simple/RTFM questions. In addition, the
stump-the-panel questions take a tremendously disproportionate amount of
time to solve (equiv. to ~20 simple questions). Well, if a few of these
difficult questions show up, then the poor SE doesn't answer the other
questions. Given the choice of making one person happy, or making 20 people
happy which choice does the SE make? Service the 20. Get around to the
other question as best you can. It also makes it difficult to attract the
attention of a subject matter expert (as Dave Taylor so appropriately
designated this type of person).
After this much time, I've developed some tactics in self-defense
(self-offense). I learn/categorize each SE's skills. I learn their schedules.
I learn how to get to other response centers, where some other SE might
have the skills to solve-my-problem/answer-my-question. I know for example
one of the best individuals at solving uucp problems is taking classes
part time at Georgia Tech (working on a Masters Degree no-less). He often
covers the phones on weekends. Guess when I call with uucp problems?
Another SE who's in general very good, and especially good with disk problems
tends to work late Friday nights at the Western Response Center. Guess when I
call with disk related problems?
When I get a new SE, yes new ones do occasionally show up, they're usually
pretty green. I'll suggest if they can't answer a question to go ask another
SE, and I'll tell them who to ask! After a while, they learn to do this
themselves.
When all else has failed I escalate, but its emotionally painful for all
involved. When you escalate, you're effectively saying, "I don't think
you can solve this problem", I don't like putting people down by doing this,
but on the other hand, my boss insists I solve the problem *now*. What do you
do? Try to be tactful, but insist on getting others involved, or forcing
the problem to the local HP office. (No, I've never called J. Young... but
the sign above the computer directs complaints to him... clipping from
Business Week with his phone number is on the sign).
The gist of this is that, the experienced user gets short-changed in
response center support. This doesn't show up in surveys, because they
are a minority! But it does alienate some of HP's best assests. I value
the opinions of the experienced system operators that aren't HP (HP too,
but they're always suspect ;-)). But HP drives these people away. I value
a system more highly, the more experienced users there are... kinda like
having shepherds for the flock. They solve problems and fill in when HP
can't. They lend the system credibility... their presence, their use of
a system indicates it's viable and useful. It's a much better guide than
advertising. (It's one of Sun's best assets!)
Remember the discussion/postings about "Is HP a good system to develop on?".
That wouldn't happen if more "shepherds" posted here indicating all the great
and wonderful things they've been doing.
In order to help the Response Center help the experts, they've got to be
unburdened and allowed the time to tackle these difficult questions. The
mechanism for doing this is the net... but operating out of the response
center. Not the MPE idiocy they've got right now (yes, I have very strong
opinions about teaching unix users MPE. MPE for MPE users. Unix for Unix
users... especially when all the software has been developed and is
already running in the response centers! I've started to email my gripes/
questions to those at the response center. Yes, their already on the net).
I advocate changing Support Line so it provides news feeds, uucp service,
archives, etc for unix users. (I know Dave Taylor has suggested Interex...
and I've talked to Art Gentry there, but I still perceive Interex as
supporting MPE for unix. It's going to take some good will efforts on Interex's
part for unix users to change my mind on that subject.) Then the response
center is simply an extension of my mail system. They can run HP-only news
to their customers... I believe HP has real problems advertising to Sun
sales reps the problems with HPUX... but if it only went to HP customer sites,
and wasn't propagated beyond that... maybe HP wouldn't have a problem.
This would allow bugs to be posted, bug fixes to be circulated, HP to have
archives of unsupported/contributed software, and provide a slick marketing
tool too! (I wouldn't mind e-junk-mail from HP..., and from HP's point this
is a great way to get to the people that fill out the purchase req's for
more HP equipment!) It also means the 90%+ of the simple questions could
be answered by other users.... leaving the SE's free to be problem solvers!
Finally, I'd like to pass along a little story...
I'd reported bugs in the man pages (format, ability to include in whatis
database, etc) for years for products out of HP-LSD. I track the KPR's.
Eventually, I got a new product, ended up editing every man page, as usual,
and posted how upset I was this had gone on for so long. This got a fast
response. The problems were reproduced. I'm sure they'll be fixed by the
time a full release cycle has completed itself (~ 8-12 months). They had
never heard of the KPR's I'd been calling in!!!!
To add insult to injury... I was very politely told not to use the net as
a back door to solving these problems. AARGH!!! Wake UP! I'm not the
only one. The users are trying to implement what HP is reluctant to do
with the suggestions for comp.sys.hp.bugs, comp.os.hp.patches, etc. Why
does HP resist implementing a time proven system for handling questions,
problems, fixes.... the net has been doing this for years. It costs next
to nothing to implement (not like all the time and effort in writing MPE
software). At the very least, the postings from HP not to use the net as a
means of solving problems with HP ought to cease, and a formal mechanism
for accepting bugs this way should be put in place. The net is a large,
popular, productive tool. It's time HP acknowledges that fact.
HP has always succeeded because it innovates. It's time to innovate in
customer service.
--
Joe Garvey UUCP: {apple,backbone}!versatc!mips!cmic!garvey
California Microwave Internet: mips.com!cmic!garvey
990 Almanor Ave HP Desk: xxx ("mips!cmic!garvey")/hp1900/ux
Sunnyvale, Ca, 94086 800-831-3104 (outside CA)
408-720-6439 (let it ring) 800-824-7814 (inside CA)
Feel free to disagree, but disagree civilly.dgreen@squid.cs.ucla.edu (Dan R. Greening) (12/01/89)
In article <221@cmic.UUCP>, garvey@cmic.UUCP (Joe Garvey) writes: > Why does HP resist implementing a time proven system for handling questions, > problems, fixes.... the net has been doing this for years. It costs next > to nothing to implement ... > At the very least, the postings from HP not to use the net as a > means of solving problems with HP ought to cease, and a formal mechanism > for accepting bugs this way should be put in place. The net is a large, > popular, productive tool. It's time HP acknowledges that fact. > > HP has always succeeded because it innovates. It's time to innovate in > customer service. I can't agree more with this. USENET, uucp, and the internet, are major software distribution mechanisms for software. Just look at the flood of stuff in comp.sources.*, the 6-8 anonymous FTP sites I use all the time, etc. But on the other hand, at UCLA I don't even have convenient access to a dial-out phone. Therefore, it is quite bothersome for me to contact an S.E. in any other way than e-mail. UCLA's machines, like most other university machines, have all sorts of new software running. They are managed by graduate students. Yes, we often diagnose and report difficult problems. That should come as no surprise: we are on the frontlines. It seems like HP should encourage our help, and should provide what it can to support us, rather than admonishing us not to use convenient reporting mechanisms (USENET) or telling us HP cannot distribute patches via USENET because of so-called "legal" problems. Easy to dispel the so-called "legal" argument: a. If HP could be sued for distributing an incorrect patch via USENET, HP could be sued for distributing an incorrect patch via any other means. b. If HP *fails* to distribute patches to everyone via USENET or some other convenient mechanism, it DOES NOT satisfy the customer. Advanced customers (like UCLA) discover they can't run X11R3 on HPUX 6.5. What do they do? Either 1) give up and make students run X11R2. The students discover they can't compile their X11R3 stuff on the HP, so they use Suns or IBM RTs or SparcStations or whatever. Or 2) They decide that they are better off dealing with a more free-wheeling hardware company. Or 3) They get MtXinu Unix 4.3 and say "to heck with HPUX". Or 4) They scream about it in USENET. How can any of these help HP? They can't. c. To completely protect its legal butt, HP (or any company) should not sell software, or anything for that matter. If you feel like you have to sell software, sell something tried-and-true... like, say, FORTRAN. No patches. No mess. d. Any patch distributed on USENET could be accompanied by a disclaimer, as is found on all MIT sources, etc. I *like* HP equipment, by the way. It is extremely reliable. And HP people have treated me well. However, I do believe a fundamental policy change should go into effect: patches should be posted in "comp.sys.hp", customers should be encouraged to use USENET or some other e-mail mechanism to report bugs, HP revised sources of public domain software should be made available on anonymous FTP sites, there should be someone from customer service assigned to monitor and transcribe all bugs reported here. Any decent company must go where the customers live. And for advanced customers, like universities and major labs, the customers live on USENET. To ignore that fundamental fact is to lose market share. Dan Greening | NY 914-789-7861 | 12 Foster Court dgreen@cs.ucla.edu | CA 213-825-2266 | Croton-on-Hudson, NY 10520
taylor@limbo.Intuitive.Com (Dave Taylor) (12/01/89)
Doug McKenzie of HP's Pacific Technology Park site responded recently to my article in this newsgroup about the state of customer support in the computer industry, specifically that of HP. In his posting, Doug seems to have missed much of the gist of what I am talking about, and though I have since posted another article that clarifies my points (I hope!), I thought I'd delve into some of his comments anyway: > It seems what you're suggesting is that HP Support is terrible, [and] > the best in the business. That's exactly what I'm saying, though rather exaggerated a tad; I feel that the state of customer support in the Unix marketplace is far worse than it should be, and while HP is a front runner in the game, they too suffer from many of the same problems. What's worse, these problems are not only visible internally, but are just as bad for 'real' customers, people that are paying $$/month to have HP help them along. HP is doing a good job. They've got a very talented crew of people on board, many of whom I am priviliged to consider my friends and professional colleagues, but they're not "done"; there's lots and lots of room for improvement... > You found "hundreds of bugs", "NONE of them were ever resolved"? Are you > serious? With this 0% fix rate, I suppose your inescapable conclusion is > that no bugs ever found in HP-UX by anyone, are ever fixed. I can recall being in situations where I literally would spit out a couple of bug reports a day for a few weeks, when I was doing what I describe as "hitting the edge" of the operating system. I cannot recall, however, ever successfully having had ANY of them resolved. Further, I can only surmise that I wasn't being singled out for the "don't resolve" treatment, and if that's the case, well, then there are a whole lot of defects and enhancements that have never quite made it into the product or been otherwise resolved. And of course, my "inescapable conclusion" is simply that for me, the ratio of submitted to resolved bugs was quite low, and if I take into account the *time delays* between submission and hearing any response at all, well, then it gets very close to 0. I can recall in particular a bug I submitted against the TCP/IP sockets implementation on HP-UX 5.2 (I think) on an early 300 series machine. With the aid of a few other engineers we resolved that when opened using "fdopen" to have two streams, one for reading and one for writing, the file I/O stream buffer size and the TCP/IP window size conflicted so that I would get garbage if I were trying to push lots of information through quickly. We pinned that baby down to the size of the buffers, had a nice small sample program that demonstrated the problem, AND figured out a workaround (using the setvbuf() command, if I recall correctly). I can well recall that it was almost two months before I heard back from the Fort Collins Networking group, with the response that "it didn't fail on our machine, sorry." That was it. I called up some friends at the division and asked them to look into it further, sent them copies of the bug report, and lo and behold, suddenly one of the remembered that it was indeed a defect that they were aware of, and indeed they had a well known workaround to do with setting the stream vbuf to a specific size 2x the size of the TCP/IP buffer (or something like that). I then responded to the response to my bug report with further information including some further thoughts and hints on what might really be wrong, and about three or four months later, after the next rev of the operating system was released, I received another summary note stating "report closed: fixed by new release of operating system". That is not necessarily typical of the type of interaction one ends up having to get defects resolved, but on the other hand, just like with fleas in the carpet, when you hear about one, you can bet that there are twenty more hiding... And that is *not* what I'd call adequate and proper support. Whether internal or external, that's not the way to polish and produce the best possible product line for the happiest customers. > .. Customers hate it when a release is delayed, just as they hate it > when they find bugs. It's a matter of balancing timing with the > criticalness of the bug. Not really. It's a matter of viewing the whole thing as an "all or nothing" sort of game; what if HP implemented some sort of nifty useful binary patch utility and then sent out "incremental patches" to known and reported bugs? I mean, with the delays in the way the company (and other companies in the industry, to be fair) plans its OS releases years in advance, it's quite possible that a bug reported against the current HP-UX 6.5 release would not only not be fixed by 7.0 (since it's shipping already) and 8.0 due to timing, but it might not make it into 9.0 either since that'd be approximately TWO YEARS after the bug was reported and might be summarily resolved as "obsolete". That's a long time for a customer to wait... > I think your innuendo is that the bug "owner" is lazy, and this is > VERY UNTRUE, in my experience. I don't think this is the case at all, Doug. I think that *the system* is set up so that there is no motivation other than negative reinforcement (e.g. "too many outstanding bugs and you're in trouble") for programmers to become craftsfolk, and to ensure that the code they're responsible for is as free of bugs, defects, and problems as humanly possible. Just like with system administration, it's a negative feedback job. Further, no-one gets brownie points for having bug free code, but people DO get brownie points for having lots of bugs that they can resolve quickly. It's like some sort of Orwellian Pavlovian experiment or something... just like the problems with superficial application of code metrics; people learned to write statements that filled multiple lines, and learned to have more meaningless comments to improve their code "ratings"... [I can feel in my bones that I'm skirting a fairly heavy psychological, cultural, and sociological issue here --- sorta like Robert Persig -- but I shall try to refrain from preaching...] > Why is the SSB "infamous"? The SSB is infamous because it's lots of useful and vital information in a format that is almost completely unusable, and certainly one that does not encourage casual browsing by interested software professionals and others that might well want to know what's contained therein. Plus it doesn't come out frequently enough... - - - Anyway...this is becoming a most interesting discussion here in this newsgroup, and I hope that within HP (and perhaps with the support organizations of a few other big companies) they're further discussing what's going on here... I would be delighted if we could get some people from some of the support organizations involved too. Posting some statistics would be great information for us to chew on, like number of HP9000-related reports received weekly, breakdown of internal vs. external, average time to resolve, number and percentage still outstanding, longest outstanding and why, and so on... Unfortunately that's all company confidential. Which means that we might well all be blowing hot air and not actually destined to "get" anywhere with this conversation. Ah well. C'est la vie. From the edges of reality, -- Dave Taylor Intuitive Systems Mountain View, California taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor
gerwitz@hpcore.Kodak.Com (Paul Gerwitz) (12/01/89)
In article <221@cmic.UUCP>, garvey@cmic.UUCP (Joe Garvey) writes: > > 1) I'm a paying HPUX support customer. > 2) I've been on support for years. > 3) I didn't know what the hell I was doing when I started. (I believe I've > learned a little bit since then :-)). > 4) I agree there are some things about support that really need to be > improved. > > Feel free to disagree, but disagree civilly. I must commend Joe for his thoughtful post. I have been one of the prime support people in my company for 9 years now, working on HP/1000 and HP/9000 platforms and have had a similar experience with HP as far as customer service. I must say the HP has improved dramatically over that time. I remember before the days of the response center, how difficult it was to get experienced SE's to solve those real trick problems for me. I am part of a small group who answers all those 'beginner' question so when I call PICS, I expect someone who knows what they are doing, and how to get my difficult probblems solved. In general, I'm pleased with the Response Center and it's people. But I find HP's lack of recognition of their customer base to be very troubling. Also in my group we have a larger collection of people supporting rival systems. So I am put into the position of not only defending HP and it"s products, but also the ability to convince my customers that HP is worth investing their projects in. IMHO, HP has one of the most loyal customer segments in the industry. Not only that, but we really know what we want from HP. If I was making the decisions (don't we all wish we could :-) ) I would be spending as much time, money and effort in building up those relationships with existing customers by getting their input, making them part of the process to solve problems, spreading information in any way possible (usenet, Internet Mail lists, small customer study groups etc.) We are setting up a local mail connect to out local office to get away from playing telephone tag with my sales rep and SE. All I had to do was ask. Come On, HP,............. What If......... The customer is really the most important part of your business ?? [The opinions expressed are my own, and may not reflect those of my employer, but wouldn't it be nice if they did ] +----------------------------------------------------------------------------+ | Paul F Gerwitz WA2WPI | SMTP: gerwitz@kodak.com | | Eastman Kodak Co | UUCP: ..rutgers!rochester!kodak!eastman!gerwitz | +----------------------------------------------------------------------------+
nick@bischeops.UUCP (Nick Bender) (12/01/89)
In article <221@cmic.UUCP>, garvey@cmic.UUCP (Joe Garvey) writes: > > The gist of this is that, the experienced user gets short-changed in > response center support. This doesn't show up in surveys, because they > are a minority! But it does alienate some of HP's best assests. I value > the opinions of the experienced system operators that aren't HP (HP too, > but they're always suspect ;-)). But HP drives these people away. I value > a system more highly, the more experienced users there are... kinda like > having shepherds for the flock. They solve problems and fill in when HP > can't. They lend the system credibility... their presence, their use of > a system indicates it's viable and useful. It's a much better guide than > advertising. (It's one of Sun's best assets!) I very much agree with this. Several times over the last year of using HPUX I have stumbled across things that make me want to ask "is anyone *really* using this stuff?" One example is the ommision of <sys/wait.h> which was "inadvertently left off the HP-UX 6.2 release." This does *not* give me a warm fuzzy fealing. > to their customers... I believe HP has real problems advertising to Sun > sales reps the problems with HPUX... but if it only went to HP customer sites, > and wasn't propagated beyond that... maybe HP wouldn't have a problem. Hiding problems from users is not a win for anyone. Every time I discover a bug in HPUX it has probably taken me at least a day to isolate it and make sure that it is HP's problem and not mine. How many times is this repeated at other HP sites? > This would allow bugs to be posted, bug fixes to be circulated, HP to have > archives of unsupported/contributed software, and provide a slick marketing > tool too! (I wouldn't mind e-junk-mail from HP..., and from HP's point this > is a great way to get to the people that fill out the purchase req's for > more HP equipment!) It also means the 90%+ of the simple questions could > be answered by other users.... leaving the SE's free to be problem solvers! This, IMHO, would be a huge win for HP. If such a system were in place I would read it. Every day. And I would participate, lending my expertise when appropriate. Here I am offering my services to HP free of charge. All I ask in return is an HPm supported forum for doing it. Somone at HP mentioned liability problems for distributing patches (sorry no reference). Is this really any different from the initial liability if a bug causes a problem in already running code? Don't you think people are going to check to see if your bug-fix actually fixes the bug? This argument holds no water for me, but then again I'm not a lawyer. I have used the current support system. I think this MPE stuff *sucks*. It's slow and alien and reminds me of mainframes and IBM. BLECH! Several times I have *faxed* code to the support center. HP sent me a *tape* with <sys/wait.h> on it. Come on people, UUCP is what, 10-15 years old now? > HP has always succeeded because it innovates. It's time to innovate in > customer service. Innovation? Sun has been on the net for years. HP is still playing catch up in this market. > Joe Garvey UUCP: {apple,backbone}!versatc!mips!cmic!garvey > Nick Bender ...!uunet!bischeops!nick nick%bischeops@uunet.uu.net
cunniff@hpfcso.HP.COM (Ross Cunniff) (12/02/89)
I'm just a compiler hacker, but off the top of my head I can
think of several reasons why distributing patches via USENET
is a bad idea:
1. The other companies who help pay for USENET would
not be happy to find that they're paying for HP
software distribution
2. There is no way to ensure that a patch actually
came from HP; this seems like an incredibly obvious
way for someone to distribute a trojan horse
3. It is possible (nay, probable) that patches could
become corrupt during transmission; witness the
number of requests for reposts of part N of the
latest neat comp.sources.thing.
You'll notice that none of IBM, DEC, Sun, Apple, or HP distribute
software via the net. I'll bet the above reasons are a partial
explanation.
Now, I don't disagree at all that it might be appropriate for HP
to figure out some sort of online notification about software
patches; I've heard rumors (RUMORS, mind you) that something like
that is in the works.
Ross Cunniff
Hewlett-Packard Colorado Language Lab
...{ucbvax,hplabs}!hpfcla!cunniff
cunniff%hpfcrt@hplabs.HP.COM
DISCLAIMER: HP pays me to write compilers, not to post opinions like
this to the net.defaria@hpcladb.HP.COM (Andy DeFaria) (12/02/89)
>The primary reason why HP and other companies don't post patches to a >public forum like USENET is because of liability. > >This is not a cheap excuse. It is a fact of the business world. In >contrast to say, most of Apple's customers, HP customers tend to be >large institutions or companies with a legal department and alot of >money. If HP distributes a patch BEFORE it has been rigorously tested, >and the end user uses the patch in a critical production situation, and >the patch fails to fix the problem, there are many people out there >with the financial clout to sue the company that WILL. Even if they >don't win, it ends up costing HP alot of money, time, and headache. If >they do win, it could mean the end of HP. Bull! Ours software/patches is distributed with the infamous "use it at your own risk" warrantee. Therefore nobody in their right mind would have cause to sue HP. People outside of their right mind would surely not have a case and HP should be able to recoup any expenses in counter suit (and dare I say: maybe make some money). Any counter suit that failed because of plaintiff bankruptcy wouldn't break HP! I do agree more with your position of support and control, however customers in the know, who are willing to forego the support and take the risk are being told NO by HP and going elsewhere. I think with enough warnings (sort of like we warn our commerical customers on MPE about using priveledge mode), posting patches could improve HP's image in the technical market place as being one of the most "state-of-the-art" vendors. (Of course these are my own opinions - How could I honestly state anyones else's without being in politics ;-) Andrew DeFaria
kean@nyssa.CS.ORST.EDU (Kean Stump) (12/02/89)
It's worthy to note that Sun contracted a while back with uunet for
anonymous ftp services; Sun places patched binaries (like sendmail,
finger, ftpd etc) on uunet.uu.net for anonymous ftp.
kean
Kean Stump, College of Oceanography Domain: kean@{cs,oce}.orst.edu
Oregon State University, Corvallis OR 97331-5503 UUCP : tektronix!orstcs!kean
****OSU knows nothing about my opinions. Absolutely nothing. So, don't ask.****
Diplomacy : The art of saying "nice doggy", until you can find a big rock.saj@chinet.chi.il.us (Stephen Jacobs) (12/03/89)
I'm using my second HP computerized analytical instrument. This one is a
top-of-the-line gas chromatograph/mass spectrometer controlled by an A series
box, and running RTE/A with both FMGR and CI (wotta mouthful). Software for
this system can uncharitably be considered one gigantic bug (and operation
a gigantic workaround). Support people are uniformly courteous and energetic;
since the system is a bit .... odd, they aren't necessarily all that well-
informed (particularly when the guy we need is on vacation, or some such).
Still, we have printer drivers that work badly or not at all YEARS after the
bug reports went in, procedures that should be automatable with (what I call)
command files querying the terminal for what should be command line arguments,
and numerous reproducible situations that hang various programs 'Acknowledged
as problems'. Aside from making all those workstations and departmental
computers, HP makes an awful lot of automated test equipment. And the
traditional attitude that the computer division doesn't support the the
instrument division still seems to be around (not universal anymore, but there).
Basically, I get the impression that if the most frequent operations run
by most of the customers work ok, further development isn't considered
necessary.
Steve J.burzio@mmlai.UUCP (Tony Burzio) (12/05/89)
In article <1320019@hp-ptp.HP.COM>, mck@hp-ptp.HP.COM (Doug_McKenzie) writes: > If a company puts out > terrible documentation, more calls will be received asking simple how-to > questions. There is one place in the HP manuals that needs to be thrown out and totally replaced: The UUCP Manuals. The main examples in the manual deal with connecting two local HPs with RS-232 connections. Now this is strange, since every HP comes with a built-in Ethernet card! Why can't we get a clear example of how to connect via a Telebit Trailblazer modem to uunet? (the modem of choice for uunet, they suggest you use one) Perhaps (gasp!) how to send and receive mail? :-):-) We are using a 2400 baud modem connection off an old uVAXII running ULTRIX. I have tried to get our 835 to connect to uunet, but I always get to the point in the manual where it says if it's still broke, call an HP SE... (quite funny really:-) ********************************************************************* Tony Burzio * 486 MS-DOS machines will triumph in the Martin Marietta Labs * end! (Gak!) mmlai!burzio@uunet.uu.net * *********************************************************************
kah@hpfcso.HP.COM (Kathy Harris) (12/05/89)
>I can recall in particular a bug I submitted against the TCP/IP >sockets implementation on HP-UX 5.2 (I think) on an early 300 series >machine. With the aid of a few other engineers we resolved that when >opened using "fdopen" to have two streams, one for reading and one >for writing, the file I/O stream buffer size and the TCP/IP window >size conflicted so that I would get garbage if I were trying to >push lots of information through quickly. We pinned that baby down >to the size of the buffers, had a nice small sample program that >demonstrated the problem, AND figured out a workaround (using the >setvbuf() command, if I recall correctly). I can well recall that >it was almost two months before I heard back from the Fort Collins >Networking group, with the response that "it didn't fail on our >machine, sorry." That was it. Well, I'm sorry Dave but your info or memory about bugs not getting resolved is just not correct, at least in this case. This one was handed to the person in charge of stdio. It was resolved with the following info: Stdio does not support two open streams connected to the same underlying file descriptor. The correct way to set up code like this is to dup(2) the file descriptor, and then do an 'fdopen' on each descriptor. The networking group made this change and the code then worked fine. Maybe you didn't submit the bug report, but instead someone else did, so the resolution info went back to them instead of you. Kathy Harris Colorado Language Labs Ft. Collins, Co.
frank@hpuamsa.UUCP (Frank Slootweg CRC) (12/05/89)
This discussion is sliding down hill somewhat (on both sides :-)).
This is perhaps caused by the delay in transmission, reading and posting.
Anyway I would like to summarize a little :
- How support of internal users is handled should not be discussed in
this forum.
Anyway, as already said by multiple HP people :
- Most internal *users* are not (internal) *customers*.
- Most internal *customers* "pay" only in accounting money and even
that at reduced rates.
- Internal support for *partners* (f.e. other divisions that develop
software for HP-UX platforms) and project *members* (internal test
sites, etc.). *is* setup differently. *This* is the only area that
impacts the software quality at customer release. Again IMO this
should not be discussed in a public forum unless there is a valid
reason to do so *and* other non-company-private approaches have
failed.
- On-line bug/patch info *is* available to customers (HP SupportLine).
However currently most (HP-UX) customers still prefer to let the
Response Center do the searching.
- Patches *are* available (through the Response Center) between major
releases. This mechanism was set up at the *same* moment we reduced
the frequency of releases (on request from our customers!).
Bottom line:
Some customers want access to bug/patch info (and perhaps to the
patches themselves) in other ways than currently offered (by HP and
other suppliers of comparable systems).
These customers should :
- Indicate what they want.
- Indicate how they want it (*without* creating a liability and/or
exposure problem for HP (see Dave Waller's and my previous response).
- (Probably) Coordinate their information through INTEREX.
*If* the solution was as simple as implied by some posters ("Just set
up a Usenet feed!") *and* had no adverse consequences then HP (and its
competitors :-)) would already have such a mechanism in place. It is
often difficult for technical people like "you and me" to determine the
viability of a proposed solution in the *real* world (i.e. business,
money, lawyers, etc.).
From the world of customer support,
Frank Slootweg, Dutch Customer Response Center.
Disclaimer: Speaking only for myself, not my company. Don't sue me, I'm Dutch.frank@hpuamsa.UUCP (Frank Slootweg CRC) (12/06/89)
Again some observations : - The original poster (Joe Carvey) suggests to use the net for questions from new users. This is fine but *most* of our customers are *not* connected to Usenet. They only have single systems or a LAN without any outside connections (a.o. (but not only) for *business* security reasons). So this covers only a small part of the customer base. Since the poster at the same time (rightfully) "complains" about the quality of support to "expert customers", i.e. another minority :-), there are apparently *multiple* customer profiles each of which needs a *different* support approach. So all "One size fits all" recommendations by both customers *and* HP are bound to fail in real life. - Dan Greening talks about Usenet and mentions e-mail and "comp.sys.hp.bugs" (or some such), i.e. News. *E-mail* is fine (even on Usenet) because it is (reasonably) private. We use it all the time with customers that do have it (see above). *News* (or *Notes*) is something else! It is not at all private (see below). - Multiple posters imply that other *companies* are using News (or similar) for bug/patch info and even the patches themselves. They fail to give examples. To the best of my knowledge no other company does this (I *do* know about "comp.bugs.sys5" and "comp.bugs.4bsd", etc. but those are *not* run/sponsored/moderated/etc by *companies* (and probably not even by Berkeley)). See also my similar remarks in the other "HP Support ..." string. So again, please address the issues also from a business/real_world standpoint (i.e. not only from a technical standpoint. We already know that technically it can be done (since it is done for Public Domain stuff)) and give input that can be used by HP to improve the current support offerings. From the land of customer support, Frank Slootweg, Hewlett-Packard, Dutch Customer Response Center. Disclaimer: Only speaking for myself, not my employer.
taylor@limbo.Intuitive.Com (Dave Taylor) (12/06/89)
Frank Slootweg of HP <frank@hpuamsa.HP.COM> summarizes the discussion we're having with the following points: > How support of internal users is handled should not be discussed in > this forum. Agreed, unless it has an impact on the quality of support that external customers can expect to enjoy; e.g. when HP engineers respond to bug reports or other defects, their answers should be similar for internal and external customers. > - Most internal *users* are not (internal) *customers*. > - Most internal *customers* "pay" only in accounting money and even > that at reduced rates. The thing that bothers me about this, though I can understand and accept the reality of the situation, is that HP should have a driving desire to make their products as absolutely high quality as possible. If that's there, then feedback of any nature from anyone, internal or external, would be invaluable and cause for immediate modification to the application to reflect the solution to the reported problems. With this distinction between real and 'fake' money, it seems to point to this not being present, which means that HP isn't that committed to the quality of their product line (if they were, then feedback is feedback, and thanks for submitting it!) which is then definitely a topic worth much discussion. What's worse is that internal customers are much more likely to know the OS and applications inside out AND are also much more likely to have a first chance at finding and reporting problems in the operating system. I surmise that many of the problems reported by people inside HP and then "ignored" were then again stumbled across by external customers and THEN resolved. That's not a great way to achieve perfect Zen Quality, is it? From my own experience, I know that I was much more likely than an external customer to spend the time and effort to track down and isolate the problem to a specific piece of the operating system or application (sometimes through access to the OS source, even) and then manage to report very specific bugs with workarounds and even occasionally solutions. That's a lot of information to be deprioritized because internal people don't rank quite as high on the scale of defect reporting importance, somehow. > - Internal support for *partners* (f.e. other divisions that develop > software for HP-UX platforms) and project *members* (internal test > sites, etc.). *is* setup differently. *This* is the only area that > impacts the software quality at customer release. Again IMO this > should not be discussed in a public forum unless there is a valid > reason to do so *and* other non-company-private approaches have > failed. Again, I conceed that discussion of this nature should probably be best kept internal to HP, but on the other hand, if customers continue to run into defects that have already been found, isolated, and reported internally (perhaps not by explicit beta test sites) but not resolved, then it is appropriate to be discussed here. In this particular instance we must balance the needs of HP internal security with the importance of the customers having a balanced and honest appraisal of what the process really is. At the same time, so as not to confuse the issue, I am not by any means advocating that HP make available defect reports against unreleased software (e.g. alpha or beta releases). On the other hand, if there are reported defects against a test release that continue to be true of the final release product, then maybe it would be appropriate to release the defect reports simultaneous with the product itself. In BSD Unix terms, this was what was known as the BUGS section in the man page... >- On-line bug/patch info *is* available to customers (HP SupportLine). > However currently most (HP-UX) customers still prefer to let the > Response Center do the searching. This is counter to the information I have, Frank: As of a few weeks ago, HP SupportLine was not yet available for HP-UX customers. In any case, I don't find that having to call up and go through the SupportLine BBS via 1200 or 2400 baud modem is an aggressive and appropriate technological solution to the problem we're talking about here. As someone else pointed out, UUCP has been around for 10-15 years by now, so why can't we utilize that, for example? [possible scenario: HP sets up a bank of 800 numbers for their customers, each being assigned a specific UUCP account & password. On a daily basis, each customer site then calls in and uploads all the latest defect and enhancement reports, as well as any new press releases, PR announcements, and any other information that can be easily and usefully disseminated this way. Advantages include: the customer has the information locally and has access to the familiar Unix tools to search and disseminate it, as well as the ability to even perhaps make a local netnews group for the info. Cost is minimal; a couple of strategically placed 350's with banks of 800 line modems could easily service most of the US at least. Down side: security, administration and resistance to change. Initial target customer: universities, and "leading edge" firms ] >- Patches *are* available (through the Response Center) between major > releases. This mechanism was set up at the *same* moment we reduced > the frequency of releases (on request from our customers!). Right, but the information dissemination problem is one of the main things we're talking about here; how do we, as customers, know about the patches and workarounds? Reading the SSBs is not a viable solution, calling our SE's weekly isn't a viable solution, and using HP SupportLine isn't viable either since it's not even an announced element of HP-UX support strategy yet. The problem here is that HP is being, as Tom Peters might put it, reactive, rather than "proactive" on these problems. That's exactly what is being pointed to when we see things like patches that you have to call and explicitly request, meaning you've already had to hit the problem and spend the time needed to ascertain that it's an OS problem, not an end user application problem. And that's just not a good solution. >- Indicate how they want it (*without* creating a liability and/or > exposure problem for HP (see Dave Waller's and my previous response). Liability is no different if the patch is posted versus mailed on a magnetic tape (with the caveats about spoofed news articles and the limitations of commercial use of Usenet: see my suggested solution above that solves both of those problems) Besides, if there is a greater liablity problem, then why don't we have a discussion about that too? Can we get some HP laywers to talk about the legal ramifications of the current patch strategy and how that would be impacted if we were to go to an online format? How does HP SupportLine avoid this increased liability? >- (Probably) Coordinate their information through INTEREX. Agreed, except INTEREX is not a sufficiently aggressive organization to manage such dramatic change; they're having enough of a challenge just trying to meet the needs of the basic HP-UX customer, let alone the needs of those further out on the edge, like what we're talking about in this discussion. Also, if this is an alternative support strategy, HP should be sponsoring it, not a third party organization. I mean, I don't call APDA to find out about bugs in the Macintosh OS, I call Apple. In a similar way, I want to know that HP is managing and maintaining any new support strategy or scheme that comes along, and that HP is committed to making it a success. (look at the problems with contrib tapes for HP-UX to see what I'm talking about...) To summarize what I'm trying to say: HP support strategy is currently reactive rather than proactive, oriented around finding problems that others have probably encountered, then spending the time to isolate it, call your SE (or field support) then receive the patch or workaround. As HP-UX and the Unix system itself gains in complexity it seems obvious that this approach is going to become harder and harder to deal with successfully. The proposed solution is simply for HP to acknowledge that this is a valid concern and to start working with their customers in public forums like comp.sys.hp to create a new and forward-thinking support mechanism for the 1990's. I think it's great that we're able to have this discussion here on the net, and I hope that those of you that are just reading this all are agreeing with one side or the other (and if you don't agree, add your viewpoint!). The computer industry has always been split by factions clamouring about the latest of new technology versus those who appreciate the slower planned and measured change of cautious evolution, and I think that this discussion is a fine example of that divergence of viewpoint. Still near the fire, at least, -- Dave Taylor Intuitive Systems Mountain View, California taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor
rer@hpfcdc.HP.COM (Rob Robason) (12/06/89)
> I very much agree with this. Several times over the last year of using > HPUX I have stumbled across things that make me want to ask "is anyone > *really* using this stuff?" One example is the ommision of <sys/wait.h> > which was "inadvertently left off the HP-UX 6.2 release." This does > *not* give me a warm fuzzy fealing. I'm not sure it will make you feel any better, but the omission of wait.h was not "inadvertent", but deliberate. I won't defend that, since I didn't understand it, but wait.h had never been shipped on the 300 before 6.2 either. It wasn't an oversight. It's possible that because we didn't have job control and waitpid() back then, it was felt it wasn't needed. Anyway, it's there now, just as deliberately as it was absent before. > Nick Bender Rob Robason
frank@hpuamsa.UUCP (Frank Slootweg CRC) (12/06/89)
Dave (Taylor) and *others*, I think we are getting somewhat closer to the right approach. As I indicated before UNIX/HP-UX customers generally want something else then HP SupportLine can currently offer. I basically agree with your proposal : >[possible scenario: HP sets up a bank of 800 numbers for their > customers, each being assigned a specific UUCP account & password. However we *also* need solutions for non-US customers, Internet users, etc. This is a complex and hence expensive matter. That does not mean that it should not be done, it just means that is should be well thought out, both from a technical and a financial/business standpoint (see later). >>- Patches *are* available (through the Response Center) between major >> releases. This mechanism was set up at the *same* moment we reduced >> the frequency of releases (on request from our customers!). > >Right, but the information dissemination problem is one of the main >things we're talking about here; how do we, as customers, know about >the patches and workarounds? Reading the SSBs is not a viable >solution, calling our SE's weekly isn't a viable solution, and >using HP SupportLine isn't viable either since it's not even an >announced element of HP-UX support strategy yet. Again, our current indication is that *most* customers do not want to get bug/patch information and associated patches for "all the problems they don't have". They do want HP to help them solve the problems they *do* have. This does not mean that we should not listen to the "minority" that does want the info/patches but we should get some grip on the number of customers that want this, how they want it, etc (see my earlier postings). This info *has* to be channeled to HP in a structured way (that is why I proposed Interex). A few people expressing their wishes or "demands" in a mainly technical *public* forum like "comp.sys.hp" is not going to do the trick. The audience in this forum on both sides are mainly technical people. Responses from HP are mainly one engineer trying to help out another (not a *supplier* helping a *customer*). Most of the HP posters do *not* have direct (note "direct") customer support as their job (I am the exception in this string). If you don't like *that*, then you should try to change it, but again in a structured way. I will do my best on the HP side to try to let people pay attention to what is being said in this forum. You and other customers should combine forces and express your concerns to HP in a structured way. It can only be done *together*. >The problem here is that HP is being, as Tom Peters might put it, reactive, >rather than "proactive" on these problems. I am the first to admit that a company can never be proactive enough. However you should also realize that HP's support products have generally been leading edge in our main markets (both technical and adminstrative applications, however mainly in companies and company-like institutes, less in universities etc.). The latest examples in this area are the various CD-ROM based support products. > That's exactly what is being >pointed to when we see things like patches that you have to call and >explicitly request, meaning you've already had to hit the problem and >spend the time needed to ascertain that it's an OS problem, not an end >user application problem. And that's just not a good solution. Again, this is *not* our experience. At least not in The Netherlands, even not, generally, for universities and other leading edge users. In any case you will have to determine if it is an OS problem or a user application problem *when* you encounter the problem. Being proactive can shorten this troubleshooting process but can not eliminate it. If you want to be proactive then, as said before, you have to "wade" every time through all the bugs (most of which you will probably never encounter). Most customers don't want this hassle (the principle is called "Return On Investment" (i.e. "How much time must I spend repetively to save some time when I have a problem?")). The customers that do want this proactive bug/patch info and patches should speak up in a structured way. >>- Indicate how they want it (*without* creating a liability and/or >> exposure problem for HP (see Dave Waller's and my previous response). > >Liability is no different if the patch is posted versus mailed on >a magnetic tape (with the caveats about spoofed news articles and >the limitations of commercial use of Usenet: see my suggested >solution above that solves both of those problems) *I* am not so concerned about liabilty. Every company, so also HP, is concerned about (negative) exposure, that is what I meant. Perhaps exposure is not the right English term. What I mean is that we do not want everybody (i.e. also non-customers, competitors, etc.) to have detailed information on the bugs in our products. We are not alone in this standpoint, our competitors have the same, it is just common business-sense. Note that we use the word "defect" instead of "bug" (both internally and in our documentation/communication to the customer). "Bug" has a too nice ring to it. Your car does not have a "bug", it just does not work, it is defective. Summary : - We are making some progress in reaching concensus in this forum. - What is needed next is - More volume (i.e. customers sharing the same needs). - A detailed technical and business proposal that satifies the needs of most of this customers). - A structured way of expressing these needs to HP management (R&D, sales, marketing, support, etc.). From the world of customer support, Frank Slootweg, Hewlett-Packard, Dutch Customer Response Center. Disclaimer: Only speaking for myself, not my employer. P.S. Give Dave and me a break. Let's here some more from other customers and HP employees (especially in support).
bill@iccdev.UUCP (Bill Gaines) (12/06/89)
burzio@mmlai.UUCP (Tony Burzio) writes: >There is one place in the HP manuals that needs to be thrown out >and totally replaced: The UUCP Manuals. The main examples in the >manual deal with connecting two local HPs with RS-232 connections. >Now this is strange, since every HP comes with a built-in Ethernet >card! Why can't we get a clear example of how to connect via a >Telebit Trailblazer modem to uunet? (the modem of choice for uunet, >they suggest you use one) Perhaps (gasp!) how to send and >receive mail? :-):-) We are using a 2400 baud modem connection >off an old uVAXII running ULTRIX. I have tried to get our 835 to >connect to uunet, but I always get to the point in the manual where >it says if it's still broke, call an HP SE... (quite funny really:-) Once when I called the response center about one of my numerous UUCP problems, I was told by the PICS person that "We don't really feel that UUCP should be a part of UNIX. Therefore, HP doesn't provide much support for UUCP problems." I haven't called back with a UUCP problem since then. By the way, HP-UX 7.0 will finally officially support the Telebit Trailblazer modem. In the past, when I have called the response center, I have been told "We have never heard of Telebit modems". -- Bill Gaines (...!gatech!iccdev!bill)
nlouie@hamilton.Berkeley.EDU (Nancy Louie) (12/07/89)
In article <1320019@hp-ptp.HP.COM> mck@hp-ptp.HP.COM (Doug_McKenzie) writes: >Dave, what are you saying? It seems what you're suggesting is that HP >Support is terrible, the best in the business. It's like after insulting >and accusing HP of almost malicious negligence, you feel apologetic?!? > Come on, Doug. That's not what he's saying at all. If you think about *what* he's saying, rather than how he's saying it, you'll see that he is making general statements about support organizations as a whole, and, since this is an HP related newsgroup, he's citing examples from his experiences with HP. >You found "hundreds of bugs", "NONE of them were ever resolved"? Are you >serious? With this 0% fix rate, I suppose your inescapable conclusion is >that no bugs ever found in HP-UX by anyone, are ever fixed. One person's submissions do not the whole encompass. I myself submitted a good number of bugs while at HP. Some of which were fixed fairly soon, and some which took over a year to get a first response. One in particular came back with a "cannot reproduce" type of message, and I went over to the machine and the problem was still there. > >I don't deny that bugs have been reported, and not fixed. Most of these >have to do with being found too late to make it into the "frozen" release. . . > It's a matter of balancing timing with >the criticalness of the bug. > Do you really think this is true? From my experience, it's not really the case. There were times when we would find bugs during field review that would not get fixed, and there were definitely bugs which I had submitted as serious, that I never even heard back from by the time I left the company. It's true that low priority bugs which are submitted just before a code freeze will most likely *not* make it into the release, but at the same time, the amount of time needed to fix the bug should also be taken into consideration. If a bug fix consists of changing one line of code, and the engineer is reasonably sure that it wouldn't affect the release and make the test suites fail, don't you think that it would be reasonable to try to get that fix into the release? >I wouldn't even deny that some bug fixes fail to make it into subsequent >releases. Nobody's perfect, some bugs fall through holes. I do deny that >it's common, much less "almost traditional ... [that] it would just vanish". If these are, indeed, the reasons, then don't you think it reasonable that the submitter get a message stating this? In these cases, they don't get anything back. I was one of those people whose bug reports sometimes fell into the black hole ... >Maybe so. Care to name a few (bugs, not friends :-)? fingerd -- fingering a user on the system would return a message stating that the user was not logged in. talkd -- inappropriate messages trying to establish connection, failure to establish connection to user. >Well, once again I can't deny that this ever happens, but I don't know of >any times that it has. I do. I supported one of those customers. The lab took a while to finally respond and when I left, it still wasn't resolved -- after 3 months.
nlouie@hamilton.Berkeley.EDU (Nancy Louie) (12/07/89)
As Dave and Frank have discussed in this newsgroup, HP is indeed rated as one of the top companies in the support area. Having once worked in the factory support group at HP, I can see both people raising very good points. HP has some very good people trying very hard to do good work. I think that part of the issue here is not just the dissemination of information, but the manner in which it is disseminated. For instance, Dave brought up the point that customers who run into problems will only get patches from those SE's who know about the patches and who actually *ask* specifically for the patch. He alluded to the fact that the SE's should be more informed of the patches available &c. Well, as a former member of the Hewlett-Packard General Systems Division Series 9000/800 (Spectrum) On-Line Support group, I can only speak for the 800 side, but in the group I was in, we tried very hard to keep the field informed of new patches, known bugs, and other things of a similar nature. Unfortunately, it's not just a matter of informing the field. So many of them are so busy trying to support multiple product lines and getting new information on each, that they often do not have time to keep up with the influx of information. (This is probably true of many support organizations). The question to ask here is how can HP (and other companies) provide information to the field and customers in a timely, yet efficient manner? One suggestion is to make the information available on the net. Personally, I think one of the best solutions is to make the information available on CD-ROM and have the information go out on a set schedule. As Dave pointed out, if the information is readily available and easy to search through, it will most likely lead to reduced numbers of calls to the support group. It would also imply that the majority of the calls that did come in afterward would be more difficult and technically indepth. Even in factory support, our group received calls from the field asking simple "read the manual" questions. One call that I got from the field was someone asking how to use the foreground and background utilities. I directed them to the manual pages for csh and closed the call letting them know that if they still had problems after reading it, we'd be happy to assist. At any level of support, the groups are going to get the "how to" type of question. While novice users may call and ask, "How do I do ____ ?" and expect some reasonable support to answer their question, the response, "Well, on page ___ of manual X, it describes exactly what you need. Why don't you look through that and call us back if you're still confused." should be considered a reasonable answer. There are only a limited number of people trying to answer all the calls that come in, and hand-holding tends to take lower priority because of the nature of the questions and the "easy solution" (i.e., RTM). Any company can expect to see a number of duplicate calls to their support groups when a bug is found and patched. We saw that very often in our group. Once people started to run into the bug, everyone started calling to see if it was a problem and what the fix was. This is where things like CD-ROMs and dial-up lines to bug systems can come in handy. It's actually interesting to see the types of calls that a support organization will receive at any particular time. For instance, right around the time when things are getting finalized as to what the next release will contain, you can bet that a lot of customers will call their support engineers to see if application X is going to be supported, or if option Y is going to be fixed in the next release. It's all human nature though. A customer who has just set out a lot of money to buy a machine wants to be sure that it is going to meet his needs in the future and that new releases of the software contain at least some of the things that he's been jumping up and down about trying to get it supported. In terms of the comment about getting what you pay for, I've seen both sides of the coin. I used to submit bug reports while in the Unix lab at HP, and got very timely responses. When I left the group and joined series 800 on-line support, however, the responses were less timely, even though the submittal method was the same. The other issue that was brought up was letting management know when you are not happy with the support that you are receiving. I think that this is a relevant issue regardless of whether you are an HP employee or a customer. As Dave pointed out, the divisions also pay for the equipment. If they buy a support contract, they are entitled to the same support as all the other customers. There should be some way of ensuring that this happens.
frank@hpuamsa.UUCP (Frank Slootweg CRC) (12/08/89)
A small point:
Both "sides" (customers and HP employees) keep talking about SE's ("Can
not get a hold of the SE", "The SE does not know about all the patches",
etc.).
The organization to contact is the *Response Center* (RC). The
engineers that work there are called RCEs (Response Center Engineers).
SEs do (generally) not exist anymore for many years. They are now
called AEs (Application Engineers) and are part of the AEO (Application
Engineering Organization).
The Response Center and the Application Engineering Organization are
(basically) seperate entities.
The AEO is mainly involved in pre-sales support and consulting.
The RC is the "maintenance" organization (at least for software). All
post-sales support (that is not consulting or the Account Management
part of a software contract (which is still done by the AEO)) is given by
or coordinated by the RC.
So while the actual work *might* be done by other organizations (for
software sometimes, for hardware always (by the CEO)) the RC is always
the one to call for "maintenance" (software and hardware), i.e. "One
Point Shopping".
If you are "chasing" your SE/AE for maintenance problems then you are
bound to be disappointed.
*If* you do not get good support from the RC then you should "hit" on
the engineer(s) or their management.
The situation I described exists in The Netherlands. Since this is a
(very) small country it is valid for most countries. For details contact
*your* local sales or support representative.
Thanks for listening (again :-)),
Frank Slootweg, Hewlett-Packard, Dutch Customer Response Center.burzio@mmlai.UUCP (Tony Burzio) (12/09/89)
In article <7810021@hpuamsa.UUCP>, frank@hpuamsa.UUCP (Frank Slootweg CRC) writes: > Again, our current indication is that *most* customers do not want to > get bug/patch information and associated patches for "all the problems > they don't have". They do want HP to help them solve the problems they > *do* have. This does not mean that we should not listen to the > "minority" that does want the info/patches but we should get some grip > on the number of customers that want this, how they want it, etc (see my > earlier postings). A graphics software company we deal with has an interesting way of handling updates. If some patches come out during the years between their every-three-year-major-release, they send out a letter to the support customers detailing the bug fixes/new features and a letter to return if the customer wants the fixes. I suppose you could set it up so that customers can set a default either way, always ship or never ship updates. The major releases would incorporate all the changes since the last major release. With HP-UX file sets, this would be easy to implement. Personally, I would apply the patches, but we have others who are running UNIXen that are four years old. ********************************************************************* Tony Burzio * Good heavens, it SNOWED! How'm I supposed Martin Marietta Labs * to get home?! mmlai!burzio@uunet.uu.net * *********************************************************************
jsadler@misty.boeing.com (Jim Sadler) (12/11/89)
>/ misty:comp.sys.hp / gentry@kcdev.UUCP (Art Gentry) / 10:09 am Nov 30, 1989 / >>In article <1320019@hp-ptp.HP.COM> mck@hp-ptp.HP.COM (Doug_McKenzie) writes: > >> >>couldn't be locally resolved. Software fixes are usually much quicker to >>resolve, because the problem can be emailed. Everyone I know at HP >>recognizes that months-long delays in fixing problems loses customers, and ^^^^^^^^^^^^^^^^^^^^ With the current release policy (updates about once a year) it may take longer. It would be nice if there was a list of patches available. There is nothing worse than spending days on a problem only to find out that "Oh thats been reported x amount of time ago" >>is perhaps the worst way to run a business. >> >Emailed???? What an original idea???? When is the RC going to recognize that >this is a valid option? Talk about cost savings!! Everytime I want a bug >fix I have to wait for the RC to FedEx it to me or spend the time to TRY >and get hold of my local SE to dial into the SE Support System in Fort Collins >to download it for me. I have requested that the RC uucp patches to me >several times, but they don't want to do this. > The peculiar thing about this is that the people in the "labs" use the internet and email. But not the response center, anyone know why ? >> >>I agree about the patch BBS. Why is the SSB "infamous"? >> One part is HP's interpatation of "enhancement request". Ask your customers about the "enhancement request" that was submitted for them, I bet most of them consider them BUGS. The second part is that an awful lot of "enchancement requests" are resolved as "May be fixed in a future release". >Very simple, it's impossible to use in it's current format. Unless you have >the time to read through the WHOLE thing. I'd love to get it on disc/tape >so I could load it onto my system for scanning through. Nice idea!! > > > >-- >| R. Arthur Gentry AT&T Communications Kansas City, MO 64106 | >| Email: attctc!kcdev!gentry ATTMail: attmail!kc4rtm!gentry | jim sadler 206-234-9009 email uunet!bcstec!jsadler|root | hplabs!hpubvwa!b-mrda!jim
jsadler@misty.boeing.com (Jim Sadler) (12/11/89)
/ misty:comp.sys.hp / frank@hpuamsa.UUCP (Frank Slootweg CRC) / 12:39 am Dec 6, 1989 / >Dave (Taylor) and *others*, > > I think we are getting somewhat closer to the right approach. > > As I indicated before UNIX/HP-UX customers generally want something >else then HP SupportLine can currently offer. The current supportline is not useable. I have 825CHX all terminals are network attached, try to use support line that way. I have 4 to 6 800s coming in between now and summer. They will have 700-22 and 32 terminals, try supportline on them. The data in supplort line is not up-to-date. Supportline is a nice idea it just is not there yet, maybe in 18-36 months. >>>- Patches *are* available (through the Response Center) between major >>> releases. This mechanism was set up at the *same* moment we reduced >>> the frequency of releases (on request from our customers!). How many customers know about the availability of patches ?? The way I found out was someone mentioned it at the last Interex. > > Again, our current indication is that *most* customers do not want to >get bug/patch information and associated patches for "all the problems >they don't have". They do want HP to help them solve the problems they >*do* have. This does not mean that we should not listen to the >"minority" that does want the info/patches but we should get some grip >on the number of customers that want this, how they want it, etc (see my >earlier postings). We have so many machines and so many applications for those machines that it is a MUST to have all of the info and we can't get it. > The audience in this forum on both sides are mainly technical people. >Responses from HP are mainly one engineer trying to help out another ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thank-you Thank-you Thank-you I can't thank you people enough. > >Frank Slootweg, Hewlett-Packard, Dutch Customer Response Center. > >Disclaimer: Only speaking for myself, not my employer. > >P.S. Give Dave and me a break. Let's here some more from other > customers and HP employees (especially in support). >---------- jim sadler 206-234-9009 email uunet!bcstec!jsadler|root | hplabs!hpubvwa!b-mrda!jim
john@hp-ptp.HP.COM (John_Fereira) (12/15/89)
> > One person's submissions do not the whole encompass. I myself > submitted a good number of bugs while at HP. This implies that you are not at HP anymore. Is that true? John
burzio@mmlai.UUCP (Tony Burzio) (12/15/89)
In article <1150004@misty.boeing.com>, jsadler@misty.boeing.com (Jim Sadler) writes: > The peculiar thing about this is that the people in the "labs" use the > internet and email. But not the response center, anyone know why ? Golly, about a year ago I got a patches sendmail.cf file through the mail from the Response Center. Somebody there has a connection, perhaps it is a close-guarded secret? ********************************************************************* Tony Burzio * Where do we go to surrender? Martin Marietta Labs * mmlai!burzio@uunet.uu.net * *********************************************************************
jsadler@misty.boeing.com (Jim Sadler) (12/18/89)
/ misty:comp.sys.hp / burzio@mmlai.UUCP (Tony Burzio) / 1:46 am Dec 15, 1989 / >In article <1150004@misty.boeing.com>, jsadler@misty.boeing.com (Jim Sadler) writes: >> The peculiar thing about this is that the people in the "labs" use the >> internet and email. But not the response center, anyone know why ? > >Golly, about a year ago I got a patches sendmail.cf file through the mail >from the Response Center. Somebody there has a connection, perhaps it >is a close-guarded secret? Last week one of the sites I support had reported a problem the response center asked that the info be emailed to them. Must be very dependant on whom you get. > >********************************************************************* >Tony Burzio * Where do we go to surrender? >Martin Marietta Labs * >mmlai!burzio@uunet.uu.net * >********************************************************************* ---------- jim sadler 206-234-9009 email uunet!bcstec!jsadler|root | hplabs!hpubvwa!b-mrda!jim
belkin@teecs.UUCP (Hershel Belkin) (12/19/89)
>>Golly, about a year ago I got a patches sendmail.cf file through the mail >>from the Response Center. Somebody there has a connection, perhaps it >>is a close-guarded secret? > Last week one of the sites I support had reported a problem the > response center asked that the info be emailed to them. Must be > very dependant on whom you get. I recently dealt with the Western Response Center and they asked me to FAX them a 15-page listing! Well, I have in the past found out that you get what you ask for -- ie. if you don't ask (read: demand), you don't get, so I launched into an attack of such a high-tech company not making use of e-mail. The consultant then managed to come up with an e-mail address on usenet! I sent the file immediately, and even got back a patch the next day!!! Generally, I find response center support to be excellent! And I've used it for the past 7 years, for all sorts of HP systems. I do agree that much more use of e-mail would be great, but I'm also sensitive to the fact that many HP sites are not (or cannot be) connected to usenet. Most problems that I have seen with the response center are a result of what I would call "mis-use" by the customer. (Although I wish that the customer need not know all the "rules" in order to get good service). What I mean is that you, as the customer, have the final say in your support response -- don't allow a call to be closed until you are satisfied! I make sure to end each RC call with an agreement as to whether the call remains open or is closed. And if things seem to drag, don't hesitate to escalate the problem! Worst that can happen is your local SE will be dispatched to "talk some reason" into you!! (You probably would like to see him/her at that point anyways :-) I plan to put into writing a set of "rules" for dealing with HP support that I have used for years with success...when I do I'll post it for discussion! (One important one is to keep a detailed log of every call and callback, including times, names, action plans, etc.) Recent experience: Had a *major* problem on our main system one evening. After some considerable effort, called RC (Atlanta). Explained problem, and informed them that my system was down. Got a call back from Atlanta; as it was already late, they promised to forward the call to California. Short time later got a call back from California; decided on some action attempts and left it that I would call again if I still wanted more help. I did. The next call back came from Melbourne, Australia! This really surprised me; seems that on urgent calls they now follow the time zones. Problem was eventually solved (before morning). I don't think many computer companies would do this well. (And I really didn't push it -- it was late and I was almost willing to leave the system down until morning :-) My only complaint is that in the end I sort of solved the problem myself...but I _did_ require some answers from HP that I allowed me to succeed, and I got them. (Had I not known what to ask, I would have had to wait for an SE). I'll end here for now by stating that I'm a _big_ fan of HP. In the past 8 years I have seen almost no system failures except those caused by user error, and most software is very solid (compared to lots of other manufacturer's stuff). However, I have a number of suggestions which I've been waiting to make -- this seems like the best forum, but I'll post them as a separate article. I think it's great that such a discussion can take place here! -- +-----------------------------------------------+-------------------------+ | Hershel Belkin hp9000/825(HP-UX)| UUCP: teecs!belkin | | Test Equipment Engineering Computing Services | Phone: 416 246-2647 | | Litton Systems Canada Limited (Toronto) | FAX: 416 246-5233 | +-----------------------------------------------+-------------------------+