Conference 7.286::digital

    We need one system that can be accessed and updated realtime.  This
    system needs to be available to evryone in sales, services, billing,
    accounts recievables, etc.  I'm thinking out loud here.  Two systems. 
    One dealing with revenue generation and one which deals with
    expenditures/purchasing.  Different people in different groups could
    have different functions (read only, interactive, reporting) as needed.  
    
    Airlines can see who's doing what and at what time on the other side of
    the country, why can't we? 
    
    This may be an expensive undertaking in the outset, but I truly believe
    that in the long run it would pay itself off many times over.  Our
    customers would ba able to do business with us easliy.  I also think
    this fits in very well with the business units.
    
    Mike

I have two thoughts (not bad at my age):

	First and foremost, we need to streamline policy and procedure.
	I am not talking about any of these that are mandated by law
	or necessary to do government business.  I am talking about the
	way we do things because that is the direction in which Digital
	has grown.  We are crazy for documentation, paper, and layers
	of redundant functionality (which sometimes come from our 
	current penchant for double-checking the double-checkers work).
	This is accomplished a little piece at a time.  First on a local
	level, check every piece of paper needed to accomplish a task,
	evaluate its necessity and act on that information.  If it's
	not vital to either legal audit regulations or the task at hand,
	trash it!  I recently tried to get billing for 10 hours of work.
	The OMS person got a memo and a P.O. from the customer, and a
	signed CLAR, but this wasn't enough.  Still needed a quote.  How
	much paper really is necessary (very small example)?

	Second, *I think* we add too many dollars of risk to customer
	quotes.  Believe it or not, some of that risk is in case we
	deliver our OWN equipment or services late.  Maybe it's just
	me, but *I think* we should live up to our commitments and not
	quote extra money in case we don't.  So, if we deliver everything
	on time, we got a bunch of extra $$ for thinking we wouldn't?  I
	think our bids could become much more competitive...

Barb   

    Bravo .1!! You hit it right on the head.  The admin systems by which
    we attempt to measure revenue against expenses against the phases
    of the moon are so poor as to literally be dangerous.  Beyond our
    apparent inability to spend a dime to fix the problem, it blows my
    mind that our auditors actually allow us to get away with it.
    
    So we continue to live in a sea/swamp/quagmire of allocations, which
    continue to provide more-than-adequate hiding places for the
    unprofitable parts of this company.  Maybe L.L. Bean could show
    us how to do it...y'know, how to use computers.

    Re .1,  We could start by simplifying the business rules.

    E.g. How many different "Digital" codes and numbers have to be
    assigned to even simple orders?  and does anyone have any idea how
    many DEC rules and policies apply to the simplest of orders as
    they work their way through the various Digital computer systems?

    It would also be an eighth wonder of the world if we could drag
    ourselves out of the pricing zoo we have created...MLP, CLP, SLP...
    ad infinitum.  I do pricing, and I get confused.  God help the
    field and our customers.
    
    Can anyone see themselves buying a car or TV that way??
    
    

    I totally agree with all of the above. I especially feel the need for
    .0s idea. Ever try to find technical/sales data. If you don't get the
    literature on your desk you have a hard time being informed. Im in CS
    in Washington DC and spend a several hours a week trying to get thru
    on the ENET via NOTES and access info, either sales/CS info. The ENET is 
    great but can't it be more centralized. And most of the conferences
    are just discussion areas with no one accountable to listen and fix problems
    that we in the field see every day.
    
    DEC has come a long way as far as disseminating information to its
    employees in the field. Hopefully the new laptops will make it even 
    better and more "realtime".
    
    	Mike Turro
    

    Digital employee:
    
    Okay Mr/Ms Customer, you have now bought some DEC gear.  This is you
    MOF number or your order number.  This is not to be confused with your
    system serial number, which you will need to log calls for service. 
    Your hardware service will be assigned a hardware services Digital
    agreement number, however, you cannot use this hardware agreement
    number to log service calls.  You will also be assigned a software
    agreement number for your software maintenance contract.  You will not
    be able to use this software agreement number to obtain software
    services via telephone, to do this you will need to obtain your access
    number which we cannot give you now, but you will get it once your
    software services contract is proccessed.  Any invoice questions you
    may have, please be sure to note your invoice number.  Any questions?
    
    Customer:
    
     AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!
    
    (end of scenario)
    
    Didi I miss anything?
    
    Mike

    Does Delta work and how does it work?
    
    Saving Digital; eliminate the redundant adminstration/overhead would
    be a good start.  Allow more ideas to flow to the right people and
    allow us "to do the right thing for the customer".
    
    

    All of the previous replies have merit. It is good to look at systems
    and administrative proceedures and try to fix them. We (DEC) also need
    to humble ourselves and become less concerned with our own sales
    budgets and goals. When a customer calls DEC for a $10000 PC network we
    should not be trying to get rid of them because we have a $2 million
    budget and PC's won't make it for us. 
    Resolve to listen more and to talk less, no one ever learns anything by
    talking.
    Do not equate money with success. There are many rich people who are
    miserable.
    Be cheerful and helpful. People will repay you in kind.
    Humble yourself, if that's what it takes for customer service.
    
    

    If we could just ban the phrase "world class", which seems to be
    every product groups latest hot button....and just dammit doit ....
    that would be a great start.

    1) Number all kinds of transactions with customers, suppliers, and
    among internal entities sequentially, regardless of type of
    transaction.  Identify transaction type in a separate field.
    
    2) Number all kinds of materials we buy, make, sell, transport, etc.
    sequentially, regardless of material type.  Identify material type in
    as separate field.
    
    These rules have been found effective in keeping things simple.  Over
    and over we violate them by defining new transactions, new systems, new
    products with "meaningful" names or numbers.  Whenever you question
    this (as experts in manufacturing and inventory systems usually do),
    the answers you get are:
    
    1) Too much has been invested.  Therefore we can't afford to improve.
    
    2) "Meaningful" part and transaction numbers make it easier to sort the
    data.  This is an excuse which applies to manual, not automated
    systems.
    
    3) We've always done it this way.
    
    Sigh....
    
    Dick
    

    In the note about three back someone used the example of the various
    serial numbers and contract numbers and etc etc that customers get and
    need, well I have an even better one.
    
    Have any of you ever tried to order software from us? Yea we all know
    we need license, H-kit, documentation, software maintenace, updates,
    phone support etc etc...
    
    Well think of the last time you bought a software product for a PC, you
    went to the store and came home with a little box with everything you
    needed, and maybe a little card to register for support if offered.
    
    Now why can't a company as computer rich as Digital figure something so
    simple?
    
    	One part number for :
    
    	License
    	Media
    	Documentation
    	Maintenace
    	Updates
    	Phone Support
    
    	very simple right! Wrong I submitted a DELTA idea for that six or
    eight months ago and it has been forwarded from one group to another
    with one willing to bit the bullet and take on AQS.
    
    This would save time and money for our sales reps and our customers but
    it seems to much to ask.
    
    These are the kinds of things that should be easy to fix in Digital.
    
    Frank

Two interrelated suggestions:

(1) make decisions

(2) take calculated risks

--PSW

    How about in the area of problem reporting/resolution.... I think there
    are hundreds of trouble tracking systems being used in this company.
    
    I know that here in the Colorado/CSC, there are two (at least) that 
    are used, just for our particular calls. When the CRRs get the call
    into the center, from the customer... The CRR has to log it into one
    system, which is there tracking system... Then turn around and log it
    into the system that we are using, so we can keep track of and handle
    the call. Now, from what I understand, both are a form of CHAMPS, but
    neither is compatible with the other.
    
    WHY not create and utilize one trouble tracking system that can be used
    to track problems across the country/world. 
    
    Also along these lines. It seems that any particular customer can have
    several "access numbers" which are utilized for the various products
    they may have (i.e. software, hardware, networks, sna, desktop, etc.).
    Why not create a numbering system which would assign one access number
    to a customer, and as an identifier of each product, have a variant at
    the end. 
    
    Again, centralized trouble tracking databases, to assist in avoiding
    "reinventing the wheel".
    
    Bob G.
    

    .14 has summarised, for me, one major part of Digital which we need to
    fix - the multiplicty of different ways of doing exactly the same
    thing.
    
    Other replies have mentioned the different identification references
    customers have to use to identify themselves.  In manufacturing we have
    umpteen different systems for data collection/BOMs/MRP systems/document
    tracking/quality reporting etc. etc. (and that may well be in the one
    manufacturing site supporting different business units!).  Engineering
    use different design tools.  Admin uses different support systems.
    
    All of these differences require huge amounts of overhead to support
    them AND EACH IS PERFORMING EXACTLY THE SAME FUNCTION.
    
    The solution:  STANDARDISE (where applicable)!
    
    Why should some manufacturing sites be using PIOS as their MRP system
    when others use MAXCIM?  Why should one design group use MDB for it's
    data system when another uses MDA?  Why should one engineering function
    use EUCLID for product design when another uses Unigraphics?  The list
    is endless.
    
    From my understanding, this situation is a result of Digital's ethos
    which allows freedom to individuals thereby hoping to capitalise on
    their creativity.  This was fine when we were a small group of
    dedicated engineers whose strengths were in their leading-edge,
    creative products.  Now we are a multi-national, massive organisation
    which is out of control and which needs to be brought INTO control.
    
    MAINTAIN the freedom and personal choice where creativity is required.
    
    IMPOSE control and standardisation where this is needed.
    
    ELIMINATE the overhead of supporting multiple systems/methodologies.
    
    Mike

    
>    I know that here in the Colorado/CSC, there are two (at least) that 
>    are used, just for our particular calls. When the CRRs get the call
>    into the center, from the customer... The CRR has to log it into one
>    system, which is there tracking system... Then turn around and log it
>    into the system that we are using, so we can keep track of and handle
>    the call. Now, from what I understand, both are a form of CHAMPS, but
>    neither is compatible with the other.
>    
>    WHY not create and utilize one trouble tracking system that can be used
>    to track problems across the country/world. 
    
 	This is just how it worked when I started working for Digital in
    	Sweden a year ago, at the Service Center, which seems to be what
    	you call CRR. We had one logging system, and then sent the calls	
    	on to three different CHAMPs.
    
    	But last November we implemented NICE (New Integrated Callhandling
    	System for Europe). This is one system where we log the call, and
    	send it on to different queues, depending on whether it's software
    	or hardware. It's very easy to keep track of everything that's
    	been done to a service request, which engineer has been working
    	on it, what have logistics done, and so on.
    
    	I don't know if NICE has been implemented all over Europe yet, 
    	but it is designed to handle a transfer of calls between 
    	different countries in the future. 
    
    	If Europe could do it, I guess US could to...?
    
    	Hans

    re .12  To be perfectly honest, the part numbering system we presently
    have for software comes as close to being a single part number for
    all the things you mentioned as there could be.  It's not that hard
    to understand, and it works quite well.  Assuming that not all of
    our customers want the same things....I can't think of any better
    system than the one we presently have.

    Re: .17 answer to .12.....
    
    .17 is right on the money.  It sounds so simple, one part # for
    everything.....in doing that we *are* forcing customers to purchase
    more than they need.  We've tried it before and we still do this for
    some 3rd party SW, but it doesn't allow much flexibility.
    
    A few years ago when we first introduced that concept for SW that
    ran on Rainbows, DECMates, etc......we had a bundled package....sales
    reps didn't like that because it was killing them with the installed
    base customers.  The numbers were usually QBxxx-xx....these numbers
    included the licenses, plus media & doc; the numbers did not include
    services.  Usually what we heard in my support group was that an
    existing cust had 500 employees with DECMates......500 licenses would
    be appropriate, but say the cust could get away with 25 sets of media
    and doc <------ there was no way we could provide this because of the
    bundled packaging on any of the SW that ran on the PC......so customers
    were forced to purchased 500 sets of media & doc (whether they wanted
    to or needed to).  Made for a lot of unhappy campers.
    
    As for seperate access numbers....again, installed base accounts have
    tons of HW supported out the CSCs.  Once it is determined that a HW
    problem definitely exists, the CSCs log calls to the local offices,
    electronically.  Imagine a FS person trying to locate one VAX out of
    20 if they were all registered using the same access number (or worse
    yet, swaps a board in the wrong machine).  Separate access numbers
    equate to separate serial #s for CPUs.
    
    I now work with Remote Sales Support.....on the team that handles
    SW licensing, services and warranty :-)  A few weeks ago I spoke to
    a young man who said he wanted to do a sanity check....he said he 
    was a new sales rep....fresh out of training.  He rattled off those
    QL numbers for licenses, QAs for media & doc....and QTs for service;
    I must admit I was impressed!!!  When I told him so, he explained that
    he had formerly worked for a DEC E/U - JPL, as I recall.  When I asked
    him what he did at JPL.....he said he had been an engineer, 'nuff
    said??   :-) :-)
    
    A simple part numbering scheme probably wouldn't equate to a balanced
    system of allowing a customer to order only what he needs.
    
    Karen
    

    
    
    	What about distributing software order forms that look like
    	one of those standardized tests where you fill in the blank ?
    
    
    	Product:			 Pascal
    		 			 ------
    
    	Media: 								
    					o TK50
    					o Magtape
    					o CD
    					
    	Documentation:
    					o Full Kit
    					o Users Guide
    					o Admin Guide
    					o Programmers Guide
    	
    	etc.
    
    	Then all the customer or sales rep needs is a #2 pencil.
    
    
    						Mike
    						----
    				

    re: 19
    
    Because sales reps are expected to place their orders electronically,
    via AQS.......
    
    Karen
    

    I work in Channels sales support in the field.  About 4 months ago we
    were required to put together a document called the "One Plan".  This
    presented our view of the reseller we support.  We put it together
    according to the format, about 15 pages' worth.  Our One Plan was never
    presented nor used.  Two months ago Southwest Channels was absorbed
    into Western Channels, and we were required to put together an
    'informal' presentation for our new Channels DM.  No, we couldn't use 
    the One Plan, wrong format.  So we did an 'informal' presentation
    using DECwrite and presented it to good reviews.  NOW we have to put
    together a formal Account Plan using yet ANOTHER format, which matches
    niether previous Account Plans, the One Plan, or the informal plan.
    
    Where's the time to get in front of the customer ?
    
    Karl Moeller Western Area Channels Sales Support Consultant/
    UNIX Partner

    re: .17 and .18 or was it .19
    
    I am not sure where you guys work, but if you are not out in front of a
    customer trying to deal with software part numbers, do not say the
    system is EASY.
    
    The system stinks! Do you get my drift. Now I have been in Sales
    Support for 4 years, and before that a customer for 10, I know the
    system becasue I am forced to know it.  
    
    Have you ever had a customer on you back because he got software doc
    and lic with no media?
    
    Yea the rep forgot and the customer just assumed he got what he ordered
    software. 
    
    It is this kind inward thinking that is wrong with the people on the
    mountain top. We think the system is easy, who cares what WE think it
    our customer that pay the light bill.
    
    Frank

    re: .17 and .18 and .22
    
The system we presently have for software licensing, software maintenance and 
media and docs is ridiculous. I, too, am in Sales Support and have spent 
inordinate amounts of time figuring out SW license upgrades (clusterwide or 
traditional? What?!) and making sure all the part numbers are accurate. These 
efforts were primarily for the corporate computer centers of one of our 
corporate accounts. The system is not at all intuitive; to do it right you 
need a combination of VTX PRICE, an old U.S. Price Book (since software is no 
longer in the latest one) and the DECdirect Software Catalog. And sometimes 
even that isn't enough! Just this afternoon I had all of these spread out on
my desk trying to figure out a number of cluster upgrade alternatives for my
customer. 

I shake my head in disbelief every time I have to deal with software 
licensing. It is very labor-intensive and error-prone. I know the system, but
I double and triple check my work because its so damn complicated.

QL-frustrated,

Jim

    
    
    Re .20 
    
    	It sounds like we're trying to fit the user/sales_rep/customer
    	to the system instead of the other way around.
    
    	The order could still be done up using a #2 pencil and then
    	placed electronically through one of those readers... It be a
    	peice of cake for the system to then generate a report in 
    	what ever language you like describing the order for final
    	confirmation prior to processing.
    	
    	That way everyone knows exactly what's ordered through the 
    	report and the system is happy with its bits and bytes.
    
    						Mike
    						----
    

    Re .24
    >  	It sounds like we're trying to fit the user/sales_rep/customer
    > 	to the system instead of the other way around.
    
    
    You hit the nail on the head. Easy for who I ask, easy for the system.
    
    That's what's wrong with this company, too many things that are easy
    for Digital on hard on everyone else.
    
    Frank

	While we're talking about cruddy situations that'll never
	change :^) .....

	There's been a lot of discussion lately about putting our
	organization ( the Customer Support Centers ) under some
	sort of global "Services" umbrella.  Even today, we are a
	part of "Customer Services", the old Field Service.

	This is hosed.  In the Colorado CSC, a thumbnail evaluation
	of the distribution of software and hardware people reveals
	that we are about 60%-75% software support, and the rest 
	support hardware ( remote diagnosis and the like ).

	The folks supporting software have no direct contact with
	engineering. It seems that our closest common manager
	is Jack Smith, or possibly Ken Olsen.  

	I believe that the software support organizations should be
	funded (and necessarily a part of ) the engineering groups
	that write and maintain these products.  As it is now, 
	buggy products produce volumes of calls, patch letters, FLASH
	articles, patch tapes....all of which are produced/paid-for by
	Customer Services.  

	One engineering group releases runtime libraries with its
	product which causes horrible upgrade problems for customers
	that use it.  The team that supports this product spends
	hundreds of hours each quarter unravelling the tangled messes
	this product creates.  Who pays ? Customer Services.

	This engineering group has NO INCENTIVE TO CHANGE THE WAY THEY
	OPERATE.  

	This is just one story.  If the cost of support came out of
	an engineering group's revenue from the sale of their product,
	things would have to change.

	In addition, a support group closely aligned with the engineering
	group for the product would certainly be more likely to 
	get a quick query answered than is the case now ( no
	query support for the CSCs -- AT ALL ).

	But, as we know, this'll never change.....after all....this
	is the way we do it TODAY.

	Steve H

    
    re .26: This engineer agrees with you 100%.
    
    I worked in the Marlboro TSC (Telephone Support Center) ten years ago,
    doing support for 36-bit layered products. The engineers were just down
    the hall. It was not Nirvana, but we could talk to them about sticky
    situations and get quick answers. Then TSC became (Colorado) CSC, and the
    lines of communication immediately began to wither. Today, with the
    exception of sporadic under-the-table assists, this essential
    communication is slow where it exists at all, and bogged down in
    bureaucratic layers. Engineers lost a link to the customers of
    incalculable value, and the front-line people in the CSCs lost the
    ability to react quickly to sensitive customer issues.
    
    It is well past time to reestablish direct lines of communication and
    responsibility between CSC's and engineering.
    

    This is in the spirit of "making it easier" to work at Digital,
    even if it isn't a permanent fix....
    
    Frank and Al......I believe you both mentioned you are in sales 
    and/or sales support.  I work for Remote Sales Support out of the
    Atlanta CSC.....I am part of a 15 member team devoted to licensing,
    SW services and warranty; to the best of my knowledge my team is
    unique in that we do cover licensing as well as services....I know
    in the field this is split out over 2 organizations <----- this is
    causing a lot of your pain, believe me.  I was once a SW Business
    Account specialist in the field; at that time we were expected to
    know both services and licensing; today I know you cannot go to just
    one person in your office and have that person be up-to-date on
    *both* licensing and services issues.
    
    Not to go down a rathole; perhaps my group could help you gentlemen
    out......rather than sit with bunches of books for hours....try
    giving 1-800-DEC-SALE a call.  RSS is chartered to handle "pre" sales
    questions, not E/U issues....so if you decide to call us, bear that
    in mind.
    
    Our group does assist Customer Services people (that is subject to
    change because we are funded by the sales organization, and C.S.
    hasn't decided whether or not to contribute to the funding in order
    for us to continue to be a resource to their people).
    
    I didn't say our numbering scheme was a piece of cake, but there is
    a method to it.  It's pretty fundamental really.....but it *is* 
    scary when I see evidence day after day that folks doing the quoting
    do not realize when selling a new SW product they must quote a 
    license AND and H-kit (binary media & hard copy doc).  From the one
    case described, it's quite obvious the previous rep ordered a
    license and a GZ kit instead of a license and an H-kit.
    
    If you'd prefer not to call RSS; one tool neither of you mentioned
    was the AQS quoting system.  If you understand that QL = license,
    QA = media & doc or doc only, and QT = services.....doing a wild
    card on AQS can show you all active part #'s. 
    
    RSS does have other teams devoted to HW configuration for high-end
    to low-end systems, local area and wide area networks.  I can't
    guarantee you a total solution every time you call (especially if
    you wait until 10 minutes before you are due at a customer's site
    to call us) :-) :-)......but we might be able to help you speed up
    the process.
    
    To the person who is still holding out for a form and a #2 pencil;
    don't mean to be a wet blanket......but I don't think that idea
    will fly :-}
    
    Karen
    
    
    Bottomline on the theory of one part # for all is that you're not
    facing what has been mentioned before......going the one part #
    route means forcing customers to pay for quite a bit more than they
    might need.....just to get that one portion they *do* need.
    

    re .26, maybe I can help just a wee bit.
    
    First, there is a major evolution taking place right now as we speak
    to migrate the support function from CSSE to engineering groups.  It
    is planned to be completed by end of FY92.
    
    Secondly, the "cost of support" is generally met by the warranty bucks
    that are stripped off the Standard List Price for a software license
    and transferred to SPS.  It's been running at at 5% in the past, but
    is moving upward toward 10%.

    One more comment on .22, and others if I may.  I agree that our
    corporate licensing scenario is shameful.
    
    However, on a per-product basis, the licensing/media/service part
    numbering system should take about five minutes to understand.  It
    is simple and straightforward, and anyone with fundamental competency
    should be able to handle it.
    
    I have been hearing the same complaint about sales folk ordering a
    SW license without an H-Kit for many years now.  If there is still
    one sales person in the world who does not understand that relation-
    ship between the two, they seriously need to think about a new job.
    My personal experience with this issue is that sales people do not
    want to, and will not listen to explanations of a very simple system.
    
    BTW, I see absolutely no reason to belabor a customer with the details
    of any of this.

	Hi Dick,
    
>    Secondly, the "cost of support" is generally met by the warranty bucks
>    that are stripped off the Standard List Price for a software license
>    and transferred to SPS.  It's been running at at 5% in the past, but
>    is moving upward toward 10%.

	This is interesting...but still broken.  The same amount
	gets transferred to SPS for a gleaming, wonderful product
	as the tuba-glued-to-the-side-of-a-bathtub product ?

	Engineering needs to feel the pain of their foul-ups, and
	needs to be able to bask in the comfort of low support 
	costs for well-engineered products.

	Thank you for your support,

	Steve H

    I can't offer a total solution to the problems discussed here, but I do
    think that the application I support, SWIFT, will simplify the
    configuration of the QT service model numbers.
    
    SWIFT (Services & Warranty Inquiry Field Tool) can be used by any
    member of the Account team.  It asks questions in English, and
    translates this into the QT part numbers.
    
    I can personally attest that the QT service model number format is not
    consistant 100% of the time.  SWIFT has been enhanced to accomodate to
    support the exceptions to the part number construction as well as the
    normal process.
    
    In addition, V2.0 was just released on August 12th.  The benefit to
    V2.0 is that it is integrated with AQS.  SWIFT will read the license
    purchased, and propose a service model number for that product.
    
    I am the application manager for SWIFT.  As I infrequently read this
    file, please feel free to contact me via All-in-1 at MRO.
    
    
    Kevin Duhaime
    

    re: .26, .27
    
    We don't have to fix all of Digital to fix this problem.  The "under
    the table" contacts can be made frequent, and with proper encouragement
    Email can serve to bridge the geographic gap.
    
    I had to threaten to take vacation time in order to visit the Colorado
    Springs CSC two years ago.  That visit proved an eye-opener for me.
    Subsequently I got permission to review the CSC's call logs on my
    product, and I still find them a useful source of customer feedback.
    In exchange, the support specialists know that they can contact me
    at any time for information.  Sometimes I can add information to
    a call without being asked.
    
    I completely agree with .31 about the allocation of service costs
    described in .29: it doesn't provide rewards to engineering for
    producing quality products.  Engineering gets recognized for the
    revenue its products bring in, and so engineering is encouraged to
    ship products as quickly as possible, so that revenue starts as soon
    as possible.  That tendency needs to be moderated by a requirement
    that the product make a profit for the corporation when service
    costs _of that product_ are taken into account.  The Colorado Springs
    CSC, at least, measures the amount of time that each specialist spends
    on each call, and each call is identified with a product.  Therefore
    it should be possible to distribute the service costs among products
    based on the amount of specialist time spent on each product.
        John Sauter
                               

    Kevin:
    
    You've mentioned the SWIFT component of the quote system before and
    I have referred reps to it, especially when the rep indicates he/she
    will be working after RSS work hours.  Quite a number of reps are
    unaware of SWIFT.
    
    RSS does not have access to all the functionality of the AQS system
    because we are not expected to generate quotes (we use the price
    look-up and the corp long description look-up).  I have noticed
    that when I first log onto the quote system, quite often there are
    special messages pertaining to new revs or updates to the quote
    system.....have you flagged that section of AQS to the SWIFT
    component?
    
    Karen
    

    Karen,
    
    	I appreciate the feedback.  Communications are just beginning on
    	the abilities of SWIFT.
    
    	I don't know what subset of AQS you are restricted to, but off the
    	main AQS menu, SWIFT is a selection (Option 17).
    
    	From an integrated standpoint, SWIFT is available by selecting
    	SWIFT Configuration at the services screen under Quote Entry.
    
    	SWIFT is also available as a standalone application, and is part of
    	the account workbench and SMART.
    	
    	If the special messages that you see when you first log in include
    	AQS V4.6 release notes, then a detailed explanation of SWIFT V2.0
    	will be included.
    
	SWIFT is really designed for those individuals that do not have a
    	detailed understanding of the complexities of the SPS business.
	It is extremely helpful in enabling the user to tailor a solution
    	by asking service related questions that translate into the service
    	model numbers.
    
    	I've been involved with SPS for over 5 years now, and I believe
    	that the complexities involved with using price books, policies, etc
    	is not the most effective use of the selling teams time.  The
      	business complexities exist, but I feel SWIFT removes the part
    	number complexity from the process.
    	
    
    Kevin Duhaime

    Kevin,
    
    I have been in sales support for over four years and I have never heard
    or seen any of my sales reps speak about or use SWIFT. If it is part of
    AQS it must be a secret. I will ask some of my reps in the AM.
    
    Frank

  
  Re .26,.27,.31     Sadly, you are exactly right.
  
  Re .33 (John)
  
  > We don't have to fix all of Digital to fix this problem.  The "under   
  > the table" contacts can be made frequent, and with proper encouragement
  > Email can serve to bridge the geographic gap.                          
  
  The point was that such assistance is currently left to the engineers
  themselves, usually (as you said) going against the "normal procedure".
  There are some engineers - indeed some whole groups - who believe in
  their product and have the dedication to help in this way but it's no
  coincidence that their products tend to be the well-written ones anyway ...
  the authors of DECgarbage are the ones who hide behind every possible
  official procedure to *avoid* the responsibility for their mistakes.
  THEY are the ones who require all support to go via "official channels
  only" and THEY are the ones whose support channels are totally useless
  until the customer goes nuclear. I've had a priority 3 SPR for a "good"
  product serviced, fixed and returned in the time it takes a priority 1 CLD
  to be acknowledged by a "bad" product group ... and a P1 CLD is about the
  only way to get any response at all from them anyway, everything else is
  just lip service.
  
  Yes John, your action shows the way that Digital SHOULD work but until
  the bureaucratic barriers created by incompetent groups are broken down,
  we are left relying on the goodwill of engineers who know the meaning of
  the word "responsibility". Those who can, do ; those who can't, hide.
  
  Frank

    Re: 1575.36
    
    Frank,
    
    	SWIFT has been a main menu option of AQS since AQS V4.3.  That
    	version was released in Sept '90.   SWIFT is Option 17 off the main
    	menu.
    
    	If you have any questions on SWIFT, feel free to contact me via
    	All-in-1.
    

    Kevin Duhaime

    Re: .29
    
    �First, there is a major evolution taking place right now as we speak
    �to migrate the support function from CSSE to engineering groups.  It
    �is planned to be completed by end of FY92.
    
    Interesting point of view on this. I originally thought that putting
    the Corporate Support load on Engineering was the purpose for the
    transition. The CSSE point of view seems to be that the purpose is to
    make the field self-sufficient.
    
    michael moy
    Rdb/VMS Engineering

	Recently, I have heard that the systems used to log software problems
	are being changed.  I did not hear all of the details, but I did hear
	that there will be one system that will communicate the problems
	back to engineering.

	I work in Atlanta, in the workstation group of the CSC.  When we get
	a call from the customer we log that call into the CHAMPS system.  I
	will agree that this system has its problems, but it does keep track
	of what was done, if properly used, and how much time a specialist
	worked on a problem.

	Why can't this system be used by engineering to keep track of and
	take responsiblity for a problem?

	Plans are that in the future all three CSCs will be on the same CHAMPS
	system and we would be able to move problems from center to center,
	so that the person with the training needed could work on the problem.
	Why not add engineering into this?

	Look at the advantages.

	First, instead of the CSCs moving the call from one system to another
	the problem could be moved from one queue to another, much faster.

	Second instead of a support specialist beating his/her head against the
	wall, trying to get status of an SPR or a CLD, the specialist could just
	look at the sequence number attached to that call.

	Third, this one I have to ask in the form of a question.  Why can't the
	engineer, assigned to correct a problem, talk directly to the customer.
	In my approach, he would have the customer's name and phone number.  He
	could find out first had what the software is doing.

	If you are concerned with tracking how many problems are logged against
	a produce, look into the open and closed call list.

	Maybe this solution is just to simple.

	Somebody suggested that some engineers or engineering groups are hiding
	behind the "proper channels", will if we make this the proper channel,
	then they will have very little to hide behind.  Then we can get rid of
	them, instead of getting rid of the many compedent people we got rid of
	in the past couple of years.

	Dave Mac Eachern
	GRAPHAPPL  CSC/AT

    Re: -1
    
	Recently, I have heard that the systems used to log software problems
	are being changed.  I did not hear all of the details, but I did hear
	that there will be one system that will communicate the problems
	back to engineering.
    
    >> This system is called the Integrated Problem Management Tool or IPMT
    >> for short and is being implemented by Digital Services. It will take
    >> problem escalations (SPRs, CLDs and suggestions) from the CSCs
    >> worldwide and direct them to CSSE/Engineering. It will also provide
    >> status update capability via mail along with certain interested
    >> parties having the ability to look through the log. I believe the
    >> group that is doing this Corporate Field Support.

	I work in Atlanta, in the workstation group of the CSC.  When we get
	a call from the customer we log that call into the CHAMPS system.  I
	will agree that this system has its problems, but it does keep track
	of what was done, if properly used, and how much time a specialist
	worked on a problem.

	Why can't this system be used by engineering to keep track of and
	take responsiblity for a problem?
    
    >> I would imagine that there's a lot of information in CHAMPS that
    >> CSSE/Engineering shouldn't be concerned about. There's also the
    >> issue of database ownership, and where it's located, how it would
    >> interface to existing development systems. I do agree, however,  that one
    >> integrated system would be nice.
    >>
    >> When I worked in CSSE, we got customer problem logs on CLD
    >> notifications and usually 95% of the information in the logs was
    >> not needed to solve the technical aspects of the problem.
    >>
    >> I think that IPMT (once the bugs and implementation issues are
    >> worked out will accomplish the goal of Engineering/CSSE keeping
    >> track of and taking responsibility of a problem.

	Plans are that in the future all three CSCs will be on the same CHAMPS
	system and we would be able to move problems from center to center,
	so that the person with the training needed could work on the problem.
	Why not add engineering into this?
    
    >> Engineering has to deal with the world. Other geographies use
    >> different call-handling systems. There is supposed to be a common
    >> call-handling system interface which IPMT will use.

	Look at the advantages.

	First, instead of the CSCs moving the call from one system to another
	the problem could be moved from one queue to another, much faster.

	Second instead of a support specialist beating his/her head against the
	wall, trying to get status of an SPR or a CLD, the specialist could just
	look at the sequence number attached to that call.
    
    >> I believe that IPMT will have this functionality perhaps by the
    >> second version. If a specialist is working on a call, he should be
    >> on the distribution list for updates. If not, then with the
    >> appropriate security permission, he should be able to see the
    >> problem log.

	Third, this one I have to ask in the form of a question.  Why can't the
	engineer, assigned to correct a problem, talk directly to the customer.
	In my approach, he would have the customer's name and phone number.  He
	could find out first had what the software is doing.
    
    >> This does happen on CLDs and priority 1 SPRs, and when customers
    >> call high-level engineering managers directly. When I worked in
    >> CSSE, however, it was preferable to work through the local office as
    >> they should understand the local political situation. This also
    >> serves to train the local support people. This also saves
    >> engineering time as we can say please provide me with x, y and z
    >> (if the local office can supply x, y, and z).

	If you are concerned with tracking how many problems are logged against
	a produce, look into the open and closed call list.
    
    >> IPMT will have a reporting database to do this.

	Maybe this solution is just to simple.

	Somebody suggested that some engineers or engineering groups are hiding
	behind the "proper channels", will if we make this the proper channel,
	then they will have very little to hide behind.  Then we can get rid of
	them, instead of getting rid of the many compedent people we got rid of
	in the past couple of years.
    
    >> I hope that we have more of an education problem with engineering
    >> moreso than a problem with people deliberately hiding.
    
    michael

    re: .40, .41
    
    I have heard that CSSE is getting out of the product support business.
    I suppose this means that IPMT will escalate problems from the CSCs to
    Engineering, bypassing CSSE.  There is currently a system called PIPE
    which sends SPRs from the CSCs to Engineering.  PIPE seems to work
    quite well, except that responses sometimes get lost.  This probably
    isn't PIPE's fault---I think responses take a complex path.
    
    CHAMPS is human-engineered for specialists, who do nothing but deal
    with customer problems while they are "on the phones".  A specialist
    will sometimes take a problem and work on it while away from the
    phones---this is called "research".  During this time the specialist
    doesn't use CHAMPS but is working with an extracted description of
    the problem.  For engineers I think you would need a differently
    human-engineered system, oriented to concentrating on one or a few
    problems until they are resolved, and then going on to the next.
    I think it could use the same data base as CHAMPS, but it would need
    a front end more like NOTES.
    
    Speaking as an engineering person who has been watching my product's
    call logs in CSC/CS for many months, I haven't seen anything in
    CHAMPS that I'm not concerned about.  If the customer is irate, or
    spends a lot of money with Digital, or has a simple workaround, those
    are all significant to the scheduling of problem solving resources
    (i.e., my time).
    
    I believe the data base should be located in each CSC, as it is now,
    and there should be links between the CSCs and with the engineering 
    groups for moving tasks.  For data base design purposes each separate
    engineering group can be considered a small CSC.  This kind of data
    base is not simple to design.  Moving a call from one CSC or
    engineering group to another should be as simple as moving a call from
    one queue to another.
    
    Usually, engineers don't have the skill to talk directly to customers.
    When I was at CSC/CS I watched a specialist read to a customer from
    the Datatrieve manual, including citing page numbers, without offending
    the customer.  That takes a lot of skill!  Some engineers are so
    lacking in tact that letting them talk to a customer risks losing the
    account.  You could argue, as I have, that engineers can and should be
    trained to interact well with customers.  However, that proposal hasn't
    gotten any serious attention.
    
    There are exceptions, of course.  The kind of engineer who can hold an
    audience's attention for 45 minutes at a DECUS symposium shouldn't have
    much trouble learning at least the rudiments of how to talk to
    customers.
    
    I have very seldom called a customer who had a problem.  When I have
    made such a call it has always been because the particular situation 
    seemed to require it, and I have always either informed the local
    office of what I was doing, or asked permission of the specialist
    handling the call in the CSC.
    
    I think in some cases people are deliberately hiding.  An engineering
    group may be saddled with maintenance of "the product from Hell".
    They are embarassed by its shortcomings, but there is little they can
    do about it because a major rewrite would take more resources than
    they can spare from fighting fires.  They can't get more resources
    because the product isn't bringing in much revenue.  The product
    doesn't bring in much revenue because of its problems: catch-22.
    I can sympathize with a group in this position who hides behind the
    standard procedures---they'd really rather not deal with customer
    problems at all, and hiding is the closest they can get to that.
    
    While I can sympathize with such behavior I don't condone it.  A sick
    product should be put out of its misery and the resources formerly
    assigned to it put to better use.  If the product is so important
    that it can't be scrapped then upper management should have the wisdom
    to assign enough resources to it to get it fixed.
        John Sauter

	Well guys,
	
	The IPMT, PIPE, CHIME, CSSE business is all just overhead
	and band-aids that are being applied because the system
	is not organized properly.

	The CSC software groups should be part of engineering, not
	Customer Services. I mean, our whole response to critical
	software problems is oriented toward sending Joe Toolbox 
	out to a customer site when something's broken !  This
	is exactly who is first sent out in response to a broken
	Ultrix component, in my experience....

	CSSE, is, to us, a huge Berlin Wall between the CSC and 
	engineering.

	PIPE and the QAR system, Notes and EIRS -- these are all
	databases that must be reviewed JUST TO SEE IF A CUSTOMER'S
	PROBLEM HAS BEEN SEEN BEFORE !

	As long as the toolkit organization manages software
	support groups, complex links, multiple databases, haphazard
	communication, and deferral of responsibility will
	continue to plague us.

	Please, no more alphabet soup programs and procedures !

	Steve H

>	The IPMT, PIPE, CHIME, CSSE business is all just overhead
>	and band-aids that are being applied because the system
>	is not organized properly.
    
    I don't know enough to agree with the above assertion, but my gut tells
    me there's a lot of truth in it.
    
    
    One principle of organization we seem to violate in all of our systems, 
    
    *  Define the work before you define the organization!
    
    For whatever reason, we continue to allow people to design
    organizations before there is a consensus on what work is needed.  Then
    we allow them to define work to occupy the organization.
    
    I know it's harder to think about the work in the abstract, but then
    managers are paid to think harder aren't they?  :-)
    
    Dick

    All this talk about consolidating problem reporting systems, etc.,
    is fine and dandy, but it still only covers 40-45% of what's really
    happening...remember Europe and GIA???  I think Europe has 8 or 9
    or sumpin like that CSC's alone.
    
    In my job, unless I have valid, up-to-date, world-wide support data
    it's useless.  For instance, I have one product where 85% of the
    action is in Europe.  U.S. CSC call data on that product is of very
    little value to me.

>    All this talk about consolidating problem reporting systems, etc.,
>    is fine and dandy, but it still only covers 40-45% of what's really
>    happening...remember Europe and GIA???  I think Europe has 8 or 9
>    or sumpin like that CSC's alone.


IPMT is supposed to take escalations from US, Europe, and GIA. Thats multiple
call handling systems.  It should replace TIME, CLD, PRISM, ??.  If it meets
that goal it is progress.

re .26 etc.

I take probs from anyone anytime anyway....  If you can't handle my preferred
method look in ELF and call me!  Make your other support people do it too...

Richard.

	The system you described sounds good, so did the PIPE system.

	Pipe was suppose to file our SPRs from the CSCs and provide feedback to
	us about the status of problems that we had to SPR.  It is not doing
	that.

	I am not saying that the software doesn't work.  I am saying that the
	system doesn't work.

	It is my opinion, that with every interface you add into a system, you
	add another place where the system can "drop the ball".  I also believe
	that the more complicated the system the less people want to use it.

	Only one more comment.

	I have seen this company hurt a number of times because we dealt with
	situations politically and not technically.  Who are we doing a favor
	to if we take on a job that technically cannot be done the way the
	customer wants, or in the time frame he wants?

	If we get the right people working on a problem as soon as possible
	we will not have to be conserned with politics.  The problem will
	either get solved, or the customer will know as quick as possible that
	it cannot or will not be solved.  We will not have a customer waiting
	for months to hear that engineering will fix the problem in the next
	release, or that engineering does not agree that there is a problem.

	enough rambling.

	dave.

    No matter what system is developed, the usefulness depends on how
    well people use it.  How well they use it depends on many things, but
    mainly on how well it is understood.  And that takes training,
    education, and willingness to adapt to changing environments.
    
    So, we start with a straightforward design that does the basic
    functions required, provide adequate training and education to all
    potential users and assure the availability of that traiing for new
    hires, and prune the organization of the change resistors.
    
    All of this requires an internal discipline we have not yet acquired.
    First, we have to learn that there is no free lunch.  If you want a
    system to help you do your job, you have to participate in planning,
    implementing, and testing and using that system.
    
    Everyone would like to have a magic wand.  Just do X, and all our
    problems will be solved.   Not by a long shot!
    
    
    Dick

re: *

Who am I?  I have been a developer on the CHAMP/CSC system and I am currently
the project leader for the CHAMP/CSC V2.3-PIPE/IPMT Integration project.
(How's that for a mouthful?).

I've been reviewing the replies (since about .38) and I can only say that
you're right, both good and bad...

In a nutshell, I believe the Corporate mindset is moving towards "connectivity"
and "consolidation" of all our PROBLEM-TRACKING/CALL-HANDLING tools.  Up until
a few months ago, I wasn't so sure.

When IPMT was first announced, I thought, "Oh great *ANOTHER* call-handling 
system.  I still think it is *another* call-handling system (or problem-
tracking if you like) and this corporation has enough call-handling systems.
(FWIW, we have CHAMP/CSC, CHAMP/FLD, CHUCKware, CLD, NICE, ENCORE, TIME, IPMT,
etc., etc.)  The good news is that there has been a decision to use CONNECT/CS
V2.0 (GCM) to provide connectivity between these call-handling systems and
IPMT.  This *is* progress.  However, the reality is that there is still
a lot of tree-hugging/turf/political issues around the call-handling systems.
Too many people believe theirs is the *best* and can only handle their 
business needs.  The fact is that 80-90% of the "requirements/functionality"
of *all* the call-handling systems is the same, only the UI's reveal any
true differences.  It has been very *slow*, but there is a reshaping of
paradigms away from customized call-handling to a Consolidate Call Handling
System.  This is progress too.  We are working cooperatively with the ENCORE 
development group to consolidate.  (If you want details see the TINCUP::CCHS
notes conference.)  

I'll try and keep up with this note, but if anyone wants to ask me questions
specifically, send mail to BSS::BILLINGSLEA.

+- Mark

    Speaking from the other side of the fence -- I work on the ENCORE
    project which is other end of the co-operative development effort of
    which Mark spoke -- I'd like to underscore what Mark said in .49: There
    are groups who are trying to do common development to ensure that we
    are efficiently using our design and development resources. 

    The two groups responsible for the development of call administration
    systems for GIA and USA are working towards a common data model and
    common base-line user functionality for call administration.  We will
    then use this common functionality to solve maybe 80 per cent of our
    respective USA and GIA functionality issues, and then use customised
    modules that fit within that framework to solve the remainder.

    The bottom line is that we're working towards an end goal of having two
    development groups build a single "plug'n'play" call administration
    system where modules built by either group work within the call
    handling infrastructure.  One group adds remote services functionality,
    or another group adds escalation functionality, and it's available to
    all users who share the infrastructure.

    The problem we're running into is that one development group is in CXO
    and the other development group is in KAO.  And USA travel guidelines
    say that travel from CXO to KAO is international which requires a VP 
    signature.  That's all but impossible to get.  So we struggle along as
    best we can, making use of conference calls, or occasional travel from
    KAO to CXO, since GIA rules say that travel from KAO to CXO is not
    considered international.

    One could argue that the solution to our travel restrictions would be
    to simply have one development group do all the development for call
    administration on a corporate basis.  I'd counter that argument with
    the fact that there *are* differences between the different geographic
    entities within Digital that require some amounts of customised work. 
    The environment that our two groups are working towards will support
    the freedom to customise modules where appropriate, but take advantage
    of a common development infrastructure whose design and construction
    has been shared by the two development groups.
    

re: .3 in particular and a whole lot else in general

A huge amount of money has been poured down the drain of Admin. Systems.

How do I know?  Well, I helped audit several of them for a few years. And 
the rest of my 11 years in DEC I've helped develop them.

Currently I'm working on YARFS  (**Yet another replacement for SMART) known as
CSA.

The primary problem in developing the kind of integrated, helpful systems all 
the replies are after can be stated in one word: money.

You know, the golden rule; he who has the gold sets the rules.

In the admin world, there are a long line of corporate financial stovepipes
that run from the top to the bottom.  So, the money (and therefore the rules)
are established to meet the desires of those at the top of the stovepipe as
they are filtered through the rest of the layers.

In my work with real field users of the systems, they need the ability to 
interact, via the application, with other groups in the district; NOT with
their regional or area or corporate hierarchies. BUT the IS community is 
funded by the heirarchy; and unless two hierarchies happen to agree on a goal,
integration, if any must be driven, sub fusc., by IS. In a time of tight
budgets and managerial panic guess how easy that is?

However, to leave you on a high note, there does seem to be a growing effort 
toward integration and the ease of use that the previous few replies from
my compatriots in call handling have pointed out. It is a horribly tough battle
and the stovepiped business mentality is fighting tooth and nail to keep 
the power over IS.  

IMHO, DEC needs to win this fight fast, or it may not matter any more.

Alan

    Thanks for the insight Alan, much as I have suspected.  I think your
    last statement speaks volumes.  Are customer are seeing us stumble over
    ourselves and each other.  It is obvious that we do not have the tools
    to do what needs to be done in a timely and efficient manner.  It is
    painfully obvious not only to us, but to outsiders now.  I remember
    years ago we used three reports in customer services (then field
    service) admin.  Now we have access to many reports and many reports
    are generated.  What I have to ask is how many reports are NEEDED.  Not
    needed so a table full of managers can sit around and have something to
    talk about, but what is needed to take care of the business.  Within
    the last few years it seems that the former is being given much more
    emphasis than the latter.  My philosophy is to only make things as hard
    as they need to be.  In my opinion things are much harder than they
    need to be.  Even taking into cosideration government compliance and
    the like.
    
    As always IMHO,
    
    Mike

    re.49
    Although that you forgot to mention ECSO in your list of call handling/
    escalation tools, you are right about basic functionality beeing
    O.K all over.
    In my previous life, I was involved in definition and usage of ECSO
    (the still current Euro Escalation tool):
    We had it just before CSSE planned to create the (pre-IPMT) CLD
    tool. > same functionality, different implementation. Of course
    we showed ECSO to CSSE and of course they wrote their own and
    of course we had then to hack an ECSO > CLD feeder (still in use).
    
    Later, we needed new ECSO functionality and had gathered lots
    of user requirements and planned to create a new version.
    At the same time we found out about an Escalation tool that
    had been created by and for GIA. (Sorry I forgot the name).
    I studied the functionality and even worse, compared the list
    of outstanding ECSO requirements with the GIA tools specs.
    Guess what ?
    90% percent of the ECSO wish list was fulfilled by the GIA tool !
    Guess what ?
    We still did the new ECSO version!
    The reasons are multiple ranging from political over support aspects
    retraining the ECSO users etc...., but still, I wonder if it
    was the "right thing" to do or just the old "NIH" syndrom as usual.
    
    So far to the tools....
    
    BUT, as someone pointed out, although those things costed/are costing
    megabucks, they are NOT THE business or operation, just supporting
    tools, no more no less.
    The important rest is THE WORK, operation, business etc..
    
    In my humble (ancient DEC'ies) opinion we should learn from the past
    (the old DEC) and eventually agree that:
    
    In this IT (and other) businesses one might consider that there are
    only two parties (or "end  nodes" ? perhaps) directly involved:
    
    1- The Source: Product Engineering, Manufacturing, Third Party,
                   Service-, Solution- Engineering.... ad infinum
    
    2- The Sink:   The Customer, user, OEM......ad infinum
    
    (For the $$$ flow, just reverse source and sink !)
    
    Everything in between is "support" in the largest sense and
    includes sales, service delivery, etc ( "router nodes" perhaps ?)
    
    Focussing now on the Services part, (ex- Field Service, ex- Customer
    Services ) which seems to be the case for the recent replies to
    this note, I'd say that this functionality is a significant and
    complex part of the overall "support". 
    Trying to simplify further, this functionality may be broken up
    into two sub-functions:
    
    a) "fixing the customer"
    b) "fixing the product"
    
    Bearing this in mind, we should be able to find out:
    
    Who does what for whom and where and who pays for it.
    
    Which the might translate into:
    
    Organizations (or not), Processes, Business and other financial
    models...
    
    When DEC was small and "beautiful" it worked that way, because
    everything was small and simple including the technology and
    the customers, then when "things" became more complex, we thought
    we had to make ourselves (organisations, jobs, processes) even
    more complex to cope with it. It was wrong, but nobody noticed
    it during the "fat times". Those were the times where we created
    the CSSE and lots of other layered (branch, district, country, area,
    COG) support/delivery ORGANISATIONS. Don't get me wrong, I have no
    doubt on the partial or total (continously changing) usefullness of 
    the respective functionalities, but I have serious doubts on 
    the necessity of the present COMPLEX organisations.
    They appear as many "router nodes" requiring the usage of
    a well designed, but bandwith consuming communications protocol
    (such as Escalation, Exceptions management processes and tools)
    
    Have you ever checked if your job, organisation, group mission etc.
    is simple enough or too complex ?
    
    Try to explain it to your father in law who happens to be a doctor,
    lawyer, shoe-maker, truck driver...... 
    
    My two centimes worth...
    /fred

	re: the last few....

	Do you guys hear what you're saying ?

	example:

	"Well, I used to write the ECSO CFB module which
	interfaced to the PYD system on the AFM side.  Then,
	I had to write an interface to the PFY system that the
	UGG group required, but their management wanted a
	DSY program to......"  and on and on.

	This is looking at the symptom, and applying gum and
	bailing wire.

	I don't know much about the systems you mention.  But
	I  am convinced that for the CSC software support groups,
	no number of interfaces, hack-job software links, and
	so forth, can possibly replace:

	1) Having CSC software support groups report to the respective
	   engineering groups.

	2) Having the engineering groups responsible for the costs
	   of maintaining/supporting their products.

	Thanks,

	Steve H

re: .54
>    	1) Having CSC software support groups report to the respective
>	   engineering groups.
>
>	2) Having the engineering groups responsible for the costs
>	   of maintaining/supporting their products
    
   I'd agree that this could answers the "fixing the product" (see .53)
   aspect of the support job, although that implementation outside
   the U.S (who is lucky to have "only" the Springs and Atlanta CSC's
   and no country and language barriers to worry about) might be
   quite difficult.
    
   However, there is also the "fixing the customer" aspect. In my
   humble opinion, it's the only one where "support" should and
   could make legal customer money on. 
   Aside Hardware which really "wears out", Software bugs are
   simply due to the fact that engineering didn't (or couldn't)
   do a quality job. In the good old days with PDP and VMS "monopoly"
   and a strong HW maintenance background we were able to have
   customers pay for Software "maintenance" as well, which in turn
   allowed us to do a lot of "fixing the customer" including 
   a lot of effort spent on "calls" which never revealed a bug
   in the product but rather in customer's way of using/managing
   the system or quite often as well a "bug" in the solutions
   defintion/selling phase.
   Today, we still don't know how to make money there, but I am
   convinced that NMS (In Europe "Entrepreneurship" is more
   often used than "NMS") will bring a solution. But only if
   the entrepreneurs do have entrepreneural vision and goals
   and not just short term "my enterprise's profit" objectives
   in mind and job plans.
   Example:
   -There is rare (classic) product expertise in my support group.
   -Today it's mostly free of charge because of the "Software
    Maintenance" mentality.
   -Tomorrow as an entrepreneur I could sell it for "megabucks"
    screwing all those who need it.
   -If i'd do that and nothing else, I am sure that my "enterprise"
    will be very successfull but only for a very short time !
    
   Another 2 centimes...
    /fred
        
                   

    This interesting discussion started off on the difficulty of doing
    business with Digital (which I've experienced, working for customers,
    and seen, working "inside").   It got off into Admin. systems
    complexity then into support responsibilities, problem-tracking, etc.
    
      One thing about Digital (strength and weakness) is the way people try
    to solve things from first principles, rather than looking at how other
    organisations might do things.   Does anyone know of management case
    studies/success stories where OTHER companies have managed to get
    themselves out of a quagmire of over-complex admin. systems,
    configuration rules, support and problem-fixing structures?

.56> ... the difficulty of doing business with Digital...

    I had to laugh when I read this phrase .....

    FACT:  Customer give us purchase order for 'bout $600K.  Customer gets
    invoices from too many organizations in Digital to mention ... customer
    issues checks for invoices ... one organization says they haven't been
    paid - wants customer to send copies of canceled checks to Digital
    with the following "WE have know way of knowing how much you've paid
    Digital, we just know that we haven't been paid".

    FACT:  Same customer is questioning some installation procedure being
    done by field service - service rep replies "we only install what the
    sales force sells, if you have a problem with what I'm doing, take it
    to your rep".

    FACT:  Same customer receives invoice with state taxes on services.
    Customer notes that other vendors do not charge taxes on services.  Our
    response (for lack of a better word):  "we don't know that they are not
    charging you taxes, they're probably just giving you a discount and not
    showing the taxes".

    How can I get a "strength" from this?

    Oh well ...

    Bubba

    re .56
    
    The experience described in "Up the Organization" showed how one top
    manager turned around his company, AVIS.  Of course, any such
    autobiographical work has its credibility problems.  The other problem
    is how to use someone else's experience here.  Translation difficulties
    are sure to come up.
    
    Dick