How to Disable Mortal Loops of Enterprise Resource Planning (ERP) Implementation: A System Dynamics Analysis

Abstract

Successful Enterprise Resource Planning (ERP) implementation depends upon various factors known as critical success factors (CSFs). This study developed a system dynamics model of ERP implementation based on CSFs to discuss ERP implementation complexities, which identifies the effect of CSF interrelations on different aspects of ERP project failure. Based on the model hypothesis, CSF interrelations include many causal loop dependencies. Some of these causal loops are called mortal loops, because they may cause the failure of risk reduction efforts to a more severe failure in effect of lack of system thinking on CSFs interrelations. This study discusses how system thinking works as a leverage point for overcoming ERP implementation challenges.

1. Introduction

ERP projects have a high failure rate. According to a recent International investigation by Panorama Consulting Group, 66% of ERP projects run late on average. Panorama’s study of 342 recent ERP projects showed that 74% were over budget, 37% have received less than 50% of measurable expected benefits and most of the respondent organizations found “unanticipated organizational issues” as the most important reason for project cost overruns [1].

An IT project’s success can be categorized by assessing the resulting system against the planned objectives, user expectations, project budget and goals by obtaining users’ consensus on the differences. A successful ERP implementation project should meet the user’s expectations while being completed on time and on budget [2]. Although there are many benefits associated with ERP implementation, the ERP project is very challenging. A big challenge for ERP implementation, which this study tries to answer, is why most ERP projects fail to meet expectations even if they run longer than initially planned and spend significantly over budget. To overcome such big challenges, different groups of researchers and practitioners have studied ERP implementation, which resulted in the introduction of ERP implementation Critical Success Factors (CSFs) [3,4,5,6]. There are many CSFs with different classifications and some are more important, which is mentioned by most researchers. However, the importance of CSF interrelation has been overlooked by most studies. Most of the past studies on CSFs have discussed them independently or brought up the simple relation between two factors, while CFSs have complex interrelations that should be considered in the analysis. This study answers the afore-mentioned question by focusing on causal loops among ERP implementation CSFs, which is a moot point in ERP project risk analysis. It clarifies why, in some cases, ERP projects fail to meet expectations even when additional time is spent on them than was planned for. It also provides a policy for achieving the best trade-off between project performance and the reliability of the implemented system. To be more specific, causal loops and complex interrelations among CSFs have made some what more important than others. Some CSFs have causal relations with more factors and affect the overall project experience more seriously. Also, disregarding these complex interrelations and the key role of some CSFs within this relational network might cause any effort towards failure risk reduction to fail more seriously. CSFs contribute in three ways to figuring out the final experience of ERP implementation as an incomparable success or irrecoverable failure. These are: project time; cost; and achievement of the expected benefits. The first two issues might cause full project failure and the third one mostly causes partial failure [7]. However, a common point in ERP implementation CSFs analysis studies is the discussion of the distinct effects of CSFs on project success [2,8]. Not only are CSFs interdependent and have complex interrelations that include lots of causal loops dependencies but also overall project time, cost and achieved expected benefits as the aspects of ERP’s success are linked together too.

When a project is unable to meet its critical expected benefits, it will take more than the planned time to fix problems and verify expected benefits—spending more time on a project causes more expenditure, which has an inverse effect on project ROI. In some cases, a project that goes over time makes it economically infeasible and causes the project to stop entirely. In classic project management, time and cost performance are the most important and most project managers make decisions based on time and cost performance. Unfortunately, inadvertency of output system performance and a focus on time and cost performance that lacks a systemic view of ERP implementation causes most ERP projects to fail in achieving their expected benefits and goals, even though the implementation process took much more than the planned time and cost. Although project time and cost are two different factors, they are integrated because project time overrun causes increased cost overrun. Also, trying to decrease project time overrun through increasing project resources also causes additional cost overrun. Consequently, ERP implementation success analysis has two different aspects—time and cost performance—which is called the Schedule Performance Index (SPI). Also, the abilities of the implemented system to meet expected benefits—called system reliability—in which the SPI indicates a ratio for the project’s planned progress to its actual progress in the time axis. In the case of system reliability success, project SPI plays an important role too. As an illustration, when an implemented ERP package is unable to provide expected benefits, the project will be faced with some rework cycles which means more time overrun.

Relying on the complexities in ERP risk management mentioned above, effective ERP implementation risk management should include more aspects and project managers need an effective tool for ERP implementation to achieve the best trade-off between Project SPI and output system abilities to meet expected ERP implementation benefits. This study tries to provide a proof of such tool capabilities through System Dynamics simulation. System Dynamics methodology is appropriate for any dynamic system characterized by interdependence, mutual interaction, information feedback and circular causality. System Dynamics is a way of analysing the behaviour of complex systems to show how they are structured and how policies used in decision-making govern their behaviour [9,10]. In this regard, the ERP implementation process developed as a system dynamics model based on system thinking theory to analyse ERP implementation dynamics as a common IT-based solution for Business process re-engineering. The developed System Dynamics model relies on ERP most important critical success factor as system ingredients frequently repeated in ERP risk analysis literature. The model discusses ERP implementation dynamic structure through identifying the system’s core causal loops, mortal loops which impact the core structure and cause failure and, the causal structure of systemic policies for successful ERP implementation. Also, ERP projects’ critical success factors effect on the implementation time performances and the exploited system operational performances have examined by using this system dynamics simulation. The analysis of ERP implementation CSFs effects on project overall success has done through mirroring all ERP implementation CSFs effects on project SPI which enables Project managers to examine the effect of different policies on CSFs’ behaviour. The study contributes system dynamics as the missed key of comprehensive ERP implementation risk analysis by integrating project time, cost and reliability indicators into a systemic concept of success and assert risk management policies effect on project outcome using CSFs causal system.

2. Literature Background

The ERP implementation project’s life cycle starts when an organization decides to implement an ERP package. At first, the organization selects an ERP package based on its requirements and defines a time scope for the project [11]. Even though picking the best ERP package is critical for ERP implementation success, it’s not enough to start running on the bumpy road to ERP implementation. Organization’s readiness for such fundamental changes that highly associated with business process re-engineering (BPR) is critical for successful implementation. To go into the depth of implementation readiness and its aspects, [12] have developed a methodology by establishing an adaption between ERP implementation CSFs and EFQM model indicators in assessing organizational readiness for those, that have decided to implement ERP system. On the same path, [13] have developed a hybrid model based on fuzzy logic and AHP methodology, that introduces important factors of a successful ERP selection from both product and managerial solution perspective of ERP implementation. Finally, when ERP implementation starts, the organization will be in a way that its readiness as its initial situation has an important effect on how the organization will complete the way.

Large ERP projects implementation associated with more BPR. A former study by Panorama Consulting implies that more than half of the respondent organizations in Panorama study found “organizational issues” as the most important issue in ERP implementation which causes spending 0–25% of project budget on organizational change and business process management [14]. BPR is the fundamental rethinking and the radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance such as cost, quality, service and speed. Suresh believes that the radical redesigning of a process has easily achieved by involving information technology (IT) in business processes and hence the prominence of IT in BPR [15]. So IT is accepted as an essential enabler of BPR [16]. As ERP systems achieve seamless integration through information flow across the various functional areas of an organization, this technology tool enables BPR. Thus, ERP system qualifies as a potential candidate for IT-based BPR in organizations [15]. But what makes attaining BPR benefits through ERP implementation complex is the software package basis of ERP and its customization complexities. Since ERP is a software package, ERP developers would like to provide a general solution; while organizations require a specific package that is as customized as possible to meet all their business process requirements. Although general ERP packages support some level of customization, corporations still need to redesign some processes to implement ERP. Fully customized ERP system is so expensive that there is only a few organization those have enough financial resources to develop a fully customized package can implement. These corporations also have some core processes common ERP packages do not fit [15]. Consequently, attaining BPR benefits through ERP implementation would be possible through a combination of business processes changes and ERP package provider’s customization. Even in the best case scenario, ERP implementation can meet about 80% of adopter organization requirements [15]. To shed more light on the importance of both BPR and ERP customization in implementation success, Panorama Consulting states that “Organizations that do not define their business processes clearly before software selection will most likely find their chosen ERP system requires heavy customization to meet business requirements.” They also “have found the cost of customization a shock for implementation.” [14]. The results of the most recent Panorama study showed 11–25% of customization for 70% of the respondent organizations [1]. In fact, the risk is consequences of simultaneous implementation of ERP implementation as a software package, which its customization is so expensive and organizational process re-engineering leads to high-risk levels of implementation success.

Since ERP is a best practice-oriented software package that most of the organizations pick it as an IT-based BPR, required a level of BPR for adopting the selected ERP package is an important factor for a successful ERP implementation. Consequently, the larger gap between the organization’s maturity process level and what ERP produce as a best practice, the more BPR required. Needless to say, in the case of more intense BPR, the organization has to work harder and complete more implementation tasks in a limited time, because time performance is very important for the investment return and implementation time could not extend consumedly.

But the question is, although most implementation processes take much more than the planned time, why do organizations fail to improve ERP implementation performance and implementation outcomes are not satisfying, even though organizations are aware of the importance of the project time performance and spend their whole effort to improve attained results performance? This research is going to answer the question through system dynamics simulation of ERP implementation. The simulation model asserts how lack of system-thinking in ERP implementation risk management will cause project failure to meet expected benefits while corporation spends significant time and cost more than the initial plan. It also produces some risk management policies for successful ERP implementation. To delineate, ERP implementation as a system has some leverage points that control project success indicators such as SPI and reliability. Unfortunately, instant reaction of project managers to success indicator called system effect without considering leverage points as system cause makes correcting efforts inefficient and lead project to a more serious failure. To be more specific, since time and cost are more tangible factors, in most of the failure cases project managers focus on SPI to reduce the risk of ROI failure. They attempt to shrink tasks that hurt system reliability. Needless to say, that system modification under operation is more difficult than final tests preparation phase and imposes more force on respondent organization lead to a worse SPI situation. Contrary to considering the systemic relation between SPI and system reliability and focusing on factors effects reliability, ERP projects would be able to achieve a better outcome.

3. Methodology

As mentioned, this research objective is to answer the question why most ERP projects fail to meet expectation even if they run later than initial plan and spend much more than the budget and any effort for failure risk reduction to a more serious failure? This study uses System Dynamics methodology to answer these questions and, assert how system thinking on ERP projects implementation risk factors makes corporations able to prevent project failure. System-thinking is a combination of tools and skills are being used to express our understanding of complex dynamics through sharpening our awareness of wholes and how the parts within those wholes interrelate [17]. Complex interrelations among CSFs is a good motivator to apply system dynamics methodology in ERP risk analysis to understand how does each CSF work during an ERP project implementation? And how do interrelations among CSFs affect project outcome?

Causal loops diagram and stock-flow diagram are two most important tools in every system dynamics simulation. Causal loop diagrams are important tools for representing feedback structure of the system. They represent interrelations among parts of a system. These feedback loops are the main source of system dynamics [18]. This research produces how these feedback loops in ERP implementation system will cause project failure. They not only make over budgeted cost ineffective but also cause serious failure as more as overtime accrue.

Stock-Flow diagrams can perform system accumulations. Accumulations called stock in system dynamics simulation exhibit the system’s status in different sections of time and are a source of the system’s disequilibrium. They also give some information of what are the system’s decisions based. There are lots of examples of accumulations. As a case, the account balance is an accumulation. Accumulations are altered by the difference of inflows and outflows and have historical memory. In the account balance case, a deposit is an inflow and withdrawal is an outflow [18].

This research simulation focus is on ERP implementation CSFs. There are several factors are affecting ERP implementation but the simulation model required those CSFs that are in close relation with SPI and system reliability as the main focus of simulation analysis and model the system mathematically as simple as possible. SD simulation tries to eliminate some real-world complexities that do not play a pivotal role in system behaviour to make the system easier to understand. Hence this study has used CSFs that meet the above requirements and have scrutinized by more studies. In this way, most recent review papers on ERP systems CSFs and risk factors have studied and common factors have been picked up for further research on interrelations. Also, to solidify the authenticity of interrelations are used in the simulation model; several studies and handbook on ERP implementation have reviewed.

Table 1. Enterprise Resource Planning (ERP) Critical Success Factors (CSFs) Review of Literatures.

CSF	[19]	[20]	[3]	[7]	[4]	[5]	[6]	[21]	[22]
Education & Training	√	√	√	√	√	√	√		√
User Involvement	√		√	√	√	√	√
Employees’ Motivation		√	√			√
Poor Project Team		√	√	√	√	√	√
Lack of cross-functional project team				√	√	√	√
Project Management	√	√	√	√	√	√	√		√
Change Management		√	√	√		√	√
Resistance to change	√	√	√	√	√	√	√	√	√
Project cost planning and management	√	√	√	√				√
Business Process Re-engineering	√	√	√	√	√	√	√		√
Communications	√	√	√	√		√	√	√
Inadequate Legacy System Management		√		√		√			√
Absence of readiness			√		√			√
Internal conflict between departments			√		√	√			√
Wrong ERP Modules Selection		√		√		√	√		√
High rate of system customization			√	√	√		√
Poor Vendor Support	√		√	√	√		√		√
Consultant Poor			√			√			√

represents these CSFs and frequency of mentioning in most recent ERP implementation CSF review papers.

4. Model Development

Practically, ERP systems are integrated process-oriented systems, are based on best practices and also generally have a software package on the business front. From this point of view, ERP systems are wide ranging software packages that have numerous parameters that make them strongly complex to configure adaptive organizations’ processes in the best performance level that is necessary to run the system. Nevertheless, there are some Exclusive processes that ERP is unable to cover [23]. In this respect, [24] believes that sufficient technical knowledge on ERP vendor package details is essential for implementation. Because ERP packages have thousands of parameters that delimit processes and enables the project team to establish its processes between lots of available solutions that ERP provides for a single purpose. That being so, a cross-functional team, who are fluent not only in the selected ERP package details but are also experts in the organization’s process requirement details, is required. Based on what was previously mentioned about the ERP implementation complexities and the required knowledge, an ERP critical success/failure factor is the “project team,” and its productivity will emerge. In fact, the “project team” is responsible for business process re-engineering based on the final goals and the ERP package capabilities. Hence vendor support and the quality of vendor training programs for the project team as two other ERP implementation CSF, play important roles in determining the project team’s productivity. After finishing the vendor training programs on how to configure processes in an ERP package, implementation process would transmit to a phase that the project team’s capability in the progression of the implementation project based on the planned schedule would frequently measure. The measure will be throughout the schedule performance index (SPI) until the official end of the implementation process and the feedback on the SPI project would have important effects on decisions during the project’s lifecycle.

A question that might arise in the implementation of ERP and that this research will answer is, how do ERP implementation dynamics cause such a severe challenge for organizations and eclipse the project time performance? To elucidate this matter, as a comprehensive solution for all organizations in all industries, ERP packages are very complex to understand all of their details. Consequently, most firms perform business process re-engineering in partnership with expert ERP consultants to enhance the implementation and also BPR quality to reduce the implementation time [25]. Also in the point of critical roles in ERP project’s life cycle, [26] emphasized on the role of a consultant and expressed that most of ERP adoptive firms use expert consultants because they provide comprehensive and optimized solutions whose necessity would appear when systems go operational. The role of expert consultant support as a frequently mentioned ERP critical success factor interprets to the ratio of implementation tasks that have done in collaboration with a consultant and those tasks have done internally. More collaborative tasks improve BPR quality that decreases the probability of newly implemented process misfits.

After process re-engineering and ERP package configuration based on the re-engineered processes, it’s time for implementing those processes. Besides process re-engineering, ERP would change roles and responsibilities; so new roles and responsibility-designing and their level of intervention in new processes are essential. As already noted, the ERP project team completes BPR tasks aided by ERP consultants; consequently, the project team structure plays a key role in their organizational processes requirements conversancy. Shields also believes that one of the most important CSFs in ERP implementation is user participation. He Emphasizes that all ERP stakeholders should be involved in designing the process and system performance tests. In other words, ERP implementation from Shields’ point of view has formed by a core team who works on the implementation project full time and a support team that includes all stakeholders who are not a core team member. The support team provides essential information about the process requirements, suitable test scenarios, training requirements, etc. [24]. Therefore, it can conclude that even professional project teams do not know the different processes and roles and details. This knowledge is achievable only through permanent interaction between the project team and process owners and also their involvement in the processes and role re-designs [27]. The importance of “communication” and “user participation” could be understood as two critical success factors. Therefore, the frequency of the project team’s interaction with others is used in this study’s simulation that has a significant effect on BPR quality, or in other words, whole roles and processes requirement will gain coverage. Figure 1 represents the dynamic hypothesis about ERP implementation as a causal diagram.

Based on what has said about the project team’s productivity and the quality of BPR, it can conclude that re-engineered process that is designed and implemented by the project team is rarely able to cover the whole organization’s process requirements. Also, some level of rework is needed because of probable misfits between what the organization requires and what ERP provides [28,29,30]. Such reworks increase implementation remained task which has adverse effects on “SPI.” Most organizations compensate recognized rework causes project lag through increasing overtime which will bring more task performing capacity. If these rework that is caused by the process misfits would identify in the go-live phase after the legacy system abundance, the firm would be facing a serious crisis and would have to solve the identified misfits simultaneous to the system’s live use. In such situations, the performance of the in-use ERP is not as expected; and the system reliability which is a critical factor for a successful ERP implementation, causes some levels of resistance to change. The greater the misfits, the higher level of resistance to change and increased efforts to leave ERP and return to the legacy system. Since there is a tight link between ERP and the legacy system to cover those requirements that ERP is unable to provide and the project’s time performance is unsatisfactory at the same time, it would be even more difficult to convince users to spend their efforts on solving ERP problems instead of returning to the legacy system [24]. Obviously, these misfits will eclipse the project’s time performance and will postpone the project’s end in addition to the project’s time performance before going live.

4.1. ERP Implementation’s Hidden Dynamics

The causal diagram in Figure 1, illustrates the ERP implementation’s dynamics core. But what intensifies the ERP implementation’s failure risk are the hidden mortal dynamic loops that, overshadow the core dynamic’s structure and change the consequence of the efforts for a successful implementation to an unexpected accelerated movement to a more formidable failure. This study is going to introduce and analyse these hidden mortal loops. Figure 2 represents the ERP implementation’s causal diagram, including the hidden mortal loops.

In most cases, organizations try to compensate for projects falling behind the scheduled progress through increasing over time. But most project managers miss the point of overtime effectiveness slippage in a long time. However, increasing overtime may look effective but especially in ERP implementation projects, it is not an effective policy to enhance project schedule performance in the long term. Because increasing overtime cause fatigue in the project team which leads to slipping in the project team’s performance which will lead to more errors in completing the implementation tasks. Consequently, future overdoes will be increased as a result of long-term use of higher levels of overtime policy [18,27]. In the case of overtime policy incompetency, if the firm attempts to enhance the ERP implementation schedule performance through eliminating those project tasks scheduled for implementation in the last days, the project’s overall performance will deteriorate much more. It’s because most of the implementation tasks planned for the last days are those who examine the implemented system’s reliability and also user training which bears great importance [31]. System reliability tests in ERP implementation mainly consist of the implemented system’s cross-functional performance, which can be performed just at the end days of the project after all involved processes completion. Note that eliminating such important tests may increase the risk of incompatibility between the implemented system and the expected performance in an irreversible way. In fact, it’s essential to examine the implemented system’s performance accuracy in providing all of the firm’s process requirements through precise test scenarios before leaving the legacy system and switching to an ERP system to solve them. These tests require profound knowledge in the field of adoptive firm business that the ERP system is implemented to respond to its requirements. Therefore, using various users’ experience who are responsible for different roles in the organization and have full knowledge about the organization’s requirements can be useful in planning test scenarios for the implemented ERP system’s misfit recognition in the integrated performance tests. Any weakness in recognizing the implemented system’s misfits before going to the live phase will face the organization with serious problems [24]. Some system misfits are recognized during the system’s overall performance tests and enter the modification cycle to be solved but some misfits those are not recognized because of the tests’ reduced quality as a result of eliminated test tasks planned in the end days. These unrecognized misfits are the main reason for the system’s weakness in providing the expected benefits will impair the organization’s performance and should be resolved simultaneously with using the ERP system which will cause a serious performance crisis for the organization. As mentioned before, most organizations leave the ERP system and return to their legacy system in such performance crisis situations or other words; the ERP project fails to implement.

About reducing the final users’ training tasks, it should note that their fluency on their new roles and responsibilities will decrease as a result of decreasing the required training programs which cause further required on-job training in the go-live phase. Umble expresses the importance of the final users’ training notes, stating that if the final users are unable to use the ERP system perfectly, the ERP’s expected benefits could not be realised. So the project team should ensure that the final users can work with the ERP system fluently and give them on-job complementary training if necessary [11]. It is important to have in mind that increasing on-job complementary training leads to the project team’s less available time to support and resolve the recognized misfits after the go-live phase which will postpone the actual project end.

4.2. Systemic Policies Preventing ERP Implementation’s Failure

As is evident in Figure 2, the ERP implementation’s dynamic structure consists of some mortal loops. The core structure’s interaction with those mortal loops is like the interaction between cotton and a match; a wrong spark can transform ERP to a hill so that the project team’s efforts to improve the implementation results would invert the effort in intensifying the flames of the hill. How organizations can reduce the ERP implementation’s risk through relying on the described structure for ERP implementation as a dynamic system remains a question. The answer firstly lies in the firms’ motivation for ERP implementation and secondly in their reactions to the upcoming challenges in effect of starting an ERP implementation. As mentioned before, most of the organizations select ERP implementation as an IT-based solution for their firm’s business process re-engineering, while customizing ERP as a software package to fit it to the organization’s unique processes that create the organization’s core competencies is strongly time-consuming and requires lots of financial and human resources. So increasing the number and monopolization of the firm’s unique processes requires more customization. It not only will increase the implementation tasks but also will increase the probability of misfits between what ERP can provide and what the adaptive organization expects from the ERP implementation that can cause a serious challenge for the organization in leaving the legacy system. On the other hand, by increasing the gap between the adaptive organization’s current processes and what ERP proposes as a best practice, the level of BPR required will increase. In higher levels of the required BPR, not only the implementation tasks will increase but also the probability of misfits between the implementation results and the organization’s requirements will increase. Figure 3 represents the ERP implementation system’s causal diagram after applying factors which can control the mortal loops and neutralize their adverse effects as much as possible.

According to the causal loop diagram in Figure 3, one of the possible solutions for reducing the ERP implementation risk is “performing BPR before ERP implementation, to provide a suitable conformity between the firm’s processes and the ERP available processes.” As Panorama research results admit, an organization that does not perform some levels of BPR before ERP implementation, are those require more customization in their ERP Package [14]. Also performing BPR before ERP implementation also provides insight into the firm’s processes that is a useful facilitator for selecting the best ERP package which has the most conformity to the firm’s requirements.

Even though performing BPR before ERP implementation reduces implementation tasks, some other factors interfere with the implementation of the scheduled progress; thus, project management policies play an important role in a successful implementation. As mentioned before, when an ERP implementation project falls behind the schedule, two wrong policies are increasing over time and eliminating some end days’ tasks including the systems’ cross-functional reliability tests and final users’ training that have important roles in the implemented system’s conformity with the organization’s expected benefits. In other words, every misfit that is unrecognized in effect of the decrease in the tests’ qualities will not only face the firm with a serious crisis but also impairs the project’s schedule performance and resource usage will be more than usual. The policy of “concentrating on the quality of the results and refusing to do actions that have adverse impacts on the results’ quality” is more efficient in the long-term from both a time and a results perspective, even though it may cause the performance to slip in the short term. The Panorama consulting research results admits that organization should emphasize on business process management through allocating budget toward organizational changes with a strong third-party consultant [14]. Consequently, concentrating on reducing the level of required BPR during implementation through performing some level of BPR before attempting to implement an ERP package can have inconceivable effects on reducing ERP implementation failure risk. Also, simultaneous focus on keeping the quality of performed tasks, especially final test tasks through refusing elimination of end days’ tasks and collaborating with both expert consultants and all roles during implementation, reduce failure risk too.

5. Simulation Results

This study has developed a computer-based simulation model of the ERP implementation as a System Dynamics simulation to analyse its failure from the System dynamics point of view. Also, it produces two recommended policies for decreasing ERP implementation failure risks based on adjusting the existing structure examined in a simulation environment. Although all model parameters and equations have set based on simple and logic relations, all classic tests for validating a system dynamics model behaviour, structure and policies implication introduced by Forrester have passed successfully [10].

As mentioned, the stock-flow diagram is one of the essential requirement for the System dynamics simulation of the discussed hypothesizes is a flow diagram. Figure 4 shows the ERP implementation flow diagram based on the discussed dynamics hypothesizes.

System dynamics simulation use mathematical equation especially differential equations to model systems variable interrelation and these interrelations effect on system behaviour in time pass. Details of these equations have been dismissed in this research to concentrate on simulation outcomes. Simulation focus is on the behaviour of two critical part of the system, “SPI” and “system reliability” as the main indicator of ERP implementation success calculated by Equations (1) and (2).

SPI = Actual Progress/Planned Progress

(1)

system reliability = 1 − ((AGL Recognized Rework + BGL Recognized Rework)/Planned BPR Tasks)

(2)

In Equation (2) “AGL Recognized Rework” indicates reworks should perform after go-live in effect of system misfit to firm requirements and “BGL Recognized Rework” represent reworks have recognized in system tests before go-live. Also “Planned BPR Tasks” in Equation (2) represent all aggregated BPR and implementation tasks except end-user training tasks, should be performed by a corporation to adopt an ERP system.

5.1. Results of Examining Policy (1)

To examining the effectiveness of “performing BPR before ERP implementation to provide a suitable conformance between ERP processes and the adoptive firm’s processes” policy, the simulated model is run three times with different settings. At the first run, the model has been set to a little customization requirement level and performing BPR tasks during the ERP implementation. For the second run, the model has been set to perform BPR tasks during the ERP implementation without any customization. Finally, for the third run, not only BPR tasks has been performed before the ERP implementation but also there is not any customization during implementation. Figure 5 represents the project’s schedule performance through “SPI” variable for these three runs.

As is evident in Figure 5, a lower level of BPR tasks during the implementation and also lower customization levels cause better schedule performance for ERP implementation projects. Tsai et al. affirm in their study that companies should adopt BPR to adopt ERP system and companies that consider BPR in ERP system will have better implementation performance [32]. Based on simulation results, by performing all BPR task and customization during ERP implementation, the project might take 1.5 times longer. Alongside with better schedule performance, the reliability of implemented system after go-live is a key factor in implementation success. Figure 6 represent dynamics of system reliability for three runs for a policy of performing BPR tasks before ERP implementation.

Based upon simulation results doing BPR task during ERP implementation would increase the risk of system unreliability. Although ERP systems provide seamless integration through cross-functional information flow that enables IT-based BPR, BPR is a revolutionary redesign of firm’s processes based upon corporation vision to achieve competitive competency through a dramatic improvement in processes main characteristics such as quality and speed [15]. Combining BPR and ERP implementation might decrease the quality of BPR that cause a lower level of system reliability after ERP system lunch in go-live phase and force more tasks to the ERP implementation project as unrecognized rework during live operation of ERP system. Esteves believes that the strategic importance of BPR would be lost if it is seen as being a consequence of ERP implementation [32,33]

5.2. Results of Examining Policy (2)

To examine the effectiveness of “concentrating on the quality of the results and refusing actions that impact it” policy, the simulated model is run three times with different settings too. For the first run, the model has been set to perform all BPR tasks with the collaboration of expert consultants in an isolated environment and there is not any interaction between the project team and the process owners. Also, the project team’s productivity has set to 80%. For the second run, the model has been set to use only the overtime policy to compensate for the project falling behind schedule. Finally, for the third run, the model has been set to use eliminating end days’ tasks including final users’ training and the system’s cross-functional reliability tests in addition to the overtime policy. Figure 7 represents the project’s schedule performance through the “SPI” variable for these three runs.

As is evident in Figure 7, in both first and second runs of the model, there is a schedule lag because of the project team’s productivity. However, both runs tried to compensate their schedule lag through overtime; simulation results reveal that the overtime policy is not efficient in the long term because the project’s schedule performance enhanced slightly after applying overtime but in the long run, it fell again to a lower level than it was before applying this policy. Simulation results also reveal that eliminating final tests and training tasks acts the same as the overtime policy. Even though eliminating final tests and training tasks may improve schedule performance but this improvement is temporary. Once the project goes to the go-live phase, complementary on-job training and identified misfits put the project behind schedule again and cause a later end for the project in comparison to the project end before applying this policy. In fact, these two policies make system adjustments more complex through transferring required reworks for fixing the existing misfits and the identified reworks before the system goes live to unrecognized reworks that should be performed simultaneously using the system after it goes live. Although, Figure 8 represents system reliability dynamics for the second policy.

Both overtime and eliminating final tests lead to decrease system reliability by increasing unrecognized reworks. Overtime would increase the fatigue ratio and cause a lower level of tests quality that causes unrecognition of a misfit among expected and implemented processes that would solve after go-live phase during live operation of the system, has a drastic inverse effect on system reliability.

5.3. Results of Examining the Combination of Policies (1, 2)

Performing BPR before ERP implementation provides a suitable conformance between ERP processes and the adoptive firm’s processes. Also, concentrating on the quality of the results and refusing actions that impact the results’ quality helps meeting expected performance. So by applying these two policies at the same time, organizations would achieve the best schedule performance level. Simulation results in Figure 9 and Figure 10 reveal achievements of applying the two policies together.

Concentrating on the quality of the results and refusing actions that impact the results’ quality through refusing elimination of end days’ tasks enable firms to find out misfits before systems go-live and have enough time to correct them. When a firm leaves its legacy system in the go-live phase and starts using ERP it has to correct recognized misfits while using the imperfective ERP system for handling its daily tasks, which causes a lot of crisis for the firm and puts more pressure on solving problems. In case of serious problems, users may attempt to resist solving recognized misfits and leave ERP which causes project failure. Regarding the importance of using expert consultant and communicate with all roles during the implementation, it reduces the probability of misfit between expectations and what has developed through ERP implementation. Finally performing BPR before ERP implementation would provide a suitable conformance between ERP processes and the adoptive firm’s processes which not only reduce implementation tasks but also increase conformity of the Firm’s processes with standards which cause less probable misfit between ERP outcomes and expectations.

6. Conclusions

According to the simulation results, it could understand that ERP implementation has lots of dynamics and a parameter’s behaviour can change quite the contrary to the organization’s expectation. Such different behaviour is because of the organization and the project team’s misunderstanding caused by a lack of a holistic and systemic view on ERP implementation. The important point in the ERP risk management is exactly such misunderstandings in considering SPI and system reliability relations together and to CSFs as a dynamic system which is the basis of most decisions that their consensus would be irreversible and determine the project’s success or failure. For instance, the effects of eliminating final tests and final training tasks on the schedule’s performance have examined in the simulation. Simulation results illustrate that despite the project team’s expectation in compacting these tasks in ERP implementation, not only it was unable to enhance the project’s schedule performance but also it caused serious challenges for the firm after the system go-live. That’s because of the negative relation between tests quality and system reliability, not only cause more time overruns but also in go-live phase cause more resistance to change and makes system modification more challenging. Also in examining the effects of performing BPR before ERP implementation, the simulation results illustrate that there is little risk in implementing ERP as a software package and the main risks in ERP implementation are the required changes in the organization’s processes, unique procedures, roles and managing these changes during the implementation. What emerges from the simulation results is that a holistic and systemic view on the ERP implementation and, thus, considering causal loops, play a significant role in successful outcomes of the decisions during the project. In case of eliminating final test and training tasks, system dynamics model assert that lower quality of tests in the effect of eliminating final test cause more unrecognized rework should perform in go-live. These unrecognized reworkings have an unavoidable effect on firm’s process unreliable and cause a serious crisis for the firm might cause project stop and return to the legacy system. Also elimination of end-user training task to solve project schedule performance problem cause a lower level of end-user fluency on ERP usage which results in more on job training and less available time for the project team to solve unrecognized misfits. Since simulation results demonstrate, without a holistic view and considering the systemic effect of a decision, any effort for improving the implementation result may cause a fatal failure. Results of the most recent Panorama’s ERP report are indirect proof of what has elaborated in the simulation. According to the Panoramas survey on 394 ERP project in 2017 more than half of the time overrun reason belonged to technical, organizational, training and expanded project scope issues [1]. System dynamics simulations such as what discussed in this study can provide valuable insight about complex projects such as ERP implementation and the importance of long-term thinking about the effects of decisions on attaining the best trade-off between the project’s outcome performance and other factors. Although alluded system dynamics model and policies are not the best solution for ERP implementation risk reduction, it can prove the concept of System Dynamics application in ERP implementation risk analysis and answer the questions why ERP project is challenging and how organizations can reduce the risk of implementation failure through making systemic decisions. In other words, SD simulation in this study contributes to a more lucid understanding of ERP implementation challenges and role of each CSF in different aspects of project outcomes. Also, it provides insight for project managers and team members about how to do their performance and decision effect overall system function. Therefore, the study results could affirm past studies more comprehensively and practically.