| I know standardisation is the modern way to go (maybe we will all look the
same one day..)
As you would probably guess I don't think that standardisation for its
own sake is a desirably thing - there may be advantages but do they outweigh
the benefits of indivuals/groups using a method appropriate to their particular
needs. I am aware that others use different standards so whenever
I pass a call to another group I put on the top of the call a pointer
to the up to date summary for the benefit of anyone who doesn't understand our
methods. (eg see 'a' descr by dagle). That 'a' desc may well have pointers to
other descriptions on the call.
I expect that most calls that are passed between individuals are passed within
groups, not between them, so it is the intragroup interface that is the most
commonly used and in my option should get the most attention.
When I became the mascot for the systems group I found it almost
impossible to understand what was going on most calls passed to me, often 3,4
screens of descriptions of various types by many different people. We spent a
lot of time evolving a method that works very well I think, appropriate for our
group, but probably not for any others. I dont want to have to change this
for the sake of the 1% of calls that we pass to other groups... maybe we won't
have to, I would like more info on your proposals (can you mail me the full
minutes) - it may be that our methods would work with yours anyway.
To restate my point, it may be possible to standardise to every ones benefit,but
it may be at the expense of 'local' benefits.
I would be interested to know who is the rep from the systems group and whether
he agrees with me!
--------------------------------------------------------------------------------
here is the mail I am replying to. I have address stuff marked with ****
Hello All,
Some of you may not be aware but I am your representative in the
local Change Forum panel within the CSC.
Change Forum is an improvement group and we should all by now be
booked on the Change Forum event which will be held over the
coming months.
From a local point of view, we have been looking at trying to
build bridges between the various groups in the building . The
first and hopefully easiest should , we think, be beneficial to us
all - that is a common template for call write-ups.
The way we implement this within each group can be different but
the basic aim is to ensure that the templates used, contains the
same basic criteria - regarded as important information - for anyone
who may need to look at the status of the call.
Once a call template is in use - it should be easier to adopt a
"fine tuning" to show the state of the calls at a glance , maybe
by use of the LRS codes. Both of these are discussed below.
Please can I ask you to read the following, which I have extracted
from the minutes of our last meeting and give me any feedback on
the proposal of implementing this within VMS . I'd appreciate any
thoughts by the end of the week if possible.
Thank you in advance for your time.
Lisa.
********************************************************************************
Subj: A: Notes/Actions from UVO Change Forum - 04-MAY-95
From: NAME: Jon Morris
FUNC: UK Customer Support Services
TEL: (01256) 373554 or DTN 833 3554 <MORRIS AT A1UBOHUB AT LARVAE AT
U
CG>
To: See Below
CC: See Below
Folks,
Here are the notes I made at our meeting with a list of actions for
us all to take.
We discussed reasons why the LSDd/t option was not being used
extensively:
- people were already comfortable with other techniques
- people using LRS or Service Wish instead
- people have an ownership feeling around their queue and
want to do it `their way'
- having a queue backlog makes it harder to plan and manage
to LSDd/t
- with the best will in the world, even if you plan and set
LSDd/t, it can all go to pot if one call goes pear shaped
- not every team has a process for managing queues of
absentees
- some people may need help with associated skills (planning
and organising, time management) and self discipline
The meeting focussed on call management standards and, initially,
the list of topics was:
Call Updates
LSDd/t use
LARS codes
Queue management
LRS codes
Service wish field
Priority field
We spent a short time looking at LRS codes, of which the commonly
used ones are:
blank because no Specialist has yet spoken to the
customer
CUS the action is on the customer to try something and come
back with the results
TRY the Specialist is trying to get back to the customer
with some plan or information
WRK the Specialist needs to do some work on the call before
going back to the customer
ZOM the call is in a `zombie' state - probably waiting for
an agreed time period to expire with no further
problems, after which the call can be closed: these
calls should be in the Resource Controllers WAIT queue
********************************************************************************
** I try to use the lsd time mainly because I got a mail saying I should be
** using it. I would use it more extensively if there was a way for it to
** to send me a message when the time expires and if I could find a way to
** list a que showing the rec time AND lsd time AND optn supp on one line
** (there may be such a thing, I haven't needed it enought to look for it).
** I (not systems group as well) have a more detailed status thing using the
** optn supp eg.
rms dump/cc<2-ap ie rms dump,contact customer before 2-apr (would
prob set lsd date as well even though I wouldn't us it)
astdel/awc 9-ap astdel crash, await customer action since 9-apr
(I would set lsd date to chase date her
sls/**wr** sls problem, work required (more stars
the more urgent it is. Will do it as soon I can fit in (if there is
an agreed deadline I would put a date in as well,but most of the time
I work on calls as soone as I can.
sched/to>3-feb scheduler problem, will close (timeout) call
after 3-feb (normally for aes calls where I have told the customer
that he can mail me back if he want any more help, else I will close
the call.
ucx/t1>8-mar ucx problem, will send a message after that
date saying will timeout call (ie will get to status after that.
etc...
I want to continue using these as they help me do the job, I could use the LRS
as well, but would be a waste of time to me.
********************************************************************************
We then worked on a standard for call updates. We agreed the
following proposal:
1 Each call will have one (and only one) P description.
2 All information relating to the call (technical updates, call
information updates, solution information, closure criteria)
will appear in chronological sequence in the one P
description, from top (oldest) to bottom (newest).
** note that the systems group can't use this as they need to use the p desc
** for branch updates. (we use a single a descriptions for a summary of the call
** (non tech overview), multiple ts desc for gory details (noramlly one per
** person whos has looked at the problems) ca for canasta summary (for crash
** dumps only). I use RC desc (until I get around to creating a new type eg SU)
** for suggestions I have made for calls I have never owned, but have seen in the
** queue of incoming (awaiting tape in post) queue.
3 For AES calls, which may have many DP and DS descriptions,
these will be summarised in the P description.
** this will be a real drag and slow me down (ie reduce the no of calls I can
** take). The whole advantage of aes call is that they are self documenting
** and easy to work on a read/reply sort of basis.
4 All technical updates will have the following minimum
information:
- date and time of update
- name and DTN of person making the update
- the update
- an action plan (which must include who is going
to do what and by when). Where the action plan is
to close the call, the name of the customer who
agreed to closure must be included.
** by our scheme of things this would be on the non-tech (a for action plan
** desc, the technical update would be more just that...
5 All call information updates will have the following minimum
information:
- date and time of update
- name and DTN of person making the update
- the update
** not sure what sort of descriptions this means.
ACTION - All
We will all discuss the above proposal within our Teams to solicit
feedback on the practicality of achieving it. This discussion will
include the question: "Why couldn't the LSDd/t be set to be no later
than the `by when' part of the action plan?".
The output from these discussions will be brought to the next Change
Forum meeting to finalise the proposal and agree the standard.
ACTION - Jon
Jon will set up the next meeting of the Team in about two week's
time from 04-MAY-95. The objective of this meeting is to agree the
call update standard and develop an implementation strategy,
including suggested technology fixes/aids.
|