首页    期刊浏览 2025年02月08日 星期六
登录注册

文章基本信息

  • 标题:Enterprise resource planning systems implementation as a complex project: a conceptual framework/Imones istekliu planavimo diegimas kaip kompleksinis projektas: koncepcinis modelis.
  • 作者:Ghosh, Saumyendu ; Skibniewski, Miroslaw J.
  • 期刊名称:Journal of Business Economics and Management
  • 印刷版ISSN:1611-1699
  • 出版年度:2010
  • 期号:December
  • 语种:English
  • 出版社:Vilnius Gediminas Technical University
  • 摘要:Prior research has provided valuable insights into how and why employees make a decision about adoption and use of information technologies (ITs) in the workplace. From an organizational point of view, however, the more important issue is how managers make informed decisions about interventions that can lead to greater acceptance and effective utilization of IT (Venkatesh and Bala 2008). Project management has been dominated by the hard paradigm in which reductionist techniques such as work breakdown structures and critical path analysis are used to manage projects. These tools and techniques are fairly well suited to the management of single projects and it is therefore unsurprising that industry is overwhelmingly dominated by the single project paradigm (Aritua et al. 2009).
  • 关键词:Enterprise resource planning;Industrial project management;Project management

Enterprise resource planning systems implementation as a complex project: a conceptual framework/Imones istekliu planavimo diegimas kaip kompleksinis projektas: koncepcinis modelis.


Ghosh, Saumyendu ; Skibniewski, Miroslaw J.


1. Introduction

Prior research has provided valuable insights into how and why employees make a decision about adoption and use of information technologies (ITs) in the workplace. From an organizational point of view, however, the more important issue is how managers make informed decisions about interventions that can lead to greater acceptance and effective utilization of IT (Venkatesh and Bala 2008). Project management has been dominated by the hard paradigm in which reductionist techniques such as work breakdown structures and critical path analysis are used to manage projects. These tools and techniques are fairly well suited to the management of single projects and it is therefore unsurprising that industry is overwhelmingly dominated by the single project paradigm (Aritua et al. 2009).

ERP systems, also called enterprise systems (ES) are among the most important business information technologies that emerged during the last decade (Chung et al. 2008). Transforming a core business process requires intensive cooperation among executive peers and therefore for ERP adoption process which involves multiple business units, require a confrontation of reality, both external and internal (Chen et al. 2009; Miles 2010). Total cost of ownership, which is critical is measuring success (Jasilioniene and Tamosiuniene 2009) of any product based implementation, it can only be measured if all the internal and external variables are considered properly.

There have been very limited studies in investigating ERP in the project management domain or exploring the integrated applications of project management practices. The current project management methodology has failed to provide tools and techniques for successful ERP implementations. Adopting and implementing appropriate project managements principles, tools, and techniques to manage large and complex application projects is one of the most important management decisions for managing any enterprise application implementation. And project managers are required to be empowered to execute. An ERP implementation is not merely a "computer project", it is strategic and must be approached as such. ERP systems are integrated applications with an impact on the entire organization (Aloini et al. 2007).

A lot of research has been done during last decade about the success and failures of ERP implementations (Helo et al. 2008). Most data came from survey and case studies without going into fundamentals on impact of project management tools and techniques for ERP project. A theory of ERP implementation approach must address the integrity and application of a project management methodology, establish relationship with implementation partners and vendors and include strategies for empowerment, fairness, and accountability during the implementation life cycle. The result of that relationship should be that the project manager is rigorously in control and, simultaneously, management methodology is optimally established process and procedure to manage a project involving multiple partners without direct hierarchical reporting structure. Three main components affect the level of satisfaction of an ERP user: "interaction with the IT department", "pre-implementation processes", and "ERP product and adaptability" (Longinidis and Gotzamani 2009). In this paper, we attempt to reconcile these diverse arguments, following complex organization structure involved in any enterprise application implementations.

Often ERP implementations may require going against conventional wisdom to be successful (Luo and Strong 2004). However no further study has been done to established a new methodology to implement ERP systems. We also discuss ERP project as a complex adaptive system that all ERP projects are different and require project governance and management in place to adapt to interconnectedness, communication and control over different stakeholders involved with any non-hierarchical relationship.

2. Background

2.1. ERP literature review

Three distinct research streams are identified for ERP related research. The first provides a comprehensive overview of the ERP systems (Gupta 2000; Rao 2000; Chen 2001; Kerbache 2002; Payne 2002). These articles cover such aspects as research agendas, motivations and expectations and proposals on how to analyze the value of ERP systems (Esteves and Pastor 2001).

The second stream focuses on the details associated with ERP implementations and their relative success and cost. The articles in this stream include topics such as implementation procedures, critical success factors, pitfalls and complexities in ERP implementations and successful strategies for effective ERP implementations. Esteves and Pastor (2001) classify the publications related to the implementation phase into four main topics: implementation approaches, implementation success, other implementation issues, and implementation case studies.

The third stream focuses on the theoretical research models that have been developed to cover aspects such as usage of modeling tools applied in ERP contexts, new business modeling approaches and comparisons between processes.

Critical success factors are also quite well studied. There is the need to develop approaches to put in practice and manage the critical success factors identified in some studies. For a detailed reference on critical success factors for ERP implementations, refer to Moon's article (Moon 2007).

Most frequently documented risk factors for ERP implementations are: a) inadequate selection of application, b) ineffective strategic thinking and planning strategic, c) ineffective project management techniques and bad managerial conduction, d) inadequate change management and e) inadequate training (Aloini et al. 2007). Both of a and b activities are identified to be project governance responsibilities (Grembergen and Hass 2008), c is a project management activity which can only be successful if project governance empowers project managers properly, and d and e are project management activity. Other documented management practices with correlations with implantation success are: explicitly defined information technology strategy, strategic alignment and management commitments (Bernroider 2008).

ERP implementations support multiple business areas (Umble et al. 2003; Skibniewski and Ghosh 2009) and introduce business process changes in the organization (Ross 1999; Kwahk and Lee 2008). ERP implementations are also expected to improve business process; consultants and solution providers can only provide the expertise how to knowledge base how the ERP package works (Helo et al. 2008; Sledgianowski et al. 2008). Readiness for change was found to be enhanced by two factors: organizational commitment and perceived personal competence (Kwahk and Lee 2008). However product knowledge about the ERP application is provided by software vendor and consultants (Helo et al. 2008) and should be part of the governance process. ERP projects are complex: PMP (2001) found that the average implementation time of an ERP project was between 6 months and 2 years and that the average cost is US$1 million (Aloini et al. 2007).

2.2. ERP systems as 'Business Enablers' Mankins and Steele (2005) pointed out that to ensure good performance in a company, it is required to use a rigorous framework and use common business processes during any system implementation. ERP systems integrate the data and processes of an organization into one single system. ERP systems are software packages composed of several modules, such as human resources, sales, finance and production, providing cross-organization integration of data through embedded business processes. Also implementation must balance resistance to change and application of change management required (Davidaviciene 2008), can only be achieved using a pluralist approach. Therefore ERP project management should have systemic pluralist approach to manage complex IT projects (Williams 2002) like ERP implementations.

ERP systems provide seamless integration of business functions by providing them access to the information they need (Ghosh et al. 2010). Organizations using ERP have achieved savings by eliminating many different and often incompatible legacy systems as well as streamlining business processes (Jenson and Johnson 2002).

Therefore success of ERP projects is also measured by how much financial, efficiency gain or productivity gain the implementation created for the ERP adopter. Project management methodology for ERP systems therefore must work with all stakeholders so that overall value of implementation can be understood across the organization.

2.3. Complex project

While many project managers use the term a complex project, there is no clear definition about what is meant beyond the general acceptance that it is something more than simply a 'big' project (Williams 1999). This paper does not aim to give a definitive definition of complex ERP projects either. It aims to be inclusive rather than exclusive, to encourage discussion of all of the dimensions of complexity as it applies to ERP projects relative to CSF and RFs, as well explain different types properties of complexities involved in any ERP implementation and how best to manage and govern such implementations. The paper considers whether these aspects can be first conceptualized, and gives some ideas about why project complexity might be considered to be different between different sub-domains within a project.

As stated by Peter Drucker, enterprises are paid to create wealth, not to control costs and projects are means to create wealth in the enterprise. This obvious fact is not reflected in traditional measurements (Drucker 1995). Business models were thought to be able to make decisions and might even be able to run much of the business. These models have drastically changed tasks associated with running a project. However since ERP touches several business areas, project managers are required to focus of creating wealth for the ERP adopter and therefore success of ERP implementation is measured by the wealth the ERP implementation created for the ERP adopter.

There has been a wide range of literatures discussing complex projects within the domain of project management since the late 1990s. Remington and Pollack (2008) recommended using four types of complexities involved in a project. Sauer and Reich (2009) showed that we need to think project managers to have cognitive and affective (or emotionally intelligent) qualities to rethink their practice and whether a new kind of individual will be required to be tomorrow's IT project manager. Sauer and Reich (2009) also showed that project managers must focus on ultimate value, investment in trust, devolved, collective responsibility and willingness to continually adapt. All of these qualities go against the fundamental concept of project as a short term endeavor with specific begin and end. For our purpose of this paper, we consider four types of complexities: structural, technical, directional and temporal complexities (Remington and Pollack 2008). The purpose of this paper is to review CSFs and RFs currently identified in the literature and how project complexities can provide a new approach to achieving those CSFs and mitigating RFs.

3. Why ERP projects are complex projects?

3.1. Background

Since a full adoption of ERP systems spans all functional silos, the hazards of implementation uncertainty are usually salient. Therefore apart from ERP adopter, also ERP vendor and ERP consultancy combine their efforts and resources to achieve mutually desirable goals. Skibniewski and Ghosh (2009) identified resources are also required from training, application service provider and support for a successful implementation. Wang and Chen (2006) identified the importance of outside consultants for a successful implementation. Rose and Kremmergaard (2006), Ghosh (2003), Ifinedo and Nahar (2009) identified the importance of technology organization for a successful implementation. Lui and Chan (2008) identified the importance of business process reengineering.

Therefore if we consider ERP implementation as a system, it is complex because "one made up of a large number of parts that interact in a non-simple way. In such systems the whole is more than the sum of the parts, not in an ultimate, metaphysical sense but in the important pragmatic sense that, given the properties of the parts and the laws of interaction, it is not a trivial matter to infer the properties of the whole" (Williams 2002). The success of ERP depends on how the system is integrated with other applications in the enterprise. The integration can often be underestimated and therefore add complexities. Therefore applying the same definition, ERP projects consist of multiple sub projects(business requirements mapping, technical infrastructure development, change management to name a few) so that they hinder the effective modeling of complex projects, whose behavior is beyond the sum of their parts and whose reaction to changes in inputs is difficult for the human mind to predict.

Following Baccarini (1996)'s definition, project complexity is "consisting of many varied interrelated parts". This operationalises in terms of differentiation--the number of varied elements--and interdependency--the degree of inter-relatedness (or connectivity) between these elements. ERP will only be successful if all these parts work together. We will refer to four types of complexities: structural, technical, directional and temporal (Remington and Pollack 2008). For a detailed discussion on project complexity, which is defined using of elements involved in the project and interdependence of elements, readers are referred to Williams (2002), can be matched with number of elements involved and interdependence in any ERP implementation (Skibniewski and Ghosh 2009).

ERP project involves multiple business and technical areas as described before and all areas will not follow same pattern of life cycles in the implementation. In terms of ERP project structural complexity, "differentiation" would mean keeping track of number of hierarchical levels, number of tasks which are interconnected from different hierarchical level and effective management of those tasks in an efficient work break down structure. The major challenge comes from project organization (consisting of multiple parties e.g. ERP adopter, ERP vendor, training provider and others, hence forth mentioned as actors of the ecosystem), scheduling, interdependencies and contract management. Structural complexities arise due to the fact that different sub-projects involved in any project may be at a different level of project life cycle at same point in time (Law and Ngai 2007; Somers and Nelson 2004; Raymond and Louis 2009). Interdependencies would arise to coordinate different actors involved in the ERP implementation.

The main technical challenge faced in any ERP system is that the product life cycle may not match with adoption life cycle. In terms of technological complexity, "differentiation" would mean the number and diversity of inputs, outputs, tasks or specialties; "interdependency" would be the interdependencies between tasks, teams, technologies or inputs (Williams 2002). Technical complexities arise when technical infrastructure required for ERP is non-compatible with existing environment of ERP adopter (Ghosh 2003; Hawking 2007) and therefore interdependency with existing technical architecture.

In terms of directional complexity, "differentiation" would be mean the unshared goals and goal paths, unclear objective and hidden agendas between different actors involved in any ERP implementation (Bueno and Salmeron 2008; Aloini et al. 2007). ERP requires business process changes to best practices as dictated by ERP vendor's supported business process which may not match with ERP adopters' business process. Changed business process may not benefit all sections or locations equally (Ghosh 2002). Directional complexity will be interdependent with management's objective from the ERP success.

In terms of temporal complexity, "differentiation" would be characterized by shifting environment, and strategic directions which are outside the control of the project team, e.g. ERP vendor changing technology platform of the project that may require an upgrade of the environment used by ERP adopter.

3.2. Review of CSFs and RFs

ERP projects often result in cost overrun, schedule delays, and sudden project terminations because of poor selection of software and lack of management support. ERP projects involve business process changes, change management and technical risks, need proper project governance in place and empower project managers to execute. Project steering committee and project managers must have knowledge of applying complexity theory--structural, directional, technical and temporal processes, procedures, and policies and to implement them rigorously from the initial stage of the project.

Adopting a complexity theory mindset affects practice in different and often counter intuitive ways. Just as people in a market are empowered to make their own purchases, so too, in accordance with complexity theory, project managers must be allowed to react--in independent, self-organized ways--to developments in individual single projects. The challenge of our proposed model of ERP implementation project as a complex project needs successful "institutionalization" across multiple boundaries--within ERP adopter, ERP vendor, consultants, training and other support organizations. Streamlining a governance and management structure that satisfies all stakeholders, involves multiple organizations within a given time period is a difficult task.

Table 1 describes ten most frequently documented CSFs for ERP implementations, documenting project management and project governance challenges involved in resolving each of the CSFs. Table 2 describes how key ERP risk factors should be viewed from project complexities perspective. The tables clearly explain that each of the documented CSFs and RFs can only be viewed from a complex project perspective and improve project manager's understanding of the challenges they will face. This study will provide project managers a different perspective of the challenges and help better improve ways to deal with those challenges.

[FIGURE 1 OMITTED]

4. Analysis

Hall and Day (1977) consider three uses of models: understanding, assessing, and optimizing. In this paper, an understanding model is developed which is assessed using data gathered from IT system enablers and based on the data and analysis performed on that data, the model is optimized. The purpose of this section is to identify, apart from ERP adopters, there are also several other stakeholders, without direct hierarchical relationship with ERP vendor to make the project successful. Initially we start we end users' attitude towards usage of the new system as a key criterion for success, but also identify several other groups of individuals required to make the project successful, but not meant to be an exhaustive study to identify all stakeholders. Skibniewski and Ghosh (2009) identified complex ERP implementation ecosystem (Figure 1) and actors of interests in the ecosystem which are analyzed in this section.

4.1. Attitude towards usage

The behavioral intentions to use an IT are determined by an individual's attitude toward using the IT, as well as beliefs the user holds about its perceived usefulness. One of earliest definition and exploration of compatibility is defined as belief of using an innovation is perceived with the existing socio-cultural values (Venkatesh and Davis 2000). The definition of compatibility is later extended to include cognitive compatibility as what people are thinking and therefore perceive as useful. When an organization is willing to adopt a new technology, there are some prior beliefs that drive the selection procedure. The adoption of new technology is driven by prior knowledge of the key decision makers, their past experience, organization's existing technology basis, as well other collaterals like trade association journals, professional community meetings as well other information sources.

Karahanna et al. (2006) identified the following four components that directly impact use of ERP system in any enterprise: Compatibility with preferred work style, existing work practices, prior experiences and values of users towards use of technology, also showed that except preferred work style has direct impact on the perceived usefulness and perceived ease of use. Unless beliefs that the system will be useful and easy to use, the project will not be a success.

Project managers are expected to maintain a system of stability to ensure users get consistency in the system, and therefore compatibility beliefs are instrumental in shaping beliefs about usefulness and ease of use, and they also influence usage directly, managers responsible for implementing new technologies need to pay careful attention to their formation. If the system does not behave consistently, it is likely to create a chaos; positive beliefs about the compatibility of a new technology can be lost. Project managers are also required to emphasize the fit between the technology and the mental models created through the implementation. In order for the system to be successful, complexity comes from a number of people, groups and separate organizations involved. In order to manage all these elements, governance process should ensure project managers are properly informed to manage multiple independent entities involved. Management decision processes are susceptible to delays and errors without proper authority and pre-defined process in place. Perceived usefulness will be increased in formation about product capabilities that are passed by the product company and consultants to the end users.

Complexity theory predicts that the closer the system is to order, the easier it is to manage projects with structural complexities. ERP projects are likely to show all the attributes of structural complexities. Complex projects assume that communications will be rule-bound and formal between all sub-systems. Any ERP implementation at a minimum has two additional sub-systems: a vendor sub-system who created the product and a consulting sub-system providing domain expertise of the product implemented. However the three sub-systems: vendor, consulting and ERP adopter are independent and therefore traditional project management literature which typically refers to how communication is planned and transferred efficiently will not work and need a more rule-bound formal process. For rule-bound communication, project managers will be required to define a rule of which information is communicated.

4.2. ERP vendor and consulting support

For any technology to be acceptable, sustainable and eventually to be called a successful implementation, proper support structure should be in place. Application service providers (ASPs) are third party service firms that deploy, manage and may also remotely host remotely located servers and application through a central location. Internal support organizations are the specialized division, department of group of individuals within the same organization who are entrusted to support the specific application. Several existing literature on ASP has identified the participants of the ASP model who are identified as a) solution developer, b) customer, c) business service provider and d) platform enabler (Gurbaxani 1996).

ASP support is also direct consequence of globalization and organizations are looking for metanational advantage (Doz et al. 2001) However the coordination problem is of technical, temporal or process oriented type (Espinosa et al. 2007). Software as a service is also a model that has gained recently growing interests in the market segment. Ekanayaka et al. (2003) documented different types of support an ASP is supposed to provide (Table 3).

4.3. Infrastructure components

Ghosh (2003) proposed that executives need to have a complete understanding of the technical challenges involved in adopting a new enterprise wide system and proposed that the three elements to consider are, a) network upgrade, b) hardware upgrade and c) providing global support. Executives are required to judge each of the aspects separately and at the end match all the three to make the decision which ERP package to adopt. When ERP implementation does not involve infrastructure resources, the implementation faces temporal complexities, however if the implementation involves infrastructure resources, it becomes a structural complexity issue since scope of the implementation goes up and can become unmanageable. Also technical requirements of the implementation may change due to a new version of the software released which may create temporal complexity challenges as well.

4.4. Training components

There may be a compatibility of existing business processes with preexisting software development, but not for packaged ERP application. Several researchers identified that success of IT adoption may be greatly influenced by how closely an individual's personal values and perceived values of the organization overlap (Cazier 2003; Cazier and Gill 2003; Cazier et al. 2002). To ensure personal values and perceived values are mapped properly with users' expectations, training will be the bridge between the two, which is procured from outside, creating a temporal complexity challenge and when incorporated in the plan, creates a structural challenge.

And therefore IT enablers identified training to be a critical component (Sharma and Yetton 2007) of ensuring success, primarily in the packaged software market segment. Packaged software are conceptualized, developed and marketed by a vendor without specific input from the implementing organization. Following Sharma and Yetton (2007), the effect of training on implementation success is contingent on both technical complexity and task independence. The above mentioned theory therefore evaluated in practical purposes to ensure the key measures of success in training.

5. Conclusion

This article has outlined the conceptual revisions needed to extend the new project management approach from its current linear way of looking into project management of ERP projects. The article suggests that ERP project management is best understood within the context of environmental complexities. The article also suggests that the choice of project management approach is a matter of reviewing at the complete ecosystem rather than of functional goals of the ERP implement. The acknowledgement of pluralism broadens distributive concerns in project management decisions to issues such as the distribution of complexities and project management impacts.

The aim of the presented research has been to fulfill the need for a comprehensive framework for ERP systems to be reviewed as a complex project. A theoretical framework for identifying and classifying management process following critical success factors was formulated and it forms the basis of understanding the spectrum of ERP implementations.

Consistent with our approach of project governance and management of ERP projects, we propose that three additional research phases are necessary to complete the study: 1) confirming a structure of ERP complexities model, 2) parsing information model to understand different elements of ERP identified in this paper and 3) assessing the consequentiality of ERP governance and management complexities in ERP project execution. Future research can address how near real time governance and management can be incorporated in the project management and governance process and develop a system to capture and analyze problems. A new body of knowledge related to governance and management of complex ERP implementations should be developed in order to ensure better coordination between several actors involved in an ERP implementation.

doi: 10.3846/jbem.2010.26

References

Aloini, D.; Dulmin, R.; Miminno, V. 2007. Risk Management in ERP project introduction: Review of the literature, Information and Management 44(6): 547-567. doi:10.1016/j.im.2007.05.004

Aritua, B.; Smith, N. J.; Bower, D. 2009. Construction client multi-projects--A complex adaptive systems perspective, International Journal of Project Management 27(1): 72-79. doi:10.1016/j.ijproman.2008.02.005

Baccarini, D. 1996. The concept of project complexity--a review, International Journal of Project Management 14(2): 201-204. doi:10.1016/0263-7863(95)00093-3

Bernroider, E. W. N. 2008. IT governance for enterprise resource planning supported by the DeLone-McLean model of information systems success, Information & Management 45(5): 257-269. doi:10.1016/j.im.2007.11.004

Bueno, S.; Salmeron, J. L. 2008. TAM-based success modeling in ERP, Interacting with Computers 20(6): 515-523. doi:10.1016/j.intcom.2008.08.003

Cazier, J. 2003. The Role of Value Compatibility in Trust Production and E-Commerce, in J. Ross and D. Galletta (Eds.). Proceedings of the 9th Americas Conference on Information Systems. Tampa, FL, 2003, 3240-3246.

Cazier, J.; Gill, M. 2003. Values in E-Business: Testing Value Compatibility and Trust Production in E-Commerce, in J. Ross and D. Galletta (Eds.). Proceedings of the 9th Americas Conference on Information Systems. Tampa, FL, 2003, 1723-1730.

Cazier, J.; Shao, B.; St. Louis, R. D. Personal Privacy Preferences, in R. Ramsower and J. Winston (Eds.). E-Business: A Focus on Trust and Value Compatibility, Proceedings of the 8th Americas Conference on Information Systems, Dallas, TX, 2002, 2204-2212.

Chen, I. J. 2001. Planning for ERP systems: analysis and future trends, Business Process Management Journal 7(5): 374-386. doi:10.1108/14637150110406768

Chen, C. C.; Law, C.; Yang, S. C. 2009. Managing ERP Implementation Failure: A Project Management Perspective, IEEE Transactions on Engineering Management 56(1): 157-170. doi:10.1109/TEM.2008.2009802

Chung, B. Y.; Skibniewski, M. J.; Lucas, H. C.; Kwak, Y. H. 2008. Analyzing Enterprise Resource Planning System Implementing Success Factors in the Engineering-Construction Industry, ASCE Journal of Computing in Civil Engineering 22(6): 373-382. doi:10.1061/(ASCE)0887-3801(2008)22:6(373)

Davidaviciene, V. 2008. Change managment decisions in the information age, Journal of Business Economics and Management 9(4): 299-307. doi:10.3846/1611-1699.2008.9.299-307

Doz, Y.; Santos, J.; Williamson, P. 2001. From Global to Metanational. Harvard Business School Press.

Drucker, P. 1995. The Information Executives Truly Need, Harvard Business Review 73(1): 54-62.

Ekanayaka, Y.; Currie, W. L.; Seltsikas, P. 2003. Evaluating application service providers, Benchmarking: an International Journal 10(4): 343-354. doi:10.1108/14635770310484971

Espinosa, J. A.; Slaughter, S.; Kraut, R. E.; Herbsleb, J. 2007. Team Knowledge and Coordination in Geographically Distributed Software Development, Journal of Management Information Systems 24(1): 135-169. doi:10.2753/MIS0742-1222240104

Esteves, J.; Pastor, J. 2001. Enterprise resource planning systems research: an annotated bibliography, Communications of AIS 7(8): 2-51.

Ghosh, S. 2002. Challenges on a global implementation of ERP software, in Engineering Management Conference, 2002. IEMC, 02, 1, 101-106. ISBN 0-7803-7385-5

Ghosh, S. 2003. Global implementation of ERP software--critical success factors on upgrading technical infrastructure, in IEMC, 03. Managing Technologically Driven Organizations: The Human Side of Innovation and Change, 2-4 November 2003, Albany, USA. IEEE, New York, 1, 320-324.

Ghosh, S.; Negahban, S.; Tatari, O.; Skibniewski, M. 2010. Analysis of Key Performance Indicators of the Integration between building information modeling and enterprise information system, in 6th Innovation in AEC Conference, June, 9-11 2010 (in Press).

Grembergen, W. V.; Haes, S. D. 2008. Implementating Information Technology Governance: Models, Practices and Cases. IGI Publishing.

Gupta, A. 2000. Enterprise resource planning: the emerging organizational value systems, Industrial Management and Data Systems 100(3): 114. doi:10.1108/02635570010286131

Gurbaxani, V. 1996. The new world of information technology outsourcing, Communications of the ACM 39(7): 45-46. doi:10.1145/233977.233992

Hall, C. A. S.; Day, J. W. 1977. Systems and models: terms and basic principles, in C. A. S. Hall; J. W. Day. Ecosystem Modeling in Theory and Practice: An Introduction with Case Histories. Wiley, New York, 6-36.

Hawking, P. 2007. Implementing ERP Systems Globally: Challenges and Lessons Learned for Asian Countries, Journal of Business Systems, Governance and Ethics 2(1): 21-32.

Helo, P.; Anussornnitisarn, P.; Phusavat, K. 2008. Expectation and reality in ERP implementation: consultant and solution provider perspective, Industrial Management & Data Systems 108(8): 1045-1059. doi:10.1108/02635570810904604

Ifinedo, P; Nahar, N. 2009. Interactions between contingency, organizational IT factors, and ERP success, Industrial Management & Data Systems 109(1): 118-137. doi:10.1108/02635570910926627

Jasilioniene, R.; Tamosiuniene, R. 2009. Evaluation of customer relationship system efficiency: Applying of total cost of ownership approach, Journal of Business Economics and Management 10(4): 343-347. doi:10.3846/1611-1699.2009.10.343-347

Jenson, R.; Johnson, R. 2002. Enterprise Systems Integration. Taylor & Francis, Inc.

Karahanna, E.; Agarwal, R.; Angst, C. M. 2006. Reconceptualizing compatibility beliefs in Technology Acceptance Research, MIS Quarterly 30(4): 781-804.

Kerbache, L. 2002. Enterprise resource planning (ERP): the dynamics of operations management, Interfeces 32(1): 104-105.

Kwahk, K.-Y.; Lee, J.-N. 2008. The role of readiness for change in ERP implementation: Theoretical bases and empirical validation, Information & Management 45(7): 474-481. doi:10.1016/j.im.2008.07.002

Law, C. C H.; Ngai, E. W. T. 2007. ERP systems adoption: An exploratory study of the organizational factors and impacts of ERP success, Information & Management 44(4): 418-432. doi:10.1016/j.im.2007.03.004

Longinidis, P.; Gotzamani, K. 2009. ERP user satisfaction issues: insights from a Greek industrial giant, Industrial Management & Data Systems 109(5): 628-645. doi:10.1108/02635570910957623

Lui, K. M.; Chan, K. C. C. 2008. Rescuing Troubled Software Projects by Team Transformation: A Case Study With an ERP Project, IEEE Transactions in Engineering Management 55(1): 171-184. doi:10.1109/TEM.2007.912933

Luo, W.; Strong, D. M. 2004. A framework for evaluating ERP implementation choices, IEEE Transactions on Engineering Management 51(3): 322-333. doi:10.1109/TEM.2004.830862

Mankins, M. C.; Steele, R. 2005. Turning great strategy into great performance, Harvard Business Review 83(7): 64-72.

Miles, R. H. 2010. Accelerating Corporate Transformations (Don't Lose Your Nerve!), Harvard Business Review 88(1): 68-75.

Moon, Y. B. 2007. Enterprise Resource Planning (ERP): a review of the literature, International Journal of Management and Enterprise Development 4(3): 235-264. doi:10.1504/IJMED.2007.012679

Payne, W. 2002. The time for ERP? Work Study 51(2/3): 91-93. doi:10.1108/00438020210418827

Rao, S. S. 2000. Enterprise resource planning: Business needs and technologies, Industrial Management & Data Systems 100(2): 81-88. doi:10.1108/02635570010286078

Remington, K.; Pollack, J. 2008. Tools for Complex Projects. Gower Publishing Company.

Rose, J.; Kremmergaard, P. 2006. ERP systems and technical discourse shift: Managing the implementation Journey, International Journal of Accounting Information Systems 7(3): 217-237. doi:10.1016/j.accinf.2006.06.003

Ross, J. W. 1999. Surprising Facts About Implementing ERP, IEEE IT Professional 1(4): 65-68. doi:10.1109/6294.781626

Sauer, C.; Reich, B. R. 2009. Rethinking IT project management: Evidence of a new mindset and its implications, International Journal of Project Management 27(2): 182-193. doi:10.1016/j. ijproman.2008.08.003

Sharma, R.; Yetton, P. 2007. The contingent effects of training, technical complexity, and task interdependence on successful information systems implementation, MIS Quarterly 31(2): 219-238.

Skibniewski, M. J.; Ghosh, S. 2009. Determination of Key Performance Indicators with Enterprise Resource Planning Systems in Engineering Construction Firms, ASCE Journal of Construction Engineering and Management 135(10): 965-978. doi:10.1061/(ASCE)0733-9364(2009)135:10(965)

Sledgianowski, D.; Tafti, M. H. A.; Kierstead, J. 2008. SME ERP system sourcing strategies: a case study, Industrial Management & Data Systems 108(4): 421-436. doi:10.1108/02635570810868317

Somers, T. M.; Nelson, K. L. 2004. A taxonomy of players and activities across the ERP project life cycle, Information & Management 41(3): 257-278. doi:10.1016/S0378-7206(03)00023-5

Umble, E. J.; Haft, R.; Umble, M. M. 2003. Enterprise resource planning: Implementation procedures and critical success factors, European Journal of Operational Research 146(2): 241-257. doi:10.1016/S0377-2217(02)00547-7

Venkatesh, V.; Bala, H. 2008. Technology Acceptance Model 3 and a Research Agenda on Interventions, Decision Sciences 39(2): 273-315. doi:10.1111/j.1540-5915.2008.00192.x

Venkatesh, V.; Davis, F. D. 2000. A Theoretical Extension of the Technology Acceptance Model, Four Longitudinal Field Studies, Management Science 46(2): 186-204. doi:10.1287/mnsc.46.2.186.11926

Wang, E. T. G.; Chen, J. H. F. 2006. The influence of governance equilibrium on ERP project success, Decision Support Systems 41(4): 708-727. doi:10.1016/j.dss.2004.10.005

Williams, T. 1999. The need for new paradigms for complex projects, International Journal of Project Management 17(5): 269-273. doi:10.1016/S0263-7863(98)00047-7

Williams, T. 2002. Modeling Complex Projects. Chichester, UK: John Wiley & Sons.

Saumyendu Ghosh (1), Miroslaw J. Skibniewski (2)

(1) Dept of Civil & Environment Engineering and Adjunct Faculty, George Washington University, School of Business, 1188 G.L. Martin Hall, University of Maryland, College Park, MD 20742-3021, USA

(2) Department of Management, Bialystok University of Technology, Poland E-mails: (1) [email protected] (corresponding author); (2) [email protected]

Received 8 March 2009; accepted 6 September 2010

Saumyendu GHOSH is an experienced program manager with a large global consulting organization. He has worked on all the major market segments with extensive experience as program manager, solution architect, team lead and a delivery consultant. He has completed 16 full life cycle application implementations in 22 countries. He is also a researcher on project governance theory with multiple publications on referred journals and international conferences; currently teaching at George Washington University's business school and University of Maryland's project management program.

Miroslaw J. SKIBNIEWSKI is the A. James Clark Endowed Chair Professor of Project Management in the A. James Clark School of Engineering at the University of Maryland, College Park, USA. In addition to other former appointments at academic and government research institutions worldwide, he has been serving as a visiting professor in the Department of Management at Bialystok University of Technology in Poland and, currently, as Dean of the College of Engineering at Khalifa University of Science, Technology and Research based in Abu Dhabi, UAE. Among Prof. Skibniewski's honors are the U.S. National Science Foundation Presidential Young Investigator Award, Walter L. Huber Research Prize from the American Society of Civil Engineers, elected Foreign Membership in the Russian Academy of Engineering, and an honorary doctorate from Vilnius Gediminas Technical University in Lithuania.
Table 1. Evaluation of complexities of CSFs (CSFs only adopted
from Moon (2007))

No.   Critical         Type of       Project Management
      Success Factor   Complexity    Perspective

1     Top              Structural    Top management/executive
      management       and           participation; company-wide
      support and      Directional   support; employee recognition
      commitment                     and incentive; funds support

2     Project          Structural    Effective project
      Management                     management; project planning
      and Evaluation                 project schedule and plan;
                                     project scope; work time
                                     schedule; detailed schedule;
                                     project completion time;
                                     project cost; auditing and
                                     control; project management
                                     of consultants and suppliers

3     Business         Directional   BPR and alignment of the
      Process          and           business with the new
      reengineering    Temporal      system; process adaptation
      and minimum                    level; process standards;
      customization                  business process skills; job
                                     redesign; worked with ERP
                                     functionality maintained
                                     scope; minimum customization

4     ERP team         Temporal      Composition of project team
      composition,     and           member; project team
      competence       Structural    empowerment; project team
      and                            competence; the domain
      compensation                   knowledge of the ERP project
                                     team; teamwork participation;
                                     attitude of the ERP project
                                     team; professional personnel;
                                     constitution of project team;
                                     ERP team compensation

5     Change           Structural    Managing changes; managing
      Management       and           conflicts; conflicts between
      Process          Directional   user departments

6     User training    Structural    Training employee; education
      and evaluation                 on new business processes;
                                     adequate training and
                                     instruction; training of
                                     project team and end-user;
                                     effective  training; Hands-
                                     on training

7     Business plan    Directional   link to business strategy and
      and vision       and           execution, ERP strategy and
                       Temporal      implementation methodology
                                     and implementation; consensus
                                     on execution and control;
                                     clear ERP strategy execution

8     Enterprise       Directional   Effective enterprise-wide
      wide commu-      and           communication;
      nication and     Temporal      interdepartmental
      cooperation                    communication; free flow of
                                     information in project team;
                                     communicating ERP benefits;
                                     communication with ERP
                                     project team

No.   Comments

1     Company-wide commitment;
      dedicated resources;
      funding utilization and
      alignment with objectives

2     Project managers will be
      required to work with
      multiple stakeholders who are
      not in direct hierarchy of
      the PM, therefore,
      governance should ensure
      project managers are
      empowered to execute

3     BPR is not directly related
      to ERP implementation but a
      necessary pre-requisite to
      make ERPs successful.
      Changing business process
      would often lead to
      reduction in force, so BPR
      requires systemic approach to
      governance to adopt new
      system. This is a  strategic
      direction to be set to meet
      business process with
      technical solution

4     Governance should ensure
      proper representation from
      all stake holders. Setup of
      proper steering committee;
      balanced implementation team
      and free up domain experts;
      project team: the best and
      brightest;  Governance
      process should ensure proper
      risk-reward is  balanced for
      team members

5     Management of  expectations;
      organizational  resistance to
      change; change readiness;
      change in  business goals
      during the  project;
      conflicts between user
      departments; reasonable
      expectation with definite
      target

6     Choice of education partner
      and medium and mode
      of training

7     Business plan-vision-goals-
      justification; vision
      statement and adequate
      business plan; feasibility-
      evaluation of ERP project;
      Effective strategic  thinking
      and planning strategic;
      competitive pressure; clear
      goals and objectives; clear
      desired outcomes; strategic
      IT planning

8     Interdepartmental
      cooperation; open and honest
      communication among the
      stakeholders; cross-
      functional coordination

Table 2. Evaluation of complexities to mitigate key ERP risk factors
(RFs only adopted from Alorm (2007))

No.   Risk Factor           Type of Complexity

1     Inadequate            Structural,
      selection of          technical and
      application           directional

2     Ineffective           Structural,
      strategic             technical,
      thinking and          temporal and
      planning strategic    directional

3     Ineffective project   Structural,
      management            technical,
      techniques and        temporal and
      bad managerial        directional
      conduction

4     Inadequate            Temporal
      change                and structural
      management

5     Inadequate training   Structural and
                            temporal

No.   Risk Mitigation--Complexity
      Perspective

1     Selection can be proper if
      ERP adopter  understands how
      it will impact on the
      business from implementation
      and supporting after the
      application goes to
      production. ERP adopter needs
      ensure that organization is
      capable of taking that
      initiative and ready to
      accept business, cultural and
      technological changes
      involved. Mitigation requires
      understanding the scope and
      domain of the implementation
      and ecosystem involved

2     ERP adopters should
      understand all the four
      complexities since all four
      complexities are involved in
      various CSFs. ERP adopter
      should carefully consider all
      the actors  involved in ERP
      implementation ecosystem and
      ensure proper governing and
      management process is in
      place involving each  actor
      involved

3     Same as # 2

4     Change management may be due
      to  technical complexities in
      the product  (technical) and
      incompatibility between
      business process supported by
      the ERP and existing business
      process. The business process
      supported by the ERP is
      beyond any control of the ERP
      adopter and therefore
      temporal in nature

5     Availability of training may
      be out of  control of ERP
      adopter and may add project
      complexities to schedule
      those tasks in the project
      plan

Table 3. ASP services and complexity mapping

Source                       Type of
                             Complexity

Security (Currie             Structural
and Seltsikas, 2001)         and technical

Ability to Integrate         Directional
(Greg, 2000)                 and technical

Pricing (Gerrit              Structural
and Gunther, 2000)           and temporal

Customer Service             Structural

SLA Monitoring               Structural
and Management

Reliability, Availability    Temporal
and Scalability

Source                       Project Management
                             Responsibilities

Security (Currie             Physical security
and Seltsikas, 2001)         Security of data and applications
                             Backup and restore procedure
                             Disaster recovery plan

Ability to Integrate         Ability to share data between
(Greg, 2000)                 applications, automatically
                             populating one application with
                             data from another application

Pricing (Gerrit              Effect of TCO
and Gunther, 2000)           Hidden costs/Charges
                             Return on investment

Customer Service             Help desk and training
                             Support for administration of
                               accounts

SLA Monitoring               Clearing defined monitoring
and Management               procedure

Reliability, Availability    24X7 supports
and Scalability
联系我们|关于我们|网站声明
国家哲学社会科学文献中心版权所有