[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::digital

Title:	The Digital way of working

Moderator:	QUARK::LIONELON

Created:	Fri Feb 14 1986
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5321
Total number of notes:	139771

991.0. **""Hey man, it's not my job"..."** by MUSKIE::SCOTTG (Greg Scott, Minneapolis SWS) Thu Dec 28 1989 03:26

    The following happened on Thursday and Friday, Dec 14-15, 1989.
    I wrote it all down, sent it to our local Sales and Software Support
    management.  I'm frustrated because I spent a week at DU:IT in October
    listening to VIPs tell me how Digital is getting rid of red tape
    and trying to make life a little easier for us field grunts.  Welcome
    back to the real world...
    
    I waited a few days before posting this, because I was mad at the time.
    Well, now it's a couple weeks later and I'm still mad.  The moral to
    the following stories are, we all need to cooperate with eachother -
    even if it's not our job - if we want to stay viable for the long term
    future. 
    
    Names are "******"'ed out.
    
    
This has been a rough couple of days.  I think there's a moral in these 
two stories someplace.

First:

Yesterday, I had a sales rep ask me for help finding somebody to talk to
her customer about an ASSETS package called ***********.  Her customer
is the Mayo Clinic, and the person she is working with wants to give us
a purchase order for it now, today.  But, her customer has a few basic
questions about the package.  Basic questions, like what kinds of
reports does it produce and stuff like that. 

We don't have anybody available locally who's heard of the package.

So we found a notes file and looked at a few entries.  We found a person
from an engineering group who seemed to be intimate with the package.  
So I gave the person a call.  This person told me there was a good 
writeup in VTX, with product descriptions, contacts, everything we need.

So we followed the VTX menus, found the writeup on the package, copied 
and printed everything we could find.  This consited of a couple hundred 
blocks of policies, procedures, workstatement guidelines, rules, 
regulations, terms and conditions, and other legalese.  And there was a
few pages that described what the product does in general terms.  But no 
contacts for technical questions.

Near as we could tell, the model doesn't take into account a customer 
that might want to ask a couple questions about an ASSET package 
*before* buying it.

Well, after plowing thru this stuff for a couple hours, I called the
person from engineering again.  He told me to read and understand the
procedures and follow them, and that it is not his job to talk to
customers.  I replied I understood it's not his job, but he is the
best person to answer the questions.  He gave me a hotline phone
number, DTN ***-****, told me again to follow the proper channels, and 
told me again it's not his job to talk to customers.

So we tried this corporate hotline and got put on hold for several 
minutes.  We finally got thru to a guy, who said he would try to find 
somebody to talk to our customer.  That was yesterday, Thursday, 
about 3 PM central time.  We haven't heard back.  (Note, we *still*
    haven't heard back, 2 weeks later.)

Meanwhile, we found a person in Milwaukee who has installed the package 
and used it a little bit.  He is willing to talk to our customer, and we 
got them together on the phone this afternoon, Friday.

Happy ending?

I hope so, but consider the big picture at Mayo Clinic.  This is a huge
and influential Digital customer, with a worldwide reputation.  We just
finished talking to a manager out there who told us they are considering
setting up a database of all their patient research records since 1952. 
They think this database will have about 30 *million* records.  The
database will be available to researchers all over the world.  Right
now, Mayo is concerned about the long term viability of VMS as a
strategic platform. They are leaning, believe it or not, towards UNIX as
a long term platform because they are not convinced VMS will be around
for the long term future. 

We're working to fix that mistaken impression, but we're just a couple 
grunts from a local office.  We don't have much credibility.

If I were the person at Mayo Clinic, I would be wondering right now if
Digital can't get its act together on a little ASSET package, how can
they possibly trust Digital as a vendor for a mission critical research
database?  From their point of view, lots of other vendors out there 
*want* to do business with them.

Between the Sales rep and I, we've probably got at least 8 hours of time 
just trying to find somebody to talk to the customer and filling out the 
paperwork - for a $5000 package - and it's not done yet.

For you folks that don't work in field offices, I know you are busy.  And
I know it's not your job to talk to customers.  I know that people in
engineering have schedules to meet.  But you should know that when I
call, I really need your help.  I am also busy, I also have schedules to
meet, and our customers have schedules to meet.  And you should
remember, without customers, we will *all* be out on the bread line or 
pumping gas and getting our hands dirty. 

If you're not sick of reading yet, here's the second story:

We've been working with a group at the University of Minnesota since 
April.  The group is called the Colon Cancer Control Study.  They are 
looking for a computing platform for their database.  The *only* reason 
they are in business is to build this database and draw conclusions from 
it.  Right now, they are buying time on a CDC platform from another 
group at the University.

After lots of hard work by a whole bunch of people in our local 
office, and after lots of politics at the University, they finally 
issued a purchase order.  They bought a bunch of VMS VAXstations, a 
bunch of DEPCAs, an MV3800, cabling and tools to network it all 
together, and some consulting.

After officially putting in the order, Manufacturing promised a
"committed" ship date.  The sales rep called the customer and told them
the ship date.  The customer then made plans to receive the stuff and
coordinate everyone they needed, including pulling the cable over a
weekend.  The Sales Rep also lined up hardware installation from our
Customer Service.  When manufacturing failed to meet their committed
ship date, they gave another ship date.  The Sales Rep informed the
customer and our service organization, and everybody changed their
plans.  Well, this happened 5, count 'em, *five* times.  We've been
promised 5 ship dates and each one has failed.  Not only has
manufacturing failed to meet 5 promised ship dates, the only way we have
been able to find out is for our CAS people to keep calling to find out
where the stuff is. 

Well, now, after spending most of a year building our credibility with
this customer, they are starting to wonder if they should trust Digital
as a vendor for their operation.  As a vendor, if we can't even ship
hardware when we say we're gonna ship it, how can we possibly manage the
much larger task of "Enterprise Integration" we brag about?  

I'm not talking about long delivery times here, I'm talking about keeping 
promises.  The only weopon we have here in the field is credibility.  
When Digital makes a commitment to a customer, then fails to meet that 
commitment, Digital's credibility goes way down.  When Digital fails
5 times to meet a commitment, Digital's credibility goes waaaaay down.

Our name isn't mud yet with this customer but it's close.  It took 
almost a year to gain some credibility, it took a couple weeks to blow 
most of it away.

- Greg Scott

T.R	Title	User	Personal Name	Date	Lines
991.1	On digging sand...	RIPPLE::KOTTERRI	Rich Kotter	`Thu Dec 28 1989 11:40`	32
	Re: Note 991.0 by MUSKIE::SCOTTG I've been with the company in sales for six years and the scenarios you described seemed so familiar, as I have lived through them so many times. The sales person and his support people feel like they have to move heaven and earth to get the most rudimentary things done. It makes you feel like you spend most of your time digging yourself out of the sand, rather than actually going somewhere. The sales process at Digital is much too complex. There are too many details that need to be chased down with no clear place to get them, and often multiple conflicting answers when you do. The official support channels often know less about the products being sold than the person trying to get the answers. Those who really know the answers are often not accessible to the sales people. The press stories about Digital sales being non-responsive are often (but not always) true, and it is because of this complex sales process. The good news is that upper management seems to be beginning to realize this and to try to figure out how to change it. One encouraging developement is a hot line for sales managers to call when something seems to be getting in the way of getting business. Their job is to cut through any red tape that is getting in the way, and to find solutions to such problems. You might talk to the Sales Unit Manager, to see if he/she is aware of it. I don't know how well it is working generally, but they claim that they have had some good successes. I sincerely hope this kind of stuff will soon begin to happen less and less often. It is so incredibly frustrating, and it makes a BIG negative impact on Digital's long term success. l
991.2	re .0: did you use the MRC??	SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 11:47`	534
	From: NAME: Dave Grainger FUNC: US. MGMT TEL: 297-4940 <GRAINGER.DAVE AT A1 AT USCTR1 AT MRO> Date: 02-Nov-1989 Posted-date: 02-Nov-1989 Precedence: 1 Subject: MANAGEMENT RESPONSE CENTER ANNOUNCEMENT To: See Below CC: See Below ********************************************************************* PLEASE DISTRIBUTE THROUGHOUT YOUR ORGANIZATION ********************************************************************* We've talked much lately about the importance of communications during times of change. To be totally effective, communications must be two way to allow for quick response to changing needs. Recently we announced the cross-functional teams led by Bill Lynch and Mike Marshall to assist in problem resolution and barrier removal. Today I want to tell you about another resource to help you remove barriers that impede business, the new Management Response Center (MRC). We are putting this cross-functional service in place to give you the ability to call a central location, submit issues for resolution, and receive the same priority as customer issues that escalate to Ken Olsen. The Center will help put more muscle behind your empowerment and help ensure that the fastest possible response will be given to your issues. Effective immediately, you will be able to call the MRC on a special direct line when anything stands in the way of your organization's ability to do business. DTN: 276-MGRS (276-6477) OUTSIDE: (508)496-6477 The center is intended to provide cross-functional support and will address any issues regardless of function. However, we do ask that sales management submit them for resolution. This will help provide a common focal point for recording and tracking submissions. The MRC is an integral part of the Customer Relations Group managed by Elaine Navedonsky and is staffed by experienced individuals who will be able to provide a timely solution to your issue. The group will have a direct link to the USMC and will give every request top priority. You will receive, by ALL-IN-1 mail, an issue acknowledgment and a detailed action plan the same day your call is received. Daily status will be provided until the issue is resolved. This new capability does not replace any existing process for resolving problems but provides you with another tool to use when normal processes do not meet the need. The MRC will also provide the focal point for issue resolution for the Executive Partner Program (EPP), District Partner Program (DPP), and all similar activity where issues are collected that need to be addressed. In order to share resolved issues, we will communicate to all of you on a regular basis the resolution of all issues that affect everyone. We will also build an on-going database of resolved issues that will be readily accessible on ACCESS. Watch for more information about this as it comes on line. I encourage you to use this new support tool to ensure quick resolution of critical business issues and to continue effective two way communications. To Distribution List: ROSE ANN GIORDANO @MRO, AL HALL @MEL, LARRY GOODWIN @WRO, FRANK BOWDEN @SCA, RON HEVEY @NYO, RON EISENHAUER @ACI, RAY WOOD @MRO, BOB LONG @IVO, HARRY EISENGREIN @ALF, CAROL BAYLEY @UFO, BOB RUSSELL @NYO, ALAN CROLL @MEL, AL PINK @RHQ, RAY ARNDT @ACI, BOB BURKE @OHF, CHARLES PAYNE @SCA, MALCOLM JONES @WRO, GERRY BRYANT @IVO, GARY MOORE @DER, JUDY CHARTIER @MKO, SUSAN VINE @MKO, MIKE MCNALLY @WMO, BOB CORBEIL @NIO, JACK SHAUGHNESSY @MRO, JOHN DELISLE @MRO, SPENCER DESHIELDS @MRO, GWALKER @USMFG @VMSMAIL, ROGER HARRIS @MRO, NANCY MCCUNE @MKO, JACK MCCORD @BUO, MANFRED TADLHUBER @AWO, LARRY SEARS @EKO, SHERRY GROOVER @RHQ, MARIANNE SCHRODE @OHF, LISE GORAJSKI @ACI, JOHN CLARK @DVO, GARY WHITE @WRO, MATT WILLIAMS @LQO, DICK MCCARTHY @BUO, DAVE BERESFORD @UFO, SUE ANN KRAKOWER @NYO, DICK ROGERS @MEL, JIM MYERS @RHQ, BEVERLEE JOHNSON @ACI, KATHLEEN CONNOLLY @YWO, DENNIS BEDARD @SCA, GORDON GILBERTSON @WRO, SYLVIA HANKINS @IVO, SALLY CUNNINGHAM @NYO, AL PERKINS @MEL, ALAN ANDERSON @RHQ, ROBERT NANCE @ACI, GARY CHICOINE @OHF, BILL DELLACCIO @SCA, JACK LANDERS @WRO, WILLIAM NIXON @IVO, GIL VONDRASEK @CXO, LEE PLEDGER @WFR, JOHN MARLETTE @MEL, BOB KETZ @UFO, GORA DUTTA @NYO, DALE EMERSON @MEL, RICHARD RACKLEY @RHQ, DAVE STEVENS @ACI, DOROTHY GLEASON @OHF, ED PANCHISHIN @SCA, TED HOPSON @IVO, BILL GERVAIS @MRO, GWEN CRAWFORD @WRO, DON LEIGHTON @UFO, JOHN FISCHER @PCO, HORST ADLER @MEL, MIKE JACKSON @ACI, BILL CUMMINS @OHF, DON PHILPOTT @SCA, ROBERT BROOKS @WRO, GEORGE NEWTON @ALF, RICK DISTASIO @DER, JIM NEUMANN @IND, WILLIE HOOKS @IVO, TOM GRILK @UFO, PAT MCMAHON @NYO, ANDY STONE @MEL, JOHN HENDERSON @RHQ, NORMA SUTTON @ACI, STEVE MORELLO @OHF, FREDYE GOODEN @SCA, JEFF SMITH @IVO, JEFF LEVINE @WRO, SCOTT RIMMER @MDO, TOM IANNOTTI @RCO, STEVE MCGOWAN @BXO, MIKE WURSTER @OFO, DON LABELLE @MHO, LOU LEGGERO @WAO, DAN ROSS @OFO, CAROLYN PARKS @OFO, JOHN CARROLL @ATO, JEFF HALL @TMO, DICK GROSECLOSE @CEO, MIKE HOWARD @MMO, AL TETRAULT @RHQ, DAVID MITCHELL @ORO, ROBIN SPANGLER @RHQ, MIKE HOLFERT @ACI, MIKE MORTIZ @CPO, DAVE BARRY @STO, DICK WRIGHT @MPO, MIKE NOTARO @ACI, ROGER ROSE @KCO, NARI BAWA @STO, BRIAN MCQUADE @LAO, SHEL SHERMAN @LAO, BOB DREW @CWO, JOHN DONAHUE @CWO, VINCE DIMENNA @CWO, RANDY WATERS @TFO, ROD GUTHRIE @CWO, BOB BAJEMA @SEO, JACK SUNDERLAGE @SLO, DICK BRUCE @SZO, SUSAN STEVENSON @WRO, TOBY ARNOLD @WRO, ART LANATA @WRO, ROGER ORR @WRO, DICK GORTLER @KYO, RITA ROLEY @NJC, BILL STYSLINGER @NYO, MIKE DEPASQUALE @NYO, PETER EDWARDS @WHO, BOB STEPHENS @NYO, LENNY PEZZELLO @NYO, ANDREW STEPHENSON @WNP, PETER HATFIELD @DCO, JT MCFADDEN @PHO, HERB CLINE @PHH, TED SCHRAFFT @CHO, ED SCULLY @DCO, BOB BRYANT @DCO, BRUCE DAVIDSON @DCO, VIC MACHIANO @DLO, DICK ROBERTS @HSO, IVAN BOYD @DLO, LARRY HOLMBERG @AQO, BILL KRAUSE @DVO, DON JONES @DLO, LEN ZERA @FHO, SCOTT BENSON @CYO, DENNIS DEBAISIO @PTO, JIM BRIGGS @FHO, JIM ALBERTY @FHO, LOU YOUNG @CLO, JACKIE CARTER @RHO, ROBERT CARTWRIGHT @RHQ, DAVID ALFIERI @PTO, NICOLE BAAS @DLO, BOB BARNARD @MEL, FRANK BLAKE @TFO, ANANIAS BLOCKER @DCO, GERALD COLEMAN @ATO, RICHARD COYLE @CYO, BOB DAVIDSON @BWO, PEGGIE DRAUSS @KYO, ROSEMARIE ECK @MHO, PAUL FOREE @MMO, BRIAN GREENE @TMO, PATRICK GRIMES @DVO, LARRY HARAMOTO @LAO, JOEL JOHNSON @WRO, SUZANNE JONES @CEO, BARBARA LAINE @WHO, LUCINDA LARSON @WAO, REGINALD LINEBARGER @FHO, ALLEN LOVE @STO, DAN MARTIN @CWO, JAN MCCARTHY @MPO, ROMESH MEHTA @MDO, STEVE MYERS @ACI, ED SAMUEL @PHH, CURTIS SMITH @SZO, POYEE TAI @NYO, DUANE TAYLOR @DCO, RICK VACCARO @RCO, BILL ADAMS @PTO, SUSAN ANDREWS @CHO, ROY BROWN @MEL, SUSAN CHAMBERLAIN @CXO, GLORIA CLAYTER @STO, JUDY CORNELIUS @ACI, IRENE DUBBER @ATO, DONNA DUSCHANE @SCA, JULIAN EAVES @IPO, JOYCE FULLER @ACI, GEORGE GARDNER @LAO, RON GIBSON @UFO, JOHN GONZALES @HSO, WANDA HACKETT @IVO, EVE HALL @OHF, COURTNEY HALL @WRO, PAT HANNON @FHO, MARY HEBEIN @MPO, PAT HOLDER @CWO, MARTY HOULDSWORTH @RHQ, TOM HUBAN @KYO, ED HURLEY @IND, MARY KENDRICK @MEL, LINDA KLEIN @NYO, BARBARA LATIMER @OFO, ESTHER LINAN @WRO, BOB MAHER @NYO, DAVID MCGEE @DVO, NANCY MOSER @WRO, JOANNE OLSON @NYO, BILL ONEAL @CEO, CARLOYN PEELER @SCA, DOUG PETERSMA @ACI, JIM ROGERS @MEL, RICHARD ROGERS @ACI, WALTER SLADE @KYO, SUE BOLTON SMITH @OHF, KAY STEGING @SCA, JUANITA THOMAS @ATO, ROBERT UNGARO @SEO, CLAUDETTE WARD @DLO, JERRY ZEVIN @IVO, NABIL BALADY @FVO, DON BERTSCH @SDO, WALT BIEL @LIO, RON BURT @TMO, BILL CAMERON @WHO, PAUL CIARDULLO @MDO, MIKE CLARK @CPO, PAT CRUZ @SZO, ERNIE DALE @PTO, BOB DAVISON @BNO, BILL DENLINGER @KYO, TED DEVER @SEO, FRANK DIROCCO @FLA, LOIS DOWD @HSO, JIM DUPREE @CXO, AL DUX @HWO, TOM ENGLADE @MMO, CHARLIE FIORINA @FTO, DENT FRUEH @DVO, DENNIS GILES @CLO, BOB GLASER @LVO, STEVE GRAVES @CSO, BOB GRAY @SAD, FRED GRECO @ODO, MIKE HARRIS @RTP, MARK HAUT @MKO, RUTH HILL @ACI, CHRIS JENNINGS @DCO, CHUCK JENSEN @SLO, VINCENT KAMINSKI @CXO, PAUL KILLAM @MLO, GINO LAMARCA @DWS, JOE MARAGIOGLIO @OFO, MARION MARQUEZ @BHO, BOB MATUSIEWICZ @LLO, PAT MCCARRAGHER @AQO, DALE MELTON @FOO, GERRY MISENER @STO, BILL MOORE @AUO, MIKE MORTENSEN @NYO, STAN MOSS @MRO, RITA NEER @PCO, DOZIER NICHOLS @GPO, WALLY NOVAK @HEO, AL ODABASHIAM @HYO, PHILLIS ODITT @CYO, MARK OLSEN @MPO, SAM PIZZITOLA @NOO, KEITH READ @KCO, KEN REEVES @GGO, TOM RENNER @AWO, JIM RONEY @RCO, SHARON ROSEN @PVO, STEVE RUCINSKI @MWO, AGGIE RUCKER @VYO, WALT RUSH @PHO, JOHN SCAVELLI @EJO, GEORGE SCHIEBER @RDO, BOB SILHAVEY @WAO, RON SMITH @DWO, RAY TURCOTTE @WDF, DICK VINTON @MHO, LOUISE WARREN @CBO, RANDY WHISLER @TFO, GARY WHITE @DEO, RUDY WILLIAMS @PDO, KEN WILLIS @DLO, GIL ZEPEDA @WRO, JOE BELBRUNO @CWO, SARAH BIGGS @CEO, CATHY CAMBAL-HAYWARD @WAO, RON CARDAMONE @PHO, TONY COMITO @KYO, MIKE CRONIN @MHO, TOM DARCY @NYO, TOM DAVIS @MWO, MIKE DELVECCHIO @MDO, BESTY FITZ @OFO, DAN HOLDEN @WRO, JOE GARZONE @DWO, KEN GILLIS @RLO, GEORGE TOPPING @DCO, JOHN GROH @KYO, JIM HALPIN @NYO, GEORGE HARLOW @HSO, AL HAUG @RCO, MIKE INDOVINA @DWO, ROD JACKSON @FHO, ERIC JOHNSON @PTO, LINDA JOHNSON @ATO, BILL KING @MDO, RON KINNEY @LAO, PAT LAMBS @SZO, LOU LIBERIO @CHO, JIM LIVINGSTON @IND, JIM MAPLES @CYO, BETTY MCGOUGAN @DLO, TED MCKIE @BXO, MARK MITRA @FHO, AL NORDGREN @WRO, JOE PETERS @PXO, JIM POPA @DCO, RICK POTTINGER @LAO, SAM PRAUL @CLO, JIM RIZZOLO @NYO, JOHN SCARDUZIO @CHO, AL SHORT @MPO, CLAUDIA SKELTON @SEO, BENNIE SLONE @TMO, DARNELL SPENCER @DCO, DAVE VEST @MMO, BRAD WILSON @SCA, BILL BYRD @ATO CC Distribution List: ELAINE NAVEDONSKY @OGO, JOHN ALEXANDERSON @CORE, HENRY ANCONA @MKO, FRANK BOWDEN @DLO, DON BUSIEK @CORE, PAT CATALDO @BUO, GEORGE CHAMBERLAIN @CORE, HENRY CROUSE @CORE, JAMES CUDMORE @CORE, WILLIAM DEMMER @CORE, HARRY EISENGREIN @RHQ, RON EISENHAUER @ACI, SAM FULLER @CORE, ROSE ANN GIORDANO @CORE, ROBERT GLORIOSO @CORE, LARRY GOODWIN @WRO, DAVID GRAINGER @CORE, RUSS GULLOTTI @NPO, WILLIAM HANSON @CORE, WILLIAM HEFFNER @CORE, RON HEVEY @NYO, WIN HINDLE @CORE, MARTIN HOFFMANN @MLO, ROBERT HORNE @OGO, ROBERT HUGHES @MKO, DONATO INFANTE @CORE, ILENE JACOBS @CORE, WILLIAM JOHNSON @CORE, BOB LONG @IVO, WILLIAM LYNCH @OGO, JACK MACKEEN @CORE, MIKE MARSHALL @MRO, KEVIN MELIA @CORE, AL MULLIN @MSO, JAMES OSTERHOFF @CORE, ROBERT PALMER @CORE, JERRY PAXTON @OGO, GREG PLAKIAS @MLO, BRUCE RYAN @MLO, GRANT SAVIERS @CORE, JACK SHIELDS @CORE, JOHN SIMS @CORE, JACK SMITH @CORE, PETER SMITH @CORE, WILLIAM STRECKER @CORE, HARVEY WEISS @CORE, RAY WOOD @MRO, DON ZERESKI @CORE, JOHN ALEXANDERSON @CORE, HENRY ANCONA @CORE, DON BUSIEK @CORE, PAT CATALDO @CORE, GEORGE CHAMBERLAIN @CORE, DAVID COPELAND @CORE, BEL CROSS @VRO, HENRY CROUSE @CORE, JIM CUDMORE @CORE, BILL DEMMER @CORE, GARY EICHHORN @MRO, ROBERT FARQUHAR @MKO, RICHARD FARRAHAR @MLO, DICK FISHBURN @OGO, SAM FULLER @CORE, DOUG FULRATH @MRO, _WJO::GAVIGLIA AT A1 AT USCTR1 AT MRO, ROSE ANN GIORDANO @CORE, BOB GLORIOSO @CORE, DAVID GRAINGER @CORE, _CSS::GULLOTTI AT A1 AT USCTR1 AT MRO, BILL HANSON @CORE, BILL HEFFNER @CORE, WIN HINDLE @CORE, ROBERT HORNE @OGO, DON INFANTE @CORE, ILENE JACOBS @CORE, BILL JOHNSON @CORE, MIKE KALAGHER @CHM, DOM LACAVA @CORE, DAN LATHAM @AET, JACK MACKEEN @CORE, FRANK MCCABE @CORE, DON MCINNIS @CORE, KEVIN MELIA @CORE, AL MULLIN @CORE, JOHN OKEEFE @MKO, JIM OSTERHOFF @CORE, BOB PALMER @HLO, RON PAYNE @MLO, GREG PLAKIAS @MLO, PETER ROBOHM @AET, BRUCE J RYAN @CORE, GRANT SAVIERS @CORE, JACK SHIELDS @CORE, JOHN SIMS @CORE, JACK SMITH @CORE, PETER SMITH @CORE, BILL STEUL @CORE, BILL STRECKER @CORE, SANDY THOMAS @AET, RICHARD WALSH @OGO, ABBOTT WEISS @MLO, HARVEY WEISS @CORE, DON ZERESKI @CORE, STEVE BEHRENS @MRO, DONNA BLANEY @MRO, BILL FERRY @MRO, LOU GAVIGLIA @WJO, DAVE GRAINGER @MRO, TOM GRILK @UFO, MIKE KALAGHER @CHM, RICH NORTZ @WFR, JERRY PAXTON @OGO, BOB HUGHES @MKO, HARVEY WEISS @MRO, JACK MACKEEN @UPO, ELIZABETH STRONG @MRO, TOM COLATOSTI @MRO, JAY ATLAS @UPO, DICK CLINTON @OGO, JOEL GOLDSTEIN @OGO, ED KAMINS @OGO
991.3	...and so it goes...	SCAM::GRADY	tim grady	`Thu Dec 28 1989 12:17`	16
	Re: .-* Personally, I don't think the problem is in the process, but in the attitude. We've been subjected to a lot of lip service about being more customer-focussed, with barely a word about HOW that focus will be attained. Everything I'm seeing is focussed on our own internal organization trees and job-swapping of middle management. I haven't seen a single plan to implement this customer focus. Just a lot of memos tossing around this year's latest management 'science' (and I use that term very loosely) buzzwords. If I see the words 'empowerment' and 'stovepipe' one more time, I think I'll scream. Garbage. Greg, as you so elloquently point out, the more things change, the more they stay the same. Quite disillusioning. As for the MRC, I'll believe it when I SEE it.
991.4	Are Their Any Leaders Out There?	MSCSSE::LENNARD		`Thu Dec 28 1989 13:39`	10
	Re .0....Where in the h--- was your manager in both situations? Sounds to me like a gross failure on his/her part. Both issues should have been elevated to whatever level needed in a matter of hours. The "engineer" should have been on a plane in four hours. Disgusting! Re .3...Strongly agree. We don't have managers (read leaders). Far too many of them are self-serving career climbers who don't want to dirty their hands with real problems. If this is typical of the "field", I grieve for Digital.
991.5	Takes a crisis to move the leviathan....	CSC32::S_HALL	Digital Employment Corporation	`Thu Dec 28 1989 14:48`	27
	.0's situation is pretty typical, sadly. There is still NO plan in place to handle critical software problems for a customer. Hardware, no problem: RDC, local Field Service Rep, senior specialist, area support, etc. But when a software problem that's CRITICAL pops up, once the CSC's have exhausted the phone-support and dial-in options, the whole thing bogs down. If it's one of those might-be-hardware, might-be-software situations, then the customer often winds up left alone while different groups try to decide who "owns" the problem. As it now stands, to get a CSC or engineering-level expert flown to a customer site,one of the following probably has to be true: 1) Pending sale of equipment (probably hundreds of 1000's $s at stake) 2) Or, threats by a large customer to toss the DEC hardware in the street... It'll probably take a MAJOR streamlining of Digital (can you say takeover?) or enormously more active upper management than we've seen to erase these sorts of problems.... Steve H
991.6	re .5	SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 14:56`	6
	Steve, you're dead wrong. My group handles critical software problems every day. The method is a CLD. If you're working for the CSC and don't know about CLDs as the means to get engineering-level corporate support group involved with your customer outage, go see your manager. Marge
991.7	or see John Webster or Travis Brannon in CXO	SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 14:58`	4
	...oh, and if it's a "hot potato" hardware/software issue, get ahold of Bruce Judson or John Earnshaw or George White. Marge
991.8	_Whose_ job is it?	ASD::DIGRAZIA		`Thu Dec 28 1989 15:29`	17
	In .0 you say "... that it is not his job to talk to customers. I replied I understood it's not his job, but he is the best person to answer the questions. ..." You replied incorrectly. It was indeed his job. IBM says "Everyone Sells". Of course, the problem lies with the boss, who doesn't make room for the engineer to consult for sales. After all, it isn't as if sales people ring the phone off the hook. It's alwasys easy to create _some_ time! Regards, Robert.
991.9	Everyone a marketing manager?	ODIXIE::CARNELL	DTN 385-2901 David Carnell @ALF	`Thu Dec 28 1989 15:39`	10
	Ref: 991.8 >><< IBM says "Everyone Sells".>> Perhaps an even better idea might be where Digital says, "Everyone is a self-managed marketing manager with both the responsibility and the authority to ensure that customer wants are satisfied." Of course, realizing such a thing within all 125,000+ employees would require a change or two in "how" Digital works.
991.10		KYOA::MIANO	Mad Mike's Mythical Miracle	`Thu Dec 28 1989 15:41`	11
	RE: .-2 I have used the CLD a few times but never will again. There is nothing that can be done with a CLD that cannot be solved quicker by putting in a few week of extra legwork (Of course either way will piss the customer off but at least you have some control of the situation) or getting a sales rep to scream at the top of his/her lungs to anyone who will listen. The CLD just another layer of bureaucracy that does absolutely nothing towards solving serious customer problems in a timely manner. John
991.11	Did you ask to speak to the boss?	SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 15:41`	15
	Perhaps the maligned engineer had just been given a strict talking to about his/her job metrics or had just had an exhaustive job planning session with his/her manager. Perhaps it was made abundantly clear that she/he was spending entirely too much time in notes trying to feed information to the field while letting development/maintenance go by the way. If that were the case, the response was absolutely appropriate. Unless you can relieve someone of their current job responsibilities or help them in some way meet their job metrics, you are simply asking them to fail by taking on additional, unrecognized responsibilities. The trick is to have the additional responsibility become a recognized job. The only way to do that is to have the manager of that individual contributor recognize it as a valid task. Got the picture? marge
991.12	We're measured on them, tend to ignore nonformal requests.	SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 15:42`	3
	John, I've seen CLDs work wonders. Too bad they didn't work for you. Marge
991.13	Forms? Procedures? Yikes, off with their heads!	ISLNDS::BAHLIN		`Thu Dec 28 1989 17:36`	22
	Hey Marge, I've been there (on both sides). I want you to know that I understand your message but think you can't really appreciate the frustration until you've been out there. Quoting stories about metrics and CLDs or XYZs or ABDEFs or any other TLA is just so much smoke to some body who has just struck out on their 5th phone call, 200 miles from the office and into their 10th hour of work in a 60 hour week. Anybody with customer contact is viewed (by the customer) as an information resource 'socket'. You don't have to be in a CSC to be put into this mode. And if you think everyone touching customers knows the obscure elevation channels to your organization or any other 'correct' and formal path you have an exagerated sense of the completeness of communication in this company. I certainly don't mean to offend but you must understand that what you propose sounds a bit like bureaucracy gone wild....... "We're sorry corporal Jones, but we can't just send in an air strike on your say so. You need to fill out form DD219. We will process your request just as soon as we get the form and proper payment authorization from Washington."
991.15	Just my two cents!	ISLNDS::BAHLIN_B		`Thu Dec 28 1989 17:39`	18
	RE: .12 I disagree with you, I believe the biggest problem that DEC faces today is the attitude "that it's not my job!" Customer satisfaction is everyone's job....... just exactly what is the GOAL of this company? Is it not sales/revenue/customer satisfaction? I believe that is our whole reason for being....and if someone calls me and needs help resolving some issue, it is my responsibility to do my damndest to do it. And I find it hard to believe that taking time to guide or direct someone to the resource necessary to resolve the problem is going to jeopardize anyone's performance metrics. It seems to me if the person calling was given your name as a resource it must be because you either know the answer or know how to get it! And if by chance you resolve their crisis, what is the satisfaction worth to you? It means a lot to me....
991.16	re .13	SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 17:48`	10
	Sorry, I'm speaking from experience on both sides here. I've "done my time onsite". Four years with a suitcase and a dial-a-prayer number. When there are mechanisms in place and metrics in place, they should be used, and if they are not responsive they should be fixed. Going around the mechanisms simply allows them to continue to be non-responsive to your needs. my .02, Marge
991.17	Whew	ISLNDS::BAHLIN		`Thu Dec 28 1989 18:21`	12
	re: .16 I agree, almost. For the person on the other end of the phone, the immediate need is for an answer. Fixing the process is secondary to the problem currently on the front burner. So yes, I think the caller needs to work the system, eventually. But, I think it is inappropriate for the callee to site company regs. The first order of work is FIX THE PROBLEM. The second order of work is for both parties (caller and callee) to beat up the system that enabled the disconnect in the first place.
991.18	so long as there's a parallel submittal	SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 18:58`	13
	I agree, except that there are so many properly-escalated problems in the que normally that we simply never have time to work on improperly escalated problems. Staffing is based on the numbers. Back-alley fixes don't show up in the numbers and don't result in staffing. Fact. In many, many cases I've tutored folks on the telephone on how to submit a problem so that we can indeed work on the problem. AND, in the meanwhile, we work on the customer's problem, but only so long as there is a parallel effort going on that will eventually result in the problem reaching us thru formal channels. It's the only way our work gets recognized. Marge
991.19	And yes, CLDs really do work	BEING::MELVIN	Ten Zero, Eleven Zero Zero by Zero Two	`Thu Dec 28 1989 19:00`	38
	> I disagree with you, I believe the biggest problem that DEC faces > today is the attitude "that it's not my job!" Customer satisfaction > is everyone's job....... just exactly what is the GOAL of this > company? With all the customers that DEC has, which customer is to be satisfied first? In the .0 case, what was the workload of the engineer? Was a more critical problem being worked on? Perhaps a CLD? Who gets to order the workload? Anyone who calls up? The engineer's management? A person dropping (some) current work to take on the new 'chore' may very well get into a situation of trying to please 2 (or more) customers at the same time. Then it is a no-win situation for the engineer, and for one or more of the customers. > damndest to do it. And I find it hard to believe that taking time > to guide or direct someone to the resource necessary to resolve > the problem is going to jeopardize anyone's performance metrics. I thought that .0 said the engineer in question did provide pointers as to where to go for additional help. > It seems to me if the person calling was given your name as a resource > it must be because you either know the answer or know how to get > it! Wrong. Just because someone has your name does NOT mean you know enough to answer someone's questions. An example would be someone reading the IBM PC conference. Someone looking for an answer to a question comes across a note where person A has taken a guess at an answer. Is person A now expected to be able to answer any IBM question someone might have. Should they be faulted for NOT being able to answer? Or for not being able to provide a pointer to another person? Sure, customer satisfaction is everyone's business. There does have to be a limit on what you can reasonably expect one person to do. There was an old saying that went something like "No one can serve two masters (well?)". -Joe
991.20		SUBWAY::BOWERS	Count Zero Interrupt	`Thu Dec 28 1989 19:02`	7
	Marge, I understand the constraints under which you work. However, doesn't the fact that the "proper" method of submitting a problem requires a tutorial say something right away about the process being out of whack? -dave
991.21		BEING::MELVIN	Ten Zero, Eleven Zero Zero by Zero Two	`Thu Dec 28 1989 19:12`	19
	> Marge, I understand the constraints under which you work. However, > doesn't the fact that the "proper" method of submitting a problem > requires a tutorial say something right away about the process being > out of whack? When a customer problem is being worked on, a certain minimal amount of information is needed (eg, crash dumps, session trace, etc) to start work on the problem. Sure, time could be taken to try to reproduce the problem internally (and does happen at some point along the way). But not all problems are easily reproducible. So, the right information up front can save vast amounts of time in tracking down problems. Some customers do need a 'tutorial' about how to submit a problem. RSX once got a customer problem that read simply: "My system crashes. Why?". No attachements, no further information, no crash dump. Nothing. That is not a problem with process but with information content. From working on CLDs, I have found that by the time I see them, good basic information IS available and has proven very valuable in resolving the problem in a timely fashion. -Joe
991.22		SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 19:21`	7
	re .20: Perhaps, Dave. Normally, it's just a matter of pointing them toward someone locally who has been thru it all before. grins, Marge
991.23		SCARY::M_DAVIS	Marge Davis Hallyburton	`Thu Dec 28 1989 19:23`	4
	Soooo, now that I've spoken my piece on CLD process, is there anyone who knows about ASSETS who can help .0 Greg? mdh
991.24	Know how to turn a NO into a YES	MANFAC::GREENLAW	Your ASSETS at work	`Thu Dec 28 1989 19:47`	43
	RE: .15 and .17 I agree that the problem needs to be fixed BUT is the person being called able to fix it or know enough to fix it. Most of the time the answer is NO. As someone who has been on both sides of the fence at other companies, I have some idea of what is going on. However, assuming that .0 had contacted someone who couldhelp, let's look at solutions to the problems. Confrontation in an ugly word but when I have trouble getting a correct response, I ask for that person's supervisor. Assuming that you have the right person, if you are not getting what you need from that person, generally it is because they have been instructed to not give that help. ASK for the manager. If they will not help then ASK for their manager. Why do people jump when customers call KO? It's because he will find someone to fix the problem and roadblocks are not allowed. So in the first case, if the engineer is saying that they are not allowed to talk with customers, ask for their manager. (As you can see from my personal name, I work for ASSETS and we do not take direct calls from customers BUT I have participated in customer demos and have talked directly with customers. All it took was convincing my manager that it was necessary.) If your problem and your needs do not persuade them to help, then that is a different issue. Also they may ask if you have tried the correct channels. It is part of your job to know the correct channels. As Marge said, there are people funded to help resolve problems. I am funded to support the field concerning Manufacturing ASSETS. Ask me about an Office ASSETS package and I will direct you to the folks in Charlotte, N.C. If they are not available, you can not expect me to know something that is not in my area of expertise. That does not mean that I wouldn't try to answer the questions but that a correct answer would be the exception not the rule. The shipping of hardware slipping five times sounds like a problem that needed to be escalated after the second time! What was .0's manager doing about this situation. One of the first things I was taught when I was a supervisor was that my main job was to solve problems that caused my people not to be able to do their jobs. This means knowing both what they were doing and what they couldn't do. Again, if you are not getting the answers that are needed, ask for the person who can give you the answers or ask your manager to help. My $.02 Lee G.
991.25	ASSETS is hopefully taken care of	SHALOT::LAMPSON	Never Bless a Banshee	`Thu Dec 28 1989 20:21`	50
	Re: .23 > Soooo, now that I've spoken my piece on CLD process, is there anyone > who knows about ASSETS who can help .0 Greg? Whew! So glad someone remembered .0 after all that's occured since. Instead of writing my opinions of the whole process here, I instead wrote to Greg directly with information on ASSETS. In short, I said that the ASSETS hotline, DTN 223-5911, is the single contact point for ASSETS. It is also the CSC for ASSETS and transfers calls to the appropriate support group and doesn't answer them directly (Office ASSETS is in Charlotte, NC, for example). There is also an ASSETS CLD mechanism which I didn't mention as I wrote to Greg before all this discussion on CLD's, etc. Also, each ASSETS library has a notesfile, a direct VAX Mail address and a support manager. Additionally, PASSes (1 of 2 forms of ASSETS packages) have product managers and independent support files. Also, the ASSETS Program as a whole has a notesfile which contains the information I've stated above. So, there is a wealth of information out there. The really hard part is knowing where to find it. This is true all over Digital. If any person can call any other person at any time to get help on a product, we're going to have the "corporate anarchy" which was mentioned in some other topic. No one is going to meet their goals and Digital loses track of reported problems and other important information such as the amount of support needed for various products. This is important so that we have FUNDED support organizations which have the product knowledge needed to satisfy our customers. In short, use the channels. They exist, but you may need to look for them. In calling an engineer directly, you're risking our business by not having problems formally reported (which typically implies they'll never get fixed) and receiving mis-information. After all, an engineer's performance (and salary) are graded on his engineering work, not how well he/she supported the field. _Mike P.S. This is reality in my eyes, not necessary my personal view of engineering. I always answer unsoliticed enquiries as best as possible -- TIME PERMITTING. This is why I perfer helping via mail and notes vs. the phone as the phone interrupts my current work, while mail and notes is handled on a time-available basis. That's why I often answer phone calls with "you should really contact ...".
991.26	Don't lay this one at local mgmt's feet.	SALMON::SCOTTG	Greg Scott, Minneapolis SWS	`Thu Dec 28 1989 21:21`	47
	re .<a bunch> Lots of replies are harsh on our local management. This is incorrect. It is because of our local management we found somebody. After finding that the proper channels - as best as we could figure out - didn't work, we immediately elevated the situation in writing to our local Sales management. That was on a Thursday. By Friday AM, I got a call from a fellow SWS person in Milwaukee, who happened to read the memo, which had been forwarded a bunch of times starting with our local Sales management. By Friday PM, he was on the phone in a conference call with the sales rep and the contact at Mayo Clinic. So our informal channels, because of our local management, worked better then the official channels. On the shipping issue, that's been elevated up the chain too. But, what can you do about it locally besides bitch and make people from somewhere in New England mad? Another little tid-bit we learned. It seems manufacturing is measured in a 5 day window. That means, say if the ship date they give is the 15th of the month, if "it" ships anywhere between the 10th and the 20th of the month, they are considered on time. Sort of makes it difficult to schedule the electrical contractor and DEC Customer Service to be onsite at the same time. In our case, this is really maddening because every day our customer must buy time from the CDC machine, there are that many fewer dollars in their budget for DEC products and services. This customer's budgets are done on a 5 year cycle, and this is year one. For budgeting purposes, the next shot is 1994. BTW, the Sales rep and her management chain has raised a lot of hell, and now most of the stuff did ship. One funny note here, it seems we asked mfg to do a partial shipment of what they could do. So they shipped the MV3800, but did not ship the software media and doc. It seems they thought that all the software should belong with a VAXstation 3100 model 48, and not the boot server MV3800, so they held up shipping the software until some time in January, which is when the VAXstation will ship. And a big part of the reason the customer ordered the VS3100 model 48 - instead of another model 38 - in the first place was, we were told they could be shipped fast. Well, now the MV3800 is there, and we're still waiting on the model 48 and software. Yes, we've made other creative arrangements for software. You've just gotta laugh. - Greg Scott
991.27		KYOA::MIANO	Mad Mike's Mythical Miracle	`Thu Dec 28 1989 22:16`	14
	The frustrating thing is that there is not a single place a customer can go and get there problem solved. One should not have to go through escalation procedures such as CLDs to get things fixed. One thing that customers have told me is that it often seems that the support organization is more concerned with closing calls than solving their problem. (I wonder why?) It is not uncommon for a customer to have gone through several support people who are not equiped to solve the problem, as few PSS people who where just bodies thrown at the situation, and their problem is nowhere near over. When you tell them we are now going to do a CLD or any other form of escalation they are just going to laugh at you. John
991.28	hot topic	NSSG::ROSENBAUM		`Thu Dec 28 1989 23:05`	3
	27 replies and the day's not yet over..
991.29	Who pays YOUR paycheck?	REGENT::GETTYS	Bob Gettys N1BRM 235-8285	`Fri Dec 29 1989 00:28`	19
	First of all I'm going to say it is NOT in my JOB DESCRIPTION to solve a customers problem; but....... As a practical matter, that customer DOES pay my paycheck! Therefore I attempt to quickly and sufficiently answer the problem when it is presented. Only if it going to take a significant amount of time, do I "balk" and then only to get the right priorities set by my management and get it coordinated so that I don't get either my neck, or my bosses neck in a sling! One thing that we should all remeber - THE ONLY REASON WE EXIST IS TO SERVE THE CUSTOMER!! I do agree (as said above) that we need to keep from failing in our primary job too. But this can be done without ignoring the customer. /s/ Bob VIPS Design Engineer
991.30		LESLIE::LESLIE	Andy - on vacation until 9th January	`Fri Dec 29 1989 07:47`	18
	Our customers may be best served by those paid to produce software, doing so. Equallly, those paid to support and sell what we produce, can best serve our customers by supporting and selling the products. It is especially unfortunate that we are increasingly reliant upon personal networks to get information to do our jobs. I believe that DEC is fundamentally flawed right now in the way that we sell and support our products. Like Marge, I've worked in the field and now am responsible for CLD's in a particular area (OSI Comm.). As a result of the former, I have extremem sympathy with those going through hell with the customer, as well as the customer themselves, but when dealing with the latter, I try to ask the right questions of the right people at the right time. To do otherwise is jsut foolish.
991.31	Maybe things can work better.	INFACT::GREENBERG	Wendy Greenberg	`Fri Dec 29 1989 14:24`	50
	> It is especially unfortunate that we are increasingly reliant upon > personal networks to get information to do our jobs. I believe that DEC > is fundamentally flawed right now in the way that we sell and support > our products. I agree very strongly in using the system instead of working around it, however from what I have seen it is at least a common PERCEPTION in the field that the system doesn't work. I believe that some of this is related to actual experiences of trying to go through proper channels. Some of the frustration with going through proper channels may be inevitable because in the field I have to face the customer every single day, face to face and answer for every DIGITAL related problem whether is has anything to do with my job or not. While two weeks may not seem like such a long time to resolve a problem, it is if you are a customer losing money or a DIGITAL employee that has to face that customer everyday. So while I see that problems with going around the system, I see the motivation for doing it. I think there are a couple questions that should be answered relative to this: 1. Do people in the field know all the proper channels? We get lots and lots of information from different sources. I am in a PSS "delivery" unit and you can jump all over me if you want, but neither I nor my manager ever heard of a CLD. 2. Does the system work as well as it should? How come I can order from "MAC-CONNECTION" today and get it tomorrow and yet our customers have to wait a long time, frequently getting hardware before necessary software and have a terrible time trying to track it down. 3. Can the system keep up? If going through channels is slow, what's going to happen when everyone starts doing it. Yes, I know that going around it bogs down the system sometimes, but not always - e.g. the original noter got his answer from another user not from the proper channels. Also a lot of problems aren't even escalated, customers are just told "thats the way things are". I dont mean just to be critical, but I do think we could improve in terms of meeting commitments to customers and I think it would have a tremendous payoff. Wendy
991.32	A software success story	WORDY::JONG	Steve Jong/NaC Pubs	`Fri Dec 29 1989 18:17`	18
	Re: [.31] (Wendy Greenberg]: >> 2. Does the system work as well as it should? How come I can >> order from "MAC-CONNECTION" today and get it tomorrow and yet >> our customers have to wait a long time, frequently getting >> hardware before necessary software and have a terrible >> time trying to track it down. I can't let this pass without comment. I ordered software from MacConnection on the afternoon of December 26, and it arrived at my front door, via United Parcel Service, before 9 AM on the 27th. This software direct-sales outfit has just about taken the whole Macintosh market away from its competition with performance like that. They seem to want my business and everyone else's, and they act as if every little transaction makes them money, and so they want to make as many transactions as fast as they possibly can.
991.33	Classic reply of the 80's	CALL::SWEENEY	International House of Workstations	`Fri Dec 29 1989 23:21`	22
	I think I've been saying this every year in one VAX Notes Conference or another since 1983 and it echos Tom Peters "In Search of Excellence" Service, the level of service, the quality of service, etc. should be defined by the customer. If customers want Digital to guarantee delivery of software in 48 hours, then we ought to do it and there's no excuses for not doing it. There are people in Digital whose job it is to tell customers why Digital can't deliver the level of quality in products and services they demand. When it comes to simple things such as keeping one good salesperson on an account for more than a year, we've got "internal" excuses for not doing what the customer wants. Everywhere one turns in Digital someone's doing something the customer doesn't want done or making up an excuse for why we can't do what the customer wants. Patrick Sweeney
991.34	Juggling sales $'s?	ALOS01::MULLER	Fred Muller	`Sat Dec 30 1989 14:01`	13
	>When it comes to simple things such as keeping one good salesperson on >an account for more than a year, we've got "internal" excuses for not >doing what the customer wants. From a different perspecive: I'm a ten year PSS'r and have seen the saleperson shuffle often. I've often wondered IF I were a salesperson being juggled around, how in the world could I perform against $ quotas? I just found out about a $600K order from a former customer site resulting from a sales cycle of at least 3 years. The listed salesperson was not the one I expected because of a juggling of sales reps. Is the pie sliced up in some way? Fred
991.35	External Escalation always works...	CGOA01::DTHOMPSON	Don, of Don's ACT	`Sat Dec 30 1989 14:13`	76
	Re: Fast Delivery... This is a four-year-old story, so it is possible things have improved. I was once a customer. In education. We have several GiGi's, and our own PC/Terminal servicing people. We requested some available hardware documentation on the GiGi from DECdirect. The essence of the call went something like this... Cust> Identify ourselves and request part number [whatever]. DECd> That part is not stocked in Canada, it will be 1-3 months delivery. Cust> Is there no way we can get it faster? DECd> No. Cust> Ok, how much is it? DECd> $35 Cust> Ok, can we order one, please. DECd> I'm sorry, but the minimum order is $50. Cust> We buy lots of stuff from you. Make an exception. DECd> I can't do that. Why don't you wait until you want something else and order it then? Cust> We need it ASAP. Why don't YOU wait 'til I order something else and bill me then? DECd> We can't do that. Cust> Can I speak to your manager... The story is just like dealing with the phone company... each level up gets briefed by his/her report and then gives you the same answer, so, experienced customer that I was... Cust> Who is the absolute boss of DECdirect in this country? DECd [a manager by now]> Name. Cust> Thank you. We call <Name> Cust> Here is my story... Can you help? Name> I'm sorry. We must do business that way. Cust> OCC [pet name for the 'Other Computer Company'] doesn't hassle me like this. Please help. Name> Sorry, there's nothing I can do. [We were prepared...] Cust> Ok. I am booked on the following flights, (itinerary to Boston), and have the following tickets in my hands at this time (listing of real ticket numbers). I will arrive at Mr. Olsen's office at about... I will not leave without my technical documentation. If he tries to kick me out I'll put it in the newspapers. Name> May I call you back? Cust> Sure, you have two hours. (about 15 minutes go by...) Name> Your documentation has been copied and is on its way by... Cust> Thanks. The moral of the story... Digital, like the government and the phone company, can best be manipulated from outside. What .0 might have done to help his cause is to get as high a person as possible at the customer's to call Mr. Olsen. What gets accomplished by such radical action? - The customer gets the answers needed in a short time - The 'system' gets jiggled - either the response mechanism wasn't working, or - the field people were unaware of how to use it. - The next customer doesn't have such a problem - The original customer - who, BTW, knows damn well Digital is hard to do business with - knows his local Digits are on his side. Besides, I love a righteous crusade... Don
991.36	The customer is the most important person	CALL::SWEENEY	International House of Workstations	`Sat Dec 30 1989 18:01`	28
	Don, You were on the right track, too many people are reading from policy manuals that reflect someone desire for internal controls, internal consistency, internal convenience. The gap between the people who answer phones and have direct customer contact and "policy makers" is in the absolute sense too large, and for the relative size of Digital absurdly too large. You then fell into the trap: Ken Olsen is less important that the customer who buys a $10 cable. He always was and always will be. Employees who fear Ken Olsen or someone on his staff more than they fear the dissatisfaction of a customer are employees that have a serious need for attitude readjustment. We've never had a customer-oriented culture. Don't kid anyone about that. On the occaisions where customer satisfaction is measured, well, we have a management-oriented culture where a customer satisfaction number is obtained. You might call this fear-of-management-oriented. When people who "break the rules/change the rules" to increase customer satisfaction are acknowledged, then I'll believe that we're customer-oriented.
991.37		STAR::MFOLEY	Rebel Without a Clue	`Sat Dec 30 1989 23:37`	6
	RE: .36 That mail should be sent to the Involvment folks.. (provided they aren't piled under a ton of red tape) mike
991.38		HANNAH::LEICHTERJ	Jerry Leichter	`Sun Dec 31 1989 11:07`	95
	Oldie by goldie. Note the date on the memo - this problem is hardly new. [Moderators: Yes, I know about the policies concerning posting mail messages in notesfiles. This message was written and sent into wide distribution - the distributino list on my copy is 6 or 7 layers deep - 5 years before those policies were proposed.] -- Jerry I N T E R O F F I C E M E M O R A N D U M Memo: [45815.4153467.MCCABE ] Date: Wed 25-APR-1984 11:32 From: Kevin McCabe Dept: BOSA/All-In-1 Tel: DTN 264-2216 Subject: Engineering as a Career Senior Development Manager - The person responsible for making sure that DEC does not interfere with the group's long range plans by doing such things as cutting the budget, or changing the project direction by suggesting that the group do something profitable. This is accomplished by keeping the outside world from talking to anyone in the group. Development Manager - This person is mainly concerned with spending all of the money allocated for activities under their jurisdiction. This is accomplished by keeping the Senior Development Manager from bothering any of the supervisors. Development Supervisor - This person is responsible for convincing the Development Manager that everything is going according to plan. Regardless of what is actually being done, the Supervisor must convince the Development Manager that the development group is working hard toward accomplishing the Development Manager's goals. This is done by keeping the Development Manager from talking to the Project Leaders. Project Leader - This person is responsible for keeping the Development Group's programmers from looking bored. This means that there must be a clear understanding between the group and the project leader that leads the programming staff to believe that they are doing something that they want to do, not fulfilling management goals. This is accomplished by keeping the Development Supervisor from talking to the architect. Architect - This person is a frustrated future Ph.D candidate who would like to implement the world's most wonderful software engineering thesis while still getting paid a high salary. In order to accomplish this goal the architect must prevent the Project Leader from talking to the developers. Software Developer - The goal of this person is to implement a meta-pascal compiler, regardless of what else anyone expects. This is accomplished by writing one and disguising it as something else (a command language, a batch input processor, a run time library parsing routine, a 4th generation language, Artificial Intelligence, a natural language parser, a Data Base Management Query system, a programmable editor, a hardware independent Graphics Kernel, a network protocol, a Bliss compiler ....). By definition Software Developers will simply avoid listening to anyone. In addition to these direct responsibilities, there are other related activities that are necessary for any software engineering effort to take place. Product Manger - The purpose of the Product Manager is to convince everyone that regardless of what the development group makes, someone will buy it. This is accomplished by talking to everyone, without really telling anyone anything. Program Manager - This person is responsible for convincing everyone in DEC that they are doing something wrong. This provides justification for anything that the development group might do, since someone is always available to blame. This is accomplished by not listening to anyone. Quality Assurance Manager - This person is responsible for making sure that the support manager remains employed. This is accomplished by listening to the Product Manager. Support Manager - This person is responsible for insuring that the development group will continue to be funded, while they work out the details for their next meta-pascal compiler. This is accomplished by listening to customers, without actually hearing anything. Release Engineer - This person is responsible for insuring that SDC has the latest copy of whatever the customer thinks that the group is making. This is accomplished by magic. No one has yet figured out exactly how to tell the SDC anything. SDC Planner - This person is responsible for getting the customer a copy of what they ordered. Since this is rarely accomplished, I will not venture a guess as to how it is done. CSSE Representative - This person is responsible for insuring that everyone connected with the project has someone to swear at. They accomplish this by listening to everything, and telling everyone. There is, of course, an alternative. However, I can not as yet explain how anarchy (a much more productive structure) would fit into an org chart.
991.39	Perhaps this will help, perhaps not	CAMRY::DCOX		`Sun Dec 31 1989 13:10`	61
	For what it's worth...... I don't know about ASSETS, but I can offer advice on other products. I am a Hardware Product Management Manager (love those new job deescriptions) in CSS. I "own" both Hardware and Software (so much for the job title) products in all phases of development (Including Phase 5). My name is in the Option Module List (often referred to as the Dick Best List) for ALL my products. As the Product Manager, I am responsible for ALL aspects of that product; revenue, warranty, and customer satisfaction. Often, I get calls from the field for two problems; pre-sales support and post sales problem resolution. I assure you that I am VERY interested in providing pre-sales support since that has a direct bearing on my porduct's revenue. However, you need to keep in mind that pre-sales support MAY not mean joining you in your sales presentations; I hope you can understand that I may need to prioritize my business needs. Each of my products has either an ongoing Product Team or a responsible Sustaining Engineer. When I don't know the answer (too often, lately - too many products), I know who does. I will make sure that the caller knows who on my team to call and then I will PERSONALLY discuss the question with that team member as well; I will follow up with both of them. Post sales support can be a chore. I have learned the hard way that all too many customers do not buy our Field Service support. Although I would like to provide installation and other assistance, that scenario presents two problems. First, Field Service is a revenue generator and any over_the_phone support I or my Sustaining Engineer provide robs Digital of reasonable revenue - this particular stock holder does not feel we should be in the give-away business today. Second, it ties up an engineer when it is not necessary. So, the first question I ask of the Account Manager is, "Has this customer gone through Field Service?" In many cases, the answer is that the customer does not have a Field Service contract. In many cases, the answer is that the Account Manager believes he can get the answer quicker by calling the Product Manager. I welcome the call (keeps me abreast of what is happening with my product), but I refer him to Field Service. Part of my Product Development expense is to train Field Service to respond to problems. I do not intend to short circuit the system right at the beginning. Often Field Service cannot provide the answer in a timely manner. When they cannot, my Sustaining Engineer (who usually knows more about the product than anyone else) gets involved. My experience has been that when this happens (a problem cannot be resolved through Field Service), it has taken less than 2 days for my Sustaining Engineer to get involved. Sometimes doing the "right thing" means that the Account Manager, for any number of VERY good business reasons, just cannot wait to sign the customer up on a Field Service Contract nor wait for the CLD process to work. When that happens, I can pull in my team resources to work on (not necessarily solve) the problem ASAP. As long as I don't keep dipping into the Engineering well too often and as long as the reasons are valid, I can continue to get away with short circuiting the system. So think it out before you call, please. The point is, when all else fails (if you have not done so before that), call the Product Manager. At least for my products... Dave
991.40	Maybe they 'shouldn't' but they 'must'...	CGOO01::DTHOMPSON	Don, of Don's ACT	`Sun Dec 31 1989 15:45`	25
	Re: .36 I agree with you, but... in the 'real world' of Digital, most of management is afraid, not so much of Ken Olsen, but of 'noise'. This is very similar to the government. The point was not that the method used to get something done was the way customers 'should' operate, but is one way they might 'have to' operate to compensate for our collective unwillingness to assist them. On the positive side, it does say as awful lot for Digital's products that customers buy from us in spite of the hassle. The IS Director at my account when I was assigned to one used to say: "We're a VAX shop. That goes without saying. As long as the boys in Boston produce such a superior product, we'll buy it and use it. Your [the account team's] measure of success is where we buy the VAX. If you are successful, we will buy them from you. If not, we'll broker them through the States." We were fortunate (5 Polarstars in '88) and the team was again this year (3 9000's), but it was and is an uphill battle. INSIDE!!! The external sell is relatively easy. Don
991.41	Stay away from ASSETS!	POCUS::KOZAKIEWICZ	Shoes for industry	`Sun Dec 31 1989 18:34`	57
	re: .0 Actually, you share part of the blame for your problems by trying to sell an ASSETS package to begin with. Ha! Just kidding. (Not really!) For those that don't know, ASSETS are software packages that were originally developed as internal tools (read: hacks) or as custom applications for customers. The idea is that these things are of nominal interest to customers who have might have problems which could be solved easily by reusing someone elses software. The way you are supposed to sell them is the same as a custom software solution, i.e. they must come bundled with a fixed amount of a specialist's time to do the implementation. The software, once installed, is owned by the customer. There is no support or warranty available other than what the customer purchases outright as T&M labor from the local office. On a very superficial level, ASSETS seems like a good idea in that we are leveraging work that is already done and paid for. The customer gets a solution that is cheaper than one they might develop on their own, and we rake in lots of profit by reselling software that, for all intents and purposes, costs us nothing. In the real world, however, things are not so simple. Sometimes I swear the people who dreamed up the ASSETS program are staffers who have NEVER seen a real live customer. Compared to our "real" products, support for these things is essentially nonexistant. Usually it involves getting the specialist who developed the thing initially to give you a call. Of course, he or she is either on-site at another customer by now, or on vacation, or no longer with the company. Some of the packages (those that were developed in Engineering) are somewhat better in this regard, but customers still can't obtain anything resembling support worth paying for. Three scenarios have evolved in my experience with these things: 1. Sales sells one to a customer without setting the expectations properly. This usually manages to piss the customer off, as he can't figure out why DEC would sell such a piece of junk and refuse to stand behind it. 2. Expectations are set properly and the customer, being rational, refuses to buy it. Why would they? There are so many disclaimers that is sounds like we're equivocating - because we are. 3. We give a package away in order to solve a customer satisfaction problem. This one slays me becuase it inevitably leads to scenario 1. Al's first rule of customer management: Giving something to a customer without accepting payment generally results in the customer being more pissed off than they were to begin with. My advice to anyone who cares: stay away from ASSETS! Al
991.42	Conflicting or cooperating groups?	HABS11::MASON	Explaining is not understanding	`Sun Dec 31 1989 19:41`	10
	Not being terribly close to either prompts me to ask: What are the differences (or similarities) between ASSETS and the New Venture Sales organization? My understanding is that the NV organization is to package and sell things originally developed for internal use, which sounds to me like what ASSETS is there for. Gary
991.43	Is anybody up there listening? or even awake?	SCAM::GRADY	tim grady	`Sun Dec 31 1989 20:42`	18
	Great discussion! Hope something can come of this... A few more thoughts on the customer support issues: 1. Nobody in DEC should ever be reprimanded for dropping their 'real' job to help a customer in need. In fact, they should be rewarded. 2. I live with a large customer (GTE) -- got a cubicle on site and everything, for the last three years. Not to ruffle feathers in the food chain, but the CLD/LOR process simply doesn't work well enough. I started out in COG a long time ago, before it was even called that, so I'm very familiar with the procedure - it's time someone took a look at it instead of just defending it. It's broken, at least where software products are concerned. I've seen the process take MONTHS before anything happened to fix a CRITICAL problem. It's a crisis in management. The porch light is on, but there's nobody home.
991.44	Why did I read this on New Year's Eve? :>)	YUPPIE::COLE	Now is the time for ACTION, not proposals!	`Mon Jan 01 1990 00:57`	101
	RE: .41 by POCUS::KOZAKIEWICZ I hope someone from ASSETS reads .41 and answers it more fully, but I MUST correct some gross errors now! > For those that don't know, ASSETS are software packages that were > originally developed as internal tools (read: hacks) or as custom > applications for customers. The idea is that these things are of > nominal interest to customers who have might have problems which could > be solved easily by reusing someone elses software. "Hacks" is hardly the way to describe tools or solutions that have gone through a QA process to see if they really DO belong in customers' hands. Maybe they start out "hacks" but they end up with a QA stamp before release. True, tools don't get the support that packaged application solutions (PASS's) do, but they were never expected to (remember that word "expect"!). > The way you are supposed to sell them is the same as a custom software > solution, i.e. they must come bundled with a fixed amount of a > specialist's time to do the implementation. The software, once > installed, is owned by the customer. There is no support or warranty > available other than what the customer purchases outright as T&M > labor from the local office. A minor wording problem with a MAJOR misconception! DEC "owns" ASSETS packages, tools or PASS's. The SUPPORT of a tool is owned by the customer, and it is shared on a PASS, with DEC taking the lion's share. Just because source code is sent to the customer doesn't mean they "own" it. Check the copyrights on the sources! But your concept of bundled time is basically right; ASSETS is a SERVICE to be done jointly with EIS services of some flavor. > In the real world, however, things are not so simple. Sometimes > I swear the people who dreamed up the ASSETS program are staffers > who have NEVER seen a real live customer. Wrongo! ASSETS was dreamed up BY the field, albeit in different forms over a period of years. It coalesed in Charlotte when the ALL-IN-1 U. S. engineering team found a bunch of applications floating around DEC and isolated customers, and decided that some QC needed to be applied to the process. The US Country funded the ASSETS program start-up with the three application areas (ALL-IN-1, Manuf., Networks/Systems). > ....................................... Compared to our "real" > products, support for these things is essentially nonexistant. Usually > it involves getting the specialist who developed the thing initially > to give you a call. Of course, he or she is either on-site at another > customer by now, or on vacation, or no longer with the company. > Some of the packages (those that were developed in Engineering) > are somewhat better in this regard, but customers still can't obtain > anything resembling support worth paying for. The responsible ASSETS SWS/E office is supposed to accept full responsibility for support of a PASS before it is released. Any contact with the "developer is supposed to have taken place by then. Don't expect (that word again!) to have PASS developers at your beck and call. Expect ,and demand the SWS/E office to support them. As for tools, expect them to be "as is", and if a local specialist can't support it, don't sell it. > Three scenarios have evolved in my experience with these things: > > 1. Sales sells one to a customer without setting the expectations > properly. This usually manages to piss the customer off, as he > can't figure out why DEC would sell such a piece of junk and refuse > to stand behind it. > > 2. Expectations are set properly and the customer, being rational, > refuses to buy it. Why would they? There are so many disclaimers > that is sounds like we're equivocating - because we are. > > 3. We give a package away in order to solve a customer satisfaction > problem. This one slays me becuase it inevitably leads to scenario > 1. Al's first rule of customer management: Giving something to > a customer without accepting payment generally results in the customer > being more pissed off than they were to begin with. Expectations are the key! Both our INTERNAL and our customers'! In the Southern Area, I think we have had reasonably good success with ASSETS, both from a customer sat and profit perspective. When ASSETS went live in '87, our Area Projects Consultant made sure the Districts knew what it was, how to use it, and how NOT to use it. As a District Projects Consultant, I ensure that my USWMs stay up with the program. They KNOW that they own the customer sat and support, and that they own Sales Support. The Florida District has even come up with a "package" service of ASSETS and on-site time for ALL-IN-1 and VAX/VMS that their Sales force has embraced very readily, because everyone has the expectations set properly. As for point 3 - RIGHT ON! If it's of value to the customer, put a price on it, and take it from there! > My advice to anyone who cares: stay away from ASSETS! > > Al OK, and give up possible follow-on business, unloaded margin $$$$, projects with a QA'd starting point, and solving a customer's pesky problem that has already been solved somewhere else. Let's face it, ASSETS may not be perfect, but it HAS worked, IS working, and WILL work. Our success as a services provider demands it.
991.45	No, use Assets properly	KYOA::MIANO	Mad Mike's Mythical Miracle	`Mon Jan 01 1990 03:38`	31
	RE: <<< Note 991.41 by POCUS::KOZAKIEWICZ "Shoes for industry" >>> > -< Stay away from ASSETS! >- You are absolutely correct about the things you have described but I believe you are wrong about Assets in general. Believe me, there is some really great stuff in Assets. How would we live around here without FTSV? That's an Assets package! Have you read stories in the Digital Enquirer about DEC having Remote Procedure Calls (RPCs) some time in the future? If you don't want to wait for Central Engineering and you want to use RPCs and transparent messaging today try the 3D Bus product in Assets. There appear to be two types of packages in Assets. First of all there are the "don't re-invent the wheal" type. These are the type you described and they are sold as time saving devices when we are doing custom work. Unfortunately often in the field we have the "Don't worry about the resources. Just sell it." attitude. If these things are not sold properly then of course we're going to get burned. The second type of package is the almost product. Unfortunately there is an N.I.H. attitute in DEC so there is virtually no chance a tool developed in the field will ever become an "official" Digital product (All-for-nothing is a notable exception). I have seen customers say things like "I can't believe this thing, no other computer company has anything like it yet!" after seeing 3D Bus. I admit that most of Assets is pretty useless for the world in general, but if something is re-used only once or twice it has probably paid itself off. John
991.46		LESLIE::LESLIE		`Mon Jan 01 1990 07:56`	13
991.47	...and we're working to bring that down.	SCARY::M_DAVIS	Marge Davis Hallyburton	`Mon Jan 01 1990 11:58`	16
	re .43: Tim, I hope the CLD process has improved since HOSS ;^). Through very hard work, we've gotten closure in our group down to 19 days average, not 'months'. The clock starts from the time the problem is reported to the corporate CSSE support group, the problem is reproduced, there is either a permanent fix or workaround developed and installed at the customer site, and they have ACCEPTED it. Closure happens when both corporate and the field say, "It's soup". I don't know overall figures, but 19 days average against a goal of 30 is not bad. This is not to say the system cannot be improved. But it's not broken. Marge
991.48	Another reply from the front lines.	INFACT::GARRETT	Curtis W. - Indianapolis	`Mon Jan 01 1990 16:07`	13
	.31 Well its 3 days and 16 replies later. Wendy is in the same unit as I am. She has the desk next to mine. we've worked together several times. I don't know what a CLD is either. It seem noone else knows what it is or how to use it. I agree with Wendy. When you're at a customer site, and charging 80 to 125 dollars per hour, and there is a problem interfering with the customer's business... Well, The customer doesn't give a good G__ D___ about proceedures form or channels. They just want it fixed NOW. And I'm the one that has to face their rath until it is fixed.
991.49	Since we're into confessing...	CGOA01::DTHOMPSON	Don, of Don's ACT	`Mon Jan 01 1990 17:44`	5
	I don't know what CLD means, either. Don
991.50	CLDs and etc.	CSSE32::RHINE	Jack Rhine, Manager, CSSE/VMS Group	`Mon Jan 01 1990 18:48`	24
	CLD stands for Central Log Desk and is a way of elevating REMEDIAL problems to the corporate level (CSSE). CSSE then solves the problem or manages it into engineering. I work in the new product area and do not normally handle CLDs as CLDs for VMS are handled by the CSSE/VMS Support Group (we help out from time to time), but the CLD process was never intended to handle consulting issues. Some of the previous notes indicated that the CLD process has not worked well in the past. The process was originally established for dealing with critical hardware problems. At that time, CSSE did not provide corporate support for software and had to negotiate with other organizations for support of software problems. A great deal has changed since then. The process probably isn't perfect, but as Marge indicated, it has improved considerably. As far as doing work that "aint my job", my groups does plenty and it usually interferes with what we are being measured on. When this type of work comes our way, if we have the knowledge required and it doesn't take a lot of time, we do the work or answer the question. Otherwise, we try to identify the right resource. We also try to ensure that other organizations outside of Customer Services have access to work that we do for Customer Services.
991.51	How many Digital VP's are upset over this?	CALL::SWEENEY	International House of Workstations	`Mon Jan 01 1990 22:10`	16
	It is your job, if you are paid by the customer to solve their problems, to understand the formal channels that exist for problem resolution. The customer can rage and scream at Digital, all too often that rage and scream is passed through Digital from employee to employee without any thought. In fact, the some employees in the field coach the customer on how to maximize that rage and scream. This only reinforces that "helplessness" that the field has complained about for years. Action comes not from a concern that starts with a customer but with "high management visibility". The CLD mechanism is for "non-conformance to the SPD". Poor design, lack of training, poor predictions of performance, etc. are for other mechanisms.
991.52		SUBWAY::KOZAKIEWICZ	Shoes for industry	`Mon Jan 01 1990 22:52`	56
	re: .44 I use both FTSV and VWSlat (or DECtse or whatever it goes by these days). I am aware that they are ASSETS. They both seem to be a. reasonably useful and b. reasonably robust. So why don't we support them as real products? re: .44 It's a product! It's a service! It's two; two; two mints in one! Or, to borrow from a SNL skit: It's a floor wax! No, it's a dessert topping! ... Your reply stands as a testament to why these things are such a headache. Listen to yourself! >True, tools don't get the support that packaged application solutions >(PASS's) do, but they were never expected to >DEC "owns" ASSETS packages, tools or PASS's. The SUPPORT of a tool is owned >by the customer, and it is shared on a PASS, with DEC taking the lion's >share. Just because source code is sent to the customer doesn't mean they >"own" it. [...] ASSETS is a SERVICE to be done jointly with EIS services >of some flavor. >The responsible ASSETS SWS/E office is supposed to accept full >responsibility for support of a PASS before it is released. [...] As >for tools, expect them to be "as is", and if a local specialist can't >support it, don't sell it. Andy is right - the QA on these things is nowhere near the standards of our real products. The support is not through the same channels or of the same caliber as that for our real products. We sell them as a service, but unlike real services, the customer doesn't own the resulting code (and I don't want to hear about standard T&C's - very little business is actually conducted under them and the data rights are the first things to go) but he does own at least some of the support responsibilities. And, most maddening of all, we expect customers to understand the nuances of our organization and business practices in order to purchase them. A customer can objectively identify with a software product. They can do the same (to greater or lesser degrees) with advisory consulting or project services. ASSETS tend to fall into a netherworld that generally defies decsription to a customer insufficiently steeped in DECese. It looks like a product, but we sell it as a fixed-price service with no formal functional spec or warranty (unless it's a PASS and today happens to be Tuesday...). I'm sorry, but I have to stand by my gut reaction. ASSETS looks like something dreamed up by someone who was paying more attention to the bottom line than to the customers. I'd love to hear what Tom Peters would say about ASSETS... Al
991.53	Mac Connection does support, too	BOLT::MINOW	Pere Ubu is coming soon, are you ready?	`Mon Jan 01 1990 23:03`	22
	re: .31, .32 (Mac Connection): This software direct-sales outfit has just about taken the whole Macintosh market away from its competition with performance like that. Price, too -- their mail-order prices are about as low as you can find. They were the pioneers of the $3/package, overnight air anywhere, philosophy. They seem to want my business and everyone else's, and they act as if every little transaction makes them money, and so they want to make as many transactions as fast as they possibly can. If you call them (or their IBM PC twin, PC Connection) with a question about something they sell, they will do their best to answer your question. They do not ask whether you bought the software from them. Amazing how much new business this drums up. There's an article on them in, I think, March 1988 Inc magazine that discusses their philosophy of support. Anybody interested in the realities of customer satisfaction should read the chapter on support in Kawaski's book, The Macintosh Way. Martin.
991.54	My New Years Resolution:	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Tue Jan 02 1990 03:03`	38
	Since I started the topic, I think it is appropriate to make some resolutions. A person sent me some mail and asked me to send .0 to the involvement people, along with my suggestions on how to fix the problem. I can't fix the world's problems. I learned long ago that I can only fix what I can control. So I'll fix the part of the problem I can control. Here are my resolutions, in public, for the whole world to see. Call it them New Year's resolutions, one day late: If you call me and I can help you, I will. If you call me and I'm not there, I will return your call if I can find you. If you call me and I can't help you, I will tell you so and try to find somebody who can help you. And I'll ask you to call me back if you subsequently get jerked around. If I need your help, I will call you. If you point me to the system, I'll try as best as I can to follow the system. If the system doesn't work, I will call you back. If you jerk me around, I will be mad. This one is most important: I will treat you the way I expect you to treat me. I think the overwhelming majority of Digital people have already made these resolutions, long ago. Let's all of us make similar resolutions for 1990 and beyond. re .39, from the Product manager. Thank you. I know you have a tough job even without the ad-hoc field requests. I, and I'm sure lots of other people, really do appreciate your willingness to help when needed. - Greg Scott
991.55	Own your work for life?	ISLNDS::BAHLIN		`Tue Jan 02 1990 13:32`	28
	re: .54 Right on! This should be made into a poster. re: general comments I think that two types of support are being mixed up in this discussion. One is the quicky; pointer to more help, a part number, yes/no answer etc.. The other is extensive help; analyze a crash dump, work arounds for bugs, special configs, etc.. I am sympathetic to the two types requiring radically different types of support and requisite formality. Having said that, .54s new year's resolutions are particularly important. It is usually the 'quicky' support that I find lacking and infuriating. Non returned calls, rudeness, meaningless pointers, and such are the symptoms of 'being jerked around' and if everyone followed Greg's resolutions, much of that aggravation goes away. Also, I think a long term solution is to eliminate a developer or development group thinking of ownership in terms any shorter than the full life of a product. Wherever you go in this company, you (and your current mgr.)should know and plan for some percentage of your time to be dedicated to 'support' of past work. Since the magnitude of that percentage is normally related to the quality of the product development work itself, no one should object to this new accountability.
991.56	In case anyone is interested, ...	YUPPIE::COLE	Now is the time for ACTION, not proposals!	`Tue Jan 02 1990 13:46`	9
	... the ASSETS Program has a conference: BUFFER::ASSETS_PROGRAM and the three different categories do also, although I can't recall the specs for each one. Topics there will be read by people who can do something.
991.57	More pointers to ASSETS Conferences	CVG::THOMPSON	My friends call me Alfred	`Tue Jan 02 1990 14:22`	27
	More pointers to ASSETS Conferences There are in fact quite a few conferences related to the ASSETS program. Here are the ones listed in EASYNOTES.LIS. ASSETS - European Elect. Pub. UTROFF::EEP_ASSETS 1757 ASSETS - European Manufacturing GYPSC::ASSETS-MANUF-EUR 1925 ASSETS - European Office POMPEO::EOASSETS 1399 ASSETS - Manufacturing MANFAC::MASSETS 1805 ASSETS - Network/Comm/Systems HORUS::NASSETS 2383 ASSETS - OFFICE Market OAXTRA::OASSETS 642 ASSETS Network/System Europe CLARID::EUR_NETASSETS 2149 ASSETS Program BUFFER::ASSETS_PROGRAM 1692 BTW, there are quite a few people in this company who do spend quite a bit of time doing things that are not their job. It has been my pleasure to run into quite a few of them over the years. Many of them pay a price for it though because doing the best thing for the Company and doing the best thing for your group do from time to time conflict. So what you do is the best you can at reaching a balance. Often that means you get more efficient. Sometimes if means you lose sleep. Alfred BTW, EASYNOTES.LIS is not anyones job. Seems to get done though. :-)
991.58	Closures: 19, Customer: 0	SCAM::GRADY	tim grady	`Tue Jan 02 1990 15:17`	33
	'got a couple of rebuttals from prior replies... I really DO believe anybody who helps a customer should be rewarded, even if it isn't even remotely their job, and even if it slips a schedule. I did spend three years in SWE, so I'm not just being hypothetical. If the traffic got too heavy, that simply means something else is broken and should be fixed. Customers do come first. Naturally, they ought to be really helping, not just boondoggling. We get in the way of such help too often. I don't believe the CLD process has good end-to-end continuity. Marge, you are certainly right, things are better than they were in the HOSS days, but we've gotten so damn big since then that things fall through the cracks too often. A lot of that appears to be due to the 'not my job' syndrome. I've even run into the occasional misguided soul who believes it's their job to PREVENT the problem from escalating to engineering. Maybe that looks bad, interrupts schedules, or disrupts the natural karma of the universe, I don't know. I don't agree, with it, though. Although I live with a customer, I don't bill for my time -- I'm actually Sales Support, and my only job is to keep my customer happy. In that sense, my job is Customer Satisfaction. It's important to make the customer realize the procedures we use to escalate problems, but I've never needed to coach a customer to act irate or angry. That's the last thing I ever need to do -- our procedures and delays do that themselves. Sounds like we could use a better metric for remedial support other than simple closures. Perhaps input from the local office, or the customer themselves, would provide a better metric of whether the real problem was solved: is the Customer satisfied?
991.59		NITTY::COHEN	What fools these mortals be...	`Tue Jan 02 1990 17:29`	31
	I find it very sad to read the replies that say tell the customer they must go through the never ending maze of channels. Let me pose a question: I am an instructor and I have customer A in a Sys. Mgr. class. Mr. A has a question related to the network. Because he is not in a Network Mgr. class and did not pay for that class should I say I cannot answer your question because "its not my job to answer network questions this week. I am only able to discuss what I am funded for. And your question is not important to that class. I am sorry." As stated before the customer does not care where the answer comes from or what had to happen, inside DEC, to get the answer, only that the answer be correct (the first time) and timely. I talk to customers every week and the three most common statements are: 1) There is no way easy to get correct/fast answers about anything from DIGITAL. 2) When DIGITAL says something we have to check it with our own resources to see if it is true. 3) I cannot get a straight answer about when our stuff will be delivered or what hardware is/will be available. I can tell you the customers are getting extremely PO'ed. We will/have lost $$$$$ because of this. The bottom line is IT IS YOUR JOB. Would you accept any other kind of treatment from your doctor/dentist/car dealer/bank/etc. Or would you find another doctor/dentist/car dealer/bank/etc.. My $.02... tac
991.60		NOSNOW::GEORGE		`Tue Jan 02 1990 18:08`	12
	I worked for several non-computer-industry companies before coming to Digital. This is the first place I've seen this syndrome displayed so consistently by so many. The matrix is the expression of all that's wrong here: especially metrics and management style. We are so specialized (even in non-technical areas) that we can't get out of our own way. Picture this: the instructor in .59 gets in trouble for the answer he gave ONLY if he didn't then try to sell Customer A a "networks class"! We seem to have all the answers for all our customers, but we want to increase revenue by charging the customer for each guess at a "correct" question.
991.61	No, no, no!	WORDY::JONG	Steve Jong/NaC Pubs	`Tue Jan 02 1990 18:56`	21
	Here's a SOAPBOX-style shotgun reply: Re: [.35] (Don Thompson): Your description of a four-year old problem, particularly the tantrum you had to throw as a customer before you got a response from Digital, is nothing short of obscene. The organization you describe sounds mired in bureaucracy, by which I mean my own private definition: an organization that believes its job is NOT to do its job. Re: [.38] (quoting Kevin McCabe): This is funny! But it's also clearly satirical. Unless you wish to identify a specific Digital organization that behaves in this manner, I suggest (and hope) that it is not germane to the discussion. Re: [.41]: I am very uncomfortable with this message ("Stay away from ASSETS!"). It sounds like you're saying, "We know what you want, Mr. and Ms. Customer, and this ain't it." It's like the waiter joke where you order the blintzes and the waiter refuses to take your order because today they're not so good. To my mind, you cannot separate this attitude from corporate arrogance. It is 180 degrees from where we ought to be going.
991.62	maybe too idealistic?	TIXEL::ARNOLD	From purple graphic majesties...	`Tue Jan 02 1990 20:22`	9
	.54> If you call me and I can help you, I will. I love the attitude & sentiment, really. It's the way things should be, working as a team. The only problem here (purely hypothetical, of course) is when your manager stipulates that if your telephone involvement > 90 seconds, then your "proper" response initially should be "sorry, I can't help you". Jon
991.63		RIPPLE::FARLEE_KE	Insufficient Virtual...um...er...	`Tue Jan 02 1990 20:37`	31
	Re: "You should go through channels, and don't bother engineering with your troubles because if I take any time for you, other customers will get PO'd that schedules have slipped": First off: From a field perspective it is not always easy to even identify someone in engineering to ask. You can be sure that before I call you up to get abuse for "going around the system", I have tried every other channel that I know of. If I have not been informed of a support channel (I thought CLD stood for "Career Limiting Decision"), then something's broken. I spend a fair amount of time ferreting out such details and just today found out what CLD stands for. Still dont know the process. Second: If you think its not your job simply because you don't get explicit credit for it, consider this: If customers stop buying your product because nobody in the field can get sufficient info to support it, what job will you have? Re: "CLD is only for non-compliance to SPD..." Are you telling me that if I try to use the CLD channel for a problem which does not meet your guidelines, that you will tell me "its not my job"?? Is this help? Re: ASSETS, we need more education and more care with how they are sold. ASSETS is a powerful program with lots of potential, but I have seen HUGE problems caused by selling a package which looked like a fit on the surface. The package didn't even compile until over a month had been spent with several local folks and the original author. Even then the customer was expecting far more than the package delivered. In the end we gave the customer his money back and ate the consulting time in order to avoid a lawsuit. The salesman is no longer with Digital. Kevin
991.64	Also sprach Network ASSETS	NWACES::ROHNERT		`Tue Jan 02 1990 20:40`	51
	Re: .0 Another perspective to the problem in 991.0 by The Corporate Network/ Communication/Systems ASSETS Library in Hudson, NH. I spent much of today reviewing the sixty one responses to your note as well as our response to your problem. The ASSETS package was LTM-Reports, Release 1.1. This package was developed by Software Services Engineering for distribution by ASSETS. It is our most popular package and has been in the library since January 1988. On December 14 you called the project leader for LTM-Reports and asked him if he would call your customer and answer any questions your customer might have about LTM-Reports. He said he could not talk to directly to customers and told you to call ASSETS at DTN 223-5911 which you did. (Ref. Log 89348A020 @16:01EST) You spoke to Hugh Mercer of Network ASSETS and asked him to call the customer to answer any questions they might have. Hugh suggested that you request the LTM-Reports documentation via VTX, read the documentation and if your customer had specific questions to call us. Hugh also mentioned that you could deliver these documents to your customer and we would be pleased to answer any questions remaining. I notice that you did request the documentation kit on December 14, and a copy command file was sent to ANGLIN::SCOTTG. This package contains a PASSD (similar to an SPD), Release Notes, Installation Guide and a User's Manual. In addition, LTM-Reports documentation contains a Delivery Guide (Internal Use) to help you to qualify, sell and train the customer as well as a complete set of overheads for your technical presentation. An excellent package, fully supported, to sell to your customer, 100% PSS revenue at no charge to your Cost Center. We did not say, "Hey man, it's not my job", because even though our charter says we are not to talk to customers, we will do everything we have to above un-natural acts (but sometimes those too) to support you in the field. If a customer called anyone in our library with a question, we would answer the question, get the customer name and address and turn the name over to Carol Armistead in U.S. Country for closure. If ASSETS does worldwide pre-sales we are going to have three geography managers on our case for interrupting their revenue streams. Besides if we do pre-sales, orientations, installations, and warranty, someone will have to move to beautiful Hudson New Hampshire to do our job. Best Regards, Dick Rohnert Corporate Network ASSETS Library
991.65	Matrix Mismanagement.	SCAM::GRADY	tim grady	`Tue Jan 02 1990 20:41`	21
	Re: .-1 Too idealistic? What's wrong with this picture? Alot of these cynical scenarios of Customer Support gone awry are EXTREMELY familiar. It's even scarier that they come from every corner of the field (geographically and organizationally). There still isn't anything in place to guarantee quality of customer support in the field, and no sign from management that anyone cares beyond hollow lip service. For God's sake, don't even mention the surveys! I have a friend who runs a small MicroVAX site, and has been negotiating with our Hardware Support Contracts people for over six months to determine just what hardware is there, and how much maintenance fees should be. Six months. We have the dubious honor of having the hardest working Customers in the computer business.
991.66		SCARY::M_DAVIS	Marge Davis Hallyburton	`Tue Jan 02 1990 23:57`	31
	re .63: Kevin, CLDs are most often used for "non-compliance" issues. That doesn't mean that they cannot be used for other issues that have a major impact on a customer's ability to use a DEC product. It wont help you get systems delivered on time or get a benchmark done, however. It's remedial support with the end result generally a workaround with "fixed in next release" or a patch. What distinguishes a CLD from an SPR/TIME case is that the customer is seriously impaired by the problem and a CLD provides the timeliest response to the customer from corporate Customer Service, working closely with Engineering. As for process, CLDs are generally initiated by the CSC (Customer Support Center) sending an LOR (Local Office Referral) to the local area and then the local area's Customer Service folks opening a CLD. However, I heard recently that an LOR may no longer be necessary as an interim step, that the CSCs may be able to open a CLD to corporate support directly. They still require a local Customer Service manager's name to be listed, however. The corporate support group within CSSE will work directly with the local Customer Service problem manager and tecchy (often the onsite EIS consultant) to resolve the customer's problem and WHEN the customer is satisfied, then the local office will send notification to CSSE to close the CLD. The process is both product and customer-oriented. It's not perfect, but it's not bad. There are enforced communication lines; the major problem I see is that the CSC that initiated the silly thing rarely hears the outcome. Marge
991.68	re .64 - I was there.	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Wed Jan 03 1990 02:47`	160
	Re: .64 When I put in .0, my purpose was not to name names or finger out any particular group. You see it from your perspective, I see it from mine. I was there, and, I must tell you, I felt like I was jerked around every which way but Sunday. Your facts are mostly correct, with a few exceptions. > On December 14 you called the project leader for LTM-Reports and asked him > if he would call your customer and answer any questions your customer might > have about LTM-Reports. He said he could not talk to directly to customers > and told you to call ASSETS at DTN 223-5911 which you did. > (Ref. Log 89348A020 @16:01EST) That't not quite the way it happened. On Dec 14, one of my Sales reps asked me to help her find somebody to talk to her customer about an ASSET product called LTM-REPORTS. The customer was interested in talking to somebody who had actually used the product and wanted to ask a few basic questions. We looked thru the LTM_REPORTS notesfile and found a guy who seemed really competent with the product. And, to my pleasant surprise, it was a guy I used to work with. I didn't know his title, or his manager, or what group he works for, or any of that. All I knew was, here was what appeared to be the most qualified person to help us out for a few minutes. So I called him. He pointed me to VTX and told me about the menu selections to get to what I wanted. I thanked him and told him we would take it from there. So we spent an hour or so going thru the VTX stuff. It takes 20 minutes or so to copy each menu selection from VTX. Remember, we are on the far end of the network. We went thru all the VTX stuff we could find on the screen and read it as best as we could. It seemed to lead us to a dead end. By now, it was late afternoon and we had a customer who, we thought, wanted to buy the product on the spot. So we ended up talking to this guy again. Here's the conversation as best as I can remember it: "We've gone thru the VTX stuff as best as we can, and we can't find a contact. Can you just talk to the customer for a few minutes for us?" "No, it's not my job to talk to customers. You need to follow the channels." "We've tried the channels as best as we can, and we can't get anywhere. I know it's not your job and all, but can you just help us out for a few minutes?" "This is what you need to do: read the procedures, understand them, and follow them. Don't try and go around the system." "Well, that's great but the directions don't point us to any contact. Who the hell do we call with questions? All I need is a contact to talk to our customer." "Hang on a minute.......You call DTN 223-5911 and tell them it's an ASSET package." "Thanks" "Bye......<click>" (I have a hunch we both had some kind words for eachother after the phones hung up.) > You spoke to Hugh Mercer of Network ASSETS and asked him to call the > customer to answer any questions they might have. Hugh suggested that > you request the LTM-Reports documentation via VTX, read the documentation > and if your customer had specific questions to call us. Hugh also > mentioned that you could deliver these documents to your customer and we > would be pleased to answer any questions remaining. I notice that you did > request the documentation kit on December 14, and a copy command file > was sent to ANGLIN::SCOTTG. This package contains a PASSD (similar to an > SPD), Release Notes, Installation Guide and a User's Manual. In addition, > LTM-Reports documentation contains a Delivery Guide (Internal Use) to help > you to qualify, sell and train the customer as well as a complete set of > overheads for your technical presentation. An excellent package, fully > supported, to sell to your customer, 100% PSS revenue at no charge to your > Cost Center. That is pertially correct, but missing a few details: After my conversation unsuccessfully begging for help, I called DTN 223-5911. The first words I heard were, "Corporate support...please hold....<click and silence>" After what seemed like an eternity - really 4 or 5 minutes by my watch - the person came back on the line and directed me to somebody named Hugh. Hugh was as helpful as he could be - I asked him to talk to our customer, but Hugh indicated he was also not technically familiar with this product. Hugh told me he would try to find us somebody, and indicated the name of a person who might be able to help. Unfortunately, that person was the same guy who had just sent us away. I told Hugh not to bother with that person because he had just directed us at Hugh. Hugh indicated he would look for somebody else. Now don't take the following comment personally, but to this day, we have not heard back from anybody on this call. You have the log number - check it out and I'll bet the call was closed long ago. If I'm wrong and the call is still open, go ahead and close it. We used informal channels and found somebody to help us. Somewhere in the conversation, Hugh also pointed us to the online documentation and some VTX voodoo to get it. I started the copy operation at the end of the day that day, and here is the directory of what we got the next morning: Directory $1$DJA1:[SCOTT.LTM_REPORTS] LTMREPORTS011.RELEASE_NOTES;1 100 LTMREPORTS011_DG.LN03;1 538 LTMREPORTS011_IG.LN03;1 330 LTMREPORTS011_OH.LN03;1 824 LTMREPORTS011_PASSD.LN03;1 122 LTMREPORTS011_UM.LN03;1 1572 LTM_DIR.TMP;1 0 (That is this directly listing - doesn't count.) Total of 7 files, 3486 blocks. Even with sixel and formatting stuff, how long would it take you to print and read this documentation? And then, after reading the documentation, how long would it take you to become familiar with the product? And, then, having never used the product, how competent would you be to answer any questions? And, if you were a customer, how inclined would you be to buy from a company that sent you a pile of manuals and told you to read them? We asked for a few minutes of somebody's time, on the phone, to answer a few questions. We didn't ask for any technical presentation, we didn't ask for or expect any follow up. Having spent several years in a support role, I know very well how those "few minutes" add up. It happens to me every day - that's why I'm sitting here in the middle of the night doing this. If I don't respect your time then tell me to get lost or bitch at my management. But please don't jerk me around when I legitimately need your help. > We did not say, "Hey man, it's not my job", . . . That is correct. In fact, you said, "It's not my job to talk to customers." And you said it more than once. - Greg Scott
991.69		POCUS::KOZAKIEWICZ	Shoes for industry	`Wed Jan 03 1990 11:27`	27
	re: .61 (Jong) I suggest you reread .41 and subsequent replies. It is VERY pro-customer stance I propose, not anti-customer as you suggest. If a customer were to come to me and say "Gee Mr. Digital, I'd like you to sell me some code to solve this here business problem. I don't want it to be one of your standard supported software products. I'd like it to be something that neither you, the local office, nor I engineered, and I want to make sure that when I take possesion of it I will not own the code and that I'll have to pay for less than first class support." And I'll say, "Sure, how about one of these here ASSETS?" To me, it's binary. We sell solutions comprised of supported standard products, custom or packaged services or a combination of the two. ASSETS are a blend of services and non-standard product. I contend that we are not equipped as an organization to deal with this mixture in such a way as to ensure quality solutions and highly satisified customers. If we can't deliver both virtually ALL of the time, we should just say no until we can. I have yet to be shown the benefit TO CUSTOMERS of pro-actively peddling ASSETS. Al
991.70	ASSETS resources available to you	BUFFER::DILL		`Wed Jan 03 1990 14:42`	111
	Greg, It is most unfortunate that the right connections were not made in a timely manner. I hope that my phone call to you last week in addition to the information in this note will renew your enthusiasm in using ASSETS packages. Please don't hesitate to call me if you have further questions. Jane Dill Corporate ASSETS Marketing Manager DTN 276-8278 There are several avenues you can choose when searching for more information about ASSETS. SAIL - For a quick overview of the packages in the Libraries, this online infobase gives a one-page description of the function and benefits of all PASSes and select Solution Tools. (This would probably have satisfied your "quick need to know" and is an easy alternative to the documentation request through ALS). Notes Files - There are notes files set up for the Libraries, worldwide. These are regularly monitored and are a good place to go for package and Library specific information. Market/Area___________Notes_File____________Contact_Node__________ Corporate ASSETS BUFFER::ASSETS_ BUFFER::ASSETS Program Office PROGRAM Corporate OAXTRA::OASSETS OAXTRA::MAINTAINER Office/Publishing/BusiOAXTRA::A1SFCP OAXTRA::A1SES Corporate HORUS::NASSETS HORUS::MAINTAINER Network/Communications/Systems Corporate MANFAC::MAINTAINER Manufacturing/Engineering/Scientific MANFAC::MASSETS European POMPEO::EOASSETS POMPEO::MAINTAINER Business/Office Information Systems (B/OIS) European CALIFE::EUR_ CALIFE::MAINTAINER Network/Systems/TransaNETASSETS Processing (TP) /Artificial Intelligence (AI) European GYPSC::ASSETS-MANUF- MANUF::MAINTAINER Manufacturing/TechnicaEUR Applications (TA) GIA Program Manager AKOV12::BURKLEY Rodger Burkley GIA Marketing AKOV13::CLOUTHER Manager Steve Clouther Canada KA0SWS::CDN_ASSETS KAOSWS::MAINTAINER Far East HGOV07::PETERCTWONG Latin LACV01::CLAUDE America/Central Region Japan TKOV50:SHIRATSUKI South Pacific Region BERAQ::SPR_LOCAL_ BERAQ::MAINTAINER ASSETS United States CARTUN::ARMISTEAD Program Manager Carol_Armistead___________________________________________________
991.71	My $.02: What can be done?	SSDEVO::YESSE	Computing at 6200 ft.	`Wed Jan 03 1990 15:44`	19
	This may deviate a bit off the main topic, but from my viewpoint in engineering, I'd like to see two databases available for corporate use (these may have been alluded to in other notes): 1) Who-Does-What in DEC. Enter 1 or more keywords on a tool, program, etc., and up pops the names of the person(s) currently providing support (with easynet addresses & other pertinent data). 2) How-To-Do-That in DEC. Again, using appropriate keywords, find out how a specific task is done in the corporate labyrinth. I've spent more time poking around, trying to find out the right people to contact & the right tasks to accomplish in the right order, than the time spent actually doing the job. Reality, of course, may be something else (issues of security, maintenance, etc.). Maybe these already exist in some form I'm unaware of...but it appears the company needs methods of streamlining the way we work as "one company". Keith Y.
991.72	Sorry, but that's arrogance	WORDY::JONG	Steve Jong/NaC Pubs	`Wed Jan 03 1990 15:57`	26
	Mr. Kozakiewicz, you seem to have formed an uncomplimentary opinion of ASSETS. I have no experience whatever with the program, so I have no opinion as to its suitability for customers. Understand, then, that I'm reacting to the music I hear, not the words. What I hear you saying is, "ASSETS is a collection of sub-standard offerings. Informed customers stay away from it. If a customer asks for an ASSETS product, talk him out of it." Is that a fair paraphrase? I think there is a very fine line between understanding what a customer wants (and skillfully shaping that desire toward your products) and deciding for the customer what he does or doesn't want. It doesn't seem that the ASSETS program has any mechanism for determining "what customers really want;" it's just a clearing-house, equipped to take orders, not answer--or ask--questions. (Is that right?) If you can't ask an ASSETS customer what he wants, then you're making presumptions; in your case, that the customer is making some sort of mistake to order. That, to me, is arrogance. I hope your opinion of ASSETS is wrong, but I can't say. If it's right, though, there is a separate problem. If we are offering for sale products that customers wouldn't or don't want once they learn about all the strings attached (limited support, uncertain origin, limited license, etc.), and we are, or ought to be, steering customers to regular software, then ASSETS is, by definition, a bait-and-switch operation.
991.73		KYOA::MIANO	Mad Mike's Mythical Miracle	`Wed Jan 03 1990 19:32`	48
	RE: .72 Let me theorize how Assets gets a bad name. 1) Digital realizes it has done a lot off work in custom projects and would like to capitalize on this work (Pretty standard among software shops). 2) Digital creates the Assets program to implement #1. 3) Not many people know what Assets is, does or has so. 4) The management realizes that Assets is underused. 5) The management creates an "Assets" metric for sales. (If there actually is an Assets metric I'd love for one of our sales folks to tell us about it.) 6) The sale force, not being a bunch of idiots, starts to [over]sell Assets hard. (Got to make those numbers!) 7) The customers get the wrong idea of what Assets is and the get pissed off. 8) Since the customers are pissed off Digits get pissed off at Assets. ------------------------------------------------------------------------------- o I may be mistaken, but as far as I know Digital does not put out brochures to customers on Assets that say "Look at all the neat stuff we have. If you like it we'll take your order". All the stuff I have received on Assets is of the type "This is what we've got. If you need it, it is available to help you deliver a solution to a customer". o Do we even have list prices for Assets? In my experience Assets can be sold for a nominal charge if they are used are part of a custom solution. The pricing is done so that the customer pays for the solution not the Asset. o In the past Assets administration has been a pain in the tail. I have been told that there has been a big inprovement recently. o There is a lot of useful stuff in Assets if it is used properly. o If there are people/organizations that are simply trying to sell Assets packages off the shelf then something is wrong. John
991.74	It's human nature, lending a hand.	NEWVAX::MZARUDZKI	Freeze up. Bigger hole in ozone	`Wed Jan 03 1990 21:18`	14
	Yes, How does one get pricing information on ASSETS solutions! Now back to the topic. It's basic attitude IMO. If one is well cared for, content , happy, payed for performace, wouldn't you all agree that you will go that extra mile. Helping people out when diaster strikes is inherently in your basic nature, is it not? Why do you help, why don't you? Anyone can have a bad day and out pops "it's not my job". The stigma of it all is that if one doesn't get groomed via the care, happiness and pay for performance, bad days happen more often. Helping people are happy people. Bash away........... Mike Z.
991.75	Here comes the Energizer Rabbit...	NWACES::ROHNERT		`Thu Jan 04 1990 11:08`	93
	Re: .41 ... Your opinion of ASSETS is biased, but mine is too. Let me tell it from my perspective. I joined the Upstate NY Software Services District in 1975, moved to the Northeast District the following year. Spent the next eight years in the New England and Northeast Accounts and Applications Districts. My tasks included a mix of presales, customer support and consulting (incl. 8 residencies) so I can empathize with Greg's(.0) support problem. I then worked in Computer Services for a few years and joined ASSETS in July of '87. So why the resume'? Because in my almost 9 years on the front-lines we always had to re-invent the wheel, every project had to be started from scratch (unless you could find something in the Small Buffer). What a waste of my time, what a waste of customer's money! One of my accounts wanted a system to manage their network plus a company wide business system in six months, we didn't have the people and they didn't want to spent the money it would take to develop the system from scratch. We could have had the contract if we had ASSETS, but we had to leave the money on the table. So let me tell you what we are trying to do with ASSETS. ASSETS is trying to get software to the field to solve customer problems and to stop re-inventing the wheel for each new project. ASSETS are not products. We do not want to compete with products. But we have to get the software to the field so that the PSS Specialist can solve the customer's problem. So the Specialist sells the software components as part of the total project. ASSETS saves starting from scratch. We had to name ASSETS something other than product so we named the supported ASSETS "Packaged Applications" and the rest "Solution Tools". Supported means we have a commitment from a Cost Center Manager to back us up, supply new versions and a few other things. We will support the Specialist whether we have backup support or not. Some of our Packaged Applications look a lot like products. FTSV and LTM-Reports are two in the Networks Library. Very confusing concept to sales people and customers as well. It appears to be semantics to the customer. It is. Explain that Packaged Applications come with an installation, orientation, and a warranty for 90 days. If a sales person or specialist drops a tape on a customer's desk and doesn't provide the above services, the customer got cheated. We thought that most of our ASSETS were going to come from the field organization. We don't get many from the field, we get them from everywhere in the world and every organization. Digital Telecommunications has given us several ASSETS. DTE's charter is to develop tools to help Digital remain efficient. Once they complete a project they move on to the next. Their tools go through a Phase Review process, field test and come with excellent documentation. DTE gave us Netpath and Poll Network Tool, both important tools to help customers migrate their networks to Phase V. Software Services Engineering has given us LTM-Reports, Netconsult Workbench, NCW-SF and has many more packages in process. All SWS/E projects have high documentation standards, follow the Phase Review Process, go through field test. My point is that none of our packages are "hacks" or "junk". ASSETS does know what customers want, they tell us at DECUS. Customers asked us in Anaheim for two Network packages that we thought were closely kept secrets. Sometimes customers tell specialists what they want and we track it down. We have about 30 packages in the Network/Systems queue. We prioritize by customer and field needs. The team member that processes a package in this library, supports it. Some will be rejected. A lot of the misconceptions with ASSETS quality come from the idea that if it isn't a product then it must have come from the toolshed. That is incorrect. We don't know who owns datarights to any package in the toolshed and we won't touch it. When a package is submitted to our library we send out a detailed questionaire. When it is returned we do a preliminary evaluation, a business plan, project plan and an implementation plan. We perform a quality verification on the package, convert all the documentation to VAX Document and create .LN03 output. We always have an Installation Guide, User's Manual, Description and usually a Delivery Guide to assist the Specialist in Selling the package. It takes about 140 hours to process a Solution Tool and 240 hours to process a Packaged Application. So let's go on from here... -dick
991.76		LESLIE::LESLIE		`Thu Jan 04 1990 11:33`	3
	Nevertheless, without a consistent approach to QA by the developers, customers are going to see an inconsistent level of product quality. Unless ASSETS are sold very carefully, they'll end up costing us $$$.
991.77	red tape was supposed to be eliminated	ODIXIE::CARNELL	DTN 385-2901 David Carnell @ALF	`Thu Jan 04 1990 11:51`	13
	In the November 1989 DVN broadcast of the Digital Employee Quarterly Report, Dave Grainger was seen showing a thick report of all the red tape and bureaucracy, presumably obtained via asking the field what was preventing them from being more successful in their jobs of getting and keeping customers, which he proceeding to rip in half, demonstrating corporate's commitment to eliminate all the red tape and bureaucracy, making proactive changes to help the field. Are all employees who actually meet in-person with customers not being asked continuously by senior management if these changes are taking place, along with what other recommendations these employees have to enhance effectiveness in winning and keeping customers?
991.78		LESLIE::LESLIE	I'd rather be in Seattle	`Thu Jan 04 1990 12:25`	4
	As a proactive demonstration of the corporate commitment to eliminating red tape, it would be most convincing if anyone can name 5 procedures that have been abandoned as a result of this commitment and not replaced in any way.
991.79	Well, I can think of a couple ...	YUPPIE::COLE	Now is the time for ACTION, not proposals!	`Thu Jan 04 1990 13:08`	24
	... because I got stuck with the results! District EIS Managers now have $2M dollars worth of approval authority for consulting efforts, whatever the flavor. This up from basically $0 as of last FY. The old "Area" bottleneck is eliminated. US Country wants to know about those over $2M, but I've yet to see them turn one down! Result is a lot more QC responsibility at the District, and rightly so. BTW, that's the monkey I got! In the same light, EIS DM's also more authority to do allowances without Area approval. Essentially, it allows them control over their business: Certs vs. Margin, Customer Sat., investment, etc. And, thinking of one more, EIS also now has a "Letter Agreement" that was, I think, originated in the Southern Area, and is intended to handle small study, spec, and just plain "consultancy" engagements without a Work Statement, SSD, T & C's, etc. Its all in 1, 2, or 3 pages. All Sales Support needs to do is add a description of the work, and any special working conditions they have ascertained to be necessary, produce it professionally, and get it signed. In closing, I would caution against thinking that eliminating "red tape" is going to make business easier or more profitable. It may be easier to por- pose and close, but a nightmare to deliver, and make us $0 profit, because it wasn't thought out, and QC'd.
991.80	Knowledge is an important element	MANFAC::GREENLAW	Your ASSETS at work	`Thu Jan 04 1990 13:34`	38
	Let me start with Andy's statement in .77? and work backwards. I am sure that SWS/E folks would be very surprised to learn that they don't do QA like the Engineering groups. I work next to a SWS/E unit and I have over 15 years in QA/QC so I think I know something about what QA is and what the SWS/E groups do. I have processed major packages from three SWS/E groups and I can assure you that they have had 1 or 2 FULL TIME people doing QA on each of the projects. They also use a QAR system to track bugs and a phase review process for project management. So I think that as a general statement, your comment does not represent the facts. However, we do not get all of our packages from SWS/E. Some come from the field and some come from internal groups. One of the reason that we put a degree of completeness on each package is to show how much work is needed before the delivery person can deliver the package. And yes, there are some bugs in the software. In 15 years of checking software, I only passed one package without a re-work cycle and the customer found a bug as soon they tried it (At another company not DEC). Dare I say it, even VMS has bugs! Now let me address a separate issue. We are told that customers want to get the software they see running in Digital plants. There is a program that has these tours as part of its charter (sorry I can not remember the TLA for the program.) We are told that the customers want the software as is; they don't care what it looks like, they want it NOW. When we put these software packages in ASSETS so that they can be sold to these customers, I can guarantee that someone will sell one to a customer who wanted a perfect package, not an as-is package. I quess that I come back to the following point. If you do not know what you are selling and the customer does not know what they are buying, there is a good chance that Digital will fail with that customer. As Dick said earlier, ASSETS is a place to START. We do not supply products. We supply re-useable code that can be included in a customer project to solve a problem. If you sell an ASSETS like a product, Digital will fail. Lee G.
991.81		LESLIE::LESLIE	I'd rather be in Seattle	`Thu Jan 04 1990 18:06`	9
	Whether you like it or not, there isn't CONSISTENT QA because, amongst other things, the Phase Review Process isn't followed and CSSE aren't involved. The trouble is that these ARE sold as products by the eager sales folk to eager customers to utter failure in some cases. These are necessarily generalisations and no doubt there are success stories - but I can only go on my limited experience.
991.82	Sounds like a problem	NWACES::ROHNERT		`Thu Jan 04 1990 20:05`	5
	re: .46....81 Please document. We need to address our problem. -dick
991.83		POCUS::KOZAKIEWICZ	Shoes for industry	`Sat Jan 06 1990 14:45`	19
	re: .72 If you wish to call the refusal to enter into business arrangements which have a high probability of failure for both the customer AND Digital "arrogance", then so be it. I call it smart. It requires a three-inch thick binder to explain the terms and conditions of the ASSETS program. I'm not going to try to do it justice here. If you are interested, get a copy and read it. It boils down to this: Real customers and real sales reps are, on the average, unable to reconcile a "service with a head start in the form of already written software sold without standard support" offering with a products and services mentality. As hard as you try to set expectations properly, you are likely to fail because they don't "make sense". I have the war stories to back it up. Al
991.84	We never claimed to be perfect but ...	MANFAC::GREENLAW	Your ASSETS at work	`Sat Jan 06 1990 16:46`	32
	RE:.83 OK, I will jump to the bait. Can you tell us how you sell a project? Why do I ask? Because that is how most ASSETS should be sold! Your description of '"service with a head start in the form of already written software sold without standard support"' is close to the mark if you mean "standard" = CSC support for the US Field customers. That is also a good description of a project. The local unit supplies the customer with the support of the custom code in a project, right? That is the same for an ASSETS package. Why should the customer care where the code came from as long as the customer gets the solution that is paid for. The gain for Digital in this is that the code does not have to be re-invented over and over again. But to continue to reuse the code, we (Digital) MUST protect the data rights and this does require that there be some T's and C's for using the code. Most of that three inch binder is there to explain where to get help whether you need to know how to sell an ASSETS package to the government or you want to find a notes conference for a particular library. I will NOT apologize for the size of the manual because I think it is necessary to have single source for all the information about the program. I am sorry that you have had problems with the program in the past. As with all programs, ASSETS did not start out with everything defined and all of the bugs worked out. It has been a learning process for us and we continue to try to improve our service to the field. Lee G.
991.85		POCUS::KOZAKIEWICZ	Shoes for industry	`Sat Jan 06 1990 18:16`	46
	re: .84 When a local office delivers a custom project, two things come into play: 1. the customer owns the code at the end and 2. the local office developed the application and understands it inside and out. The customer pays full price for the project and support. With an ASSETS package, the annual support for something like SES is usually about the cost of the original installation. That is because the local office cannot spread its risk out over hundreds or thousands of customers like a product group can. The local office must make a profit on each service sale. Customers are unable to rationalize this. In their mind, Digital developed the package and Digital is a monolithic entity. As they see it, Digital should be able to support it like any other product. The fact that we sold it to them with the understanding that we are reusing code precludes setting expectations that the customer is getting a pure custom application. And what do they get for their support money? How many PSS offices have you been in where there are people just sitting around waiting for the phone to ring? Support will involve 1. finding someone to handle the call, usually by borrowing them from another customer 2. scheduling the time 3. the specialist will probably not be familiar with the package so they will either spend time, at the customers expense, learning the application or by making phone calls to the ASSETS hotline (who will take a few days to find someone to return the call or blame the problem on a standard software product) 4. the customer wondering just what they got themselves into. A customer will gladly spend $175K a year for a resident to help support a custom application that cost $1M. Only an idiot will spend the same amount to support an ASSETS package that cost $15K. Unfortunately for us, we don't have many customers that stupid. As I said before, some of the packages are great. Others are not so. I think that the potential is high but that there are two basic problems: One is that the people who manage the ASSETS program have unrealistic expectations on how easily they can be sold by the Field as standalone solutions or incorporated into other projects. The other is that until support for them becomes more transparent to the customer, the Field (i.e., those who have to implement the grand vision of Digital as integrator) is going to be wary of using them. Al
991.86	again, not true	SHALOT::LAMPSON	I'm sorry, I don't have TIME!	`Sun Jan 07 1990 16:05`	17
	> Whether you like it or not, there isn't CONSISTENT QA because, amongst > other things, the Phase Review Process isn't followed and CSSE aren't > involved. Andy, I wish that you had told me we didn't use the Phase Review Process before my last project. It would have saved lots of time. :^} Seriously, anything which is done by SWS/E _does_ follow _a_ Phase Review Process. SWS/E has their own PRPM and a MANDITORY course on the process. As far as CSSE involvement . . . I don't have enough information to provide an answer. I'm sure someone else does. _Mike/L
991.87		LESLIE::LESLIE	New, improved, thinner model	`Sun Jan 07 1990 21:09`	13
	Lets not get pedantic over "a" Phase Review Process. The one you follow isn't the standard engineering one and is viewed by those with experienceof both as incomparable IMO. Background to my comments: As a CSSE Engineer, I have been involved in projects that were turned into ASSETS so that they didn't have to 'measure up' to the PRP's demands. ------------ ASSETS are a mistake, in my opinion. They'll not be sold properly for all the reasons that Al stated.
991.88	PHASE_REVIEW == BUREAUCRACY	KYOA::MIANO	Mad Mike's Mythical Miracle	`Mon Jan 08 1990 02:32`	26
	RE: .87 PHASE REVIEW != QUALITY You seem to imply that since ASSETS is a mistake because it does not follow the official central enginering phased review process. In my personal view the phase review is a piece of bureaucracy that guarentees product obsolesence. In addition the phased review as spelled out in the Engineering Handbook is totally inapplicable to the real world of producing custom software which is the goal of Assets. (Didn't the phase review process originate in that model of quality organization that brought us the Challenger disaster?) I have been involved in three large custom projects in which Assets played a critical part so I know from personal experience that Assets can be a life saver. Many of our competitors in the integration business make a fortune off of reworking the same system for different customers. If we want to be in the business we have to play by the same rules. That means pooling our resources to avoid re-inventing the pulley. Since the MGMT has clearly state that this is the business we are going to be in we better learn to use Assets properly. John
991.89		LESLIE::LESLIE	New, improved, thinner model	`Mon Jan 08 1990 06:44`	26
991.90	Looks like its time to agree to disagree	MANFAC::GREENLAW	Your ASSETS at work	`Mon Jan 08 1990 13:11`	27
	re:.85 and .89 I quess that I am not going to be able to convince either of you that there is any value in the packages in ASSETS. For this, I am truly sorry. Let me say for the record that there are those who do find value in our packages and have had success selling them. I am a "techie" by trade so I know that re-using code I or others have written has saved me a lot of development time. I also know that the number of bugs found in the re-used code is a lot less than in new code. Support of the ASSETS packages is an issue and it is being addressed. I could include a support model that is being proposed but that is not the purpose of this conference. It will be put into the ASSETS_PROGRAM conference when it is finalized for all to see. Lastly, I don't know what problems you have had in the past. I do know that we try to help all that ask for help. At the same time, I can not be an expert on every package in library. Nor is everyone who has submitted a package to us still available or even working for Digital. So there will be those times when I will honestly say that you know more about a package than I or anyone else who is available. That does not mean that I won't try to help, just that you may be more qualified than I am to resolve the problem. Or I may say that it will take some time to find the help you need. That's the real world; there are not going to be easy answers for every question no matter how much we would like them. Lee G.
991.91		SUBWAY::BOWERS	Count Zero Interrupt	`Mon Jan 08 1990 13:43`	16
	Before we become too negative about the ASSETS concept, I feel compelled to point out that IBM has had moderate success with a similar program. Their term for such packages was FDPs (Field Developed Products). One big hit in this category was a telecommunications monitor written for a major customer. It was called the Customer Information Control System or CICS for short. Probably the biggest difference between FDPs and ASSETS was that an FDP ended up going through a full product-level QA process and ended up in the price book as though it were a full fledged product. I might also add that IBM had a similar program for re-marketing customer-developed applications. These, too, were QA'd and came with full IBM-style documentation. -dave
991.92	You can't just get an engineer to call a customer - yet	COUNT0::WELSH	Tom Welsh, UK ITACT CASE Consultant	`Mon Jan 08 1990 16:00`	49
	re .8: >>> You replied incorrectly. It was indeed his job. IBM says >>> "Everyone Sells". I can't let this go by, even a week or so later. Spot the unstated assumption - this is not IBM! Digital may do things differently. Even if the IBM way is right (and it may well be), Digital can't just pick it up and run with it. Flying may be a great way of life, but how does that help a beaver? If half of what I read about IBM is true (uncertain), all employees without exception get a substantial amount of TRAINING on how to handle customer situations before they are allowed anywhere near a customer. Are we prepared to do this? And who would do the training? Just imagine we adopt Robert Digrazia's suggestion (from .8) and have the engineer say "Sure, I'll call the customer right now, give me the number!" What next? - If it's a known bug the CSC would have identified it. - If it's a new bug the engineer won't be able to do much about it either. - If it's an enhancement request (or a suggestion that the product be changed to be "better"), the engineer can't make any commitment. - Many engineers may be LESS able to diagnose a software fault than a CSC specialist, who does that for a living. Engineers' knowledge is often deep but narrow. - Engineers are not always known for their tact (a celebrated remark about magtape drives and boat anchors comes to mind). They may strike a customer as arrogant, unyielding, or even rude - when they are merely being honest, straightforward, and realistic. Formal SPRs go to and from Engineering via CSSE, one of whose functions is to screen replies for courtesy and to make sure they NEVER promise something we can't be sure of delivering. Now if responding rapidly to customer problems (which are subtly but clearly distinct from software bugs) is recognised as a #1 priority, we could find ways to allow engineers to talk directly to customers in a controlled fashion - but only when really indispensable. /Tom
991.93	Here's another company's ASSET	UNXA::ADLER	Ed - VAX System V Operations	`Mon Jan 08 1990 16:06`	2
	AT&T's UNIX !
991.94		CVG::THOMPSON	My friends call me Alfred	`Mon Jan 08 1990 16:51`	9
	RE: .93 Tempting to make a comment to the effect that it's nice to know that AT&T doesn't have any better QA then our ASSETS do. :-) On the other hand is does show how far a poorly documented, difficult to support tool can go when sold into the right enviornments. (This comment assuridly relates to the early years of UNIX going to schools.) Alfred
991.95	3-in-1 reply!	SHALOT::LAMPSON	I'm sorry, I don't have TIME!	`Mon Jan 08 1990 18:17`	24
	IBM's FDP's are not the same as ASSETS. ALL-IN-1 started out as a FDP SSM and SBO are currently FDP's and, one you might all recognize - SPM is a FDP!! ASSETS packages are TOOLS to help you do your job. If you don't need them to do your job, great! More power to you! Consider ASSETS to be Toolshed items which are available to customers. Andy, I take it you don't plan on making PAN an ASSETS package. It really would make a very useful tool once you've released a V1.0. Also, since you seem to be familiar with both SWS/E's and Central Engineering's Phase Review Processes, could you please provide some examples of what you see as the mojor differences? Note that I said SWS/E's PRP. ASSETS doesn't have a PRP as it is a program and a software library, not a group of programmers or engineers. _Mike
991.96	Why not?	WORDY::JONG	Steve Jong/NaC Pubs	`Mon Jan 08 1990 18:54`	24
	Re: .92 (Tom Welsh): By now the original intent of .0's note may be getting lost. I think he was describing a situation in which a customer waited, cash in hand, for the answers to a few straightforward technical questions about an ASSETS offering before placing an order. No "bugs" were involved. In this situation, the original engineer is probably exactly the right person to answer the questions correctly, clearly, and quickly. Not to put too fine a point on it, but I'd like to repeat a concern several people have expressed here. I think we can all agree what The Right Thing is here: 1) Customer has questions about something we sell 2) Customer gets answers to those questions in a timely manner 3) Customer is happy with answers 4) Customer gives us money 5) We give customer the thing in a timely manner 6) Customer is happy, we are happy You can justify the need for procedures, screening, protocol, efficiency, direction, etc. until you are blue in the face. But if the net effect is that you get in the way of these six steps, you are contributing to a bureaucratic clog.
991.97		LESLIE::LESLIE	New, improved, thinner model	`Tue Jan 09 1990 07:14`	9
	Please be clear that I'm not saying that ASSETS are without value. I am saying that unless they are sold PROPERLY, the end result could be that DEC loses money on the deal and gains a frustrated customer. ASSETS are different things given a generic name. As such this discussion is rather vague and leads to different interpretations being put upon statements made herein. I guess I'll shut up for now.
991.98	Meanwhile, back in Minneapolis...	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Wed Jan 10 1990 03:37`	23
	Here's where things are from my original note in .0. You wouldn't believe all the mail messages and phone calls I've gotten from all over creation. Thanks everyone for your offers of support. Jane, thanks for posting the list of ASSET contacts, in .70, I think. Meanwhile, the little problems fester. My other problem, the shipping fiasco, is getting comical. It seems we promised our customer we would ship the printers they ordered 2 day air. According to the shipping documents given the customer, the scheduled ship date was to be Dec 8 or Dec 18, depending on which document we looked at. Well, last week, week of Jan 1, we got to looking at those documents to try and figure out what came in and what we were waiting for. And we discovered the printers. So we traced the printers and found they were "somewhere in Chicago." Our CAS people raised a little rucus, and one of the printers magically showed up onsite Monday Jan 8. Longest 2 days I've ever seen. - Greg Scott
991.99		LESLIE::LESLIE	It's a DEC, DEC, DEC, DEC World	`Wed Jan 10 1990 07:18`	8
	Reminds me of DECUS a few years back: Product Manager: "We'll deliver the new functionality in 6 months" DECUS delegate: " Is that 6 calendar months or 6 DEC months?" :-)
991.100		SCAM::GRADY	tim grady	`Thu Jan 11 1990 11:25`	18
	Greg, I think your running narrative of this incident is really terrific -- I can't believe how familiar this sort of debacle sounds. On the positive side, just last night I recieved a formal description from upper management about how to get the right support at the right time, including the LOR/CLD process. Anybody know if this is just a coincidence? On the down side, my friend with the mangled h/w maintenance contract (for the past n months) is still wrestling with our contracts people. We estimate it will be a year in mid-February. Keep updates coming. It's very therapeutic. tim
991.101	More unworkable plans...	FSDB00::AINSLEY	Less than 150 kts. is TOO slow!	`Thu Jan 11 1990 12:15`	11
	re: .100 Tim, If the memo you got is the same as the one I got, I think it just made NOTES conferences the OFFICIAL #1 step in problem resolution. Now, how that will work is going to be interesting, since most conferences, quite correctly, refuse to commit to solve problems entered into the conference. Bob
991.102	perhaps this will change	ODIXIE::CARNELL	DTN 385-2901 David Carnell @ALF	`Thu Jan 11 1990 16:52`	9
	Ref: 991.101 >><<that will work is going to be interesting, since most conferences, quite correctly, refuse to commit to solve problems entered into the conference.>> I hear some new VAXnotes conferences may be instituted via the Employee Involvement program. Perhaps this will change.
991.103	If It Works Do It	SCAFST::RITZ	The Power of Notes	`Thu Jan 11 1990 18:56`	8
	Yea, most conferences refuse to commit to see total problem resolution but due to the good nature and drive to make things work as exhibited by most people who read notes it is my #2 resource after researching available material in the office. Not everybody wants, cares, or has the time to "go through the channels" to contact the people who can help them deliver the right answer to our customers. Some of go for what works best and notes is quite often the quickest way to do that. Ted
991.105	The Price Of Being Right	ZILPHA::EARLY	Actions speak louder than words.	`Fri Jan 12 1990 02:57`	48
	re: .104 I suppose it would be great if every answer I got in NOTES would be "guaranteed 100% accurate." However, I know that as humans we all make mistakes. So, I must take issue with your stance, because in my profession (where things need to happen today [unlike sales where things need to happen yesterday]) I will gladly accept an answer that is 90%, 80%, 70%, 60%, 50% 40%, or even LESS accurate over no answer at all. To demonstrate a scenario that happens all too often: New product comes out. We get it and try to install. We have problems. We call the "listed contacts" and wait ... and wait ... and wait ... But we don't REALLY just wait, because in the meantime we try posting a question on the problem in NOTES Someone replies. The reply says, "Try typing the following command ... and see if it fixes your problem." This command doesn't work. (The "Expert" was WRONG!) But, we now have: A command that we can diddle with and analyze to see if we can figure out why it's not 100% right A name and nodename of someone who knows more than we do about how to fix the problem. If s/he can help further they do. If they can't they can't, but sometimes they refer us to someone who can. 2-3 Days later the phone rings. It's the "right person" with the "perfect answer". It's also too late. The demo was yesterday. Being right isn't always the most important thing. Sometimes being "close enough" can make you a magnanimous hero. I would hate to discourage anyone from "taking a stab" at trying to answer one of my questions in a notesfile for fear of "being wrong". I could also cite examples of things we've done that were perfect ... too perfect. We'd have been better of to be a "little wrong". But that's another story and I don't feel like telling it now. /se
991.106	Notes is usually a win-win.	RIPPLE::FARLEE_KE	Insufficient Virtual...um...er...	`Fri Jan 12 1990 15:21`	15
	The scenario where looking for answers in notes files gives the biggest win is when the problem has already been answered. at least 90% of the time, I'm not the first person in the world ever to have a given problem. Chances are pretty good that someone has already asked the question in a notesfile somewhere. All I need to do is a little detective work, and the answer is usually waiting for me. So, 1) I don't have to wait for ANYBODY. 2) Nobody has to take time out to answer my question (through any channel). 3) The time that someone originally took to post the answer actually answers the question for many people. In my experience, the quality of the answers varies widely from conference to conference, but on the whole I have gotten excellent answers and help from the notesfiles, and far more timely than any other channel could be. Kevin
991.107		STAR::MFOLEY	Rebel Without a Clue	`Sat Jan 13 1990 14:20`	11
	Notes is a win-win situation until some persons boss says "The project needs 100% of your time. Stop noting now." What info can the person give to show that their time is also very well spent in Notes? As much as I hate numbers, they are needed in an organization like the CSC to forecast equipment and resources. How do we put the numbers into answering notes? mike
991.108	possibilities ...	ASDS::NIXON	Rock Like ***k !	`Sat Jan 13 1990 17:34`	17
	> <<< Note 991.107 by STAR::MFOLEY "Rebel Without a Clue" >>> > How do we put the numbers into answering notes? One solution we've come up with to utilize notes is to dump the info into a stars database. Ours is updated on a nightly basis so the info in there is the most current availiable. The amount of time it takes to search for a given topic is seconds!! It's helped me many many times looking for Ultrix info. Management loves it too, because of the time it saves. It cuts down on me having to ask a redundant question as I can actually find where it was asked before and so on. I don't know how useful this would be in a CSC but maybe it could help some. Vicki
991.109		SCARY::M_DAVIS	Marge Davis Hallyburton	`Sun Jan 14 1990 11:10`	5
	Unless the conference is "sanctioned" as a support conference, what you read in there is generally hearsay and, often, heresy. It's fine to give you perspective, but I'd caution against using it as gospel. Marge
991.111	But...	SCAM::GRADY	tim grady	`Mon Jan 15 1990 15:03`	12
	I found it interesting that the official instructions I received last week for handling remedial and advisory issues showed this as the first step: 1. Refer to the "Notes Conferences". Calling the CSC was step three. tim P.S. Sorry, my last attempt to reply lost the network link...
991.112	Saying "don't do it" here won't change policy	NEWVAX::PAVLICEK	Zot, the Ethical Hacker	`Tue Jan 16 1990 17:17`	18
	The copy of the official instructions I received last week was distributed from a U.S. SWS official with instructions to distribute to all reports. This is now, apparently, the official problem escalation procedure for U.S. SWS. If I am incorrect in that statement, I hope someone corrects me. It is being passed around the Mid-Atlantic region as U.S. SWS gospel. As Tim has been saying, the first line of problem resolution is to refer to Notes Conferences. Arguments of "you shouldn't do that" are probably best aimed at U.S. SWS Headquarters. FWIW, this is the first time I have _ever_ seen SWS problem escalation procedures outlined (even semi-) "officially" in the three years or so that I've been here. -- Russ
991.113	CSCs use STARS on notesfiles	CSC32::K_PARRIS	Keith CSC/CS DECsupport Team	`Tue Jan 16 1990 17:47`	11
	Re: .108 > One solution we've come up with to utilize notes is to dump the > info into a stars database. > I don't know how useful this would be in a CSC but maybe it > could help some. The CSCs are currently doing this with a number of notesfiles, and it is a great help to those of us answering the phones. (See the notesfile NOETIC::STARS for more info on the STARS software.)
991.114		STAR::MFOLEY	Rebel Without a Clue	`Tue Jan 16 1990 23:52`	9
	RE: .112 I'd like to see a copy of that so it can be forwarded to some s/w development managers that see notesfiles as un-official. Time to re-educate some people.. mike
991.115		LESLIE::LESLIE		`Wed Jan 17 1990 08:45`	6
	Notesfiles ARE largely unofficial support channels. As Marge said, unles sthe support folks say that this is the way to go, then there can be no reliance upon such channels. Just because someone, somewhere, says they're official, don't make it so.
991.116	It's official for SWS, not for other orgs	NEWVAX::PAVLICEK	Zot, the Ethical Hacker	`Wed Jan 17 1990 14:08`	25
	The memo does not state that any support group recognizes NOTES as an official mechanism. It _DOES_ state that it is SWS's first line of support. It appears that we have a difference in procedures across organizations (so what else is new? 8^\| ). It is my job, as a SWS grunt, to attempt to get information from the NOTES files in order to solve a problem. It may or may not be your job to answer my question in the conference, but that is largely immaterial (unfortunately). My job is to try there first. Failing that, I am to try DSIN. Failing that, I am to try the CSC route. The fact that CSC & Engineering do not recognize the problem until it hits the third step is a difference in perspective, it appears. Apparently, it is now officially my task (as a SWS-type) to solve my problem thru NOTES and DSIN whenever possible before escalating to CSC. I regard this as goodness, as I think too many specialists punt things to the CSC rather than making an attempt to solve the problem on their own. We need to use the CSC only after the problem appears to be beyond the scope of our knowledge and/or circumstances require immediate escalation. The CSC should not be used as an excuse for laziness. -- Russ
991.117	Update: It may not be official, after all	NEWVAX::PAVLICEK	Zot, the Ethical Hacker	`Wed Jan 17 1990 15:07`	7
	I have been contacted by an official at the US level. He indicates that the memo I have received may not be official at all, despite a remarkable appearance to the contrary. I will wait for further clarification and attempt to correct any misconceptions to which this memo may have given rise. -- Russ
991.118	IT'S OFFICIAL (apparently)	NEWVAX::PAVLICEK	Zot, the Ethical Hacker	`Wed Jan 17 1990 15:46`	5
	It _is_ apparently official. I will attempt to contact the author to secure permission to post it here, in order to further understanding of the matter across groups. -- Russ
991.119	What one group does	CLOSET::DUM::T_PARMENTER	Chantez la bas!	`Wed Jan 17 1990 16:28`	18
	In my group, CUP Engineering, we run a number of notesfiles for our products and they are all "official". For most of the products, the notesfiles are moderated by the principal developer. In the case of VAX Document, we have our own support person, who moderates the notesfile and dispatches notes to various developers to answer. Frequently, one of our users will answer the question before we get around to it. If so, the answer stands, but the developers watch the file closely and correct or extend answers where appropriate. In addition to dispatching notes (and QARs, etc.), the support person also deletes transitory notes ("Thanks") after a day or two, assigns keywords, moves notes when needed, and generally keeps the ducks in a row. As for talking to users, since the bulk of our users are DEC employees, we're pretty used to that. We work closely with CSC to support external users and we'll even talk directly to those users persistent and perspicacious enough to find us from outside, although, realistically, despite the pleas of .0, we wouldn't do it if a lot of users started calling us. We also call selected users from time to time to ask for their observations on issues we're considering.
991.120		LESLIE::LESLIE	Think laterally. Move forward.	`Wed Jan 17 1990 17:50`	10
	re: .119 Great! I'm all in favour of engineering groups providing this support "officially". What I'm not in favour of is someone else declaring that a given notesfile is an official line of support when they have nowt to do with the engineering group. Hope thats cleared up any misunderstanding.
991.121	If it comes in through Notes, by all means ignore it!	WORDY::JONG	Steve Jong/NaC Pubs	`Wed Jan 17 1990 18:34`	8
	I think I'll add this to my "Are You a Bureaucrat?" quiz: You are a development engineer whose project maintains an "unofficial" Notes conference. You see a note reporting a bug, but it is not accompanied by a QAR. Do you: (A) fix the bug, or (B) ignore it, as it didn't come in through the proper channels? You may be able to guess what I consider the "right" answer 8^)
991.122	"Please submit a QAR" = "I'll look at this later"	HANNAH::MESSENGER	Bob Messenger	`Wed Jan 17 1990 20:25`	19
	Re: .121 > You are a development engineer whose project maintains an > "unofficial" Notes conference. You see a note reporting a bug, but it > is not accompanied by a QAR. Do you: (A) fix the bug, or (B) ignore > it, as it didn't come in through the proper channels? How about (C) ask the user to submit a QAR, so that I can go back to working on the higher priority QARs in my backlog and work on this lower priority problem later on. (In some cases I've entered the QAR myself if the user hasn't done this.) A lot of notes aren't so much bug reports as "My system is broken. What am I doing wrong?" or "How can I customize xxxx?". I usually try to help out, but not if it would more time than I can afford. In some cases I might not make the right tradeoff between doing what I've been assigned to do and helping out a particular user. -- Bob
991.123		MIPSBX::thomas	The Code Warrior	`Wed Jan 17 1990 22:58`	5
	A) if the bug takes <5 minutes to fix, probably. B) nope C) I either ask for a QAR or SPR to submitted (if it's a wishlist item or a customer problem) or send it off to our maintainance person and ask him to persue it.
991.124	Measurement and Evaluation set the Style	FSCORE::READ	Bob Read @KBS, DTN 641-5021	`Thu Jan 18 1990 11:51`	20
	re: .121 It probably depends on how you or your group is measured. Some groups use the QAR system to allocate, prioritise and measure the workload of individuals within the group. If I'm a development engineer who gets evaluated (and gets my raises or promotions) by how many QARs I complete, and how many QARs I have outstanding, then I'm less likely to respond to a bug reported in notes than a development engineer who works in a group which has a more well-rounded evaluation mechanism that looks at what I'm doing, and not just the stats out of the QAR system. The person who evaluates my performance and/or determines the salary plan is going to set the tone of the group. Individuals may attempt to use their own way of doing things, but the over-all response mechanism "style" is going to be set by the measurement methodologies and their usage by management. "Measurement and evaluation" is a very powerful force in the workplace, shaping what I do and how I do it on a day-to-day basis.
991.125		COVERT::COVERT	John R. Covert	`Thu Jan 18 1990 12:12`	6
	There's another option not mentioned: The developer can enter the QAR, or have the group secretary do it. If it's too much trouble to turn a note into a QAR, something's wrong with the QAR input procedure (which might be why the person reporting the problem didn't enter the QAR). /john
991.126	Perspective	SUBWAY::BOWERS	Count Zero Interrupt	`Thu Jan 18 1990 17:38`	11
	Those of us working in the field need to come to grips with the fact that our view of customer satisfation is rather biased - "Satisfy MY customer, NOW!!!". Unfortunately, central support organizations and engineering are, directly or indirectly, responsible for "satisfying" thousands of customers. It is here that our ideal of "instantaneous" problem resolution breaks down. If you (field person) cant't solve it, it's got to go into the queue and neither you nor I have sufficient perspective on the problem to set priorities. -dave
991.127	Notes: A valuable tool, if we use it wisely ...	AUSTIN::UNLAND	Sic Biscuitus Disintegratum	`Sat Jan 20 1990 03:51`	19
	Probably the main reason I often use Notes instead of QAR's (generic term for "The Proper Channel") is that usually only a few people will see the problem statement or question as it tracks through the system, but many people will see a Note. Sometimes the stars are with me, and another person completely unrelated to "The Proper Channel" has the answer and supplies me with the help I need in the best possible timeframe. That's the major benefit that I see. Like all good things, Notes can be abused. There are some who use Notes as a means for getting others to do the dirty work of research and legwork, where notesfiles become so clogged with inane questions that people give up trying to read them. That defeats the whole purpose in my view, and I hope that we avoid having good notesfiles turn into "dumping grounds" where we have to sift through thousands of unanswered questions and complaints to get a few good nuggets of useful information. Geoff
991.128	Plug for ASSETS group from a lone ASSET developer	PHAROS::DMCLURE	Your favorite Martian	`Mon Jan 22 1990 19:38`	107
	I feel that as a developer of a network ASSET PASS (PULSE - soon to be rereleased as DECPULSE for trademark reasons), I should come to the defense of Hugh Mercer and the folks over in the ASSETS group in general who, in my humble opinion are getting unduly criticised for their excellent work providing and supporting the ASSETS library. First of all, I think you folks in the field should realize that alot of the ASSET submitters (such as myself) are not necessarily afforded the luxury of an entire development and support organization for these products we create. On top of that, we many times create these things for no apparent reason other than to help DEC as a corporation. I know, because over the years that I have developed, quality assured, and supported my PULSE Remote VAXen Monitor tool, I have never yet been able to claim any credit whatsoever for this work in my monthly reports, or ultimately in my own reviews. So what's a guy like me doing writing programs? Well, I'll tell you. For one thing, I've written enough code and feel that I have enough educational background to be in software development working on "real DEC products", but for one reason or another, things just seem to have worked out differently. A few years ago, however, back when I was working in the HPS engineering support group over in MR01, I and a few of my cronies were approached by our management to help out the local marketing group in putting together some demos for the upcoming 8974-78 announcement. Well, one thing led to another, and we ended up developing a pretty close working relationship with this marketing group. We put together various ad-hoc demos for this group, and eventually, DECWORLD '87 rolled around our group was picked to support the 8978 cluster (which was arguably the main attraction of the entire event). The 8978 was demoed inside of the fish-bowl in the middle of the main floor, and to show it off, we came up with a series of different system monitor displays (Monster Monitor), along with a few razzle-dazzle color photographic image demos displaying various sexy marketing shots of the system up close in a multi-window environment. Directly across from our fish-bowl demos was the VCS (VAX Cluster Console) software demo (VCS is/was DEC's official cluster monitoring product at the time). Well, I can't tell you how many customers would walk up and admire the Monster Monitor displays of various system activity on the cluster, and then ask one of us more about the "product" only to discover that the Monster Monitor "product" didn't really exist as it was only a hack demo thrown together in a month or two to show off a specific system. The customers would then be tactfully pointed towards the VCS displays and told that this was DEC's product to solve their needs, and almost every time the customer would squint their eyes at the VCS display and eventually turn back around to view the Monster Monitor display instead. This became such a common occurance, that towards the end of the second week of DECWORLD '87, I began to take cards of representatives of various corporations who were interested in purchasing whatever code they could of the Monster Monitor right then and there! Anyway, having seen the potential for the product, I went about trying to get support for such a product within the various engineering groups I was currently involved with. It was so frustrating trying to drum up support for the idea however, that one of the marketing fellows that we had been working with (Dave Wagner) and who was also actively trying to drum up support for the product idea up and quit DEC and went to work at Stratus. Ironically, the product manager for VCS (who had originally scoffed at the Monster Monitor demos when DECWORLD first began) ultimately became one of the few champions of the product idea and was perhaps my only Mentor in the productization effort. Needless to say, however, time passed by, the stock market crashed, and people's minds soon forgot about DECWORLD '87 (along with the various demos). After a while, I became disillusioned at my attempts to productize the Monster Monitor, so I vowed to write the damn thing anyway (on my own time if nobody else would fund me) since I knew that there were customers out there who wanted it. A few months passed by, and eventually PULSE V1.0 hit the network (via the PULSE notesfile - currently located on node PSYCHE). It wasn't long after that that I learned of the Network ASSETS program, and after a little greasing of the wheels in my existing management, I managed to get them to back me in a PASS level of support for the product. Well, a few years and a new job (almost two new jobs - knock on wood) later, and I am still carrying the ASSET development/support responsibilities for the PULSE/DECPULSE PASS with around me and I plan to keep on improving it, as well as perhaps eventually even port it to monitor Ultrix systems as well for many years to come. Why? Well, because I'm damn proud of the thing that's why. The way I figure it, if it only leverages the sale of one single DEC computer, then it's been worth it to me. Sure, it's far from perfect, and I'll admit that it never went through a formal phase review process, but what do you want for nothing? So, what does all of this have to do with Hugh Mercer? Well, if it wasn't for the friendly assistance and encouragement I have received over the years from the likes of Hugh Mercer, Bill Ziminsky, Dick Ronhert, and the rest of the crew over in the Network ASSETS group, I doubt whether I ever would have managed to get as far along with the Monster Monitor/ PULSE/DECPULSE application as I have. Keep in mind that DECPULSE is but one of many such Network ASSETS tools that these people support for the entire corporation, and between getting the message of the ASSETS Library out to the field and to the various "established" organizations within DEC, as well as working with the developers in helping us fill out all of the legal forms and support contracts correctly, as well as learning the insides of these various applications (such as DECPULSE) so they can fly around the world demoing them, it must be one helluva job and my corporate hat goes off to these guys! -davo p.s. Check out the latest DECPULSE V1.0 (currently in field test). See the PSYCHE::PULSE (soon to be renamed to DECPULSE) notesfile for more details.
991.129	notesfile policy query. DEC needs efficient problem reportage	VAXWRK::TCHEN	Weimin Tchen VAXworks 223-6004 PKO2	`Mon Jan 22 1990 23:20`	49
	<<< Note 991.118 by NEWVAX::PAVLICEK "Zot, the Ethical Hacker" >>> -< IT'S OFFICIAL (apparently) >- Since my group, VAXworks, used to handle VMS calls escalated from CSC's and still handles SWS support, I asked my manager about notesfiles being an official line of support. He responded that neither our group nor the "elevations" manager for US SWS, has heard of anything about this. I'm wondering what this notesfiles policy actually means: Support people are now allowed to read and write notesfiles as part of their job? I ask this I remember notes elsewhere complaining that managers felt that reading techincal notesfiles was a waste of time. or Support people should consult notesfiles before escalating their problems? This seems to be the point in .116 by NEWVAX::PAVLICEK . or Problems can be reported in (perhaps special) notes file instead using the QAR mechanism? Some feel notesfiles are a more efficient method of reporting a bug than QAR; many developers differ. This problem appears repeatedly in VMSnotes. > <<< Note 991.116 by NEWVAX::PAVLICEK "Zot, the Ethical Hacker" >>> > -< It's official for SWS, not for other orgs >- > It is my job, as a SWS grunt, to attempt > to get information from the NOTES files in order to solve a problem. > It may or may not be your job to answer my question in the conference, > but that is largely immaterial (unfortunately). I'm concerned since we host VMSnotes which has been seeing more activity lately. Several people in our group feel that DEC wastes much energy by not using a unified problem reporting and searching mechanism. If a notesfile will be widely used to search and report problems, then DEC should organise appropriately. As mentioned earlier, notesfiles are much slower and more difficult to search than STARS databases. People writing to VMSnotes often don't search for duplicate cases or take the time to clearly formulate a query. As DEC moves toward providing solutions based on the facets of growing number of products (or ASSETS :=} ), where is the unified tool for the the local support person to turn to? -Weimin Tchen
991.130	Agreed -- Efficient Problem Reporting is Needed	NEWVAX::PAVLICEK	Zot, the Ethical Hacker	`Tue Jan 23 1990 16:40`	84
	RE: .129 > Support people are now allowed to read and write notesfiles as > part of their job? I ask this I remember notes elsewhere > complaining that managers felt that reading techincal notesfiles > was a waste of time. Not support people -- SWS people. It would appear that any SWS manager who tells his/her people that "reading technical notesfiles is a waste of time" is not following current US SWS practices. Nothing implies that internal support people should be reading/writing in conferences. The implication is, simply, that answers may be found, on occasion, in NOTES conferences. > > or > > Support people should consult notesfiles before escalating their > problems? This seems to be the point in .116 by NEWVAX::PAVLICEK . > Again, SWS people. According to the document, we are to go to NOTES first to look for an answer. If that doesn't work, we are to check DSIN (using the customer's access number). If that's no good, we are to call a support center and begin up the road of internal escalation if needed. I get the sense that step 0 would be "read the manual". It almost seems like a check list to begin escalation. I'd paraphrase this part of the instructions as: "If you've looked in NOTES and checked DSIN and still can't get a grip on your problem, then it is time to call for support." > or > > Problems can be reported in (perhaps special) notes file instead > using the QAR mechanism? Some feel notesfiles are a more efficient > method of reporting a bug than QAR; many developers differ. This > problem appears repeatedly in VMSnotes. I did not get any sense of this in the memo. > I'm concerned since we host VMSnotes which has been seeing more activity > lately. Several people in our group feel that DEC wastes much energy by > not using a unified problem reporting and searching mechanism. If a > notesfile will be widely used to search and report problems, then DEC > should organise appropriately. As mentioned earlier, notesfiles are > much slower and more difficult to search than STARS databases. People > writing to VMSnotes often don't search for duplicate cases or take the > time to clearly formulate a query. STARS is not available to SWS folks, as far as I know. If it is, it can be classified as one of the best-kept secrets of the corporation. Yes, NOTES can be slow, but waiting hours for a callback from an overworked support center can be much slower. And, yes, because of the slowness of searching for topics in NOTES, many people do not do exhaustive checks for previously entered information. Frequently, the customer expects the resolution within MINUTES. Customer satisfaction is frequently much better when someone says "I've entered the problem; I'm now waiting for a solution" than when one says "I've been searching the conference for the past hour and have found nothing of interest thus far". Also, keep in mind that the SWS-type is frequently not free to search the conference. The customer often expects him/her to continue doing "critical" work while the problem is "being addressed" by others. > As DEC moves toward providing solutions based on the facets of growing > number of products (or ASSETS :=} ), where is the unified tool for the > the local support person to turn to? Well, considering that it has taken almost three years for me to see a copy of instructions of "what to do to solve problems", I sincerely doubt that I'll see a "unified tool" for QARs, etc. in my Digital lifetime. Were such a tool available, made known, and capable of returning data within MINUTES instead of HOURS or DAYS, you'd have a winner on your hands. You'd just need to make certain that there would be enough horsepower behind the whole thing to support the potentially large traffic which such a system would endure. -- Russ
991.131	Still waiting for permission to post...	NEWVAX::PAVLICEK	Zot, the Ethical Hacker	`Tue Jan 23 1990 16:51`	7
	By the way, I sent a mail message asking for permission to post the memo in question. I sent it to the originating ALL-IN-1 address (which seemed somewhat out of the ordinary) about a week or so ago. Thus far, I have received no reply. -- Russ
991.132	gee, i'm doing DEC good	NEWVAX::MZARUDZKI	Freeze up. Bigger hole in ozone	`Tue Jan 23 1990 22:46`	14
991.133		ALOS01::MULLER	Fred Muller	`Wed Jan 24 1990 01:59`	26
991.134	?	ALOS01::MULLER	Fred Muller	`Wed Jan 24 1990 02:22`	20
	The phone line cut off my last reply. For better or worse, I'll let it stand as is. Middle management, keep up the good work and keep shovelling it out, we will all wind up in middle ground somewhere. My unfinished remark about noting the time stamp was to be a reference rebut any criticizm about wasting company time noting (or anything else) - it is my time! If it is taking up too many bits or bps's, take my gadgets away (yeh, I've felt some of that coming too) and I'll work to rule. Somehow I know that's not the way Digital became a success. I thought that we were in a mode of trimming the middle man. However, I recognize they are also trying their best - and the support memo is an example. I'm trying too. So are all my immediate peers and everyone else in these notes files. Not many of you would be here if you did not give a damn. Just leave me alone. I'll do my job to satisfy my current customer list to the best of my ability and try to do "the right thing always" - as my "Maximum Leader" exhorts me to do. Fred. Wow, did that feel good.
991.135	Back in Minneapolis, the parts finally arrived!	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Sat Jan 27 1990 05:52`	9
	Well, the rest of the parts finally arrived for our customer at the University of Minnesota. They were shipped 2 day air on Monday Jan 15. The stuff arrived at Twin Cities airport on Friday Jan 19, 5 days later. The final 6 ethernet thinwire "T" connectors arrived a few days after that. Life goes on. - Greg Scott
991.136	This is probably $.04, but . . .	16BITS::DELBALSO	I (spade) my (dog face)	`Wed Feb 07 1990 11:52`	212
	OK. I know y'all haven't seen my face in here since I left for vacation before the holidays. And I've done pretty well on my new year's resolution to spend less time noting. But when I got a copy of .0 in my MAIL yesterday with a bunch of forwards - (Yes I know that violates policy and I'll be willing to turn the forwards in to the Enet cops, as it's mostly all my upper management) when I got that copy and read it I just couldn't resist getting back in here on this one. So I read all 135 replies last night. I'd like to offer a few comments I didn't see. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- re: Note 991.17 by ISLNDS::BAHLIN > -< Whew >- > > I agree, almost. For the person on the other end of the phone, > the immediate need is for an answer. Fixing the process is secondary > to the problem currently on the front burner. > > So yes, I think the caller needs to work the system, eventually. This is the correct attitude, _BUT_, I think this never happens. Rather, I believe, when folks can short circuit the system, they get their answer and they're gone. Goodbye! Someone else can fix it. re: Note 991.18 by SCARY::M_DAVIS -< so long as there's a parallel submittal >- > escalated problems. Staffing is based on the numbers. Back-alley > fixes don't show up in the numbers and don't result in staffing. Fact. Ummm. Not so sure it's a fact, Marge. Funding provides headcount based on what you need to do the job, not how many SPR's were submitted. There's been a steadily decreasing influence on funding from Gray book metrics over the past several years. re: Note 991.26 by SALMON::SCOTTG -< Don't lay this one at local mgmt's feet. >- > Lots of replies are harsh on our local management. This is incorrect. > It is because of our local management we found somebody. After > finding that the proper channels - as best as we could figure out - didn't > work, we immediately elevated the situation in writing to our local > Sales management. That was on a Thursday. By Friday AM, I got > a call from a fellow SWS person in Milwaukee, who happened to read > the memo, which had been forwarded a bunch of times starting with > our local Sales management. By Friday PM, he was on the phone in I'm sorry Greg, but to me this just sounds like your management found you a different route because _they_ didn't know the correct one, either. > In our case, this is really maddening because every day our customer > must buy time from the CDC machine, there are that many fewer dollars > in their budget for DEC products and services. This customer's budgets I must admit it's been a long time since I was a customer, but trading operating expenses against capital expenditure plans sounds unrealistic to me. > asked mfg to do a partial shipment of what they could do. So they > shipped the MV3800, but did not ship the software media and doc. It > seems they thought that all the software should belong with a > VAXstation 3100 model 48, and not the boot server MV3800, so they held > up shipping the software until some time in January, which is when the > VAXstation will ship. And a big part of the reason the customer This sounds just plain wrong to me, as well. It sounds like a problem which "ought" to be easy to fix, provided someone knows "the appropriate channel by which to do so" [only half :^) ]. re: Note 991.35 by CGOA01::DTHOMPSON -< External Escalation always works... >- > at the customer's to call Mr. Olsen. What gets accomplished by > such radical action? > - The customer gets the answers needed in a short time > - The 'system' gets jiggled > - either the response mechanism wasn't working, or > - the field people were unaware of how to use it. > - The next customer doesn't have such a problem I'm not sure I can agree with this, Don. I've been on the receiving end of many a call from Ann McWalter (used to (maybe still does) handle most of the KO calls on software problems). The problem with these calls is that they _DON'T_ normally fix the problems with the _system_. They satisfy that individual customer's complaint, yes. They "jiggle" the system, yes. But I believe that often the next customer _DOES_ have the same problem, only if it's not recognized to be the same by either the customer or the person handling KO's calls (possibly because it's differently defined by the caller), then another individual customer problem gets fixed with absolutely no overall effect on the system. re: Note 991.59 by NITTY::COHEN > three most common statements are: > 1) There is no way easy to get correct/fast answers about anything from > DIGITAL. > 2) When DIGITAL says something we have to check it with our own > resources to see if it is true. > 3) I cannot get a straight answer about when our stuff will be delivered > or what hardware is/will be available. Funny - the more things change, the more they remain the same. I had the same problems as a customer 15 years ago. But I suppose things were a lot simpler then, as I knew that at least once the hardware got delivered and installed I could "cut the cord" and handle the rest of it on my own, 'cause I wasn't gonna get any more help from DEC anyway! re: Note 991.63 by RIPPLE::FARLEE_KE > channel that I know of. If I have not been informed of a support channel > (I thought CLD stood for "Career Limiting Decision"), then something's broken. > I spend a fair amount of time ferreting out such details and just today > found out what CLD stands for. Still dont know the process. This has been stated several times. This is the part I don't understand. WHY is it that people in the field _DON'T KNOW_ about the proper procedures and channels? Maybe half (or more) of the problem isn't in the procedures or the channels themselves, but in the dissemination of the information _ABOUT_ the procedures and channels to the people who need to know about them! re: Note 991.92 by COUNT0::WELSH -< You can't just get an engineer to call a customer - yet >- > Formal SPRs go to and from Engineering via CSSE, one of whose Ummm. I don't mean to disagree with you, Tom, nor do I mean to knock CSSE, but at least in the organizations I've been in in Engineering in the last 12+ years, CSSE has _NOT_ always been the channel to or from us for SPR's unless there was some elevation procedure (e.g. a CLD) in effect. re: Note 991.121 by WORDY::JONG -< If it comes in through Notes, by all means ignore it! >- > "unofficial" Notes conference. You see a note reporting a bug, but it > is not accompanied by a QAR. Do you: (A) fix the bug, or (B) ignore > it, as it didn't come in through the proper channels? As the authors of .122 and .123 have already suggested, I also would ask for an SPR, Steve. I have, perhaps, a couple of other reasons, though. 1) If I, as an engineer, "just fix it", who will know about it? At least if I get an SPR (for which a process exists) then it will get a formal answer which will be recorded and available for others to see and reference (That's part of what TIME and DSIN are all about, I believe.) So by using existing processes, I add value to the system with no additional overhead (like having to remember to go back and find the note that complained about the problem and add a response saying "Oh yeah, I fixed that". 2) If I get hit by a truck on the way home, at least if there's an SPR someone will still know that there's a problem which has been formally registered - guaranteed - even if nobody ever opens the NOTES conference again. re: Note 991.125 by COVERT::COVERT > There's another option not mentioned: The developer can enter the QAR, or > have the group secretary do it. If it's too much trouble to turn a note > into a QAR, something's wrong with the QAR input procedure (which might be > why the person reporting the problem didn't enter the QAR). You may have hit on something here, John. At least with my group, what I probably need is an SPR rather than a QAR, the latter being only used for products in field test, and hence, often procedures are not in place to even process them (like if I don't _have_ a version currently in FT). But the way we've got things set up right now, neither I as a supervisor nor any of my engineers _CAN_ create cases in TIME to enter SPR's. But I believe most people in the field can do so at least through the CSC's. re: Note 991.126 by SUBWAY::BOWERS -< Perspective >- I think you've hit the nail quite squarely on the head, Dave. While others stated it, and while I share the same view, you have probably said it most succinctly. And finally, re: Note 991.71 by SSDEVO::YESSE I think Keith has a great idea here, and he should contribute it to the "Involvement" program, or whatever that's called. If we had these tools ("Who-does-what" and "How-to-do-that") I think we could all save immeasurable amounts of time and possibly do away with tons of red tape, provided that some of what you'd find in "How-to-do-that" simply could tell you what the right channels were. This has probably gone on far too long, but in closing, I recognize your problem in .0, Greg. I know it sucks. But at the same time, I hope you can appreciate engineering's need to isolate themselves somewhat from the field and see to it that channels _are_ used. Yes, if they're broken they need to be fixed, but if they're working they oughtn't be short circuited. Being involved in some perhaps "obscure" PDP-11 products, I know our phones aren't likely to ring off the hooks anyway, but look at it this way - how is an engineer supposed to be able to evaluate whether or not any particular call is critical for him to deal with? Even I, as his manager, don't want to need to make those choices if we did away with the channels. At least we know when something has come through the channels, that it warrants our attention according to the book. nuff said, -Jack
991.137	what counts is what gets counted...	SCARY::M_DAVIS	Marge Davis Hallyburton	`Wed Feb 07 1990 14:20`	24
	re: .136: >>re: Note 991.18 by SCARY::M_DAVIS >> -< so long as there's a parallel submittal >- >> escalated problems. Staffing is based on the numbers. Back-alley >> fixes don't show up in the numbers and don't result in staffing. Fact. >Ummm. Not so sure it's a fact, Marge. Funding provides headcount based on >what you need to do the job, not how many SPR's were submitted. There's >been a steadily decreasing influence on funding from Gray book metrics over >the past several years. Well, unfortunately I'm on track here. We're doing the budget process this week for next FY. Direct inputs to the headcount we'll receive for backup support are the number of CLDs, SPR/TIME cases, and the number of requests we receive for technical consulting. There is a multiplier of hours for each level of support, plus an "overlap" factor which takes into account that the support folks usually work on more than one problem at a time. The failure in this type of budgeting process is that it doesn't take into account skill mix. Alas. Marge
991.138	more then one truth	CVG::THOMPSON	My friends call me Alfred	`Wed Feb 07 1990 14:37`	5
	RE: .137 Marge you're in CSSE, Jack is in engineering. Seems likely that the use of Gray book stuff for CSSE funding and for Engineering funding may not be the same. Alfred
991.139	Whoops! Didn't mean to detract from your statement, Marge.	16BITS::DELBALSO	I (spade) my (dog face)	`Wed Feb 07 1990 15:15`	11
	re: <<< Note 991.138 by CVG::THOMPSON "My friends call me Alfred" >>> (re: .137) Alfred's right, Marge, and my apologies. When I read your statement I was thinking about it from an Engineering standpoint whereby our headcount is _not_ primarily driven by metrics. I realize that CSSE and support organizations are budgeted for differently. I didn't mean to imply that your statement wasn't correct, I simply misassumed that it was being applied across the board. -Jack
991.140	no whoops required !	SCARY::M_DAVIS	Marge Davis Hallyburton	`Wed Feb 07 1990 19:28`	4
	Living by the metrics can be foolish at times; discussed elsewhere. If you read frustration in my reply, it was that... :^) Marge
991.141	What goes around, came around	NWACES::ROHNERT		`Thu Feb 08 1990 02:27`	73
	Re: .136, .0 "Hey man, it's not my job"... > >But when I got a copy of .0 in my MAIL yesterday with a bunch of forwards - >(Yes I know that violates policy and I'll be willing to turn the forwards in > to the Enet cops, as it's mostly all my upper management) >when I got that copy and read it I just couldn't resist getting back in here >on this one. > > Someone said, "What goes around, comes around", well it just came back. A few days ago I received my very own copy of the infamous note 991.0, many forwardings deleted, several subject headings remaining such as: Subj: Horror stories from the field Subj: Two customer support horror stories from the field Subj: no wonder the stock is at 77 Subj: IT'S NOT MY JOB!!!!!!!!! Subj: What can happen to DIGITAL when we say not my job or miss committments! Subj: interesting notes from the field Subj: Some real life stories Subj: SOFTWARE SUPPORT AND DELIVERY ISSUES NOTED Now this frosted me a bit as the message had dribbled through NAC Engineering and we work closely with these folks. I think what was most upsetting was that our responses were not included. But this is the killer, I happened to be the last person in the office this evening when I received a call from none other than KEN OLSEN'S EXECUTIVE HOTLINE requesting to speak to one of our support people or our manager. Mr. Scott, the author of 991.0 filed a complaint against ASSETS with K.O.'s office on January 29th. I assured the caller that Mr. Scott's complaint would be taken care of. Let's see now, we have four support people in Corporate Network ASSETS that support 4,956 registered users in the U.S., GIA and European geographies as well as process new submissions into the library. Now this field person in Minneapolis says that we should call his customers in U.S. Country and make a presentation of a very technical package to his customer, bypassing the Sales Rep., Unit, District and Area Support Organizations (which seems to be okay as Specialists now escalate problems directly to K.O.'s office). Now if four can do the work of thousands or even hundreds... Perhaps I do not understand what field specialists do so I extracted the first Specialist Requisition for the Minneapolis area from the Jobs book: >------------------------------------------------------------------------------- > 52AB SOFTWARE SPECIALIST 2 WC: 4 (Exempt) > Title: SOFTWARE SPECIALIST 2 Shift: 1 Travel: 25% Hours: 40 > >Recruiter: Jean Jacob Requisition Number: H325236 > E-mail: ANGLIN::JACOB Date: 04-JAN-90 > LOC/DTN: MPO 442 X 2043 Relocation Funds: Yes > > Job Site: MPO N CENTRAL DIST OFF MINNEAPOLIS, MN >Job Description: >This is a Sales Support position for a Desktop/Workstation team member. This >position requires close teamwork with our Sales Reps & district workstations tm. >in assigned accounts & projects. The primary focus will be DEC solutions in the >workstations market. Duties include understanding customer business problems & >developing & proposing technical solutions, technical product & SW presentations >to customers & providing technical support & consultation to Sales during the >sales cycle. 4 yr. college degree in Computer Science, Math, or equilvalent. >2 yrs. wksts. or desktop marketplace. VMS, C programming, & Unix/Ultrix >------------------------------------------------------------------------------- > Am I missing something? What are specialists supposed to do? Dick
991.142	Hmmm, I never thought of us as an amoeba before...	SVBEV::VECRUMBA	Infinitely deep bag of tricks	`Thu Feb 08 1990 03:43`	67
	re .141 I have another story to recount (that ended happily), but first, as to what a field person does. It is the responsibility of a sales support specialist to do all technical support related to the sale of hardware or software products, or services. The problems happen when the local person doesn't know the answer, and neither does any other local person. Things start going wrong as support requests go up the ladder, and with each rung in the ladder the response window has shortened. It sounds like the originator of .0 went through all the appropriate steps. [Question: was his manager doing the escalation?] The fundamental issue is that there is no place "where the buck stops." If I am a sales support specialist with a question I can't answer myself, there is _NO ONE_ in Digital whose job it is to make sure my question gets answered. It's even worse if you need to have service delivered for a week, for example. A couple of years ago [and this was the event that drove me out of unit management] we had a customer who was installing our interface to DISOSS, IBM's office mail system. We had a product, EDE-DISOSS to accomplish this. Our customer was the client's corporate headquarters E-mail technical support group. I needed to get someone in for a week to train them on our product, its setup, usage, and troubleshooting. I was the PSS (Software Services consulting) manager for this account. One week and two 8 1/2"x11" sheets of names/phone numbers later, I was taking ten or fifteen minutes of each conversation relating to the person whom I called how I tracked them down. In some cases, not even their co-workers or manager knew they had EDE-DISOSS experience -- it was their "deepest, darkest secret." When I couldn't get a satisfactory response (a warm body) out of the CSCs, I called the secretaries of the appropriate CSC managers to get more contacts. [PLEASE, PLEASE don't take this as a how-to-hint!!!] After two weeks, numerous dead-ends, and over fifty contacts, I found someone in California whom I flew in for a week -- who did an excellent job. So, why did I spend two weeks of my life on the phone? Because we had a customer and we _HAD_TO_DELIVER_ the service. Elsewhere, I recently saw a memo talking about needing to change the "attitude" of sales executives so they sell services without worrying about their delivery. This is all wonderful, but again, no talk of where the buck stops. I truly appreciate the frustrations of .0 and .141 -- several years ago someone tracked me down as a DV11 expert (I hadn't seen anything even close to one in at least 5 years) to solve a crisis, so I've gotten the heat and sufferred the frustrations from both sides. When we just sold products, our loose, non-hierarchical organization worked well to respond to point needs -- like an amoeba devours its prey. As we progress to being service providers, integrating internal (and external) products into solutions, we need to have a place where the buck stops, where the answer _MUST BE_ YES, WE HAVE THE ANSWER FOR YOU. Not "we don't know" or "we can't find a person." Personally, I don't care if it's a buck-stopper in each engineering group or in a separate group, but it desparately needs to be there. We've reached a point where "the best we can do" -- even if our best would make each of us in the support chain a "2" or "1" performer -- is not enough if it doesn't guarantee results. We need to get beyond the organizational amoeba stage. /Petes
991.143		SHAPES::KERRELLD	Dave Kerrell @UCG 781 x4101	`Thu Feb 08 1990 07:17`	12
	A few days ago I received a copy of .0 by mail which had come via some of the more senior European managers and then filtered down through numerous distribution lists. I forwarded my copy to Greg so that he was aware of the visibility this was getting. Something bothers me about the extent that this extracted note got forwarded around. Like if the forwarders used VAXnotes maybe it would save some network bandwidth and disk space and maybe they would get the whole picture. Everyone is focusing on the "it's not my job" phrase and not support available to the field. Dave.
991.144	Perfect example of how a free-market setup would help	PHAROS::DMCLURE	Your favorite Martian	`Thu Feb 08 1990 13:11`	9
	I can't help but wonder how many people would have been climbing over each other to answer those questions had they been able to market that information using the info-market idea (currently being kicked around in note 1024). -davo p.s. Think of an info-market as a system where "the buck starts here".
991.145	Lots of moaners, no fixers	SVBEV::VECRUMBA	Infinitely deep bag of tricks	`Thu Feb 08 1990 14:42`	33
	re .143 I share your uneasiness about how quick we are to spread the bad news, with no attempt to spread ideas to fix the problem(s) described. Every manager in Digital should be notes literate/or should minimally have the ability to monitor notes without doing it interactively. The _proper_ mail message should have at least included "See HUMAN::DIGITAL note 991 for an enlightening discussion." It's simple. Whose job _is_ it to fix these problems? There's another "parable" floating around the E-mail, about the stone-cutters/tool-builders of Latigid, which has seen the E-mail desk of just about all our top management. It bemoans the reluctance of sales to sell services because they doubt our ability to deliver. I've been really sick the last few days, but finally got it together to send the originator a response. My perception may be off here, but... we have too many people bemoaning our situation and no one seems to have the responsibility/authority to make some fixes. Management speaks of problems and solutions in general terms, but when it comes to _specifics_, mum's the word. About the only thing I've seen recently (and they've been advertizing their success _real_ hard) is the MRC, set up as a last-gasp-fix-customer-issues hotline. That's only the tip of the iceberg. re .144 I'm not sure I would _charge_ for information. However, I think an individual's or a group's willingness to contribute to Notes and to solve peoples' problems should be rewarded by management. The basic problem, lack of a _guaranteeed_ answer, would not be solved by info-marketing. /Petes
991.146	RE: .44	YUPPIE::COLE	So let it be NOTEd, so let it be done!	`Thu Feb 08 1990 14:49`	5
	I feel you missed the point of Greg's complaint. It wasn't just the info that was valuable, but it was the PERSON who was important! Getting the PERSON to talk to the customer was important. What Greg encountered was a lack of management attention to customer service and satisfaction, not some inherent secrecy of info.
991.147	For the record, I never contacted KO's office	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Sat Feb 10 1990 03:18`	108
	Every time I think I've seen it all I get at least one more surprise. Evidently, somebody extracted my base note, .0, and forwarded it to a few zillion people. They, in turn, forwarded their copy to a bunch of other people, who forwarded their copies to some more people, and on and on and on. Today, I think half the company has seen a copy of .0 and they are forwarding their copies to the other half of the company. Every day for the last couple weeks I have had 3 or 4 MAIL messages waiting for me from people who were forwarded a copy of .0. I've gotten messages from all over the US and, I think, at least one from England or someplace in Europe. This morning, I heard from my manager that I had logged a complaint with KO's office about ASSETS. I laughed - thought that was a good one. I was about to recount the latest Minnesota fish story when I noticed he was serious. He had gotten a call from an ASSETS manager (Dick, that was you) who told him that I logged some sort of complaint with KO's office. EVIDENTLY, SOMEBODY OUT THERE CONTACTED KO'S OFFICE, LOGGED A COMPLAINT, AND PUT MY NAME ON IT!!!!!!!!!!!!!!!!!!!!!! Needless to say, that really makes me MAD!! (stronger adjectives deleted) Folks, extract and forward any NOTES entry I put in to anybody you want. As far as I'm concerned a NOTES entry becomes DEC public domain when entered. But don't log complaints in MY name. If you want to log a complaint with somebody, use your own name. If I had wanted to complain to KO's office I would have done so several weeks ago - before the issue was settled with our customer. And, remember, the ASSETS issue was settled with the customer nearly two weeks before posting .0. re .141 - Dick, as we discussed on the phone today, for the record, I did not did not DID NOT log any complaints with anybody except my local management. And those complaints weren't personal, they were about the treatment we received and lack of support on lots of issues from more than one situation. And, as we discussed today, the ASSETS issue has long since been settled. We have also documented the manufacturing issue and sent that, via MAIL, to appropriate managers. But now you are being put thru the ringer, and you're forced to work thru midnight responding to NOTES, MAIL messages, and inquiries from people in KO's office. For what it's worth, my wife is mad at me right now for sitting in front of this terminal and responding to NOTES. She is in bed and I'm NOTING at my terminal in the other room. Probably the same situation you, Dick, were in a couple days ago at midnight. You asked what does a software specialist do. I can't tell you what everyone does, but here's a snapshot of my calander the last couple weeks. This is typical, except for all the out of town travel: Jan 29 - onsite Bemidji, Minnesota. (Come to think of it, I was 300 miles out of town that day. I couldn't have logged a KO call even if I had wanted to.) Jan 30 - onsite, Fargo North Dakota Jan 31 - St Paul (forget the hotel name) State of Minnesota Trade show Feb 1 - Onsite consulting University of Minnesota Feb 2 - Onsite, St. Cloud State University Feb 3-4, Saturday and Sunday - sleeping. Feb 5 - Interviewed a candidate Feb 6 - I don't remember, must've been important Feb 7 - In the office meeting with a customer Feb 8 - Quickie unplanned trip to Atlanta to plan an RFP response Feb 9 - Onsite at NSP in Minneapolis Both weeks are 50 plus hours. The schedule gets busier the rest of the month. And I think that's pretty typical of a Sales Support person. I think after our discussions, we both have a feel for what it's like to be in the other guy's shoes. I know you, like me, also have more work than you can possibly keep up with. Meanwhile, this story gets even better. This afternoon, I got a MAIL message containing, you guessed it, a forwarded copy of .0, from Dave Grainger. The message had been forwarded to Dave Grainger by Ken Olson, to KO from some other VP, to that person from somebody else, on and on several levels deep. I replied to Dave and told him the ASSETS issue was settled. I also told him the manufacturing story was good and offered to send to him if interested. We also invited him to visit the Mayo Clinic with us if he wants. Later this afternoon, I got a phone call from Abbott Weiss. Abbott introduced himself as the secretary to the Executive Committee. I assume that means the Executive Committee. He told me that Ken Olson had, in fact, seen the forward of .0. Not somebody on his staff, but KO himself. Abbott and I talked for a while. I told him the ASSETS issue was long since settled, and MAILED to him the manufacturing story. It's been a long day. - Greg
991.148	A couple other details I forgot to mention	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Sat Feb 10 1990 03:31`	10
	I forgot to mention, Wednesday I got a call from a person at the new Management Resource Center. That must've been Feb 7. I told him the ASSETS issue had long since been settled. I don't remember if I sent him the manufacturing story or not - I probably did. Sometime today I got another call from another guy in the Management Resource Center. And I told him that the ASSET issue was taken care of, and refered him to the first guy. - Greg Scott
991.149		BOLT::MINOW	Gregor Samsa, please wake up	`Sat Feb 10 1990 15:18`	12
	There's an old aphorism attributed to Mark Twain: The man who sets out to pick up a cat by the tail learns something that will always be useful and never grow dim or doubtful. What has Scott (or anyone else) learned from this? I hope it isn't "kill the messenger." Perhaps more interesing would be the question of what the Executive Committee learned -- the cynical part of me fears that the next specialist with a customer in trouble won't have an easier time than Scott. Martin.
991.150	risks	CALL::SWEENEY	Patrick Sweeney in New York	`Sat Feb 10 1990 19:21`	17
	Scott, for what's it worth, you've had, as Andy Warhol put it, your 15 minutes of fame (or infamy). In my past, I've gotten the KO office spotlight for saying in a conference, in effect, group A doesn't work with group B, and neither works with my group. Same modus operandi as yours, a note extracted, mail with forwards upon forwards and no action taken until everything had resolved itself anyway. The details were different, but I see a big resemblance to your case. Well, there's nothing that can grab the attention of a results-indifferent/ consensus-obsessed company that the implication that groups don't work harmoniously together. So don't even say it even if its true. On the other hand, your management probably knows your a super-performer and will cut you some slack.
991.151		KYOA::MIANO	Mad Mike's Mythical Miracle	`Sun Feb 11 1990 00:47`	8
	On the positive side it seems clear that the senior management of the company is truely concerned with the client satisfaction issues. Does anyone have any suggestions on how to improve the lines of communications? In DEC it seems that the distance from the front lines to HQ is very long. John
991.152		STAR::MFOLEY	Rebel Without a Clue	`Sun Feb 11 1990 19:53`	7
	RE: .151 At least it eventually makes it there.. That's better than some.. Although, there is something to be said for fixing the problem at the lowest level.. (Now where have we heard that before?) mike
991.153		BOLT::MINOW	Gregor Samsa, please wake up	`Mon Feb 12 1990 01:23`	17
	re: .151: > On the positive side it seems clear that the senior management of > the company is truely concerned with the client satisfaction issues. I'll believe that when "front-line" folk work 40 hour weeks and aren't booked 100% of their time; when they have adequate access to hardware, manuals, and training (access means both physical access and time), when engineers can spend a half-hour on the phone with a field specialist without worrying that their project will miss a deadline, and when we stop measuring client satisfaction and start listening to what our customers and field people are saying. If the "lines of communication" are long, perhaps it's because there's a perception that nobody is listening unless someone stands up and shouts. Martin.
991.154	What risk?	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Mon Feb 12 1990 04:04`	26
	re .149 and .150, I think What risk? I still have a job, a warm house, plenty of food, and a paycheck, as do we all. I don't have any plans to change my situation and nobody else has any such plans in store for me that I know of. Don't get me wrong. Nobody forced me into the schedule the last couple weeks, or the next few weeks. Most of this stuff I wanted to do. Believe it or not, I like my job and I'm generally happy here. I don't really mind the KO spotlight or the 15 minutes of infamy. Now that we've got the attention of the big boys, maybe we can influence some policies and attitudes and make this a little bit better place to work. My fear is that this thing has turned into a witch-hunt. If that's the case, then the whole thing was worse than a waste of time. I don't want anyone hurt. I want everyone to win from this experience. That is why I'm sharing it. I've been an optimist most of my life. I don't see any need to change yet. - Greg
991.155	Do DEC executives use VAXnotes?	PSYCHE::DMCLURE	Your favorite Martian	`Mon Feb 12 1990 13:56`	17
	re: .147, > This afternoon, I got a MAIL message containing, you guessed it, > a forwarded copy of .0, from Dave Grainger. The message had been > forwarded to Dave Grainger by Ken Olson, to KO from some other VP, > to that person from somebody else, on and on several levels deep. > I replied to Dave and told him the ASSETS issue was settled. I > also told him the manufacturing story was good and offered to send > to him if interested. We also invited him to visit the Mayo Clinic > with us if he wants. I wonder if some of this mail message mania might have been avoided if Ken Olsen, Dave Grainger, along with the rest of top level management simply took a peek into this notesfile from time to time? Wouldn't it be easier than trying to filter through forwarded mail messages? -davo
991.156	I vote a daily extract	SVBEV::VECRUMBA	Infinitely deep bag of tricks	`Tue Feb 13 1990 03:04`	9
	re .155 So, should we send them daily extracts? They probably get over 100 mails a day, at least. What's one more? :-) Davo, we agree!! /Peters
991.157	Some companies are still limited to mail only - can you imagine?	PHAROS::DMCLURE	Intra-Corporate Entrepeneur	`Tue Feb 13 1990 12:19`	21
	re: .156, > So, should we send them daily extracts? They probably get over 100 mails > a day, at least. What's one more? :-) Well, we could I suppose, but I'd really rather ween our corporate executives from mail message mania altogether and entice them to join the rest of the company here in the notesfiles. If nothing else, they should at least consider using a [restricted] notes conference for their communication amongst one another. Maybe after they got the hang of noting amongst one another for awhile, they might develop the confidence to come out and address the rest of us here in the public notesfiles. Of course, this all assumes that they aren't already doing just that. ;^) > Davo, we agree!! Most everybody agrees on something. It's just so fun to argue the fine points that most agreement ends up looking somewhat violent (hence the popular phrase "violent agreement")! -davo
991.158	BTW I suspect that some high level people do occasionally get extracts of some topics	CVG::THOMPSON	My friends call me Alfred	`Tue Feb 13 1990 13:44`	7
	I wouldn't suggest sending daily extracts unsolicited BTW. For people who probably get 50-100 mail messages a day already that would be annoying. Still if any VP level people wanted to get a daily extract I'm sure I could arrange it. Have them send me mail or give me a call. Alfred
991.159		SVBEV::VECRUMBA	Infinitely deep bag of tricks	`Tue Feb 13 1990 20:53`	12
	re .157 We'll never be totally paperless. It's actually more efficient (for the manager's time) to have their mail printed, they toss what they're not interested in, jot some short notes on mail which needs follow-up, and then personally respond [needing to be at a terminal] to only a small portion of their total mail. Paper, alas, is still the only truly portable medium. /peters
991.160	The whole shipping story	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Wed Feb 14 1990 03:19`	232
	There seems to be a lot of interest in our manufacturing problem at the University of Minnesota. I wrote down everything I could think of a few weeks ago. Here it is. Names are ****'d out. Comments in parens () are added by me for clarification, since some sentences don't make sense without the names. I've sent the following memo, unedited, to all the people from mfg who called or wrote to me. So far, not much feedback on this one. - Greg Scott I N T E R O F F I C E M E M O R A N D U M Date: 18-Jan-1990 01:46pm CST From: Greg Scott SCOTT.GREG Dept: MPLS SWS Tel No: DTN 442-2063 TO: See Below Subject: Getting Jerked around on U of M Colon Cancer shipping *, ** - (local CAS people; comment added for NOTES) You asked me to document this, so here is everything I know of first hand. The whole story, with input from all the players, is even more unbelievable. Here are the DEC numbers: 90Q40919H 90Q40854H The shipment of products for the Colon Cancer Control Study order at the University of Minnesota has been nothing but a comedy of errors. The Sales team spent most of the last year building credibility at this account, now much of it is messed up because of these shipping snafus. , *, **** - (people from mfg suggested by CAS; comment added for NOTES) I work for Software Services and Sales Support here at MPO. Part of my job is to provide onsite help to our customer and try to get them up and running while all this is going wrong. Digital's shipping snafus are making that job less fun than it should be. As you can probably tell, I am extremely frustrated with this situation. *** **, CAS Manager here at MPO, gave me your names. She said you guys have authority to make all this right. If you don't* have authority, would you please forward this memo, or raise cane, with somebody that does have authority? Or, just tell me who in Digital has authority to make this right and I'll talk to them. We've written several memos to lots of different managers trying to elevate this situation. So far, not much luck. What follows are extracts from them and an update on where we are today. ******************************* The following describes how we got to this situation. This is extracted from a memo sent to management in mid December, 1989: After officially putting in the order, Manufacturing promised a "committed" ship date. The sales rep called the customer and told them the ship date. The customer then made plans to receive the stuff and coordinate everyone they needed, including pulling the cable over a weekend. The Sales Rep also lined up hardware installation from our Customer Service. When manufacturing failed to meet their committed ship date, they gave another ship date. The Sales Rep informed the customer and our service organization, and everybody changed their plans. Well, this happened 5, count 'em, five times. We've been promised 5 ship dates and each one has failed. Not only has manufacturing failed to meet 5 promised ship dates, the only way we have been able to find out is for our CAS people to keep calling to find out where the stuff is. Well, now, after spending most of a year building our credibility with this customer, they are starting to wonder if they should trust Digital as a vendor for their operation. As a vendor, if we can't even ship hardware when we say we're gonna ship it, how can we possibly manage the much larger task of "Enterprise Integration" we brag about? I'm not talking about long delivery times here, I'm talking about keeping promises. The only weapon we have here in the field is credibility. When Digital makes a commitment to a customer, then fails to meet that commitment, Digital's credibility goes way down. When Digital fails 5 times to meet a commitment, Digital's credibility goes waaaaay down. Our name isn't mud yet with this customer but it's close. It took almost a year to gain some credibility, it took a couple weeks to blow most of it away. *********************** Somewhere in here is an issue about the correct kind of truck. I was not in on this first-hand. Our customer does not have a loading dock, and so needs a delivery vehicle with a lift gate. We gave instructions to this effect, but, of course, the original partial shipments arrived on a truck without a lift gate. **** ** (local Sales Rep - added for NOTES) has details on this issue. ********************** Next, the following was written last week and forwarded to CAS to escalate. I N T E R O F F I C E M E M O R A N D U M Date: 11-Jan-1990 11:04am CST From: Greg Scott SCOTT.GREG Dept: MPLS SWS Tel No: DTN 442-2063 TO: *** (local Sales, CAS, and management; distribution removed) Subject: Colon Cancer shipping - please escalate ** - This is the memo you asked me to write on the Colon Cancer situation. For fiscal reasons at the University, the Colon Cancer equipment was purchased in two separate orders. This, in turn, generated two separate DEC Nuumbers, which, in turn, has caused all kinds of headaches. The first order contained a VS3100 model 48 and a bunch of software. The second order contained a MV3800. Since, at the time of the order, we were assured that the model 48 was available for immediate shipment, the idea was to use the model 48 as a boot server until the MV3800 order arrived. Unfortunately, after sending the order, we found out that the model 48 could not ship until the second or third week of January. The latest date is either Jan 12 or Jan 19. Although **** (local sales rep; added for NOTES) has all the gory details, the bottom line is, the customer has been jerked around by Digital every which way but Sunday. As you know, Digital has repeatedly promised ship dates for various parts of the order, only to break those promises the next day. Unfortunately, with each "commit" date promised, the customer and local office made plans to prepare for installation. And, at least five times, we learned that the commit date would not be met and we were forced to change our plans. Needless to day, Digital's credibility with this customer is dropping. Here is a typical example of the treatment received so far by this customer. They ordered two LN03R Postscript printers and one LG31 printer. Depending on which documents the customer looked at, they were scheduled to ship 2 day air on either Dec 8 or Dec 18. Evidently, some documents had one date, some had the other date. On Thursday, Jan 4, the customer called the local office to find out where their printers were. The printers were traced to "somewhere in Chicago", and were promised to be onsite by the next day. The LG31 printer arrived sometime on Monday Jan 8. The LN03R printers arrived either Tuesday, Jan 9 or Wednesday Jan 10. Today, the MV3800, postscript printers, and most of the other hardware is onsite but with no software. The software is still not scheduled to ship until the middle of January sometime. Although Manufacturing has been repeatedly told different, Manufacturing evidently believes the software belongs with the workstation order. In many cases a few weeks deviation on shipping schedules would not matter. However, the situation is different for this customer. They are currently buying time from a CDC machine at another site. They want to run their own computer operation because they can save money and have more flexibility. But without software, they cannot do development, they cannot use their postscript printers. And Digital loses credibility every time we break a commitment. In addition to hurting the customer, the problem is also hurting Digital in the pocketbook. The Colon Cancer Control Study works on a five year budgeting cycle. This means, every 5 years, the National Cancer Institute gives them a pot of money to last the next 5 years. Right now, they are into year 1 of the current 5 year cycle. Every day we delay shipment is one more day they must buy time on the existing CDC platform. This means they are forced to spend money elsewhere, instead of spending with Digital on their own computer operation. Anything we can do to resolve this situation and get the rest of the order shipped in a timely manner would be greatly appreciated. Thanks, **, for escalating this situation. thanks - Greg *************************************************************************** Since sending the above memo, believe it or not, the situation has gotten worse. When I arrived onsite on Monday Jan 15, our customer showed me several boxes of terminals, keyboards, and an RZ56 disk drive that had arrived. They showed me boxes that looked like they had been hacked by a chainsaw. Many boxes had holes punched in them. The big box with keyboards had such a nasty hole punched in it that it also punctured the little boxes inside. One box has a gash all along the face. Most of the rest of the boxes were crunched or punctured in some way. As of the end of the day yesterday, none of the boxes had been unpacked. Therefore, we don't know the state of the equipment inside the boxes. I checked, and yes, our customer did note the condition of this shipment with the shipper when it arrived. Meanwhile... We were told by Manufacturing that the rest of our customer's order had shipped on Monday Jan 15. It was shipping two day air, and the ETA on the documents we received said the products would arrive on Wednesday Jan 17. Based on what these documents said, we told the customer to expect their stuff on Jan 17. We should have known better. Wed Jan 17 came and went and nothing arrived. On the morning of Jan 18, our CAS department made some phone calls to find out what happened this time. Imagine our surprise when we were told that two day air does not really mean "two" days. We were told that the order should be at the Minneapolis Airport by 8 AM Friday Jan 19, 5 days later not 2 days later. It would arrive at the customer site sometime after that. It seems that American Airlines has problems dealing with large shipments, yet we continue to use American Airlines. Words really cannot express how frustrated I am by this. I now get the pleasure of telling our customer, again, that the date we promised will not be meant. This is at least the seventh, count 'em, SEVENTH, time we have had to do this! Is anybody out there listening? - Greg Scott Distribution: (names removed for NOTES)
991.161	I would elevate this through sales	CSSE32::RHINE	Jack Rhine, Manager, CSSE/VMS Group	`Wed Feb 14 1990 10:49`	7
	REP: -1 I would think that Dave Grainger would want to know about this situation. I'm sure that yours isn't the only case. This kind of garbage is impacting DEC's ability to sell because we lose the credibility to deliver to the customer.
991.162	life in the field...	DELREY::PEDERSON_PA	FranklyScallopIdon'tgiveaclam	`Wed Feb 14 1990 12:23`	10
	Greg, Your situation sounds horrible! Unfortunately, problems like this occur....I know. I'm in CAS in TFO and see similar horror stories (how 'bout the one where...no, nevermind. I don't want my note extracted and forwarded to KO's office). pat :-)
991.163	I'm impressed aren't you? No wonder our customers don't rely on us	CVG::THOMPSON	My friends call me Alfred	`Wed Feb 14 1990 13:13`	26
	Problems like this happen? Often? Well what is anyone doing about it? I wonder how often things like this happen. Wait I know! I'm in a manufacturing plant and I seem to remember some customer satisfaction stats being posted. I'll go look. OK, here's what I found. (BTW, I don't know what products this is for). Schedule to request - week is running around 40% Ship to schedule week is running around 60%. This appears to mean that we only schedule to ship it the week the customer wants is about 40% of the time and then we only hit what ever target we set about 60% of the time. SO I guess we get it there the week the customer wants it about 24% of the time. I'd concider that a problem. I suspect our customers do as well. Are other manufacturing plants this good? BTW, it appears that Salem sechedules for the month a customer wants about 70% of the time. The hit rate for ship to schedule month is about 97%. Still a month seems a pretty big target to miss. These stats have stayed pretty constant or gotten worse over the six months that are posted. Alfred Side note: Once when I was a customer DEC gave us a ship date of 31 September. Not surprisingly it didn't ship on that date. :-)
991.164	FYI	WMOIS::DRIVETTS	Dave Rivetts, WMO, USCD, 241-4627	`Wed Feb 14 1990 14:10`	18
	There is a new Notesfile Conference called ODIXIE::OMS which is set up to resolve problems. The conference is being looked at by Manufacturing and Field OMS to be used to communicate problems and issues. Manufacturing is looking at having individuals in all mfg. sites and business groups reading the notes that get entered into that conference and setting some "Norms" as to response time and acknowlement. Currently it is all unofficial, and the norms are being established, but if anyone has a Customer Satisfaction issue, or would like to share a problem that keeps on repeating, you may enter a note in that conference and a lot of manufacturing people will be reading it. I believe issues will be addressed real quick. It is difficult to sweep notes under the carpet before people know about it as witnessed by this note. Dave
991.165		WMOIS::FULTI		`Wed Feb 14 1990 14:57`	10
	Call me a "hardliner" if you want but, I feel that as long as people have the attitude that this sort of problem should NOT be brought to K.O.'s attention then we will continue to have it. Maybe a few heads SHOULD roll! Maybe then the people who are responsible will get the message that the customer IS our main concern. I agree that whomever made the complaint to Ken's office about Greg's problem should have done it under their own name but, I do agree that it should have been done. Maybe now the next salesperson won't encounter that problem, notice I said "maybe". - George
991.166	Adding insult to injury	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Thu Feb 15 1990 02:51`	37
	One interesting addendum to the shipping fiasco: Since we could not get software to the customer in a timely manner using normal channels, we ordered stuff internally to bring to the customer. We needed a copy for our use in the local office anyway. The software was PCSA client and VAX/VMS Services for PCs. The internal order process worked fine - fastest turnaround I've ever seen on any order. I told the people in SBB that this was a critical situation on a Thursday, and they got software to me by the next Monday. The customer and I agreed that they would keep my copy and we would take back their copy when it finally arrived. We did that a few weeks ago. Today, I opened what should have been the PCSA Client documentation, received from the customer. The box was still sealed from the factory. Part number printed on the box was QA-0TLA-H5 3.0 2/2. This is the correct part number for PCSA Client. And, in fact, the box labeled 1/2 contained the correct stuff. Unfortunately, the books inside the box I just opened, box 2/2, were not PCSA Client documentation, they were VAX Workstation Software documentation. I was so mad, I nearly put my foot thru the wall. Oh, yes... re .161 I think When I replied to Dave Grainger, I offered to send him the mfg story. If he wants to see it, all he has to do is ask. Today, I got a MAIL message from somebody who was forwarded my reply to DG and asked me for the story. That was just after I opened the box above. I forwarded a copy of the story to him, along with the interesting addendum. - Greg Scott
991.167		ASDS::NIXON	Me ... Forweird??	`Fri Feb 16 1990 00:27`	22
	> <<< Note 991.166 by MUSKIE::SCOTTG "Greg Scott, Minneapolis SWS" >>> > -< Adding insult to injury >- > > When I replied to Dave Grainger, I offered to send him the mfg story. > If he wants to see it, all he has to do is ask. Today, I got a MAIL > message from somebody who was forwarded my reply to DG and asked me > for the story. That was just after I opened the box above. I > forwarded a copy of the story to him, along with the interesting > addendum. Greg, Why wait to send the rest of the info to Dave Grainger? Is it going to accomplish anything if he doesn't see it? Might it possibly help if he does? I know if I were in your shoes, the info would already be on it's way. But then, I do have a tendency to speak up about things even when it's difficult to do. Maybe if we all started speaking up to the right people we could get some of these problems solved. Vicki
991.168	Making Digital a better company	FEGPX::SWEENEY	Patrick Sweeney in Hong Kong	`Wed Feb 21 1990 09:23`	20
	Nobody in CAS or Manufacturing wants to be told by a nobody in Software Services (Gregg and I have approximately the same job), that they are doing a poor job, moreover that they are doing such a poor job that this is going to escalate to Grainger/Olsen visibility (GO/V). Nobody gets nominated into the Pentagram of Perfection for writing those detailed memos that are the horror stories of customer satisfaction. The pushback here will be to the sales rep and Gregg for not setting the customers expectations low enough to meet the actual performance delivered by Digital. As one movie put it in other words, "You screwed up, you trusted us". Setting expectations low is a theme of account management. Pulling Digital up, setting the expectations of Digital employees that need to meet those high expectations of the customer is a task that requires a reordering of the companies priorities. Pat Sweeney
991.169	Its time to duck responsibility again I see.	CSOA1::ROOT	East Central Area Product Support	`Mon Feb 26 1990 16:23`	19
	Flame -on- It seems to me that we set the customers expectations way to many times and if CAS or Manufacturing does not like the heat then try producing to meet the customer expectations you help set in the first place. When we screw up we like to do it royally but when we deserve the heat then its time we get it hot enough to do some good. If that means going to Dave grainger or Ken himself on a internal escalation then so be it. If the source of the problem is your organization then yes its your job and those you work for to take the heat for the problem. The problem is finding those responsible to take the heat since no one wants to take ownership for the problems they help create. (Ie. Its not my job man). Personally I'm tired of having the field (destination) having to suffer for problems that originate at the source. Flame -off- Regards AL ROOT
991.170	re: 169 what are YOU doing to help!?	DELREY::PEDERSON_PA	FranklyScallopIdon'tgiveaclam	`Tue Feb 27 1990 13:45`	23
	RE: .169 FLAME ON HIGH EXCUSE ME?!?!! CAS does not set customer expectations....we are problem resolvers. We process orders, deal with customers (both internal and external), and try to make the customer invisible to our internal paperwork flow! CAS DOES NOT "duck responsibility"!!! I entered a note ackowledging that there is a problem, suddenly the last few notes target CAS and manufacturing as the problem area!!! Do not point fingers at groups for which you obvoiusly know nothing about!!! We (DEC) are a company that has some internal mis-communications... we ALL should try to better the communication instead of getting on your soapbox and blaming!!! FLAME ON LOW SIMMER pat
991.171	Scapegoats are too easy to find	MUSKIE::SCOTTG	Greg Scott, Minneapolis SWS	`Thu Mar 01 1990 02:17`	27
	I started this whole bru-ha-ha, and I really must defend our local CAS people also. The CAS person who "owned" our customer with the shipping problem busted her rear end to try and find out what was going on. She has spent countless hours documenting the details of what happened. This included finding shipping waybill numbers, DEC numbers that generated other DEC numbers, and a whole slew of stuff. She tried to explain how our mfg system works to me one day last week. We both agreed the system is so complicated, nobody understands it. And neither of us could figure out the reasons for some of the steps to get an order from Digital to a customer. I expected to find the system filled with a bunch of bureaucratic inertia and people who just didn't give a hoot. I was wrong. From the memos and other stuff I've seen, it seems the system is filled with lots of people who work hard and try to do the right thing. All the people I've talked to about this problem seem genuinely concerned and want to fix it. But the system broke down in this case. Right now, I think half the company is trying to figure out why the system broke down, and then how to fix it. It's too easy to say, "such and such a department is lazy, and it's their fault." I don't think that is the case with our shipping problem. I don't think we will find a convenient scapegoat. - Greg Scott
991.172	The problem is "process", not motivation	SVBEV::VECRUMBA	Do the right thing!	`Thu Mar 01 1990 02:54`	42
	re .171 > She tried to explain how our mfg system works to me one day last > week. We both agreed the system is so complicated, nobody > understands it. And neither of us could figure out the reasons > for some of the steps to get an order from Digital to a customer. > I expected to find the system filled with a bunch of bureaucratic > inertia and people who just didn't give a hoot. I was wrong. From the > memos and other stuff I've seen, it seems the system is filled with > lots of people who work hard and try to do the right thing. All the > people I've talked to about this problem seem genuinely concerned and > want to fix it. But the system broke down in this case. Right now, I > think half the company is trying to figure out why the system broke > down, and then how to fix it. I spent two years as a unit manager, and I have to agree. It goes back to the comments elswhere about "process", and how "process" is no longer supporting people in getting their jobs done. For example, when X was first coming out, I wanted to order the videotapes from the X seminar being held at MIT. They wanted a check. I could not get a check cut -- only a purchase order -- because there was no process. _Everyone_ involved was frustrated. In the end, we wound up not getting the tapes (it would have been a $500 outlay up front). The issue is not intertia, it's (my pet peeve) metrics. Administrative type functions in particular are measured on the _LACK OF EXCEPTIONS_. And roundly denounced outside "guidelines" -- even if every exception helped Digital's business. If you need to do anything inside Digital, and it can't be wrapped and tied up with a bow in a pre-approved "box", then all hell breaks loose. My hat's off to the group (MRC?) that's been formed to work these "box" issues -- to solve whatever the customer situation is. The one thing, though, that should be the PRIMARY charter of the MRC is to actively plan for and single-mindedly pursue its own obsolecense. We will never be able to effectively, no, _exceptionally_ react to our own internal needs or to our customers' needs until we break the metric mold. /Peters
991.173	customer satisfaction: you knew what it was	HGSW34::SWEENEY	Patrick Sweeney in Hong Kong	`Thu Mar 01 1990 10:27`	28
	I hope this doesn't sound as if I'm Peters' twin here, but the "process", ain't it something? (1) It insures that groups internally don't get "emotional" and don't get "hard feelings" (we couldn't have that) (2) No one internal group is solely "to blame", no one internal group is held accountable to the customer, no one group need fear that "they let the customer down", everyone blames the system and no one is empowered to change it. It blows over in a week anyway. (3) Everyone is accountable, no one is accountable and let the nail that rises from the floor be hammered down (4) The only one with the "emotions" at the conclusion of the "process" is the customer. Hey! What can I do? Let them call Ken Olsen. It shouldn't be this way and it doesn't have to be: Customer satisfaction cannot measured by a survey. And we've been deluding ourselves all these years that we've been doing so. Customer satisfaction is how often a problem pops up and what the company is gonna do to "make it right" when it happens. Everyone I speak to knows that this really is customer satisfaction whether you're buying a house or a hamburger. Getting this sort of common sense into Digital, well, that's another matter.

Conference 7.286::digital

991.0. ""Hey man, it's not *my* job"..." by MUSKIE::SCOTTG (Greg Scott, Minneapolis SWS) Thu Dec 28 1989 03:26

991.0. **""Hey man, it's not my job"..."** by MUSKIE::SCOTTG (Greg Scott, Minneapolis SWS) Thu Dec 28 1989 03:26