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:
- (1)
the chaotic level, where the system is implemented and the organisation is in a state of dynamic change;
- (2)
processes are coming to be consistent, though are not clearly defined, possibly lack rigour, and are repeated over and over again;
- (3)
some organisation is present, so some processes are established with clear documentation while others (minor processes) are not;
- (4)
documented processes can be observed and measured by applying metrics to robust, clearly-defined processes;
- (5)
the penultimate level of maturity where processes are clearly documented, measurable and can only be tweaked for optimisation. Very few corporations, the authors argue, ever reach this level.
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.
Interviewees | |
---|---|
Case Study 1 | Manager commodities and contracts |
Manager procurement | |
Commodity facilitator | |
Administrator for accounts payable | |
Change management officer | |
Administrator for accounts payable | |
Contractor for the inventory project | |
Process design advisor | |
Manager overseeing commercial commodities and corporate contracts | |
Acting senior executive manager | |
Manager performance and reporting | |
Business improvement officer | |
Commodities facilitator | |
Senior executive manager | |
Case Study 2 | Lecturer – supply chain |
Lecturer – leadership | |
Lecturer – military history | |
Professor – military tactics | |
Professor – head of school | |
Lecturer – supply chain and logistics | |
Lecturer – military contracts and large acquisitions | |
Senior lecturer – large acquisitions and military contracts | |
Lecturer – tactics | |
Professor – information systems | |
Senior lecturer – acquisitions | |
Senior lecturer – leadership | |
Lecturer – information technology | |
Case Study 3 | Head of management – technical department (aluminium company) |
Supply chain manager (furniture company) | |
Business consultant (furniture manufacturer) | |
Head of quality improvement (electronics company) | |
e-Business process manager (supermarket chain) | |
Technical officer (wind turbine company) |
Source: Adapted from Kumta and Shah (2002).
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:
- •
because ERP does not match their workflow expectations (Proposition 1);
- •
because they suspect a hidden agenda (Proposition 2);
- •
because ERP systems are poorly aligned and lead to process duplication (Proposition 3).
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
a [computerised] information system that is developed by individuals or groups of employees to help them with their work, but is not condoned by management [and is not] part of the corporation’s accepted information technology infrastructure. Its development is designed to circumvent existing organisational information systems. (p.142)
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:
So, SAP [the ERP] often talk about these best management practices and say that to make a thing work effectively, you use the best management practices as defined by SAP. So the cheapest implementation solution is to follow practices that are put forward by SAP and don’t change any of your own – go ‘vanilla’. (Senior manager, TC)
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:
I think for that to happen it would have to be at many levels of the corporation – now it seems that the co-operation is about how we achieve the pre-agreed outputs and each organisation has its own goals and aims – one organisation then goes to the other and works out how they will achieve their goals and aims, but that is my goals and aims these are not shared goals and aims. (Senior lecturer, TO)
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.
I just think these two are so intertwined that we need to get a much better comprehension of the socio technical. Then we might understand feral systems and a whole range of other things. (Senior lecturer, TO)
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.
Interviewee 2:There is actually the standout warehousing module in [the organisation], but it’s not as useable as we would like it to be.
Interviewee 2:Yeah, the functionality asked by the users and, by the way, how we do things in the warehouse when we are packing for overseas – packing big containers – and then we have to be able to track what did we put into that container kind of thing and how much did we put into it, its weight and all that kind of thing.
Facilitator:So you have still issues on the packing order of trucks and containers …. (ICT manager, SE)
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.
Technology shouldn’t do anything for you, it should just make something existing easier and that should really be the last of our worry …. You shouldn’t look to technology to solve problems. We should have a clear process to work something out, and hey, if technology can come along and make that easier, then that’s great. But it’s quite fashionable at the moment to say that we will do that through BBP, EBP or ERP or whatever we want to call it at the moment, that’s an internet purchasing thing, but that actual process I feel sometimes doesn’t get mulled through fully enough before we say, hey we’re going to do that electronically. So then we launch into the EBP system, which is incredibly expensive and time consuming, and then you still have your underlying process issues. So all that technology solves if you haven’t got a good process, is it makes a crappy process sort of half efficient. It doesn’t fix anything and then people get frustrated with the technology because they were promised that it would make life easier, but it actually makes life harder. I just don’t think that that’s helpful. (Engineer, TC)
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 process engineering has to come first and the tools are something that just supports it – by the time you get to the process engineering you may have discovered the fact that you don’t need the support for it or the tools you have already got are perfectly adequate but you are just not using them right. Most businesses use no more than 10% of the functionality of the software they have got. So it could well be that when you do the process engineering and you go to the supplier of your software package that it has all been there anyway. You were just not using it even though it existed. (Senior lecturer, TO)
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:
I have experience here and at other universities where computer systems were introduced. I think that people don’t really like change, 25% will always be negative, if you are lucky 50% will be ‘let’s give a try maybe’ and 25% (if you are lucky) will say yes change is good so change can be necessary but it depends on how it is done. (Senior lecturer, TO)
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:
That’s what I’ve been led to believe from speaking to various people who are right into SAP, which is an avenue I don’t pursue. But the figures seem to be different in a business warehouse to an SAP type figure. Queries get run and you get results, the level of confidence just isn’t there. (Senior procurement manager, TC)
Another interviewee noted that he had been led to believe that SAP is right and the business warehouse wrong:
Well that could be right, I guess. A scenario is if a certain vendor is providing us plant hire services and selling us baked beans. If you had a disciplined approach to putting things in the GL (general ledger), you would put the plant hire in the plant hire part of the GL and the baked beans in another. The approach that seems to happen is that people basically pick a number and put it to that so you can no longer question [the data] based on coding for particular products …. I know how to fix this but [if] the vendor has sold us three or four different products, how can I differentiate between the two. Because you are looking at a specific commodity and they go across commodity groups, it’s very hard to work out that products 1, 6 and 8 are what we are looking at from vendor C and all the other products we will disregard. I have always found it very difficult to get to that. We seem to resort to printing out a whole pile of data and getting somebody to sit down and go through the long text, which is great if there is someone [to do this] …. So that is where I was saying the data [were] an issue. (Procurement officer, TC)
Similar problems seemed to occur in the training organisation with a senior lecturer mentioning a concern about database accuracy without being prompted.
In some cases you ended up with neither database being accurate because nobody knew which one they were meant to prioritise. Indeed, in some cases there are still National Authorities that insist on retaining their own system because they feel it more fully and accurately represents their needs …. (Senior lecturer, TO)
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.
Yes, I am missing functionalities and data when I need the right data at the right time. [There is a] lack of comparable data. [There is a] lot of missing functionalities around business intelligence. (Supply chain manager, SE)
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.
Those are the very big projects in big companies it is easier to re-engineer the company to work on SAP not the other way around. Just understand who is the tail and who is the dog and work accordingly. (Professor, TO)
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.
Interviewee:They have been trying to implement different ERP systems for a longer period. So, it’s an older one that they have right now, the PMS system. But they have tried different ones over the last 12 years. I think they tried three times or something.
Interviewee:The production of the cabinets for one of the brands called HTH is very configurable. So, if you had a cabinet, you can take something off the height, you can take something off the side, and you can change the interior and all that is configured in – well – in a configurator.
Doing that and the ambition that the company has had so far that all data must be completely in line when you start the production, makes [it] a huge job to make all these combinations up to date and valid, because they are all also pushed all the way out to the shop system. So it’s validated already when the customer comes in saying I want a cabinet like that. You can ask him how we’re supposed to build it.
I think that has been one of the great difficulties for the company while implementing the ERP system, because the other brands don’t have it. (Manager, SE)
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:
… characterised by the management of existing legacy systems and planning activities concerned with the implementation of the new ERP system. The second stage involves the post-implementation exploitation of the ERP system and its widespread adoption throughout the organisation measured by the impact of the system upon business processes, and organisational coverage. The third stage involves the strategic exploitation of the core ERP system using innovative business process and IT initiatives that extend the ERP transaction data into high value processes that are often supported by satellite systems to support new functionality and capabilities in areas such as supply chain management. (Holland and Light, 2001, p.43)
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.