Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde!uunet!cs.utexas.edu!usc!brutus.cs.uiuc.edu!apple!limbo!taylor From: taylor@limbo.Intuitive.Com (Dave Taylor) Newsgroups: comp.sys.hp Subject: Re: HP Customer Support... Message-ID: <208@limbo.Intuitive.Com> Date: 5 Dec 89 18:00:18 GMT References: <203@limbo.Intuitive.Com> <7810019@hpuamsa.UUCP> Reply-To: taylor@limbo.Intuitive.Com (Dave Taylor) Organization: Intuitive Systems, Mountain View, CA: +011 (415) 966-1151 Lines: 181 Frank Slootweg of HP 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