Make your own free website on Tripod.com

  BACK | Key Success Factors | IT for Business | people issues in IT | other articles on ITDownload articles       

 
     
 
 

CAMBLE'S RAMBLES

  by

Prem Kamble

 
Read Comments
Submit Comments

Contents  

USER SUPPORT STRATEGY

Golden Rule for Software Support

Problem Definition

Bottleneck Area or Where the Shoe Pinches Most

CONCLUSION

Learnings

















































USER SUPPORT STRATEGY

Golden Rule for Software Support

Problem Definition

Bottleneck Area or Where the Shoe Pinches Most

CONCLUSION

Learnings

Summary:

This article relates a best practice in a support function – a job of supporting your customer of an application software in a changing environment. The author narrates a real life situation when one of his users had rained on him requests for changes in an application system which was already  implemented and running for a few months. He was seriously short of resources as each of the few analysts that he had was busy in some project.

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 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. Apart from saving in time, resources and cost, the author has often found that he ended up improving the process for his customers in the bargain.

(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...

 

USER SUPPORT STRATEGY

Comments    Top

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

Comments    Top

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. To top it all, most often you end up improving the process thereby benefiting everyone including the customer and the company. 

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.

 

Problem Definition

Comments    Top

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.

Top

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.  Steel Purchase was mainly from a single government agency, where there is no PO for individual deliveries. Instead there is an annual contract to supply a specified annual quantity, and the deliveries are spread out across the year. We discovered that since steel purchase was a special process and a different process, no indent and PO was raised for it. The contract agreement itself served the purpose of PO in the manual system. So in the computerised system it never got raised. The approximate projected staggered requirements were given to the steel supplier, who would then deliver according to the estimates, or last minute changes communicated otherwise, throughout the year.

Now how do you receive the individual staggered lot which was delivered without a PO? Some bright guy thought of a workaround - whenever the lot arrived, they asked the purchase assistant to enter a dummy indent and PO in the system for the expected quantity. So far so good. This workaround would never have been noticed. But there was a problem. The quantity which arrived often did not match the quantity in the dummy indent and dummy PO. Since the quantum of individual staggered deliveries were often altered based on even verbal instructions and did not matter so long as the annual quantity did not axceed the contracted quantity, it was common to make last minute changes in the actual quantity delivered in the staggered lots. No problems, they thought, when the quantity exceed the dummy PO quantity, they thought they would alter the PO. There was no problem so long as the delivered quantity was less than the dummy PO quantity. But when it was higher, the system did not allow an amendment to increase it beyond the (dummy) indented quantity. After all, the system did not know whether it was dummy or not, for the system every indent was real and every PO was real!! That is when a brighter idea of requesting for a system change for this special case arose - and was loosely worded as "change required to allow increasing the PO quantity". Although the change request itself was questionable, but if it all it was to be raised, the correct wording of the change request should have been "all increasing the PO quantity above indented quantity". 

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.

In this exercise, I not only saved the effort and cost of amendment, I plugged a major loophole in their process. For the exceptional case of Steel purchase, no PO and indent was being raised. 

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

Comments    Top

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. As my customer's immeidate pressing problem was resolved, there was no hurry to deliver this PO Amendment and I had bought the time to do justice to the job.

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.

 

CONCLUSION

Top

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).

Learnings

When the business study was on and automated business processes were being designed, nobody would have thought of this exceptional case of steel purchase which followed a different path in the manual system. When automated, the user found a way to beat the system without anyone's knowledge. Even the head of user department did not know of the workaround.

The way the problem was communicated by the end user was incomplete. The user said "I am not able to 'increase the PO amount' in the Amenedmen" 

What the Head of the department understood of the problem was even more distorted. "The system does not allow for changes in the PO Quantity"

It needs real probing to really zero in on the right problem and to define the problem correctly. 

Look for where the shoe pinches the most.

I hope this article has kindled your thought process too. I  will look forward to your reactions and views.

Top

Related Readings:

Computing - A Field Job

The Management is Shocked to Know that...

More Articles for CIOs / IT Managers

All Articles by Prem Kamble

Also See:

Manager's Key to Success in a Changing World

More Seminars for CIOs

                                 Home