ACES: Did it succeed as a core workflow project ?

ARTICLE:
ACES: Did it succeed as a core workflow project ?

To measure the success of an event or venture, usually the positive factors are set as a criteria for achievement. At times, it so happens that even if certain painful factors are eliminated from execution, the venture can still be successful. Here, to determine the success of the Central Excise and Service Tax Department's Automation Project - ACES - we apply certain painful factors for elimination, to decide about the success of the project. Were these factors, GROWING PAINS, eliminated under the project management ?


* Growing Pain 1 :
Bugs in the Software:
Goals of automation skid owing to poor understanding of the domain by the IT project team, or problems interfacing with existing systems and hardware difficulties. If there is a lack of resolution of solving technical problems and its proper management, automation process may lead to a doom. In Aces, this direction is yet to get narrowed even after nearly two years after the launch. The field formations - not all, but at least those which implemented the program vigorously - have been wanting to get cleared many glitches faced in the workflow. Many of them are yet to be decoded. It looks puzzling to think of implementing a new module. Major problem is inability to watch the pendancy status or progress position over a period, even at the commissioner's level.


* Growing Pain 2 :
Treating the automation process as if it is a narrow IT section's facilitation
(as if only officers working in computer section is focussed on) :
Treating the implementation with this 'as if' treatment defeats the purpose of automation. As told by an expert, "....in such a condition, technology deployment will take place in a vacuum, re-engineering and alignment of work-flow with software requirements will not take place, and staff will resist using it". It is felt that sufficient push is not attached to the implementation widely across the country. Only a handful of officers are aware of the positive and negative factors of the project and the rest are happy with doing the work manually ! There is no compulsion or systemic mandate to undertake the electronic workflow of files and documents. But if that mandate is to come by, then all the bugs in the software should be eliminated first.


* Growing Pain 3 :
Leadership in middle hierarchy :
If senior or middle level hierarchy officers do not evince interest in actually using the workflow in real-time, and if they are not committed to the changed environment, they can not project the success of the plan as a result of the profound changes necessitated by process; in another department, officers used to hand over the user id and password to the lower level officers and dictate them to post what they wanted into the workflow. For them, this appeared to be ceremonial flow, not requiring to undertake the workflow seriously. Conversely, they need to view the project as a means of transforming the administration. Being within the Dept. the author cannot stress much on this aspect. I see some users asking for a print-out of the page of confirmation screen of completing the task !


* Growing Pain 4 :
Inaccurate data:
Data entered into a digital workflow is to be used by the entire organization. Because of the integrated nature of workflow, if inaccurate data is entered into the common database - particularly by the assessees in various application/return formats, the erroneous data may have a negative domino effect throughout the department. Inaccurate data can lead to errors in revenue planning, HR and other administrative planning and management. If the Dept. with inaccurate data just forges ahead under the assumption that someone will correct the data errors when they are spotted, then the automation will lose credibility. This encourages people to ignore the new system and continue to run the Dept., under the old manual system. Users working at the level of capturing data, like the executives of assessees or the Dept. have to be coginizant on the accuracy and the validation of the data posted. Any shortcut method to skip entering true values in an 'embarassing' field or column should be strictly prevented. Non-accuracy of data when capturing the Returns in the old Sermon Software was one major reason for its failure and the board could not use the reporting modules effectively to take a decision on the tax policy; no data was available against selected Notification or SSI status or duty ratio trends, etc., under "sermon". Till now, under ACES, no MIS reports have been enabled. The old migrated Return data is not useful in ACES, for either it is incomplete or inaccurate. Difference is found in the data between the one generated out of the working menus and its corresponding status from the Report module.


* Growing Pain 5:
Unrealistic expectations:
Departments grossly underestimate the amount of resources, time, and outside assistance required to implement and run the new system. Moreover, administrators and the staff frequently assume that performance will begin to improve immediately after launch. Since the new system is complex and difficult to master, organizations must be prepared for an initial decline in output after the new software comes into operation. As familiarity with the new system increases, the expected improvements will come. However, administration must be prepared for initial waves of frustration. Sustained encouragement and appreciation of the users is essential to keep the expectations of the software high. The CAG Dept . has to view them in a 'soft' way and it is no good weighing the worth of the software against the past period or shorter period.


* Growing Pain 6:
Lacklustre Management of co-ordination between the tax policy research cell and System Project:
Credibility between these two administrative machinery is essential, failing which changes in technology implementation can go awry every time when tax policy is altered or amended, anything from notification to rules to procedures. Proposed changes in policy needs to be discussed with the Systems side well in advance before the change is brought. Transparency applies to everywhere. If the administrators do not initiate the necessary level of detailed project management planning and control, then, the scope, size and complexity of automation process implementation can end up surprising the administrators who are supposed to use it. The project has to be thought of in a scaled up environment so that any changes in the software due to technical or administrtive changes immediately on the launching does not cost one more fortune to the Government. The current status of the ACES scalability is not known. Latest, this news is merry-go-rounding the press: " Ministries consider XBRL for public enterprises, GST regime"


* Growing Pain 7:
Inadequate education and training:
Top System Managers and all users must be fully educated so that they understand how to integrate the workflow system into the overall department operation. Users must be trained to take full advantage of the system’s capabilities. Failure to educate and train all relevant personnel will guarantee implementation problems. This is one area plaguing the field offices now. The training given to the officers initially was very rudimentary and it just opened out what was prima facie available in the program; there was little follow-up on the various working problems people came across after the launch. The website also does not contain any manual for the officers. There is an unbridgeable gap between the users who were trained but did not have the domain knowledge update and the users who were updated on the domain but lacked training.


* Growing Pain 8 :
Trying to maintain the status quo:
People have a natural tendency to be comfortable with the status quo and may be fearful of changes brought about by any new system, where performance of each individual is system-measured frequently unlike manual way of annual confidential reporting. They may fear that the new system will make their jobs more difficult, reduce their importance, or even cost them their jobs. People are also afraid of failure. These reasons compel them to continue with the manual workflow. This is a dangerous approach and the administration needs to wind up the manual workflow practice immediately. At present, only the Range Superintendents are working in Aces while there is no workflow for lower or middle level officers in the Division or the Commissionerate, not to speak of the role of Inspectors. This keeps the manual workload being continued for the 90% of one's time or workload, while working in Aces takes only 10% of the workload.


Department has to consider whether these negative points really exist in the hierarchy. If they are really there, until all the above negative factors are eliminated, the success of Aces cannot be determined. The big advantages of Aces' MIS reporting (using the data-warehousing/data-mining concepts) as apprehended in the previous article might be missed by the Dept. Under Aces, it was missing owing to non-availability of legacy data for the past. CAG field visits are already indicating negative opinion about the efficacy of the program. If GST is impemented, it will take another 3 years to build the lagacy data for intelligent administration. Judging the efficiency of any venture when the venture is out of shape due to its immaturity to the desired growth level will poorly reflect upon the judgement itself.

[The views expressed above are personal of the author and does not subscribe to be those of the Department where he is working.}

No comments:

Post a Comment

PLEASE QUOTE YOUR E-Mail Id