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

This paper explores end-user perceptions of poorly implemented enterprise
resource planning systems (ERP) from the perspective of a primary frontline
user. This exploration analyses three case studies – from Australia, the United
Kingdom and Denmark. Through these cases, we find three areas of concern: the
reaction of implemented systems to existing work processes; the suspicion among
workers that management has a hidden agenda in implementing an ERP system;
and the perception that the implemented system is poorly aligned and leads to
process duplication. The objective of this research is to see how ERP implementations
have consequences that go beyond current research which, in the main,
frames ERPs in a positive light and does not critically evaluate them. Our
research demonstrates that, while major work groups in an organisation may
appear to accommodate the ERP implementation, many individuals are very
concerned about how the ERP disrupts their work. Our research demonstrates
that there may be ‘dark’ consequences arising from an ERP implementation.
These are likely to include unauthorised software development to fit previous
work processes, confusion and little understanding of the new business
processes. The result is an overall lack of trust in the efficacy of the system.
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).
*Corresponding author. Email:
© 2015 Taylor & Francis
Prometheus, 2014
Vol. 32, No. 3, 281–295,
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 systemlevel
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.
282 D. Kerr and L. Houghton
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,
Table 1. Human characteristics of the first two levels of the capabilities maturity model
Capability maturity model level
1 – Chaotic Organisations at the initial level typically exhibit four characteristics:
Inconsistency in performing practices
Displacement of responsibility
Ritualistic practices
Emotionally detached workforce
2 – Repeatable At this level, frequent problems hinder people who are unable to perform
effectively. Some of these are:
Work overload caused by re-work
Unclear performance objectives and feedback
Lack of relevant knowledge and skill. It is difficult to have all the
skills within a project group. In the absence of an organisation-level
policy, access to available skills in other projects is difficult. Project
managers tend to retain team members for fear of not getting the
resources when required
Poor communication channels. There is no organisation-level
structure to facilitate inter-group communication. This happens only
at the initiative of the project manager
Low morale as a result of no organisational focus
Source: Adapted from Kumta and Shah (2002).
Prometheus 283
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?
284 D. Kerr and L. Houghton
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.
Prometheus 285
The first site was a large transport corporation (TC) in Australia, a governmentowned
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).
Table 2. Units of analysis
description Abbreviation Location
Number of
Estimated capability
maturity level (from 1 to 5)
Large transport
TC Australia 14 1
TO United
13 1
Small and mediumsized
SME Denmark 6 2
286 D. Kerr and L. Houghton
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.
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
Prometheus 287
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.
Facilitator: Right.
Interviewee 2: Looking into our processes that we are having today when we are
shipping overseas.
Facilitator: So why isn’t it as useable? What’s the problems?
Interviewee 2: Well it’s …
Interviewee 1: Functionality.
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.

Click here to request for this assignment help

Hi there, would you like us to help you do this question?

We are professional assignment help service for students who can't even. Get your papers written starting at just $11.99 a page.

Do my question How much will it cost?