The REA Approach to Database Modeling:Risks Associated with ERP Implementation

Risks Associated with ERP Implementation

The benefits from ERP can be significant, but they do not come risk-free to the organization. An ERP system is not a silver bullet that will, by its mere existence, solve an organization’s problems. If that were the case, there would never be ERP failures, but there have been many. This section examines some of the risk issues that need to be considered.

BIG BANG VERSUS PHASED-IN IMPLEMENTATION

Implementing an ERP system has more to do with changing the way an organization does business than it does with technology. As a result, most ERP implementation failures are the result of cultural problems within the firm that stand in opposition to the objective of process reengineering. Strategies for implementing ERP systems to achieve this objective follow two general approaches: the big bang and the phased-in approach.

The big bang method is the more ambitious and risky of the two. Organizations taking this approach attempt to switch operations from their old legacy systems to the new system in a single event that implements the ERP across the entire company. Although this method has certain advantages, it has been associated with numerous system failures. Because the new ERP system means new ways of conducting business, getting the entire organization on board and in sync can be a daunting task. On day 1 of the implementation, no one within the organization will have had any experience with the new system. In a sense, everyone in the company is a trainee learning a new job.

The new ERP system will initially meet with opposition because using it involves compromise. The legacy systems, which everyone in the organization was familiar with, had been honed over the years to meet exact needs. In most cases, ERP systems have neither the range of functionality nor the familiarity of the legacy systems that they replace. Also, because a single system is now serving the entire organiza- tion, individuals at data input points often find themselves entering considerably more data than they did previously with the more narrowly focused legacy system.

As a result, the speed of the new system often suffers and causes disruptions to daily operations. These problems are typically experienced whenever any new system is implemented. The magnitude of the problem is the issue under the big bang approach in which everyone in the company is affected. Once the initial adjustment period has passed and the new culture emerges, however, the ERP becomes an effective operational and strategic tool that provides competitive advantage to the firm.

Because of the disruptions associated with the big bang, the phased-in approach has emerged as a popular alternative. It is particularly suited to diversified organizations whose units do not share common processes and data. In these types of companies, independent ERP systems can be installed in each business unit over time to accommodate the adjustment periods needed for assimilation. Common processes and data, such as the general ledger function, can be integrated across the organization without disrupting operations throughout the firm.

Organizations that are not diversified can also employ the phased-in approach. The implementation usually begins with one or more key processes, such as order entry. The goal is to get ERP up and running concurrently with legacy systems. As more of the organization’s functions are converted to ERP, legacy systems are systematically retired. In the interim, the ERP is interfaced to legacy systems. During this period, the objectives of system integration and process reengineering, which are fundamental to the ERP model, are not achievable. To take full advantage of the ERP, process reengineering will still need to occur. Otherwise, the organization will have simply replaced its old legacy system with a very expensive new one.

OPPOSITION TO CHANGES IN THE BUSINESS’S CULTURE

To be successful, all functional areas of the organization need be involved in determining the culture of the firm and in defining the new system’s requirements. The firm’s willingness and ability to under- take a change of the magnitude of an ERP implementation is an important consideration. If the corporate culture is such that change is not tolerated or desired, then an ERP implementation will not be successful.

The technological culture must also be assessed. Organizations that lack technical support staff for the new system or have a user base that is unfamiliar with computer technology face a steeper learning curve and a potentially greater barrier to acceptance of the system by its employees.

CHOOSING THE WRONG ERP

Because ERP systems are prefabricated systems, users need to determine whether a particular ERP fits their organization’s culture and its business processes. A common reason for system failure is when the ERP does not support one or more important business processes. In one example, a textile manufacturer in India implemented an ERP only to discover afterward that it did not accommodate a basic need.

The textile company had a policy of maintaining two prices for each item of inventory that it sold. One price was used for the domestic market, and a second price, which was four times higher, was for export sales. The ERP that the user implemented was not designed to allow two different prices for the same inventory item. The changes needed to make the ERP work were both extensive and expensive. Serious system disruptions resulted from this oversight. Furthermore, modifying an ERP program and database can intro- duce potential processing errors and can make updating the system to later versions difficult.

Goodness of Fit

Management needs to make sure that the ERP they choose is right for the company. No single ERP sys- tem is capable of solving all the problems of all organizations. For example, SAP’s R/3 was designed primarily for manufacturing firms with highly predictable processes that are relatively similar to those of other manufacturers. It may not be the best solution for a service-oriented organization that has a great need for customer-related activities conducted over the Internet.

Finding a good functionality fit requires a software selection process that resembles a funnel, which starts broad and systematically becomes more focused. It begins with a large number of software vendors that are potential candidates. Evaluation questions are asked of vendors in iterative rounds. Starting with a large population of vendors and a small number of high-level qualifier questions, the number of vendors is reduced to a manageable few. With proper questioning, more than half the vendors are removed from contention with as few as 10 to 20 questions. In each succeeding round, the questions asked become more detailed and the population of vendors decreases.

When a business’s processes are truly unique, the ERP system must be modified to accommodate industry-specific (bolt-on) software or to work with custom-built legacy systems. Some organizations, such as telecommunications service providers, have unique billing operations that off-the-shelf ERP systems cannot satisfy. Before embarking on the ERP journey, the organization’s management needs to assess whether it can and should reengineer its business practices around a standardized model.

System Scalability Issues

If an organization’s management expects business volumes to increase substantially during the life of the ERP system, then there is a scalability issue that needs to be addressed. Scalability is the system’s ability to grow smoothly and economically as user requirements increase. The term system in this context refers to the technology platform, application software, network configuration, or database. Smooth and economic growth is the ability to increase system capacity at an acceptable incremental cost per unit of capacity without encountering limits that would demand a system upgrade or replacement. User requirements pertain to volume-related activities such as transaction processing volume, data entry volume, data output volume, data storage volume, or increases in the user population.

To illustrate scalability, four dimensions of scalability are important: size, speed, workload, and trans- action cost. In assessing scalability needs for an organization, each of these dimensions in terms of the ideal of linear scaling must be considered.5 Size. With no other changes to the system, if database size increases by a factor of x, then query response time will increase by no more than a factor of x in a scalable system. For example, if business growth causes the database to increase from 100 to 500 gigabytes, then transactions and queries that previously took 1 second will now take no more than 5 seconds.

Speed. An increase in hardware capacity by a factor of x will decrease query response time by no less than a factor of x in a scalable system. For example, increasing the number of input terminals (nodes) from 1 to 20 will increase transaction processing time proportionately. Transactions that previously took 20 seconds will now take no more than 1 second in a system with linear scaling.

Workload. If workload in a scalable system is increased by a factor of x, then response time, or throughput, can be maintained by increasing hardware capacity by a factor of no more than x. For example, if transaction volume increased from 400 per hour to 4,000 per hour, the previous response time can be achieved by increasing the number of processors by a factor of 10 in a system that is linearly scalable.

Transaction Cost. In a scalable system, increases in workload do not increase transaction cost. There- fore, an organization should not need to increase system capacity faster than demand. For example, if the cost of processing a transaction in a system with one processor is 10 cents, then it should still cost no more than 10 cents when the number of processors is increased to handle larger volumes of transactions.

Vendors of ERP systems sometimes advertise scalability as if it were a single-dimension factor. In fact, it is a multifaceted issue. Some systems accommodate growth in user populations better than others. Some systems can be scaled to provide more efficient access to large databases when business growth demands it. All systems, however, have their scaling limits. Because infinite scalability is impossible, prospective users need to assess their needs and determine how much scalability they want to purchase up front and what form it should take. The key is to anticipate specific scalability issues before making an ERP investment and before the issues become reality.

CHOOSING THE WRONG CONSULTANT

Implementing an ERP system is an event that most organizations will undergo only once. Success of the projects rests on skills and experience that typically do not exist in-house. Because of this, virtually all ERP implementations involve an outside consulting firm, which coordinates the project, helps the organization to identify its needs, develops a requirements specification for the ERP, selects the ERP package, and manages the cutover. ERP consulting has grown into a $20 billion-per-year market. The fee for a typical implementation is normally between three and five times the cost of the ERP software license.

Consulting firms with large ERP practices at times have been desperately short of human resources. This was especially true in the mid- to late-1990s, when thousands of clients were rushing to implement ERP systems before the new millennium to avoid Y2K (year-2000) problems. As demand for ERP implementations grew beyond the supply of qualified consultants, more and more stories of botched projects materialized.

A frequent complaint is that consulting firms promise experienced professionals, but deliver incompetent trainees. They have been accused of employing a bait-and-switch maneuver to get contracts. At the initial engagement interview, the consulting firm introduces their top consultants, who are sophisticated, talented, and persuasive. The client agrees to the deal with the firm, but incorrectly assumes that these individuals, or others with similar qualifications, will actually implement the system.

The problem has been equated to the airline industry’s common practice of overbooking flights. Some suggest that consulting firms, not wanting to turn away business, are guilty of overbooking their consult- ing staff. The consequences, however, are far graver than the inconvenience of missing a flight—a free hotel room and meal cannot compensate for the damages done. Therefore, before engaging an outside consultant, management should:

• Interview the staff proposed for the project and draft a detailed contract specifying which members of the consulting team will be assigned to which tasks.

• Establish in writing how staff changes will be handled.

• Conduct reference checks of the proposed staff members.

• Align the consultants’ interests with those of the organization by negotiating a pay-for-performance scheme based on achieving certain milestones in the project. For example, the actual amount paid to the consultant may be between 85 and 115 percent of the contracted fee, based on whether a successful project implementation comes in under or over schedule.

• Set a firm termination date for the consultant to avoid consulting arrangements becoming interminable, resulting in dependency and an endless stream of fees.

HIGH COST AND COST OVERRUNS

Total cost of ownership (TCO) for ERP systems varies greatly from company to company. For medium- to large-sized systems implementations, costs range from hundreds of thousands to hundreds of millions of dollars. TCO includes hardware, software, consulting services, internal personnel costs, installation, and upgrades and maintenance to the system for the first 2 years after implementation. The risk comes in the form of underestimated and unanticipated costs. Some of the more commonly experienced problems occur in the following areas.

Training. Training costs are invariably higher than estimated because management focuses primarily on the cost of teaching employees the new software. This is only part of the needed training. Employees also need to learn new procedures, which is often overlooked during the budgeting process.

System Testing and Integration. In theory, ERP is a holistic model in which one system drives the entire organization. The reality, however, is that many organizations use their ERP as a backbone sys- tem that is attached to legacy systems and other bolt-on systems, which support the unique needs of the firm. Integrating these disparate systems with the ERP may involve writing special conversion pro- grams or even modifying the internal code of the ERP. Integration and testing are done on a case-by- case basis; thus, the cost is extremely difficult to estimate in advance.

Database Conversion. A new ERP system usually means a new database. Data conversion is the process of transferring data from the legacy system’s flat files to the ERP’s relational database. When the legacy system’s data are reliable, the conversion process may be accomplished through automated procedures. Even under ideal circumstances, a high degree of testing and manual reconciliation is nec- essary to ensure that the transfer was complete and accurate. More often, the data in the legacy system are not reliable (sometimes called dirty). Empty fields and corrupted data values cause conversion problems that demand human intervention and data rekeying. Also, and more importantly, the structure of the legacy data is likely to be incompatible with the reengineered processes of the new sys- tem. Depending on the extent of the process reengineering involved, the entire database may need to be converted through manual data entry procedures.

Develop Performance Measures

Because ERPs are extremely expensive to implement, many managers are often dismayed at the apparent lack of cost savings that they achieve in the short term. In fact, a great deal of criticism about the relative success of ERPs relates to whether they provide benefits that outweigh their cost.

To assess benefits, management first needs to know what they want and need from the ERP. They should then establish key performance measures such as reductions in inventory levels, inventory turnover, stock-outs, and average order fulfillment time that reflect their expectations. To monitor performance in such key areas, some organizations establish an independent value assessment group that reports to top management. Although financial break-even on an ERP will take years, by developing focused and measurable performance indicators, an operational perspective on its success can be developed.

DISRUPTIONS TO OPERATIONS

ERP systems can wreak havoc in the companies that install them. In a Deloitte Consulting survey of 64 Fortune 500 companies, 25 percent of the firms surveyed admitted that they experienced a drop in performance in the period immediately following implementation. The reengineering of business processes that often accompanies ERP implementation is the most commonly attributed cause of performance problems. Operationally speaking, when business begins under the ERP system, everything looks and works differently from the way it did with the legacy system. An adjustment period is needed for everyone to reach a comfortable point on the learning curve. Depending on the culture of the organization and attitudes toward change within the firm, adjustment may take longer in some firms than in others. The list of major organizations that have experienced serious disruptions includes Dow Chemical, Boeing, Dell Computer, Apple Computer, Whirlpool Corporation, and Waste Management. The most notorious case in the press was Hershey Foods Corporation, which had trouble processing orders through its new ERP system and was unable to ship products.

As a result of these disruptions, Hershey’s 1999 third-quarter sales dropped by 12.4 percent compared to the previous year’s sales, and earnings were down by 18.6 percent. Hershey’s problem has been attributed to two strategic errors related to system implementation. First, because of schedule overruns, they decided to switch to the new system during their busy season. The inevitable snags that arise from implementations of complex systems like SAP’s R/3 are easier to deal with during slack business periods. Secondly, many experts believe that Hershey attempted to do too much in a single implementation. In addition to the R/3 system, they implemented a customer relations management system and logistics soft- ware from two different vendors, which had to interface with R/3. The ERP and these bolt-on components were all implemented using the big bang approach.