{'fraction_non_alphanumeric': 0.015440508628519528, 'fraction_numerical': 0.0012110202845897668, 'mean_word_length': 4.953153153153153, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Reworking with a Legacy Financial Accounting System: Lessons from a Pharma Company

The issues of legacy systems become more pronounced at the time of a major IT upheaval such as implementation of ERP or business process reengineering (BPR) exercise. In this changing scenario, there is a need to update the systems and skills and integrate them with the emerging enterprisewide infrastructure. The main problems with a legacy system are that it remains insulated from the update attempt that largely follows market trend thus rendering it outdated and also that its documentation is poor. In this paper, the authors share the experiences of a project undertaken in one of India's leading multinational pharmaceutical companies (MPC) which was to rework on the existing legacy system and design a new application. The legacy system referred to here is the company's financial accounting system which was developed in 1993. Originally designed in COBOL, it was subsequently improved as and when the finance department put forth its requirements. The major downside of the system was that it had virtually no documentation and no one from the original team that developed the system was still working with the company. This made it all the more difficult to understand and document the system. Also, the system had a high response time thus leading to lower productivity of the data entry staff and other users. Further, it had a limited reporting capability and was basically used for storing financial data. When this project was undertaken for rework, the MPC was in the process of implementing an ERP package for its manufacturing and, therefore, it was necessary to bring all its applications to the same database structure. The most obvious question was whether to discard the legacy system and implement ERP's accounting module. The management, however, decided to retain and rework on the legacy system with the intention of integrating the new system with ERP. The driving point in favour of this decision was the realization that the legacy system was regarded as very critical for the accounting function and also that the users had become conversant with the system despite it being not very user-friendly. Also, there was no risk of failure. Incidentally, the review of the legacy system and ERP implementation coincided thereby easing out concerns of managing organizational changes as the company already had its strategy and preparedness in place for the scenario emerging out of ERP implementation. The computer-aided systems engineering (CASE) tool was chosen for designing the new system because of its inherent advantages in handling software projects which are as follows: The well-documented new system simplifies the maintenance jobs and, therefore, fewer people are required for its maintenance (this was the major problem with the previous system). It has removed the dependence of the management on a small set of people who specialized in the maintenance of an undocumented system. Financial reporting has become easier and better. The experience on this project made it amply clear that the top management support can make or mar a project. This is one of the most popular hypotheses in the information systems literature which has been found to be true in the case of the MPC.