Abstract
Purpose
In the last years the penetration of enterprise resource planning (ERP) systems within small, medium and large organizations increased steadily. Organizations are forced to adapt their systems and perform ERP upgrades in order to react to rapidly changing business environments, technological enhancements and rising pressure of competition. The purpose of this paper is to focus on the critical success factors for such projects.
Design/methodology/approach
The paper is based on a literature review and qualitative interviews with CEOs, CIOs, ERP consultants and project managers who recently carried out ERP upgrade projects in their respective organizations.
Findings
This paper identifies 14 critical success factors for ERP upgrade projects. Amongst others, effective project management, external support, the composition of the ERP team and the usage of a multiple system landscape play a key role for the success of the ERP upgrade. Furthermore, a comparison to the critical success factors for ERP implementation projects was conducted, and even though there are many similarities between these types of projects, several differences emerged.
Originality/value
ERP upgrade projects have a huge impact on organizations, but their success and antecedents for it are currently under-researched.
Keywords
Citation
Barth, C. and Koch, S. (2019), "Critical success factors in ERP upgrade projects", Industrial Management & Data Systems, Vol. 119 No. 3, pp. 656-675. https://doi.org/10.1108/IMDS-01-2018-0016
Publisher
:Emerald Publishing Limited
Copyright © 2019, Christian Barth and Stefan Koch
License
Published by Emerald Publishing Limited. This article is published under the Creative Commons Attribution (CC BY 4.0) licence. Anyone may reproduce, distribute, translate and create derivative works of this article (for both commercial and non-commercial purposes), subject to full attribution to the original publication and authors. The full terms of this licence may be seen at http://creativecommons.org/licences/by/4.0/legalcode
Introduction
For decades, many large companies have implemented enterprise information systems, also termed enterprise resource planning (ERP) systems (Davenport et al., 2004), including an increasing number of SMEs (Olson and Staleya, 2012). In the literature, repeatedly the high percentage of failed ERP projects is discussed (Davenport, 1998; Beatty and Williams, 2006; Ahmad and Cuenca, 2013). Emphasis in research has been on the earlier phases in the life cycle of ERP systems, particularly the implementation, for example by Holland and Light (1999), Aloini et al. (2007), but also decision-making, for example by Bernroider and Koch (2001), Stefanou (2001), Hakim and Hakim (2010). Evolution, maintenance and eventual replacement of such systems (Gable et al., 2001) has received considerably less attention, with some exceptions (e.g. Koch and Mitteregger, 2016; Ng et al., 2003; Nah, Faja and Cata, 2001; Salmeron and Lopez, 2010; Law et al., 2010; Haddara and Elragal, 2013). Related issues will be of increasing relevance and importance in the next years for practice though (Botta-Genoulaz et al., 2005; Salmeron and Lopez, 2010; Law et al., 2010), as in times of rapidly changing business environments and newly emerging technologies, companies are not only forced to adapt their business models, their strategy and their organizational structures but also their information systems. This area is growing in publication activity, the proportion of publications in 2000 was 11 percent and has grown to already 30 percent in 2009 (Schlichter and Kraemmergard, 2010). A research agenda for this field spanning over 80 topics was already proposed by Gable et al. (2001).
One possibility to adapt an existing ERP system to changing demands is to upgrade the system to a new version, which constitutes one of the major activities within the post-implementation phase (Nah, Faja and Cata, 2001). Typically, every three years organizations have to conduct a major ERP upgrade and several small upgrades to guarantee a smoothly running system (Olson and Zhao, 2006). Due to the high complexity of ERP systems, upgrades can only be conducted within comprehensive projects and require significant personal and financial resources as well as a high degree of ERP know-how. Because of the large amount of money spent on ERP upgrades, which can add up to 25–33 percent of the initial implementation costs for one upgrade (Ohlson, 2000), a comprehensive understanding of ERP upgrade concepts and their challenges is necessary to prevent project failures (Olson and Zhao, 2006). The current change in the market leader’s platform to SAP HANA and associated to the SAP S/4HANA ERP software makes this issue very relevant for industrial practice. Therefore, the objective of this paper is to identify the main factors which lead to success within ERP upgrade projects. We will especially focus on the following research questions:
What are the objectives in ERP upgrade projects?
What are the factors which enable an organization to reach these objectives and therefore can be defined as critical success factors?
Whether any differences between critical success factors in ERP upgrade projects and those in ERP implementation projects exist and what they are.
This paper is structured as follows: after the introduction, a literature review on ERP implementation and upgrade is provided for an understanding of both types of projects, and critical success factors for implementation projects. We will then detail the research methodology which follows a qualitative approach to uncover critical success factors for upgrade projects and differences to implementations. The next sections describe the data analysis, followed by a discussion, conclusion and directions for future research.
Literature review
ERP implementation projects
ERP systems are large packaged enterprise information systems that consist of several integrated subsystems, enabling planning and control of resources and processes of an enterprise (Davenport, 1998). They facilitate a unified data source for all activities within an organization and therefore represent the information backbone of a company. This leads to a considerable improvement of the organization’s decision-making process, and contributes to making it consistent, timely and reliable across organizational units and geographical locations (Chatzoglou et al., 2016).
After the decision for deployment of an ERP software, the next steps and phases can be classified and ordered based on a life cycle model (e.g. Stefanou, 2001). Markus and Tanis (2000) describe the lifecycle of an ERP system on the basis of four phases. The first phase, called the chartering phase, consists of actions in order to define the business case and solution constraints, and select the software. In the second phase, the project phase, the selected and defined system is set up, configured according to the organizational needs and rolled out to more and more end users (Markus and Tanis, 2000). With the beginning of the third phase, the shakedown phase, the system will be stabilized, bugs will be eliminated and the system will get to normal operations. The last phase, the onward and upward phase, covers all maintenance, support and upgrade activities (Markus and Tanis, 2000). Esteves and Pastor (1999) distinguish between adoption decision phase, acquisition phase, implementation phase, use and maintenance phase, evolution phase and retirement phase.
The main focus in the literature so far has been on implementation (Botta-Genoulaz et al., 2005; Salmeron and Lopez, 2010; Law et al., 2010; Schlichter and Kraemmergard, 2010), mostly project management and the extent of customization. The implementation of an ERP system is a highly challenging, complex and dynamic process which does not only trigger technological but also organizational changes in the affected organization (Otieno, 2010). These changes need to be carefully administered in order to be able to take advantage of an ERP solution (Al-Mashari and Al-Mudimigh, 2003). Although there is a generally shared knowledge concerning these challenges, ERP implementation failures still happen frequently (Soh et al., 2000; Hillman Willis and Willis-Brown, 2002; Barker and Frolick, 2003). Nah, Lau and Kuang (2001), Dezdar and Sulaiman (2009) and Finney and Corbett (2007) surveyed existing literature about ERP implementation success factors and ranked them according to occurrences within the analyzed articles. Results showed that the main critical success factors identified are overlapping with only few differences between the articles.
One of the most cited critical factors is top management commitment and support (Sumner, 2000; Bingi et al., 1999), which is especially critical in the early stages (Finney and Corbett, 2007). Along with that, change management is the most cited critical success factor (Finney and Corbett, 2007), in order to ensure user acceptance (Somers and Nelson, 2004) and reduce resistance (Wagner and Newell, 2004), confusion, redundancies and errors due to significant changes (Sumner, 2000). In order to succeed, a culture with common goals, shared values and a strong corporate identity open to change, is essential (Nah, Lau and Kuang, 2001), as well as communication of the benefits and the need for an ERP system (Finney and Corbett, 2007).
Good project management including a detailed project plan related to the project goals, milestones and critical paths (Holland and Light, 1999) and establishment of necessary roles (Somers and Nelson, 2004) is fundamental to secure implementation success (Nah et al., 2003).
When implementing an ERP solution, especially worldwide (Bingi et al., 1999), companies always face the challenge of bringing their business processes in line with the new ERP package. The possibility for customizing the software, i.e. modification of the software to match the organization’s existing business processes (Rothenberger and Srite, 2009), is a central requirement for an ERP system. Many guidelines for implementation, such as Accelerated SAP, contain the advice to perform an implementation without major customization. In practice, however, the majority of implementations include extensive customizing and adaptation measures, Davenport et al. (2004) report in a study that 74 percent of surveyed firms have adjusted their ERP system at least to a moderate degree, but only 40 percent of companies have achieved a significant optimization of their systems. Therefore, existing business processes have to be analyzed and adapted to the system, rather than to customize a system which makes the best of bad processes (Scheer and Habermann, 2000; Sumner, 2000). Code modification or far reaching customization of the ERP system should be avoided as far as possible to avoid complications with updates and upgrades (Nah, Lau and Kuang, 2001).
Additional critical success factors are the selection of a project champion, who has the power and reputation to promote the importance of the project (Sumner, 2000), and cultural change management, also because major ERP vendors are located in North America and Western Europe, and thus functionalities and processes embody a western-centered perspective. It is essential to adapt processes and services for different cultural conditions (Davison, 2002). It is furthermore crucial that expectations and goals are communicated effectively among stakeholders and throughout all levels of an organization, including capabilities as well as limitations of the system (Nah and Delgado, 2006), also to prevent frustration due to “over-selling” (Somers and Nelson, 2004). Additionally, good communication of the project’s progress to the rest of the organization is an easy way to promote and advertise the project and project team (Holland and Light, 1999). The project manager has to have the ability to communicate relevant information appropriately to different stakeholders, and also within the project team to ensure coordination (Kræmmergaard and Rose, 2002).
The appropriate management of IT legacy systems is a key success factor, whether it is replacement or development of interfaces (Lee et al., 2003). A strategic partnership with the software vendor enables using implementation tools such as process modeling, templates for specific business practices or packages of software, services and support, as well as best-practices (Somers and Nelson, 2004). This is also related to the critical success factor of ERP package selection. According to a large-scale European multi-country survey the most important factor is the best fit with current business processes, respectively, organization (Hong and Kim, 2002; Ngai et al., 2008), followed by flexibility, cost, user-friendliness, scalability and vendor support (van Everdingen et al., 2000). Finally, at the end of any ERP implementation project, it is necessary to evaluate its success, focusing on measurable project management metrics like completion dates, costs and target achievement, and the production system, including metrics like performance or reliability (Nah, Lau and Kuang, 2001; Ross and Vitale, 2000).
ERP upgrades
After the implementation, the ERP system is eventually transferred to the phase of operation and maintenance. Software maintenance is generally understood as all changes to an existing software system after it is already operational, often distinguishing between corrective maintenance, adaptive maintenance and product care (Abran and Nguyenkim, 1993). The authors note that major upgrades or program changes should be treated as development. In the context of ERP systems some differences to traditional software maintenance exist (Ng et al., 2002). For ERP, maintenance activities can be categorized into user support, troubleshooting, function changes and enhancements, functional tasks during release changes, technical tasks during release changes and technical maintenance of the ERP system (Brehm, 2004). Nah, Faja and Cata (2001) add communication with external partners and user support as key points based on an empirical study. Hirt and Swanson (2001) show that the distribution of roles in the maintenance of ERP systems is unlike typical software maintenance. Especially the cooperation with the vendor is an essential point not covered in the required form in maintenance standards (Ng et al., 2003). Salmeron and Lopez (2010) develop a taxonomy of risk factors for ERP maintenance, which they clearly distinguish from an upgrade, as do Peng and Nunes (2009). Somers and Nelson (2004) showed that the importance of individual actors and activities within the company over the life cycle of an ERP system is not constant, for example a steering committee and change management lose importance in the later phases. Chen et al. (2009) name maintenance and support as essential elements in the management of ERP systems, and show that the establishment of appropriate governance structures is necessary, also because costs for maintenance can come up to annually about 25 percent of implementation costs (Granebring and Revay, 2005). Law et al. (2010) additionally emphasize that maintenance and support constitute a significant success factor for ERP projects, together with the implementation itself. Therefore, these phases need to be considered in the implementation itself, since the implementation can affect maintenance and support. This is also emphasized by Koch and Mitteregger (2016), who have shown that amount of customization during implementation affects support costs in maintenance, similar to Light (2001).
Little relevant literature exists that clearly defines ERP upgrades as part of maintenance. Sahin and Zahedi (2001) provide a general definition of an upgrade of a software system, and define upgrade as “adding new functions or features to a software system, in addition to any maintenance and fault removal. An upgrade action involves new programs and constitutes an overhaul of the system.” Scheckenbach et al. (2014) describe ERP upgrades as “mainly intended to take advantages of new technologies and business strategies to ensure that the organization keeps up with the latest business development trends.” Therefore, in this paper an ERP upgrade is understood as a major change process resulting from the implementation of a new version of an already installed ERP system, whose main intent is to add functional upgrades, respectively, enable the usage of new technologies and business strategies. The term excludes minor changes within a version of an ERP system, such as new releases that only provide technical upgrades, for example patches and bug fixes.
Upgrade activities are getting more attention in ERP-using organizations, especially as on average an organization has to execute an ERP upgrade every three years (Olson and Zhao, 2006), and costs reach between 25 and 33 percent of initial implementation costs. As an ERP system has to be upgraded several times during its life cycle, the upgrading costs will exceed the implementation costs eventually. Additionally, many companies and organizations have no experience and expertise in this area, as there exist hardly any standards or guidelines for ERP upgrade preparation and execution (Ng et al., 2003).
The decision whether to upgrade a system or not is guided by both internal and external pressures. Beatty and Williams (2006) describe these pressures as organizational push and vendor pull. Organizational push refers to the situation that executives are motivated to further expand and improve their ERP system as their organizations realize business benefits from their initial investments. Also, vendors are urging organizations to upgrade their systems, as they have to enhance their systems in order to remain competitive, and cannot afford to offer support for numerous versions. As guidelines for such a project, the authors provide in addition to a focus on added value rather than cost reduction, most importantly de-individualization. 80 percent of the programmers time and 66 percent of the analysts’ time is due to individualization, so that a careful evaluation is necessary before an upgrade.
The main benefits organizations are trying to gain when they upgrade their ERP systems are continued eligibility for help desk support (Collins, 1999; Otieno, 2010), to take advantage of new technologies (Dempsey and Liam Sheehan, 2013) to stay competitive, to enable new, expanded or improved features to meet business and IT needs (Collins, 1999; Otieno, 2010), and finally to reduce costs of maintenance which tend to become higher the longer an ERP version is deployed (Ng, 2001). Nicolaou (2004) also emphasizes the role of post-implementation reviews for the successful generation of added value through an ERP implementation, particularly in connection with upgrades and enhancements, as do Häkkinen and Hilmola (2008). The author indicates that in the cases considered initially only 50–75 percent of the necessary technology was included. Kremers and van Dissel (2000) focus on migrations, which they understand as major change processes caused by installing a new version, analyzing both customer and supplier perspective. The main arguments from the vendor perspective are intensification of customer lock-in and enabling support at lower cost due to a lower number of active versions, in addition to revenue effects. From a customer perspective, mainly technical reasons, as well as new functions are cited, while cost and time requirements are the most significant obstacles. The authors conclude that the timing of a migration is a source of competitive advantage, as other opportunities for differentiation are no longer possible due to the implementation of an ERP system. Finally, upgrades can also impact the user acceptance (Shaw, 2001).
The upgrade procedure itself is critical to the overall success of the ERP upgrade activity. Ng et al. (2003) have developed an ERP maintenance model, which consists of three major phases, maintenance preparation, maintenance procedure and software upgrade. The respective ERP software upgrade phase consists of 11 sub-phases, namely design of an upgrade project methodology, research of upgrade options, develop a business case, full assessment of modifications in the current version and technical environment, full assessments of the new functionality and technical requirements in each (potential) upgrade option, impact analysis between the new upgrade version and the existing version, install the new version onto the development system, construct the new system, thorough testing of the upgrade system, trial upgrades, and conversion or go live.
Methodology and data collection
The first step in addressing the research questions involved a comprehensive literature search conducted on various databases, such as ACM digital library, Wiley online library, SpringerLink, Emerald, ScienceDirect, IEEE Xplore and Google Scholar. The focal topics were ERP implementations and their critical success factors, ERP maintenance and especially upgrades, and any insights on respective projects and their management. The findings were summarized into the literature review presented above, and informed the next step in the research. As discussed, a limited amount of research has focused on ERP upgrade projects so far. Therefore, qualitative research has been deemed appropriate to investigate the research questions. The specific characteristic of qualitative research is the openness regarding the research subject, which enables the possibility of gaining new findings and closing knowledge gaps (Patton, 1990). It also allows to look into the environment of people and use it as a basis to describe and interpret reality from their view.
In this study expert interviews with knowledgeable representatives including CEOs, CIOs, ERP consultants and IT project managers were used. The expert interviews were conducted as problem-centered interviews, a form of open, semi-structured interviews (Mayring, 2000). This form has been chosen as it allows the interviewee to speak as freely as possible and enable a nearly open conversation, though the focus of the conversation is put on specific topics and problems. The main topics have already been analyzed and summarized within an interview guideline, and during the conversation these are addressed (Mayring, 2000). This kind of interview is specifically applicable for theory-based research approaches, as it is not solely exploratory but is rather based on aspects of prior research (Mayring, 2000; Gläser and Laudel, 2013). The second important factor is the standardization of the interviews, as the same interview guideline is used for each interview, which allows an easy comparison (Mayring, 2000).
All experts participated entirely voluntarily and were informed about the purpose and nature of the study. All were interviewed anonymously and the data collected were used strictly for the purpose of this paper. In total 12 persons, 11 men and 1 woman, were interviewed. The interviews were conducted either in person, via internet or mobile telephony, and were recorded with the approval of the participants. One single interview was conducted in written form. All of the recorded interviews were transcribed in order to make them usable for further analysis. The study was conducted in organizations in Austria which have experience with ERP upgrades. Every interviewee was either an ERP consultant or an executive IT manager strongly integrated in ERP upgrade projects in their respective organization. They mostly had predominant influence on the organization’s IT decision making and were in charge of the upgrade procedure including planning, arranging teams to support the upgrades and conducting the upgrades. The duration of the discussed ERP upgrade projects ranged from one and a half months for rather small projects to one and a half years for comprehensive and large projects. Table I provides some basic information on the interview partners.
The interview guideline was derived from the literature review and the research questions, and was structured into five main parts. In the first part the purpose of the interviews were introduced. Additionally, the interviewee was informed about the recording of the interview and the anonymization of personal- and organization-related information. The second part dealt with the background of the interviewee. Therefore, questions concerning the person, the area of responsibility, the field of duties, the organization and the latest ERP upgrade projects were asked. The third section dealt with goals and objectives. The main focus was put on the reasons for ERP upgrades and which goals and objectives had been defined for these projects. The fourth section dealt with key success factors in ERP upgrade projects. Hence, the interviewees were asked to state the key success factors for ERP upgrade projects from their point of view and experience, and to give an assessment of their importance. Afterwards, problems during the projects and any countermeasures were discussed. The last section of the interview guideline dealt with the differences of success factors between ERP implementation and ERP upgrade projects. Thus, interviewees were asked to state the main differences from their point of view and rank success factors for ERP implementation projects mentioned in existing literature according to their importance for ERP upgrade projects.
The qualitative content analysis (Mayring, 2000) has been chosen as method for analysis of the transcribed interviews because the systematic and reproducible approach was the most suitable for this study. Bos and Tarnai (1999) provide an overview of content analysis for empirical social research, Gläser and Laudel (2013) describe differences to related approaches, including coding as part of grounded theory. This type of qualitative analysis is particularly fruitful when dealing with a novel field that is not yet structured and requires preliminary understanding (Patton, 1990). For example, it has been used to study Facebook users’ awareness of privacy issues (Debatin et al., 2009). The objective of the analysis is inter-subjectivity, and it follows a determined system based on stepwise categorization and codification of the material. As the qualitative content analysis is based on rules and theory, the research problem was divided into sub-issues along the research questions. Structuring with regards to content is used to filter particular topics, content or aspects out from the material. Therefore, various differentiable categories are defined deductively, and all text components are systematically analyzed and assigned to the corresponding category, using a three-stage process of definition of categories, setting concrete passages of a category as typical examples or anchors, and finally deriving coding rules to ease the assignment to particular categories. The selected text components were analyzed accordingly, and during the first run-through of the material, sub-categories for success factors for ERP upgrade projects were defined, as well as for upgrade reasons, and project goals. Subsequently, all the material was analyzed a second time to determine all suitable text passages to the corresponding sub-categories. After the finalization of the analysis process the categorized material was structured and summarized in order to present the results of the qualitative study.
Analysis and results
For each interviewee, different aspects triggered the decision to execute an ERP upgrade. One of the main aspects was the ability to use new functionality offered by new releases. Even though some organizations only need a small part of new functionalities included in the release, upgrading the system is often preferred to the development of individual enhancements for economic reasons (E). In case more of the included functionality is needed, it can be easily activated from that point on (K). Often organizations are forced to upgrade their ERP system because legal patches offered by the ERP vendors often require a specific release version (G). Another main reason for upgrading the ERP system is the imminent end of support offered by the vendor (E). Not only the support for the ERP system itself can be a crucial factor also compatibility issues with underlying systems can be another reason why an ERP upgrade is inevitable (I, L). In order to maintain competitiveness organizations have to conduct process innovation and establish emerging technologies, which both is easier during an ERP upgrade project (F, J, D).
In order to determine critical success factors, the success of ERP upgrade projects needs to be defined. C states: “Projects have to meet time, budget and scope targets to be called successful.” H, on the other hand, thinks time is not the main priority in ERP upgrade projects, as long as there is a usable system in place and productivity is not endangered. However, functionality targets have to be achieved and budget targets met. For I, the main aspect of success is functionality. Both the successful use of already existing functionality and the availability of new features are the key factors which influence the success of ERP upgrade projects. Nevertheless, I states: “To qualify a project as successful, also time and budget targets have to be met.” As a result of the high complexity of the project and the huge dependency on the ERP system, B and J scale down the expectations and consider an ERP upgrade project as successful when time targets are nearly met and the company is able to continue their business without complications. L and G also mention non-functional requirements which have to be met. The down-time caused by the upgrade has to be minimized so that it is hardly influencing work in the organization. Additionally, criteria such as performance and availability of the system have to reach at least the level before the upgrade (L, G).
The interviews showed that there is no large distinction between success of an ERP upgrade project and its objectives. When asked about the objectives of ERP upgrade projects, many of the interviewees talked about securing already existing functionality. After the implementation of the new release version, users must not discover any obstacles in their daily work (B, C, D). Also, non-functional aspects, such as performance, security, stability or reliability must at least reach the level from before (G, K). Additionally, the basis for new functionality should be established to be able to implement new functionality and benefit from it (I, G). B and K agreed that one objective on an ERP upgrade project always has to be the effort to replace individual developments within the system with standard functionality offered by the vendor. That means that new features of the new release version have to be examined in detail to identify possible replacements of individual developments. (B, K). D emphasizes the necessity to intensively study new technology offered by a new upgrade version to be able to adapt applications and processes and benefit from enhancements. In sectors where users are dependent on the system 24/7, the minimization of system down-time and connected non-availability are major goals (G).
The main research question was related to critical success factors in ERP upgrade projects. The following 14 factors were derived by classifying statements into categories which can be adapted to different organizations. The order of the success factors is based on the priorization of the factors done by the interviewees and the amount of occurrences within the interviews:
Project management: project management was the most often mentioned critical success factor. This means comprehensive project management has to be conducted with all its components such as an exact project charter, a detailed time plan, the appointment of a project manager and a project team, a work breakdown structure and project controlling (G). H and I emphasize the absolute necessity to put the focus on the planning and specification phase. It has to be defined in detail who is responsible for which work package and when it has to be finished (H, I). Another part of the planning phase is the definition of fallback scenarios (I). E also points out that responsible persons should think thoroughly about features to be implemented and their benefits. He states: “The fact that some processes are already established within a company or the fact that key users and process owners desire some feature alone is not reason enough that a specific functionality has to be implemented. Each new functionality has to be discussed in detail and benefits have to be weighed against the costs in order to find the best solution for the company.” A special focus was often put on the project manager. When asked about the most important key success factors J answered: “First the project manager, second the project manager and third the project manager.” Next to managerial tasks, he/she has to commit himself/herself to the project, has to know the current status of each work package at any time and has to compensate problems which occur on the levels below. C and D took the same line and described the project manager as a person who not only is an IT professional, but also has deep knowledge of the business and the processes of the organization. Project review and evaluation should be done in recurring time intervals, where the project team checks if the project is on track and if there is room for improvement to be able to respond to unforeseen changes as quickly as possible (E). At the end of the project it has to be checked if the project has been executed as planned, if expectations are met and if users get along with the upgraded system (I). Another important task often forgotten by organizations is the measurement of the benefits of the project after finalization of the project. K proposes to not only measure it one year after finalization, but also after three and five years after finalization to identify long-term benefits.
External support: a substantial success factor often mentioned was external support. As employees within organizations often work at full capacity and are not able to spare a large amount of their workload for additional projects, it is inevitable to engage external resources with comprehensive know-how to support the local ERP team within such a project (J). Another reason for the necessity of external resources is the economically non-viable development of internal know-how in specific areas. This would not only lead to high costs but also to an increase in the lead time (I). Additionally, companies benefit from the experience of external consultants or implementation partners. I underlines this factor: “I expect from an external consultant that he is able to tell me which problems already occurred in other similar projects and knows a way to avoid them within our project.” Even though most of the interviewees pointed out the importance and benefits of external consulting, B described his experience with consulting as not satisfactory and would have expected more input. Therefore, D and H emphasized the importance of the selection of external resources. They not only have to offer deep technical knowledge but also have to understand your business and be experienced. Apart from consultants and implementation partners, also the ERP system vendor plays an important role, as he is able to provide enhanced support levels and system experts (G). G also proposes to contact companies within the same business sector which already implemented the corresponding release version to profit from their experience. Furthermore, J recommended to employ students and interns for data cleansing tasks to allow ERP team members to focus on the critical tasks within the project.
ERP team: the success in ERP upgrade projects heavily depends on the composition of the project team. Employees with the best technical expertise are not always the best suitable team members for such projects. Team members must be able to think project-oriented and must be ready to show commitment. I proposes to select different team members for the conception phase and the realization phase to benefit from personal strengths of the employees. J insists that executive managers should not be part of the project team. First, employees do not always tell the inconvenient truth if their supervisor is in the same room, though this is crucially needed. Second, the project manager needs to have possibilities to put pressure on team members if they are not putting enough effort in the project. (J). The ERP project team should consist of a well selected mixture of employees with business, process and technical competence. The existence of business and process knowledge within the project team allows the handling of business-related topics without consulting the appropriate department (C). In addition to that, a team member should be selected to act as a mentor in order to mediate between team members in case of disagreements and to put the focus back to the essence (I).
Multiple system landscape: a multiple system landscape for ERP systems typically consists of three systems, the development system, the quality assurance system and the productive system. G even suggests to use a fourth, preceding system, the sandbox system. The sandbox system is an independent system where the new release version is initially installed to identify issues during the technical installation process. The goal of this step is the identification of optimizations on the productive system before the technical upgrade to be able to reduce down-time. The next step is to move to the development system, where functional and non-functional tests are performed. First, already existing functionality, especially individual developed functionality, is tested with a special focus on compatibility with the new release version. Second, new available functionality is configured and tested. On this level software developers perform basic tests. As soon as basic functionality is guaranteed, also key users should test detailed real-life scenarios (G, I). Subsequently, the quality assurance system is used to test the interaction between the ERP system and various connected information systems and interfaces. The last part is the deployment of the tested versions on the productive system. Due to the gained experience with the preceding systems, the whole upgrade process can be better calculated and the down-time of the productive system can be reduced as much as possible (G, I). G recommends to clone the system before the upgrade procedure and establish a so-called “evidence system” to allow comparison with the old system (G).
System testing: system testing is one of the most important tasks to ensure an unobstructed operation of the ERP system after the upgrade procedure (L). K recommends establishing a quality assurance department, which knows business processes and the functionality of the system before the upgrade to be able to determine misbehavior within the system (K). Additionally, it is inevitable to integrate key users of all departments to be able to validate both the already existing and the new functionality (B). Detailed test plans and test scenarios with various test cases have to be defined to secure a comprehensive and wide-spread coverage of the functionality (B, H). Even though test automation tools for ERP systems are expensive and are often not able to cover individually developed parts of the system, test automation is a way to reach a high standardization of the testing process. In the case of a system without much individual development, they should be considered (G). System testing should not only focus on functional testing, but non-functional factors, such as performance and reliability, have to be part of the process. The fact that the load on a productive system can hardly be emulated constitutes a challenge. Therefore, G proposes to have some reference transactions with “which we are able to compare the processing time before and after the upgrade.” During testing compatibility has to be dealt with, which secures that connected systems and peripheral devices are working with the new version (A). As the last part of the system testing process G proposes to execute further tests on the already upgraded productive system before go-live to be able to eliminate potential missed misbehavior.
Communication: one major objective has to be the introduction of a communication culture, which enables effective coordination between various departments and their interests. Within an ERP project many different departments are involved and each of them is pursuing slightly different interests. These parties have to be in exchange from the beginning of the project in order to accomplish the best result for the organization (J). Additionally, there is the need for professional communication within the project. Even though team members have different opinions on a topic, communication and discussion must take place on a professional level and personal differences must be left behind (I). Furthermore, communication with end users is important, as they can offer crucial process knowledge and indicate potential problems from their point of view (L). Another important factor within the communication with end users is the management of expectations. Users tend to expect a universal remedy from an ERP upgrade. To avoid frustration after the upgrade, it is recommended to communicate in detail which functionality and which improvements are included in the new version of the system (I). Furthermore, also reporting is a part of communication, which should be based on a detailed plan (I).
Key user integration: the analysis of the interviews showed that the integration of key users right from the start is essential for the success of the project. H proposes to integrate key users not only in the planning phase but also in the testing phase as they are able to deliver valuable input for the definition of test scenarios and test cases (B). The awareness that such projects are necessary and important for the organization is essential to be able to get all employees on board. Key users are a perfect way to act as middlemen between the project team and the end users to promote the advantages and to point out the value of the project. In addition to that, key users are in a position to prepare end users for possible system changes and challenges to increase acceptance (H, F).
Lessons learned: during the lifecycle of an ERP system, multiple ERP upgrade projects have to be carried out. The improvement of the performance from one project to another has to be a major goal for every organization. Thus, learning from mistakes is a key factor for future success. G suggests implementing a structured and standardized lessons learned process. E emphasizes the importance of lessons learned meetings, which are not only conducted at the end of each project, but rather are established as a continuous process. J takes the same line: “Even though this is often neglected by a lot of companies, from my point of view it is very important to invest your time in lessons learned meetings to be able to learn from your own mistakes.”
Stick to the standard: E and J strongly recommend to avoid code modification, as it entails major difficulties during an ERP upgrade. If the modified functions are changed by the vendor within the new release version, the desired functionality cannot be guaranteed after the upgrade (G, J). Another important factor which is influenced by code modification is revision security. Code manipulation in critical parts of the system can lead to problems in tax audits as legally correct archiving of fiscal information cannot be guaranteed (J). Because of these reasons, K proposes to use the upgrade project to analyze both new functionality within the new release version and individual developed functionality within the existing system. The objective has to be the replacement of as much individually developed functionality as possible by standard functionality offered by the vendor (K).
Top management support: ERP upgrade projects not only cause huge costs but often also implicate considerable organizational and technical change. As a result of the high complexity of such projects, financial forecasts are often not met and costs exceed the planned budget. Top management has to be aware of the importance of the project and assure financial and moral support. Additionally, ERP upgrades often lead to changes for end-users as new processes are implemented or new functionality is added. Therefore, top management has to communicate the necessity of the potential changes to avoid resistance within the workforce and encourage commitment to the project (F, I, J).
Resources and focus: another important factor which has been stated several times is the availability of all necessary resources. The ERP upgrade project has to be carefully coordinated with other projects within the organization. A time frame has to be chosen in which no other major projects take place in order to have the needed workforce available for the upgrade project. ERP team members must have the chance to not focus on their regular field of activity as much as possible during the project (C, G, F). Additionally, G suggests to focus on the upgrade itself and warns of seeing the required downtime as a reason for further adaptations or improvements. The increase of already high complexity can lead to difficulties when the source for a specific error has to be determined.
Change management: in case that the upgrade is not only technical but also new processes are implemented or existing processes are optimized, change management is a key factor for a successful project (K). Organizational structures have to be adapted to new or changed processes and necessary staffing changes have to be managed to prepare the organization in the best way possible for the time after the upgrade (E, H).
Data and code cleansing: the upgrade of an ERP system should always be used for a system clean-up. During many years of usage, a lot of unneeded or incorrect data are accumulated within a system (Xu et al., 2002). This clean-up prevents the transfer of wrong or outdated data into the new system. H suggests to not only clean up user data but also to clean up the source code. As modifications within the source code often are necessary anyway, this opportunity should be used to check the source code for old or unused functions and if possible, get rid of them (H, J).
Use of new potentials: the decision to upgrade an ERP system is often driven by the availability of new technologies. According to D, it is essential that companies use new technological possibilities provided by the new release version. Organizations have to put their full attention to the new technology and develop profound technical knowledge in order to understand the implications on their business. All these findings must influence the development of improvements, so that the new technological possibilities are beneficial. D states: “The implementation of old processes with the new technology is only a waste of money.” He also advises against relying solely on external consultants. The understanding of your own business is a key factor to be able to get the best out of the new technology for your organization.
In order to answer the research question related to differences in success factors between ERP implementation and upgrade projects, interviewees were asked to discuss these differences from their point of view. Afterwards, they were asked to rate the importance of the success factors for ERP implementation projects condensed from literature with respect to ERP upgrade projects. A major difference stems from the fact that already a running system exists when starting an ERP upgrade project. This leads to various changes in success factors. During an ERP upgrade project only a part of the functionality is changed, renewed or newly implemented. Therefore, the detailed specification has to be done only for new functionality and can be aligned to the existing system. When implementing an ERP system, the specification of the functionality has to take place in a more detailed and extensive way as requirements from different departments have to be collected, specified and prioritized and therefore, is more complex and time-consuming (I). The same applies to the factor business process re-engineering and customization, which is a key factor in ERP implementation projects. After an ERP upgrade, the majority of business processes will not be touched and stay as they are. Only processes related to new functionality have to be re-engineered and potential new modules have to be customized. Therefore, this factor only plays a minor role in ERP upgrade projects (A, H). Another consequence of having a running system is that users know the system and basic user training is not necessary. Only for newly implemented or adapted functionality users have to be trained. Because of the small amount of new functionality, users can be informed about small changes via handouts or short guidelines and extensive trainings can be avoided (B, G). Also, IT employees already acquired know-how about the system and the technology behind it. Thus, project members already can estimate potential problems and obstacles caused by the system and only have to rely to a smaller extent on external expertise (B, I). L points out that in ERP implementation projects a sensible approach has to be chosen regarding changes in business processes to be able to reach a high user acceptance. This factor only plays a role in ERP upgrade projects if new functionality is introduced which changes the working habits of users. To successfully implemented an ERP system, a clear business plan and a vision have to be defined to carry out the project accordingly. For ERP upgrade projects, this factor was estimated as not similarly important, as only minor changes in functionality are conducted and the basic strategy of the system remains as it was (C, G, K). Change management is a key success factor in implementation and was also defined as one for ERP upgrade projects in case of newly implemented functionality and processes. In case of only minor functional changes, the importance of change management was rated as not very important by B and G. Another key factor in ERP implementation projects is the selection of the appropriate software package. As the ERP package is not changed within an upgrade this factor is not applicable for upgrade projects. Further success factors for ERP implementation projects, such as the selection of a project champion, the building of a business case or the appropriate management of legacy systems were rated as not very significant for upgrade projects by the interviewees. On the other hand, also some success factors for ERP upgrade projects are not relevant for implementations. First, the use of a multiple system landscape for testing and quality assurance is not necessary, as the prior system can be in use until the newly implemented system is ready. Second, data and code cleansing is also not relevant because there is no existing code and data before an implementation project. The last factor for ERP upgrade projects which is not relevant for ERP implementation projects is the use of new potentials. To use potentials of an ERP system is a major part of business process re-engineering, which is in itself a critical success factor within ERP implementation projects.
Conclusion
Discussion and summary
During the last 20 years many organizations implemented ERP systems, and are forced to keep their system up-to-date and perform ERP upgrades in times of rapidly changing business environments, technological enhancements and rising pressure of competition. However, not only because of complexity but also because of high costs, a failed ERP upgrade project can have serious negative consequences. Therefore, this paper focused on the identification of key success factors in ERP upgrade projects. Since not much research exists yet about ERP upgrades, expert interviews and qualitative content analysis were selected to provide a starting point for further research. In total, 12 expert interviews with CEOs, CIOs, IT project managers and ERP consultants who had recently carried out ERP upgrades in their respective organization were conducted.
When analyzing the objectives of an ERP upgrade project it becomes clear that securing the already existing functionality is perceived as more important than the implementation of new functionality, hinting more at vendor pull rather than organizational push (Beatty and Williams, 2006). Organizations often carry out ERP upgrade projects to lay the foundations for new functionality (Collins, 1999; Otieno, 2010; Dempsey and Liam Sheehan, 2013), which is then implemented within separate projects, thus highlighting strategic flexibility and option thinking in the context of a platform or infrastructure investment (Taudes et al., 2000). Another major objective is the minimal disruption of daily business. Therefore the minimization of the ERP system down-time plays a key role. Furthermore, users should be able to continue after the upgrade without encountering obstacles such as severe changes in their workflow or the experience of performance losses.
In this study 14 factors were identified which are strongly connected with ERP upgrade project success. These complement and integrate prior research, e.g. from Beatty and Williams (2006), Collins (1999), Nah and Delgado (2006), Olson and Zhao (2006), Otieno (2010), Salmeron and Lopez (2010), as well as Scheckenbach et al. (2014). A major factor mentioned by most of the interviewees was comprehensive project management with all its sub-components to guarantee project success. A special emphasis has to be put on the planning and specification phase as well as the selection of a motivated and skillful project manager. Within the organization, the planning of other projects has to be adjusted with the ERP upgrade project in order to secure the availability of necessary personal resources and to put the focus on the upgrade project. Furthermore, almost everybody agreed on the fact that a successful carried-out project heavily depends on external support, as the development of necessary know-how would be economically nonviable and organizations can benefit from experiences made by external stakeholders (Somers and Nelson, 2004). As interviewees also reported about non-satisfying experiences with external consultants, careful selection of them is required. Not only the selection of external stakeholders but also the composition of the ERP team has been identified as a critical success factor. The ability to think project-oriented and to show commitment was rated as more important than technical skills. Besides, there was a broad agreement on the fact that the project team has to consist of a well-selected mixture of team members with business, process and technical know-how.
The usage of a multiple system landscape enables the organization to reduce the complexity of the upgrade process as the upgrade procedure is executed in smaller steps where technical installation procedures, functionality and interfaces to other systems can be tested in various non-productive systems. This leads to the next success factor, system testing, which should not only be executed by IT staff but rather by key users and process owners, who bring along process knowledge and therefore, can guarantee correct functionality. Another key factor is the integration of key users in the project from the very beginning of the project. They are able to deliver valuable insight into various departments and their needs to enable the perfect alignment of the system to the business needs. Even though it implies additional work for all team members, many interviewees mentioned the importance of lessons learned meetings. As ERP upgrade projects are recurring, any mistakes are a chance to improve the upgrade performance for the next upgrade project. Another stumbling block within an ERP upgrade project is a high degree of individual code modification within an ERP system. Therefore, every upgrade project should be used to remove individually developed functionality and replace it with new available standard functionality provided by the ERP vendor. Additionally, upgrade projects should also be a chance to remove unused or incorrect data and source code. There has been a broad consent on the importance of all the above-mentioned success factors. When it comes to change management and top management support, contradictory statements were made. The reason for this fact is the different amount of new functionality implemented during an ERP upgrade project. For upgrade projects where hardly any new functionality is implemented, both factors were estimated as not very important, whereas for projects with many newly implemented processes and much newly implemented functionality, they were estimated as rather important.
Many factors, such as project management, team composition, communication, system testing and external support, are crucial for ERP implementation projects as well as for upgrade projects. Still there are various critical success factors, which are only relevant for one type. ERP implementation projects are more comprehensive and therefore the specification phase is more crucial than in upgrade projects. Furthermore, a clear vision and a business plan, as well as the definition of a business case and user training, were identified as more important in implementation projects. On the other hand, success factors such as the usage of a multiple system landscape or data and code cleaning are only important for ERP upgrade projects. Additionally, some success factors for ERP upgrade projects are related ERP implementation projects and their strategies or decisions. The study showed that a high degree of code modifications leads to major problems during the upgrade procedure. Therefore, organizations are urged to avoid code modifications within the ERP implementation phase in order to prevent issues during potential ERP upgrades. These results therefore differ from Nah and Delgado (2006), who show no significant difference in success factors between ERP implementation and ERP upgrade, but have used the same factor structure. Table II provides a matching for the factors for both types of projects from the empirical study and literature review.
In conclusion, there is a large overlap between critical success factors in ERP implementation projects and ERP upgrade projects, though this paper also showed differences. Therefore, organizations should not see an ERP upgrade project as a small implementation project. A detailed analysis of the differences and corresponding behavior is crucial for ERP upgrade success.
ERP upgrade is a major topic in practice, as many organizations will be forced to upgrade their system within the next years, and managerial implications are quite clear. Understanding the factors that influence the ERP upgrade success has strong practical implications for related projects. It enables managers of ERP upgrade projects to adjust the approach for their project, ERP vendors get the chance to study the identified factors in order to improve their provided upgrade procedures and support as well as ERP consultants are able to improve and adjust their services to increase ERP upgrade project success for their clients.
Limitations and future research
This paper has several limitations, which can also provide ideas for future research. First, the data for the qualitative analysis was collected in Austria. Thus, the results can only reflect ERP upgrade projects in Austria and might not be representative for other regions. Second, due to difficulties in finding interviewees for this study, the variety of represented business sectors is limited. To compensate this imbalance, ERP consultants with experience in different business sectors were selected for interviews. Third, only one of the 12 interviewees was female. This is also a result of the fact that men dominate the IT sector and hardly any women responded to inquiries for interviews. Finally, the results of this qualitative study are based on subjective impressions of the interviewees. Thus, to be able to provide general reliable statements, the assumptions made in this thesis must be verified within a broadly based quantitative study.
As future research, a quantitative study with a larger sample size would enable the generalization of the assumptions and therefore, can confirm the relevance and prioritization of the stated critical success factors in ERP upgrade projects for a large amount of organizations, including SMEs which have been shown to differ in implementations (Malhotra and Temponi, 2010). Second, more countries or continents should be considered in this study to explore the influence of cultural differences on the criticality of identified success factors. Third, the impact of various decisions during the implementation phase on problems and challenges within an ERP upgrade project should be researched in order to assist organizations planning to implement an ERP system. Finally, the critical success factors identified could be used as a basis for the development of a prescriptive process model for ERP upgrade projects.
Interview partners
| Person | Position | Industry sector | ERP system | Users (approx.) |
|---|---|---|---|---|
| A | IT project manager | Banking | MS Dynamics | na |
| B | Head of IT | Manufacturing | SAP | 280 |
| C | Head of institute | Education | SAP | 3,600 |
| D | Professor | Education | na | na |
| E | ERP consultant | ERP consulting | MS dynamics | na |
| F | CEO | ERP consulting | SAP | na |
| G | Head of applications | Health care | SAP | 6,000 |
| H | Head of IT | IT-provider | MS dynamics | na |
| I | Head of applications | Manufacturing | SAP | 1,500 |
| J | Head of IT | Manufacturing | SAP | 5,000 |
| K | ERP consultant | ERP consulting | SAP | na |
| L | IT project manager | Manufacturing | SAP | na |
Critical success factors for upgrade and implementation projects with matching (sorted by upgrade projects CSFs)
| Upgrade projects | Implementation projects | Comment |
|---|---|---|
| Project management | Project management | |
| External support | Vendor support | Implementation partners and consultants included in ERP team composition during implementation |
| ERP team | ERP team composition | Includes implementation partners and consultants in implementation |
| Multiple system landscape | – | Not relevant in implementation |
| System testing | Software testing and troubleshooting | |
| Communication | Communication plan | |
| Key user integration | – | Not or less relevant in implementation |
| Lessons learned | Post-implementation evaluation | Different focus of improvement for next upgrade projects vs success evaluation |
| Stick to the standard | – | Includes replacement of individually developed functionality, not applicable during implementation |
| Top management support | Top management commitment and support | Minor role in upgrades, only related to new functionality or modules |
| Resources and focus | – | Not relevant for implementation projects, which generally receive sufficient focus |
| Change management | Change management | Remains major in case of newly implemented functionality and processes |
| Data and code cleansing | – | Not relevant in implementation |
| Use of new potentials | – | Not relevant in implementation (respectively part of Business process re-engineering and customization) |
| – | Business plan and vision | Minor role in upgrade, as only minor changes in functionality are conducted and the basic strategy of the system remains |
| – | Business process re-engineering and customization | Minor role in upgrade, only related to new functionality or modules |
| – | User training and education | Minor role in upgrade, only related to new functionality or modules |
| – | Business case building | Not significant in upgrade |
| – | Selection of a project champion | Not significant in upgrade |
| – | Cultural change management | Not significant in upgrade |
| – | Management of IT legacy systems | Not significant in upgrade |
| – | Selection of ERP software | Not applicable in upgrade as provider is not changed during upgrade |
References
Abran, A. and Nguyenkim, H. (1993), “Measurement of the maintenance process from a demand-based perspective”, Journal of Software Maintenance: Research and Practice, Vol. 5 No. 2, pp. 63-90.
Ahmad, M.M. and Cuenca, R.P. (2013), “Critical success factors for ERP implementation in SMEs”, Robotics and Computer-Integrated Manufacturing, Vol. 29 No. 3, pp. 104-111.
Al-Mashari, M. and Al-Mudimigh, A. (2003), “ERP implementation: lessons from a case study”, Information Technology & People, Vol. 16 No. 1, pp. 21-33.
Aloini, D., Dulmin, R. and Mininno, V. (2007), “Risk management in ERP project introduction: review of the literature”, Information & Management, Vol. 44 No. 6, pp. 547-567.
Barker, T. and Frolick, M.N. (2003), “ERP implementation failure: a case study”, Information Systems Management, Vol. 20 No. 4, pp. 43-49.
Beatty, R.C. and Williams, C.D. (2006), “ERP II: best practices for successfully implementing an ERP upgrade”, Communications of the ACM, Vol. 49 No. 3, pp. 105-109.
Bernroider, E.W.N. and Koch, S. (2001), “ERP selection process in midsize and large organizations”, Business Process Management Journal, Vol. 7 No. 3, pp. 251-257.
Bingi, P., Sharma, M.K. and Godla, J.K. (1999), “Critical issues affecting an ERP implementation”, Information Systems Management, Vol. 16 No. 3, pp. 7-14.
Bos, W. and Tarnai, C. (1999), “Content analysis in empirical social research”, International Journal of Educational Research, Vol. 31 No. 8, pp. 659-671.
Botta-Genoulaz, V., Millet, P.A. and Grabot, B. (2005), “A survey on the recent research literature on ERP systems”, Computer in Industry, Vol. 56 No. 6, pp. 510-522.
Chatzoglou, P., Chatzoudes, D., Fragidis, L. and Symeonidis, S. (2016), “Critical success factors for ERP implementation in SMEs”, 2016 Federated Conference on Computer Science and Information Systems (FedCSIS), pp. 1243-1252.
Chen, C.C., Law, C.C.H. and Yang, S.C. (2009), “Managing ERP implementation failure: a project management perspective”, IEEE Transactions on Engineering Management, Vol. 56 No. 1, pp. 157-170.
Collins, K. (1999), “Strategy and execution of ERP upgrades”, Government Finance Review, Vol. 15 No. 4, pp. 43-48.
Davenport, T.H. (1998), “Putting the enterprise into the enterprise system”, Harvard Business Review, Vol. 76 No. 4, pp. 121-131.
Davenport, T.H., Cantrell, S. and Harris, J.G. (2004), “Enterprise systems and ongoing process change”, Business Process Management Journal, Vol. 10 No. 1, pp. 16-26.
Davison, R. (2002), “Cultural complications of ERP”, Communications of the ACM, Vol. 45 No. 7, pp. 109-111.
Debatin, B., Lovejoy, J.P., Horn, A.K. and Hughes, B.N. (2009), “Facebook and online privacy: attitudes, behaviors, and unintended consequences”, Journal of Computer-Mediated Communication, Vol. 15 No. 1, pp. 83-108.
Dempsey, R.V. and Liam Sheehan, S. (2013), “Justification of an upgrade of an enterprise resource planning (ERP) system – the accountant’s role”, Global Journal of Human-Social Science Research, Vol. 13 No. 1, pp. 17-24.
Dezdar, S. and Sulaiman, A. (2009), “Successful enterprise resource planning implementation: taxonomy of critical factors”, Industrial Management & Data Systems, Vol. 109 No. 8, pp. 1037-1052.
Finney, S. and Corbett, M. (2007), “ERP implementation: a compilation and analysis of critical success factors”, Business Process Management Journal, Vol. 13 No. 3, pp. 329-347.
Gable, G.G., Chan, T. and Tan, W.G. (2001), “Large packaged application software maintenance: a research framework”, Journal of Software Maintenance and Evolution: Research and Practice, Vol. 13 No. 6, pp. 351-371.
Gläser, J. and Laudel, G. (2013), “Life with and without coding: two methods for early-stage data analysis in qualitative research aiming at causal explanations”, Forum: Qualitative Social Research, Vol. 14 No. 2.
Granebring, A. and Revay, P. (2005), “Enterprise resource planning competence centers: a case study”, Kybernetes, Vol. 34 Nos 9/10, pp. 1551-1562.
Haddara, M. and Elragal, A. (2013), “ERP lifecycle: a retirement case study”, Information Resources Management Journal, Vol. 26 No. 1, pp. 1-11.
Hakim, A. and Hakim, H. (2010), “A practical model on controlling the ERP implementation risks”, Information Systems, Vol. 35 No. 2, pp. 204-214.
Häkkinen, L. and Hilmola, O.P. (2008), “Life after ERP implementation”, Journal of Enterprise Information Management, Vol. 21 No. 3, pp. 285-309.
Hillman Willis, T. and Willis-Brown, A.H. (2002), “Extending the value of ERP”, Industrial Management & Data Systems, Vol. 102 No. 1, pp. 35-38.
Hirt, S.G. and Swanson, E.B. (2001), “Emergent maintenance of ERP: new roles and relationships”, Journal of Software Maintenance and Evolution: Research and Practice, Vol. 13 No. 6, pp. 373-397.
Holland, C.P. and Light, B. (1999), “A critical success factors model for ERP implementation”, IEEE Software, Vol. 16 No. 3, pp. 30-36.
Hong, K.K. and Kim, Y.G. (2002), “The critical success factors for ERP implementation: an organizational fit perspective”, Information & Management, Vol. 40 No. 1, pp. 25-40.
Koch, S. and Mitteregger, K. (2016), “Linking customisation of ERP systems to support effort: an empirical study”, Enterprise Information Systems, Vol. 10 No. 1, pp. 81-107.
Kræmmergaard, P. and Rose, J. (2002), “Managerial competences for ERP journeys”, Information Systems Frontiers, Vol. 4 No. 2, pp. 199-211.
Kremers, M. and van Dissel, H. (2000), “ERP system migrations – a provider’s versus a customer’s perspective”, Communications of the ACM, Vol. 43 No. 4, pp. 53-56.
Law, C.C.H., Chen, C.C. and Wu, B.J.P. (2010), “Managing the full ERP life-cycle: considerations of maintenance and support requirements and IT governance practice as integral elements of the formula for successful ERP adoption”, Computers in Industry, Vol. 61 No. 3, pp. 297-308.
Lee, J., Siau, K. and Hong, S. (2003), “Enterprise integration with ERP and EAI”, Communications of the ACM, Vol. 46 No. 2, pp. 54-60.
Light, B. (2001), “The maintenance implications of the customization of ERP software”, Journal of Software Maintenance and Evolution: Research and Practice, Vol. 13 No. 6, pp. 415-429.
Malhotra, R. and Temponi, C. (2010), “Critical decisions for ERP integration: small business issues”, International Journal of Information Management, Vol. 30 No. 1, pp. 28-37.
Markus, M.L. and Tanis, C. (2000), “The enterprise systems experience – from adoption to success”, in Zmud, R.W. (Ed.), Framing the Domains of IT Research: Glimpsing the Future Through the Past, Pinnaflex, Cincinnati, OH, pp. 173-207.
Mayring, P. (2000), “Qualitative content analysis”, Forum: Qualitative Social Research, Vol. 1 No. 2.
Nah, F. and Delgado, S. (2006), “Critical success factors for enterprise resource planning implementation and upgrade”, The Journal of Computer Information Systems, Vol. 46 No. 5, pp. 99-113.
Nah, F., Faja, S. and Cata, T. (2001), “Characteristics of ERP software maintenance: a multiple case study”, Journal of Software Maintenance and Evolution: Research and Practice, Vol. 13 No. 6, pp. 399-414.
Nah, F., Lau, J. and Kuang, J. (2001), “Critical factors for successful implementation of enterprise systems”, Business Process Management Journal, Vol. 7 No. 3, pp. 285-296.
Nah, F., Zuckweiler, K.M. and Lau, J. (2003), “ERP implementation: chief information officers’ perceptions of critical success factors”, International Journal of Human-Computer Interaction, Vol. 16 No. 1, pp. 5-22.
Ng, C.P.N. (2001), “A decision framework for enterprise planning maintenance and upgrade: a client perspective”, Journal of Software Maintenance and Evolution: Research and Practice, Vol. 13 No. 6, pp. 431-468.
Ng, C.P.N., Gable, G. and Chan, T. (2002), “An ERP-client benefit-oriented maintenance taxonomy”, The Journal of Systems and Software, Vol. 64 No. 2, pp. 87-109.
Ng, C.P.N., Gable, G. and Chan, T. (2003), “An ERP maintenance model”, Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03), HI, January 6-9.
Ngai, E.W.T., Law, C.C.H. and Wat, F.K.T. (2008), “Examining the critical success factors in the adoption of enterprise resource planning”, Computers in Industry, Vol. 59 No. 6, pp. 548-564.
Nicolaou, A.I. (2004), “Quality of postimplementation review for enterprise resource planning systems”, International Journal of Accounting Information Systems, Vol. 5 No. 1, pp. 25-49.
Ohlson, K. (2000), “Study: R/3 users face high costs for upgrades”, available at: www.computerworld.com/article/2594203/it-management/study--r-3-users-face-high-costs-for-upgrades.html (accessed February 3, 2017).
Olson, D.L. and Staleya, J. (2012), “Case study of open-source enterprise resource planning implementation in a small business”, Enterprise Information Systems, Vol. 6 No. 1, pp. 79-94.
Olson, D.L. and Zhao, F. (2006), “International Federation for Information Processing”, Vol. 205, in Tjoa, A.M., Xu, L. and Chaudhry, S. (Eds), Research and Practical Issues of Enterprise Information Systems, Springer, Boston, MA, pp. 569-578.
Otieno, J.O. (2010), “Enterprise resource planning systems implementation and upgrade”, PhD thesis, School of Engineering and Information Sciences Middlesex University, London.
Patton, M.Q. (1990), Qualitative Evaluation and Research Methods, Sage Publications, Thousand Oaks, CA.
Peng, G.C.A. and Nunes, M.B. (2009), “Identification and assessment of risks associated with ERP post-implementation in China”, Journal of Enterprise Information Management, Vol. 22 No. 5, pp. 587-614.
Ross, J.W. and Vitale, M.R. (2000), “The ERP revolution: surviving vs thriving”, Information Systems Frontiers, Vol. 2 No. 2, pp. 233-241.
Rothenberger, M.A. and Srite, M. (2009), “An investigation of customization in ERP systems implementations”, IEEE Transactions on Engineering Management, Vol. 56 No. 4, pp. 663-676.
Sahin, I. and Zahedi, F. (2001), “Policy analysis for warranty, maintenance, and upgrade of software systems”, Journal of Software Maintenance and Evolution: Research and Practice, Vol. 13 No. 6, pp. 469-493.
Salmeron, J.L. and Lopez, C. (2010), “A multicriteria approach for risks assessment in ERP maintenance”, The Journal of Systems and Software, Vol. 83 No. 10, pp. 1941-1953.
Scheckenbach, T., Zhao, F., Allard, E., Burke, J., Chiwaki, K. and Marlow, S. (2014), “Issues of ERP upgrade in public sectors: a case study”, in Kurosu, M. (Ed.), Human-Computer Interaction 2014: Applications and Services. Lecture Notes in Computer Science, Vol. 8512, Springer, Berlin, pp. 754-763.
Scheer, A.-W. and Habermann, F. (2000), “Enterprise resource planning: making ERP a success”, Communications of the ACM, Vol. 43 No. 4, pp. 57-61.
Schlichter, B.R. and Kraemmergard, P. (2010), “A comprehensive literature review of the ERP research field over a decade”, Journal of Enterprise Information Management, Vol. 23 No. 4, pp. 486-520.
Shaw, N. (2001), “The impact of software upgrades on individuals and organizations: a longitudinal study”, AMCIS 2001 Proceedings, p. 329.
Soh, C., Kien, S.S. and Tay-Yap, J. (2000), “Enterprise resource planning: cultural fits and misfits: is ERP a universal solution?”, Communications of the ACM, Vol. 43 No. 4, pp. 47-51.
Somers, T.M. and Nelson, K.G. (2004), “A taxonomy of players and activities across the ERP project life cycle”, Information & Management, Vol. 41 No. 3, pp. 257-278.
Stefanou, C.J. (2001), “A framework for the ex-ante evaluation of ERP software”, European Journal of Information Systems, Vol. 10 No. 4, pp. 204-215.
Sumner, M. (2000), “Risk factors in enterprise-wide/ERP projects”, Journal of Information Technology, Vol. 15 No. 4, pp. 317-327.
Taudes, A., Feurstein, M. and Mild, A. (2000), “Options analysis of software platform decisions: a case study”, MIS Quarterly, Vol. 24 No. 2, pp. 227-243.
van Everdingen, Y., van Hillegersberg, J. and Waarts, E. (2000), “Enterprise resource planning: ERP adoption by European midsize companies”, Communications of the ACM, Vol. 43 No. 4, pp. 27-31.
Wagner, E.L. and Newell, S. (2004), “‘Best’ for whom?: the tension between ‘best practice’ ERP packages and diverse epistemic cultures in a university context”, Journal of Strategic Information Systems, Vol. 13 No. 4, pp. 305-328.
Xu, H., Nord, J., Brown, N. and Nord, G. (2002), “Data quality issues in implementing an ERP”, Industrial Management & Data Systems, Vol. 102 No. 1, pp. 47-58.
Further reading
Al-Mashari, M., Al-Mudimigh, A. and Zairi, M. (2003), “Enterprise resource planning: a taxonomy of critical factors”, European Journal of Operational Research, Vol. 146 No. 2, pp. 352-364.
Auberta, B., Legera, P.-M. and Larocqueb, D. (2012), “Differentiating weak ties and strong ties among external sources of influences for enterprise resource planning (ERP) adoption”, Enterprise Information Systems, Vol. 6 No. 2, pp. 215-235.
Esteves, J. and Pastor, J. (2001), “Enterprise resource planning systems research: an annotated bibliography”, Communications of the AIS, Vol. 7 No. 8, pp. 1-52.
Robey, D., Ross, J.W. and Boudreau, M.C. (2002), “Learning to implement enterprise systems: an exploratory study of the dialectics of change”, Journal of Management Information Systems, Vol. 19 No. 1, pp. 17-46.
Scott, J.E. and Vessey, I. (2000), “Implementing enterprise resource planning systems: the role of learning from failure”, Information Systems Frontiers, Vol. 2 No. 2, pp. 213-232.