Putting the Enterprise into the Enterprise System

The Idea in Brief

What guarantees to seamlessly integrate all information flowing into and out of your company’s incompatible databases? And create unmatched customer service, reduced inventory write-offs, and increased profitability?

Enterprise resource planning systems, once known as ERPs. These technological tours de force have undeniable allure: one comprehensive database to house all your corporate information—customer, marketing, sales, production, financial, etc. When you enter new information in one place, the system automatically updates related information.

So why do so many enterprise-system initiatives fail? Why, for example, did Dow Chemical spend seven years—and half a billion dollars—implementing one system, then start over with another? Why is the use of enterprise systems proliferating, but not the benefits? Several reasons:

Dauntingly complex, enterprise software requires significant money, time, and expertise.

These systems impose their own logic on companies’ strategies, organization, and culture—often forcing firms to do business in ways that conflict with their best interests.

An enterprise package may be used by all companies in an industry—erasing their sources of differentiation and competitive advantage.

How to avoid these perils? Clarify strategic and organizational needs—and business implications of integration—before implementing.

The Idea in Practice

Consider these guidelines, illustrated with examples from Elf Atochem North America, a chemicals subsidiary of France’s Elf Aquitaine that suffered information-flow problems among its 12 business units.

Mục Lục

Clarify Your Strategy Before Planning Your Enterprise System

Example: Elf Atochem’s troubles stemmed from the company’s fragmentation, not its systems’. To place one order, customers had to call many units and process several invoices. The firm wrote off $6 million annually because of uncoordinated inventory management. Customers deserted when sales reps couldn’t promise firm delivery dates.

Executives refocused strategy on radically improving customer service. They targeted processes most distorted by fragmented organizational structures—materials and order management, production planning, financial reporting—and installed only the enterprise modules supporting those processes.

Change Organizational Structures—Not Just Computer Systems—to Address Information-Flow Problems

Combining its accounts-receivable and credit departments into one function, Elf Atochem consolidated each customer’s activities into one account. Combining all units’ customer-service departments gave customers one contact point.

Create Competitive Advantage with Your Enterprise System

Example: Elf Atochem’s enterprise system generated the real-time information necessary for connecting sales (demand) and production planning (supply). As orders enter or change, the system updates forecasts and factory schedules. Result? Production runs shift quickly based on customer needs. Only one other company in the industry has this capability.

Put the Right People in Place

Example: Computer systems without the right people don’t change organizational behavior. Elf Atochem created the demand-manager position to orchestrate sales and production planning. Using the enterprise system, this manager makes sales forecasts, updates them with new orders, assesses plant capacity and account profitability, and develops production plans. Now salespeople can guarantee orders six weeks ahead of production.

Install Your Enterprise System Gradually

Elf Atochem installed its system one business unit at a time, refining as rollout proceeded. This enabled staffing the effort mainly with insiders—reducing implementation costs and boosting employees’ understanding of the system.

Enterprise systems appear to be a dream come true. These commercial software packages promise the seamless integration of all the information flowing through a company—financial and accounting information, human resource information, supply chain information, customer information. For managers who have struggled, at great expense and with great frustration, with incompatible information systems and inconsistent operating practices, the promise of an off-the-shelf solution to the problem of business integration is enticing.

It comes as no surprise, then, that companies have been beating paths to the doors of enterprise-system developers. The sales of the largest vendor, Germany’s SAP, have soared from less than $500 million in 1992 to approximately $3.3 billion in 1997, making it the fastest-growing software company in the world. SAP’s competitors, including such companies as Baan, Oracle, and PeopleSoft, have also seen rapid growth in demand for their packages. It is estimated that businesses around the world are now spending $10 billion per year on enterprise systems—also commonly referred to as enterprise resource planning, or ERP, systems—and that figure probably doubles when you add in associated consulting expenditures. While the rise of the Internet has received most of the media attention in recent years, the business world’s embrace of enterprise systems may in fact be the most important development in the corporate use of information technology in the 1990s.

But are enterprise systems living up to companies’ expectations? The growing number of horror stories about failed or out-of-control projects should certainly give managers pause. FoxMeyer Drug argues that its system helped drive it into bankruptcy. Mobil Europe spent hundreds of millions of dollars on its system only to abandon it when its merger partner objected. Dell Computer found that its system would not fit its new, decentralized management model. Applied Materials gave up on its system when it found itself overwhelmed by the organizational changes involved. Dow Chemical spent seven years and close to half a billion dollars implementing a mainframe-based enterprise system; now it has decided to start over again on a client-server version.

The growing number of horror stories about failed or out-of-control projects should certainly give managers pause.

Some of the blame for such debacles lies with the enormous technical challenges of rolling out enterprise systems—these systems are profoundly complex pieces of software, and installing them requires large investments of money, time, and expertise. But the technical challenges, however great, are not the main reason enterprise systems fail. The biggest problems are business problems. Companies fail to reconcile the technological imperatives of the enterprise system with the business needs of the enterprise itself.

An enterprise system imposes its own logic on a company’s strategy, culture, and organization.

An enterprise system, by its very nature, imposes its own logic on a company’s strategy, organization, and culture.(See the table “The Scope of an Enterprise System.”) It pushes a company toward full integration even when a certain degree of business-unit segregation may be in its best interests. And it pushes a company toward generic processes even when customized processes may be a source of competitive advantage. If a company rushes to install an enterprise system without first having a clear understanding of the business implications, the dream of integration can quickly turn into a nightmare. The logic of the system may conflict with the logic of the business, and either the implementation will fail, wasting vast sums of money and causing a great deal of disruption, or the system will weaken important sources of competitive advantage, hobbling the company.

An enterprise system enables a company to integrate the data used throughout its entire organization. This list shows some of the many functions supported by SAP’s R/3 package.

Financials

Accounts receivable and payable

Asset accounting

Cash management and forecasting

Cost-element and cost-center accounting

Executive information system

Financial consolidation

General ledger

Product-cost accounting

Profitability analysis

Profit-center accounting

Standard and period-related costing

Human Resources

Human-resources time accounting

Payroll

Personnel planning

Travel expenses

Operations and Logistics

Inventory management

Material requirements planning

Materials management

Plant maintenance

Production planning

Project management

Purchasing

Quality management

Routing management

Shipping

Vendor evaluation

Sales and Marketing

Order management

Pricing

Sales management

Sales planning

Enterprise systems can deliver great rewards, but the risks they carry are equally great.

It is certainly true that enterprise systems can deliver great rewards, but the risks they carry are equally great. When considering and implementing an enterprise system, managers need to be careful that their enthusiasm about the benefits does not blind them to the hazards.

The Allure of Enterprise Systems

In order to understand the attraction of enterprise systems, as well as their potential dangers, you first need to understand the problem they’re designed to solve: the fragmentation of information in large business organizations. Every big company collects, generates, and stores vast quantities of data. In most companies, though, the data are not kept in a single repository. Rather, the information is spread across dozens or even hundreds of separate computer systems, each housed in an individual function, business unit, region, factory, or office. Each of these so-called legacy systems may provide invaluable support for a particular business activity. But in combination, they represent one of the heaviest drags on business productivity and performance now in existence.

Maintaining many different computer systems leads to enormous costs—for storing and rationalizing redundant data, for rekeying and reformatting data from one system for use in another, for updating and debugging obsolete software code, for programming communication links between systems to automate the transfer of data. But even more important than the direct costs are the indirect ones. If a company’s sales and ordering systems cannot talk with its production-scheduling systems, then its manufacturing productivity and customer responsiveness suffer. If its sales and marketing systems are incompatible with its financial-reporting systems, then management is left to make important decisions by instinct rather than according to a detailed understanding of product and customer profitability. To put it bluntly: if a company’s systems are fragmented, its business is fragmented.

Enter the enterprise system. A good ES is a technological tour de force. At its core is a single comprehensive database. The database collects data from and feeds data into modular applications supporting virtually all of a company’s business activities—across functions, across business units, across the world. (See the chart “Anatomy of an Enterprise System.”) When new information is entered in one place, related information is automatically updated.

Anatomy of an Enterprise System

Let’s say, for example, that a Paris-based sales representative for a U.S. computer manufacturer prepares a quote for a customer using an ES. The salesperson enters some basic information about the customer’s requirements into his laptop computer, and the ES automatically produces a formal contract, in French, specifying the product’s configuration, price, and delivery date. When the customer accepts the quote, the sales rep hits a key; the system, after verifying the customer’s credit limit, records the order. The system schedules the shipment; identifies the best routing; and then, working backward from the delivery date, reserves the necessary materials from inventory; orders needed parts from suppliers; and schedules assembly in the company’s factory in Taiwan.

The sales and production forecasts are immediately updated, and a material-requirements-planning list and bill of materials are created. The sales rep’s payroll account is credited with the correct commission, in French francs, and his travel account is credited with the expense of the sales call. The actual product cost and profitability are calculated, in U.S. dollars, and the divisional and corporate balance sheets, the accounts-payable and accounts-receivable ledgers, the cost-center accounts, and the corporate cash levels are all automatically updated. The system performs nearly every information transaction resulting from the sale.

An ES streamlines a company’s data flows and provides management with direct access to a wealth of real-time operating information. For many companies, these benefits have translated into dramatic gains in productivity and speed.

Autodesk, a leading maker of computer-aided design software, used to take an average of two weeks to deliver an order to a customer. Now, having installed an ES, it ships 98% of its orders within 24 hours. IBM’s Storage Systems division reduced the time required to reprice all of its products from 5 days to 5 minutes, the time to ship a replacement part from 22 days to 3 days, and the time to complete a credit check from 20 minutes to 3 seconds. Fujitsu Microelectronics reduced the cycle time for filling orders from 18 days to a day and a half and cut the time required to close its financial books from 8 days to 4 days.

When System and Strategy Clash

Clearly, enterprise systems offer the potential of big benefits. But the very quality of the systems that makes those benefits possible—their almost universal applicability—also presents a danger. When developing information systems in the past, companies would first decide how they wanted to do business and then choose a software package that would support their proprietary processes. They often rewrote large portions of the software code to ensure a tight fit. With enterprise systems, however, the sequence is reversed. The business often must be modified to fit the system.

An enterprise system is, after all, a generic solution. Its design reflects a series of assumptions about the way companies operate in general. Vendors try to structure the systems to reflect best practices, but it is the vendor, not the customer, that is defining what “best” means. In many cases, the system will enable a company to operate more efficiently than it did before. In some cases, though, the system’s assumptions will run counter to a company’s best interests.

Some degree of ES customization is possible. Because the systems are modular, for instance, companies can install only those modules that are most appropriate to their business. However, the system’s complexity makes major modifications impracticable. (See the sidebar “Configuring an Enterprise System.”) As a result, most companies installing enterprise systems will need to adapt or even completely rework their processes to fit the requirements of the system. An executive of one company that has adopted SAP’s system sums it up by saying, “SAP isn’t a software package; it’s a way of doing business.” The question is, Is it the best way of doing business? Do the system’s technical imperatives coincide or conflict with the company’s business imperatives?

Configuring an enterprise system is largely a matter of making compromises, of balancing the way you want to work with the way the system lets you work. You begin by deciding which modules to install. Then, for each module, you adjust the system using configuration tables to achieve the best possible fit with your company’s processes. Let’s look more closely at these two configuration mechanisms:

Modules. Most enterprise systems are modular, enabling a company to implement the system for some functions but not for others. Some modules, such as those for finance and accounting, are adopted by almost all companies that install an ES, whereas others, such as one for human resource management, are adopted by only some companies. Sometimes a company simply doesn’t need a module. A service business, for example, is unlikely to require the module for manufacturing. In other cases, companies choose not to implement a module because they already have a serviceable system for that particular function or they have a proprietary system that they believe provides unique benefits. In general, the greater the number of modules selected, the greater the integration benefits, but also the greater the costs, risks, and changes involved.

Configuration tables. A configuration table enables a company to tailor a particular aspect of the system to the way it chooses to do business. An organization can select, for example, what kind of inventory accounting—FIFO or LIFO—it will employ or whether it wants to recognize product revenue by geographical unit, product line, or distribution channel. SAP’s R/3, one of the more comprehensive and complex ES offerings, has more than 3,000 configuration tables. Going through all of them can take a long time. Dell Computer, for example, spent more than a year on the task.

Although modules and configuration tables let you customize the system to some degree, your options will be limited. If you have an idiosyncratic way of doing business, you will likely find that it is not supported by an ES. One company, for example, had long had a practice of giving preferential treatment to its most important customers by occasionally shipping them products that had already been allocated to other accounts. It found that its ES did not allow it the flexibility required to expedite orders in this way. Another company had always kept track of revenues by both product and geography, but its ES would allow it to track revenue in only one way.

What happens when the options allowed by the system just aren’t good enough? A company has two choices, neither of them ideal. It can actually rewrite some of the ES’s code, or it can continue to use an existing system and build interfaces between it and the ES. Both of these routes add time and cost to the implementation effort. Moreover, they can dilute the ES’s integration benefits. The more customized an enterprise system becomes, the less able it will be to communicate seamlessly with the systems of suppliers and customers.

Imagine, for example, an industrial products manufacturer that has built its strategy around its ability to provide extraordinary customer service in filling orders for spare parts. Because it is able to consistently deliver parts to customers 25% faster than its competitors—often by circumventing formal processes and systems—it has gained a large and loyal clientele who are happy to pay a premium price for its products. If, after installing an ES, the company has to follow a more rational but less flexible process for filling orders, its core source of advantage may be at risk. The company may integrate its data and improve its processes only to lose its service edge and, in turn, its customers.

This danger becomes all the more pressing in light of the increasing ubiquity of enterprise systems. It is now common for a single ES package to be used by virtually every company in an industry. For example, SAP’s R/3 package is being implemented by almost every company in the personal computer, semiconductor, petrochemical, and to a slightly lesser degree, consumer goods industries. (R/3 is the client-server version of SAP’s software; R/2 is the mainframe version.) Such convergence around a single software package should raise a sobering question in the minds of chief executives: How similar can our information flows and our processes be to those of our competitors before we begin to undermine our own sources of differentiation in the market?

This question will be moot if a company’s competitive advantage derives primarily from the distinctiveness of its products. Apple Computer, for example, has many problems, but the loss of competitive differentiation because of its ES is not one of them. With a strong brand and a unique operating system, its computers still differ dramatically from competing offerings. But Apple is an unusual case. Among most makers of personal computers, differentiation is based more on service and price than on product. For those companies, there is a very real risk that an enterprise system could dissolve their sources of advantage.

Compaq Computer is a good example of a company that carefully thought through the strategic implications of implementing an enterprise system. Like many personal-computer companies, Compaq had decided to shift from a build-to-stock to a build-to-order business model. Because the success of a build-to-order model hinges on the speed with which information flows through a company, Compaq believed that a fully integrated enterprise system was essential. At the same time, however, Compaq saw the danger in adopting processes indistinguishable from those of its competitors.

It realized, in particular, that in a build-to-order environment an important advantage would accrue to any company with superior capabilities for forecasting demand and processing orders. Compaq therefore decided to invest in writing its own proprietary applications to support its forecasting and order-management processes. To ensure that those applications would be compatible with its ES, Compaq wrote them in the computer language used by its ES vendor.

Compaq’s course was not the obvious one. It cost the company considerably more to develop the proprietary application modules than it would have to use the modules offered by the ES vendor. And using customized applications meant forgoing some of the integration benefits of a pure enterprise system. But Compaq saw the decision as a strategic necessity: it was the only way to protect a potentially critical source of advantage.

For companies that compete on cost rather than on distinctive products or superior customer service, enterprise systems raise different strategic issues. The huge investment required to implement an ES at large companies—typically ranging from $50 million to more than $500 million—need to be weighed carefully against the eventual savings the system will produce. In some cases, companies may find that by forgoing an ES they can actually gain a cost advantage over competitors that are embracing the systems. They may not have the most elegant computer system or the most integrated information flows and processes, but if customers are concerned only with price, that may not matter.

Air Products and Chemicals, for example, saw that many of its competitors were installing large, complex enterprise systems. After a thorough evaluation, it decided not to follow their lead. Its managers reasoned that the cost of an ES might force the company to raise its prices, leading to lost sales in some of the commodity gas markets in which it competes. The company’s existing systems, while not state-of-the-art, were adequate to meet its needs. And since the company had no plans to exchange information electronically with competitors, it didn’t worry about being the odd man out in its industry.

Of course, the long-term productivity and connectivity gains created by enterprise systems are often so compelling that not adopting one is out of the question. In the petrochemicals industry, for example, enterprise systems have improved the flow of information through the supply chain to such a degree that they have become a de facto operating standard. Because participants in the industry routinely share information electronically, it would today be hard for a company to survive in the business without an ES. Still, the cost of implementation should be a primary concern. It will often be in a company’s interest to go ahead and rework its processes to fit the system requirements. The alternative—customizing the system to fit the processes or writing proprietary application modules—will simply be too expensive to justify. As the CEO of one large chemical firm says, “Competitive advantage in this industry might just come from doing the best and cheapest job at implementing SAP.”

The Impact on an Organization

In addition to having important strategic implications, enterprise systems also have a direct, and often paradoxical, impact on a company’s organization and culture. On the one hand, by providing universal, real-time access to operating and financial data, the systems allow companies to streamline their management structures, creating flatter, more flexible, and more democratic organizations. On the other hand, they also involve the centralization of control over information and the standardization of processes, which are qualities more consistent with hierarchical, command-and-control organizations with uniform cultures. In fact, it can be argued that the reason enterprise systems first emerged in Europe is that European companies tend to have more rigid, centralized organizational structures than their U.S. counterparts.

Some executives, particularly those in fast-growing high-tech companies, have used enterprise systems to inject more discipline into their organizations. They see the systems as a lever for exerting more management control and imposing more-uniform processes on freewheeling, highly entrepreneurial cultures. An executive at a semiconductor company, for example, says, “We plan to use SAP as a battering ram to make our culture less autonomous.” The manager of the ES implementation at a computer company expresses a similar thought: “We’ve had a renegade culture in the past, but our new system’s going to make everybody fall into line.”

But some companies have the opposite goal. They want to use their enterprise systems to break down hierarchical structures, freeing their people to be more innovative and more flexible. Take Union Carbide. Like most companies implementing enterprise systems, Union Carbide is standardizing its basic business transactions. Unlike many other companies, however, the leaders of its ES project are already thinking in depth about how the company will be managed differently when the project is completed. They plan to give low-level managers, workers, and even customers and suppliers much broader access to operating information. Standardizing transactions will make Union Carbide more efficient; sharing real-time information will make it more creative.

For a multinational corporation, enterprise systems raise another important organizational question: How much uniformity should exist in the way it does business in different regions or countries? Some big companies have used their enterprise systems to introduce more consistent operating practices across their geographically dispersed units. Dow Chemical, for instance, became an early convert to enterprise systems because it saw them as a way to cut costs by streamlining global financial and administrative processes. (A good idea in principle, although it became much more expensive to achieve than Dow had anticipated.) Some large manufacturers have been even more ambitious, using the systems as the basis for introducing a global lean-production model. By imposing common operating processes on all units, they are able to achieve tight coordination throughout their businesses. They can rapidly shift sourcing, manufacturing, and distribution functions worldwide in response to changing patterns of supply and demand. This capability allows them to minimize excess manufacturing capacity and reduce both component and finished-goods inventory.

Owens Corning, for example, adopted an ES to replace 211 legacy systems. For the company to grow internationally, its chief executive, Glen Hiner, felt it was critical to coordinate order-management, financial-reporting, and supply chain processes across the world. Having implemented the system and established a new global-procurement organization, the company is now able to enter into larger, more advantageous international contracts for supplies. Finished-goods inventory can be tracked daily, both in company warehouses and in the distribution channel, and spare-parts inventory has been reduced by 50%. The company expects to save $65 million by the end of 1998 as a result of its adoption of these globally coordinated processes.

For most companies, however, differences in regional markets remain so profound that strict process uniformity would be counterproductive. If companies in such circumstances don’t allow their regional units to tailor their operations to local customer requirements and regulatory strictures, they risk sacrificing key markets to more flexible competitors. To preserve local autonomy while maintaining a degree of corporate control—what might be called a federalist operating model—a very different approach to enterprise systems needs to be taken. Rather than implement a single, global ES, these companies need to roll out different versions of the same system in each regional unit, tailored to support local operating practices. This approach has been taken by a number of large companies, including Hewlett-Packard, Monsanto, and NestlÃƒ©. They establish a core of common information—financial, say—that all units share, but they allow other information—on customers, say—to be collected, stored, and controlled locally. This method of implementation trades off some of the purity and simplicity of the enterprise system for greater market responsiveness.

The federalist model raises what is perhaps the most difficult challenge for a manager implementing an ES: determining what should be common throughout the organization and what should be allowed to vary. Corporate and business-unit managers will need to sit down together—well before system implementation begins—to think through each major type of information and each major process in the company. Difficult questions need to be raised: How important is it for us to process orders in a consistent manner worldwide? Does the term “customer” mean the same thing in every business unit? Answering such questions is essential to making an ES successful.

Different companies will, of course, reach very different decisions about the right balance between commonality and variability. Consider the starkly different approaches taken by Monsanto and Hewlett-Packard. Monsanto’s managers knew that different operating requirements would preclude the complete standardization of data across its agrochemical, biotechnology, and pharmaceuticals businesses. Nevertheless, they placed a high priority on achieving the greatest possible degree of commonality. After studying the data requirements of each business unit, Monsanto’s managers were able to standardize fully 85% of the data used in the ES. The company went from using 24 coding schemes for suppliers to using just one, and it standardized all data about materials using a new set of substance identification codes. While customer and factory data have not been fully standardized—differences among the units’ customers and manufacturing processes are too great to accommodate common data—Monsanto has achieved a remarkable degree of commonality across a diverse set of global businesses.

At Hewlett-Packard, a company with a strong tradition of business-unit autonomy, management has not pushed for commonality across the several large divisions that are implementing SAP’s enterprise system. Except for a small amount of common financial data necessary to roll up results for corporate reporting, HP’s federalist approach gives all the power to the “states” where ES decisions are concerned. This approach fits the HP culture well, but it’s very expensive. Each divisional ES has had to be implemented separately, with little sharing of resources. Managers estimate that well over a billion dollars will be spent across the corporation before the various projects are completed.

Doing It Right at Elf Atochem

Considering an ES’s far-reaching strategic and organizational implications, the worst thing a company can do is to make decisions about a system based on technical criteria alone. In fact, having now studied more than 50 businesses with enterprise systems, I can say with some confidence that the companies deriving the greatest benefits from their systems are those that, from the start, viewed them primarily in strategic and organizational terms. They stressed the enterprise, not the system.

Those companies that stressed the enterprise, not the system, gained the greatest benefits.

Elf Atochem North America, a $2 billion regional chemicals subsidiary of the French company Elf Aquitaine, is a good case in point. Following a series of mergers in the early 1990s, Elf Atochem found itself hampered by the fragmentation of critical information systems among its 12 business units. Ordering systems were not integrated with production systems. Sales forecasts were not tied to budgeting systems or to performance-measurement systems. Each unit was tracking and reporting its financial data independently. As a result of the many incompatible systems, operating data were not flowing smoothly through the organization, and top management was not getting the information it needed to make sound and timely business decisions.

The company’s executives saw that an enterprise system would be the best way to integrate the data flows, and they decided to go with SAP’s R/3 system, which was rapidly becoming the standard in the industry. But they never labeled the ES project as simply a technology initiative. Rather, they viewed it as an opportunity to take a fresh look at the company’s strategy and organization.

Looking beyond the technology, the executives saw that the real source of Elf Atochem’s difficulties was not the fragmentation of its systems but the fragmentation of its organization. Although the 12 business units shared many of the same customers, each unit was managed autonomously. From the customer’s perspective, the lack of continuity among units made doing business with the company a trial. To place a single order, a customer would frequently have to make many different phone calls to many different units. And to pay for the order, the customer would have to process a series of invoices.

Inside the company, things were equally confused. It took four days—and seven handoffs between departments—to process an order, even though only four hours of actual work were involved. Because each unit managed inventory and scheduled production independently, the company was unable to consolidate inventory or coordinate manufacturing at the corporate level. More than $6 million in inventory was written off every year, and plants had to be shut down frequently for unplanned production-line changes. And because ordering and production systems were not linked, sales representatives couldn’t promise firm delivery dates, which translated into lost customers.

Management knew that in the petrochemicals business, where many products are commodities, the company that can offer the best customer service often wins the order. So it structured the implementation of its ES in a way that would enable it to radically improve its service levels. Its goal was to transform itself from an industry laggard into an industry leader. Even though many competitors were also adopting the R/3 package, Elf Atochem knew that if it could achieve a tighter, smoother fit between its business processes and the system, it could gain and maintain a service advantage.

The company decided to focus its efforts on four key processes: materials management, production planning, order management, and financial reporting. These cross-unit processes were the ones most distorted by the fragmented organizational structure. Moreover, they had the greatest impact on the company’s ability to manage its customer relationships in a way that would both enhance customer satisfaction and improve corporate profitability. Each of the processes was redesigned to take full advantage of the new system’s capabilities, in particular its ability to simplify the flow of information. Layers of information middlemen—once necessary for transferring information across incompatible unit and corporate systems—were eliminated in order to speed the flow of work and reduce the likelihood of errors.

To maintain its focus on the customer, the company chose to install only those R/3 modules required to support the four targeted processes. It did not, for example, install the modules for human resource management or plant maintenance. Those functions did not have a direct impact on customers, and the existing information systems that supported them were considered adequate.

Elf Atochem also made fundamental changes to its organizational structure. In the financial area, for example, all the company’s accounts-receivable and credit departments were combined into a single corporate function. This change enabled the company to consolidate all of a customer’s orders into a single account and issue a single invoice. It also allowed the company to monitor and manage overall customer profitability—something that had been impossible to do when orders were fragmented across units. In addition, Elf Atochem combined all of its units’ customer-service departments into one department, providing each customer with a single point of contact for checking on orders and resolving problems.

Perhaps most important, the system gave Elf Atochem the real-time information it needed to connect sales and production planning—demand and supply—for the first time. As orders are entered or changed, the system automatically updates forecasts and factory schedules, which enables the company to quickly alter its production runs in response to customers needs. Only one other company in the industry had this capability, which meant that Elf Atochem gained an important edge over most competitors.

The company understood, however, that just having the data doesn’t necessarily mean the data will be used well. Computer systems alone don’t change organizational behavior. It therefore established a new position—demand manager—to be the focal point for the integrated sales and production-planning process. Drawing on the enterprise system, the demand manager creates the initial sales forecast, updates it with each new order, assesses plant capacity and account profitability, and develops detailed production plans. The demand manager is able to schedule a customer’s order—and promise a delivery date—up to six weeks ahead of production. Previously, production could be allocated to individual orders no more than a week in advance. Now central to the company’s operation, the role of demand manager could not even have existed in the past because the information needed to perform it was scattered all over the company.

The way Elf Atochem is managing the implementation effort also reflects the breadth of its goals. The project is being led by a 60-person core implementation team, which reports to a member of the company’s executive committee. The team includes both business analysts and information technologists, and is assisted by a set of so-called super users, representing the business units and corporate functions. These super users help ensure that decisions about the system’s configuration are made with the broadest possible understanding of the business. They also play a crucial role in explaining the new system to their respective departments and training people in its use.

The team is installing the ES one business unit at a time, with each unit implementing the same system configuration and set of procedures for order processing, supplier management, and financial reporting. The unit-by-unit process ensures that the effort is manageable, and it also helps the team refine the system and the processes as it proceeds. For example, the second unit to implement the system found that it didn’t adequately support bulk shipments, which are the main way the unit gets its products to customers. (The first unit uses package shipping for all its orders.) The system was then modified to support bulk as well as package shipping, and the new configuration became the new standard.

Using the large and broadly representative implementation team, together with the unit-by-unit rollout, Elf Atochem has been able to staff the effort mainly with its own people. It has had to engage only nine outside consultants to assist in the project—far fewer than is usually the case. The reliance on internal resources not only reduces the cost of the implementation, it also helps ensure that Elf Atochem’s employees will understand how the system works after the consultants leave.

Elf Atochem’s ES is now more than 75% complete—9 of the 12 business units are up and running on the new system—and the rollout is ahead of schedule and under budget. Customer satisfaction levels have already increased, and the company is well on the way to its goal of confirming 95% of all orders with one call, a dramatic improvement over the previous average of five calls. In addition to the service enhancements, the company is operating more efficiently. Inventory levels, receivables, and labor and distribution expenditures have all been cut, and the company expects the system will ultimately reduce annual operating costs by tens of millions of dollars.

The Role of Management

Every company that installs an ES struggles with its cost and complexity. But the companies that have the biggest problems—the kind of problems that can lead to an outright disaster—are those that install an ES without thinking through its full business implications.

Managers may well have good reasons to move fast. They may, for example, have struggled for years with incompatible information systems and may view an ES as a silver bullet. They may be looking for a quick fix to the Year 2000 problem (enterprise systems are not infected with the much-feared millennium bug). Or they may be trying to keep pace with a competitor that has already implemented an ES. The danger is that while an enterprise system may help them meet their immediate challenge, the very act of implementing it may create even larger problems. A speedy implementation of an ES may be a wise business move; a rash implementation is not.

A speedy implementation of an enterprise system may be a wise business move, but a rash implementation is not.

A number of questions should be answered before any decisions are made. How might an ES strengthen our competitive advantages? How might it erode them? What will be the system’s effect on our organization and culture? Do we need to extend the system across all our functions, or should we implement only certain modules? Would it be better to roll the system out globally or to restrict it to certain regional units? Are there other alternatives for information management that might actually suit us better than an ES?

The experience of Elf Atochem and other successful adopters of enterprise systems underscores the need for careful deliberation. It also highlights the importance of having top management directly involved in planning and implementing an ES. Not only is Elf Atochem’s executive committee overseeing its ES project, but its entire board reviewed and approved the plans. At Compaq, the decision to go with an ES was also made at the board level, and the senior management team was involved with the implementation every step of the way.

Only a general manager is equipped to act as a mediator between the imperatives of the technology and of the business.

Many chief executives, however, continue to view the installation of an ES as primarily a technological challenge. They push responsibility for it down to their information technology departments. Because of an ES’s profound business implications—and, in particular, the risk that the technology itself might undermine a company’s strategy—off-loading responsibility to technologists is particularly dangerous. Only a general manager is equipped to act as the mediator between the imperatives of the technology and the imperatives of the business. If the development of an enterprise system is not carefully controlled by management, management may soon find itself under the control of the system.

A version of this article appeared in the July–August 1998 issue of Harvard Business Review.