Home
|
BACK | Key Success Factors | IT for Business | people issues in IT | other articles on IT | Download articles |
|
by |
||
|
Read Comments Submit Comments Contents USER SUPPORT STRATEGY USER SUPPORT STRATEGY Golden Rule for Software Support |
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...
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. 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.
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. 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 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.
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). 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. Related Readings: The Management is Shocked to Know that... More Articles for CIOs / IT Managers Also See: |