Introduction
At first glance, Enterprise Resource Planning (ERP) systems
seem to be the silver bullet for every company’s problems. In one fell swoop, implementation of an ERP
system offers a company the chance to re-engineer business processes,
coordinate the systems of geographically dispersed locations, consolidate data,
and empower users by giving them access to all the company’s data in real time. Of course, these opportunities come at a high
price in terms of financial cost, implementation nightmares, and human
issues. Often these implementations fail
miserably as they run behind schedule and over budget; other times they are
successful. Regardless of the outcome,
each ERP implementation holds valuable lessons to be learned for companies
considering their own ERP implementation.
The
Business Case for an ERP
The business case for implementing an ERP system can be seen
by examining any one of three Nestle stories.
Nestle SA is the parent company of the candy-making giant and is
headquartered in Switzerland
(Konicki, pg 185).
In 2000 Nestle SA decided that it wanted to leverage its size and begin
acting like the giant it is. To do so,
it signed a $200 million contract with SAP to roll out an ERP system to its
230,000 employees in 80 countries around the world (Olson, pg. 53). In addition to this sum, Nestle SA also
committed to an additional $80 million to be spent on consulting, maintenance,
and upgrades (Konicki, pg. 185). Executives at Nestle SA realized that the
company needed to standardize its business processes if it wanted to be
competitive. The rollout was scheduled
to take three years for Nestle SA’s largest sites
with the others to follow. Included in
the implementation were the mySAP.com financials, accounts payable, accounts
receivable, planning, production management, procurement, direct procurement,
supply-chain, demand planning, fulfillment, and business-intelligence modules (Konicki, pg. 185).
Prior to the Nestle SA ERP decision, Nestle UK
had already implemented an ERP system.
The British subsidiary of Nestle SA implemented SAP R/3 over a period of
five years in 18 UK
manufacturing sites (Glick, 7 Days, pg. 4).
This implementation wrapped up in 1999 and was the one of the UK’s
largest ERP systems with over 6,000 users (Glick, Enterprise,
pg. 24). As with the Nestle SA
deployment, the goals of the Nestle UK implementation were centered on
leveraging the size of the organization as well as tightening up the supply
chain and re-engineering work practices and processes (Glick, 7 Days, pg. 4).
The third Nestle ERP implementation story involves Nestle USA. Nestle USA
is the $8.1 billion U.S.
subsidiary of Nestle SA. In 1997, Nestle
USA
began its own ERP project known as Best (Business Excellence through Systems
Technology) (Worthen, pg. 1). Scheduled to run over the course of six years
ending in the first quarter of 2003, this project was budgeted at well over
$200 million and would implement five SAP modules: purchasing, financials, sales and
distribution, accounts payable, and accounts receivable (Worthen,
pg. 1-3). Similar to the other two
Nestle divisions, the goal behind this ERP implementation was unification. Additionally, the project would solve Nestle USA’s
Y2K woes (Worthen, pg. 3). In the case of Nestle USA,
the ERP was part of the vision Nestle USA
Chairman and CEO Joe Weller referred to as “One Nestle” that would be
responsible for “transforming the separate brands into one highly integrated
company” (Worthen, pg. 2). Prior to the implementation, Nestle USA
had nine different general ledgers and 28 points of customer entry (Worthen, pg. 2). The
goal of the ERP project was to bring these numbers down to one. One of the most interesting views on the
Nestle USA problem is the story of vanilla.
Prior to the ERP implementation, Nestle USA
did not act as one company. Instead,
each location acted on its own behalf and was free to make its own business
decisions. “In 1997, a team examining
the various systems across the company found, among many other troubling
redundancies, that Nestle USA’s brands were paying 29 different prices for
vanilla – to the same vendor” (Worthen, pg. 2). This situation arose from the fact that each
factory negotiated their own deals with the vendor and the vendor adjusted the
price per factory based on what they thought the factory would pay. The situation was only worsened by the fact
that each factory referred to vanilla in a different way. While one factory might have referred to
vanilla as 1234, another factory referred to it as 7890. This made it nearly impossible for
individuals at the corporate headquarters to do
comparisons across plants to see manufacturing costs (Worthen,
pg. 2).
Regardless which Nestle case is examined, the goals behind
all three ERP implementations were similar for all the divisions. That is, in each instance, there was a
driving goal to consolidate the operations of the different locations so that
Nestle could truly leverage their size and buying power. Additionally, there was a need to centralize
and control data so that the financial, reporting, and forecasting numbers were
more consistent and accurate. As each
factory acted as an autonomous unit, Nestle was at a severe competitive
disadvantage and realized that it needed one system used by all in order to be
more efficient and survive in the global economy.
Implementation
Strategy
The term ‘ERP implementation’ has become synonymous with
‘nightmare’ in recent years. High
profile failures dot the headlines and companies are often intimidated not only
by the high price but also the negative effect implementations can have on
their business. Vendors such as SAP are
working diligently on shaking this reputation and have made great strides in
meeting their goals. “In 1996, a user
could expect to pay six to 10 times the license cost in consulting
charges. These days the external
consulting cost has dropped to typically one to two-and-a-half times the software
costs, depending on how much process re-engineering the user does” (Adshead, pg. 26). Fortunately
for companies considering an ERP implementation there have been enough done in
the past that there are opportunities to learn from the successes and failures
of others. One of the key factors of a
successful implementation is “don’t try to make the product fit exactly the way
you would ideally like to work or on the other hand assume that people will
completely change their processes to meet the package. The first takes many years and costs loads,
the second meets big resistance” (Adshead, pg.
26). For most businesses there needs to
be a middle-of-the-road approach where individuals realize that the software
will not solve every organizational problem and not every process in the
company can be re-engineered to fit the software. Regardless, savvy project leaders with prior
ERP implementation experience will tell you that there are several pitfalls to
avoid during ERP projects. The first is
not to select an ERP package based on a demo.
Choose your package wisely, ask questions, get references, and do your
homework. An ERP package is a costly
investment and you need to be sure you are choosing the package that best fits
the needs of your organization. The
second is get management commitment. Not
securing top management buy-in results in an automatic project failure. Management commitment is often high at the
beginning of a project but begins to wane as the project wears on. It is vital to keep management interested,
involved, and positioned squarely behind the project. The third is to avoid heavy
customization. It is both easy and
tempting to customize ERP packages to fit your exact needs. Unfortunately excessive customization will
haunt you by lengthening the project timeline and by driving up maintenance
costs in the future. The final pitfall
to avoid in ERP implementations is not to underestimate the importance of
training. It is not uncommon that users
receive several days of training on the new system and then do not see the
system again for months. Users need
in-depth and on-going training and should even be involved with system testing
if at all possible (Adshead, pg. 27).
Unfortunately for Nestle USA,
they did not heed the failures of others.
Throughout the implementation, Nestle USA
made several large mistakes that almost doomed the project. When the project began a team of 50 top
executives and 10 senior IT professionals was assembled to develop a set of
best practices for all Nestle USA
divisions. The goal was to develop these
best practices for all functions of the organization. Each function from manufacturing to sales
would eventually be forced to retire their old approaches and adopt the new
best practice that had been developed.
Concurrently, a technical team was charged with the task of implementing
a common data structure across the company (Worthen,
pg. 2). By the time the implementation
began in 1999 Nestle already had problems with its employees’ acceptance of the
system. Most of the resistance met by
the project team was traced back to the fact that “none of the groups that were
going to be directly affected by the new processes and systems were represented
on the key stakeholders team” (Worthen,
pg. 3). This was only the start of
Nestle USA’s
problems. By early 2000, the
implementation had turned into a disaster.
Employees did not understand how to use the new system and did not
understand the new work processes they were being forced to adopt. Divisional executives were just as confused
as their employees as they had been left out of the planning and development of
the new system and were less than willing to assist in straightening out the
mess that had developed (Worthen, pg. 3). The result of this was that morale plummeted
and turnover skyrocketed. In fact, “turnover among the employees who forecast demand for
Nestle products reached 77 percent” (Worthen, pg. 3).
Nestle USA’s
implementation problems did not stop with employee issues. Technical difficulties began to emerge as
well during the rollout. In the rush to
beat the Y2K deadline the project team had overlooked the integration points
between the modules. This meant that the
different modules could not talk to each other.
So if a salesperson gave a discount to a customer and entered it in the
system, the accounts receivable portion of the system did not know of the
discount. The result was that the
customer would pay their bill but invoice appeared as though it were only
partially paid (Worthen, pg. 3).
By June 2000, Nestle USA
was forced to halt the rollout and the project manager was removed from the
project and reassigned to Switzerland
(Worthen, pg. 3).
Nestle USA
gathered 19 key stakeholders and executives went on a three-day offsite retreat
to discuss the future of the project.
Out of this meeting came the revelation that they would need to redefine
the business requirements of the project and then shape the project timeline
around the requirements rather than to shape the timeline around a predetermined
end date (Worthen, pg. 3-4). This process took until April 2001 and
resulted in a detailed blueprint for the project team to follow. A director of process change was hired to act
as a liaison between the project team and the different functional divisions (Worthen, pg. 4).
With all of these items finally resolved, the project was able to
continue. The last rollouts were
scheduled to be completed in the first quarter of 2003 (Worthen,
pg. 1).
Results
Although there were bumps in the road for Nestle USA’s
ERP implementation, it certainly seems to be paying for itself. As of 2002, Nestle USA
claimed they had already realized a savings of over $325 million (Worthen, pg. 1).
Most of these savings came in the area of supply chain improvements,
specifically demand forecasting. “The
old process involved a sales guy giving a number to the demand planner, who
says, ‘Those guys don’t know what the hell they are talking about; I’m going to
give them this number’. The demand
planner turns [that number] over to factory, and the factory says the demand
planner doesn’t know what the hell he’s talking about. Then the factory changes the number
again. With SAP in place, common
databases and business processes lead to more trustworthy demand forecasts for
the various Nestle products.
Furthermore, because all of Nestle USA
is using the same data, Nestle can forecast down to the distribution center
level” (Worthen, pg. 4).
In addition to saving money, Nestle USA
has also been able to come together as one organization. The problem of 29 different brands of vanilla
has been solved and now with common databases each factory refers to vanilla in
the same manner. They also use common
processes that simplify operating procedures and allow for the centralization
of functions such as developing training procedures. Training no longer needs to be customized for
each factory. Since each location
follows the same procedures, training materials only need to be developed
once. Additionally, any Nestle USA employee
could relocate to another factory and not have to adjust to local processes.
Nestle UK
experienced similar successes with their ERP implementation. They were able to recoup the money spent on
the system in only two years (Glick, 7 Days, pg. 4). Further, like their American counterpart,
Nestle UK
has experienced reduced inventory levels, tighter control on inventory, and a
more disciplined attitude toward business processes (Glick, 7 Days, pg.
4). Most importantly, the ERP
implementation at Nestle UK
helped to foster a “culture of continuous improvement” (Glick, Enterprise,
pg. 24). “Improvement priorities are
clear: first, the internal
opportunities; second, business-to-business; and third, business to consumer”
(Glick, Enterprise,
pg. 24). This attitude is embodied by
the fact that following the ERP rollout they hired a process development
manager. This person’s sole
responsibility is to act as a bridge between business and the Information
Technology department and to make sure that employees stay focused on
continuous improvement rather than simply trying to maintain existing systems
(Glick, Enterprise,
pg. 24).
Recommendations
The Nestle USA case is an excellent case study for ERP
implementations because it contains both successes and failures. There were obviously breakdowns during the
planning phases of the project yet the overall result can be considered
successful due to the consolidated system they now have in place and the amount
of money that they are saving due to the ERP rollout. By examining the experiences of Nestle USA
other companies can learn valuable lessons that can be applied to their own
rollouts. Some of these lessons come
straight from the mouths of Nestle USA
executives while others are observations made from studying the case.
The first lesson that can be learned from the Nestle USA
scenario is that in order for an ERP implementation to be successful the right
individuals need to be involved in the process from the beginning. Nestle learned this lesson the hard way and
eventually was forced to halt their rollout.
It is simply impossible to redesign work processes without involving
some of the people that actually do the work.
While an argument could be made for “too many cooks in the kitchen”
regarding ERP implementations, it is certainly better to have more people than
needed rather then not enough when the future of the company is on the line. It is easier on the project schedule to trim
the project team during the project than it is to bring new people into the fold
and then have to spend time bringing them up to speed on all of the intricacies
of the project.
Another lesson that can be gleaned from the Nestle USA case
is that an ERP implementation is not the project that companies should attempt
to force into a specific timeline. There
is no better way to miss things and have components completed shoddily than to
force the project timeline to fit a specified end date. Again, with the future of the company on the
line, it is important to completely define the business goals of the project
and then create a timeline that will accomplish those goals.
A third recommendation for companies considering an ERP
implementation is to place a large focus on training. Training is one of the key elements of any
ERP implementation because without it employees that will be using the system
and the new business processes on a day-to-day basis will not be prepared to do
so. As with most software projects,
training is often an afterthought and typically one of the first items to be
cut or reduced when the project timeline begins slipping. Organizations must resist the urge to do this
on ERP projects. It is crucial that
employees receive training early and often throughout the project. If at all possible, end-users should also be
involved in the testing of the new system.
Fourth, organizations should spend time evaluating the
business process re-engineering that will be done in conjunction with an ERP
implementation. Companies often take the
opportunity presented by an ERP rollout to either redesign business processes
or adopt best practices throughout the organization. Caution should be exercised during this phase
as re-engineering processes just for the sake of re-engineer the process is often
not necessarily a wise business decision.
There are times where processes should be left alone. There are also instances where best practices
may vary from location to location.
Attempting to force a new or revised process on every facility in the
organization is an excellent way to breed contempt and resistance within the
organization. ERP implementations do
offer a great opportunity to re-engineer processes but great care should be
taken when selecting which processes are actually modified.
The fifth general recommendation for ERP projects is to
limit the number of customizations that are done to the system. As the number of customizations requested
increase so does the cost, timeline, and likelihood of bugs in the system. Since ERP systems are sold by vendors rather
than developed in-house, they need to be generic enough to be resold to
multiple organizations. This means that
either the software needs to be customized to fit an organization’s needs or
the organization’s processes need to be redesigned to fit the software. As mentioned earlier, it is important to
choose which processes are re-designed wisely.
Combined with this recommendation, it becomes clear that making the
determination as to which processes are re-engineered and which pieces of
software are customized is a balancing act.
The final recommendation for ERP implementations is to
obtain universal buy-in for the project.
Traditionally, much emphasis has been placed on securing buy-in for the
project by top level executives.
Unfortunately this is only half the battle. Everyone in the organization needs to support
the project if it is to be successful.
In the case of Nestle, if they “were to do it over again, [they’d] focus
first on changing business processes and achieving universal buy-in, and then
and only then 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, pg. 4). The
end-users are the ones that will be using the system and the processes. If they are not behind the system there will
be morale and turnover issues.
Conclusion
In summary, ERP implementations are unlike any other system
implementation that a company will ever experience. Despite the bad press that ERP systems and
their corresponding rollouts receive, it is possible to experience a successful
rollout. Often, as in the case of Nestle
USA,
organizations will encounter major setbacks and difficulties during the
implementation yet still be able to salvage a successful project. The important point to take away is that the
plans must be flexible enough to change mid-stream to overcome obstacles that
appear during the project and organizations must do their homework prior to beginning
an ERP project. Enough companies have
gone through implementations that there are plenty of lessons to be learned if
organizations are willing to accept the advice of others. ERP implementations combine disparate data
sources, re-engineer processes, and involve large numbers of users and
locations. It is nearly impossible to
plan for every contingency in projects of this size. The difference between success and failure is
an organization’s ability to rally and work together during difficult times to
reach an end goal that will eventually make everyone’s job easier and the
company more competitive.
References
- Adshead, Antony. SAP:
The Climb Gets Easier. Computer Weekly, Dec
12, 2002; pg. 26-27.
- Glick,
Bryan. 7 Days: SAP Software Gives Nestle Sweet
Returns. Computing,
Apr 12, 2001;
pg. 4.
- Glick,
Bryan. Enterprise:
Nestle Points the Way Forward from ERP.
Computing, Apr
12, 2001; pg. 24.
- Konicki, Steve. Nestle Taps SAP for E-Business. InformationWeek, Jun
26, 2000; pg. 185.
- Olson,
David L. Managerial Issues of Enterprise
Resource Planning Systems. McGraw Hill/Irwin, New
York, 2004.
- Worthen, Ben. Nestle’s ERP Odyssey. CIO, May
15, 2002.
[Online]. Available: http://www.cio.com/archive/051502/nestle.html
(Jun 18,
2004).