ArticlePDF Available

Ensuring e-business success by learning from ERP failures


Abstract and Figures

Although enterprise resource planning may be the toughest project you've ever attempted, doing it right will be the key to implementing a successful e-business. Based on his own experiences with ERP projects in the 1990s, the author found that for your project to succeed, you must prevent problems in the following high-priority areas: e-business strategy; project management approaches; complex technology and systems; and end-user resistance. A small investment in understanding, analyzing, tracking, and preventing these major problems should pay off well, given that most such problems are common, expected, avoidable, and detectable early. One viable approach to reducing the likelihood of failure is to identify the crucial risks at each point of the project life cycle, then build plans to address them before they become real problems. The author found this technique useful in evaluating ERP projects and fully expect it to be useful for evaluating e-business system projects as well
Content may be subject to copyright.
22 IT Pro January February 2000
1520-9202/00/$10.00 © 2000 IEEE
Success by
Learning from
ERP Failures
Herb Krasner
n the 1990s, a plethora of companies at-
tempted to use enterprise resource planning
systems to support and improve their internal
business processes or to address Y2K com-
pliance issues.During my recent involvement in
troubleshooting several failed ERP projects,I dis-
covered a set of common problems that besets
these projects.As the shift toward e-business accel-
erates in this decade, more companies will face
similar problems. Un-
derstanding the impli-
cations of these prob-
lems and learning how
to mitigate the risks
they pose will be vital to
the success of ERP pro-
jects on and off the
ERP products—such
as those by SAP,Baan,
acle,and PeopleSoft—
conceptually contain a
set of functional com-
ponents, integrated around an enterprise data
warehouse. These components provide auto-
mated support in traditional business process
areas such as inventory control,material require-
ments planning,and order processing.
With each product suite emerging from a dif-
ferent historical perspective, today’s ERP prod-
ucts offer a wide variety of capabilities. People-
Soft,for example,began by specializing in back-
office systems,then expanded into the front office.
Oracle specialized in relational database man-
agement systems, branched into data warehous-
ing,and then moved into ERP. SAP started by
specializing in manufacturing automation before
expanding into other areas.Thus, each product
derives its strengths and weaknesses from its his-
tory and its company’s current business strategies.
Some vendors design their products to be flex-
ible in capturing and using customer business
processes;others dictate the processes to be used.
For example,Oracle’s ERP product is among the
most flexible; SAP’s is among the least flexible.
Over the past few years, ERP products special-
ized for particular industry segments—such as the
apparel industry’s JBA System 21 Style—have
also emerged.
Highly complex, ERP systems contain many
hardware,software,and peopleware components
that can be interconnected in a variety of patterns.
Pop the hood on one of these systems and you’ll
find dozens of parts and millions of lines of code.
These systems are further complicated by the het-
erogeneity of the connected components, the
newness of the underlying technology, and the
need for integration into the client’s total IT envi-
ronment. Some ERP components are self-con-
tained software packages—either custom-built or
standard products. For example, SAP/R3, Baan,
and others now offer various client-server prod-
ucts that reside within an overall ERP system
Although enterprise
resource planning
may be the toughest
project you’ve ever
attempted, doing it
right will be the key
to implementing
a successful
Strategic Options for
Enterprise Reengineering
January February 2000 IT Pro 23
Since the early 1990s,many companies worldwide have
attempted to implement ERP systems—and failed.Maga-
zines like Fortune,Datamation,and Information Week have
published articles on these failures.This publicity has cre-
ated the perception that large ERP implementation proj-
ects are dangerously failure-prone.To support my consulting
work,I have gathered a large compendium of such failures.
Consider the following excerpt from the Harvard Business
Review (Thomas H.Davenport,“Putting the Enterprise into
the Enterprise System,July/Aug.1998,p.2).
ERP systems are expensive and difficult to implement.The
growing number of horror stories about failed or out of
control projects should certainly give managers pause. ...
Some of the blame for such debacles lies with the enor-
mous technical challenges of rolling out enterprise sys-
tems—these systems are profoundly complex ..., and
installing them requires large investments of money,time
and expertise ....The biggest problems are business prob-
lems.Companies fail to reconcile the technological imper-
atives of the enterprise system with the business needs of
the enterprise itself.
ERP systems resemble many other large, complex,
sophisticated IT systems. Extremely risky and failure-
prone to begin with, an ERP system by its very nature
courts greater risk than other system types,as the follow-
ing comment shows (Susan Conner,And the Keyboard’s
Connected to the Backbone,Chemistry and Industry,18
May 1998,pp.1-2):“The most obvious problem with ERP
implementations is that these projects are so large and so
complex that you can’t tell the implementation of the soft-
ware apart from re-engineering the business.
These complexities can cause problems with manage-
ment,users,and technical issues.
Management problems
Most ERP disasters reported in the trade press and open
literature stem from management failures—although few
companies will admit to it.Many more such disasters have
gone unreported, an assessment supported by studies of
IT project failures in general (CHAOS, The Standish
Previous articles have focused on the management dif-
culties involved in running a complex ERP project.For
example, Marie Benesh (“Managing Your ERP Project,
Software Testing and Quality Engineering,July/Aug.1999,
pp. 38-43) describes five areas of common management
pitfalls that involve shortcomings in or a lack of
integrated project team planning,
managed communications across many people,
a formal decision-making process,
an integrated test plan and managed test process,and
applying lessons learned from earlier implementations
to later implementations.
Another report (Stanley Wee,“Juggling Toward ERP
Success, ERP News,Apr. 1999, pp.7-8) also focused on
management process issues as one lesson learned from
interviewing ERP customers.The key to success in over-
coming management problems,according to this report,is
to establish and maintain momentum by paying attention
to the following factors: focus, teamwork, defined scope,
business case analysis,planned training and support,smart
reengineering,overall architecture,rigorous project man-
agement, effective communication of expectations, and
top-management involvement.The report did not address
technology issues.
User problems
Financial services firm Deloitte & Touche conducted in-
depth interviews with 164 individuals at 62 Fortune-500
companies (The Review, Maximizing the Value of ERP-
Enabled Processes, Deloitte & Touche, 18 Jan. 1999).All
companies included in the report manufacture consumer
products,and all use ERP systems by vendors such as SAP,
Baan,Oracle,and PeopleSoft.The study focused on going
live:that point when the ERP system is made available for
general use within the company.
The study concluded that when issues and obstacles
occur before going live,they do so for the following reasons
and in the proportions reported (the report’s listed values
do not total 100 percent):
people obstacles,62 percent;
business process issues,16 percent;and
information technology (technical) issues,12 percent.
After going live, people issues still dominate, but the
emphasis of concern shifts to such areas as ongoing sup-
port, business performance, reporting, system transition,
and training.Within IT issues, only about 5 percent of
respondents considered software functionality an obsta-
cle both before and after going live.
Unfortunately, the point at which a project should go
live is not universally defined and may not always be a firm
milestone on the basis of rigorously preestablished crite-
ria.Despite the relative proportions cited for the problems
identified,the impact of those problems does not occur in
In one survey, 62 percent of
respondents cited people issues
as a prime problem in taking
ERP projects live.
the same proportions.Thus,how you deal with these obstacles
may be quite different.
Significantly,systems that suffered problems when going live
were the best of the lot—the ones that survived most of the
process, management, and technology risks that kill so many
other projects before they can go live.So it’s really no surprise
that the remaining issues that confronted these projects
involved people problems.
Technical problems
When you autopsy a failed ERP project,identifying the prob-
lems that occurred along the way can provide indicators of the
failure to come. Many ERP projects are plagued by complex
technical problems,which fall into the following general cate-
nonrobust and incomplete ERP packages,
complex and undefined ERP-to-legacy-system interfaces,
middleware technology bugs,
poor custom code,and
poor system performance.
The ERP package vendor promises that its product—
usually the next version—is robust and has all the func-
tions and features to support your business processes.
If you naively believe it, go to the end of the line.
Independent certification of such a package can be
worth its weight in gold,and firms are setting up shop
to do this (for an example, see Hugh Klipp,“Quality
Assurance Services for ERP,Proc.Ninth Int’l Conf.
Software Quality,American Society for Quality,Milwaukee,
To function,an ERP package must be placed in an IT envi-
ronment that already contains other systems.The interfaces
between these systems are complex and significantly affected
by the overall IT integration approach.You will need rigorous
legacy-systems analysis to precisely understand the ERP-inter-
facing requirements.You should also document each major
interface definition.
Middleware technology has emerged as the glue to interface
these various systems and applications over a distributed ERP
system.You can choose from several standard approaches—
based on CORBA (Common Object Request Broker Archi-
tecture),DCOM (Distributed Component Object Model),and
other distributed architectures—or roll your own.Be aware
that buggy client-server messaging or object-sharing tech-
nologies will bring the entire system to a halt.
Most ERP packages don’t cover all the specific business
requirements,and therefore you may need a certain amount of
customization to complete the fit.In some troubled projects,cus-
tom-code development started without sufficient thought and
planning.The subsequent undisciplined development produced
poor-quality code with unexpected,unlocalized side effects that
arose from poor structuring.Custom code also significantly raises
the total cost of ERP system ownership over the long haul
Strategic Options
for Enterprise
A first step in enterprise resource planning is to
reengineer,downsize,rightsize,or otherwise stream-
line business processes in pursuit of a competitive
edge or greater efficiency.This process,sometimes
called enterprise reengineering, promises big re-
wards but also carries big risks.
ER initiatives start with a planned strategy for
streamlining and integrating the company’s opera-
tions.The following choices describe the spectrum
of strategic options available for reorganizing a
company’s business processes.
Functional centralization. This option man-
dates that a single organizational unit performs
all common business functions, such as human
resources or accounting.
Functional standardization. Taking a cloning
approach, this option has one business process
t all business units and mirrors that
uniformity in the IT systems’ im-
plementation. Functional stan-
dardization implies that a com-
pany must standardize on hard-
ware platforms, choose a standard
suite of ERP packages, then con-
vert each and every business unit
to those standards.
Distributed functional specialization. This
option designates a selected business unit as a
center of excellence for a specific business func-
tion; the selected unit then performs that func-
tion for the whole corporation. Partial functional
specialization allows each business unit to con-
trol its own core MIS functions, such as sales
processing and inventory control, but also cen-
tralizes a limited set of business functions,such
as accounting,across the company.
Functional business unit autonomy. This de-
centralizing option exemplifies the noninte-
grated enterprise approach, allowing each unit
to go its own way.
Radical redesign of business processes. An
organization could choose this option in
response to a paradigm shift in which a new
approach replaces the normal business flow.
Hybrid strategies combine features of these basic
options. For example, you can loosely coordinate
standardization,allowing each business unit to pur-
sue an independent IT strategy,but insisting that it
still cooperate with business units on bulk hardware
and software purchases.
January February 2000 IT Pro 25
but that rarely happens.Even progressive companies have
done so well on the front end that they are now unable to
meet customer demands with sufficient product offerings
or services.
Lack of strategic thinking seems to get many companies
in trouble.For example,no matter how much a given com-
pany may want its e-business to run off a turnkey system,
the components that make up these systems will not come
from a single source any time soon.Even if such a system
existed, a company’s business processes are unlikely to
match the default embedded processes.Further, vendors
can implement the system’s component pieces with dif-
ferent underlying technologies and designs, forcing the
organization to overcome much greater integration chal-
lenges than if the underlying infrastructure was consistent.
Consequently,I believe that new middleware technology
must emerge that lets us glue these systems together.I don’t
know who will invent this technology or even when we will
see it.It’s not Java or ActiveX.It’s not CORBA or DCOM,
because I also wonder where organizations will find expert
integrators who know how to architect the whole solu-
tion—at present they are in extremely short supply.
Assessing project risks
Most of today’s corporate CIOs and CTOs don’t under-
stand the complexities of establishing an e-business.Aside
from the enormous management and people challenges,
many technical challenges confront such projects.
Examining e-business through the lens of the FURPSI—
bility, integratability—model of system quality (Herb
Krasner,“Using FURPSI for Software Product Quality
Evaluations,to appear in Software Quality Professional,
June 2000), I see increased technical risks in several areas.
Functionality.Systems will need to support a more inte-
grated style of business processes, including womb-to-
because IT shops must upgrade the
customizations each time a vendor
upgrades the base ERP package.
Once an ERP system is fully loaded
with the necessary corporate data and
hundreds or thousands of people start
using it,performance can suffer if you
haven’t designed for scalability.Users
who must wait more than a few sec-
onds to see the on-screen results of
their input will not be happy.Nor will
the regular appearance of the dreaded
“blue screen of death”please them.
ERP’s silver lining
Although trade publications tend to
focus on ERP’s failures, many ERP
projects have succeeded—they just
don’t seem to get much press.One well-documented excep-
tion is Cisco Systems, which reportedly installed a com-
pany-wide ERP system for about $30 million in only nine
months (Cisco Systems,Inc.:Implementing ERP,Harvard
Business School Publishing,Report 9-699-022,20 Oct.1998, you look closely at
what Cisco did,you realize it has taken IT to a new level,
integrating with its suppliers and customers to an amazing
degree,and realizing tremendous efficiencies and capabil-
ities as a result.It showed that a strong focus on business
goals in defining a system could lead to business success.
E-business systems are the latest fad in advanced IT and
business process improvement.Figure 1 shows the emerg-
ing architecture for such a system in a large company.
While watching some of my clients join the e-commerce
game,I’ve often observed that the following “ease into it”
scenario works well.These clients start easy,establishing
a Web site presence.Then they incrementally redesign
their Web page to add better organization, additional
information,enhanced searching,linking,and interactive
capabilities.Next,they attempt the challenging task of tak-
ing customer orders or handling customer transactions via
their Web page. If they clear this hurdle, they attempt to
integrate their Web-based front-end system with existing
legacy IT systems—a task so difficult that many organi-
zations fail to implement it.If they successfully integrate
their legacy systems, they then try adding other e-com-
merce capabilities,like supply chain management.Finally,
with all these capabilities in place, they begin to see new
ways of running their business and start improving their
systems and processes accordingly.
Strategic vision is key
If the organization has analyzed, planned, and archi-
tected well,the system functions as a fit and useful whole—
Integrated, enterprisewide
information system
Figure 1. E-business system architecture.
26 IT Pro January l February 2000
tomb management of customer, company, contractor,
and supplier relationships.
Usability.Systems must support the emerging point-and-
click generation.
Reliability.Systems must achieve the uptime goal of 24
hours a day, seven days a week, with 99.9999 percent
availability as the backup goal.Systems also need to be
safe and resistant to illegal penetrations.
Agility. Demand for shorter Web response times will
grow as people tire of the World Wide Wait.
Supportability.Systems must improve their capabilities
in a smooth evolution rather than through a constant
barrage of herky-jerky upgrades and bug fixes.
Integratability. Complexity will drive the movement
toward component-based integration and glueware—
the Lego block approach.More organizations will move
toward a distributed system built around a tiered archi-
When you add up the management,people-resistance,and
technical-complexity risks,it’s a wonder any substantive e-
business system project successfully achieves its lofty goals.
In this decade,existing ERP systems will expand to meet
e-commerce and supply chain management systems.Major
new versions of ERP software will be rearchitected to use
new technologies like Java and XML.The common archi-
tectural stratification standards may also give way to new
distributed-systems approaches.For example,it’s not clear
how existing client-server systems will meld with Web-
based technologies.
A corporate e-business project typi-
cally consists of five major phases, as
shown in Figure 2. These phases, per-
formed incrementally, usually overlap
Strategy definition. Phase one ad-
dresses the creation of a corporate e-
business strategy that contains a vision,
objectives, and an approach to
automating,improving, and integrat-
ing the company’s business processes
across the entire enterprise.The strat-
egy also defines the general scope of
an e-business system in terms of how
it will support the organization’s busi-
ness processes.
Existing-systems analysis and new sys-
tem capability planning. Phase two
begins with an analysis of existing
legacy systems, followed by the plan-
ning and architectural definition of the
new system’s capabilities.
System definition and development. Phase three involves
the precise definition and development of the integrated
e-business computer system that will provide support
for each of the company’s designated business units.
Deployment. Phase four focuses on deploying the
e-business system within one business unit or across sev-
eral to support the organization’s business processes.
Use and evolution. Phase five occurs when the organi-
zation effectively uses the deployed system—for
example,to improve the organization’s efficiency,effec-
tiveness, or competitiveness.Lessons learned from this
use feed back into earlier phases as the system evolves.
To reap the e-business system’s promised benefits, all
phases must succeed.Mistakes made in the first phase will
poison efforts in the second,and so on.
In some cases, an organization will outsource portions
of the project.For example,instead of the company’s own
MIS or IT department,you could contract with an IT sys-
tems integration company to develop the e-business sys-
tem. This solution presents a double-edged sword,
however:While outsourcing can supplement your com-
pany’s systems knowledge,it also exposes your company
to some risks in terms of performance and a knowledge
gap within your organization.
In the past decade,most ERP projects occurred over a
multiyear cycle. In this decade, however, increased com-
petitive pressures will demand that e-business systems be
delivered even more rapidly.The challenge of accelerat-
Strategy definition
Existing-systems analysis and
new system capability planning
System definition and development
Use and evolution
E-business goal
Figure 2. Typical project life-cycle model.
January February 2000 IT Pro 27
ing these phases will lead to rapid,incremental,and iter-
ative approaches to the essential activities of planning,
systems analysis,system definition,hardware acquisition,
software acquisition,custom software development,sys-
tems integration,testing,documentation,pilot use,instal-
lation, and evolution.
In ERP projects,I’ve seen many cases in which signifi-
cant iteration occurred both within the early phases and
across those phases.For example, it is not uncommon to
see the first and second phases iterate several times before
the planning is sound.Often,people think they know what
processes they want to automate right to the point when
the requested software packages actually come in-house.
Then gap analysis tells them it would be a lot cheaper to
adapt their processes than to rebuild the software,so it’s
back to the planning phase again.
Based on my experiences with ERP projects in the
1990s,I’ve found that for your project to succeed,you must
prevent problems in the following high-priority areas:
e-business strategy,
project management approaches,
complex technology and systems,and
end-user resistance.
A small investment in understanding,analyzing,track-
ing,and preventing these major problems should pay off
well given that most such problems are common,expected,
avoidable, and detectable early. One viable approach to
reducing the likelihood of failure is to identify the crucial
risks at each point of the project life cycle,then build plans
to address them before they become real problems.I have
found this technique useful in evaluating ERP projects
and fully expect it to be useful for evaluating e-business
system projects as well.
My colleagues at TeraQuest and I have built a risk fac-
tors model-and-analysis toolset for these types of e-busi-
ness-system projects (see
model captures the experience gained from studying ERP
failures as well as from identifying areas of improvement
in the management capabilities of organizations that per-
form large software projects using component packages.
For example,the toolset identifies 76 risk factors in eight
key categories for consideration when selecting an ERP or
e-commerce package. It then rates these factors as low-,
medium-,or high-risk indicators.Working with the factors
and toolset,a project team uses the high-rated factors to
plan for the mitigation of a risky selection decision.
IT personnel currently use the toolset to analyze lessons
learned on completed projects,review the status of proj-
ects under way, and assess risk planning as projects get
started.Data collected from all these sources provides a
growing knowledge base of common risks encountered,
thus enabling less problematic acquisitions of such pack-
aged systems.For more information about how this tech-
nique has been used in past situations for organizational
risk management, see the article “From Project Risks to
Organizational Learning—A Path to Practical Knowledge
Management” (Joyce Statz and Don Oxley, Application
Development Strategies,June 1998,http://www.teraquest.
f you consider your e-business system project to be cru-
cial to the future of your organization,you should want
to treat the knowable risks to success formally and
proactively so that you can focus resources and mitigate
potential project failures.The techniques I’ve presented
here can provide tools for starting this process.
Herb Krasner is an independent software systems/man-
agement excellence coach and troubleshooter at Krasner
Consulting.Contact him at
The best rates for
IT Pro
12 issues of Computer
Member discounts
on periodicals,
conferences, books,
Free membership in
Technical Committees
Digital library access
at the lowest prices
Free e-mail alias
your Computer Society
membership for
your Computer Society
membership for
... • Tratar de sucesso, falha ou indicadores em projetos ou processos Eden et al., 2014;Emirates, 2010;Garg & Agarwal, 2014;Ghasemzadeh et al., 2014;Grover et al., 1995;Kraft & Steenkamp, 2010;Krasner, 2000;McElroy, 1996;Melão & Pidd, 2003;Ngai et al., 2008;Nolan, 1999;Ogbo et al., 2018;Ram, Corkindale, & Wu, 2015;Rotchanakitumnuai, 2010aRotchanakitumnuai, , 2010bShakkah, Alaqeel, Alfageeh, & Budiarto, 2016;Umble et al., 2003;Zarei & Naeli, 2013) Grover et al., 1995;Herzog et al., 2007;Motwani et al., 2002) Escolha da tecnologia (Bai & Sarkis, 2013;Currie & Willcocks, 1996;Krasner, 2000;Willcocks & Griffiths, 1994) Project Owner (Dono do projeto) (Engelbrecht, Johnston, & Hooper, 2017;Ram et al., 2013) Realização de treinamentos e educação coorporativa (Bai & Sarkis, 2013;Dey, 1999;Ebad, 2018;Motwani et al., 2002;Muscatello, Parente, & Swinarski, 2016;Ram et al., 2013Ram et al., , 2015Shakkah et al., 2016;Zarei & Naeli, 2013) Papel do gerente do projeto (Ko & Kirsch, 2017;Ram et al., 2013) Mudanças no projeto (Alterações no escopo do projeto) (Motwani et al., 2002) Complexidade dos projetos (Cameron & Braiden, 2004;Willcocks & Griffiths, 1994 O corpus de pesquisa que forneceu alicerce para este artigo utilizou como preceito a tríade: projetos, processos e fatores críticos de sucesso. O alinhamento estratégico em projetos cujo produto seja a mudança de processos organizacionais foi abordado por diversos autores (CAPALDO; RIPPA, 2015;GROVER et al., 1995;UMBLE et al., 2003). ...
... • Tratar de sucesso, falha ou indicadores em projetos ou processos Eden et al., 2014;Emirates, 2010;Garg & Agarwal, 2014;Ghasemzadeh et al., 2014;Grover et al., 1995;Kraft & Steenkamp, 2010;Krasner, 2000;McElroy, 1996;Melão & Pidd, 2003;Ngai et al., 2008;Nolan, 1999;Ogbo et al., 2018;Ram, Corkindale, & Wu, 2015;Rotchanakitumnuai, 2010aRotchanakitumnuai, , 2010bShakkah, Alaqeel, Alfageeh, & Budiarto, 2016;Umble et al., 2003;Zarei & Naeli, 2013) Grover et al., 1995;Herzog et al., 2007;Motwani et al., 2002) Escolha da tecnologia (Bai & Sarkis, 2013;Currie & Willcocks, 1996;Krasner, 2000;Willcocks & Griffiths, 1994) Project Owner (Dono do projeto) (Engelbrecht, Johnston, & Hooper, 2017;Ram et al., 2013) Realização de treinamentos e educação coorporativa (Bai & Sarkis, 2013;Dey, 1999;Ebad, 2018;Motwani et al., 2002;Muscatello, Parente, & Swinarski, 2016;Ram et al., 2013Ram et al., , 2015Shakkah et al., 2016;Zarei & Naeli, 2013) Papel do gerente do projeto (Ko & Kirsch, 2017;Ram et al., 2013) Mudanças no projeto (Alterações no escopo do projeto) (Motwani et al., 2002) Complexidade dos projetos (Cameron & Braiden, 2004;Willcocks & Griffiths, 1994 O corpus de pesquisa que forneceu alicerce para este artigo utilizou como preceito a tríade: projetos, processos e fatores críticos de sucesso. O alinhamento estratégico em projetos cujo produto seja a mudança de processos organizacionais foi abordado por diversos autores (CAPALDO; RIPPA, 2015;GROVER et al., 1995;UMBLE et al., 2003). ...
... utilização de projetos orientados ao BPM/BPR tem apresentado resultados eficazes para o alinhamento entre processos e sistemas(KIM et al., 2005;KRASNER, 2000;SELTSIKAS, 2001). Identificamos durante a pesquisa que os projetos relacionados à implantação de sistemas de gestão do tipo Enterprise Resource Planning (ERP) são os tipos de projetos cujo escopo frequentemente causa mudanças em processos organizacionais. ...
... One of the main reasons for information systems project failures is user resistance (Keen, 1981;Markus, 1983;Krasner, 2000). User resistance should not be ignored since minor resistance can reduce the speed of change, but major resistance can lead management to abandon the project. ...
The convergence of cloud computing, mobile technology and big data technologies are transforming information technology faster than ever before. While there is an established knowledge base of known implementation issues relating to project management, technology, user resistance, organisation/environment and outsourcing, digital technologies introduce new challenges. This chapter summarises traditional challenges in information system implementation and discusses some of the issues arising from the deployment of digital technologies including migration to the cloud, security, data protection and ICT governance, contractual issues in the cloud, big data and mobility.
... Users' resistance to use ERP system is one of the important factors causing this failure. According to [3], the main challenges that the organization faces is related to people , 62 % of which are before and after post-implementation stages [4] states that ERP implementation is not a technical issue rather it is an issue related to the people. User resistance is one of the main issues that led to problems in implementing ERP system and threats to its functions. ...
In fact, ERP system has become required for many organizations particularly those organizations that have foundations in different countries. Recently, some organizations in Yemen have adopted ERP system but the usage of this system failed as it faced user resistance. Hence, the prime concern of this study is to investigate the resistance factors of Enterprise Resource planning from user perspective not organization or technical perspective to specify the basic reasons for user resistance to successfully adopting ERP system. Four factors are examined their association with adopting ERP. These factors are user training, resistance to change, user expectation, and system usage. A questionnaire was distributed to 200 of ERP end users. Linear regression analysis program was used to analyze the data and examine the relationship between user’s resistance factors and ERP adoption. The result shows that each of user’s training, resistance to change and system usage has a significant relationship with ERP adoption, However results show no relationship between user expectation and ERP adoption. This paper benefits management in organizations by providing the factors that contribute to adopt ERP system. Keywords: ERP adoption, User resistance, User’s training, Resistance to change, System usage.
... This is because employees tend to avoid using ERP when they do not like the system or do not feel comfortable using it (Chawla & Kelloway, 2004). Krasner (2004) ascertained that it takes numerous months for employees to get used to a new system and be comfortable using it after its implementation. However, with the complexity and system failures associated with ERP use, most accounting department employees tend to completely resist the system, which has resulted in its underutilization (Chawla & Kelloway, 2004). ...
Full-text available
The Enterprise Management Planning (ERP) software applications allow companies to integrate key daily activities such as procurements, financial, production, human resources, and project activities and helps organizational stakeholders to facilitate efficient decision making based on integrated data from various departments. Many accountants have not been able to realize the effectiveness of the ERP system due to its inadequate flexibility to adapt to change and resistance among some accountants that use the system. This research aims at showing the role that the inadequate flexibility of the system plays in impeding the ERP software from guaranteeing effectiveness and depicts how resistance to change among different stakeholders in an organization hinders the effectiveness of the enterprise resource planning (ERP) system in accounting. It uses a qualitative research method entailing semi-structured interviews with multiple employees working in the accounts department in different organizations. The study revealed that many accountants are driven by fear of new technology, making them resist the ERP system. Participants also affirmed that ERP does not readily adapt to organizational changes in the accounting departments. The major limitation of this study is that it focused on a small sample population because of the limited funds to cater to many participants.
... Multiple studies related to the use and implementation of ERP. have been focused mainly on the identification of success factors [8,9], implementation and evaluation of success [4,[10][11][12][13], however, there is a lack of research for specific modules of ERP systems and focusing on evaluation of the reduction of times of flow of information and customer response. ...
This paper aims to analyze the effect of implementing an inventory module of ERP Openbravo for the reduction of information flow time and customer response time, in a Colombian metalworking company. The processes structure and inventory management practices of the company were characterized and information flow time and customer response time were tested before and after implementing the inventory module. The main results were the reduction of 36% of information flow time and 41% of customer response time, so it can be concluded that obtained success is related to the active involvement of manager and workers’ willingness to change.
... Over the last decade, in addition, leading industrial vendors have tried to make their products scalable and cheap enough for SMEs [44]. In contrast, these monitoring systems are still designed for latest products and require specific software or expensive additional device have to be integrated with existing machine tools and effective implementation take a substantial amount of time; it can also be extremely rigid once installed [45]. At a machine tool level, Machine-to-Machine (M2M) communication protocols, such as MTConnect and OPC UA, have been considered as a potential standard. ...
Full-text available
In the new era of manufacturing with the Fourth Industrial Revolution, the smart factory is getting much attention as a solution for the factory of the future. Despite challenges in small and medium-sized enterprises (SMEs), such as short-term strategies and labor-intensive with limited resources, they have to improve productivity and stay competitive by adopting smart factory technologies. This study presents a novel monitoring approach for SMEs, KEM (keep an eye on your machine), and using a low-cost vision, such as a webcam and open-source technologies. Mainly, this idea focuses on collecting and processing operational data using cheaper and easy-to-use components. A prototype was tested with the typical 3-axis computer numerical control (CNC) milling machine. From the evaluation, availability of using a low-cost webcam and open-source technologies for monitoring of machine tools was confirmed. The results revealed that the proposed system is easy to integrate and can be conveniently applied to legacy machine tools on the shop floor without a significant change of equipment and cost barrier, which is less than $500 USD. These benefits could lead to a change of monitoring operations to reduce time in operation, energy consumption, and environmental impact for the sustainable production of SMEs.
This paper examines the role of fairness and how it shapes a user’s view in IT-enabled change. Drawing from several fairness theories, components of fairness are identified and examined in two studies. The first study examines the role of fairness through user interviews and finds that all five components of fairness are considered by users in enterprise system implementations. The second study operationalizes and analyzes the components of fairness through a questionnaire distributed to users. This second study finds that fairness is comprised of all five components that were proposed and a significant relationship exists with user dissatisfaction. The two studies lead to a new theoretical perspective and provide practical implications regarding the role of fairness in IT-enabled change and their strategic implications.
Full-text available
An Enterprise Resource Planning (ERP) system encompasses the mechanisms and inklings conducted for the solidified management of enterprise as all-inclusive from the discernment of consequential exertion of management expedients to embellish the expedience of the business. Several organizations have implemented ERP system but none of them has claims the desire results. User satisfaction is considered as central indicators of ERP project success. This study was conducted in Pakistani industry with the purpose to indentify and ensure potential success factors of ERP implementation. On the bases of extensive theoretical underpinning, measurement constructs of success factors of ERP implementation were identified. Survey instrument was developed from those success factors. Total three hundred and fifty questionnaires were distributed randomly to ERP users working in Telecom, engineering, Oil and Gas and Government sector. Out of distributed questionnaires two hundred and twenty eight (N=228) questionnaires were retrieved back. The responses were systematically entered, cleaned, and screened in statistical package for social science (SPPS). The core statistical techniques used in this study are regression and correlation analysis. The study finds that user satisfactions have positive and significance relationship with perceived usefulness of ERP system, Perceived ease of use of ERP, Internal support and compatibility of ERP system whereas as results demonstrability of ERP system is found to insignificantly related to ERP user satisfaction. The study further investigates that perceived usefulness, perceived ease of use, internal support, and compatibility of ERP system is perceived as important factors for ERP success. The findings suggests that all those interested in better business results and reliable business solutions should consider proper procedure review of software capabilities with confined focus on results demonstrability before embarking on ERP system implementation.
E-business projects (eBPs) can be described as endeavors which transform traditional business functions into digital and mostly automated, inter-organizational e-business functions. Although studies exist which already increased the understanding of such endeavors, there is still no conceptualization that defines eBPs as their own kind of project, summarizing and categorizing all of their characteristic topics, problem areas, and tasks. This study attempts to close this gap by exploring the conceptual nature of eBPs. A large number of practical project reports was evaluated, using a latent semantic analysis for the exploratory summarization of the textual database. As a result, the study provides a comprehensive theoretical conceptualization including 12 core concepts and 74 specific sub-concepts, structured within the context of a system development life cycle. Such a project conceptualization provides a contribution to the practical management of eBPs, as well as a theoretical framework for further establishing eBPs as a unique project type.
Telehealth can be used to develop innovative healthcare services for promoting medical quality and efficiency. Despite previous research on users’ adoption intention of telehealth, users’ acceptance and resistance have rarely been considered at the same time. This study used a research model based on the dual-factor concepts of “enablers” and “inhibitors” to explain users’ intentions to utilize telehealth. We extended the Technology Acceptance Model and Status Quo Bias with the technology anxiety concept to explain why patients accept or reject the use of telehealth from the perceived enablers and inhibitors of intentions. The experimental results demonstrated users’ ambiguous and indecisive intentions of adopting telehealth. It was also found that availability and perceived usefulness are the main factors that encourage individuals to adopt telehealth services. Technology anxiety and transition costs are the key factors in discouraging people from using telehealth. Technology anxiety could be overcome through the perceived usefulness to promote the adoption of telehealth.
ResearchGate has not been able to resolve any references for this publication.