Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
Supporting the Module Sequencing Decision in the ERP Implementation Process Petri Hallikainen, Harri Kimpimäki and Hannu Kivijärvi Helsinki School of Economics P.O. Box 1210, 00100 Helsinki, Finland, E-mail:
[email protected],
[email protected],
[email protected] Abstract An important part of the Enterprise Resource Planning (ERP) system implementation process is the decision, which modules are implemented and in which order. We posit that the decision of the module sequencing involves a myriad of issues, such as, investment costs and risks, key business requirements and solution constraints. We develop and test an ANP (Analytic Network Process) model to support the sequencing decision. Through the ANP analysis a preferred module implementation sequence is achieved in the case company. Moreover, the practical applicability of the method is discussed in the paper.
1. Introduction Contemporary organizations operate in a global environment that is characterized by constant change and different cultural settings. Dividing the company’s operations across the globe creates challenges for managing the corporate data. To avoid the fragmentation of the operational data in different business units, companies implement enterprise wide information systems, such as ERP (Enterprise Resource Planning) systems that can increase control and create the picture about the corporate functions on the aggregate level. Typically, ERP-systems support Financials, Human Resources, Operations and Logistics, and Sales and Marketing functions [3]. Recently also small and medium sized enterprises have started adopting ERP-systems and the market is expected to grow in the future. The objective of ERP systems is to conduct the business processes more efficiently and effectively, in an integrated manner, in organizations. They are a way to control functions of the organization and to make all the units perform in a more uniform way. Dramatic operational improvements are possible, through integration and redesigning of processes. It is
assumed that the standard software package more or less fits all organizations, and all units inside one organization, which creates risks for ERP investments. This assumption can be considered dangerous, since for some companies the competitive advantage may come from their idiosyncratic business processes [3]. Thus, the business implications of adopting ERP systems should be fully understood early enough in the acquisition process. ERP systems are truly strategic investments and their success is ultimately measured in their effect on the conduct of business processes and may directly influence the business success of a company. In theory, the business processes are modified to fit the systems, since customizing the system is considered too expensive and too risky. But in practice both business processes and ERP systems are suspects to be changed during the implementation process. There are, however, a lot of problems reported in the implementation of these systems, and even the objectives of the system investments may evolve during the process [6, 16, 26]. Technology and organization are in a continuous interaction with each other during technology adoption and use, according to Orlikowski [17]. The alignment of the needs of business functions with IT functions is a dynamic process, where the interactions are bi-directional: business affects IT and vice versa. The alignment of the business and IT functions can be addressed both at the strategic and tactical levels. The strategic decisions concerning ERP projects include, for example, which modules are implemented and how much business process re-engineering is conducted. On the tactical level, companies have to make decisions on issues, such as, using internal or external resources for implementation, how many and which modules are implemented in the first phase, and in which order the modules are implemented. We argue that the decision of the sequence of ERP module implementation is one of the crucial decisions that determine whether the business
0-7695-2507-5/06/$20.00 (C) 2006 IEEE
1
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
benefits of the ERP investment are achieved. Companies must consider which modules are the most important in terms of business value and have to be implemented first. Additionally, they have to assess the risks involved in the implementation of the different modules. There may also be organizational and environmental constraints, such as lack of resources or knowledge that may cause a need to postpone the implementation of some modules. Since the decision problem of the module sequence involves a myriad of organizational and technical issues, which are interconnected in networked manner, we propose the Analytic Network Process (ANP) method [21] to be applied to solve the decision problem. ANP has been applied to a variety of decision problems, including, for example, evaluating componentized Enterprise Information Technologies [22] and R&D project selection [13]. The ANP methodology includes defining the decision-making criteria and their interrelationships as well as the decision alternatives. ANP methodology supports complex, networked decision-making with various intangible criteria. It improves the visibility of the decision-making process and generates the priorities between the decision alternatives. Therefore, we consider the ANP methodology valuable for supporting the ERP module sequencing decision. In the next section we review the literature on ERP adoption and business process development to create the conceptual basis for understanding ERP adoption processes. Moreover, we discuss the implementation strategies for ERP implementation. Section three describes the principles of the ANP method and the conduct of a case study where the method is implemented. Section four presents the results of the case study. Finally, section five discusses the results and concludes the paper.
2. ERP adoption process 2.1. Business Process Development and ERP Adoption In this section we briefly review the literature on the business process development perspective on the adoption of information technology, and its implications to ERP adoption processes. Information technology can help organizations make their current business processes more effective or it can even enable the organization to redesign the business processes. Often information systems development projects are part of some larger strategic business development programs. Different projects have a varying degree of business development involved, some IS projects may be rather technically oriented but others may even involve new product development or going to a new business area. Venkatraman [27] classified IT-enabled business
transformation into evolutionary or revolutionary and identified five transformation levels: localized exploitation (evolutionary) internal integration (evolutionary) business process redesign (revolutionary) business network redesign (revolutionary) business scope redefinition (revolutionary) The localized exploitation means implementing standardized functional information systems with minimal changes to the business process. Internal integration means developing a common IT platform to integrate corporate information systems and additionally it involves integrating the interdependent business processes. On the revolutionary levels, business processes may be totally redesigned to be more efficient, the co-operation between business partners can be tightened with the help of information technology and it can even be considered whether information technology would play a role in changing the business scope of the company. In the case of the ERP systems, only focusing on the operational efficiency would probably not deliver the maximum value of the investment, but rather the business process development should also be considered. A clean slate approach to business process development is, however, very rarely possible and it must be considered carefully how much the existing processes can be changed [4]. In some situations, information technology can, however, be the actual driver for change and may make changes possible that would not be possible without the IT focus, because of the organizational resistance of change [12]. When improving companies’ business processes with information systems, the alignment process of IT and business is a dynamic and bi-directional process. The alignment process can be seen as a change management process interacting with three domains: information systems, organizational processes, and organizational strategy [5]. In the case of ERP systems, organizations have to consider issues along these dimensions, such as, the technical limitations of the software, how much tailoring should be made to fit the systems into the organization, and what kind of strategic business benefits are expected from the system investment. As to the expected benefits, ERP systems may bring substantial operational benefits and, at best, they can also generate various strategic level benefits. Mirani and Lederer [14] identified three sub-dimensions of strategic benefits of information systems: competitive advantage, alignment, and customer relations. They maintained that competitive advantage benefits help companies introduce radical changes to business processes and understood alignment broadly to directly support organizational goals, help organization to create linkages with other
2
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
receptivity of the client system to a possible change in the organizations, or enable it to respond faster to distribution and balance of social forces. Changing, or environmental changes. These are all relevant strategic moving, alters the magnitude, direction, or number of objectives for an ERP system investment. The array of driving and resisting forces, consequently shifting the benefits expected from ERP systems can be classified into equilibrium to a new level. Refreezing reinforces the new [24]: distribution of forces, thereby maintaining and stabilizing operational (lower costs, shorter cycle-times, the new social equilibrium. Kwon and Zmud [9] elaborated increased productivity, better customer service) Lewin-Shein theory of change in their six-phase managerial (improved resource management, implementation model as described in Figure 1. improved decision making and planning, improved As a response to the realized implementation problems performance) with ERP systems, a number of factor and process models strategic (support for business growth, support for have been proposed to moderate these problems. The co-operation in business, creating business factor models describe an extensive set of risk factors as innovations, establishing cost-leadership, supporting well as critical success factors for ERP implementation product differentiation, establishing external connections) IT-infrastructure related (flexibility for business, lower IT costs, increased capability of the IT-infrastructure) organizational benefits (change in the way of working, common way of working, support for organizational learning, increased possibilities Figure 1. IS implementation model [9] projects [1, 8, 15, 25]. The basic strategy behind the process models for organizational influence, varies from a detailed phase model to a big bang approach. creating a shared vision, increased job satisfaction). Rajagopal [19] extended the process model proposed by Kwon and Zmud to the problems of the ERP In the next section, we discuss the critical issues in the implementation process and tied each phase of the general ERP implementation process. implementation model to the realm of the ERP implementation. Parr and Shanks [18] classify ERP 2.2. ERP implementation process implementations to three broad categories (comprehensive, middle road, and vanilla) and according to them ERP ERP systems automate and integrate an organization’s implementations differ with respect to the following business processes and allow data and information sharing characteristics: physical scope, BPR scope, technical across the different business functions. ERP scope, module implementation strategy, and resource implementation is a technical, economic, and allocation. organizational challenge. In the adopting organization, Bancroft et al. [2] divided the ERP implementation ERP implementation requires substantial business process process into five successive phases: 1) focus, 2) as is, 3) to changes at strategic, tactical as well as operational levels. It be, 4) constructing and 5) testing, and actual also requires decisions concerning software configuration implementation. In their model the key activities of the to align the selected package with business demands ‘focus’ phase are the set-up of the steering committee, effectively. ERP implementation is usually an extensive selection and structuring of the project team, development and costly process that takes time even years and most of the project's guiding principles and creation of a project companies experience serious problems during the plan. The key activities of the ‘as is’ are the analysis of the implementation process. current business processes, installation of the ERP, Because ERP implementation is both an organizational mapping of the business processes on to the ERP functions change process and an IS implementation process, the and training of the project team. The ‘to be’ phase involves general models of organizational change and the general high-level design, detailed design, and interactive models of IS/IT implementation process can be applied to prototyping. The ‘construction and testing’ phase consists the planning, execution, and evaluation of the ERP of the development of a comprehensive configuration, the implementation. In the Lewin-Schein theory of change any population of the test instance with real data, building and organizational change can be viewed as a three-step testing interfaces, writing and testing reports and, finally, process consisting of unfreezing, moving (or changing), system and user testing. The ‘actual implementation’ and refreezing phases [10, 23]. Unfreezing increases the
3
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
covers building networks, installing desktops and finally managing user training and support. During the implementation process, different types of decisions have to be made. Mabert et al. [11] recognize the following seven key strategic decision variables in the ERP implementation process: Single ERP package versus multiple packages Big-Bang or mini Big-Bang versus a phased-in approach Number of modules implemented Order of implementation Modifications to system Major reengineering upfront versus limited reengineering An accelerated implementation strategy In the categorization above, attention is paid to the modules implemented and to the order of implementation. ERP packages are wide-scale products that cover all significant functions of organizations. ERPs are not, however, monolithic, undivided giants, but rather they are constructed by a number of modules that are independent in the sense that their implementation order can be determined relatively freely taking into account the organizational requirements. Proper implementation of the modules requires two decisions: 1) selection of the modules and 2) sequencing the implementation order of the modules. Both of these implementation decisions are grounded on business goals and requirements, costs, and risks. Additionally, there can be some, for example, technical solution constraints that affect the decisions. Next, we propose a methodology for deciding the proper order to implement the selected modules. It is assumed here that the initial decision of which modules are going to be implemented is already done.
3. Research Methodology 3.1. Analytic Network Process The Analytic Network Process (ANP) is a methodology that extends the Analytic Hierarchy Process (AHP) to the problems with dependence and feedback between the clusters of the decision situation. In ANP the hierarchical relations between criteria and alternatives are generalized to networks. ”Many decision problems cannot be structured hierarchically, because they involve the interaction and dependence of higher-level elements on lower-level elements. Not only does the importance of the criteria determine the importance of the alternatives as in a hierarchy, but also the importance of the alternatives themselves determines the importance of the criteria“[21]. Thus, in ANP the decision alternatives can depend on criteria and each other as well as criteria can depend on
alternatives and other criteria. It is assumed that feedback can better capture the complex direct and indirect effects of the interplay in organizational settings and hence allows more systematic analysis of the decision situation. It allows the inclusion of both tangible and intangible criteria and the ratio scale measurements with pairwise comparisons are used to capture the judgments of the decision makers. As a default structure, ANP offers four kinds of control criteria: benefits, costs, opportunities, and risks. These clusters of criteria can be used to make comparisons of outer or inner influences between the elements of the decision situation. Technically, in ANP, the system structure is presented graphically and by matrix notations. The graphic presentation describes the network of influences among the elements and clusters by nodes and arcs. The results of pairwise comparisons (weights in priority vectors) are stored to matrices and further to a super matrix consisting of the lower level matrices. After the super matrix is ‘normalized’ to be column stochastic arbitrary large number of powers of the matrix is taken. This is the genuine idea and challenge in ANP. By taking powers of the matrix, the indirect effects of the feedback relations are cumulated towards the equilibrium. Appropriate software (e.g. Super Decisions, ECNet) can support ANP methodology. ANP process typically consists of the following six steps: Problem structuring: o Determine the logical grouping of the elements (clusters) in the problem to be modeled. Model definition at upper level: o Create the clusters. Model definition at lower level: o Build the nodes (elements) within each cluster. Model construction: o Create the links between nodes in the same cluster or in the other clusters. Data collection: o Make judgments in the form of pairwise comparisons with respect to a controlling element. System calculates priorities for decision elements. Solution: o Synthesize to prioritize the alternatives with respect to the structure of the whole system. The problem-structuring phase cannot be done effectively without a deep understanding about the domain in question. Theoretical or practical knowledge helps to find the most essential issues and their relative significance. Typically the process starts from upper level and continues towards details. The modeling process with an appropriate support system continues with the definition of the key clusters. Some clusters are devoted to criteria and some of them
4
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
include the decision alternatives. When the clusters are defined, the elements inside each cluster are identified. After that, the relationships between the elements are defined by dichotomized fashion; there is a link between two elements or there is not. In data collection, it is important to make the questions in the right form. Alternatives are evaluated by the importance with respect to a criterion but a criterion is evaluated by the dominance of an alternative. Similarly, when making judgments about costs and risks, the questions are formulated asking which element is more costly or more risky. Fortunately, the construction of the super matrix and the process to synthesize are performed automatically by the support systems.
business reasons. After careful investigations and ERP suite comparisons, Oracle eBusiness Suite was selected to be the preferred software to fulfill the various business requirements better than competitors’ products or the legacy ERP. One of the authors worked as sales consultant in this selection process. Because Oracle is offering a large ERP suite of business applications, we considered the ANP methodology relevant for analytical ERP module sequencing decisions. Next, we will present the results of the ANP analysis, including the ERP module sequencing for the case company. Also, the usability of the ANP methodology is discussed.
3.2. Case context for the ANP model
4.1. ANP model for ERP module sequencing
The case organization is a global industrial manufacturing company, which has been growing through acquisitions. Meanwhile IT investments have been at quite moderate level. Therefore the company’s legacy systems are rather heterogeneous. Even the newest and most common legacy ERP software (referred as legacy ERP) was not capable to respond the sales and operations planning requirements, which caused the business to consider a major investment into a new enterprise information system. European level program for reengineering of business operations was initiated, including a new business operations model, which requires large changes into the enterprise information systems. Legacy ERP could be extended with Supply Chain Management (SCM) applications, but some of the major European business units were not interested in investing into the somewhat old-fashioned legacy ERP, which should be further extended with SCM, CRM and EAM applications. Also American and Asia-Pacific business operations were interested in investing in the new ERP system for several
The problem structuring for ERP module sequencing produced the following logical grouping of the elements (clusters) in the problem to be modeled (Figure 2): from the investment control perspective there are costs and risks, and the key business requirements and solution constraints represent the alignment perspective. Naturally, one cluster includes the alternative modules. The model is designed with the Super Decisions ANP tool. Goal for our ANP model is optimal ERP module implementation sequence, and the alternative ERP modules as options for the implementation sequencing decision. The implementation sequence is analyzed against the criteria of key business requirements, solution constraints, costs and risks. In Super Decisions software all four criteria, the overall goal and the alternatives are called clusters. Clusters include sub-elements called nodes. In this model, the key business requirements, costs and risks are the criteria directly connected to the goal of sequencing alternative ERP modules. The solution constraints are having more complex relationships between the alternative modules and other criteria, because what is possible from
4. Research results
Figure 2. High-level ANP model for ERP sequencing
5
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
the software perspective may be limited by the sometimes conflicting business requirements, all bringing in some implementation costs and risks. Solution constraints are environmental factors having loop back to themselves: while considering ERP module implementation sequence one must phase ERP module sequence and elimination of solution constraints to achieve the possible future enterprise information system. With this ANP design we are trying to explicitly express that from the software point of view all business requirements can be solved, but from the enterprise information system point of view the process change from “AS-IS” to “TO-BE” as well as new knowledge requirements, changes in the data model and technology have complex and intertwining relationships, which should be taken into consideration while making decision about ERP module sequence and scope. Solution constraints are possible change management elements, which must be balanced while making ERP module decisions, because too much change will bring additional inertia, risks, delays and costs, which will consume more effort and resources than more modest space of change.
Figure 3. Detailed ANP model for ERP sequencing While making our ANP model definitions at the lower level and building the nodes (elements) within each cluster, we have tied the model tightly to our case context. In the key business requirements cluster there are 24 nodes, which are derived directly from the most important process step for demand forecasting as documented in the software selection phase in the case company. The risks and costs of the ERP project in the model, such as application complexity and vendor experience, reflect rather well other corporate wide software investments, such as the case of Web Content Management investments reported by Hallikainen et al. [7]. The solution constraints cluster contains 12 nodes of possible practical constraints for ERP
implementation: knowledge, process culture, localizations, integration, services, module dependencies, data, networks, software tools/components, hardware configurations, usability and centralization/decentralization. The nodes in the alternative eBusiness Suite modules cluster are limited to the 2 most relevant modules and the 7 most relevant module domains totaling 9 possible candidates for ERP module implementation. The detailed ANP model is depicted in Figure 3. Next, we will discuss in more details the key business requirements and the solution constraints, which play a vital role while prioritizing ERP modules for ERP implementation. 4.1.1. Key business requirements. The key business requirements represent the benefits required from new ERP system. These requirements should be initiated while making the ERP adoption decision, and the requirements list should be maintained and referred to during the whole ERP implementation process. The requirements list should contain all the key business requirements from strategic,
tactical, operational and technical levels, and therefore the list might be quite long and contain even somewhat conflicting requirements. In our case company the list of key requirements is impressive with 244 key business requirements (224 main requirements and 20 subrequirements) for the main process areas covering new product development, forecast to finished goods, procure to pay, and order to cash processes. These requirements were generated while preparing the ERP adoption decision, and at that point of time the financial operations and internal accounting processes where considered to be outof-scope for this investment. But during the ERP software acquisition phase it soon became obvious that all the major ERP vendors suggested financial operations as a default
6
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
module for implementation, and financial shared service center was suggested operational implementation model to improve the business case for the whole ERP investment. This way, the financial operations became included into the ERP implementation scope, but the actual key business requirements were never explicitly generated for this area. For ANP purposes these 244 key business requirements are far too much for pairwise comparisons. Therefore we have focused on the core process for sales and operations planning as the primary factor for ERP module sequencing. But even for this process there were 76 requirements and 8 sub-requirements totaling 84 requirements, which would have still generated rather extensive pairwise comparisons. Therefore we focused our ANP model on the first process step called as “demand management”. This process step contains 24 key business requirements ranging from new product development to key account management, from graphical user interface to analytical reporting requirements, from budgeting integration to master data management and customer collaboration. Because demand management is one of the most important strategic activities for the new business operations model, and because this selection of 24 key business requirements well represents the whole variety of strategic, tactical, operational and technical key business requirements for the case, we have selected these 24 key business requirements as nodes in our ANP model. 4.1.2. Solution constraints The solution constraints represent mostly intangible environmental realities that may limit the ERP implementation and the realization of the possible benefits enabled by the new ERP software. Typically this kind of constraints can be related to internal and/or external resources, services, capabilities, data models and relationships, which may require additional efforts, time and money to be converted into ERP compatible model. In our case, we have listed 12 solution constraints as node, which may bring in additional costs and compromise the possible ERP benefits required by the key business requirements. These solution constraints are more often included as topics for change management activities, which try to manage these constraints, risks and costs in a proactive manner. Our ANP model includes the following solution constraints: knowledge, process culture, localizations, integration, services, module dependencies,
data, networks, software tools/components, hardware configurations, usability, centralization/decentralization. These are perhaps the most typical solution constraints that may eliminate, delay or decrease the benefit realization despite of the technically optimal ERP system and implementation efforts.
4.2. Preferred ERP module sequence Using the ANP model for the ERP module sequencing one of the authors entered the pairwise comparisons into our Super Decision model using questionnaire comparisons. The data for this study is thus based on the
Figure 4. Data entry example as questionnaire author’s retrospective understanding about the preferences of the ERP selection group in our case company. This understanding about the case is collected through various transactions during a one and a half year software selection and implementation phases. A data entry example as questionnaire mode is presented in Figure 4. Data entry with this big ANP model is a rather tedious process, which may cause data errors. To eliminate the errors Super Decisions contains functionality to check sanity and consistency for data entries. Sanity check reports about network calculation warnings and incomplete node comparisons, which is valuable information to ensure that all pairwise comparisons have been entered. Sanity check does not, however, analyze the data content, which may be checked with various inconsistency tools. Inconsistency measures the logical inconsistency of judgments. In general, the inconsistency ratio should be less than 0.1 to be considered reasonably consistent [20]. First, we checked our data using the Super Decision function called “Most Inconsistent”, which is available in the comparison mode to find out the most inconsistent value while comparing the currently evaluated node against all the nodes in the
7
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
currently evaluated cluster. The “Most Inconsistent” function did not always seem to function with this big model, so this functionality in Super Decisions is for limited value. After fixing the most inconsistent data entries in those nodes where “Most Inconsistent” function worked we further analyzed our data using a tool called “Full inconsistency report” also available in the comparison mode. The full inconsistency report represents the calculated best values for the alternative module comparisons. Interesting best values were suggested for comparisons in the "KBR01 Statistical Figure 5. Overall synthesized priorities for ERP module sequencing demand generation" node in the These results mean that the prioritized ERP module "Alternative modules" cluster, where M05.4 DP is assessed implementation sequence for our customer case is: to be extremely more important than M01 Intelligence. 1. M05.4 DP: Demand Planning from M05 Supply Because our initial data entry mode was the questionnaire Chain Planning suite we entered the highest possible value 9 for Demand 2. M02 Marketing and Sales: EBS/CRM Marketing Planning, but the software calculates the best value for this and Sales suite comparison to be 23.306789. According to tutorial of Saaty 3. M03 Order Management: EBS/ERP Order [20] for Super Decisions: ‘When a number greater than 9 Fulfillment suite is suggested by the inconsistency checking, this means that 4. M05.5 CP: Collaborative Planning from M05 the elements you have grouped together are too disparate. Supply Chain Planning suite You may input a number greater than 9, but perhaps you 5. M04 Logistics: EBS/ERP Inventory & should re-organize your structure so that such a Transportation modules comparison is not required. It will do no great damage to 6. M01 Intelligence: EBS intelligence and analytical allow numbers up to 12 or 13, but you should not go much reporting beyond that.’ This result suggests that we should not 7. M11 Product Lifecycle Management: EBS/PLM compare the reporting module M01 Intelligence to the modules actual data processing module M05.4 DP, which is a valid 8. M15 Customer Data Management: EBS/CRM statement for this particular key business requirement Master Data regarding statistical demand generation. In general, one 9. M12 Financials: EBS/Financials modules might expect that each alternative ERP module should In this list M05.4 Demand Planning and M05.5 contain relevant reporting capabilities, but in practice this Collaborative Planning are modules included in Oracle’s is not necessarily true: even modern ERP software modules Supply Chain Planning suite for Advanced Planning and include quite limited reporting functions for a limited set of Scheduling/APS. The rest of the modules are actually transactional data. Often, more advanced aggregative and module groups or domains containing several software analytical reporting requirements may be solved with modules. This list gives one possible sequence for the ERP separate reporting modules, tools and datawarehouse module implementation, but it does not give actual solutions. suggestion for the scope of the ERP implementation It should also be noted that when using Super Decisions project. It’s interesting to note that even the three first data entry mode may have influence on results: in matrix modules represent various application areas: CRM, SCM and direct data entry modes Super Decisions enable direct and ERP. This finding supports company’s decision to data entry with decimals, in graphic and verbal data entry select full ERP suite instead of best of breed APS or SCP mode graphical user interface may be used to enter decimal approach, because the typical planning applications do not values, but in the questionnaire mode data entry is done include modules or functionality for master data using full digits from 1 to 9. In our case, we used the management nor for demand data standardization. But matrix mode to enter decimal values while fixing the most implementation of the full ERP suite of course activates an inconsistent values. array of solution constraints, which may consume a lot of After these data entries we were able to report the resources. Therefore, expectation management will be an following overall synthesized priorities for alternative ERP important part of internal communication to increase the modules as depicted in Figure 5.
8
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
awareness of the complexity of the wall-to-wall ERP implementation project. Patience is required also from management while realizing the expected business benefits from a full scale ERP investment, because ERP solutions may require fine-tuning, new competencies and organizational learning before the full payback may be perceived. We argue that the decision-makers should evaluate various combinations and ERP module configurations before running into ERP implementation: there are other options than implementing only the top prioritized ERP modules or implementing all the relevant ERP modules from 1-9 at the same time. In this case, one possible option for solution phasing might be the implementation in three different ERP module groups: demand forecasting and fulfillment history related modules ranked between 1-5, master data and reporting modules ranked between 6-8, and financials as a separate module ranked as the least important. Again, these ERP module groups might be implemented in various sequences: if quick benefits are preferred, the implementation might start from demand related modules; if risk avoidance is preferred, implementation might start from financials; if all benefits are preferred and additional investments are done to change management, then implementation project might try to implement all the possible modules at the same time. Our ANP model does not, however, enable analysis using logical module combinations, which would require another ANP model including various ERP module combinations as alternatives for decision-making. More detailed analysis inside supplier’s module list may also be required, because there may be several modules available for the same set of data or same core operations, but functionality and usability between alternative modules may differ. Therefore ERP module sequencing is not a simple task: it requires patience and careful analysis inside and between key business requirements, alternative modules and solution constraints. At the high-level these results are well aligned to our key business requirements. Demand forecasting and generation related modules are ranked as the most important, while demand related master data management modules are ranked as less important. Finally, the Financials module gets the lowest priority, which is a valid research result, because the Financials area was originally defined to be out of the scope for this ERP investment. But these results do not give any absolute recommendation for this case company, because we have used simplified and theoretical model with limited set of key business requirements.
5. Discussions and conclusions As a result of this research we achieved an ANP model for the ERP module sequencing and the preferred sequence
in the case company. We believe that the process presented in the paper represents a relevant model for communicating and managing the key business requirements and the solution constraints as well as the costs and the risks when considering the module sequencing. The ANP methodology itself seems to be applicable for this kind of decision-making, but ANP model easily generates too many pairwise comparisons to be practically executable for practitioners without scientific interests. But at the same time ANP approach enforces the analytical comparison between the alternatives as well as the decision visibility for external auditors and boards investing huge amounts of money in the ERP software. A possible concern regarding the ANP model abstraction level is related to the alternate ERP modules: at strategic level alternate ERP modules might be grouped into module groups or system domains, but at tactical and operative levels the decision alternatives might be covered at the individual ERP module level. In our model, we did compromises while including both key modules and related module domains, which resulted in some comparisons to compare apples to grapevines. To get the full benefit from the ANP approach, the decision alternatives should be analyzed at module level, but this would make the pairwise comparisons with the full key business requirement list a very demanding and tedious process. The benefits from utilizing the ANP model for ERP module sequencing do not only come from the explicit priorities between the alternative modules. Major value can come from the knowledge transfer during the ANP data collection process, because answering to pairwise comparisons requires an enhanced dialog between the ERP vendor, the IS department and the business units. ERP implementation process is more knowledge, resource, requirements and change management challenge than technical IT system deployment. Thus, issues regarding IT and business alignment, as well as IT governance might surface during the data collection process. Key business requirements may be biased, current understanding about solution constraints may be limited, and priorities may be unintentionally sub-optimized because of bounded rationality and past experiences from non-integrated operations and systems with limited data models. Therefore our decisions can never be fully optimized, but at least these decision elements of behavioral analytics can be documented and communicated in structured manner through the data collected in pairwise comparisons. We could have used sensitivity analysis in Super Decisions to elaborate how sensitive our results were for chancing priorities, but this field of behavioral analytics opens own discourse, which we have left for future research. Our ANP approach for ERP module sequencing might be translated towards the service-oriented IS architecture. When prioritizing between future information needs and
9
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
possible services, companies must make difficult comparisons between current and future information needs (key business requirements), as well as current and future information services (alternative services), without fully understanding the differences between the data models and the service integration supported by the heterogeneous service providers and information sources (solution constraints). This opens new research opportunities to improve our initial ANP model in more heterogeneous information service environments covering composite applications, but at the same time it would make the ANP model abstraction even more demanding task, when individual information services would be added to alternative decisions in addition to module domains, module combinations and individual modules. To conclude, for practical usability, the abstraction level of alternative ERP modules for ANP model should be carefully considered and the analysis should focus on a rather limited set of the decision-making domain to make the actual results of ANP assessment useful. But ANP process itself would be valuable for enhanced knowledge transfer and improved communications regarding ERP module sequencing decisions.
6. References [1] Al-Mashari, M., Al-Mudimigh, A. and Zairi, M. (2003), Enterprise Resource Planning: A Taxonomy of Crititcal Factors, European Journal of Operational Research, Vol. 146, pp. 352364. [2] Bancroft, N, Seip, H. and Sprengel, A. (1998), Implementing SAP R/3, Manning Publications, Greenwich. [3] Davenport, T.H. (1998), Putting the Enterprise into the Enterprise System, Harvard Business Review, Jul-Aug, pp. 121131. [4] Davenport, T.H. and Stoddard, D.B. (1994), Reengineering: Business Change of Mythic Proportions?, MIS Quarterly, Vol. 18, No. 2, pp. 121-127. [5] Earl, M.J., Sampler, J.L. and Short, J.E. (1995), Strategies for Business Process Reengineering: Evidence from Field Studies, Journal of Management Information Systems, Vol. 12, No. 1, pp. 31-56. [6] Glover, S.M., Prawitt, D.F. and Romney, M.B. (1999), Implementing ERP, Internal Auditor, Vol. 56, No. 1, pp. 40-47. [7] Hallikainen, P., Kivijärvi, H. and Nurmimäki, K. (2002), Evaluating Strategic IT Investments: An Assessment of Investment Alternatives for a Web Content Management System, Proceedings of the HICSS-35, Big Island, Hawaii, USA [8] Hong, K.W. and Kim, Y.G. (2001), The Critical Success Factors for ERP Implementation: an organizational fit perspective, Information & Management, Vol. 40, pp. 25-40. [9] Kwon, T. H. and Zmud, R. W. (1987), Unifying the fragmented models of information systems implementation, in Boland, R. J. and Hirscheim (eds.), Critical Issues in Information Systems Research, John Wiley & Sons Ltd., pp.227-251.
[10] Lewin, K. (1952), Group Decision and Social Change, In Newcomb and Hartley (eds.) Readings in Social Psychology, Holt, New York. [11] Mabert, V. A., Soni, A. and Venkataramanan, M. A. (2003), Enterprise resource planning: Managing the implementation process, European Journal of Operational Research, 146, pp. 302-314. [12] Markus, M.L. (2004), Technochange Management: Using IT to Drive Organizational Change, Journal of Information Technology, Vol. 19, pp. 3-19. [13] Meade, L.M. and Presley, A. (2002), R&D Project Selection Using the Analytic Network Process, IEEE Transactions on Engineering Management, Vol. 49, No. 1, pp. 59-67. [14] Mirani, R. and Lederer, A. (1998), An Instrument for Assessing the Organizational Benefits of IS projects, Decision Sciences, Vol. 29, No. 4, Fall 1998, 803-838. [15] Nah, F.F.H. and Lau, J.L.S. (2001), Critical Factors for successful Implementation of Enterprise Systems, Business Process Management Journal, Vol. 7, No. 3, pp. 285-296. [16] Nandhakumar, J., Rossi, M. and Talvinen, J. (2003), Planning for ‘drift’?: implementation process of enterprise resource planning systems, Proceedings of the HICSS-36, Big Island, Hawaii, USA. [17] Orlikowski, W.J. (1992), The Duality of Technology: Rethinking the Concept of Technology in Organizations, Organization Science, Vol. 3, No. 3, pp. 398-427. [18] Parr, A. N. and Shanks, G. (2000), A Taxonomy of ERP Implementation Approaches, Proceedings of the HICSS-33, Island of Maui, Hawaii, USA. [19] Rajagopal, P. (2002), An innovation-diffusion view of implementation of enterprise resource planning (ERP) systems and development of a research model, Information & Management, 40, pp. 87-114. [20] Saaty, R.W. (2003), The Analytic Hierarchy Process (AHP) for Decision Making and The Analytic Network Process (ANP) for Decision Making with Dependence and Feedback, a tutorial for Super Decisions [21] Saaty, T. L. (2001), The Analytic Network Process, RWS Publications, Pittsburgh [22] Sarkis, J. and Sundarraj, R.P. (2003), Evaluating Compnentized Enterprise Information Technologies: A Multiattribute Modeling Approach, Information Systems Frontiers, Vol. 5, No. 3, pp. 303-319. [23] Schein, E. H. (1961), Management Development as a Process of Influence, Industrial Management Review, 2, pp. 5977. [24] Shang S. and Sheddon, B. (2002), Assessing and Managing the Benefits of Enterprise Systems: the Business Manager’s Perspective, Information System Journal, Vol. 12, pp. 271-299. [25] Sumner, M. (2000), Risk Factors in Enterprise-Wide/ERP projects, Journal of Information Technology, Vol. 15, pp. 317327. [26] Themistocleous, M., Irani, Z. and O’Keefe, R.M. (2001), ERP and Application Integration – Exploratory Survey, Business Process Management Journal, Vol. 7, No. 3, pp. 195-204. [27] Venkatraman, N. (1994), IT-Enabled Business Transformation: From Automation to Business Scope Redefinition, Sloan Management Review, Vol. 35, No. 2, pp. 7387.
10
