Whenever we start with a mission or with an objective, we are bound to face hurdles. Every journey is an adventure and we need courage to go through and win at the end. We undertake similar journeys when taking up systems for computerization. When doing so, we look at various steps in the process and try to automate them and also look at modifying the process or to eliminate certain steps that, in our opinion, are redundant. You may call it process reengineering or process improvement; but the fact is that processes do need to undergo changes when automated.
This is where the real test of the CIO comes to the fore. Resistance to change is normal and many reasons are usually put forth by the users to justify it. There are two ways in which the CIO can deal with this situation. He can either take an aggressive stance, take risks and push for full automation of the processes; or succumb to pressure and compromise on the solution and automate partly leaving some of the steps in the process to be done manually.
I have seen such situations often, either being directly involved as a CIO or having observed as a reviewer or consultant. It is very often that these difficult situations are evaded and an easy non-controversial path is followed that tries to accommodate the objections of persons who do not want things changed. The result is a compromise. When that happens, parts of the process are fast and efficient yet interspersed with manual and ineffective steps. The full process chain is therefore affected and the benefits of automation are not realized. I consider these partial automation cases as bad examples and not really worth emulating.
Let me cite a few examples of partial automation. As a CIO I initiated the work of automating the process of expense reimbursement to employees through vouchers. The manual process involved the employee preparing the voucher, getting it okayed by the head of the department and then forwarding to the accounts department for verification. Whenever the voucher was ready, he would go to the cashier to collect the money. Automation of this process involved the employee preparing the voucher on the system and forwarding it to his superior for approval which then would automatically flow to the accounts for verification. But it still required the employee to physically go the cashier to collect his money depending on the timing of the payment window. I then had to put my foot down and convince the accounts department to transfer the payment amount directly to the employee’s account with the bank.
Similar was a case in another company where the process of approval of special discounts required approval of the vice president – marketing. Since the VP himself was not comfortable using the system, he insisted on this part to be a manual process as he did not think approval through the system was secure enough. It needed considerable convincing to bring him on board.
I was recently reviewing a few processes in the Government bodies as a consultant. As it happens in most places, some departments were very good and some others tried to compromise. For example, there was a department that went for complete automation, in which papers needed to be sent from one section of the government to several others, but the responses could be received directly through the system. In order to ensure security, they introduced digital signatures and officials were reminded about their responsibility to keep their accounts secure. In contrast, another wing of the Government preferred to automate all processes within their department; but when approvals and responses were to be got from other departments, they were asked to take a print from the system, sign and then deliver.
Systems, when automated fully, run smoothly and provide the much needed efficiency; and the environment is devoid of papers floating around. Partial automation cases however are inefficient and carry along many of the problems associated with manual systems.