|
Why ERP systems fail
by Bernie Goldband
Implementing and maintaining large
scale Enterprise Resource Planning (ERP) software can require major dollar
investments. Yet many companies invest in an ERP system without adhering to the
same disciplines applied to other areas of their business.
They typically discard essential
steps such as risk assessment, benefit analysis, performance objectives, and
cash flows. In their place, they make expenditures based on naive assumptions
that the computer will magically transform a company into a paragon of
efficiency. This misguided approach sets up a sequence of events that often
leads to a failure of objectives. The resulting conclusion is that the ERP
software was a bad investment decision.
As a business consultant, I am often
asked to review a failed ERP implementation and determine the circumstances that
led to its failure. Frequently, company management will conclude that the
software doesn’t work or it is too complex to implement in their unique
environment. Management further compounds the failure by claiming that the wrong
ERP system was chosen, and if they had the “right” software package they could
recapture their initiative and achieve their original objectives.
Yet, my experience is that the
software itself is rarely the source of failure. In fact, selecting the presumed
“right” software package will most likely result in a second failure – this one
even more costly than the first.
Best business practices
ERP packages, even those that are industry specific, are designed for a large
audience of companies looking to achieve success by following a template of best
business practices. However, software often fails to achieve its promise because
people who have a vested interest in existing processes are reluctant to change.
This leads to costly program modifications to replicate those processes. This,
in turn, can result in unnecessary manual tasks and issues of software
maintenance, which neutralize the original benefits of the software.
When making your ERP software
selection, examine the processes encoded in the software. If you can agree to
model your company’s best practices based on those processes, you’re choosing
the right solution. If you can’t, continue looking.
Once the ERP system is chosen, it’s
not uncommon for management to turn the project over to a subordinate to manage
the implementation. The problem is that the subordinate, who is usually chosen
from the end-user base or IT department, typically isn’t given the authority to
implement necessary business process changes.
Project management is a discipline,
if not an art, which requires the ability to delve into detail while keeping a
perspective on the original business objectives. The project manager needs to
have the ability to overcome impasses through a judicious combination of
political guile and management direction.
The most successful ERP projects are
led by a member of the management team who has actively participated in both the
software selection and implementation efforts. When selecting your project
manager, choose the one who has the most to gain (or lose) from the ERP system.
Implementation budget
Once the project manager is selected, many companies tie their hands by under
funding their efforts or by limiting the scope through impractical project
schedules. It has been my rule of thumb that an implementation budget should be
a one-to-three times multiple of the list price of the software package. Budgets
are variable based on the size of the organization and the package selected.
Tier 1 packages, such as SAP or
Oracle, should be budgeted on the upper end of the range due to their
implementation complexity and the size of company that gravitates to that part
of the spectrum. Other packages fall elsewhere on the range. Variations can
occur as a result of the amount of outside consulting required and the
geographical diversification of the company.
At a minimum, five to 10 percent of
the implementation budget should be set aside for a project management
consultant. Many companies make the mistake of using the software vendor for
this role. But the vendor is driven by installing the package and moving on, not
by business process improvement. Furthermore, vendors do not have the resources
and background to evaluate and recommend business process improvements and do
not see this as their job.
The most significant cost of the ERP
implementation is not the software, but the cost of the implementation. Budget
accordingly.
Project schedule
Project schedules are equally important to ERP initiatives as implementation
budgets. Some companies try to back-schedule an ERP project by establishing an
implementation go-live date and then attempting to schedule interim (and often
unrealistic) milestones. This usually results in insufficient attention to
details and carelessly completed tasks.
An effective project plan starts
with a kick-off meeting and logically progresses to a go-live conclusion. Tasks
should be properly resourced and scheduled, in man-day increments, with no task
exceeding 15 days. At the end of each task, a meaningful deliverable should be
presented for evaluation by the project manager.
The project schedule is the
foundation of a successful ERP implementation; it should be developed and
monitored carefully. The schedule should be updated weekly to reflect real-time
activity and progress, and regularly reviewed by both the project manager and
senior management.
Training and education
The last reason for ERP system failure that we are going to look at in this
article is a double-edged sword: lack of training and education. Many companies
confuse – and under fund – both tasks.
Traditional training, initially
provided by the software vendor, is essential to successful ERP implementations.
For obvious reasons, end-users need to have working knowledge of the selected
software package to feel confident when performing their jobs.
There are two ways to approach this.
One is have the vendor provide all of the training. The alternative is to take a
“train the trainer” approach where the vendor trains a few individuals who then
train the rest of the staff. The latter approach minimizes the stress on your
implementation budget while developing expert users who tend to claim ownership
of the process. There are no rules of thumb, however, in time or percentage of
implementation budget, to determine how much training is required.
Successful ERP implementations
stress staff training. They provide training sessions regularly throughout the
project, with special concentration during the weeks just prior to
implementation.
Education is different from training
and provides staff with the knowledge of the methodology behind their
activities. Members of the management team, master production schedulers, shop
foremen, or even cost accountants won’t be effective unless they understand the
concepts required to do their jobs in an ERP environment.
You can’t rely on the software
vendor to perform the task of educating your workforce. In fact, the education
step should really begin prior to package selection. This allows key staff to
correctly evaluate your company’s processes as they relate to the software
requirements and each vendor’s offerings. For companies who miss this early
opportunity, education should be completed prior to the new software
configuration.
Make the commitment to educate
yourself and your staff on how you need the business to perform and consider
outside help if needed. For example, successful ERP education programs have been
developed in conjunction with professional organizations such as The Association
for Operations Management (APICS) and independent consultants who specialize in
operations management education.
Taking responsibility leads to
success
Now that we’ve outlined some of the real reasons why ERP implementations fail
(some say up to 50% or more), it’s time to ask: Whose failure is it?
None of the points discussed here
are technical issues related to software. An overwhelming number of ERP system
failures are caused by lack of attention to the critical management issues
discussed above. Even the right software will fail under similar circumstances.
Blaming or changing your ERP system is simply a way to divert attention from the
execution mistakes made as a result of human error.
To rescue a failing ERP project,
start by taking corrective action. Before throwing out your current system (or
worse, letting it spin into oblivion), evaluate what steps were followed (or not
followed) to bring you to your present situation. Use the key points in this
article to make sure you understand why the system is failing. Be prepared to do
whatever it takes to reverse the current course of action.
There are times when the software is
not appropriate for a particular environment. Even then, the reason for failure
is not the software. Rather, it is the lack of due diligence by the company
before buying it. While software mismatch does occur, those instances are not as
common as business managers believe.
Bernard Goldband is an
executive-level management consultant with more than 25 years of information
systems and technology management experience in manufacturing, distribution,
finance, planning, and process improvement. He has been responsible for the
implementation of IT solutions in both domestic and multi-national companies,
with emphasis on technology infrastructure, integration of enterprise-wide
business solutions, and applications development. Reach him at
bgoldband@ctsguides.com.
This article originally
appeared in
the March/April 2008 issue of Progressive Distributor. Copyright
2008. back to top
back
to e-business archives |