Zhang Danyang
Overview
Overview
This reflection will discuss
about the lessons learned from both successful and unsuccessful Enterprise
Resource Planning (ERP) implementation cases. The purpose of ERP is to
integrate and unify every aspect of the business of an enterprise into one
single suite of software system. Many of the ERP implementation cases occurred
around late 1990’s, in an attempt to tackle with Y2K problems. After discussion about the lessons learned
from these cases, the reflection will talk about the ERP implementation approaches,
and a new approach from Software Engineering is proposed.
The problem. ERP implementation is not
the kind of project that companies should or even could attempt to force into
a precise timeline. There is no better way to have sub-components missed or
have configuration completed shoddily than to force the project to complete
before a specific end date (Dieringer, 2004) . Taking Hershey as
an example, the project was initially planned to take 4 years, but the
management forced the implementation to complete in only 2.5 years. When the
system went live in July 1999, Hershey experienced serious problems generating
orders through the system, resulting huge lost during business peak period (Perepu, 2008) .
The solution. It is more important to
define and adhere to technical principles and then set business goals. After
that, the company is able to construct a flexible and realistic schedule that
will accomplish those business goals in accord to the principles. At the same
time, management must constantly review the need for extending deadline to
reduce the rate of system errors (Barton, 2001) . When Tektronix implemented
Order Management Account Receivable in one of departments, due to complexity
of legacy systems and potential dramatic change of business model, the company
carried out additional cycles of testing. Although the implementation took
twice as long as originally planned, the system is rolled out free of problem (Harvard Business School, 1999) .
The problem. Many companies wrongly regard the end-user
training as afterthought and commonly the first item to be trimmed when the implementation
project falls behind schedule. Consequently, it can result in disgruntle from
employees and will backfire the whole project. Without user training and
universal buy in, workers felt their jobs were threatened. Consequently, they
resisted the change by damaging inventory (Scott, 1999) .
The solution. That company places a
large focus on training is another essential factor of ERP implementation.
Training is the key element of ERP implementation and future usage, because
without it employees who will be using the ERP and the brand new business
process for day-to-day transactions will not prepare themselves to do so. Companies should resist cutting off the
training, and should understand the criticalness that employees get sufficient
training early and throughout the entire project (Dieringer, 2004) . Additionally,
companies can involve the end-users in the testing phase of the new project to
speed up the implementation process as well as training process.
Industrial best practices.
Companies should investigate their own business processes and evaluate the
payoffs of re-engineering that will be carried out conjointly with an ERP
implementation. Companies often seize the chances of ERP rollout to
re-engineer their business processes to adopt the industry’s best practices
built in the ERP system.
Competitive strategy. On
the other hand, if a company depends on its unique competitive advantage to
differentiate itself from competitors, it would possibly damage the strength
of the company by forcing the company to fit the system. The best practices in
ERP systems are general based and relies on a series of assumptions about how
a typical company carries out business. The best practice may vary from region
to region and companies may choose its own unique strategy, therefore the
legacy processes as unique competitive advantage should be left alone, as
argued by Erik Fosser (Erik Fosser, 2008) . Otherwise,
resistance and contempt will be bred within the company.
Conclusively, ERP
implementations offers companies a great opportunity to re-engineer processes
but great caution should also be taken when evaluating and choosing which one
of business processes to be altered and tuned in the end.
It is recommended to confine
the source code customizations and changes to the ERP system itself. As
evidenced by Tektronix (Harvard Business School, 1999) , if Tektronix did
not adhere to Plain Vanilla principle, the timeline, cost, and bugs in the
system would increase along with the increase in number of modification
requested.
The future maintenance and
upgrading will be easier and more cost-effectively if the number of modifications
is limited, as evidenced by Panasonic SAP Upgrade Project (IBM, 2008) – the limitedly
customized ERP system was upgraded within only one weekend for entire Europe.
Code modification should
only be carried out on occasions when it is absolutely needed (e.g. unique
competitive advantage). Otherwise, the company will run into heavy costs for
implementation and upgrade. The company should evaluate different ERP vendors
to find out a package can best fit its business model. The company will
benefit from finding a vendor’s ERP system that mirrors its business processes
as closely as possible, then resolve to implement that package with no drastic
modifications (Dieringer, 2004) . Moreover, it is
possible to send an analysis team to the vendor, ensuring that that vendor can
do what the company needs.
Top management commitment. Many
implementation project teams have placed much emphasis on buying in top
management. Without strong commitment and sponsorship, the ERP system can only
be installed rather than be implemented (Elisabeth J. Umble, 2003) . Unfortunately, top
management commitment is only half of the story. As evidenced by FoxMeyer, the
project failed despite the strong commitment of the CEO (Scott, 1999) .Only buying in top
management is not enough.
Universal buy-in. Every
employee as well as management needs to support the implementation process if
it is expected to be successful. As Dunn said, if the Nestle’s implementation team was to do the project
over again, the team would put the primary focus on obtaining universal
buy-in, and thereafter on installing the software. “If you try to do it with a
system first, you will have an installation, not an implementation. And there
is a big difference between installing software and implementing a solution” (Worthen, 2002) . In the case of
FoxMeyer, if warehouse workers supported the new system and business process
changes, there would not be such morale and inventory damage issues (Dieringer, 2004) .
The problem. It is not uncommon that
companies want to get the “best of breed”, thus they buy different products
for different business process from different vendors and hire consultants from
multiple consulting firms. The risk exposed to the company here is that
different products are hard to achieve synergy due to compatibility issues.
For example, the failure of ERP project of Hershey is partially attribute to
choosing SAP for production, Manugistics for SCM and Siebel for CRM (Perepu, 2008) . Furthermore, it is
even more dangerous to switch consulting firm half way through the project;
simply because the company has to start over again to bring the new consultants
to the same page, which is both costly and time-consuming.
The solution. As many examples
indicated, the one reason behind the success is to have a single vendor and
consultant firm throughout the project. Panasonic Europe has established a
long-term relationship with SAP as ERP vendor and IBM as consultant to ensure
a successful implementation and upgrade of the system (IBM, 2008) .
Integration points.
Nevertheless, it is still possible to have different systems functioning together.
Nestle succeeded making SAP module work together with Manugistics module after
IT team’s careful examining of integration points. The key issue here is
whether the company can synthesize the interfaces of systems. Only after that,
the company can obtain the benefits from the specialized advantages of
different systems.
When a company senses the
risk that the ERP implementation may go out of track, it should halt the
project proactively and re-assess the project scope and re-structure the
project team. The management should not “bet the company”. Otherwise
unfavorable results like bankruptcy can take place like what happened to
FoxMeyer.
Half way of implementation,
Nestle found itself essentially substitute process silos for process silo;
therefore Nestle halted the entire project proactively, and then gave Dunn
full responsibility after removing project co-leader. After a series of meeting
with key stakeholders and business executives, the project restarted and was
successfully delivered one year later eventually.
Whirlpool, a home appliances
company, opted not to halt the SAP ERP project despite the fact that read
flags had been raised in the testing phase. Whirlpool made the
shoddily-implemented SAP system go live; therefore the company suffered delays
in delivering its products to customer. The decision of continuing the project
rather than halting resulted in a crippled ERP order management system, which
left the home appliances stacking in warehouses with 40- to 50-day delays for
sales and delivery orders (Collet, 1999) .
Traditional approaches such
as big-bang and phase-in approach are waterfall approach (Figure 2). Big-bang
approach implements ERP modules in various departments simultaneously, while
phase-in approach implements the modules separately in different phases. But
both of them are waterfall model, that is, one series of tasks after another
in linear sequence, process flowing steadily downwards. ERP project team
should move to next step of ERP implementation only when its preceding step is
completed and perfected (Royce, 1970) .
Figure 1: Steps of Waterfall Approach
Software development
(Software Engineering) has radically changed due to the emergence of agile
development approach. ERP implementation project should also go beyond the
traditional waterfall approach, benefiting from using agile implementation
approach.
Figure 2: Steps of Agile Approach
Iteration. Agile methods break the
ERP implementation into small increments with multiple iterations. Iterations
are short-time cycle that typically last 1 to 4 weeks. Each iteration (Figure
2) involves planning, requirement elicitation, design, implementation, unit
testing, and user evaluation and acceptance testing (Beck, 1999) .
Incremental change.
Traditional big-bang or phase-in approach, project team is required to fully
implement one ERP module in one department and then do the testing. Instead,
agile approach empathizes on implementing smaller portions of the module at a
time. Both end-users can learn the system and the project team can learn the
business process. Such learning comes from the incremental changes where the
process starts with a simple implementation of a subset of the module and
iteratively enhances the evolving versions until the full module is
implemented (Allenman, 2002) .
Working prototype. Agile
approach empathizes on working prototype as the primary measure of ERP
implementation process. One iteration might not implement enough functionality
to guarantee a live system, but the objective is to have a working prototype
to allow the client to evaluate project.
Communication. Agile approach empathizes
on the high frequency face-to-face communication between the implementation
team and client. Thus it facilitates the full involvement of the client
throughout the process. Working closely with the client, ERP project team can
understand more about the client’s requirements and get rapid feedback in
every single iteration.
There are as many lessons
learned from successful ERP projects as there are from failed projects. A
portion of lessons is covered in this reflection derived from these project
implementation cases:
·
Flexible and realistic project
timeline
·
Emphasis on end-user
training
·
Balance between
re-engineering the business process and modification of the ERP software
·
Strong top management
commitment as well as universal buy-in
·
Choice of single vendor and
single consultant
·
Pro-active halting of the
project
Moreover, the agile approach
is recommended for the ERP implantation project in the future, compared to
big-bang approach and phased approach.
ERP implementation is not a
single destination, but a journey towards smarter business operations, an
evolutionary process for modern enterprises.
(1950 words)
Works Cited
Allenman, G. B. (2002). Agile Project Management
Methods for ERP: How to Apply Agile Processes to Complex COTS Projects and
Live to Tell About It. Extreme Programming and Agile Methods: XP/Agile
Universe, Springer Verlag, 70-78.
Barton, P. (2001, Nov 25). Enterprise Resource
Planning Enterprise Resource Planning. Retrieved April 14, 2013, from
http://www.umsl.edu/~sauterv/analysis/488_f01_papers/barton.htm
Beck, K. (1999). Embracing Change with Extreme
Programming. Computer , 70-77.
Collet, S. (1999). SAP: Whirlpool's rush to go live
led to shipping snafus. Computerorld.
Dieringer, D. S. (2004). ERP Implementation at
Nestle. Enterprise Resource Planning Systems.
Elisabeth J. Umble, R. R. (2003). Enterprise
resource planning: Implementation procedures and critical success factors. European
Journal of Operational Research, 241-257.
Erik Fosser, O. H. (2008). Organisations and Vanilla
Software: What Do We Know About ERP Systems and Competitive Advantage? European
Conference on Information Systems, Galway, Irland.
Harvard Business School. (1999). Tektronix, Inc.:
Global ERP Implementation. Harvard Business Cases.
IBM. (2008, Sep 01). Panasonic Europe teams successfully
with SAP and IBM. Retrieved April 14, 2013, from IBM:
https://www-01.ibm.com/software/success/cssdb.nsf/CS/STRD-7J3L6M?OpenDocument&Site=gicss67sap&cty=en_us
Perepu, I. (2008). ERP Implementation Failure at
Hershey Foods Corporation. ICFAI Center for Management Research.
Royce, D. W. (1970). Managing the Development of
Large Software Systems. Concepts and Techniques, Proceedings of WESCON.
Scott, J. E. (1999). The FoxMeyer Drugs' Bankruptcy:
Was it a Failure of ERP? Americas Conference on Information Systems AMCIS,
Milwaukee, USA, 223-225.
Worthen, B. (2002). Nestle's ERP Odyssey. CIO.
No comments:
Post a Comment