by
Golden Rule for Software Support
Bottleneck
Area or Where the Shoe Pinches Most
(The following piece was written for a regular column in our office magazine where I planned to share interesting people related experiences while performing my role as a CIO (Chief Information Officer) there.)
Welcome
to this column which I call Camble's Rambles
(pronounced Cambel's Rambles).
Camble is what my friends used to call me at college. Rambles is a word
which rhymes with Camble. The synonyms for the word are
"Discuss" and "Elaborate".
I
plan to discuss in this column certain strategic issues related to
IT Management. I hope
to come back to you with this column from time to time and share my own
experiences in tackling various IT related problems in my day to day
activities. On several occasions I have come across instances which are
really interesting and worth sharing with you.
Ramble,
according to
the dictionary also
means "walk
for pleasure". Through this column I will also have a
"Pleasure walk" down memory lane. I am certainly not old enough
to be sitting in an armchair proudly relating my experience such as
"When I was in Gergovia..... ". But here goes...
What
I can remember today is a situation I faced only a few
days back - a situation when one of my users had rained on us
requests for changes in the Purchase system which was already
implemented and running for a few months. I had no resources to
allocate for carrying out
these changes as each of the few programmer analysts that I had was busy
in some project.
Golden
Rule
for Software Support
In
such a situation, how does one support the user or satisfy his ever
increasing appetite for system changes as judiciously as possible? One of
the golden rules which I follow is to try
and find a solution to his requirement as much as possible within
the system rather
than outside the system. The idea is to find a solution to his
problem with innovative use of the
existing package instead of with additional programming or any
modifications to the system.
This
has several advantages. For one, you get a tested product to solve
your problem. When you use the running system for
solving the problem,
the built in checks and controls are available to
you. While the system which you would be using is
a tested
and tried product,
any new program you
may write will not
be as reliable
since it will be put to use for the first time. As
the new program would
most likely be written in a hurry, you would tend to
skip providing enough checks and controls.
Leave alone the
time required
to write
or modify
a program
and most important,
the problems or risk of introducing a bug in a
tested program by modifying it.
The
instance I want to narrate illustrates how
the programming resources can be optimally used by keeping
maintenance activities to the
bare minimum. And how in this case a detailed
discussion led to a solution within the existing system.
The
Purchase system was being used by the Purchase Assistant
for almost a
year now. She was fairly conversant with
the system. Suddenly my
Systems Analyst came to me saying that
she had
requested some changes
in the system related to
PO Amendment, two of which we shall discuss here. The problems
were reported as follows:
Firstly,
she was unable to raise a PO Amendment to increase
the item quantity beyond the original PO quantity. She wanted this
to be made possible.
Secondly,
the PO Amendment print format presently lists out
the full amended PO. She wanted the amendment to show the old
figures and the new amended figures.
We
shall discuss both these problems in details. An analysis of the first
problem will show us how important it is to define the problem clearly.
The second case shows how an exact understanding of the users’ problems
helps to pinpoint where the shoe pinches the most.
You
must have noticed that sometimes the problems
reported and changes
suggested by the operating personnel cannot be taken
at face value. Some
probing is normally required to understand
the exact requirement.
Let
us try and understand the first problem. Further
discussions with my Systems Analyst revealed that the problem she
was facing was not that the
system does not allow increasing the
quantity, but that it
does not allow for increasing the PO
item quantity beyond the Indented quantity. That is, through a PO
Amendment, it is not
possible to increase the quantity
beyond the
Indented quantity.
I
thought that the restriction was fair. You cannot provide
for allowing the
quantity to exceed Indent quantity without loss
of control. I was
wondering what could be the situation
requiring such a
facility. I was sure her boss would not desire
to have such a
facility. I thought of talking to her Boss, the
Purchase Head.
I
asked him what exactly was the problem. I wanted to know how he saw the
problem.
He
said that he asks his Purchase Assistant to make an
Amendment and she comes back saying that the computer does not
allow her to amend the quantity. He also asked me to change my program
to allow this.
I
explained to him what exactly she meant when she said that
the computer did not allow. I explained that the system allows you
to decrease the quantity.
"Oh really?" was his reaction.
I
said it allows you to increase the quantity also.
"Oh
really? Then
why does she say she cannot change the quantity ?"
I
explained that the quantity can be decreased for sure and
also increased so long
as it does not exceed the Indented
quantity. Only if the
PO quantity exceeds the indented
quantity after
amendment, the system disallows.
"Well,
that is exactly how I want it to be. Then where is the problem?"
You
can see
how a communication gap leads
to an
improper definition of
the problem. The
Manager was not aware of the problem
because the Purchase Assistant could not clearly
define it. He only knew that there is a problem in the computer
program - that
it does not allow amendment in quantity.
But the real problem
she was facing was that she was not able to increase
the PO quantity beyond the Indented quantity.
Now
the question was why
did she at all need such a facility? What
could be the situation when such a facility is required?
Interrogations
revealed that this was the case with
only Steel POs.
For Steel Purchase, no formal Indent is received. Based
on the Projected requirements, the Purchase Manager asks her
to prepare a PO for some specified quantity for immediate
purchase. She on
her own makes a dummy indent for the same quantity and
then a PO.
Further
discussions revealed that if the indent itself
is made for a higher quantity, the problem would be solved.
Indeed
that is what the
Manager wanted. He said he can
easily make an indent
for the total projected requirement (instead
of for the quantity of
immediate purchase) and keep on raising
the POs from time to
time. As a bonus, he can at any time
know the pending
quantity to be purchased.
I suggested that
a proper indent format
is made
for steel purchase
which will be raised
and authorised by
the Purchase Manager himself.
That
was some relief to me as one of the two problems
at least could be solved effectively using the current system
without any modifications.
Any modifications to the programs on
this count would
be quite
some effort,
not to
talk of
the risk
of introducing fresh bugs while modifying.
The
second problem remained, that of printing the PO Amendment in a different
way giving both old and amended figures.
The
requirement seems
quite justified. For
whatever reasons,
during the
design of
the software, the
system and
the PO Amendment
format were
accepted by the user. (Of
course, the Manager
now requesting the change was not there in
the company when the system was designed). Any change now again
would mean some
programming effort which was very difficult to spare at that time.
Again
I asked the manager what exactly was the problem - I wanted the problem to
be defined as he saw it. He explained to me thus:
As
the PO amendment looks
exactly like a PO and lists all the items
again with the amended data it is difficult to
distinguish an original
PO with the Amended PO. Secondly, and what
is more important,
the suppliers
misbehave and
send fresh
material treating the amendment as a fresh order.
I
explained that firstly there is a clear difference between
the PO and PO Amendment. " Amendment No # " is printed on
the top of the PO Amendment
to distinguish it from the PO. It can in no
way be mistaken
for a fresh order. The
Manager asked
for the printouts of
POs and PO Amendments and found that indeed that was there to serve his
purpose. However I decided to probe further.
Bottleneck
Area or Where the Shoe Pinches Most
I
noticed that his main concern was that suppliers treat it as a new order.
That was what was worrying him most. If we be in
his shoes, we
find that that is
where the shoe
pinches most.
I thought of addressing his most pressing need.
For
his second problem, I agreed that an ideal solution would be to print a different format, but as this format was
accepted and provided
in the system,
making a new format would take some time.
I
knew I could not give him a complete solution in a short time. I thought
I will
at least solve his
most critical
problem immediately.
An
alternate solution
within the
existing system,
which I suggested they
could start using immediately, was as follows.
The
PO program allows to enter about ten lines of footnotes which can
be entered and directly printed as comments or footnotes.
I suggested that
if his problem was to
prevent suppliers
from treating it as a fresh order, a clear message could be entered
as a footnote by the operator saying that this is not a fresh
order and that there are amendments only in item serial nos. so and
so. This was acceptable to the Manager.
As
a follow-up activity, I requested him to give me a format
for PO Amendment, on the basis of which I would make a fresh
program.
The
Manager then felt that as the Purchase procedures were
being reviewed at corporate level by a committee which is also
going to recommend standard
formats for
each document,
it would
be advisable to wait
for the committee's recommended format for
PO Amendment rather than make our own and make a program for it.
As a result it was decided to continue with the existing format
with the solution just suggested and postpone any new development.
Probing
into the problem and understanding the users requirements better led to a
solution acceptable to both. It saved the need to immediately divert my
resources which would also
disturb my programmer in his current assignment. At the same time I
have time to plan out and give him a proper solution. I was successful in
finding solutions for my user within the existing system with absolutely
no changes required in the system. My user was
happy and so was I.
The
above incident highlights a few things:
With
the right strategy, considerable maintenance effort can
be saved.
The
changes requested by a user should always be ratified by
the department head - he often has a different and wider view.
The
exact problem is
sometimes not clear to both
the systems persons and the user and
we tend to hit the keyboard to
start modifications. A little deliberation reveals what exactly is
the problem, what is it that the user is exactly concerned about and what could
be an alternate solution (perhaps a better
solution than the
change requested by the user) which will address his most
critical problem (where the shoe pinches most).
I hope this article has kindled your thought process too. I will look forward to your reactions and views.