NESTLÉ'S ERP ODYSSEY

IN JUNE 2000, Nestlé SA signed a much publicized $200 million contract with SAP—and threw in an additional$80 million for consulting and maintenance—to install an ERP system for its global enterprise. The Switzerland-based consumer goods giant intends to use the SAP system to help centralize a conglomerate that owns 200 operating companies and subsidiaries in 80 countries.

Not surprisingly, a move of this magnitude sparked skepticism. Anne Alexandre, an analyst who covers Nestlé for HSBC Securities in London (the company is traded only in Europe), downgraded her recommendation on Nestlé stock a year after the project was announced. While she says that the ERP system will likely have long-term benefits, she is wary of what the project will do to the company along the way. "It touches the corporate culture, which is decentralized, and tries to centralize it," she says. "That's risky. It's always a risk when you touch the corporate culture."

It is a risk that Jeri Dunn, vice president and CIO of Nestlé USA, the $8.1 billion U.S. subsidiary, knows all too well. In 1997, the Glendale, Calif.-based company embarked on an SAP project code-named Best (business excellence through systems technology). By the time it reaches the finish line, Best will have gobbled up six years and more than $200 million (the same amount its global parent intends to spend). Dunn now says she sees the light at the end of the tunnel. The last rollouts will take place in the first quarter of 2003. But the implementation has been fraught with dead ends and costly mistakes. It is a cautionary tale, full of lessons not only for its Swiss parent but for any Fortune 1000 company intent on an enterprisewide software implementation.

"I took eight or nine autonomous divisions and said we are going to use common processes, systems and organization structures," says Dunn. "[Nestlé SA is] looking at 80 autonomous countries and saying the same thing. They're just taking it up a notch. If they go in with an attitude that there's not going to be resistance and pain, they're going to be disappointed."

Nestlé's global SAP project, which is tied in to a larger $500 million hardware and software data center rehaul, will be integrated with its American subsidiary's soon-to-be completed ERP. And Dunn is even lending 70 of her own staffers for the global initiative, as well as some of her hard-won expertise. But while the verdict is still out on the global project, the pain—angry employees, costly reengineering and long periods when it seemed the project would never end—was worth it for Nestlé USA, Dunn says. To date, she claims, the Best project has saved the company $325 million. (Because Nestlé is headquartered outside the United States, it doesn't have to disclose its financial information to the SEC.)

Regardless of the project's exact ROI, the lessons learned are real. The primary lesson Dunn says she has taken away from the project is this: No major software implementation is really about the software. It's about change management. "If you weren't concerned with how the business ran, you could probably [install the ERP software] in 18 to 24 months," she says. Then "you would probably be in the unemployment line in 19 to 25 months."

Nestlé learned the hard way that an enterprisewide rollout involves much more than simply installing software. "When you move to SAP, you are changing the way people work," Dunn says. "You are challenging their principles, their beliefs and the way they have done things for many, many years."

The Problem:
29 Brands of Vanilla
Vanilla may be the world's least exciting ingredient—the word is even a synonym for bland. But that wasn't the case at Nestlé USA, where vanilla represented a piquant plethora of inefficiencies and missed opportunities.

Before 1991, Nestlé was simply a collection of independently operating brands, such as Stouffer's and Carnation, owned by the Swiss-based parent. In 1991, the brands were unified and reorganized into Nestlé USA. Even so, the new company continued to function more like a holding corporation than a single entity. Divisions still had geographically dispersed headquarters and were free to make their own business decisions, although they now reported to corporate Nestlé USA executives in Glendale rather than in Vevey, Switzerland. The new company was trying to introduce economies of scale and common practices, but years of autonomous operation proved an almost insurmountable hurdle.

In 1997, a team examining the various systems across the company found, among many other troubling redundancies, that Nestlé USA's brands were paying 29 different prices for vanilla—to the same vendor. "Every plant would buy vanilla from the vendor, and the vendor would just get whatever it thought it could get," Dunn says. "And the reason we couldn't even check is because every division and every factory got to name vanilla whatever they 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."

While the American brands were willing to go about their business as autonomous companies—headaches be damned—the Swiss parent knew that similar problems would continue. In 1991, the same year that Nestlé USA was created, Dunn, then associate director for application systems of Stouffer's Hotels, one of the many Nestlé brands, went to Switzerland to help implement a common methodology for Nestlé projects worldwide. In 1995, she was promoted to assistant vice president of technology and standards for Nestlé SA, where she came up with technology standards for every Nestlé company to follow. Dunn figured that common systems across the Nestlé empire would create savings through group buying power and facilitate data sharing between subsidiaries.

Yet when Dunn returned stateside to take the more hands-on CIO job at Nestlé USA in 1997, she found that few of her recommendations had been acted on. "My team could name the standards, but the implementation rollout was at the whim of the businesses," she says during a recent interview in her sparsely decorated fourth floor office in Glendale. Dunn takes cigarette breaks at every possible opportunity and isn't afraid to dress in a leopard-print skirt and blouse. At 47, she is a survivor who is refreshingly open about her mistakes and is respected throughout the company. Her staff speaks of her in almost reverential tones.

The Proposal:
One Nestlé, Under SAP
Dunn's arrival in spring 1997 came a few months after Nestlé USA Chairman and CEO Joe Weller coined the term One Nestlé to reflect his goal of transforming the separate brands into one highly integrated company. In June, Dunn joined with executives in charge of finance, supply chain, distribution and purchasing to form a key stakeholders team and study what was right and wrong with the company. When the time came, the key stakeholders were initially allotted a little over two hours to present their findings to Weller and other top Nestlé officials.

The team balked at the time limit. "I told them that they would either throw me out in the first 15 minutes or they would cancel the rest of the day, and we would really have a great discussion," says Dick Ramage, Nestlé USA's vice president of supply chain and a member of the team. "It took them an hour, but they canceled the rest of the day."

"I don't think they knew how ugly it was," says Dunn, referring to the company's condition. "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 own vendor masters and purchased on their own."

Soon the stakeholders team presented Weller with a blueprint for major changes they thought could be made in three to five years. While the cornerstone of the recommendation was an SAP package, Dunn says, "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 did business. There was going to be pain involved, it was going to be a slow process, and this was not a software project."

Despite that warning, it would later become apparent that neither Weller nor the key stakeholders really understood the degree to which the Best project would change the business processes at Nestlé or the amount of pain it would cause. "They still thought that it was just about software," Dunn says.

By October 1997, a team of 50 top business executives and 10 senior IT professionals had been assembled to implement the SAP project. The team's goal was to come up with a set of best practices that would become common work procedures for every Nestlé division. All the divisional functions—manufacturing, purchasing, accounting and sales—would have to give up their old approaches and accept the new pan-Nestlé way.

On the technical side, a smaller team spent 18 months examining every bit of item data in each division in order to implement a common structure across the company. From now on, vanilla would be code 1234 in every division. The SAP system would be customized around the uniform business processes. In the case of the supply chain, the team decided not to use SAP because the ERP company's supply chain module, Advanced Planner and Optimizer or APO, was brand-new and therefore risky. Instead, Nestlé turned to Manugistics—at that time an SAP partner. Manugistics' supply chain module followed all the SAP standards and could easily be integrated.

By March 1998 the key stakeholders had a plan in place. Nestlé would implement five SAP modules—purchasing, financials, sales and distribution, accounts payable and accounts receivable—and the Manugistics' supply chain module. Each would be deployed across every Nestlé division. For instance, the purchasing group for confections would follow the same best practices and data as the purchasing group for beverages.

Development work began in July 1998. The deadline for four of the modules was Y2K. The new systems would have to double as code fixes and be in place for the millennial change. Nestlé USA made the deadline. But its haste created almost as many problems as it solved.

The Process:
Nestlé's Crunch
Even before three of the SAP and the Manugistics modules were rolled out in late 1999, there was rebellion in the ranks. Much of the
Even before the SAP modules were rolled out, there was rebellion in the ranks.

employee resistance could be traced to a mistake that dated back to the project's inception: None of the groups that were going to be directly affected by the new processes and systems were represented on the key stakeholders team. Consequently, Dunn says, "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." Dunn calls that her near fatal mistake.

By the beginning of 2000, the rollout had collapsed into chaos. Not only did workers not understand how to use the new system, they didn't even understand the new processes. And the divisional executives, who were just as confused as their employees—and even angrier—didn't go out of their way to help. Dunn says her help desk calls reached 300 a day. "We were really naive in the respect that these changes had to be managed," she admits now.

Nobody wanted to learn the new way of doing things. Morale tumbled. Turnover among the employees who forecast demand for Nestlé products reached 77 percent; the planners simply were loath or unable to abandon their familiar spreadsheets for the complex models of Manugistics.

A technical problem soon emerged as well. In the rush to beat the Y2K deadline, the Best project team had overlooked the integration points between the modules. All the purchasing departments now used common names and systems, and followed a common process, but their system was not integrated with the financial, planning or sales groups. A salesperson, for example, may have given a valuable customer a discount rate and entered it into the new system, but the accounts receivable department wouldn't know about it. So when the customer paid the discounted rate, it would appear to the accounts receivable operative as though the invoice were only partially paid. In its haste to unify the company's separate brands, the project team had essentially replaced divisional silos with process silos.

In June 2000 the project was halted. The company removed Marc Richenderfer as project coleader and gave Dunn full responsibility. (Richenderfer was reassigned to work in Switzerland.) It was time for self-examination. In October 2000, Dunn gathered 19 Nestlé USA key stakeholders and business executives for a three-day offsite at the DoubleTree Hotel in Pasadena, Calif., about 10 miles from Nestlé headquarters.

Jose Iglesias, director of information systems, says the retreat started off as a gripe session. The time constraints necessitated by Y2K had put too much pressure on the people in charge of executing the changes. The project team had lost the big picture of how the various components would work together. And there was still work to be done. The existing modules had to be integrated and the team still needed to roll out two more SAP modules—sales and distribution on the domestic side, and accounts receivable—as well as a new module for the supply chain. Since Dunn had rejected the SAP supply chain module two years before, it had improved and been named a Nestlé global standard by Dunn's old standards group in Switzerland. So she decided to replace all but a couple of parts of the Manugistics system with APO. Dunn estimates that last-minute switcheroo accounted for 5 percent of Best's $210 million cost.

The offsite group members eventually decided that to finish the project they would need to begin at the beginning, starting with the business requirements then reaching an end date, rather than trying to fit the project into a mold shaped by a predetermined end date. They also concluded they had to do a better job of making sure that they had support from key divisional heads and that all the employees knew exactly what changes were taking place, when, why and how.

The End Game:
Sadder But Wiser
By April 2001, the end-state design was complete, giving the project team a highly detailed road map to follow. A month later, Tom James came on board as director of process change for the Best project, having the sole responsibility of acting as a liaison between the divisions and the project team. James says that he was shocked by the still poor relationship between the divisions and the project team. He and Dunn began meeting with more of the division heads. They also started conducting regular surveys of how the employees affected by the new systems were dealing with the changes.

They were not afraid to react to what they found. Dunn says that Nestlé recently delayed the rollout of a new comanufacturing package for six months based on feedback indicating that the would-be users were not prepared to make the process changes that were involved.

ERP projects are notorious for taking a long time and a lot of money. Jennifer Chew, an analyst at Cambridge, Mass.-based Forrester Research, found that 54 percent of respondents to a recent survey said that their project lasted more than two years (the other 46 percent brought theirs to fruition in less than two years). Nestlé USA's project "sounds on the high side" for both time and money, says Chew. Still, success is ultimately measured by what the project accomplishes. Chew points out that Kmart had to write off $130 million for an ERP project that was never completed.

Dunn herself is not ashamed of the length of the project or the numerous dead ends. She insists that slow and steady wins the race. Nestlé USA has already achieved significant ROI, she says, with the largest chunk of savings from better 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,''' Dunn says. "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 Nestlé products. Furthermore, because all of Nestlé USA is using the same data, Ramage says, Nestlé can forecast down to the distribution center level. That allows the company to reduce inventory and the redistribution expenses that occur when too much of a product is sent to one place and not enough to another. Ramage says that supply chain improvements accounted for a major chunk of the $325 million Nestlé says it has saved from SAP.

If Dunn were to do it over again, she'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," she says. "And there is a big difference between installing software and implementing a solution."

2000年6月，总部位于瑞士的食品巨头雀巢公司与SAP签署了一份价值2亿美元的合同，此后又追加8000万美元用于咨询和维护，在世界范围内推进ERP项目，加强对全球80多个国家的200个多家分公司和分支机构的管理。

理智的分析家都深知，实施ERP未必是好消息，雀巢的大动作也受到了资本市场的怀疑，雀巢宣布实施全球ERP一年之后，跟踪雀巢股票走势的恒生银行分析师安妮·亚历山德拉对雀巢股票做了降级处理，她认为，从长远意义来看，ERP系统可能会给雀巢带来好处，但就中短期影响而言，她建议投资者持保守谨慎的态度，因为"这个项目试图实行集权化管理，将触及原来分散式的企业文化，这样做的风险很大，一旦触及公司文化的深层，风险就会不期而至。"

美国分公司打头阵

实际上，雀巢实施ERP并非一时的心血来潮，而是美国分公司打完头阵之后的大部队集体行动。
雀巢美国分公司总部位于加州的格伦代尔，员工数约为16000人，去年营业收入为81亿美元，拥有雀巢公司旗下的众多品牌，有饮料部、糖果与快餐部、食品服务部、外贸部、营养品部、精制食品部、销售部等7大业务部门。

1997年，SAP帮助雀巢美国分公司实施ERP项目，代号取为BEST（Business Excellence through Systems Technology），预计需要6年时间，预算成本为2.1亿美元（与后来母公司ERP投资相当），初步定于2003年第一季度收工。雀巢美国分公司副总裁兼CIO杰丽·杜恩喘了一口长气，似乎经过漫长黑暗的穿行之后，终于看到了隧道尽头的光明。不过，雀巢美国分公司ERP的实施远非一帆风顺，其间数度遭遇无法解开的死结，犯下了若干代价沉重的错误。在管理最规范、IT支持系统最发达的美国分公司尚且如此，在全球其他分公司推行ERP的难度就更来不得盲目乐观。实际上，雀巢的ERP之旅非常值得业界深思，得到的教训不仅仅应该引起母公司的警戒，对于其他急于上马ERP项目的公司也有非常强烈、现实的借鉴意义。

杜恩说，"我负责（美国分公司）八九个自治的分支机构，让它们采用通用的流程、系统和组织结构，总公司则要管理80多个国家的分公司，做同样的事情，它们只是级别高一些罢了。如果它们抱着一种很乐观的心态，觉得不会遇到抵触和痛苦，那么以后它们会失望的。"

雀巢全球ERP项目将投入5亿美元，用于升级硬件、软件和数据中心，然后再与即将完工的美国分公司ERP集成到一起。杜恩已经将其手下70余名员工借调去参加母公司的全球项目，利用他们来之不易的经验、教训，避免再犯重复错误、少走弯路。雀巢美国分公司实施ERP的过程虽然非常痛苦──员工抱怨甚至愤怒、再造工程成本昂贵、项目实施没完没了，但杜恩认为还是很值的，截止到目前为止，BEST项目已经为美国分公司节省了3.25亿美元的开支（雀巢总部不在美国，不必向SEC披露财务信息，所以具体的官方数字不详）。

即使不考虑BEST项目的投资回报，雀巢从ERP实施中学到的经验和教训也是一笔无价之宝，杜恩认为她从这个项目中得到的最大教训就是：重大软件项目的实施其实不是软件的事，而是如何管理变革，"如果不管业务的运作情况，单安装ERP软件18至24个月内就完全可以搞定，不过呢，第19至25个月你可能就得准备下岗。"

有些道理听起来很浅显明白，但只有用身心经历过才知道其深刻和刻骨铭心。雀巢通过自己艰难的实践，体会到实施全球ERP不只是简单的软件安装，就如杜恩所说的那样，"上马ERP的时候，你正在试图改变人们传统的工作方式，挑战他们的原则、信念以及延续了多年的做事风格。"

29个品牌的香草

香草可能是世界上最不够刺激的东西，其英文单词就有"刺激性少"之意，但在雀巢美国分公司，香草却非常刺激，因为它刺激了雀巢领导们麻木的神经，提醒他们雀巢的运行效率曾经多么地低下，曾经错失了多少良机！

1991年之前，雀巢只是一些独立运营公司的混合体，产品品牌归瑞士母公司所有。1991年，雀巢美国分公司成立，品牌管理被统一重组到这家新公司，尽管如此，它仍然只相当于一家控股公司，而不是一个完整的统一体。虽然各个分支机构都需要向雀巢美国分公司报告工作，但它们各自的地理位置很分散，商业决策也有相当大的自主权，完全是"诸侯割据，各霸一方"的局面。雀巢美国分公司曾试图引入一些通用做法，整合分散的组织，实现规模经济，提高运作效率，但是，多年的自治运营成为了一道不可逾越的障碍。

1997年，一个特别小组对雀巢美国分公司的各种系统进行了检查，结果发现，管理极其混乱，为一个供应商的香草居然支付29种不同的价格！每个工厂都从这家供应商处购买香草，但互不通信，所以供应商就随心所欲地开口要价，以前没有注意到这一点的原因是，每家分支机构和工厂都根据自己的意愿给香草编制代号，甲可能编为1234，后面有一套规范说明，乙可能编为7778，公司根本就没法进行比较。

更头疼的是，各个分支机构还特别喜欢自治式的业务运营，母公司早就知道这个问题，所以在1991年成立了雀巢美国分公司，统一品牌管理，以期达到"削藩"的效果。当时杜恩是雀巢著名品牌Stouffer's Hotels应用系统的副主管，被召集到瑞士帮助设计公司全球项目的通用方法，制定每家分公司都要遵循的技术标准，以便将来借助集团购买力实现节流的目的，并增进各个分支机构间的数据共享。

1997年，杜恩返回美国，出任雀巢美国分公司的CIO，这个时候，她才发现一件很尴尬的事，在瑞士总部制定的那些建议很少有被采用的，做标准的只管做标准，而不管实施，总部对实施标准也只是兴之所至的时候强调一下，然后就把它给扔到遗忘的角落去了。

用ERP"统一"雀巢帝国

1997年春天杜恩回美国之前，雀巢美国分公司主席兼CEO乔·韦勒提出了"统一雀巢"的口号，志在将各个分散的品牌整合到一个高度统一的公司中。6月，杜恩和主管财务、供应链、渠道及采购的高级经理组成了一个主要利益相关者小组，研究公司哪些地方做的好哪些地方做错了，然后将发现的结果报告给韦勒及其他高层领导。

杜恩说，"我觉得他们根本就不知道实际情况有多糟糕，我们有9个不同的分类帐务，28点客户条目，我们有很多采购系统，对于跟某家供应商做了多少笔交易，连我们自己都不清楚，因为每家工厂都有自己的采购组，只根据自己的需要进行采购。"

他们很快就给韦勒拿出了一份蓝图，列出了他们认为在三至五年内可以获得重大改进的地方，建议采用SAP的ERP系统重整公司业务流程，杜恩说，"我们非常清楚，这将是一次业务流程再造，如果不改变业务运行模式，就无法达到预期的目标，后面会更痛苦、更艰难、更缓慢，这不是一个软件项目。"

尽管在实施之前就打了这样的"预防针"，后来的事实仍证明，无论韦勒还是那些参与方案制定的主要利益相关者，他们都没有真正理解BEST项目将如何改变雀巢公司的业务流程以及可能导致的痛苦程度，因为他们把ERP当成了一个纯软件项目。

1997年10月，雀巢美国分公司召开ERP项目誓师大会，由50名高层业务经理和10名高级IT专家组成实施小组，目标是制定一套对公司各个分支机构都适用的通用工作程序，所有部门的功能──制造、采购、会计、销售等，都必须抛弃过去的旧方式，接受新的"泛雀巢"思维。

还有一个技术小组用了18个月的时间，检查各个部门的所有条目数据，考虑如何实现一个全公司通用的结构，从那时起，各个分支机构的香草代码都被编为1234。ERP系统可以根据统一的业务流程，在各个部门被定制化，例如，在供应链一环，小组并没有使用SAP的产品，因为SAP的供应链管理模块理念太新，隐藏的风险太大，雀巢转向SAP的合作伙伴Manugistics，这家公司的供应链模块遵循SAP的标准，可以很容易地集成到SAP的ERP系统中。

1998年3月，ERP项目已经有了眉目，首先实施SAP的5个模块──采购、财务、销售与配送、应收帐款与接收帐款，以及Manugistics的供应链模块，每个分支机构都将采用这五大模块，例如，糖果部采购组和饮料部采购组使用的最佳准则和数据是一样的。

天下大乱

开发工作始于1998年7月，其中四个模块（三个SAP模块和Manugistics模块）要求在2000年之前完成。虽然事先制定了进度表，但由于一些代码修改及千年虫问题，在匆忙完成既定任务的同时，又出现了大量的新问题，最大的问题是，反叛心理在不同阶层中开始滋生。员工的抵制情绪源于项目启动时犯下的一个重要错误：主要利益相关者小组中没有来自那些受到新系统和业务流程直接影响的团体的代表。所以，结果就如同杜恩所描述的那样，"我们总是令销售部和其他部门的领导大吃一惊，因为我们带给他们的东西与他们并没有实质性的利害关系。"杜恩称之为她犯下的近乎致命的错误。

2000年初，项目实施陷入混乱，工人不知道如何使用新系统，甚至连新的工作流程都不明白，没有人想学习业务运作的新方式，公司士气低落，预测产品需求的员工流动率高达77%，计划制定者不情愿、也无法抛弃熟悉的电子表格，而转向复杂的Manugistcis模块，部门主管和他们手下人一样迷茫。抱怨增多的时候，ERP实施出现停滞甚至撤退。杜恩当时每天接到的求助电话都高达300个，她现在承认，"我们当时真是幼稚，居然认为这些变革是可管理的。"

很快又出现了一个技术问题。由于解决千年虫问题的时间非常紧迫，那些负责推进改革的人面临很大的压力，项目小组在匆忙之中忽略了模块之间的集成点，一时陷入迷茫，不知道如何将各个部分实现协同工作。虽然所有采购部门都使用通用的代码和系统，遵循通用的过程，但它们的系统并没有跟财务部、计划部和销售部集成在一起。例如，一名销售人员可能已经给一个很有价值的大客户打了一个折扣，然后将结果输入到新系统，但帐务接收人员却不知晓，当该客户按折扣率付款之后，帐务接收人员却以为它只支付了一部分款项，还有欠款。原来的品牌管理过于散乱，而过程整合又很匆忙，项目组在推进过程做法的时候，忽略了部门之间的整合工作。

2000年6月，项目搁浅，公司撤消另一联合组长的职务，将其分配到瑞士总部工作，由杜恩全面负责雀巢美国分公司的ERP。这个强烈的信号充分显示出总部对美国分公司ERP工作的不满。2000年10月，杜恩召集雀巢美国分公司的19名主要利益相关者和业务主管，在一个宾馆开了三天检讨会。

经过激烈的讨论，小组成员最后决定，从需要重新开始的地方重新再来，先分析业务需求，再制定结束日期，而不是像以前那样将项目套进一个预先设定结束日期的模子。他们还得出两点结论，首先必须确保得到主要部门领导的支持，其次要确保所有的员工都确切知道正在发生什么变化，何时、为什么及如何发生的。

结局：痛苦但却划算

2001年4月，规划设计结束，项目小组有了一套可遵循的详细说明方案，一个月之后，公司任命了一名流程改革主管，专门负责各个分支机构和项目小组之间的联络沟通，协同杜恩会见更多的部门领导，并定期调查员工受新系统的影响程度，以配合项目的实施。例如，雀巢最近将一个制造软件包的实施推迟了6个月，因为反馈的信息表明用户对过程变革还没有适应。

众所周知，实施ERP要花费大量的资金和漫长的时间。Forrester公司一位分析师在最近做的一项调查中发现，54%的受访者反映他们的项目持续了两年以上的时间，其他46%的在两年内初步见到成效。雀巢美国分公司的ERP项目不管从时间还是资金上，看起来都不太美妙。

杜恩是个很豁达的人，对自己犯过的错误毫不避讳，她也没有因为项目的漫长和死结无数而感到丢人。杜恩认为，搞ERP不宜采用工程性做法，慢慢来、稳扎稳打才能成功。她说，实施ERP之后，需求预测准确了，节省了大量资金，雀巢美国公司已经获得了很显著的投资回报，"过去，当一名销售员将一组数字送给需求规划人员时，经常会说，'那帮家伙根本就不知道他们在谈什么，我就把这些数字给他们'，而需求规划人员就将那组数字原封不动地给传给工厂，工厂却说需求规划者根本不知道他在说什么。"然后，工厂还要再修改这些数字。当ERP就绪之后，通用的数据库和业务流程就可以对各种产品进行高可信度的需求预测，并且，由于整个雀巢美国分公司使用的都是相同的数据，预测的准确度就可以达到配送中心一级，这样，当一个地方积压了太多的某类产品而另一个地方却不足的情况发生时，公司就可以减少库存和再配送的开支。杜恩说公司因ERP系统而节省了3.25亿美元的开支，供应链改善的贡献率相当高。

如果上天能给杜恩一次重来的机会，她将首先专注于改革业务流程、制定通用的大宗买进框架，然后再安装软件，她感触颇深地说，"如果你首先上系统的话，那就是在安装软件，而不是执行方案，安装软件和执行解决方案之间存在很大的区别。"

五大教训

雀巢ERP的实施可以说是"一路坎坷"：在第一阶段，公司匆忙设定2000年期限，而忽略了重要的整合过程；实施小组由50名高层业务主管和10名高级IT专家组成，但忽略了那些直接受到新业务流程影响的团体利益，结果用户抵制，公司士气低落，人员流动率上升，求助电话每天高达300个。2000年6月，雀巢暂停了项目的实施，从头做起，抛弃了预先设定结束日期的做法，定期调查用户对变革的反应，当有反馈信息表明需要进一步的培训适应时，推迟实施。现在，雀巢美国分公司的ERP之旅终于要画上一个并不算太圆满的句号。CIO杜恩说从中得到了很多惨痛的教训，首当其冲的就是"重大软件项目实施其实并不是软件的事。"
雀巢ERP实施五大教训：

1、不要采用工程化的做法为项目实施过程预先设定期限。应该先分析项目需求，然后确定需要多长时间实现这些需求，定期调查用户的反应情况，如有异常，暂停实施，学习适应，再继续推进。

2、定期更新预算估计。在项目实施的漫长过程中，往往会发生很多意想不到的事情，能在某一时间段基本达到预期目标就不错了，更不要说在整个实施过程中。经常检查预算可以将棘手的问题降至最少。

3、ERP不是软件的事。将一个新系统安装就绪是很容易的，真正难的是改变那些将要使用该系统的人们，使他们能适应新的业务流程。

4、没有人喜欢流程变革，尤其当他们没有思想准备的时候。那些因流程变革而受到影响的人需要特别关注，项目实施过程中应多进行交流沟通，在实施前、中、后衡量人们的接受认可度。

5、不要忘记整合。单单安装新系统是不够的，要确保各个部分能相互协同工作。