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

Conference kernel::csguk_systems

Title:CSGUK_SYSTEMS
Notice:No restrictions on keyword creation
Moderator:KERNEL::ADAMS
Created:Wed Mar 01 1989
Last Modified:Thu Nov 28 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:242
Total number of notes:1855

129.0. "Should Front End Dial In ??" by KERNEL::ADAMS (Venus on Remote Control) Fri Jan 18 1991 21:05

    
    This is a request from Frank Briggs, to solicit your
    inputs/suggestions,as to whether or not the Front End
    Desk should or should not Dial in to calls.
    
    Bear in mind that the goal of the FE Desk is to handle 
    the calls as quickly and painlessly as possible in the
    most efficient manner.
    
    To give some idea of what we are looking at, consider an
    8600 (whatever that is) Machine Check. There might be 
    connection problems etc adding to the call time, but is 
    this worthwile, in preference to expecting the customer 
    to scan up/down the errorlog entry (if they have one 
    printed off)
    
    There are some side issues, such as do we need to set 
    customer expectations, for certain call types, that they
    should have the errorlog printed ???
    
    Also if there are connection problems, should we identify
    these and tighten up on actions to resolve them, such that
    they only bite us once.
    
    So feel free to input your vote/comments etc so that Frank
    can take the majority into account, to make his decision.
    
T.RTitleUserPersonal
Name
DateLines
129.1WHERE DO WE GET THE TECH STAFF FOR THE 90'S FROM ??KERNEL::GARNETTSat Jan 19 1991 23:0213
    MY FEELINGS ARE THEY SHOULD DIAL IN ,  TO GAIN THE NECESSARY EXPERTISE
    IN ORDER FOR THEM TO ASK THE RIGHT QUESTIONS IN THE FUTURE.
    THE OTHER CONSIDERATIONS ARE:-
    
    1....THE SIZE OF INITIAL TREE (AND THE TIME TO PRODUCE IT).
    2....OFTEN IT IS QUICKER TO DIAL IN RATHER THAN RELY ON SPECIFIC
         CUSTOMERS.
    3....THE EXPERTISE ALREADY EXISTS WITHIN THE "FE GROUP"
    4....THE "FE GROUP" WOULD PREFER TO DIAL IN !!!!!!
    5....SOME OF THE FRONT END MAY WANT TO DEVELOPE "TECHNICALLY" !!!
    
    NIGE
    
129.2YESKERNEL::JAMESAlan James CSC BasingstokeTue Jan 22 1991 12:1755
    re .0
    
>    This is a request from Frank Briggs, to solicit your
>    inputs/suggestions,as to whether or not the Front End
>    Desk should or should not Dial in to calls.

	Frank Briggs should not solicit.
    
>    Bear in mind that the goal of the FE Desk is to handle 
>    the calls as quickly and painlessly as possible in the
>    most efficient manner.

	Is quality important?
    
>    To give some idea of what we are looking at, consider an
>    8600 (whatever that is) Machine Check. There might be 
>    connection problems etc adding to the call time, but is 
>    this worthwile, in preference to expecting the customer 
>    to scan up/down the errorlog entry (if they have one 
>    printed off)
    
	Worthwhile - also by connecting, when this is considered necessary
		     or efficient, the group will gain the experience needed
		     to interrogate a customer with a hardcopy errorlog. 


>    There are some side issues, such as do we need to set 
>    customer expectations, for certain call types, that they
>    should have the errorlog printed ???
    
	No need to set expectations. The customer can be asked if she/he
	would mind reading the errorlog. If there is any hint of unwillingness
	we could always offer to dial in.

>    Also if there are connection problems, should we identify
>    these and tighten up on actions to resolve them, such that
>    they only bite us once.
    
	The connection problems are already identified - and ignored!!
	e.g.
	Why havn't MDS01's been put on 8600's as they have been in other areas?
	How many more systems do we have to crash  - just by connecting - 
	before action is taken.

>    So feel free to input your vote/comments etc so that Frank
>    can take the majority into account, to make his decision.

	The Front End group should be allowed to do their job as efficiently,
	effectively, and freely as possible. If they feel they must dial into
	systems on occasions then they should be allowed to.
	A more important point is what calls should they be taking. To take
	on System Calls means they need the dial out capability. Should they
	be taking these calls?    
    
    
129.3KERNEL::GARNETTWed Jan 23 1991 02:447
    THE BOTTOM LINE IS THAT IF THE "FE" GROUP DONT DO THESE EASIER SYSTEM
    CALLS.....THEN WE HAVE TO DO THE WHEN OUR ENERGIES SHOULD BE
    CONCENTRATED ON DEVELOPING SOFTWARE SKILLS AND HEAVIER TECHNICAL
    ISSUES (6000'S, 9000'S ETC).
    
    NIGE
     
129.4FE keep connectingKERNEL::WIBREWThu Jan 24 1991 01:0027
    
    
    	Yes, 
    
    	I think that the FE desk should use the option of connecting
    to a system to diagnose the problem. It provides a good test of
    the RD link, which is now important as RHM is coming to an end.
    We dont want to wait until the customer system is dead with feet
    in the air before we find we cant connect.
       The use of RD access should be the descision of the FE person,
    they will soon learn wether to connect or not in order to make
    effective diagnosis.
    It would be wrong to impose restrictions on who they handle their
    calls.
    
    If they find they have problems making a connection, these problems
    must be reported to local field sevice to get the link or the customer
    fixed.
    The use of remote access should be clear and simple for the operator
    onsite to setup, we should not accept situations where it takes a
    long time to connect where the customer is re-installing the modem
    etc for us to use.
                      
    With the advent of SDD etc the number of times we need to connect
    should reduce, however Remote Access will continue to be an essential
    tool for diagnosis.
    
129.5I agree...Dial in.KERNEL::CLARKSTRUGGLING AGAINST GRAVITY...Mon Mar 18 1991 12:5523
    In the area of devices diagnosis, I have long held the view that a
    front-panel fault code for some devices is not sufficient to make a
    good diagnosis. When faced with a Fault Light scenario, I believe that
    it is worth asking "Has the drive logged any errors with VMS?"
    	If the answer is "yes", then I believe that it is worth analysing
    the errorlog for further information, and in an extreme case, delving
    into the drive's internal silo.
    	All of this is best carried out by direct access to the
    information, rather than attempting to do OJT with a customer on the
    phone, in other words, by dialing in to the system.
    	All the FE people have the nessecary skills to dial in. It requires
    a moderate amount of development and support to enable them to unravel
    errorlogs.
    	This access to live data also provides opportunity for personal
    technical development, as identified in an earlier reply to this note.
    	Whilst I recognize the need for efficiency and speed in handling
    calls, I do not believe that this should be implemented at the
    expense of development opportunities and job satisfaction.
    	In the long term, I feel that the quality of diagnosis will suffer.
    	When the novelty and interest of a task has faded, the task
    becomes mechanical, with minimal individual input and quality being
    applied.
    				Dave Clark