4: Literature Review: Factors Affecting the Relationships between the ERP System’s Evolution and IS Integration or Disintegration – ERP and Information Systems

4
Literature Review: Factors Affecting the Relationships between the ERP System’s Evolution and IS Integration or Disintegration

This chapter gives a description of the literature review. Given that an enterprise resource planning (ERP) is an indicator of information system (IS) integration, it is important to study some interaction factors between ERP systems and the IS. Within this perspective, the ERP system’s selection criteria and then the success or failure of the ERP implementation are crucial factors to consider. The analysis of the literature helped us to discover the appropriate factors that impact the IS evolution’s trajectory, thereby allowing us to reply to the research question.

Kumar et al. [KUM 03] analyzed a practical survey of 20 enterprises in Canada of ERP selection criteria (functionality of the ERP, better fit with company’s business processes, fit with parent/allied organization systems, cross-modular integration, best business practices available in the system, system reliability, implementation project management, vendor reputation, availability of regular upgrades, compatibility with other systems, vendor’s support/service infrastructure, ease in customizing the system and lower costs of ownership).

Grabski et al. [GRA 03] confirm that an ERP system’s implementation differs from more traditional IS implementation in terms of scale, complexity, organizational impact and the costs involved. Umble et al. [UMB 03] mention the following criteria: price, supplier support, ease of implementation, closeness of fit to the company’s business, flexibility when the company’s business changes and value (total implementation cost vs. total value to the company).

Verville and Halingten [VER 03] suggest a list of selection criteria: customization; user interfaces; whether the organization’s existing database management system is compatible with the proposed solution; the ability of the proposed solution to integrate into the organization’s existing hardware architecture; the architecture of the proposed solution (client/server, two-tier, three-tier or other); scalability of the system; training (in-house or external to the organization; does vendor conduct the training or is outsourced?); performance; ability to assist the organization with the implementation; the association with or the availability of third party vendor/partners; vision future plans and trends regarding the direction of the technology and/or strategic positioning; financial strength; product recognition; ability to meet future needs; reputation; vision and/or strategic positioning of the vendor; longevity of the vendor; qualifications, experience and success in delivering solutions to organizations of a similar size, complexity and geographic scope; quality of the vendor’s proposal; demonstrated understanding of requirements, constraints and concerns; implementation plan that properly positions the proposed solution to achieve the maximum level of business benefits; implementation services; implementation strategy; and support services.

Fisher and Kiang used the following criteria to evaluate ERP packages: service and support, training, scalability, implementation flexibility, integration, manufacturing process, core financials, purchasing and sales, human resource process, support fees and training fees [FIS 04]. Han mentions many ERP selection criteria: vendor, functionality and scalability [HAN 04].

Wei et al. identify six system software factors and three vendor factors. System software criteria are total costs, implementation time, functionality, user friendliness, flexibility and reliability [WEI 05]. Vendor criteria are reputation, technical capability and provision of ongoing services. Keil and Tiwana synthesize the ERP selection criteria: cost, reliability, functionality, ease of use, ease of customization, ease of implementation and vendor reputation [KEI 06]. Lall and Teyarachakulmenion synthesize four ERP selection criteria: complexity of implementation, estimated cost of implementation, functional match and vendor profile [LAL 06].

Ayağ and Özdemir [AYA 07] discuss the following criteria: system cost (license fee, vendor support, maintenance cost and infrastructure cost), vendor support (good reputation, consulting performance, research and development (R&D) capability, technical-support capability and training performance), flexibility (upgrade ability, ease of integration and easy of inhouse development), functionality (module completion, function fitness and security level), reliability (stability and recovery ability), ease of use (easy of operations and easy of learning) and advanced technology (standardization, integration of legacy systems and easy to maintain). Yang et al. [YAN 07] mention the importance of an ERP system’s acceptance by end users (hardware requirements, compatibility with old hardware, hardware upgrade capability, fitness of available modules, acceptance by middle-to-high-level managers and working load for end users).

Bueno and Salmeron [BUE 08] identify many criteria related to ERP systems: the capacity to integrate the ERP system with the current IS/information technology (IT), trust in the ERP system, modularity, adaptation of the ERP to the current system needs, software costs, consultation costs, maintenance costs, parameter complexity, employee continuing education, traditional organizational culture, complexity of the organizational structure, traditional organizational strategy and complexity of organizational processes.

In the research performed by the Aberdeen consultancy group [ABE 06, ABE 07], 1,245 and 1,680 companies, respectively, of different size, industries and geographical regions, have participated. As a result, we defined the three ERP selection factors cited most frequently. Functionality has been named as the most important criterion (in 69 and 75% of cases, respectively). In 53% of cases, the system price has been mentioned. Ease of use was the third most popular factor, cited in 42 and 51% of cases, respectively. The surveys performed in the years 2008 and 2009 by the same group have shown and confirmed the previous results.

Ratkevičius et al. [RAT 12] studied 12 of the most important software-related ERP selection criteria: ERP functionality, total costs of ERP implementation projects, vendor reputation, ERP reliability, ease of integration with other systems, advanced technology, scalability, upgrade ability, customization/parameterization possibilities, ease of use, flexibility and modularity.

In summary, when a firm wants to select or buy an ERP package, there are some crucial interrogations to help guide the selection process:

  • – Would it be possible to pay the “Total Cost of Ownership (TCO)” and can the return on investment (ROI) be positive within the framework of an economic crisis?
  • – Would the firm’s IS be independent or completely dependent on the ERP vendor (in other words, the ERP system is it modular or would it be possible to buy a part [i.e. certain modules] of the ERP system only)?
  • – Will ERP project management be a success or a failure (what are the risks)?
  • – Is it an interoperable ERP?
  • – Which strategy will be adopted by clients to integrate the ERP system within the framework of the existing system (urbanization or total overhaul)?
  • – Is it a complex or a simple ERP system?
  • – What is the evolution strategy of ERP vendors?

Beyond the ERP selection criteria, many authors have performed significant research to identify critical factors in ERP implementation. Several academics and practitioners have tried to capture the main reasons for the success or failure of ERP system implementations [EWU 97, GLA 98, LAU 99, SWA 99, PAR 00, SOH 00, SUM 00, MOT 02, MAJ 03, STA 04, WEI 04, ANE 06, KIM 06, IBR 08, LIN 08, PAR 09]. Most of these analyses and lists focus on the factors that contributed to failure rather than the factors that contributed to success. There are many factors that appear on most of the lists: top-level management support for the project, user training and education, project management, project team competence and change management, process and organizational adaptation, measurement of the benefits, resistance to change, scalability and scope, and ERP importance.

Some researchers investigated the “Critical Success Factors (CSFs)” of ERP implementation. CSFs of ERP have been demonstrated by an extensive number of publications: [DAV 98, BIN 99, SHA 99, BRO 99, CAN 99, GRI 99, HOL 99, LAU 99, KUM 00, JAR 00, PAR 00, WIL 00, ALM 01, CHE 01, EST 01, NAH 01, ROS 01, SOM 01, AKK 02, HON 02, MUS 02, VER 02, MAB 03, SPA 03, UMB 03, COL 04, RAS 05, SUN 05, ALM 06, KIN 06, PLA 06, FIN 07, KHO 07, BRA 08, BUE 08, ELS 08, NGA 08, SHA 09].

However, some researchers studied the “Critical Failure Factors (CFFs)” of ERP implementation. For example, failure factors were highlighted in the following papers: [YEO 02, SHO 05, TSA 05, MOM 10]. Kumar et al. [KUM 10] did a study to prioritize the issues affecting an ERP system in a medium-scale fertilizer company and the following factors were determined: training and testing, employee retention, customization and external consultant dependency. The CFFs are defined as the key aspects where “things must go wrong”. This means that these critical failure factors could compromise the reliability of the IS integration, and thus a kind of disintegration in the IS architecture could be happened.

For the purpose of our research, we have classified, organized and grouped the literature within the framework of seven main factors as shown in Table 4.1. All of the articles reviewed were related to ERP selection criteria and to the main reasons for the success or failure of ERP implementation.

Table 4.1. An alignment of the literature with the main factors affecting the relationships between the ERP’s evolution and IS integration or disintegration

Themes, of the literature review, used to determine = the research’s factors affecting the relationships between the ERPs’ evolution and the IS integration or disintegration Authors (literature review)
High costs, lower costs of ownership, software costs, consultation costs, maintenance costs, ROI, business implications of ERP implementations, strategic impact of ERP implementation on a firm’s competitive advantage, competitive strategy, reductions in costs, reductions in customer lead times and production times, reducing total time from order to delivery, improve competitiveness, value, (total implementation cost vs. total value to the company), estimated cost of implementation, competitive advantage and profitability, organizational bankruptcy =
ECCO (Economic Crisis and Competitiveness)
Bulkelery, 1996; Scott, 1999; Kumar and Hillegersberg, 2000, Davenport 1998; Akkermans et al., 2003; Umble, Haft and Umble, 2003; Gunn, 1998, Somers and Nelson, 2001; Ayağ and Özdemir 2007; Majed, 2000 ; Markus et al., 2000; Ptak, Schragenheim, 2000; Sadagopan, 1999; Bueno and Salmeron 2008; Fisher, Fisher and Kiang, 2004; HsiuJu Rebecca Yena et al., 2004 ; Keil and Tiwana, 2006; Lall and Teyarachakul 2006; Rao 2000; Grabski et al. 2003; Umble, Haft and Umble 2003; Kumar, Maheshwari and Kumar 2003; Wei, Chien and Wang 2005; Leon 2007; Yang, Wu and Tsai 2007; Mabert, Soni and Venkatraman 2000; Bernroide, Koch 2001; Severin V. Grabski, Stewart A. Leech, Lu Bai 2001; Aberdeen’s 2007 study; Hitt, Wu, & Zhou, 2002; Kalling, 2003; Kennerley and Neely, 2001; Mabert et al., 2001; Poston and Grabski, 2001; Hayes et al., 2001; Robinson and Wilson, 2001; Hitt et al., 2002; Hunton et al., 2002; Gattiker and Goodhue, 2002; Beretta, 2002; Hunton et al., 2003; Somers et al., 2003; Spathis and Constantinides, 2003; Stensrud and Myrtveit, 2003; Spathis and Constantinides, 2004; Hedman and Borell, 2004; Nicolaou, 2004; Gattiker and Goodhue, 2004; Huang et al., 2004a; Spathis and Ananiadis, 2005; Chand et al., 2005; Tsai et al., 2006; Ziaee, Fathian and Sadjadi, 2006; Wieder et al., 2006; Wu and Wang, 2006; Spathis, 2006; Lall and Teyarachakul, 2006; Ayağ and Özdemi, 2007; Leon, 2007; Uflacker and Busse, 2007; Yang, Wu and Tsai 2007; Bueno and Salmeron, 2008; Aberdeen group, 2006, 2007, 2008 and 2009; Trabelsi et al., 2013.
external consultant dependency, ERP modularity =
TDEV (Total Dependency on the ERP Vendor)
Dhénin, 2001; Themistocleous et al., 2001; Kumar, Maheshwari and Kumar (2002, 2003); Rowe et al., 2005; Ziaee, Fathian and Sadjadi, 2006; Naugès, 2007; Uflacker and Busse, 2007; Bueno and Salmeron (2008); Vijaya Kumar et al., 2010; Bidan et al., 2012; Ratkevičius et al., 2012.
training and testing, Customization/parameterization, employee retention, support from top management, ERP project efficiency, user knowledge, project team competency, change management =
PMER (Project Management ERP)
Anderson and Narasumhan, 1979; Barki, et al. 1993; Bulkelery, 1996; Ewusi-Mensah, 1997; Davenport, 1998; Holland and Light, 1999; Jiang and Klein, 1999; Markus et al., 2000; Grabski et al. 2003; Verville and Halingten, 2003; Wei, Chien and Wang, 2005; Stapleton and Rezak, 2004; Weightman, 2004; Anexinet, 2006; Kimberling, 2006; Nah and Delgado 2006; Ziaee, Fathian and Sadjadi, 2006; Yang, Wu and Tsai 2007; Ibrahim, et al., 2008; Lindley, et al., 2008; Chen, R. 2008; Vijaya Kumar et al., 2010; ParijatUpadhyay, 2010.
standardization, integration possibilities with the legacy systems, capacity to integrate the ERP with the current IS/IT, integrate other specialized software products with the ERP suite, exchange data and enable sharing of information, interoperate implies that one system performs an operation for another system, ease of integration with other systems =
INTE (INTEroperability of the ERP)
Bingi et al., 1999; Everdingen, 2000; Sprott, 2000; Markus, 2001; Papazoglou and Georgakopoulos, 2003; Irani et al., 2003; Sharif et al., 2005; Jamison, Layman, Niska, Whitney, 2005; Bueno and Salmeron, 2008; Naugès, 2008; Chen et al.,2008; Maheshwari and Kumar (2002, 2003); Verville and Halingten, 2003; Konstantas et al, 2005; Jamison, Layman, Niska, & Whitney ??; Ayağ and Özdemi, 2007; Moon, 2007; Leon, 2007; Bidan et al., 2012; Ratkevičius et al., 2012; Trabelsi et al. 2013.
traditional organizational strategy, traditional organizational culture, complexity of the organizational structure, complexity of organizational processes, organization’s existing compatible with the proposed solution, can the proposed solution integrate into the organization’s existing hardware architecture?, compatibility and adaptability of ERP with old systems and with other systems, modernize the IS by erasing the legacy systems, modernize the IS without erasing the legacy systems, changes within an organization =
ESES (Evolution Strategy of Existing Systems)
Davenport, 2000; O’Leary, 2000; Themistocleous, Irani, & Love, 2002; Bueno and Salmeron, 2008; Verville and Halingten, 2003; Yang, Wu and Tsai 2007; Kumar, Maheshwari and Kumar 2003; Hopkins & Jenkins, 2008; Trabelsi et al., 2013.
user-friendly interface and operations, ERPs are complex systems, ease of customization, ease of implementation, ease of integration, ease of use (easy of operations and easy of learning), parameter complexity, vendor’s complexity, simplicity of training and use, using ERP intuitively without additional specific knowledge, complexity due to the ERP complexity =
COER (COmplexity of ERP)
Pivnicny and Carmody, 1989; Ciborra et al. 2000; Everdingen 2000; Schönefeld and Vering, 2000; Hanseth et al., 2001; Grabski et al., 2003; Verville and Halingten, 2003; Wei, Chien and Wang (2005); Kumar and Hillegersberg, 2000; Ciborra et al., 2000; Hanseth et al. 2001; Bueno and Salmeron, 2008; Verville and Halingten, 2003 ; Lall and Teyarachakul 2006; Keil and Tiwana 2006; Ayağ and Özdemi, 2007; Uflacker and Busse, 2007; Yang, Wu and Tsai (2007); Leon, 2007; Ratkevičius et al., 2012; Aberdeen group, 2006, 2007, 2008 and 2009.
module completion, scalability and scope and ERP importance, complete functionality, ERP functionality, system reliability, extension, vendor’s vision (future plans and trends regarding the direction of the technology and or strategic positioning), product recognition, vision and strategic positioning of the vendor, longevity of the vendor, qualifications, experience, domain knowledge suppliers, technically upgradable, functional match and vendor profile, vendor profile (prompt availability of software upgrades and technical support), adaptability of ERP system (employed system technologies, embedded database system, system development tool and language), availability of regular upgrades, R&D capability of vendor, importance of choosing a suitable ERP vendor (reputation, technical capabilities and provision of ongoing services), functional match and vendor profile, uses latest technology, upgrade ability of the ERP vendor, functional match (capability of the ERP to meet the business requirements of the firm), adaptability of ERP system (employed system technologies, embedded database system, system development tool and language) =
ESEV (Evolution Strategy of ERP Vendors)
Goldenberg et al., 1991; Pivnicny and Carmody, 1994; Chau, 1995; Hecht, 1997; Everdingen et al., 2000; Rao 2000 ; Siriginidi, 2000; Schönefeld and Vering, 2000; Chen, 2001; Bernroider and Koch 2001; Stensrud, 2001; Nah, Faja, Cata, 2001; Verville and Halingten (2003); Kumar, Kumar and Maheshwari 2002, 2003; Scott and Kaindl, 2000; Zheng et al., 2000; Tarn et al., 2002; Willis and Willis-Brown, 2002; Choi and Kim, 2002; Sumi and Tsuruoka, 2002; Yen et al., 2002; Lee et al., 2003; Weston, 2003; Akkermans et al., 2003; Rutner et al., 2003; Newell et al., 2003; Symeonidis et al., 2003; Kovács and Paganelli, 2003; Ash and Burn, 2003; Ng and Ip, 2003; Verville and Halingten, 2003; Gulledge et al., 2004a; 2004b; Frank, 2004; Bendoly and Kaefer, 2004; Davenport and Brooks, 2004; Koh and Saad, 2004; Barthorpe et al., 2004; Ndede-Amadi, 2004; Cardoso et al., 2004; Han, 2004; Swanton 2004; Chou et al., 2005; Burn and Ash, 2005; Moon and Phatak, 2005; Moller, 2005; Bendoly and Schoenherr, 2005; Lea et al., 2005; Jaiswal and Kaushik, 2005; Kelle and Akbulut, 2005; Biehl, 2005; Burca et al., 2005; Sammon and Adam, 2005; Wei, Chien and Wang (2005); Keil and Tiwana 2006; Lall and Teyarachakul 2006; Sharma et al., 2006; Although Liao, Li and Lu 2007; Johansson, 2007; Uflacker and Busse, 2007; Yang, Wu and Tsai 2007; Bueno and Salmeron 2008; ParijatUpadhyay, 2010; Aberdeen group, 2006, 2007, 2008 and 2009.

As stated previously, values were assigned to each research factor. This evaluation helps to determine the impact that each of these seven factors (variables) has on IS integration or disintegration.

We can notice from the literature review two main possibilities:

  1. – the first is the ERP system’s selection and then the success of its implementation. This scenario could logically improve the IS integration;
  2. – the second possibility is the failure of the ERP implementation, or, before implementation is even possible, the rejection of the ERP system (e.g. the ERP system’s selection is postponed). This scenario could promote IS disintegration instead of integration.

In other words, we deemed those variables that can improve the IS integration to be positive values (first possibility). Based on this logic, we attributed negative values when the ERP system’s evolution could lead to IS disintegration instead of its integration (second possibility).

The seven identified factors or variables (ECCO, TDEV, PMER, INTE, ESES, COER and ESEV) will be studied below in more detail.

4.1. Economic crisis and COmpetitiveness (ECCO)

Legacy systems have been described as having a “consequentially negative impact on competitiveness” [BRO 95] while being “non-maintainable and inflexible” [O’CA 99]. In order to improve this competitiveness, authors have advised to implement an ERP. Akkermans et al. supported the strategic impact of ERP implementation on a firm’s competitive advantage [AKK 03]. In the past few years, ERP has become a “must have” system for almost every firm to improve competitiveness [HSI 04]. The ERP can be considered an integration tool that is able to help the competitiveness of the company [PER 04]. Competitive priorities clearly affect the practices of ERP implementation in many aspects. The ERP system is implemented to support these competitive priorities. The authors confirm that ERP implementation should be aligned with competitive strategy.

However, Davenport suggested that firms should restrain from ERP investment until further study of its business implications is fully understood [DAV 98]. The cost of ERP is significant and failure can result in the demise of the organization, as in the case of the FoxMeyer Drugs bankruptcy [SCO 99].

Total cost of ERP project (TCO) is a selection criterion that is mentioned quite often by Mabert et al., Bernroide and Koch, Umble et al., Fisher et al., Wei et al., Keil and Tiwana, Lall and Teyarachakul, Yang et al., Bueno and Salmeron, Ratkevicius and others [MAB 00, BER 01, UMB 03, FIS 04, WEI 05, KEI 06, LAL 06, YAN 07, BUE 08, RAT 12]. Most researchers include as part of the TCO: an upgraded technical infrastructure, software licenses, ERP implementation, support, maintenance, consultant fee and user training. Summarizing different definitions, ERP costs include all ERP implementation and usage costs (both direct and indirect) during the total lifetime of the system. Direct expenses involve hardware, software and implementation costs. Indirect, or hidden, expenses are related to productivity drop during the ERP implementation period when activity outage or stoppage occurs.

Firms experiencing unprecedented economic crisis tend to delay major ERP projects considered to be too expensive. Pending a more stable environment, they favor, in principle, secondary short-term projects. However, in a state of economic crisis, companies operate in a difficult environment: saturated markets, increased competitiveness, customers more demanding and less loyal, etc. In such an environment, the competitiveness of enterprises depends on the reliability of their IS integration internally as well as their mode of communication with partners (customers, suppliers, etc.).

According to Ayağ and Özdemi [AYA 07], ERP selection criteria are defined with regard to their influence on the company’s performance indicators: profitability and competitive advantage, which is directly related to system costs, including license fee, consultant expenses, maintenance cost and infrastructure cost. This system cost or price is a dimension that determines a company’s competitive advantage and is calculated as the total amount of expenses related to ERP implementation. Moon [MOO 07] explained that since the investment and collective efforts required to implement and run ERP systems are significant to any organization, the fundamental question of the ERP system’s value has been a key issue: is an ERP system of any value to an organization? What values can an ERP system bring to an organization? The value assessment methods can be numerous and complex. For example, the benefits may be measured by cost savings, return on investment, asset turnover, return on assets, and perceptions by the market, etc.

An ERP system helps different parts of an organization to share data and reduce costs [ALA 01]. The promised benefits of a successful ERP implementation appear attractive to an organization, because they include reductions in costs (inventory, raw materials and production), customer lead times and production times [SOM 01]. Companies that automate and streamline workflows across multiple sites (including suppliers, partners and manufacturing sites) produced 66% more improvement in reducing total time from order to delivery (Aberdeen’s 2007 study of the role of ERP in globalization). There are also reports of ERP systems providing benefits such as cost reductions, improved productivity, better managerial decision-making and facilitation of process or structural change [SHA 00, BAR 02, KAM 08, FED 09].

However, Majed [ALM 00] reported that 70% of ERP implementations did not achieve their estimated benefits. Companies must be competitive to sell their goods and services in the marketplace. A research note has published the results of an analysis of 81 public companies that use systems, applications and products for data processing (SAP) software and were listed on SAP’s Website. Contrary to SAP’s advertising claim that “Best run Businesses run SAP” and that its customers are 32% more profitable than their peers, SAP customers were in fact 20% less profitable than their peers. SAP customers had an average “return on equity (ROE)” of 12.6% versus an industry average of 15.7%. It is interesting to note that some areas of significant focus for SAP, customer relationship management (CRM) and supply chain management (SCM) had customers who fared quite poorly, with CRM customers achieving 18% lower profitability and SCM customers achieving 40% lower profitability than their peers [CAM 06].

Should the competitiveness of a firm, especially within the context of economic crisis, be a criterion to be taken into account by all stakeholders within the framework of an ERP’s evolution? If so, would IS integration be favored? If not, would its disintegration be provoked? In other words, could the economic crisis lead firms to avoid an ERP system’s selection because of its high costs? If so, could this crisis delay IS integration or even promote its disintegration?

Generally, an integrated IS is an important element contributing to the firm’s competitiveness. Depending on the ROI of the ERP system, this contribution could be positive or negative. While faced with economic crisis, firms’ arbitration (via the ROI) in terms of ERP projects is crucial. It allows firms to make important decisions regarding the adoption of ERP systems (or not) as part of their IS.

Consequently, if the competitiveness of firms could be improved by an ERP system, the integration rate of IS would be increased. On the contrary, if the competitiveness of firms could not be improved by the selection of an ERP system or even by its expansion from 1st G to 2nd G, a kind of IS disintegration would be maintained or even increased. As a result, we can propose economic crisis and competitiveness (ECCO) as a factor that could guide the relationship between the ERP system’s evolution and IS integration or disintegration.

Based on an exploration of the literature, as well as a logical analysis and the rating schema suggested in our research methodology, we assign this factor, within the context of economic crisis, two different values (one positive and another negative): if the competitiveness would be improved by an ERP system (as evidenced by a positive arbitration of ROI), the value “ECCO+” is given; whereas, if competitiveness could not be improved by an ERP system (as evidenced by a negative arbitration of ROI), the value “ECCO–” will be assigned.

As an ERP system is a element favoring IS integration, we think that an “ECCO+” could promote a total integration of IS (TIIS) or an hybrid integration of IS (HIIS) (e.g. the IS would be totally integrated if the architecture is composed of one ERP system only, which can improve the firm’s competitiveness; while the IS would be more or less integrated if the ERP system that helps to increase this competitiveness is only a part, with other applications, of the IS). However, we believe that an “ECCO-” could encourage an HIIS or even a disintegrated information system (DIS) (e.g. the IS would be partially integrated if, instead of an ERP system’s expansion from 1st to 2nd G, which does not improve the firm’s competitiveness, a part of the ERP 1st G is completed by some “Best of Breed (BoB)” applications, which are more or less integrated with this ERP system; or if the firm keeps its disintegrated legacy systems without any selection of an ERP system due to a negative arbitration of ROI).

4.2. Total dependency on the ERP vendor (TDEV)

“Do customers want to keep the freedom to choose the best solution for each application domain?” [LAM 01]. Among firms deploying ERP systems, very few adopt all the available process modules, opting not to be fully committed to the integration and standardization options required by the ERP system [THE 01, ROW 05, BID 12]. Independent ERP consultants should be impartial when assessing their technology level, because ERP vendors or implementation specialists tend to favor their own production features [RAT 12].

ERP modularity is analyzed by Kumar et al. [KUM 02, KUM 03], Bueno and Salmeron [BUE 08] and Ratkevičius [RAT 12]. Modularity enables ERP customers from all available functionalities to choose modules and functional groups that are necessary for their organization. Our definition of the dependency on the ERP vendor matches with the definition of ERP modularity. Total dependency means that the company is obliged to buy all of the modules of an ERP (complete package) without being able to acquire only some modules (independence). The total dependence on the ERP vendor (or a reduced number of vendors) could be seen by companies in two different ways:

  1. – a desire for such dependence, which allows the firm to have a limited number of counterparts related to IS (advantage);
  2. – a fear of such dependence, which means that a vendor is in a position of power and influence over the company (disadvantage).

The current policy that has been adopted by vendors is often a policy of independence given to firms to choose the modules that meet their needs and desires. Firms are under no obligation to purchase the complete package (all modules). “At Oracle we prefer the term “E-Business Suite” to that of “integrated whole”. It is our way to explain that we do not impose on our customers to immediately buy all of our products when they are only interested in a single brick. Our approach is very modular” [ANI 01]. SAP R/3 reaches a high level of variability and flexibility (modularity) by allowing customers to select only those modules that are required for their specific business scenario [UFL 07]. We note that the factor of the dependency on the ERP vendor is taken into consideration by Oracle and SAP.

Should the dependency of a firm on vendors be a criterion to be taken into account by all stakeholders within the framework of an ERP system’s evolution? If so, would IS integration be improved? If not, would its disintegration be initiated?

Consequently, we propose the total dependency on the ERP vendor (TDEV) as a factor that could guide and affect the relationship between the ERP system’s evolution and IS integration or disintegration. In fact, a total dependency on one ERP vendor promotes the integration of IS (e.g. the IS would be totally integrated [TIIS] if it is composed of only one ERP); while, an independence from one ERP vendor helps develop a kind of disintegration (e.g. the IS would be more or less integrated [HIIS] if it is composed of many ERP systems that are interconnected or the IS would be disintegrated [DIS] if the architecture is composed of many subsystems [ERP systems, applications, etc.] that are not interconnected).

Based on an exploration of the literature, as well as a logical analysis and the rating schema suggested in our research methodology, we assign this factor two different values (one positive and another negative): total dependency on the ERP vendor “TDEV+” or independence from the ERP vendor “TDEV-”. As an ERP system is a factor favoring IS integration, we think that a “TDEV+” could promote a TIIS, while a “TDEV-” could encourage an HIIS or even a DIS.

4.3. Project management ERP (PMER)

Some researchers have investigated factors (e.g. top management support, sufficient training, proper project management, communication, etc.) that are critical to the success of ERP implementation [BIN 99, GRI 99, HOL 99, KUM 00, WIL 00, HON 02, VER 02]. Yang et al. [YAN 07] mention the importance of the service quality of consultants (expertise about ERP implementation, ability of project manager, implementation methodology and tool, and experience on similar cases).

Several researchers have also mentioned the importance of suitable customization (parameterization possibilities): [MAB 00, KUM 03, BER 05, YAN 07]. Reliable management of an ERP project should be based on good customization, adequacy of user training, competency in project implementation team, acceptance of changes brought about by implementation and support and participation of external consultants [CHE 08b]. As an ERP system is an element favoring IS integration, a relationship between the CSFs in ERP implementations and IS integration could be proposed.

Although the success factors of ERP projects are frequently analyzed and their impacts on IS integration are emphasized, the role of failure factors is not sufficiently studied as an eventual stimulator of IS disintegration. “Many ERP systems still face resistance, and ultimately, failure” [ALA 01]. “Failure rates are estimated to be as high as 50% of all ERP implementations” [MUS 06]. “70 percent of ERP implementations fail to deliver anticipated benefits” [WAN 07]. Despite the promise of ERP applications, studies have found that a high percentage of ERP implementations are classified as failures [WON 03, HIC 10, KAN 11]. Panorama Consulting predicted an increase in the number of ERP failures and lawsuits for 2012 [KIM 11].

Many authors have studied risks in ERP projects, and several risk categories have been proposed. By making a synthesis of the propositions of Aloini et al., Barki et al., Bourdeau et al., Bradford et al., Bradley, Kyung-Kwon et al., Tiwana et al., Tsai et al. and Weiling et al. [ALO 07, BAR 93, BOU 03, BRA 03, BRA 08, KYU 02, TIW 06, TSA 09c, WEI 08], the project risk categories are: – stopping the project; – overrunning the deadline and exceeding the budget; – degree of integration desired is not reached; – lack of overall vision; – lack of project team’s skills (internal and/or external); – resistance to change by users; – inadequate business project reengineering (BPR); – inadequate training and instruction; – gap between specific needs and generic processes provided by the ERP; – a lot of specific developments; – poor settings (configuration); – project complexity, which can be linked to the ERP complexity.

Davenport [DAV 98] attributed many failures of ERP implementation to a lack of alignment with business needs. There is no single “best process” to do business, as ERP systems assume, and, therefore, the customization of ERP systems is necessary. He further cautioned that firms could lose their source of advantage by adopting processes that are indistinguishable from those of their competitors. However, aligning the business process to the software implementation is critical because, as far as possible, software should not be modified [HOL 99, SUM 99]. Modifications should be avoided to reduce errors and to take advantage of newer releases [ROS 00]. “You should never go too far in the specific (developed programs), otherwise you lose the whole point of a package” [GAU 07]. A lot of specific coding could make the ERP lose the advantages of integration.

Unreliable management of an ERP project is the result of bad customization, lack of user training, absence of in-house skills and deficiency of project team expertise [AND 79, BAR 93, HOL 99, JIA 99]. As an ERP system is a factor of IS integration, a relationship between the CFFs in ERP implementations and IS disintegration could be proposed.

Should a methodology for optimizing project management, based on best practices, be a criterion to be taken into account by all stakeholders within the framework of an ERP system’s evolution? If so, would IS integration be improved? If not, would its disintegration be possible?

Consequently, there is a relationship between the CSF/CFF in ERP implementations and IS integration or disintegration. We propose the “Project Management ERP (PMER)” as a factor that could guide and impact the relationship between the ERP system’s evolution and IS integration or disintegration. As an ERP system is a factor favoring IS integration, the success of ERP project management promotes IS integration, which would consist of well-implemented ERP system; while the failure of ERP project management can lead to a kind of IS disintegration (the ERP system would not be well implemented and would not be well integrated within the framework of the whole architecture). We are interested in the failure of an ERP system’s implementation because we think that it could engender a kind of regression from a TIIS to an HIIS or to a DIS.

Based on an exploration of the literature, as well as a logical analysis and the rating schema suggested in the research methodology, we assign this factor two different values (one positive and another negative): reliable ERP project management “PMER+” or unreliable “PMER-”. We think that a “PMER+” could promote a TIIS or an HIIS, while a “PMER–” could encourage a DIS.

4.4. INTEroperability of the ERP (INTE)

“Interoperability is the connectivity of two systems to flow information freely from one to another and back again” [JAM 05]. Indeed, interoperability is characterized by the ability of independent systems to work together with minimal effort [KON 05]. It is also the capacity for two systems to understand one another and to use functionality of one another [CHE 08a]. The word “inter-operate” implies that one system performs an operation for another system. Precisely, “it is the ability of information systems, and the business processes they support, to exchange data and enable sharing of information” [PAP 03].

The interoperability of an ERP system is its ability to interact with other subsystems (applications, legacy systems, ERP systems, etc.) within the whole of the IS. The interoperability allows us to evaluate the ERP software suitability, which could be evaluated by the integration possibilities of an ERP system whose software is already in use. This kind of opinion is held by Everdingen et al., Sprott, Kumar et al., Verville and Halingten, Fisher and Kiang, Bueno and Salmeron and Ratkevičius et al. [EVE 00, SPR 00, KUM 02, KUM 03, VER 03, FIS 04, BUE 08, RAT 12]. For the purpose of our research, we are not interested in the native interoperability between the modules of an ERP system that should be reliable according to ERP’s founding principles and definition. We are interested rather in the interoperability between the ERP system and other subsystems within the whole IS.

Today, there are different technologies that lead to the improvement of the interoperability within an IS. Interfaces for commercial software applications or legacy systems within an ERP suite may need to be developed in-house if they are not available in the market [BIN 99]. New integration technology such as software componentization, enterprise application integration (EAI), service-oriented architecture (SOA) and Web Services are introduced and their implications are discussed [MOO 07]. In spite of this need for coexistence between the subsystems, ERP packages are not designed to be incorporated into existing systems [SCH 00]. A survey from 2009 remarks that eight of 10 users cite a significant need for improvement in interoperability [MCG 09]. As a result, for the purpose of our research, we suggest two types of ERP interoperability: reliable or unreliable.

Should improving interoperability be a criterion to be taken into account by all stakeholders within the framework of an ERP system’s evolution? If so, would the IS integration be improved? If not, would its disintegration be initiated?

Logically, a reliable interoperability can promote the integration of different subsystems within the IS (e.g. an incomplete ERP 2nd G, which does not contain all modules but whose interoperability is reliable, could be easily interfaced with a part of the legacy systems. As a result, there is good communication between the modules of this package and the rest of the architecture. In this case, the IS would be more or less integrated [HIIS]); while, an unreliable interoperability leads to a kind of disintegration between the different subsystems (e.g. an ERP 1st G, whose interoperability is unreliable, which could not be interfaced with other applications within the IS. As a result, there is no communication between the modules of this package and the rest of the architecture. In this case, the IS would rather be disintegrated [DIS]). Consequently, we propose the “INTEroperability of the ERP (INTE)” as a factor that could guide and impact the relationship between the ERP system’s evolution and IS integration or disintegration.

Based on an exploration of the literature, as well as a logical analysis and the rating schema suggested in our research methodology, we assign this factor two different values (one positive and another negative): reliable interoperability of the ERP “INTE+” or unreliable interoperability of the ERP “INTE-”. As an ERP is a factor favoring IS integration, we think that an “INTE+” could promote an HIIS, while an “INTE-” could encourage a DIS. Contradictorily, we think that an “INTE-” could sometimes lead to a TIIS (e.g. because of the lack of the ERP system’s interoperability, the firm avoids interfacing any other subsystem with the ERP system to implement. In this case, the IS would consist only of this ERP system, and a total overhaul of the existing system would be necessary. This idea will be explained in the next section).

4.5. Evolution strategy of existing systems (ESES)

The evolution strategy of existing systems (IT strategy) is managed by firms to implement an information system that serves their business process in the short term and their corporate strategies in the long term. It represents the business vision and IT strategies, as expressed in business strategies and visions. The target must be able to serve the strategy and business process within an IS that is aligned with corporate strategy.

When the ESES is based on ERP implementation, it aims to evaluate the fit of the ERP system in relation to the underlying business strategy. The state of the existing system could determine a firm’s ESES. ERP implementation involves a complex transition from legacy IS and business processes to an integrated IT infrastructure and common business processes throughout the organization [GIB 99]. Verville and Harlington emphasize the compatibility between an ERP implementation and the existing system: “is the organization’s existing DBMS compatible with the proposed solution and can the proposed solution integrate into the organization’s existing hardware architecture” [VER 03].

One of the main functions of an ESES is auditing the state of the existing system, which helps to set the objectives and strategy of the target. In order to reach this target and to evolve the existing systems, firms can principally chose one of two different strategies: urbanization or total overhaul.

4.5.1. Urbanization

The model of information system development has changed since the mid-1990s, with a move toward so-called urbanization, where systems are constructed from existing applications and new systems [HOP 08]. This strategy is based on modernizing and judiciously profiting from technological advances without erasing the past while continuing business operations while the work is carried out [LON 09]. Urbanization is the implementation of an ERP system without erasing all of the legacy systems (e.g. a functional part of legacy systems would within the IS would remain intact). The integration of the subsystems is one of the founding principles of the urbanization according to its definition.

Urbanization, which is a French framework of enterprise architecture (EA), is a process that makes an IS more suitable for serving the corporate strategy and anticipating changes in business environment [CIG 03]. The concept involves reconstructing the IS based on permanent components. It consists of moving from an existing IT system to a target one by successive stepwise stages, whereas a total overhaul is considered a more radical approach. Some firms, such as Air France KLM, Renault and BNP Paribas, have found urbanization to be an advantageous approach [TRA 13].

Consequently, urbanization consists of evolving the IS by keeping the part of the existing IS that is functional and operational. For example: urbanizing by expanding the IS’s perimeter from an ERP 1st G to an ERP 2nd G. This kind of urbanization could lead to a TIIS when both packages (ERP 1st G and ERP 2nd G) are bought from the same vendor; the urbanization is managed by adding and interfacing other third-party subsystems (applications and/or software packages) to an ERP 1st G. This kind of urbanization could lead to an HIIS instead, especially when the subsystems (Best of Breed or not) are sold by many software vendors.

4.5.2. Total overhaul

A whole replacement of all legacy systems with another at one time is termed in France a “Total Overhaul”, which involves making a clean sweep in order to completely replace the existing system by a new IS. For example, old applications developed in-house are completely replaced by an ERP 2nd G or by many interfaced subsystems (ERP systems and/or others).

The choice of a given strategy (total overhaul or urbanization) depends on the state of the existing system (extremely complex, complex or simple). “If an organization’s legacy systems are extremely complex, with multiple technology platforms and a variety of procedures to manage common business processes, then the amount of technical and organizational change required is high. Otherwise, if the organization already has a simple technical architecture, change requirements are low” [HOL 99].

Generally, firms prefer urbanization over total overhaul, which is costly, time-consuming and difficult to achieve. Unfortunately, many organizations have faced a challenge with systems integration related to the complexity of existing systems, which in many cases have fixed and rigid structures for messages, interfaces and databases [THE 02]. As a result, a total overhaul sometimes may be indispensable, especially when the existing system is very complex.

Yang et al. [YAN 07] have mentioned the importance of the compatibility and adaptability of an ERP system with existing systems (employed system technologies, embedded database system, system development tool and language). When compatibility and adaptability are completely absent, the only remaining option when selecting an ERP system is to adopt a total overhaul, because urbanization would be very difficult to manage and a favorable result would be much less likely. The more complex the existing system is, the more difficult the urbanization is; the simpler the existing system, the easier it would be to avoid a total overhaul in favor of urbanization.

Should the firm’s evolution strategy of existing systems be a criterion to be taken into account by all stakeholders within the framework of the ERP system’s evolution? If so, would IS integration be improved? If not, would its disintegration be provoked?

Logically, a total overhaul could improve IS integration, especially where the legacy systems are extremely complex (e.g. the implementation of an ERP 2nd G, by a total overhaul, could lead to a “TIIS”; likewise, a total overhaul leading to an ERP 1st G that is well interfaced with many “BoB” applications could lead to an HIIS). However, urbanization performed on a simple or sometimes on a complex existing system could lead to an “HIIS” or a “DIS” instead of a “TIIS” (e.g. an urbanization performed on a simple existing system that leads to an ERP system that is well integrated with the existing system promotes an “HIIS”; while urbanization executed on a complex existing system that leads to an ERP system that is not at all integrated with the existing systems could lead to a DIS instead). The only case for which urbanization could lead to a TIIS is when the firm migrates an ERP 1st G to an ERP 2nd G that was bought from the same vendor.

As a result, we propose the “Evolution Strategy of Existing Systems (ESES)” as a factor that could guide and impact the relationship between the ERP system’s evolution and IS integration or disintegration. Based on an exploration of the literature, as well as a logical analysis and the rating schema suggested in our research methodology, we assign this factor two different values (one positive and another negative): a total overhaul performed, especially, on an extremely complex existing system would be positive “ESES+”, while urbanization performed on a simple or a complex existing system would be negative “ESES–”. We think that an “ESES+” could promote a TIIS or an HIIS, while an “ESES–” could lead to an HIIS or a DIS more than a TIIS, which can happen in only one scenario (i.e. urbanization from an ERP 1st G to an ERP 2nd G bought from the same vendor).

4.6. Complexity of ERP (COER)

Different approaches for measuring software complexity are discussed in the related literature. Very often, ERP system buyers focus on ERP system price and its functionality without considering the IT skills of future users [RAT 12]. Ease of use is often an undervalued ERP system selection criterion according to Pivnicny and Carmody, Everdingen, Verville and Halingten, Yang et al., and Bueno and Salmeron [PIV 89, EVE 00, VER 03, YAN 07, BUE 08]. Wei et al. define it as a measure of the simplicity of training and use [WEI 05]. Keil and Tiwana treat this criterion as the possibility for using the software intuitively, without additional specific knowledge [KEI 06]. An ERP system requires the collaboration and understanding of people across the entire organization. After implementation of a complex ERP, demotivated users may avoid using it and try to replace some functions of the software package by other tools. This behavior, which can be related to a lack of training and experience, does not encourage an integrated way of working.

ERP implementation is a lengthy and complex process [PAR 00]. It is generally accepted that ERP systems are complex systems involving not only technical aspects but also business processes. ERP systems have frequently been criticized for being rigid, massive and consequently hard to implement and control [CIB 00, HAN 01]. The selection of an ERP system is a difficult and long-term process; an organization must choose a supplier capable of providing a flexible ERP system [SPR 00, EVE 00, SHE 04, WEI 04].

Uflacker and Busse mentioned the difficulty of performing a desired business task using SAP [UFL 07]. They used the term “front-end complexity” to qualify the underlying program, and “back-end complexity” to mean the difficulty of use as perceived by the end user: the flexible and holistic approach of SAP R/3 introduces a considerable amount of functional complexity into the “Sales and Distribution module SD” (the authors illustrate enterprise application complexity by analyzing sales order management and order variations in SAP). “So is SAP complicated? Of course it is,” said Christian Hestermann, an analyst at Gartner [ROB 11].

Should simplifying the complexity be a criterion to be taken into account by all stakeholders within the framework of ERP system’s evolution? If so, would IS integration be improved? If not, would its disintegration be possible?

When a complex ERP system is selected and implemented by firms, the IS integration may be compromised (e.g. a complex ERP system would be difficult to use or may be used incorrectly in a manner that spreads incorrect data within the IS, thereby rendering the integration useless or devoid of any added value). However, when a simple ERP system (as opposed to a complex one) is adopted by firms, IS integration could be improved (e.g. a simple ERP system could be used easily and correctly in a manner that spreads accurate data within the IS, thereby leading to a useful integration).

As a result, we propose “COmplexity of ERP (COER)” as a factor that could guide and impact the relationship between the ERP system’s evolution and IS integration or disintegration. Based on an exploration of the literature, as well as a logical analysis and the rating schema suggested in our research methodology, we assign this factor two different values (one positive and another negative): simple ERP system would be positive “COER+” vs. a complex ERP system, which would be negative “COER–”. We think that a “COER+” could promote a TIIS as well as an HIIS, while a “COER–” could lead to a DIS instead.

4.7. Evolution strategy of ERP vendors (ESEV)

ERP packages do not seem to be able to “cover all the business processes of an enterprise” [SCH 00]. “To best meet business needs, companies may integrate other specialized software products with the ERP suite” [BIN 99]. Functional match is a measure of the strength and capability of the ERP system to meet the business requirements of the firm [LAL 06]. A major problem with the existing ERP systems is the misfit between the delivered functionality from the vendor and the needed functionality in the receiving end-customer organization. This has led to an increasing interest among vendors to improve future ERP systems to support the end-customer organization even better [JOH 07].

Vendors are required to demonstrate how their ERP systems meet the functionalities identified by the company. Firms that have already implemented ERP systems and are relatively satisfied with their operations are now considering the extension of the functionalities provided by the original ERP systems. Some companies implement ERP systems even though their ultimate objectives lie in further extended systems. Others implement ERP systems with some plans to extend later. Consequently, enlarging the ERP system’s perimeter (scope) from 1st G toward 2nd G, which takes into account new modules such as business intelligence (BI), CRM, SCM, etc., could fit better with the new users’ needs and improve IS integration.

ERP package functionalities are one of the most important software-related ERP system selection criteria. It could be evaluated by taking into account the standard functional power and its suitability to company needs. This factor was mentioned in the research papers of Everdingen et al., Siriginidi, Chen, Kumar et al., Wei et al., Keil and Tiwana, Liao et al. and others [EVE 00, SIR 00a, CHE 01, KUM 02, KUM 03, WEI 05, KEI 06, LIA 07]. Anderson and Chen treat ERP system functionality as the main ERP system selection criterion [AND 97]. Heck presents a similar opinion, affirming that this criterion must comprise up to one-third of the final score used for making the ERP system selection decision [HEC 97].

In Kumar’s survey of Canadian companies, functionality has been the most often quoted and the most important ERP system selection factor to consider, mentioned in 79% of the cases [KUM 03]. Han has analyzed ERP system functionality as a unique and as the main significant ERP system selection criterion, separating three levels of system functionality [HAN 04]. The first one includes the basic system functionality and the third level provides an additional ERP functionality that extends the limits of collected and processed information (for example, ensuring real-time communication between customers and suppliers). ERP functionality could be used as a reference point to prioritize the performed functions as one of the principal ERP system selection strategies [RAT 12].

Researchers also investigate the importance of ERP system vendor reputation. This criterion has been cited in the research papers of Kumar et al., Verville and Halingten, Wei et al., Lall and Teyarachakul, and Liao et al. [KUM 02, KUM 03, VER 03, WEI 05, LAL 06, LIA 07]. The vendor reputation, technical capabilities and provision of ongoing services need to be considered in the ERP system vendor selection process.

Vendor reputation is defined as one of the most important non-technical ERP selection criteria [BRO 81, CHA 95]. Goldenberg et al. and Pivnicny and Carmody treat vendor reputation as the only factor that requires consideration [GOL 91, PIV 89]. Bernroider and Koch have indicated that this factor is more significant for large than for small- or mid-sized companies [BER 01]. A definition of ERP system vendor reputation has been introduced by Verveille and Hallinten [VER 03], and it highlights vendor recognition, as well as technological and strategic vision.

A long-lasting perspective of ERP system vendor existence is also an important ERP system selection criterion. Many researchers and practitioners hold the opinion that a long-lasting perspective of ERP system vendor existence is the prerequisite to ensuring and developing the actual ERP system functionality from the perspective of new business trends.

Rao identified some ERP system selection criteria for Indian small- and medium-sized enterprises (SMEs): domain knowledge suppliers, uses latest technology and upgrade ability, which characterizes the ability of the ERP system vendor to upgrade the current ERP system to a newer version [RAO 00]. The importance of the upgrade ability is also mentioned by Sprott, Kumar et al., and Bueno and Salmeron [SPR 00, KUM 02, KUM 03, BUE 08]. Vendor profile is an attribute based on prompt availability of software upgrades and technical support [LAL 06].

Advanced technology of ERP system vendors is also an important but not crucial ERP system selection criterion. This factor is described in detail by Rao and Kumar et al. [RAO 00, KUM 02, KUM 03]. When selecting an ERP system by this criterion, the ERP system’s technological architecture, its structure, database, programming platform administration possibilities, workflows, document management and report generation tools are evaluated.

To summarize, Liao et al. [LIA 07] provide four ERP system selection criteria: function and technology, strategic fitness, vendor ability and vendor reputation. All these criteria could be taken into account to define the research factor “Evolution Strategy of ERP Vendors from 1st to 2nd G (ESEV),” as also shown in Table 4.1.

The observation of the ERP system vendors’ market allows us to define three main strategies:

  1. 1) to stop an activity at the level of ERP 1st G because the vendor is bought out by another ERP system vendor (e.g. PeopleSoft and J.D. Edwards);
  2. 2) to maintain the perimeter at the level “1st G” without any expansion toward an ERP 2nd G;
  3. 3) to extend the ERP 1st G’s perimeter by adding new modules, by internal development (e.g. SAP) or by acquisition of other ERP system vendors (e.g. Oracle).

“In 1998 there were five major software vendors offering ERP solutions to businesses worldwide. The largest of these was SAP AG. The Oracle Corp. was the second, followed in third place by PeopleSoft. In fourth place was J.D. Edwards. Finally in fifth place was the Baan Co” [HOL 99]. Today, this situation has changed because PeopleSoft and J.D. Edwards, considered ERP 1st G, have stopped their activities due to being purchased by Oracle. This “Stopping Business” strategy can impact the IS because some firms still keep PeopleSoft and/or J.D. Edwards as a subset within their architectures.

Oracle has preferred an external acquisition strategy, rather than internal development, to obtain indispensable know-how to evolve and optimize certain modules in its ERP 2nd G. “This logic of buyout is to take ownership of another vendor for its expertise in a particular module” [PRA 08]. It seems that an external acquisition strategy does not allow a vendor to develop its ERP 2nd G on the founding principles of a total integration “TIIS”, as shown in Table 1.1.

It also seems that it is very difficult for one vendor to have all the necessary knowledge and competencies in all modules of an ERP 2nd G. This could mean that there is a doubt about the reliability of an ERP 2nd G sold by a vendor that adopted an internal development strategy to optimize its software package. As a result, this book does not aim to judge which ERP system is more reliable than another (obtained by internal development or external acquisition). Instead, it focuses on the integration rate that – in our belief – is not the only element that determines the reliability of an IS.

Consequently, when an internal development strategy is adopted by an ERP system vendor, the integration rate of the IS would be improved (e.g. the implementation of an ERP 2nd G SAP could lead to a “TIIS” especially when the whole architecture consists only of SAP modules); while, when an external acquisition strategy is utilized by an ERP system vendor, the IS would be more or less integrated (e.g. the implementation of an Oracle ERP 2nd G could lead to an “HIIS”).

However, if the ERP system evolution is stopped at the level of ERP 1st G (the vendor is bought out by another ERP vendor; or perhaps the ERP system evolution is maintained at the level “1st G” without any expansion toward an ERP 2nd G), an IS disintegration could result (e.g. the perimeter of an IS that consists only of an ERP PeopleSoft 1st G is enlarged to an IS that now consists of an ERP PeopleSoft 1st G with some other applications such as CRM, SCM, etc.). In this example, the reliability of the IS integration could depend on the integration rate within the IS:

  1. – an unreliable integration between all these subsystems could lead to a kind of strong disintegration from a “TIIS” (when the IS in the past consisted only of PeopleSoft 1st G) to a “DIS” (if the other applications have not recently been integrated with PeopleSoft 1st G);
  2. – while a reliable integration between all these subsystems could encourage a kind of weak disintegration from a “TIIS” (when the IS in the past consisted only of PeopleSoft 1st G) to an “HIIS” (if the other applications have recently been well integrated with PeopleSoft 1st G).

Should the evolution strategy of ERP system vendors from 1st to 2nd G be a criterion to be taken into account by all stakeholders within the framework of an ERP system’s evolution? If so, would the IS integration be improved? If not, would it result in disintegration?

We propose the “Evolution Strategy of ERP Vendors from 1st to 2nd G (ESEV)” as a factor that could guide and impact the relationship between the ERP system’s evolution and IS integration or disintegration.

Based on an exploration of the literature review, as well as a logical analysis and the rating schema suggested in our research methodology, we assign this factor two different values (one positive and another negative): evolution to an ERP 2nd G by internal development or external acquisition would be positive “ESEV+,” while keeping an ERP 1st G without any expansion toward a 2nd G or by the vendor going out of business would be negative “ESEV–”. We can also distinguish two degrees within the framework of the positive value “ESEV+”:

  1. – a high positive value could be attributed when the expansion strategy to an ERP 2nd G is achieved by internal development;
  2. – a low positive value could be given when the expansion strategy used to transition to an ERP 2nd G was external acquisition.

As an ERP is a factor favoring IS integration, we think that an “ESEV+” could promote a TIIS, or an HIIS, while an “ESEV-” could cause a disintegration toward an HIIS or even toward a DIS.

This chapter highlighted the seven research factors that we determined affect the relationships between the ERP system’s evolution and IS integration or disintegration. Each of these factors is a variable that could be defined by two different values (+ or -). Each of these two values could differently affect the IS evolution (integration or disintegration). We have evaluated the research factors according to the definitions below.

Table 4.2. Measurement of the research factors affecting the relationships between the ERP system’s evolution and IS integration or disintegration

Research’s factors Values Evaluations (ratings)
Economic crisis and competitiveness ECCO + Competitiveness would be improved due to an ERP (a positive arbitration of ROI)
ECCO - Competitiveness could not be improved due to an ERP (a negative arbitration of ROI)
Total dependency on the ERP vendor TDEV + Total dependency on the ERP vendor
TDEV - Independence from the ERP vendor
Project management ERP PMER + Reliable ERP project management
PMER - Unreliable ERP project management
INTEroperability of the ERP INTE + Reliable interoperability of the ERP
INTE - Unreliable interoperability of the ERP
Evolution strategy of existing systems ESES + Total overhaul performed, especially, on extremely complex existing
ESES - Urbanization performed on a simple or a complex existing
COmplexity of ERP COER + Simple ERP
COER - Complex ERP
Evolution strategy of ERP vendors ESEV + Evolution to an ERP 2nd G by an internal development or by an external acquisition
ESEV - Keeping an ERP 1st G without any expansion toward a 2nd G or by the vendor going out of business