Project REPORT OF ERP ON NESTLE

Submitted to
Abdul Majid Khan Submitted fromAnkit Gagneja(FT-10- ) Prashant Mishra (FT-10-981) Vishal Moudgil (FT-10-)

Type of organization (nestle)

Manufacturing and Product based organization.

Functional Area in the organization where it wanted to implement the ERP package
Whole organization

WHAT IS ERP?
Enterprise resource planning software, or ERP, doesnt live up to its acronym. Forget about planningit doesnt do much of thatand forget about resource, a throwaway term. But remember the enterprise part. This is ERPs true ambition. It attempts to integrate all departments and functions across a company onto a single computer system that can serve all those different departments particular needs. That is a tall order, building a single software program that serves the needs of people in finance as well as it does the people in human resources and in the warehouse. Each of those departments typically has its own computer system optimized for the particular ways that the department does its work. But ERP combines them all together into a single, integrated software program that runs off a single database so that the various departments can more easily share information and communicate with each other. That integrated approach can have a tremendous payback if companies install the software correctly. Take a customer order, for example. Typically, when a customer places an order, that order begins a mostly paper-based journey from in-basket to in-basket around the company, often being keyed and rekeyed into different departments computer systems along the way. All that lounging around in baskets causes delays and lost orders, and all the keying into different computer systems invites errors. Meanwhile, no one in the company truly knows what the status of the order is at any given point because there is no way for the finance department, for example, to get into the warehouses computer system to see whether the item has been shipped. "Youll have to call the warehouse" is the familiar refrain heard by frustrated customers. ERP vanquishes the old standalone computer systems in finance, HR, manufacturing and the warehouse, and replaces them with a single unified software program divided into software modules that roughly approximate the old standalone systems. Finance, manufacturing and the warehouse all still get their own software, except now the software is linked together so that someone in finance can look into the warehouse software to see if an order has been shipped. Most vendors ERP software is flexible enough that you can install some modules without buying the whole package. Many companies, for example, will just install an ERP finance or HR module and leave the rest of the functions for another day.

How can ERp impRovE a companys businEss performance?

ERPs best hope for demonstrating value is as a sort of battering ram for improving the way your company takes a customer order and processes it into an invoice and revenueotherwise known as the order fulfillment process. That is why ERP is often referred to as back-office software. It doesnt handle the up-front selling process (although most ERP vendors have developed CRM software or acquired pure-play CRM providers that can do this); rather, ERP takes a customer order and provides a software road map for automating the different steps along the path to

fulfilling it. When a customer service representative enters a customer order into an ERP system, he has all the information necessary to complete the order (the customers credit rating and order history from the finance module, the companys inventory levels from the warehouse module and the shipping docks trucking schedule from the logistics module, for example). People in these different departments all see the same information and can update it. When one department finishes with the order it is automatically routed via the ERP system to the next department. To find out where the order is at any point, you need only log in to the ERP system and track it down. With luck, the order process moves like a bolt of lightning through the organization, and customers get their orders faster and with fewer errors than before. ERP can apply that same magic to the other major business processes, such as employee benefits or financial reporting. That process may not have been efficient, but it was simple. Finance did its job, the warehouse did its job, and if anything went wrong outside of the departments walls, it was somebody elses problem. Not anymore. With ERP, the customer service representatives are no longer just typists entering someones name into a computer and hitting the return key. The ERP screen makes them businesspeople. It flickers with the customers credit rating from the finance department and the product inventory levels from the warehouse. Will the customer pay on time? Will we be able to ship the order on time? These are decisions that customer service representatives have never had to make before, and the answers affect the customer and every other department in the company. But its not just the customer service representatives who have to wake up. People in the warehouse who used to keep inventory in their heads or on scraps of paper now need to put that information online. If they dont, customer service reps will see low inventory levels on their screens and tell customers that their requested item is not in stock. Accountability, responsibility and communication have never been tested like this before. People dont like to change, and ERP asks them to change how they do their jobs. That is why the value of ERP is so hard to pin down. The software is less important than the changes companies make in the ways they do business. If you use ERP to improve the ways your people take orders, manufacture goods, ship them and bill for them, you will see value from the software. If you simply install the software without changing the ways people do their jobs, you may not see any value at allindeed, the new software could slow you down by simply replacing the old software that everyone knew with new software that no one does.

BENEFITS OF ERP
There are five major reasons why companies undertake ERP:
1.

Integrate financial informationAs the CEO tries to understand the companys overall performance, he may find many different versions of the truth. Finance has its own set of revenue numbers, sales has another version, and the different business units may each have their own version of how much they contributed to revenues. ERP creates a single version of the truth that cannot be questioned because everyone is using the same system.

2. Integrate customer order informationERP systems can become the place where the Customer order lives from the time a customer service representative receives it until the loading Dock ships the merchandise and finance sends an invoice. By having this information in one Software system, rather than scattered among many different systems that cant communicate With one another, companies can keep track of orders more easily, and coordinate manufacturing, Inventory and shipping among many different locations at the same time.

3. Standardize and speed up manufacturing processes Manufacturing companies especially those with an appetite for mergers and acquisitionsoften find that multiple business units across the company make the same widget using different methods and computer systems. ERP systems come with standard methods for automating some of the steps of a manufacturing Process. Standardizing those processes and using a single, integrated computer system can save Time, increase productivity and reduce head count. 4. Reduce inventoryERP helps the manufacturing process flow more smoothly, and it improves visibility of the order fulfillment process inside the company. That can lead to reduced inventories of the stuff used to make products (work-in-progress inventory), and it can help users better plan deliveries to customers, reducing the finished goods inventory at the warehouses and shipping docks. To really improve the flow of your supply chain, you need supply chain software, but ERP helps too. 5. Standardize HR informationEspecially in companies with multiple business units, HR may not have a unified, simple method for tracking employees time and communicating with them about benefits and services. ERP can fix that.

Why do ERP projects fail so often?

At its simplest level, ERP is a set of best practices for performing different duties in your company, including finance, HR, manufacturing and the warehouse. To get the most from the software, you have to get people inside your company to adopt the work methods outlined in the software. If the people in the different departments that will use ERP dont agree that the work methods embedded in the software are better than the ones they currently use, they will resist using the software or will want IT to change the software to match the ways they currently do things. This is where ERP projects break down. Political fights break out over howor even whetherthe software will be installed. IT gets bogged down in long, expensive customization efforts to modify the ERP software to fit with powerful business barons wishes . Customizations make the software more unstable and harder to maintain when it finally does come to life. The horror stories you hear in the press about ERP can usually be traced to the changes the company made in the core ERP software to fit its own work methods. Because ERP covers so much of what a business does, a failure in the software can bring a company to a halt, literally. But IT can fix the bugs pretty quickly in most cases, and besides, few big companies can avoid customizing ERP in some fashionevery business is different and is bound to have unique work methods that a vendor cannot account for when developing its software. The

mistake companies make is assuming that changing peoples habits will be easier than customizing the software. Its not. Getting people inside your company to use the software to improve the ways they do their jobs is by far the harder challenge. If your company is resistant to change, then your ERP project is more likely to fail. One cautionary tale that came to light in 2008 illustrates that sometimes there is a big difference between what an ERP vendor promises to deliver in its software and what actually is ready for primetime enterprise use. Trash-disposal Company Waste Management announced in March 2008 that it was suing SAP, seeking the recovery of $100 million in project expenses that related to a failed ERP implementation that had started in 2005. In the complaint, Waste Management alleges that SAP executives participated in a fraudulent sales scheme and that SAP's Waste and Recycling ERP product was actually "fake software" that was still not ready for Waste Management's use by spring 2008. Some reasons of failure of ERP Software are as follows (1) Lack of Top Management Commitment The propensity of top management to delegate the oversight of an ERP implementation to lower management levels often results in (a) Being "out of touch" with critical events, or (b) The lack of understanding of the size, scope, and technical aspects of the project, and subsequently, the lack of proper commitment of time and resources required for a successful implementation. The result is a failure waiting to happen. (2) Inadequate Requirements Definition Surveys have shown that inadequate definition of functional requirements accounts for nearly 60% of ERP implementation failures. This is simply a matter of not comprehensively and systematically developing a quality set of functional requirements definitions. This leads to the second greatest cause of ERP implementation failures: poor package selection. (3) Poor ERP Package Selection Poor package selection occurs when a company has inadequately developed functional requirements definitions. It also occurs when staff members assigned to ERP projects do not take the time to run the screens of the new system, as they would during their daily work tasks, to find out if the software package features are adequate for their needs. Another reason we have found is executives, familiar with an ERP system from a last job they held, implement the same system in their new company without defining functional requirements. We have also encountered companies who made major gaffes by selecting a package at the top levels of a company without intimately knowing its characteristics. What often results from this is the ERP package doesn't fit the organizational needs, or that the package selected takes longer to process daily work tasks. We have also seen executives select a distribution package for a manufacturing environment, or a manufacturing package for a distribution environment, for obscure reason, such as liking one salesman over another. (4) Inadequate Resources The third greatest reason for ERP implementation failures is inadequate resources. Many

companies will attempt to "save dollars" by doing everything on an overtime basis, whether or not there are adequate skills within the company, extending individual work loads to 150%. This approach can be a "kiss of death" for the program. Time and time again we run across this mistake in ERP implementations. The financial and emotional drain of what seems sometimes to be perpetual extensions, reschedules and delays of implementations takes its toll. People burn out after having put in extensive hours over a long period of time. (5) Resistance to Change/Lack of Buy-in The lack of a change management approach as part of the program can prevent a program from succeeding. Resistance to change is quite often caused by (a) A failure to build a case for change, (b) Lack of involvement by those responsible for working with changed processes (c) Inadequate communication (d) Lack of visible top management support and commitment, and (e) Arrogance A lack of buy-in often results from not getting end-users involved in the project from the very start, thereby negating their authorship and ownership of the new system and processes. (6) Miscalculation of Time and Effort Another cause of ERP implementation failure is the miscalculation of effort and time it will take to accomplish the project. Companies who treat an ERP selection, evaluation and implementation comparable to buying a washing machine are doomed to failure. (7) Misfit of Application Software with Business Processes One of the main causes of ERP implementation failure is the misfit of application software with the company business processes. This failure -- to examine underlying business process flaws, and integrate the applications with the business processes, causes loss of productivity and time, and ultimate benefits. (8) Unrealistic Expectation of Benefits and ROI Another significant cause for ERP implementation failure is the unrealistic expectation of benefits and return on investment. Software providers are notorious for overstating the benefits in terms of ROI, when the total costs of the project have been understated. Often left out of the total costs are costs of planning, consulting fees, training, testing, data conversions, documentation, replacement staffing, and the learning curve performance drop. When this happens, a company doesn't stand a chance of achieving the ROI it anticipated. (9) Inadequate Training and Education Another of the biggest causes of ERP implementation failure is inadequate education and training, which are almost always underestimated. ERP-related training is crucial as most

employees must learn new software interfaces and business processes which affect the operation of the entire enterprise. The corporate culture is impacted by changes in the companys business processes, and shortchanging this part of the ERP implementation leads to much pain and suffering downstream. (10) Poor Project Design and Management A major mistake is to short-cut critical events in the project plan, such as time for documentation, redefining and integrating processes, or testing before "going live." Another common mistake is made when a company leaves out the self-examination of business processes and uses ERP to cover-up weaknesses. It is easier to buy software than to perform the more difficult task of identifying weaknesses and opportunities for improvement. (11) Poor Communications One of the causes of ERP implementation failure is poor project communications, beginning with a failure to announce the reason for the up and coming effort, and continuing to advise the organization of the progress and importance of the ERP implementation to the company. Poor communications prevent different parts of the organization from assessing how they will be impacted by changes in processes, policies, and procedures. Communications are a vital part of managing change in a corporate environment. 12) Ill-Advised Cost Cutting Another of the key causes of ERP implementation failure is ill-advised cost cutting. In an effort to avoid temporary conversion costs, some companies take a very risky route and go live at multi-plant sites simultaneously; subjecting all plants or some plants to a total shutdown should there be a false start-up. This is suicidal. Others attempt to unrealistically compress the schedule in order to save on expenses, only to eventually overrun both schedule and budget. We feel that ROI should take a "back seat" when upgrading an important part of a company's infrastructure: the information system. Instead the implementation should be treated as an upgrade to the company infrastructure that is necessary to maintain or gain a strategic and competitive advantage.

Implementation of ERP Package in Nestle

Even before three of the SAP and the Manugistics modules were rolled out in late 1999, there was rebellion in the isn't ranks. Much of the 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 employeesand even angrierdidn'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 modulessales and distribution on the domestic side, and accounts receivableas 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 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 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 dont 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. For most businesses there needs to be a middle-of-theroad 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.

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. 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. This was only the start of Nestle USAs 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. 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.

Nestle USAs 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.

By June 2000, Nestle USA was forced to halt the rollout and the project manager was removed from the project and reassigned to Switzerland. 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. 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 division. 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.

Results
Although there were bumps in the road for Nestle USAs 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. 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 dont know what the hell they are talking about; Im going to give them this number. The demand planner turns [that number] over to factory, and the factory says the demand planner doesnt know what the hell hes 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.

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. Further, like their American counterpart, Nestle UK has experienced reduced inventory levels, tighter control on inventory, and a more disciplined attitude toward business processes. Most importantly, the ERP implementation at Nestle UK helped to foster a culture of continuous improvement. Improvement priorities are clear: first, the internal opportunities; second, business-to-business; and third, business to consumer. This attitude is embodied by the fact that following the ERP rollout they hired a process development manager. This persons 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.

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-today 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 organizations needs or the organizations 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 reengineered 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, [theyd] 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.

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 organizations ability to rally and work together during difficult times to reach an end goal that will eventually make everyones job easier and the company more competitive.