Conference kernel::csguk_systems

    I FEEL THAT WITH RDC CALLS (IN GENERAL) WE DONT HAVE A PROBLEM (OTHER
    THAN "POLARSTAR")
    TELESUPPORT CALLS REQUIRE A SPECIALISED KNOWLEDGE,IF WE TAKE CALLS
    ON WHICH WE ARE NOT QUALIFIED,THE ENG LOGGING THE CALL GETS A SECOND
    RATE SERVICE (THE BLIND LEADING THE BLIND !!!)
    
    NIGE
    

    
    re.[-1]
    
    OK we don't know everything about everything, but generally the average
    diagnosis Engineer can add value to most Telesupport calls.

    Given that the majority of Engineer calls are not of a complex nature
    but are just database/known problem queries then we do ok MOST of
    the time...However, we will always get calls from Engineers who
    know more about the product than we, who are trying to support him,
    do. Just as we will always get calls from Customers we cannot quickly 
    diagnose because of the unfamiliarity of the untrained.  
    
    With the RSDS calls it's a distinct advantage to be able to work
    at your own pace with only the contraints of time to worry about,
    but with CFSU calls it's a real-time live call situation and the
    answer to the query is required immediately.
    
    Maybe the way to redress this problem is to work in an environment
    whereby if we get stuck on a particular call then another person is 
    available who may be more knowledgable on the subject. With the way
    the office is set out it doesn't really encourage that atmosphere.
    
    So should we be thinking about what skills we all have and adjusting
    our seating arrangements accordingly ????
    
    (after all, it must be time for another change round ... :-) )

    
	Bob
    
        

    Alternatively, those that work on particular products increase their
    knowledge whereas those that don't let their knowledge of the product
    deteriorate. If you pick a call up on a product you are unfamiliar
    with and there are no customer issues then should you not keep the
    call. Passing it makes the guy who knows it learn even more and
    keeps you out of touch with the product thereby making you even
    keener to pass a similar call the next time it happens.
    
    Taking it to extreme extremes:- What would happen if 10 calls for
    the left CPU came in but no calls for the right CPU. The left CPU
    man (who knows everything there is to know about left CPUs) gets
    swamped and the right CPU man (who doesn't know about left CPU because
    the left CPU man got good at them by taking all the calls in the
    past) has an easy time. 8 or 9 customers do suffer as well!
    
    Steve.
    

    
    
    Firstly we are not a production line...relentlessly processing calls.
    We are a group of people who add value/diagnose or answer calls.
    If you get a call you are unfamiliar with, you could "ASK" someone
    who knows whether they can help or give any advice. You dont have
    to Pass everything!!!!!
    If you ASK you learn from the guy who knows and  he reaffirms
    his knowledge and everybody is happy. If I get a disk call which
    I know nothing about I ask someone. I try to ask people who I think
    know the answers, i.e. I try people just gaining experience on
    their choosen product range, this lets them see new problems and
    gives them a chance to learn, if they don't know I ask the senior
    group memember. This way once an answer is found not only have I
    learnt something but the less experienced person has learnt something
    too.
                                                 
    There seems a reluctance in some groups to work as teams. People
    want a perfect world and aren't prepared to put any effort in to
    acheive it, these people want the world to revolve around them without
    recognition for others. The net result of behaving like this is,
    in the end, zero. There are also far too many people
    all to keen to point out what we don't do, what we can't do and
    what we shouldn't be doing. Can we try to be more positive??!!!!!
    
    I agree with Bob (Sowton), we dont get it right all of the time.
    But we do a bloody good job most of the time. Lets start from there.
    
    Graham Archer.
     
               

     I BELIEVE THAT WE SHOULD BE AIMING FOR THE MOST EFFICIENT AND JOB
       SATISFYING APPROACH TO THIS PROBLEM:-
     DIVIDE INTO GROUPS ???;LETS CALL THEN "A" AND "B".......OH DAMN,WE
     TRIED THAT AND IT DIDN'T WORK.
       AN ALTERNATIVE WOULD BE TO SIT CLOSER TOGETHER (JUST LIKE THE GOOD
     OLD DAYS) SO THAT WE CAN COMMUNICATE MORE EASILY.I CONSIDER WEARING
     OUT THE CARPET TO BE A POOR SUBSTITUTE FOR "TRAINING"!!!!!
       THE GUYS IN THE FIELD DESERVE THE BEST SERVICE WE CAN GIVE THEM,I
     DONT BELIEVE THEY GET THAT WHILST I'M SCREWING UP A"NAUTILUS" CALL
     AND SOMEONE ELSE IS SUCCESSFULLY SCREWING UP AN 1170 !!!!!
       THE ANSWER,I BELIEVE,IS THAT THE SYSTEM NEEDS TO BE MANAGED BY
    SOMEONE LIKE A "T8" !!!! SO THE RIGHT CALL GOES TO THE RIGHT SKILL
    LEVEL ("DRIVE" ?????)

        Systems,as we know,is the dificult group when it comes to
    "the correct person for the call".With devices & comms it is fairly
    easy to point the call in the right direction,but within systems
    we cover a product group that has no definative boundaries.
    
        I suppose you could point to traditional products/unibus/sbi
    systems,plus the newer BI-based machines,then the even newer
    XMI machines,not forgetting PDP machines.There are 2 factors here
    to consider.Firstly the vast majority of calls are of the traditional
    products group,about which most of the group know a fair amount.
    Secondly,the newer products are more reliable & we don't get much
    exposure to them.
    
        It has been stated that the systems group will not split into
    any product groups.There is mixed feelings from what I hear,about
    taking calls people are not trained on.As Nigel stated,we need a
    mechanism (read person) wherby we can put the call into the hands
    of the person most suited to the problem,especially for FSU calls.
    
        Some suggestions fielded so far.That we should hire in someone
    specifically for PDP calls.Problem,the branches would wish to retain
    their expertise for themselves,even if said person were interested
    in moving to CSC,& if CSC mmgt were interested in this option.
                                                                  
    Monitors to be installed for FSU calls,with all calls being queued
    as with S/W calls (bar front end TSC).This would allow engineers
    to choose calls that they felt confident about handling.It would
    show up where the problems really lie,& then perhaps we could
    address those issues directly.I've rabbited on enough,any other
    views?
    
    
    Richard.

�       THE ANSWER,I BELIEVE,IS THAT THE SYSTEM NEEDS TO BE MANAGED BY
�   SOMEONE LIKE A "T8" !!!! SO THE RIGHT CALL GOES TO THE RIGHT SKILL
�   LEVEL ("DRIVE" ?????)
 
    
        It has been stated that the systems group will not split into
    any product groups.There is mixed feelings from what I hear,about
�   taking calls people are not trained on.As Nigel stated,we need a
�   mechanism (read person) wherby we can put the call into the hands
�   of the person most suited to the problem,especially for FSU calls.
    

    
    
     	Are you serious?

	Surely are we not responsible enough people (professional),
	to be able to decide, if/when a call requires re-routing or 
	higher expertise?   I don't need a T8 to tell me when I need
	help on a call, I already know that!

	What we do need is TEAMWORK.�  We need to be receptive to other
	peoples needs.  We need to pass calls around the group much more.
	We need to be more willing to accept calls from our colleages.

	I agree with Bob Sowton,  most of the time we do a good job, with
	greater emphasis on teamwork we'll do better.
	

	Brian

	� shouting for Nige �-}
				
                                                

    Yes,Brian,but the point is the "teamwork" isn't working,hence the
    need to have a mechanism to (using his words carfully) place a call
    in the right hands....
    
    The bugcheck acceptance of calls seems to work ok,but why,simply
    because it exists,it is an entity,somewhere to go to.Sixteen other
    engineers is not an entity.As someone recently put it,systems is
    a group of individuals doing their own independent thing.Teams are
    generally speaking small units,not infinite groups of individuals.
    

    
    I'll second Brian Anthony's reply. We have the skills, most of the
    time. It's just that no matter what we try, someone will always
    get a call, which they know very little or nothing about. The answer
    is TEAMWORK. Lets see who is available,move calls around,swap calls
    with one another, if that means a higher quality diagnosis. 
    That just takes a little thought, not a T8.
    
    Monitors, displaying RSDS/CFSU calls would help us to see who has
    what calls and help us to see who we might exchange calls with,
    or who we might go to for help,depending on their workload.
    We can all learn from each other and improve/broaden our skills,
    but sometimes we need to get our "experts" dealing with the call
    first hand.
    
    We can do it, it's just that we rarely try.
    

    I REMEMBER THE DAYS WHEN TEAMWORK WAS VERY EFFECTIVE IN RDC,WE WERE
    ALL IN THE AREA OCCUPIED BY THE CIC RESPONSE..COMMUNICATING WAS
    EASY......EVEN ON A "MONDAY MORNING".
    THE CURRENT GEOGRAPHY DOESN'T HELP COMMUNICATION,I HATE TO CONSIDER
    WHAT WOULD RESULT FROM EVERYONE PLAYING "PASS THE PARCEL" ON A MONDAY
    MORNING............WHEN DO TELESUPPORT CALLS SUFFER , BUSY TIMES ??
    ,MANPOWER SHORTAGES ??...WHEN THERE ARE ONLY 2 OR 3 OF US PICKING
    UP CALLS ??..............DO WE REALLY JUST SHOUT "TEAMWORK" !!!,I
    WOULD RESPECTFULLY SUGGEST WE MUTTER SOME OTHER CHOICE WORDS.....
    LIKE , WHAT *%#@*&% BUGCHECK DESK !!!!!
      I STILL MAINTAIN THE SYSTEM REQUIRES TO BE "MANAGED",AS IT IS
    WITH "LIMITED SUCCESS" BY THE "ECSO MAN",PERHAPS THIS SYSTEM IS
    A LITTLE BIT ON A "HIT OR MISS" BASIS !!!
    

    It seems to me that one of the biggest problems is the fact that
    we are still using two call handling systems for hardware calls.
    Does anyone know why TS calls have to be logged on CFSU during the 
    day and yet out of hours it's ok to log them as Tech Assist on 
    RSDS ?

    Surely, just using RSDS would eliminate both the need for Call monitors
    and the requirement for an overseer.
    
    Just as a difficult (perceived) Customer call can be offered to a more 
    suitable person, (such as a bugcheck) so might an unfamiliar product 
    query be referred to a level two Engineer.
    
    Using one system would help build the team atmosphere.
    
    
    Bob
    
    

    TEAMWORK is what it's all about, sure, but we don't have any teams
    in the Systems Group, apart from the Bugcheck Desk.  16 people is
    too big to work as a team.  Small teams work best.  
    I know that 15 people can work quite successfully as a team, chasing 
    a funny-shaped ball around, but they have to chase only one ball.
    We have to handle lots of calls, and we have to deal with them as 
    individuals.  

    Can we create some teams?  Might even develop a competitive spirit!
         
    I know it's not obvious how to structure these teams; that's why
    I'm asking.

    	But we can all work as a team if we try hard enough.
    Sure 16 soundslike a large number, but remember that at most there
    is usually only 8 working at any one time.  Take away those on the
    bugcheck desk, say 2 people, makes a nice little team of 6!
   	 Why not have a team meeting at the start of each week (say monday
    afternoon), to build the team spirit.  We can identify our strengths
    and weaknesses, (eg focus people for certain cpu's etc), nominate
    a member of the team to be a "chaser" for telesupport.  We can make
    sure shift coverage is correct (number of 7:30 starters etc).  These
    are just a few ideas, I'm sure there are many others.  You never
    know, we could even do a few exercises at the start of the day,
    just like our oriental friends.
    
    Brian
    

    re .12
    What is the point of having teams? If you do have them:-
    Do you want these teams to specialize in any way? 
    How small would your ideal team be? (you did say you
    like them small, Theo)
    Will these teams have certain responsibilities? You know the 
    sort of thing; this week team A provides the milk monitor,
    team B clean the ECSO board, team C does Telesupport. Next 
    week they swap round to the left. 
    
    C'mon Theo, tell us where your leading us on this one.

    I see two main reasons for having teams:
    
    1. To build up TEAM SPIRIT.
    2. To have several strong, efficient, all-encompassing, self-contained,
       solve-anything, do-better-than-anyone-else, all-things-to-all-men,
       universal, units.
    
    I don't think we can achieve 2. because of the resource limitations
    which prevent us from organising teams according to any of the more-
    obvious criteria like experience, skills, specialities, height,
    hair-colour, etc.
    
    However, we can achieve 1. by organising teams according to other
    criteria, eg. participation in a/some common project(s); common
    interests (bugchecks, clusters, calypso's, 8600's (a team consisting
    of Brian Adams), etc.); different but complementary interests; similar
    hobbies; similar religions (anyone want to join my team?); smokers,
    tolerant non-smokers (anyone want to join my team!?), and intolerant 
    non-smokers; etc.
    
    This may all seem very silly, but in fact it's BRILLIANT.  It just
    needs VISION to see the potential.
    
    I have a dream..........
    

    
    Theo,
    
    Thanks for the compliment of my team of 1 for 8600.
    
    But why should I hog the limelight. Any 8600 team should include
    ALL the level 2 trained people, so it would be 
    
    Richard Hoblin  Nigel Garnett (stop hiding in TPL land) and
    Norman Pettet.
    
    Why not include the Level 1 people i.e almost everyone else.
    Exposure builds experience, and you never know when you might need
    it on Nights/Weekends. It is no good saying "I'm not trained on
    that" when the level 2 people aren't on shift !!
    

    BRIAN YOU FORGOT TO INCLUDE BOB SOWTON IN YOUR TEAM (LEVEL 2..8600),
    I'M SURE HE'LL BE PLEASED I'VE TOLD YOU !!!
    IF WE CAN MANAGE TO ORGANISE ENOUGH TEAMS,NOBODY WILL KNOW WHATS
    GOING ON........OH SH-ONE-T.....THATS WHAT WE'VE GOT NOW !!!!

    Re .14. Having also been in the airforce, I'm a bit surprised at
    your comments Roland.I know this is industry,but the whole of industry
    & Digital in particular,works in teams.In the field they are known
    as SDU'S.Why is CSG so different,that we can't follow the Drive
    model.
    
            My suggestions at the last unit meeting were perhaps radical,
    & didn't gain support from management or engineers,but some people
    did inform me that they favoured product focussing.I'm not going to
    harp on about product split that is history,suffice to say that progress
    above T6 level is product focussed.
     
     Another suggestion from this stable,is that we rotate between RSDS
    & FSU call handling.While the two call-handling systems exist this
    might be worth considering,say one week on,one off,similar to the
    bugcheck desk but a smaller time period.Supposedly Systems should
    fairly well cross trained by the Summer,I don't see a skill's problem
    here.
    
    
    Richard.

    SORRY RICHARD....ABOVE T6 IS FOCUSSED PURELY FOR REVIEW BOARDS.
    THE REQUIREMENT OF THE COMPANY FOR THE FUTURE IS TO ENCOURAGE:-
     
           GENERALIST SPECIALISTS...OR SPECIALIST GENERALISTS
                AT LEVELS UP TO T9/T10
    
    I'M NEVER SURE WHICH OF THE ABOVE IS CORRECT.

	
	Initially I would like to thank the Systems moderator for 
	allowing Devices persons to participate in your notes file.  
	I have, in fact, applied to become a moderator in order to 
	represent the interests of the Devices group.  I will then	
	set hidden all of Theo's notes to demonstrate to him the 
	benefits of censorship.

	If you want to see the benefits of real teamwork look no 
	further than the other side of the filing cabinets where
	camaraderie and co-operation abound.  Admittedly to achieve
	this we had to sub-divide the group into smaller teams along 
	the boundaries of specialty, however there is still a lot of 
	flexibility across specialties in times of need.

	It seems to me that a product split within Systems should 
	be easier to implement as 2 CPU's are more similar than say
	a Disk and a Tape drive.  A step backwards? perhaps but then
	it takes a brave manager to admit when he's wrong.

						a team member.

    
    
    I would like to be in everybodys team please...
    
    
    
    
    Anon-smoker.