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”. 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.