European Journal of Information Systems (2005) 14, 324–334 & 2005 Operational Research Society Ltd. All rights reserved 0960-085X/05 $30.00 www.palgrave-journals.com/ejis
Understanding misalignment and cascading change of ERP implementation: a stage view of process analysis Hsiao-Lan Wei, Eric T.G. Wang and Pei-Hung Ju Department of Information Management, School of Management, National Central University, Chung-Li, Taiwan, ROC Correspondence: Eric T.G. Wang Department of Information Management School of Management, National Central University, Chung-Li, Taiwan 32054, ROC. Tel: þ 886 3 4267265; Fax: þ 886 3 425 4604; E-mail:
[email protected]
Abstract When adopting an enterprise resource planning (ERP) system, experiencing misalignments between the functionality offered by the package and that required by the firm is common. Implementing an ERP package often necessitates disruptive organizational change, and the outcome of implementation is largely determined by the resolution of misalignment problems. This study draws upon data from a case study to understand the misalignments of ERP adoption and the associated change dynamics from a stage view. The results reveal that industry-, company-, and regulation-specific misalignments often occurred in the chartering phase; misalignments of input, control, data, process, output, and schedule are the major problems in the project phase; misalignments of information and new business requirements are the main concerns in the shakedown phase and onward and upward phase. The cascading effects of misalignments and change actions are illustrated, the misalignment resolution strategies examined, and the implications discussed. European Journal of Information Systems (2005) 14, 324–334. doi:10.1057/palgrave.ejis.3000547 Keywords: enterprise resource planning system; misalignment; organizational change; cascading effect
Introduction
Received: 26 January 2005 Revised: 24 May 2005 Accepted: 30 August 2005
Enterprise resource planning (ERP) software has received much attention from both practitioners and academics (Hitt et al., 2002; Robey et al., 2002; Stratman & Roth, 2002). The key selling points of ERP are the integration across enterprise, the inherent best practices for different industries, and the flexibility to meet diverse requirements of multiple organizations (Davenport, 1998; Soh et al., 2003). ERP systems are beneficial because they can provide not only information technology and operational benefits but also strategic advantage (Shang & Seddon, 2002). However, the hidden costs of ERP implementation may hinder the claimed advantages (Robey et al., 2002). The implementation costs sometimes are several times the cost of software licenses (Davenport, 2000; Shang & Seddon, 2002). ERP investments are also risky because the projects often escalate budgets and the failure rate reported is three quarters high (Robey et al., 2002). The high cost and failure rate of ERP implementation may stem from the required mutual adaptation between an ERP system and the organization it supports (Hong & Kim, 2002; Soh et al., 2003; Luo & Strong, 2004). Although ERP systems claim to support a broad range of business processes (Scott & Kaindl, 2000), the
Misalignment and cascading change of ERP implementation
misalignments between the functionality offered by a package and that required by the adopting firm are common (Soh et al., 2000). As ERP systems require organizations adapt their business processes to the software (Gattiker & Goodhue, 2002), underestimating the effort of change management may cause an ERP implementation failing to achieve the anticipated benefits (Stefanou, 2001). Since resolving misalignment problems usually requires both technology and organizational changes, researchers have suggested combining both ERP customization and organizational change as a mutual adaptation approach to ERP implementation (Leonard-Barton, 1988; Hong & Kim, 2002; Luo & Strong, 2004). Although a number of studies have addressed various issues related to ERP (e.g., Al-Mudinigh et al., 2001; Akkermans & van Helden, 2002; Stratman & Roth, 2002; Ash & Burn, 2003; Bagchi et al., 2003; Somers & Nelson, 2004), there is limited research concerning ERP misalignment problems. Soh et al. (2000) identified misalignments as the incompatibilities between organizational requirements and ERP software in terms of data, process, and output. Misalignments may also be viewed as opposing structural forces between an ERP system and the implementing organization (Soh et al., 2003). An organization often needs to change its structures to align with those embedded in the software. Such change often results in a dramatic impact on the organization. As misalignments can lead to disruptive organizational changes and extreme difficulties in ERP implementation, there is a clear need to understand the dynamics of the adaptation process. A process approach sees ERP implementation as a sequence of stages and seeks to explain how and why change emerges, develops, and diminishes over time (Markus & Robey, 1988; Markus & Tanis, 2000; Somers & Nelson, 2004). Different dominating perceptions at each stage may help interpreting the problems arising from ERP implementation (Besson & Rowe, 2001). While previous research has identified the important factors, issues, and impacts when implementing an ERP system, a process approach is neglected in studying the misalignment problem. Therefore, the nature of misalignments and their influence on organizational change need more in-depth investigation. This paper reports findings from a case study of ERP implementation. The objective is to understand the misalignment problems and the related change actions from a process view of Markus & Tanis (2000). We first report the misalignment problems and the ways they were resolved in each phase of ERP implementation. Then, the cascading effects of misalignments and change actions across different phases as well as within a phase of ERP implementation are illustrated and the dominant change drivers causing the cascading effects are analyzed. A discussion on the implications of the findings concludes the paper.
325
Hsiao-Lan Wei et al
Conceptual background Misalignments and organizational change in ERP implementation Misalignments arise from company-specific, sector-specific, or country-specific requirements that an ERP package does not support and can be clustered into data, process, and output (Soh et al., 2000). Resolving misalignment problems, however, is a complicated task involving the mutual adaptation between an ERP system and the processes and structures of the adopting organization (Hong & Kim, 2002; Soh et al., 2003; Luo & Strong, 2004). In fact, misalignments are important as the evaluation criteria in selecting an ERP system (Everdingen et al., 2000) can critically impact the ultimate success of an ERP implementation (Hong & Kim, 2002; Robey et al., 2002). As misalignment resolution strategies are based on a spectrum from ERP customization to organizational change, the degree of organizational change is heavily influenced by the resolution strategies adopted (Soh et al., 2000). When an organization adapts some business processes to fit the ERP practice, the adaptation will influence not only existing business processes but also other organizational components (Hong & Kim, 2002). For example, organizational integration enabled by an ERP system’s shared database may induce changes in job responsibility and business processes. Such changes may further cause unpredictable and involuntary changes (Hong & Kim, 2002). As Leonard-Barton (1988, p. 252) suggests, ‘the adaptation process is not a predictable realization of a preprogrammed plan.’ Instead, it is an extension of the innovation process with a dynamic and emerging nature. Research has investigated the possible misalignment resolution strategies by focusing on business process change (Gattiker & Goodhue, 2002), tailoring ERP systems (Brehm et al., 2001), or both (Soh et al., 2000; Hong & Kim, 2002; Luo & Strong, 2004). Business process change may cause incremental or radical change (Luo & Strong, 2004). The incremental change results from workarounds with an ERP system or compromising on organizational requirements (Soh et al., 2000). The radical change stems from adopting the processes embedded in an ERP system (Soh et al., 2000). This stream of research focuses mainly on business process change, but other organizational changes (e.g., change strategy and individual/role change) have not been studied as misalignment resolution in the ERP research. Of course, tailoring a system to provide the required functionality has the lowest impact on organization (Soh et al., 2000). Choices of system tailoring include configuration, bolts-ons, screen masks, extended reporting, workflow programming, user exits, ERP programming, interface development, and package code modification (Brehm et al., 2001). However, the integrative nature of ERP allows little software modification and imposes many constraints on implementation. The technology changes caused by customization may also affect future
European Journal of Information Systems
326
Misalignment and cascading change of ERP implementation
maintenance, upgrade, and conversion of the system (Luo & Strong, 2004). Consequently, companies typically use various combinations of technology change and organizational change to resolve misalignment problems. Individual/role, management processes, and implementation strategy are possible organizational changes induced by ERP misalignments. Combining with the stage view discussed in the next section, the mutual adaptation of technology and organization can be more fully understood.
A stage view of ERP implementation When viewing organizational change as a continuous process in context, the time frame of analysis is important for understanding the change dynamics (Pettigrew, 1990; Van de Ven & Huber, 1990). Since a stage model can provide rich information for analyzing problems and outcomes both retrospectively and prospectively, many ERP researchers have adopted this view to investigate ERP projects (Markus et al., 2000; Besson & Rowe, 2001; Holland & Light, 2001; Stefanou, 2001; Rajagopal, 2002; Somers & Nelson, 2004). Markus & Tanis (2000) suggested four phases for the enterprise system experience cycle: the chartering phase, the project phase, the shakedown phase, and the onward and upward phase. The chartering phase is the stage of evaluating, selecting, and budgeting for initiating ERP adoption. The project phase is the main stage of a formal ERP project with a well-established project team. The goal of the shakedown phase is to get the ERP system into normal operations after going live. The onward and upward phase continues from normal operation until the system is replaced by an upgrade or a different system, and this phase is the stage in which the organization can ascertain the benefits of the ERP system. Besson & Rowe (2001) focused on the enactment process that takes place within the ERP phases and demonstrated the changing perceptions of each new actor involved in an ERP project. Stefanou (2001) developed a framework for the ex-ante evaluation of ERP systems and identified potential costs and benefits associated with ERP lifecycle phases. Rajagopal (2002) used a stage model to study the contextual factors that influence ERP implementation. Somers & Nelson (2004) investigated the role of key players and activities across ERP project lifecycle. These studies reveal that the critical issues in different phases of ERP implementation are likely to be different. Since the misalignment problems experienced in different phases of the ERP lifecycle may be distinct, certain type of resolution strategies may be prevalent in one phase but not in others. It is therefore important to uncover the dynamics of misalignments and changes across the phases of an ERP project, making stage models more appropriate for analyzing ERP implementation. This study attempts to understand such dynamics based on the emergent process view of Markus & Tanis (2000). Although previous studies have applied the model to understanding other issues related to ERP implementa-
European Journal of Information Systems
Hsiao-Lan Wei et al
tion (e.g., Markus et al., 2000; Besson & Rowe, 2001), we extend this line of research by investigating the misalignment problem and organizational change in each phase as well as across phases of ERP implementation.
Methods Case and data collection To explore the dynamic nature of misalignment and organizational change in ERP implementation, a single case study was conducted. A qualitative approach was chosen due to the lack of prior research on the dynamics of misalignment, the desire to understand the organizational change during the ERP implementation lifecycle, and the sensitive nature of the data needed (Yin, 1984). The case site was selected based on a combination of accessibility and representativeness. How many and how important the misalignment problems encountered in the ERP implementation are the criteria for case selection. The case is an electronic manufacturing company, with headquarters in a Taiwan Science Park. We use the pseudonym ElectronicCo to represent the company. ElectronicCo is one of the world’s leading contract manufacturers that provide foundry service in the electronic industry. Key department users in this project were logistics- and finance/accounting-related staffs. The company had adopted modules of FI (Financial Accounting), CO (Controlling), and MM (Material Management) from SAP and was in the onward and upward phase when interviewed. Table 1 lists and explains the SAP modules that had been evaluated or implemented by ElectronicCo. The periods of chartering, project, shakedown, and onward and upward phases took about 3, 6, 3, and 14 months (till the month we interviewed), respectively. The 3-month shakedown phase, however, is a rough estimate, as it is very difficult for the interviewees to distinguish it from the onward and upward phase in practice. In fact, the best estimates provided by the interviewees ranged from 3 weeks to 5 months. Consequently, we consider the shakedown and onward and upward phases together to represent the period after the ERP system had gone live. Data were collected primarily from in-depth interviews with the managers of information systems department and user departments. To minimize single informant biases, interviews were conducted with the ERP core team members, including six managers from departments of information systems, accounting, purchasing, and material management. All the interviewees had worked for the company for more than 5 years. The interviews lasted about 2 h on average. The same investigator conducted all the interviews at the company site from May 2 to May 21 in 2002. Preprinted interview guide was prepared and used by the interviewer during each interview. Following each interview, the notes were summarized and captured in a data repository for later analysis. One of the coauthors who did not conduct the interviewees was authorized to read the documents and meeting notes of the ERP project in ElectronicCo’s Notes system with
Misalignment and cascading change of ERP implementation
Table 1 SAP module
327
Hsiao-Lan Wei et al
SAP modules evaluated and implemented in ElectronicCo
Function
FI (Financial Accounting) CO (Controlling)
MM (Material Management) SD (Sales and Distribution) PP (Production Planning and Control)
Evaluated
Process and manage accounting data Provide information such as costs and revenues for management decision-making Manage material planning, purchasing and inventories Manage sales and distribution of products and services Manage production plans, including demand forecasting, material requirement planning, capacity planning, and lot planning Control production process, including production order, KANBAN, repetitive manufacturing, etc.
Yes Yes Yes Yes Yes
Implemented Yes Partial (excluding CO-PAa) Yes No no
a
CO-PA is the profitability analysis sub-module of controlling.
accompanied IS personnel. The data were used only for triangulation.
Research findings: the misalignments and change actions of ERP Chartering phase Evaluating and selecting an ERP package is the main activity in the charting phase. Key players in this phase included competing vendors, consultants, company executives, user representatives, and IT specialists. The executives formed a steering committee as a mechanism to facilitate cross-functional communication and integration and to provide directions. Consultants, key users, and IT specialists examined both the functionality offered by the candidate ERP systems and that required by the company to deliver gap analysis reports. Misalignment problems in the chartering phase are often industry-, business- or regulation- specific. An interviewee noted that the ERP system did not have the ‘best practice’ and appropriate business models for their industry: ‘The system was originally designed for assembly manufacturers, and thus cannot be applied to our build-toorder business model.’ Another interviewee also noted: ‘Some modules like asset management can only be partially utilized because the cost calculation function does not meet our requirement. Our current cost function provides greater visibility for decision makers because we control and analyze cost at every stage of a manufacturing process, which typically comprises at least hundreds of operations.’ Implementing those unfitted modules is unlikely to be successful under such circumstances. In addition to industry- or business-specific misalignment problems, ElectronicCo also encountered other problems related to regulation and infrastructure. For example, the local regulation of joint credit loan forced the company to give up the CO-PA (Controlling-Profitability Analysis) sub-module. As a manager pointed out, ‘in Taiwan, the interest of joint credit loan is calculated by and paid to individual banks, but the rule in SAP is decided by the leading bank representing the group of banks.’ A problem related to infrastructure was the workflow module. As
ElectronicCo had already used a system on Notes workflow for procurement, the operation was difficult to be transferred to the SAP workflow. The resolution strategies for the misalignment problems in the chartering phase were to select the most appropriate ERP system and adopt the modules that their extents of misalignment were acceptable. Misalignment problems forced ElectronicCo to implement only selected modules to avoid unnecessary process changes and too much customization. For example, all modules related to production were not implemented, since from the company’s perspective, SAP did not have the best practice for the manufacturing processes of ElectronicCo. This also influenced the adoption of other modules highly related to the unselected production modules. An interviewee remarked that SAP-SD (Sales and Distribution) and SAP-PP (Production Planning and Control) modules did not provide many specific functions required for the production process of foundry service so they decided to retain the legacy systems. As she comments: ‘We also liked to use the SAP-PA module but it is dependent on the SAP-PP module, which we did not select.’ Therefore, only modules related to purchasing, material management, accounting, and cost management were implemented. With the goal of selecting the most fitted ERP system, the charting team concentrated on the possibility of tailoring an ERP system, instead of modifying the company’s business processes, in order to minimize organizational changes. The charting team examined the explicitly identified misalignments and evaluated the possible workarounds and modifications on the selected modules. Limiting the extent of organizational change seemed to be an appropriate resolution strategy at this stage. This strategy, however, did not resolve all the misalignments at the operational level, resulting in many unanticipated problems in subsequent phases. For example, implementing only selected modules caused the incomplete information problem, reduced system integrity, and required extra add-on programs to interface with the legacy systems. The misalignment problems and change actions in the chartering phase are summarized in Table 2.
European Journal of Information Systems
328
Misalignment and cascading change of ERP implementation
Table 2
Hsiao-Lan Wei et al
Change practices to overcome misalignment problems in each phase
Phase
Misalignment type
Technology change
Organizational change
Chartering
Industry-, business-, and regulation-specific
Selecting an ERP Selected modules
Implementation strategy
Project
Input
Individual/role
Schedule
Screen masks Interface development Extended reports Extended reports Workflow programming Interface development Configuration Bolt-ons User exits Interface development ERP programming Substitution field Extended reports None
Information
Enhancement of the ERP system
Individual/role
Functionality
Extended reports ERP programming
None
Report Flow control
Business process and operation
Data
Shakedown/onward and upward
Project phase In the project phase, a formal team, including consultants, IS specialists, programmers, and key users, was formed and responsible for getting the ERP system up and running. The top management of ElectronicCo set a 6month deadline to finish the implementation. With such a constraint, the team tended to adopt the standard ERP processes and change their business processes. Although the misalignments suggested by Soh et al. (2000) all occurred in this phase, the company, however, strictly controlled the requests for customization and add-on programs, and some excluded requests were planned to be resolved after the system went live. As the ERP package might be configured to numerous business cases, the data input screens designed for general purpose were not user friendly or convenient for ElectronicCo users. In the past, users could update purchasing price master records by entering multiple items on one screen, but the ERP system allowed users to enter only one record at a time, reducing user work efficiency. Another problem was related to input formats. With the ERP system, users often needed to enter five or six fields on one screen and then switched to the next screen to enter another five fields. Such incompatibilities in input formats were the major concern of many users. Project team members also encountered misalignment problems in data and report formats. The shorter length of some specific fields and the lack of some business fields in the ERP system were the common problems. It was also time-consuming to find a matched field from the complicated table definitions in the system. An inter-
European Journal of Information Systems
Individual/role Management process Individual /role Business process Individual/role
Individual/role Implementation strategy
viewee noted that it was very important to use candidate fields carefully as the field names should be understandable by the users to avoid mistakes. Another problem was that the ERP system’s standard reports were often incompatible with the required formats. Hundreds of reports were insufficient to support the company’s requirements either in presentation or in information content. Missing the required functionality in the ERP system was the most critical problem in the project phase. The system did not support the functions required by certain important business operations such as commercial investment offset management, import management, and management of bonded goods. As those processes are the integrative parts of purchasing and material management, they should be linked together in the ERP system. ‘It is important to receive goods that already have import records, and then match them back with the original purchase orders,’ an interviewee noted. The insufficient functionality affected not only the business processes but also the flow control mechanisms of the company. ElectronicCo needed to set control points and criteria in the ERP system and validated whether a transaction could be preceded or not. However, the system could not be configured to meet such flow control requirements. The 6-month schedule for the ERP system to go live was very difficult to meet according to the ERP consultants. As completing implementation according to plan has become a key success indicator of ERP implementation in Taiwan, top management of ElectronicCo did not allow any extension of the schedule. The misalignment
Misalignment and cascading change of ERP implementation
between the company’s target schedule and the one estimated by the consultants (schedule misalignment) also became a problem in the project phase. As ElectronicCo intended to adopt the standard ERP practices in this phase, the strategies for resolving the misalignments determined the extents and types of organizational change. According to the interviewees, the change could be categorized into technology, strategy, structure, process, and individual and role (Hsiao & Ormerod, 1998). One misalignment problem might require several actions, which in turn induced different types of change (see Table 2).
Technology change The third column in Table 2 shows that different tailoring choices could be used to overcome a certain misalignment problem. These tailoring choices are illustrated based on Brehm et al. (2001), including configuration, bolt-ons, screen masks, extended reporting, workflow programming, user exits, ERP programming, interface development, and package code modification. At this stage, although ElectronicCo preferred to adopt the standard ERP functions, it still was impossible to avoid certain technology change. To reduce technology change, ElectronicCo developed add-on programs only when the functions were not provided by the ERP system and were highly interdependent with the implemented modules. For example, ElectronicCo developed its own modules for commercial investment offset management, import management, and management of bonded goods with the computer language of SAP. A third-party module developed specifically for the industry and certified by SAP was also adopted to resolve some of the industry-specific misalignments. For those functions independent of the integrated transaction flows, they might be supported by programs developed by other computer languages (e.g. Visual Basic). For example, a front-end program and the related interfaces were created to allow users to process the master structures of purchasing price by batch. Extended reporting and interface development were two frequently applied change practices by ElectronicCo in the project phase. The company developed more than 100 programs to provide a variety of output contents, formats, and options. While most of the technology changes for reducing output misalignments required the reproduction of existing reports, there were some newly created reports for resolving control problems induced by the ERP system. For example, the ERP system allowed receiving goods without the corresponding importing records. Consequently, ElectronicCo asked the staff to run an importing report in order to manually verify the related importing records before receiving the goods. For problems of data length and lack of required fields, the only easy resolution was to use substitution fields. For example, ElectronicCo required a ‘format code’ field to be used in one module and the consultants suggested the information be recorded in a referent field. The rounding problem occurred in partial receivables or payments,
Hsiao-Lan Wei et al
329
however, it was not so easy to resolve. As the ERP system provided only three digits in the decimal fields, a monitoring report had to be generated for checking the data consistency of purchase orders and payments.
Organizational change The last column in Table 2 shows the different organizational changes for overcoming certain type of misalignment problems. Since changing business processes was promoted as an approach to enhancing business capability through the best practices of ERP, ElectronicCo made a high degree of process change in the project phase. Many previously unlinked processes were changed to become the integrated parts of a seamless process. For example, purchase orders (PO) and payment processes, which had not been linked together before and relied on manual operations, were integrated in the ERP system. Nevertheless, process change sometimes was just to compromise on the ERP adoption. For example, in ElectronicCo, the rule is to reject a PO when the amount of the PO is over budget. However, it just wants to show a warning message instead of rejecting an RG when the amount of the RG is over budget because of the fluctuation of currency exchange rates. The ERP system, however, treated these processes as a whole and the action could only be set as either ‘reject’ or ‘warning’ for both PO and RG. ElectronicCo had no choice but to set ‘warning’ for both PO and RG when they were over budget and created a post-checking report for monitoring the status of budgets. An interviewee also noted that the concepts embedded in the ERP system were very different from those used in ElectronicCo. New knowledge and concepts in the ERP system were the major reasons why almost every type of misalignment problems required individual/role change (see Table 2). Adaptation to an ERP system influenced the job contents, responsibilities, and behaviors of employees. For example, the new input functions changed the data entry behaviors of employees and the flow control problems required additional manual checking points. Moreover, the responsibility of a task might be transferred from on department to another. For example, in the past, accounting department owned the responsibility to ask investment offset information from vendors, but it became the responsibility of the purchasing department after implementing the ERP system. The schedule problem could only be resolved by delaying the rollout of the investment offset management module. This decision changed the original ERP implementation scope. Under the time pressure, rolling out the system by phases seemed to be a good choice for adhering to the implementation plan. Shakedown/onward and upward phases Since the estimated shakedown phase was only 3 months on average and could not be easily separated from the onward and upward phase, these two phases are analyzed together. The goals of these phases were to achieve normal operations with the ERP system.
European Journal of Information Systems
330
Misalignment and cascading change of ERP implementation
The major misalignment problems in the shakedown/ onward and upward phases were deficient decisionsupport information for management and insufficient functions for supporting new business requirements. One of the accounting managers described: The information for decision-making needs to be accurate and timely, but this depends on the users in the process flows. The system requires the users to update the data once an event occurs, so the users at the first stage of any process flow may be heavily loaded for entering the data to be used by other departments. It is also very hard to know whether or not they have already updated the data, and this uncertainty makes the information unreliable.
The information problem resulted from the decision to adopt selected modules and the need for the ERP system to interface with many legacy systems. On the one hand, the selected modules determined what information was available; one the other hand, the need to interface with other systems affected the quality of the information. In the company, too many interfacing programs resulted in inaccurate and untimely information. The information about purchase requisition (PR), for example, would not be available until it had been finally approved and then transferred from the Notes workflow system into the ERP system. Some of the misalignment problems were unanticipated or unnoticed because the project team did not have the knowledge to discover them or because the knowledge had long been embedded in organizational rules and systems. For example, ElectronicCo allowed a transaction to span across 2 years, but the ERP system did not support this and even prohibited reversing the data from previous years. This problem was not identified until the system had been in operations. Some other problems were resulted from the attitudes of end users. For example, account payables could be paid automatically by using due dates as the criteria in the ERP system, but ElectronicCo decided to do this manually because the users worried that the ERP system might issue wrong payments. The resolution strategies for the misalignments in the shakedown/onward and upward phases relied on enhancement of the ERP system, extended reports, add-ons, and individual/role change. As a result, extended reports and add-on programs increased explosively. An accounting manager noted that the number of add-ons increased from one hundred to two hundreds. She added, ‘before the system went live, the rules to add a program were very strict because adopting the standard ERP system was set as the highest priority, but things became different later. The first few months to use the system were really a mess. Under such circumstances, requests for adding programs to fix bugs, urgent problems, and improper operations were allowed easily.’ The total add-on programs eventually reached six hundreds, far exceeding the number in the project phase. Obviously, different resolution strategies for a misalignment problem could have different impacts on
European Journal of Information Systems
Hsiao-Lan Wei et al
required organizational change. The decisions in one phase might also affect those in the next phase and beyond. Analyzing the misalignment problems and the associated change dynamics across project phases and within one phase helps us understand how and why the misalignment problems and changes occurred. This is the focus of the next section.
Cascading effects of misalignment and change Markus & Tanis (2000) argued that the misalignment and resolution actions of one point in time might be originated from the misalignments and resolution strategies in previous stages. Consistent with the common wisdom of software engineering, the cost of fixing misalignments increases with delays in problem discovery and resolution (Markus & Tanis, 2000). Thus, it is necessary to analyze the case across phases for understanding the cascading nature of misalignments and their resolutions in ERP implementation. The cascading effect within one phase is also illustrated. Cascading effects across different phases In describing their misalignment problems and resolutions, most managers mentioned that the alternatives they had were often constrained by the decisions in previous phases. The implementation of an ERP system is a set of pathdependent processes, and the interactions of various factors in one phase will result in the starting conditions for the next (Markus & Tanis, 2000). Table 3 illustrates a typical example of the cascading effect of misalignment and resolution across phases. It demonstrates the cascading effect of technology change from the chartering phase to the onward and upward phase. In the chartering phase, ElectronicCo decided not to use the workflow module of the ERP system. This, however, created process misalignment problems in the project phase. In ElectronicCo, purchase requests need to be approved by departments at different levels and then handled by the purchasing department after final approval. As the ERP system could not support this process, the company developed a PR application with the workflow engine on Notes platform and created interface programs to transfer the approved PR data into the ERP system. This, however, created report misalignment problem later in the shakedown/onward and upward phases. The lack of real-time PR information made the available budgets inaccurate. The problem was not solved until ElectronicCo had adopted the OLAP tools and the data warehouse system and enhanced the functionality of the ERP system. Obviously, adopting only selected modules to resolve business misalignment problems in the chartering phase might induce other misalignment problems and related technology changes in later phases. Cascading effects within one phase Even in the same phase, the cascading effect of misalignment and change could still be observed because change in one organiza-
Misalignment and cascading change of ERP implementation
Table 3
Phase
Example of cascading effect of business misalignment
Misalignments / Resolutions
Description
Business misalignment
The workflow module of the ERP system was not satisfactory to support the business requirements.
Technology change (adopting selected modules)
The workflow module of the ERP system was not selected.
Process misalignment
The adopted ERP system could not support the workflow process of purchase requisition (PR).
Technology change (interface development)
Developing a PR application with the workflow engine on Notes platform and creating interface with the ERP system
Chartering
Project
Shakedown/ onward & upward
331
Hsiao-Lan Wei et al
Report misalignment (Insufficient decision support information)
Technology change (system upgrade)
: misalignment
The lack of real time PR information made the available budget in ERP inaccurate. Enhancing the functionality of the ERP system to integrate transaction data into the data warehouse system and creating analytical reports from the OLAP tools.
: resolution
tional component might also cause changes in other organizational components (Hammer & Stanton, 1999). As shown in Table 4, ElectronicCo decided to roll out the system by phases to resolve the schedule misalignment problem. The postponement of the investment offset module created process misalignment problems. The local tax regulation required ElectronicCo integrate the processes for purchasing order and investment offset management, which could not be supported by the ERP system. To ensure transaction integrity, interfacing with the legacy investment offset system was a temporary solution. However, this created another misalignment problem in reporting. As the ERP system did not have the investment offset data, generating reports using the ERP system’s report writer was not viable. The resolution strategy was to pull data from both the ERP system and the legacy system and then downloaded the data into Excel to generate the required reports. This strategy, however, had created many additional manual as well as paper works. According to our case study, Table 5 summarizes the major change actions taken and the generating forces
: cascading effect
behind these changes in each phase of ERP implementation. Technology change is the most common choice in the chartering, shakedown, and onward and upward phases. In general, organizational change is considered as a viable resolution strategy only when necessary and occurs dynamically in the project phase. These results reveal that in the chartering phase, organizations still retain the mind-sets associated with the experiences of their business processes and in-house information systems. Such conservatism often dominates the strategies for misalignment resolution. Consequently, selecting the most fitted ERP system and adopting the modules with acceptable misalignment are the typical strategies. The frames of reference, however, may switch in the project phase as time pressure pushes the project to move on. To quickly push the ERP system to go live, organizational changes in process, individual/role, and strategy can all become acceptable and numerous programs and reports may be added in the shakedown/ onward and upward phases. These are caused in part by the cascading effect of misalignment and organizational change.
European Journal of Information Systems
332
Misalignment and cascading change of ERP implementation
Table 4
Hsiao-Lan Wei et al
Example of cascading effect of schedule misalignment in the project phase
Misalignments /Resolutions Schedule misalignment
Half-year schedule was not enough to implement the ERP system
Strategy change (rolling out by phases)
Implementing investment offset module in the next phase
Process misalignment
Table 5
Description
The local tax regulation required ElectronicCo integrate the processes of purchasing order and investment offset management and could not be supported by the ERP system.
Technology change (interface development)
Interfacing with the legacy investment offset system
Report misalignment
The lack of investment offset information made some reports unavailable
Technology change (extended reports)
Pulling data from both the ERP system and the legacy system and downloaded the data into Excel to generate the required reports.
Change actions and generating forces in the phases of ERP implementation
ERP phase
Chartering
Project
Shakedown/onward and upward
Major change actions
Technology
Technology change
Dominant change drivers
Conservatism
Technology change Organizational change Time pressure
Conclusion Misalignment problems are the most difficult challenges in ERP implementation, given the complex and integrative nature of the ERP system. This study investigates the misalignment problems of adopting an ERP system from a stage view and analyzes the resulting technology and organizational changes based on the interview data from an electronic company in Taiwan. As illustrated by the case, since a resolution strategy may induce technology as well as organizational changes, change management should be a critical issue in ERP implementation. The cascading nature of misalignment and change suggests
European Journal of Information Systems
Users requests Performance criteria
that managers should not underestimate the efforts required for managing change (Robey et al., 2002). Firms that are implementing or will implement an ERP system should deliberately manage misalignment and change at project initialization, focusing not only on current misalignment and change actions but also on their potential cascading effects. Our study also suggests that different change drivers tend to dominate in different phases. The transition of change drivers sometimes represents a fundamental shift in the appropriate strategies for misalignment resolution. Thus, the mutual adaptation process between the
Misalignment and cascading change of ERP implementation
technology and the organization is far from a planned change and the outcomes of the process are difficult to predict. This finding is consistent with previous studies asserting that actors cannot anticipate many of the technology-caused organizational effects (Besson & Rowe, 2001), and that trying to control certain effects will induce other unpredictable impacts (Markus, 1994). The ERP implementation process appears discontinuous because the change drivers are inconsistent and to some extent contradictory across project phases. In our case, conservatism determined the adopted ERP system and the associated modules and the time pressure in project phase led the company to pursue the strategy of minimizing technology change. However, after the ERP had gone live, the main change drivers shifted to users who demanded both organizational and technology changes. ERP project management can benefit from identifying the change drivers and managing the inconsistencies between different change drivers. As such, the benefits promised by the ERP system may be more easily obtained with acceptable cost and risk.
Hsiao-Lan Wei et al
333
Although this study has provided some preliminary evidence that different ERP project phases are likely to encounter different misalignment problems and thus demand different resolution strategies, further study is needed to identify other factors that may also influence the choice of resolution strategy from other theoretical perspectives. The causes of cascading effect may also be viewed from the organizational ecology perspective, which argues that a cascade of changes arising from a search-andadjustment process can reduce the core violations induced by an architectural change (Hannan et al., 2003). Of course, more comprehensive and in-depth investigation into the issues addressed in this study is still needed.
Acknowledgements This research is supported by MOE Program for Promoting Academic Excellent of Universities under the grant number 91-H-FA08-1-4.
About the authors Hsiao-Lan Wei is a Ph.D. candidate at the Department of Information Management, National Central University, Taiwan (ROC). Her research interests include enterprise resource planning, organizational learning, and supply chain management. Her research will appear in Total Quality Management and Business Excellence and others. Eric T.G. Wang is Professor and Dean of School of Management at National Central University, Taiwan (ROC). He received the Ph.D. degree in Business Administration, specialized in computer & information systems, from the William E. Simon Graduate School of Business Administration, University of Rochester. His research
interests include electronic commerce, outsourcing, organizational economics, and organizational impact of information technology. His research has appeared in Information Systems Research, Management Science, Decision Support Systems, Information Systems Journal, Information & Management, Omega, European Journal of Operational Research, International Journal of Information Management, and others. Pei-Hung Ju is a Ph.D. candidate at the Department of Information Management, National Central University, Taiwan (ROC). His research interests include IS project management and IS personnel.
References AKKERMANS H and VAN HELDEN K (2002) Vicious and virtuous cycles in ERP implementation: a case study of interrelations between critical success factors. European Journal of Information Systems 11(1), 35–46. AL-MUDINIGH A, ZAIRI M and AL-MASHARI M (2001) ERP software implementation: an integrative framework. European Journal of Information Systems 10(4), 216–226. ASH CG and BURN JM (2003) Assessing the benefits from e-business transformation through effective enterprise management. European Journal of Information Systems 12(4), 297–308. BAGCHI S, KANUNGO S and DASGUPTA S (2003) Modeling use of enterprise resource planning systems: a path analytic study. European Journal of Information Systems 12(2), 142–158. BESSON P and ROWE F (2001) ERP project dynamics and enacted dialogue: perceived understanding, perceived leeway, and the nature of taskrelated conflicts. The Data Base for Advances in Information Systems 32(4), 47–66.
BREHM L, HEINZL A and MARKUS ML (2001) Tailoring ERP systems: a spectrum of choices and their implications. In Proceedings of the 34th Annual Hawaii International Conference on Systems Sciences (SPRAGUE Jr RH, Ed), pp 8017–8025, IEEE Computer Society, Maui, Hawaii. DAVENPORT TH (1998) Putting the enterprise into the enterprise system. Harvard Business Review 76(4), 121–131. DAVENPORT TH (2000) Mission Critical – Realizing the Promise of Enterprise Systems. Harvard Business School Press, Boston, MA. EVERDINGEN Y, HILLERGERSBERG J and WAARTS E (2000) ERP adoption by European midsize companies. Communications of the ACM 43(3), 27–31. GATTIKER TF and GOODHUE L (2002) Software-driven changes to business processes: an empirical study of impacts of Enterprise Resource Planning (ERP) systems at the local level. International Journal of Production Research 40(18), 4799–4814. HAMMER M and STANTON S (1999) How process enterprises really work. Harvard Business Review 77(6), 108–118.
European Journal of Information Systems
334
Misalignment and cascading change of ERP implementation
HANNAN MT, Po´LOS L and CARROLL GR (2003) Cascading organizational change. Organization Science 14(5), 463–482. HITT LM, WU DJ and ZHOU X (2002) Investment in enterprise resource planning: business impact and productivity measures. Journal of Management Information Systems 19(1), 71–98. HOLLAND CP and LIGHT B (2001) A stage maturity model for enterprise resource planning systems use. The Data Base for Advances in Information Systems 32(2), 34–44. HONG KK and KIM YG (2002) The critical success factors for ERP implementation: an organizational fit perspective. Information and Management 40(1), 25–40. HSIAO RL and ORMEROD RJ (1998) A new perspective on the dynamics of information technology-enabled strategic change. Information Systems Journal 8(1), 21–52. LEONARD-BARTON D (1988) Implementation as mutual adaptation of technology and organization. Research Policy 17(5), 251–267. LUO W and STRONG DM (2004) A framework for evaluating ERP implementation choices. IEEE Transactions on Engineering Management 51(3), 322–333. MARKUS ML (1994) Finding a happy medium: explaining the negative effects of electronic communication on social life at work. ACM Transactions on Information Systems 12(2), 119–149. MARKUS ML, AXLINE S, PETRIE D and TAINS C (2000) Learning from adopters’ experiences with ERP: problems encountered and success achieved. Journal of Information Technology 15(4), 245–265. MARKUS ML and ROBEY D (1988) Information technology and organizational change: causal structure in theory and research. Management Science 34(5), 583–598. MARKUS ML and TANIS C (2000) The enterprise system experience – from adoption to success. In Framing the Domains of IT Management: Projecting the Future through the Past (ZMUD RW, Eds), pp 173–207, Pinnaflex, Cincinnati.
European Journal of Information Systems
Hsiao-Lan Wei et al
PETTIGREW A (1990) Longitudinal field research on change: theory and practice. Organization Science 1(3), 267–292. RAJAGOPAL P (2002) An innovation–diffusion view of implementation of enterprise resource planning (ERP) systems and development of a research model. Information and Management 40(2), 87–114. ROBEY D, ROSS JW and BOUDREAU M (2002) Learning to implement enterprise systems: an exploratory study of the dialectics of change. Journal of Management Information Systems 19(1), 17–46. SCOTT JE and KAINDL L (2000) Enhancing functionality in an enterprise software package. Information and Management 37(3), 111–122. SHANG S and SEDDON PB (2002) Assessing and managing the benefits of enterprise systems: the business manager’s perspective. Information Systems Journal 12(4), 271–299. SOH C, SIA SK, BOH WF and TANG M (2003) Misalignments in ERP implementation: a dialectic perspective. International Journal of Human-Computer Interaction 16(1), 81–100. SOH C, SIA SK and TAY-YAP J (2000) Cultural fits and misfits: is ERP a universal solution? Communications of the ACM 43(4), 47–51. SOMERS TM and NELSON KG (2004) A taxonomy of players and activities across the ERP projects life cycle. Information and Management 41(3), 257–278. STEFANOU CJ (2001) A framework for the ex-ante evaluation of ERP software. European Journal of Information Systems 10(4), 204–215. STRATMAN JK and ROTH AV (2002) Enterprise resource planning (ERP) competence constructs: two stage multi-item scale development and validation. Decision Sciences 33(4), 601–628. VAN DE VEN AH and HUBER GP (1990) Longitudinal field research methods for studying processes of organizational change. Organization Science 1(3), 213–219. YIN RK (1984) Case Study Research: Design and Method. Sage, Beverly Hills, CA.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
