This paper discusses the concept of Information Systems (IS) failure as a whole. Also discussed are the various types of IS failures and the factors that differentiate an IS success or failure. The paper also deals with the Critical Success Factors (CSF) and Critical Failure Factors (CFF) associated with IS failures and an attempt is also made to correlate CSF and CFF. A detailed study of three cases related to IS failures are also undertaken and an attempt is made to synthesis and analyse the failure reasons based on the three cases. The lessons learnt from the cases are also looked into in detail.
The paper concludes with a brief advise to managers/IT managers on the how to reduce the probability of an information systems failure. 1. 0 Introduction – An information system is a combination of computer hardware, communication technology and software designed to handle information related to one or more business processes. Organisations today need to handle a vast amount of information and rely on information systems for day to day activities. The dependence on Information Systems is so vital that it can make or break an organisation.
An effective information system serves to actively coordinate the work of many different organisational functions, from the basic administration support, to a company’s strategic management tool. It encapsulates and integrates a number of areas of business with an aim to increase efficiency and effectiveness of business practices. Hence importance must be given to designing, developing and maintaining the correct type of information system for a particular organisation which very much aligns with its business strategy.
Over the years Information Systems have evolved to an extent that it influences and manages an organisation’s business processes all across its departments or sub-units. Hence for such an investment to take place, there need to be a redevelopment and overall a partial or most likely a complete redefinition in the business practice. Any change in information system implementation thereby needs to bring about change all across the business structure to harness the benefits of such an investment.
Information systems are now far more sophisticated and that any failure in its development or implementation can further complicate the infrastructure and business as a whole as there are so many ways that they may occur. Each year companies lose millions of dollars on information system projects that fail and more are lost due to malfunctions of systems that have progressed beyond the implementation stage. Since information systems are complex and have many aspects attributed to each, failure (and success) can be manifested in many ways.
A detailed view in this regard is given in subsequent topics in this paper. 2. 0 Concept of Information Systems Failure – Information Systems (IS) today are far more complex and revolves around so many factors that the nature of information systems failure is multi-faceted. Over the last couple of decades a number of studies have been done in the field of IS failure, of which two approaches have come into prominence. One is Lyytinen and Hirschheim’s (1987) concept of Expectation Failure and the other is Sauer’s (1993) concept of Termination Failure.
According to Lyytinen and Hirschheim (1987), there are four main theoretical categories of IS failure: 1. Correspondence failure – Happens when there is a difference in the performance of the IS against the objective. 2. Process failure – Happens when development process cannot produce a system that works or produces a system that is over the planned budget in terms of factors like time, cost etc. 3. Interaction failure – Happens when IS is hardly ever used or the users have issue using the system.
Expectation failure – Lyytinen and Hirschheim (1987) defines this type of IS failure as containing all the above three types of IS failure. They also add that expectation failure is a very broad and detailed approach to IS failure and defines failure as the inability to satisfy the stake holder’s interest. To broaden this analysis Lyytinen(1988) distinguished between development failure and use failure. Where the former is concerned about failure to mould the IS to the stakeholders interest and the latter talks about the failure to align the IS development to address stake holder’s concerns.
But this model is heavily debated by Sauer (1993), who argues that an IS should be labelled failure only if all interest in progressing the IS project have ceased. He also states that all IS have flaws but the important aspect is the availability of support to correct the flaws. Otherwise the flaws can add up to generate a much bigger problem so as to abandon the project. The flaw concept clearly helps Sauer (1993) to distinguish termination failure from expectation failure. The above concepts are a theoretical way of differentiating IS failure and success.
Some of the empirical investigations methods of IS failure are explained briefly below. 1. Anecdotal evidence – Harel (1980) calls this as folk theorem and relies heavily on the validity of the anecdotal evidences. 2. Case studies – In Benbasat et al. (1987) views that this type of approach is more valid in problems where research and theory are still at an early stage. Since IS failures are multi faceted the case study approach is gaining importance as it gives a much clearer view of all details. 3. Survey research – Two notable studies under this concept was that of Lucas (1975) and Lyytinen (1988).
Though Lucas (1975) based his study on a number of general hypotheses on IS failure, the data was not sufficient to explain all aspects of IS failures. While Lyytinen (1988) looked at IS failure from the perception of a systems analyst. A clear distinction between IS project abandonment and IS failure was done by Ewusi-Mensah and Przasnyski (1994). They argued that IS failure is purely based on the failure to use the IS, while IS project abandonment is more to do with IS development process. This is very much in line with the development and use failure concept of Lyytinen (1988).
Semiconductor Manufacturing Thailand Ltd. (SMTL) was set up as a manufacturing subsidiary of Semiconductor Manufacturing (SMHK). Semiconductor Manufacturing (SM) is a world leader in manufacturing of a wide range of electronic equipments and their expertise include design, development and delivery of products. The plant in Thailand was designed in such a way that it will house all the manufacturing process under one roof. By 1997 the SMTL had grown to 1500 employees under the guidance of Jack Fung, Managing Director (MD) of SMTL.
The top management in Semiconductor Manufacturing knew the huge potential for growth and invested heavily. The Management Information Systems (MIS) department at SMTL was in charge of the whole IT infrastructure. But Jack Fung, took all major decisions of the IS planning and implementation. Jack wanted an IS very much similar to the one in use in SMHK and hence acquired IBM minicomputer AS/400 (B series) and selected modules of BMS (a UK-based business applications software package). A local VAR (value-added reseller), TGSystems was selected by him for the delivery of the software as well as in the training and implementation.
But at the time of delivery what SMTL acquired from IBM was the D series IBM AS/400 as it had more capacity. Furthermore at the time of purchase of the BMS module, since a 50% discount was being offered Jack purchased every module of BMS, which was more than what was earlier planned to be implemented. The purchased modules included Financial, Distribution, Manufacturing and Information Human Resource Management (IHRM). The implementation started with the Payroll and as agreed in the contract TGSystems, helped in the process of implementation and training.
But few months into the implementation process SMTL found that the payroll system was complex and not flexible to their desired reports. Hence, Carol who was the senior most member of the MIS came up with the idea of implementing FoxPro for payroll management, which in the end was found to be more successful in terms of usability and functionality. Also during the Financial and Distribution modules training sessions which were conducted by the TGSystems and EDP personnel from Hong Kong EDP, there was a significant amount of turnover of BMS experts from TGSystems.
This led to many complaints from employees of SMTL and in turn accounted for turnover of employees toward the training sessions. The eventual result was the delaying of BMS module implementation by over a year. Since the functionality of each module depended on other modules, there was delay in implementation of dependent modules too. Along the same time MIS on their part started to set up Local Area Network (LAN) in SMTL from fund received from management. This coupled with almost 50 % turnover of employees forced them to hire young programmers to develop and enhance critical IS in SMTL.
But overall they were able to implement Inventory Management (IN) and by early 1996 General Ledger (GL), Cash Management (CM), and Accounts Payable (AP) were integrated. Also by the end of the same year the Purchasing Management (PM) module was implemented and was successfully integrated to Accounts Payable (AP) module. The communication facility like Lotus Notes was implemented in early 1996 with help from Hong Kong EDP. Next the MIS staff of SMTL started the deployment of manufacturing modules of BMS, but it soon became clear that the module would not fit with the existing manufacturing business processes in SMTL.
The options were, to purchase the source code and customise it, or to copy the same from SMHK. The former would cost huge amount of money and also MIS did not have the expertise to customise the code. The latter plan was also rejected as SMHK informed them that the existing manufacturing module was not performing as intended and that a lot of human resource was being used. Hence an in-house MRP software was developed as a temporary solution. Eventually the originally expected plans never materialised.
Failure Reasons – Looking back at the whole implementation process in SMTL it becomes evident that there was lots of factors that led to the failure of the implementation process. Some of the failure reasons as explained by Sarkar, Suprateek & Sarkar, Saonee (2000) are listed below. 1. Lack of leader ship and culture issues 2. Poor communication and coordination 3. Poor Human Resource management in dealing with employee issues 4. Inefficient IT Infrastructure to support the Information Systems Overall the IS implementation failure in SMTL was mainly due to the management taking all decisions and not consulting with the IT team.
Also the communication between the management and IT implementation team was also a cause. This along with the improper planning of the implementation added on to the cause of IS failure. Adding on to this was the cultural differences within the company. 3. 0. 2 Case Study 2: ElectroCo – ElectroCo, an electronic component producing company was formed in the year 1991 in Singapore as a sister concern of its Japanese corporation. In 1998 the procurement department of the company started the implementation of electronic procurement system, called E-PRO.
The objective of the implementation was to make the procurement process paperless and more effective, but in the end the whole process turned out to work against the company as their relationship with their relatively small supplier turned worse. Even before the start of the implementation there was strong opposition from both IS manager and the users of the system. The former was because of the scale and complexity involved in the implementation and the latter was because the users were concerned about losing their job due to the automation. Most of all the suppliers in this case were not informed about the project.
But the project went ahead because of the sole interest of the procurement manager as he had a strong backing from the managing director. The project started in January 1999 with an initial budget of S$200000 and the duration for completion was for 1 year. As mentioned before due to the reservation of the users, the project had difficulties obtaining the procurement procedures from them and most of the information they got where of conflicting in nature. But the issue was solved by transferring a few employees and giving warning to the rest, which was clearly an unethical way.