This chapter initiates our dialogue into enterprise resource planning (ERP) systems, focusing on the following questions.

• Why investigate ERP systems?

• How does ERP create value?

• What is the purpose and scope of this book?

• What is the outline of this book?

Why Investigate Enterprise Resource Planning Systems?

Enterprise resource planning systems are a corporate marvel, with a huge impact on both the business and information technology worlds, including each of the following dimensions:

• ERP affects most major corporations in the world;

• ERP affects many SMEs (small and medium enterprises);

• ERP affects competitors' behavior;

• ERP affects business partner requirements;

• ERP has changed the nature of consulting firms;

• ERP provides one of the primary tools for reengineering;

• ERP has diffused many “best practices”;

• ERP gave client server computing its first enterprise product;

• ERP has changed the nature of the information systems function;

• ERP has changed the nature of jobs in all functional areas;

• ERP cost is high;

• ERP has experienced huge market growth.

ERP Affects Most Major Corporations in the World (Bowley 1998). A single ERP system (SAP's R/3) is used by more than 60% of the multinational firms. Further, according to Arthur D. Little's global strategy leader, an ERP company (SAP) “is conquering the world. Almost every important company is more or less in its hands.”

After going live with the ERP implementation, it is not time to forget about ERP because it is “done.” Instead, at that time the organization enters a stabilization period that typically drags down organizational performance. As a result, firms need to work to mitigate that negative effect. The firm also needs to build an organization to handle the day-to-day issues associated with the ERP system, and management needs to determine what else must be done and whether the implementation matches the system plan. Also, management must address what upgrades, extensions, or linkages can or should be made to the ERP system. Finally, the firm needs to evaluate the success of the project.

The Stabilization Period

After a system goes live there is what has been referred to as a “stabilization period” that typically lasts from three to nine months. During that period, as noted by a director at Benchmarking Partners, “[m]ost companies should expect some dip in their business performance at the time they go live and should expect that they'll need to manage through that dip” (Koch 1999). For example, a recent survey by Deloitte Consulting found that, after their ERP systems went live, one in four firms suffered some drop in performance.

During the stabilization period, all those processes that once were just plans are now being used. New software and processes may be unfamiliar to the users.

As part of choosing ERP software, firms face a design “reengineering policy” decision regarding the amount of software customization and organizational reengineering that must be done. On one hand, since no software is likely to meet all of a firm's needs, some firms have chosen to substantially customize the software to fit their processes. On the other hand, many businesses have used adoption of new software as a chance to change their basic business processes, reengineering their organization to match the “best practice” processes in the ERP software. In order to clarify the extent to which different firms pursue different policies, Forrester Research conducted a survey (Lamonica 1998) and found the following percentage of firms following policies:

• choose applications that fit their business and customize a bit – 37%;

• customize applications to fit their business – 5%;

• reengineer business to fit application – 41%;

• no policy – 17%.

This chapter analyzes two basic questions.

1. (1) How does the reengineering policy influence the software application choice process?

2. (2) Should business processes or ERP software be changed?

How Does Reengineering Policy Influence Software Choice Processes: On the Relevance of “As Is” and “To Be” Modeling

The decision to modify software or reengineer business processes (or both) influences the relevance and use of “as is” and “to be” modeling.

The purpose of this chapter is to provide some basic background information about ERP systems. As a result, we will address a number of specific questions.

• What is an ERP system?

• Who are the ERP vendors?

• What are ERP “partners”?

• What are some sample ERP modules?

• What does it mean to talk of “best of breed”?

• What are “add-ons” to ERP?

• What are ERP MAPs?

• How do ERP systems work?

Since SAP is the dominant ERP system, I will use it to illustrate some of the general ERP concepts.

What Is an ERP System?

In this book, ERP systems are computer-based systems designed to process an organization's transactions and facilitate integrated and real-time planning, production, and customer response. In particular, ERP systems will be assumed to have the following characteristics.

• ERP systems are packaged software designed for a client server environment, whether traditional or web-based.

• ERP systems integrate the majority of a business's processes.

• ERP systems process a large majority of an organization's transactions.

• ERP systems use an enterprise-wide database that typically stores each piece of data once.

• ERP systems allow access to the data in real time.

• In some cases, ERP allows an integration of transaction processing and planning activities (e.g., production planning).

One of the critical sets of decisions that needs to be made in any ERP concerns the choice of common standard MAPs – that is, models (e.g., organization models), artifacts (e.g., vendor numbering schemes and lists), and processes (e.g., order management). Two expressions, “common … and global” and “input by many,” have received attention as guidelines to help implement those common MAPs in some companies (see CIO 1996). Rather than following the historical process of each business unit choosing its own MAPs, as is often done in legacy systems, an ERP-structured company will use the same MAPs for each business unit. However, the choice, implementation, and use of common MAPs is not easy. Within a given firm there are likely to be conflicts over those MAPs. As a result, this chapter addresses the following questions.

• Why are MAPs important?

• Where do common MAPs come from?

• Why do firms need common MAPs for ERP systems?

• Why didn't firms have common MAPs prior to ERP systems?

• Why is it difficult to choose common standards?

• What are some choice motivations?

• In order to develop “common … and global” processes, what methods have been used to choose common ERP models, artifacts, and processes so that there is “input by many”?

Why Are MAPs Important?

The quality of the MAPs will have a huge impact on the overall success of the ERP implementation.

This chapter examines how firms choose between different ERP systems. Two primary approaches are used to guide ERP choice: requirements analysis and gap analysis. This chapter defines these approaches and examines the advantages and disadvantages of each, and it briefly discusses an alternative approach. In addition, this chapter examines the assumptions behind requirements analysis and gap analysis as well as some limitations of these two processes. Also discussed are two companies that have mitigated these limitations in their evaluation of ERP software by going beyond requirements and gap analyses. Finally, this chapter summarizes the shortcomings of broader evaluation approaches.

Requirements Analysis

Requirements analysis is a review of system requirements for organizational models, artifacts, and processes (MAPs). In some cases requirements are cataloged as to their importance – for example, required or optional, or ranked (say) from 1 to 3. Requirements are then summarized in a requirements document (request for proposal, or RFP) that is provided to different vendors. The organization uses that set of requirements to judge how well different pieces of software meet their needs.

How Many Requirements?

Requirements documents can be quite extensive. For example, one company (Firm A) with $40 million in sales produced a document with about 1,000 requirements listed. Timberjack, with over $35 million in sales, listed 1,042 requirements. A much larger and privately held company (Firm B) also had a requirements document with over 1,000 items.

The purpose of this chapter is to provide some brief background information on systems and technology to facilitate understanding of ERP issues. In order to do that, some background on computing, networking, databases, software, software choice, and reengineering is provided. Within each category, the background information is applied to some related ERP (in particular, SAP) concepts in order to tie the background material directly to ERP.

Computing

Historically, enterprise computing was heavily mainframe based. In roughly 1993 (see e.g. Frye 1994), client server versions of enterprise computing applications began to be more available.

Mainframe Computing

In a mainframe computing environment, all the computing is done on a single computer (box). Typically, this is handled by allowing users to share (e.g., via time sharing) the computing resource – the mainframe computer. The user would typically be at a terminal that had no computing capabilities (or at a personal computer that emulated a terminal).

Client Server Computing

Over time, the user began to have increasing computing capabilities locally. As a result, computing began to shift some of the processing to the user's computing facilities. This ultimately resulted in what is now called “client server” computing, where client and server are linked so that the computing and storage can be distributed between the client and the server. The term “client” refers to the user's computer, while the “server” refers to some other (e.g., centrally located) computing source that provides computing resources, software, or data.

Electronic commerce has emerged as a critical aspect of doing business. For many firms there is no separating electronic commerce from regular commerce; the two have become increasingly intertwined. For Cisco, orders over the web have increased from less than 10% in 1996 to roughly 85% in 1999. As a result of these dramatic shifts, there has been an equally dramatic set of changes in the way business is done using electronic commerce. Increasingly, firms such as Cisco are using electronic commerce to simplify their business processes and improve customer relationships (Riggs 1999).

The electronic commerce phenomenon has occurred at roughly the same time as the ERP phenomenon. Further, both are highly dependent on changes in processes to accommodate the new technology, which leads us to ask: “What are some of the relationships between the two?” This chapter explores that question by first establishing ERP as one of the primary building blocks of electronic commerce and then eliciting the role of ERP in each of a number of major electronic commerce initiatives: order tracing, order configuration, order placing, vendor-managed inventories, build to order, and merge in transit.

Building Blocks for Electronic Commerce

What are some of the building blocks for electronic commerce? ERP provides a repository for the information. Communication networks facilitate access to the information. Wide availability and easy-to-use access make it possible to get ERP information over the Internet.

Access to ERP information was at first limited to the reports that could be generated from the system or through database queries of the underlying database model. Recently, however, organizations have begun to employ intranets and data warehouses to further distribute ERP-generated information. In addition, ERP vendors have begun to develop “portals” that are designed to provide users specific access to a range of information. This has led to improvements in ease of use and hence to new opportunities in electronic commerce for ERP vendors.

ERP Reporting and Query Capabilities

With ERP systems, information is made available to particular users in the form of specific reports. In addition, there are other approaches to generating data from the system, including database queries. Recently, ERP reporting capabilities have begun to evolve as ERP vendors have tried to increase the accessibility and ease of use of the ERP software.

ERP Reports

Enterprise resource planning systems can generate a wide range of standard reports that are designed to meet standard decision-making concerns. The reports that are available depend on the particular module of interest. For example, financial modules produce classic financial reports, including income statements and balance sheets.

However, ERP reports do not always meet the users' needs, as will be seen in a number of examples in this chapter.

The primary tools for capturing and implementing best practices are enterprise resource planning (ERP) systems. As noted by Hammer (1997), “SAP implementation equals forced reengineering.” A vice-president of Cap Gemini remarked that, regarding SAP implementations, “it's rare when you don't have to do some kind of reengineering” (Gendron 1996). Gendron goes on to call ERP “the electronic embodiment of reengineering.” Because reengineering is so tightly tied to ERP implementation, firms must address the issue of using clean slate versus technology enabled reengineering.

The purpose of this chapter is to investigate the relationship between these two types of reengineering. In particular, this chapter elicits some of the advantages and disadvantages of each approach, focusing on why some firms have chosen one or the other approach as part of their reengineering efforts. In addition, this chapter investigates some of the firm characteristics that are likely to lead to using a particular reengineering approach.

Reengineering Tools and Technologies

Hammer's (1990) ideas for reengineering were initiated before there were tools to facilitate reengineering. Many early reengineering efforts were designed to “obliterate” existing processes, but there were few tools to guide firms as to how the processes should be reengineered. As a result, one of the primary reasons that many reengineering efforts failed was the lack of a sufficient tool set to facilitate reengineering. An early analysis (CSC Index 1994) of tools that were used in reengineering focused on process value analysis, benchmarking, competitive analysis, and activity-based costing.

One of the most important issues in the ERP engagement is training. According to the CIO of Brother Industries, “[t]he easiest mistake to make is underestimating the time and cost of training end users” (Fortune 1998, p. 151). An implementation will be a failure if the software runs perfectly, but employees don't know how to use it. Despite the importance associated with the need for ERP training, a Benchmarking Partners survey of 150 sites found that 43% indicated that the amount of training was the biggest surprise encountered (Stedman 1998b).

However, training encompasses more than just users; the training concerns of implementors must also be addressed. Moreover, training is not simply one step in the life cycle just before or just after implementation. Rather, training is embedded in each part of the life cycle. We therefore discuss training within its own chapter.

Frequently Asked Questions about User Training

• How should user training be timed?

• How much training should users get?

• How do you make up time lost on training?

• When should you train?

• How can employees be encouraged to train?

• How much should training cost?

• What is in the training materials: information technology or rather business information?

• Should you use script-based or general support materials?

• How should training be structured?

• Can faster training be developed?

“Phased” and “big bang” are the two primary (and contrasting) approaches used to implement ERP systems. This chapter investigates what these terms mean, some properties of each approach, and some of the advantages and disadvantages of each. This chapter also analyzes the choice of the implementation methodology in light of organization size, complexity, and structure and in terms of the overall extent of the implementation. Finally, some additional terms and approaches used to implement ERP systems are discussed briefly.

What Is a Big-Bang Implementation?

In a full big-bang implementation, an entire suite of ERP applications is implemented at all locations at the same time. Using big bang, the system goes from being a test version to being the actual system used to capture transactions in only a matter of days (hence the name “big bang”). Big bang requires simultaneous implementation of multiple modules. In the case of Quantum (see the appendices of this chapter), this meant implementing 17 modules of Oracle applications at 23 sites around the world over a period of about one week. Under this scenario, big bang requires a large amount of testing before cutting over from legacy systems to the new system. In the case of Quantum, this meant six to eight months of system testing prior to going “live” and actually using it to process transactions.

This chapter analyzes some of the different rationales associated with deciding to go with ERP. In particular, this chapter examines four questions.

1. (1) What are the business case rationales used for determining whether or not to go ERP, and which are most frequently used?

2. (2) How can business case rationales be used to facilitate design or measure success?

3. (3) How do firms measure rationales: in monetary or nonmonetary terms?

4. (4) How does a firm ultimately decide to go ERP?

Business Case Rationales

Business case rationales for ERP systems can be grouped into four different sets of categories: technology, business process, strategic, and competitive. Each of those rationales has different strengths and limitations. This chapter illustrates rationales from each category.

The choice of business case rationale is important for at least three reasons. First, critical analysis is necessary to ensure that the firm makes the correct decision regarding ERP. Ultimately, that analysis can generate a number of different rationales or arguments used to substantiate ERP adaptation. Second, in some cases, the basis of choice can facilitate ERP design, providing design specificity. For example, if the goal is to improve a specific process then the extent of that improvement can be measured. Third, the basis of choice can facilitate evaluation of the success of the implementation, based on whether the business case rationale was successfully met. Different measurement approaches can provide a basis for determining success.