The dark side of ERP implementations: narratives of domination, confusion and disruptive ambiguity

Introduction

Enterprise resource planning systems (ERP) are intended to integrate the information technology (IT) resources of a company. Prior to the ERP phenomena, the IT ideal was to provide people with software they wanted and needed. This was achieved through processes designed to ensure that all end-user requirements were captured and incorporated into the software (Davis, 1990). However, the down side of this approach was that a lot of projects failed or were over budget. This was caused mainly by ‘scope creep’ – end users ask for increasingly more complex functions and IT departments are unable to provide them (Tesch et al., 2007). As a result of this failure to provide bespoke software, many software providers market software off-the-shelf in order to overcome these problems. This off-the-shelf approach has been incorporated in ERP systems and we contend that this has caused major problems for end users in many organisations (especially those with limited IT experience, such as small and medium-sized businesses). These problems include concerns about the flexibility of the software and confusion about the effectiveness of the overall aim of the software, namely the integration of data across the organisation (Häkkinen and Hilmola, 2008).

What has been under-reported in research on ERPs is the negative side of these automated software packages. In a recent review of the ERP literature, Burgess et al. (2013) find that less than 1% of papers take a critical view of ERP systems. The problem here is that researchers are not looking for the problems these technologies cause, but rather accept them as an inevitability and focus instead on development opportunities and ‘critical success factors’ (Dawson and Owens, 2008). This paper explores the problems that ERP implementations cause in many organisations, particularly those with little experience of IT (Paulk et al., 1993) and IT people (Kumta and Shah, 2002). We suggest that this low IT maturity may be responsible for low achievement of critical success factors (Al-Mashari et al., 2003; Dawson and Owens, 2008; Ram et al., 2013). The capability maturity model (CMM) was originally developed to help firms contracted to the United States Department of Defense with the software development process. The ‘maturity’ term is a reflection on the level of formality and optimisation of processes used by organisations. This can range from improvised practices, to formally defined steps and well recorded metrics that lead to a better understanding and optimisation of processes. An adaptation of this concept was used by Paulk et al. (1993) and this forms the basis of the five-stage CMM model we use in this paper. In this paper, we coin the term ‘dark side of ERP implementations’ to provide a context to these problems within organisations. Therefore the aim of the paper is to explore these concerns through the perspective of end users in three case study organisations that we have assessed as having limited ICT maturity.

Theoretical background: ICT maturity and ERP systems

The five levels of IT maturity assume that in a ‘mature’ organisation, most system-level activities are focused on optimising IT implementation. The premise is that system activities bring about stability in business processes. Hence, maturity is reached when system-level activities are at Level 5 (clearly documented and measurable). The various levels are:

These observations will resonate with those in many organisations that have implemented ERPs that do not have the maturity in IT or the capability to use the ERP fully. Table 1 presents the human resource issues at the first two levels of the capability maturity model of an organisation. We chose these first two levels of the five-level capability maturity model because we believe none of the cases we investigate were above Level 2. We base this conclusion on the response to questions from respondents and the additional information provided in each of the cases.

These problems can also be thought of as expressions of how ready an organisation is for a big undertaking, such as an ERP system. We contend that many organisations are not mature enough to implement big ERP, which causes problems in the daily life of the organisation. To explore this further, we use a qualitative approach to look at problems often associated with ERP implementations and the unrecorded problems many individuals have with the technology. The research is based on case studies conducted in Australia, the United Kingdom and Denmark in which individuals from diverse working backgrounds were interviewed about their perceptions of ERP implementation. The transcripts were analysed and general themes extracted. These themes provide insights as to respondents’ concerns about ERP implementation, and the confusion and disruption they encountered during and after implementation. They also gave some indication of the maturity of the organisation with respect to IT usage.

ERP implementation failure

It has long been recognised that the implementation of an ERP is complicated and carries a high risk of failure (Yeh and Xu, 2013). Al-Mashari et al. (2003) discuss critical success factors for successful ERP implementations. Others have developed an optimisation approach for evaluating critical success strategies (e.g. Yeh and Xu, 2013). These factors are said to measure the relationship between organisational objectives and ERP objectives in order to determine the best ERP fit for a given organisation. The objectives used in approaches such as these are focused on the company and the ERP. We contend that they do not really cater for individual responses to an ERP implementation. For example, strategies for people and communications assume that an individual’s objectives align with the company’s objectives and that top-down, two-way and interdepartmental communication will be able to determine the requirements of each individual. Ttable 1 indicates this attitude in noting inconsistency in performing practices, ritualistic practices and an emotionally detached workforce for Level 1, and work overload, unclear performance objectives and low morale for Level 2.

This alignment may be artificial in that it relates to groups of people and not individuals, especially in organisations at Level 1 and Level 2 of the capability maturity model. We further contend that individuals within an organisation may not have the power to exert influence on the group’s assessment of the effectiveness of the alignment, and that after implementation an individual’s reaction to the new software may be different. The CMM may provide a benchmark-driven framework for the group’s key performance indicators and strategic alignment with the department and the company, but it does not consider the individual or the individual’s response to poorly-implemented systems.

Such benchmark-driven approaches as CMM have value for an organisational approach to performance management. However, although individuals within an organisation may agree initially with the implementation, they soon find it too inflexible or too hard for their requirements. Quite a number of researchers have identified inflexibility as a major problem with commercial off-the-shelf software packages (Davenport, 2000; Lindley et al., 2008). It is this lack of flexibility that can cause stress amongst employees and a feeling of disempowerment: ERP has been accepted by powerful stakeholders in the organisation and employees feel unable to express discontent with the system after implementation.

Recent research on ERP implementation failure

Research on post-implementation problems has focused on the organisation as a whole and on critical success factors that have previously been identified. Ram et al. (2013) suggest that there has been a failure in understanding how pre-implementation critical success factors influence post-implementation outcomes. Dillard et al. (2005) argue that ERPs are designed for ‘evil’ administrative purposes and are less concerned with how people actually do their work. We argue here that senior managers use these systems to drive their influence across the organisation.

Inflexibility may not be obvious to individuals prior to an ERP implementation. This can cause anxiety after the system has been implemented, which is the premise of our research. Leonardi (2011) looks at computer simulation technology in the automotive industry and concludes that employees’ perceptions of the constraints associated with a technology lead them to change the technology. Their perceptions of ‘affordance’ (the quality of the software and how it allows an individual to perform an action) lead to employees changing their routines. It is this perception of affordance that is lacking in ERP systems, especially in organisations with little experience of ICT. Employees are often unhappy with the affordance of software in many ERP implementations. Yet, such concerns are not explored in the mainstream ERP literature. Its questions focus on how ready an organisation is to implement an ERP instead of whether an organisation should implement an ERP. The literature uses critical success factors as its driving paradigm.

To explore this problem further, we ask the following research question: How do professionals in organisations with little IT capability react to their new work situation after an ERP implementation?

There are many ways employees cope with a lack of affordance with the software they have to use and it is beyond the scope of this paper to cover all possible scenarios. However, we have developed three possible scenarios in the form of propositions outlined below. They have been developed through a combination of thematic analysis of interview transcripts and analysis of relevant literature. They ask whether professionals react unfavourably to poorly-implemented ERP systems:

Note that these three propositions are by no means comprehensive. The purpose here is not to generalise, but to help explain why these systems are routinely rejected. Our qualitative insights may be useful for structuring debate on the interaction between people and ERP technology. Given the lack of empirical support from the literature, these are simply conjectures to be explored (Sandberg and Alvesson, 2011). It should also be noted that we are concerned with the whole organisation because ERP systems cover the entire spectrum of work.

There are many ways that professionals can handle problems with a mandated system, varying from outright rejection to the development of alternative systems. An example of the development of alternative systems is described by Houghton and Kerr (2006), who coin the term ‘feral information systems’. This concept is further discussed by Kerr et al. (2007) who describe a feral information system as

Feral systems or feral information systems are mentioned throughout some of the interview transcripts.

The data

Data relating to employee perceptions of ERP implementation were collected using semi-structured interviews. Interview details showing the respondents’ position in the organisation are shown in Appendix 1. Research data were collected from three sites, chosen for a variety of reasons. One of the authors had established a long-term relationship with each of the research locations. For example, in the first case study, the author spent three months at the site acting as an observer and active researcher and was privy to many of the discussions about the ERP implementation. With the second case study, the same author spent two and a half months observing staff reactions to the ERP implementation. In the third case study, the same author spent 11 days discussing research implications with other researchers and the respondents. From these long-term observations it was concluded there was much similarity in reactions to ERP implementations despite vastly differing contexts. Site 1 was a large government-owned transport organisation, site 2 an educational institution, and site 3 consisted of small and medium-sized enterprises.

The first site was a large transport corporation (TC) in Australia, a government-owned corporation. In Australia, this means a legal corporation that has been created by government (although in this case it was previously solely owned by government and then privatised). The purpose of a government-owned corporation is to deliver commercial services to the public on behalf of the government under a private industry, profit-based business model. There were a total of 14 interviews from this case site and each interviewee was based in the head office in Brisbane. The ERP system was SAP R/3 and the implementation was designed to improve reporting and other functions and involved 6000 users. Various modules were included in the implementation: financial, materials management, logistics, forecasting and planning, materials resources planning, human resources, information systems (including executive information systems), project management, and office integration. All respondents worked in the procurement section of the corporation and had good knowledge of the ERP system.

The second site was a university-based training organisation (TO) in the United Kingdom. A total of 13 interviews were obtained from this site and most interviewees were trainers (academic lecturers) who had a wealth of experience from their previous occupations. Each interviewee provided details of existing systems at the TO and also provided additional (mostly comparative) information from their past experiences. Two interviewees were professors: one had been the chief information officer of a large aerospace organisation in the UK, while the other had a great deal of experience as an academic in Australia. The remaining interviews were with academics at the lecturer or senior lecturer level (assistant professor). The ERP studied at this site was an integrated time-reporting software package called Timeo (a pseudonym). This system was implemented across the entire organisation and was developed in-house. Staff were not familiar with the software at the time of interview and many had problems fitting the system into their own work.

The third site consisted of several small and medium-sized enterprises located near Herning in Denmark. The interviewees in these companies were the key IT decision makers. The companies included a clothing wholesaler, a furniture manufacturer, an aluminium automotive parts manufacturer, a supermarket chain, an electronics manufacturer and an alternative energy supplier (windmill technology). The ERPs implemented at these sites varied from in-house developments to off-the-shelf ERP systems. The furniture manufacturer attempted to fit an off-the-shelf software package to its custom design processes and this led to problems. All the other companies used standard ERP packages, such as SAP. The units of analysis are shown in Table 2 (more detailed description of the respondents in all three cases studies is shown in Appendix 1).

Methodology

The research used an interpretative case study approach to provide insights into the social aspects of each respondent’s understanding of the use of information within the organisation (Walsham, 1993; Klein and Myers, 1999; Eisenhardt and Graebner, 2007). The case study approach was selected and qualitative methods were used as we were interested in exploring how the respondents perceived the usefulness of the implemented ERP and how they handled problems associated with its use (Stake, 1995; Yin, 2008). Of particular interest were how the problems perceived with the system led to the development of an IT artefact to work around the ERP system. As we were concerned with people’s perceptions from an organisational perspective rather than technical issues, the case method was considered highly appropriate. This builds on the work of Yin (2008), who argues that some research situations involve exploring data from an inductive vantage point. This means that the ability to generalise comes after a long period of exploring different sites and then comparing the results. All three case studies took an explorative approach since the relationships between the concepts were considered to be local and emergent rather than a priori (Deetz, 1996). Hence, the approach to understanding is primarily abductive, looking to existing theories to provide plausible explanations, but not aiming to build or test theory (Schwandt, 2007). The findings of the paper should be viewed as ‘rich insights’ or tentative concepts.

Results

Interview text analysis was based on themes related to the three propositions outlined above. For our first proposition – that professionals react unfavourably to poorly implemented systems when these do not match workflow expectations – we extracted the relevant themes for professionals who worked in any one of the 33 interviews/cases outlined in Table 1. Again, our purpose was not generalisation, but exploration of key issues, and these themes act as guide posts for further analysis. We wanted some indication of the level of perceived affordance that professionals thought could be found in the software. To this end we identified questions concerning the general usage of an existing ERP system and how well professionals thought the system fitted their own purposes as opposed to those of the whole enterprise. Professionals from TC looked at the ERP implementation from the perspective of expected improvements in efficiency in the workplace and the inflexibility of the system. For example, a senior manager expressed concern that the inbuilt ‘best management practice’ implied in the ERP software was inflexible and while it provided best management practice from the software developer’s perspective, it did not necessarily result in best practice for the company or meet his own professional requirements:

Here, the manager is pointing out that the management practices based on SAP do not match any of the management practices that have been crafted, built and reflected on over time. The problem here is that SAP replaces management processes, thereby forcing people to work around it. That is, SAP does not match the requirements when implemented from the ‘vanilla’ standard. Workflow expectations, no matter how difficult, do not appear to conform to SAP.

Referring to inter-organisational ERP implementations and the different requirements of employees in each organisation, a senior lecturer in TO stated:

Note the disparity between goals and expectations of the management role and how the implementation of the SAP systems causes cognitive dissonance. Other respondents suggested that the ERP does not cover the very important socio-technical aspects of a professional’s work life. One mentioned the concept of feral information systems as a way that professionals overcome the inflexibility of ERP systems.

This illustrates the ad hoc nature of processes in the work environment, how an ERP drives problems and eventually forces more unstructured processes. Put another way, in this context, the ERP drives duplication of processes and misalignment between workflow and strategy.

One respondent from Denmark (SE) provided an overview of the problems she felt existed because of the commercial requirements of the business and the inflexibility of the ERP.

We noted how the mismatch of workflow expectations and system expectations creates divergent paths for workers. Those that adhere are often at odds, as in our example, with those that work around the system. Our conjecture is that they work around the system because this is more effective than adhering to it. We also found that managers can be suspicious of ERP systems, confirming our proposition that professionals react unfavourably to poorly implemented systems because they suspect a hidden agenda.

There was a suspicion that the ERP implemented in TC was the result of a battle between accountants and engineers and that the accountants won the battle because of a push by government towards activity-based costing. The ERP was able to handle this accounting change more effectively. But the engineers wanted a different ERP from a different software company as this was much more attuned to engineering problems, such as on-time service and safety issues. Many engineers expressed concerns about the usefulness of the ERP for their specific needs. For example, one engineer suggested that the technology should help him perform existing tasks rather than make his job harder.

The underlying mantra of many ERP sales companies is that ERP technology makes things easier by increasing productivity. The system is supposed to make the employee more efficient. Yet, our findings show a consistent pattern of people unsure why ERP has been implemented. In many cases, people have difficulty using such systems and many find them so inflexible that they are actually an obstacle to their work. The complaint is often that just because it is best practice for the company who developed the software, does not mean that it is best practice for us.

Staff from TO had a variety of opinions on the usefulness of one ERP. One senior lecturer suggested that process engineering has to come first and that in many cases businesses do not need new tools, that existing tools are adequate.

The same staff member suggested that the problem may simply be that people don’t like change. He also suggested that it is very important for change to be undertaken in a considered way. The change brought about by ERP systems involves a complete reorganisation of the work process. Associated stresses with ERP implementations are under-explored in the current literatures and are often thought of as ‘change management’ issues. The following exemplifies this kind of problem:

While this is only one staff member’s opinion, it does point towards underlying social problems with such innovations as ERP. Such systems often take little account of the stress caused by major organisational change. This leads to the proposition that professionals react unfavourably to poorly implemented systems because they suspect the systems are poorly aligned and lead to process duplication. Interviewees certainly thought there was poor alignment between the ERP and company data, often resulting in duplication. In TC, this extended to a belief that the ERP system could not be trusted. When asked about ‘rubbery’ figures produced by SAP, one interviewee noted:

Another interviewee noted that he had been led to believe that SAP is right and the business warehouse wrong:

Similar problems seemed to occur in the training organisation with a senior lecturer mentioning a concern about database accuracy without being prompted.

A key characteristic is the questioning of the accuracy and reliability of data from systems designed to run the entire enterprise. An all-encompassing ERP system was not possible because of the differing needs and priorities of various stakeholders. However, in many cases, these differences are ignored in order to implement enterprise-wide integration. Similar concerns about missing data and missing functionalities were expressed in a wholesale retailer of women’s clothes in Denmark.

An explanation for the absence of fit in systems came from a professor at TO, who was chief information officer at a large aerospace company in the United Kingdom.

Having to accept the predefined engineered configurations of the ERP leads to the concerns outlined by many interviewees. These predefined solutions create tension between users and management because the expectation of the software does not align with the expectation of business processes. They could, given appropriate levels of maturity, but overall they create waste, duplication and even triplication that slow down work processes.

In the Danish environment, a furniture cabinet manufacturer had struggled for years to achieve a good fit between stated manufacturing aims for the product and the ERP system. It seemed that the problem sprang from inflexible systems being applied to a flexible manufacturing approach resulting in poor alignment and a great deal of extra work.

These organisations are all at different levels of maturity in their development plan. While interviewees speak about process duplication, overload and mismatched workflows leading to disruptions and ambiguity, it is important to realise that these problems might not have arisen had the original purchasers of the system known about the level of change management required.

Future directions

Little is known about the IT capability of organisations in which ERP has been implemented. Holland and Light (2001) discuss ranking the maturity of an organisation, but only within their own dataset of 24 companies. They propose a three-stage maturity model in which the first stage is:

It can be seen from this example that the maturity models developed relate to the actual implementation itself, whereas we are suggesting that an evaluation of maturity prior to an ERP implementation may provide some predictive power as to the ‘dark’ problems of ERP implementations.

We suggest that there needs to be a more universal assessment of an organisation’s IT capability maturity. This could provide additional insight into why ERP implementation is so difficult in some companies and so successful in others. We suspect this maturity factor is relevant to the many negative comments about ERP implementation encountered here. A maturity assessment, conducted from a social perspective well before ERP is implemented, might provide a useful guide to potential problems.

We encountered many instances of professionals not liking the system or finding it did not satisfy requirements. Other examples of lack of fit come from the medical imaging industry, with one example of an Australian in-house ERP system being completely abandoned at a cost of $A25 million (van Akkeren and Rowlands, 2009). In this case, there was also a hidden agenda with the in-house project being designed to be sold elsewhere following testing by the organisation’s own staff.

Another aspect of the professional’s concern about ERP implementation relates to professional standards. The example here is of accountants in TC, needing a new accounting scheme based on activity-based accounting, coming up with an alternative to the ERP implementation plan and winning the day. This effectively meant that the engineers in TC were sidelined and their ERP system went unused.

It seems that in both these cases there was a hidden agenda. In the medical imaging instance, the company developing the in-house ERP was developing the system for sale elsewhere by testing it on its own employees. In the second example, the implementation of SAP, ERP was related to a higher political imperative for a new approach to accounting, rather than any concern about more efficient controls and safety. In other cases, there appeared to be a deal of confusion with many managers not knowing why the ERP was implemented or what the benefits might be.

Lack of coordination between users and systems led to conflict, deviance and other workplace problems. The sort of suspicion shown by workers at TC about ERP implementation was a central theme in many of the interviews. Kerr and Houghton (2010) give the example of a feral information system developed to duplicate the existing ERP system for inventory controls simply because an engineer did not trust the centralised system and wanted easy access to key inventory in case of emergency. The ERP system was poorly aligned with professional requirements.

Leonardi (2011) discusses the quality of software and how it allows an individual to perform an action. Leonardi’s study was looking at simulation technology in the automotive industry, while our paper looks at a series of industries from various countries. Despite this difference, we concur with Leonardi that many employees see technological constraints in IT resources. This paper extends Leonardi’s study by looking at ERP products across a variety of industries. We find a level of mistrust caused perceptions of misalignment, little understanding why ERP was implemented, and lack of fit with professional practice. This is not to say that ERPs cannot be beneficial within an organisation and that operational staff cannot be trained to use such systems. However, consideration needs to be given to the concerns of the organisation’s professional staff.

Conclusion

We discovered many disturbing patterns that reveal the dark side of ERP implementations. We discovered people working around the system and circumventing what they did not trust. Our findings indicate that ERP systems brought confusion and mistrust. Most alarming is the sheer lack of research on the problems ERP implementations cause. Our findings here cannot be unique. While we argue that problems are related to maturity, we do not compare high maturity organisations with low maturity organisations. High maturity organisations may be very different and further research is required to test this supposition.

No potential conflict of interest was reported by the authors.