|
Here are my thoughts:
Dave's point 1
==============
Dave's primary role should be as a technical resource to the group,
not as an escallation path/route. i.e. we maintain call and
problem ownership but utilize Dave's skills to help resolve
the problem.
If the call does require escallation to BS, then we should do
so in the usual manner. (but with the correct write-ups, see 175)
A typical call flow:
-------------------
call logged : system bugchecks, and reboots.
engineer 1 : diagnose problem, no resolution available,
customer dissatisfied and requests further
action. engineer 1 requests dump to be sent in.
engineer 2 : dumps arrives, gets loaded, and is diagnosed
again, still no resolution. call open in
engineer's queue.
2nd call logged : system crashes again
engineer 3 : diagnose problem, still no resolution,
customer very dissatisfied.
problem escallated to backup support.
backup support : take on problem ownership, but have difficulty in
understanding the call escallation processes.
using Dave this could change to:
-------------------------------
call logged : crash etc
engineer 1 : diagnose problem, no resolution etc
seek help from Dave�. either by mail or by 'phone.
Dave advises other actions or concludes dump
should be sent in.
call written up with actions taken
engineer 2 : loads dump etc
if no resolution, MAIL call detals to Dave who
will investigate. engineer 2 still OWNS the
problem. Dave helps out and advises actions.
call witten up with actions taken
further crash etc
engineer 3 : we advise customer that the problem has already
been escallated (we have visability of what has
gone on before�) and if a fix is not forthcoming
the call will be escallated further
(we can use priority field to identify level of escallation?)
engineer 2/3 : consults with Dave, and both agree appropriate
actions (could include customer actions)
call written up etc.
: still no resolution
call ownership passed to backup support (could be
Dave) at highest priority (1?)
� Dave may not be available, so use other member of BS, but
we retain call ownership at this stage.
� we have a tool that allows us to quickly identify all open
calls in the systems group. i.e. if you handle a call, one of
the actions you should be taking is to check for any other open
calls for the same customer.
Dave's other comments:
I have no problems with Dave looking through queues for stagnant
calls, but I appeciate this needs to be a group decision
Dave's points 2 and 3
====================
(help by taking calls when availablity is low and front lineing)
If Dave is in the office, then the live call handler can pass
calls (bugs) to Dave.. This could work quite well, but needs planning
Brian
also read 174 and 175
|
| Here is more mumble from me. I sent it to the CIG committee just now!
I don't expect I will be at your CIG meeting, I have made some of my
views known in the notes file, I don't feel that all of them have been
understood too good though! I am putting down a few points here to clarify,plus
some more stuff!.
1. The whole thing about writing up calls is to make it easy for me and
others to find out what has gone on with a call and what the current status is
without too much brain damage.
(looking through many of the groups calls is a NIGHTMARE and very time
consuming. You can mail the call to yourself, but it don't read in
chronological order - also a lot of them are too long for mail to work). Doing
show description 20 or so times is no fun either.)
To this end I think ONE description (I suggested 'A' for this) to
summarise all the action plans, technical conclusions locations of dumps etc.
Hopefully an ops/backup/manager person could look at this one description and
get a summary of all that has gone on. If they want more info they can look at
other descriptions and find
technical updates by various specialists (gory details)
diagnosis notifications to the branch
canasta summary (for proposed search tool also)
comments from people outsinde the group (eg ops, ccd)
What codes we give these don't matter too much as long as we all agree and
it is easy to remember/not too confusing. (I think the only bit that is
in dispute is the first two, what we should call them eg p and dn or P and
ta/td)
Also the number of updates don't matter too much, if the call goes through a
new phase it might be appropriate to create a new 'a' description, likewise
if different specialists have a go it makes sense to have different technical
updates if they have a lot to say. I just want us to get away from the current
thing where you may have the same person put half a dozen updates on in a
couple of days...
--------------------------------------------------------------------------------
2. As well looking at calls when asked, I have been going through the calls
in the systems and bug_hold queue on an ad-hoc basis. I time stamp the call
using the opt-sup field and if I can think of anything useful to say I will
put an update on. Also if I think the call needs some action I will
say - eg escallating.
A number of questions comes to mind on this
> I would like to do this through individual queues. Does the group
want me to do this - or should I leave other peoples queues alone?
> if I timestamp the calls can I ask others to leave that field alone,
if it gets used for other things my system will get confused!
I don't want to sound too pushy but if I put an update on a
call saying should do this - I would rather have an argument about
it than be ignored. (I can think of a recent example when I put
update in evening with a comment on the front saying to check my update
- but was told the next day that hadn't get around it because he wasn't
too sure about ....) If I haven't made myself clear please mail or
phone me, especially if it is an important customer.
(I am not making this a high priority, I will aim to look at most calls
about once a week, but only when I have the time. I don't want chaps to
start relying on me to do it, if you want help on a call please still
ask.
--------------------------------------------------------------------------------
3. Regarding call ownership. I like the way that the calls are
owned by the group rather than one person. Much better way of doing
things. to make it work best need to sort a few things - if not already
what happens if someone is away, especially aes calls, who responds to
the updates
how do we ensure that an indepth analysis is performed (rather than
several people having a quick look). I expect that is where I can
help, but think it should be part of the procedure independant of me??
(as I think I mentioned, need clearer updates, if you are passing
calls around all the info must be on the calls in an easy to find
format)
--------------------------------------------------------------------------------
4. > Can you make sure that dumps are not automatically deleted when the
call is closed. (If it is a call I have worked on please mail me just
in case - I have been caught out before when I have resequenced a
call and lost the dump AND the tape got sent back! These ongoing
problems where the call is closed pending a recurrance, it would
be advantagous to retain the dump or at least the tape for a month
or so.
(i will be setting up something (oneday) to help archive dumps...
--------------------------------------------------------------------------------
5. Please make the use of the available information. With the high volume
of calls you guys do it is easy to not to use what you
have already. I do this myself, often miss the obvious.
eg.
Non-fatal bugcheck, set bug-check fatal but not check the error-log
to see what crash it is.
hangs - getting the customer to force a crash but not getting them
to halt/continue a few times to see what it is doing.
Not getting the customer to check the console/search operator.log
etc ...
--------------------------------------------------------------------------------
6. When you want to get hold of me - the details of when I am expecting
be contacted should be uptodate on router, (normally when I am awake.)
If you can't get through you should get a voice mail instead. Please
leave a message I should get it as I check voice mail quite often. If
you can try again a little later if you don't mind as them
yuppy phones don't always get thru first time.
<<< Note 173.0 by COMICS::GLEDHILL >>>
-< Dave Gledhill - team mascot >-
|