ERP and Change Management at Nestlé

A year after signing a $200 million contract with SAP and over $80 million for consulting services and maintenance, Anne Alexandre, an analyst for HSBC securities in London, downgraded her recommendation on Nestlé SA stock. Although the Enterprise Resource Planning (ERP) project will probably provide long-term benefits, she was concerned with what short-term effect the project will have on the company. She believes "It touches the corporate culture, which is decentralized, and tries to centralize it. That"s risky. It"s always a risk when you touch the corporate culture."

Nestlé Company"s goal is to build a business as the world"s leading nutrition, health, and wellness company. The company was founded in 1867 when Henri Nestlé developed the first milk food for infants and saved the life of a neighbor"s child. Nestlé is headquartered in Vevey, Switzerland with offices worldwide. Aside from chocolate and confectionaries, the company is widely known by its major brands, which include Purina®, Kit Kat®, Stouffer"s®, and Poland Spring®. Revenues reported in 2007 were 107,552 million Swiss francs with a net profit of 10,649 Swiss francs.

In the early 1990s, Nestlé was a decentralized company where each of the brands, such as Carnation® and Friskies®, operated independently. The brands were unified and reorganized under Nestlé USA, but the divisions still had geographically dispersed headquarters and made their own business decisions autonomously. Moreover, a team charged with examining the various systems and processes throughout the company found many problematic redundancies. For example, Nestlé USA brands were paying 29 different prices for vanilla to the same vendor. Jeri Dunn, vice president and CIO of Nestlé USA, said "Every plant would buy vanilla from the vendor, and the vendor would just get whatever it thought it could get. And the reason we couldn"t check is because every division and every factory got to name vanilla whatever it wanted to. So you could call it 1234, and it might have a whole specification behind it, and I might call it 7778. We had no way of comparing." Dunn and her team recommended technology standards and common systems for each brand to follow that would provide for cost savings and group buying power. Dunn then went to Switzerland to facilitate the implementation of a common methodology for Nestlé projects worldwide, but when she returned stateside two years later as a CIO she found that only a few of her recommendations were being followed. As Dunn recalls, "My team could name the standards, but the implementation rollout was at the whim of the businesses."

Dunn"s return to the states followed USA chairman and CEO Joe Weller"s vision for uniting all of the individual brands into one tightly integrated company. Reflecting on the company"s condition, Dunn said "I don"t think they knew how ugly it was. We had nine different general ledgers and 28 points of customer entry. We had multiple purchasing systems. We had no clue how much volume we were doing with a particular vendor because every factory set up their oven vendor masters and purchased on their own." Dunn and a group of managers from finance, supply chain, distribution, and purchasing formed a key stakeholder team to study what Nestlé did right and what could be improved upon. They were given about two hours to present their findings to Joe Weller and other top executives, but the meeting ended up taking up the whole day.
The blueprint from the stakeholder team included SAP as a cornerstone project that would take three to five years to implement. As Dunn points out, "We made it very clear that this would be a business process reorganization and that you couldn"t do it without changing the way you didbusiness. There was going to be pain involved. It was going to be a slow process, and this was not a software project." Unfortunately, senior management did not take the key stakeholder team"s recommendation to heart, nor did they understand the pain it would create. As Dunn said, "They still thought it was just about software."

In October a team of 50 senior business managers and 10 senior IT managers formed a team to carry out the SAP implementation. The team was responsible for defining a set of common processes for every division. More specifically, each divisional function, such as purchasing, manufacturing, inventory, accounting, and sales, would have to give up their old ways and start doing things the new Nestlé way.

Another team spent 18 months reviewing each piece of data in all the divisions in order to come up with a common data design across the entire business. For example, vanilla would now be coded as 1234 in every division so that the SAP system could be customized with uniform business processes and data. However, the team decided against using SAP"s supply chain module, Advanced Planner and Optimizer (APO), because it was recently released and therefore viewed as too risky. Instead, the team recommended a supply chain module called Manugistics that was developed by an SAP partner.
By March the team had a project plan in place where Nestlé would implement five SAP modules: purchasing, financials, sales and distribution, accounts payable and receivable, and the Manugistics supply chain module across every Nestlé division. Implementation began in July with a deadline of approximately 18 months. The deadline was met, but just as many problems were created as were solved.

Before all of the modules were rolled out, there was a great deal employee resistance. It appears that the problem was that none of the groups affected by the new system and processes were represented on the key stakeholder team. Dunn recalls her near fatal mistake. "We were always surprising [the heads of sales and the divisions] because we would bring something up to the executive steering committee that they weren"t privy to."
By the time of the expected rollout, the project had collapsed into chaos. Workers did not understand how to use the new system or the new processes. The divisional managers were just as confused as their employees and probably even a bit angrier. Dunn"s help desk took 300 calls a day, and she admits "We were really naïve in the respect that these changes had to be managed."

Subsequently, morale deteriorated and nobody took an interest in doing things a new way. Turnover reached a new high of 77 percent. Supply chain planners were unable and unwilling to abandon their familiar spreadsheets in favor of the complex Manugistics system. Other technical problems began to arise due to the rush to make the project"s deadline. Integration points between modules were overlooked. For example, although the purchasing departments now used common data conventions and followed the same processes, their systems could not integrate with the financial or sales groups.

The project was stopped in June. A coproject manager was reassigned and Dunn was given full responsibility. In October, Dunn invited 19 key stakeholders and business managers to a three-day offsite retreat. While the retreat started off as a gripe session, the members eventually made the decision that the project would have to be started over. The project team had lost sight of the big picture of how the various components would fit together. It was decided that the project would begin again with defining the business requirements before trying to fit the business into a mold that had to be completed by a predetermined deadline. Perhaps more importantly, they concluded that they required support from key divisional managers and that better communication was needed to tell all the employees when changes were taking place, when, why, and how.

By the following April, the project team had a well defined plan to follow. By May, Tom James was hired as director of process change and was responsible for acting as a liaison between the project team and the various divisions. James was shocked by the still poor relationships between the project team and divisions, so he and Dunn began meeting face to face with the division managers and started conducting regular surveys better to understand how the employees were affected by the new systems and how they were coping with the changes.

One difference was Dunn and the project team would act on what they found. For example, a rollout of a new comanufacturing package was delayed six months because feedback from the users suggested that they would not be prepared to make the process changes in time.

Although this project took much longer than expected, Dunn is not ashamed of the schedule overrun or the numerous deadends. She believes that slow and steady wins the race, and that the project has already achieved a significant return on investment, especially in terms of better demand forecasting. According to Dunn, "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 that number again."

Now, SAP provides common databases and processes that allow for demand forecasts to be more accurate. Since all of Nestlé USA is using the same data, it can forecast down to the distribution center level. Subsequently, inventory levels and redistribution expenses can be reduced. The company reports that improvements in the supply chain alone have accounted for a major piece of the $325 million Nestlé has saved by implementing SAP.

Dunn reflects that if she had to do it over again, she would focus on changing the business processes, getting universal buy-in, and then and only then installing SAP. As she said, "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."

What could Nestlé have done better in implementing SAP?

What did it do right?

What would have been the value of having a change management plan from the beginning?

The primary lesson that Dunn says she gained from this project is "No major software implementation is really about the software. It"s about change management." Do you agree with her statement?