Enterprise Resource Planning Modification: A Literature Review

- The current low success level of Enterprise Resource Planning (ERP) implementation stimulates the rise of research to find the critical success factor of it. One of the challenges of ERP implementation is to find a ‘fit’ between business and system requirements. It is claimed that standardizing business processes to follow the ERP system will positively impact organizations to follow the best practice process. However, there is another challenge that organization should not reengineer their business process to fit the ERP system, but rather modify or customize the ERP system to match their business process. This belief argues that standardizing business processes is not the right solution that applies to every organization since it can degrade an organization’s competitive advantages. Based on the background, the research aimed to construct a comprehensive review to succeed in implementing an ERP system, particularly on ERP modification, using a systematic literature review method. It was done by collecting and analyzing scientific publications related to ERP critical success factors with special attention to system modification. The literature review results in a comprehensive explanation of ERP modification. It includes elaborating on different types of misfit and customization to cultivate the understanding of ERP modification, a flowchart to analyze misfit to help the organization to evaluate modification requests, and critical success factors of modified ERP implementation.


I. INTRODUCTION
Enterprise Resource Planning (ERP) is a package software that embeds a standardized business process from the best practice in the industry. A different business function is integrated by embedding logic via specific modules in the software, such as the finance module for finance division, human resource module for human resource division, and others. This package provides not only process integration but also data and security which are hard to achieve with multiple software platforms (Parr & Shanks, 2000). This system can be implemented in many organizations, even organizations that have a wide geographical distribution area.
ERP is a dominant type of software that is popularly used by many organizations (Haines, 2009). The system is configurable to fit with organization requirements. Thus, modification toward the system is not recommended (Fosser, Leister, Moe, & Newman, 2008). The modification can degrade system performance and integration. It may also affect maintenance and upgrade in the future (Hong & Kim, 2002). However, there is always a discrepancy between organization requirements and ERP, which may come from specific regulations or organization uniqueness (Sia & Soh, 2007). Sometimes, changing an organization's business process into a standard vanilla ERP can cause the organization not to comply with the regulation and eliminate its competitive advantage (Liu, Wang, & Tai, 2011). Therefore, ERP modification is undeniable.
The high investment that the organization needs to pay for ERP implementation is why it needs to plan the implementation thoroughly. Moreover, the success rate of ERP implementation in Indonesia is still less than 50% (Dantes & Hasibuan, 2011). Globally, only around 25% of the ERP implementations are considered to succeed (Al-Sabaawi, 2015). It means more than half of ERP implementations exceed both budgets and allocated time frame. Customization is one of the causes that increase the probability of ERP implementation failure as it adds duration, money, and effort to the implementation (Haines, 2009). It occurs in the ERP implementation done by Woodco in the USA, which costs the company US$ 14 million, and AML in Egypt (Haines, 2009;Kholeif, Abdel-Kader, & Sherer, 2007).
Furthermore, the modification also costs an organization in the post-implementation phase. The cost to implement ERP modification can seem low in the implementation phase. However, it can increase significantly during the usage period due to the update and maintenance activities, as shown in Figure 1 (Ehsary, 2010). Therefore, the organization must have a deep understanding of ERP customization and factors to increase ERP implementation success.
Many researchers aim to find the critical success factors of ERP implementation in general. However, there is still little research focusing on ERP modification. Upon this background, the research aims to construct a comprehensive analysis of the key success factor of ERP system modification by reviewing previous studies on this topic. The research emphasizes more on the technical aspect of ERP modification. The contribution of the research is to shed light on ERP modification implementation to avoid failure. Thus, it will enrich the literature on ERP implementation.

II. METHODS
The research constructs a comprehensive view about ERP implementation strategy in terms of ERP modification by collecting and critically reviewing previous research using a systematic literature review method. Furthermore, the research addresses the following questions: What are the types of ERP misfit? what are the types of ERP modification to solve ERP misfit? How to analyze misfit to evaluate modification requests? What are the critical success factors to implement ERP modification?
The systematic literature review method is done by collecting and analyzing scientific publications related to ERP critical success factors with special attention to system modification. The literature review is performed in four stages adopted from Ancveire (2019). The process is illustrated in Figure 2.
It is essential to define and list all relevant keywords based on the research question. The following keywords in the selection process of scientific literature are Enterprise Resource Planning misfit, Enterprise Resource Planning customization, Enterprise Resource Planning tailoring, and Enterprise Resource Planning modification. The researchers also use ERP as abbreviation. Science Direct, Web of Science, and Google Scholar are used in this process as a scientific database. This initial step generates 1.271 articles. Next, the selection process is done by reading the title and abstract of the research. The research with ERP modification for the implementation phase in their title and abstract are selected. This process results in 71 articles in total. These articles are analyzed for a detailed review.
Organizations may choose between developing an ERP system in-house or buying ERP package software from an ERP vendor (off-the-shelf ERP). Developing in-house ERP is suitable for the organization which has a unique requirement. However, it will increase the total cost of ownership since the cost of integrating and maintaining the ERP component is on the organization itself, not the vendor (Haines, 2009). Therefore, many organizations choose to use off-the-shelf ERP software (Van Beijsterveld & Van Groenendaal, 2016).
ERP vendor is a configurable package software. It means the user of this software can configure the software to match the business requirement by setting the available parameters during the configuration process of ERP. This configuration process is also called customization, referring to the term used by ERP market vendor, SAP. The available parameter in ERP is derived from business practice to meet the requirement of a broad type of business rather than a specific one (Yen et al., 2011). Therefore, the ERP solution sometimes cannot fit with the organization's requirements (Haines, 2009). Around 20% of an organization's process cannot be modeled in SAP, one of the leading ERP software (Soh et al., 2000). Therefore, organizations need to choose between changing their business process or the ERP system.
In some cases, changing the business process is not possible. This condition is referred to as imposed forces, which can be in government policy and industry norms. These unavoidable forces are highly likely to require an ERP system to be modified. Another modification may also voluntarily come from the organization's requests, such as improving performance in working with the ERP (Sia & Soh, 2007). Nevertheless, the organization needs to decide how much the modification should be made since it will cost the organization not only in the implementation but also in the post-implementation phase.
The main activity in ERP implementation is configuration or customization. In a broad spectrum, configuring the system with no or very limited modification is referred to as vanilla implementation. Meanwhile, with the modification, it is referred to as modified implementation (Parr & Shanks, 2000). The advantage of vanilla implementation is a low effort and cost to implement and maintain the system. However, to solve the gap between organization and system requirements, the organization needs to change its business process to match the embedded common process in the ERP software. Modified implementation best suits organizations with a unique process that cannot be generalized using the ERP system. The company needs to put big effort and cost into implementing and maintain the system. It should also plan and assess the impact of ERP modification since the ERP vendor does not support these modifications (Davis, 2005).
There is a taxonomy based on the organization's implementation scope to simplify the planning ERP implementation: vanilla, middle of the road, and comprehensive (see Figure 3) (Parr & Shanks, 2000). First, vanilla is implemented without or with minimal modification, such as report or screen mask adjustment. It is commonly used for companies that implement an ERP system in a single site. The company will try to align its business process with ERP. So, the system modification is almost zero or limited. Only the core ERP module is implemented, and it requires the lowest budget and implementation time compared to two other approaches.
Second, the middle of the road is a mid-level of modification. It is usually used for a company that implements the ERP system in a single site and multiple sites in the same geographical or country area. The ununified process in the different areas requires a bit of business process reengineering (business process change) to match the system. The process that cannot be matched into the system will require minor or major system modification. In this implementation approach, normally, only the core module is implemented. It requires a higher budget and implementation time compared to the vanilla approach.
Third, comprehensive is a high-level modification. This approach is used for a company that wants to implement an ERP system in multiple sites in the same geographical or country area and different geographical areas (international). Since all sites need to be integrated, it needs both major business process reengineering change and system modification. Commonly, besides the core module, the company also needs to implement an industry-specific module. It costs the highest and has the longest implementation time compared to the other approaches. There are various terms to refer to the process of changing ERP systems. Some called it ERP customization (Soh & Sia, 2004;Haines, 2009), ERP tailoring (Brehm et al., 2001;Hustad et al., 2016), and ERP modification (Yen et al., 2011;Čelar et al., 2011). Referring to it as ERP customization may cause confusion since it means only a configuration as popularized by SAP. The configuration is defined as setting up organizational structure and business process in the ERP system using the available parameter in the system without changing the system (Hong & Kim, 2002). Meanwhile, tailoring SAP, as stated by Brehm et al. (2001), reflects a broad definition, including configuring table and field in the standard ERP and changes the system. Thus, in the research, the term ERP modification will be used to give a narrower term referring to making changes in the ERP system other than the process of setting up an available parameter in the configuration process.
Adopting from Brehm et al. (2001), the previous research categorizes all processes in developing ERP systems into three categories based on the degree of vendor support: configuration, extension, and modification (see Figure 4). Configuration activities include changing entries in tables or configuration files, which are supported by the vendor. The vendor mostly supports extensions via common interfaces in their system (known as user-exits). Meanwhile, the modification includes code changes and other more invasive changes, which are not supported by the vendor (Haines, 2009). According to Haines (2009), the term modification in the research refers to both modification and extension since those two categories are regarded as system changes.

Figure 4 ERP Development Activity Categories
(Source: Haines, 2009) A modification taxonomy is made to list all the possible types of modification. One of the initial and highly cited in academic literature is taxonomy developed by Brehm et al. (2001). It lists modification into eight types: screen mask adjustment, bolt-on, extended reporting, workflow programming, user exits, ERP programming, interface development, and package code modification. Furthermore, form is added as a modification type by Anderson (2011).
First, screen mask adjustment refers to modifying available screens in the system to match the organization's requirements (Portougal & Sundaram, 2005). Examples of screen mask adjustment are fading in or out specific tables, rows, or columns, creating users' specific menus, adding specific buttons, and changing, adding, or deleting input fields and output masks (Léger et al., 2011). Second, bolt-on is a software product to bring additional functions, such as a program or even module in the ERP system, to satisfy the organization's needs. The examples are high-end product configurators, shop solutions, or Customer Resource Management (CRM) systems (Léger et al., 2011).
Third, workflow programming refers to modifying embedded workflow in an ERP system to match the organization's business process. It is a systeminitiated process that is necessary for automation and control process on the operational level. ERP vendors provide dedicated workflow tools which are often integrated as a bolt-on to be implemented quickly (Léger et al., 2011). Fourth, extended reporting or report adjustment refers to changing layout reports using predefined built-in settings or using a report generator (Léger et al., 2011). It is also the activity of modifying standard reports in minor or major process or creating a new report not only using a built-in setting in ERP (Portougal & Sundaram, 2005).
Fifth, user exit is an interface provided by the ERP vendor to merge and connect programs (add-ons) that are explicitly developed by ERP in organizations without accessing ERP source code (Léger et al., 2011). It will not cause harm to the ERP maintenance, but the complexity of user exit may be difficult to maintain. Sixth, ERP programming refers to developing ERP applications and modules without making changes to the existing application or module code (Portougal & Sundaram, 2005). The difference between user exit and ERP programming is the written code in the programming language by ERP vendors, such as ABAP in SAP or C# for Microsoft Dynamics AX (Léger et al., 2011).
Seventh, interface development is an effort to develop an interface to another system, such as a legacy system that needs to be integrated with a new system (Portougal & Sundaram, 2005). Some ERP vendors facilitate this modification by providing Application Programming Interface (API) which can reduce effort and complexity. The difference between this modification with EPR programming and user exit is that it does not need to develop add-on using package code. Instead, it uses modern middleware solutions, such as Enterprise Application Integration (EAI) tools, to simplify the process (Léger et al., 2011). Eighth, package code modification happens when the existing ERP code is changed directly at the program level (Portougal & Sundaram, 2005). This type of modification has the highest risk compared to others since it can threaten ERP performance. It also costs very expensive in maintenance as the change may be corrupted and overwritten by system updates and upgrades (Léger et al., 2011). Therefore, many ERP vendors discourage this type of modification and exclude it from support services. Lastly, forms refer to developing custom forms that are required to input data in the system (Anderson, 2011).
Before deciding which and how much modification should be made, the organization needs to fully understand how the ERP works so that appropriate modification can be done. A lack of knowledge of the ERP system will cause the organization to make many unnecessary modifications. Then, it will consume a high budget for ERP implementation (Hustad et al., 2016). Thus, the modification should be made only for items that have the strategic benefit or improve the organization's system performance. According to Davis (2005), the organization should be aware of two different categories of customization based on their impact on the organization. They are strategic customization to enhance the alignment of information technology infrastructure strategy and business strategy and consistency customization to improve the organization's system agility.
One of the initial activities in implementing an ERP system is to break down the organization's business processes in detail and match them with the process embedded in the ERP system. This activity is usually called fit-gap analysis (Hustad et al., 2016). In standard or vanilla implementation, the organization sets the available ERP parameter to match the organization's business process without modifying the system. If the organization's business process cannot fit with the available parameter, it needs to choose between changing its business process or modifying the ERP system. This gap between organization business process and system capability is referred to as misfit (Soffer et al., 2005;Hustad et al., 2016).
It is suggested that not every misfit identified in ERP implementation is an actual misfit. It can be a perceived misfit. Perceive misfit does not come from legitimate issues. It derives from users' resistance to change, ignorance, and wishes. Resistance to change is when employees want to work the way they do previously in the old system (Van Beijsterveld & Van Groenendaal, 2016). Thus, the change requests to modify the new system to be like the old system arises. This case happens as the users feel uncertain about the new system (Hong & Kim, 2002).
Meanwhile, ignorance is a form of users' lack of knowledge toward the new system. They do not try to understand the feature that the system has. Thus, they perceive the system has some missing functionality or lower performance than the old system (Van Beijsterveld & Van Groenendaal, 2016). Then, wishes are the users' high expectations toward a new system. The replacement of the old system with the new system leads the users to think that the new system will be far better than the old system in all aspects. Hence, they perceive it as a misfit and want it to be customized (Van Beijsterveld & Van Groenendaal, 2016).
Based on the institutional cause, the modification is divided into imposed and voluntary (Sia & Soh, 2007). The imposed modification comes from externally imposed forces, such as government policy and industry norms. Meanwhile, voluntary modification is from the internal management choices for differentiation in the industry. Imposed modification is primarily unavoidable, which leads the organization to make system customization.
The previous research proposes four different methods to match ERP systems with the organizational requirements. First, the organization adapts fully to the vanilla ERP system. Second, the organization accepts some of the system limitations and ignores the business requirement. Third, the organization finds an interim solution without changing the ERP system. The solution can be a manual work or workaround (using ERP functionality differently as it should be). Fourth, the organization tailors the ERP system to match its requirement. In the imposed case, since the organization cannot ignore the driver for change, it can use the third or fourth method (Soh et al., 2000).
In the voluntary case, before changing the ERP system, it is recommended to review the request in detail whether it is crucially needed and has high benefit. According to Hustad et al. (2016), many voluntary requests are made due to users' lack of knowledge and resistance to change to the new system. It means some of the requests may not come from an actual misfit. It is relevant to the research of Haines (2009) that resistance to change will increase the number of ERP modifications as solutions to reduce immediate tensions. However, it will consume a lot of the organization's information system resources without getting a significant impact. It may even lead to a negative impact if the organization cannot manage the modification properly.
The misfit can occur in three levels: countryspecific requirement, industry-specific requirement, and enterprise-specific requirement (Sia & Soh, 2007). Most of the gap happens in enterprise-specific requirements since the ERP is built to accommodate the generalized organization's business process in the industry (Yen et al., 2011). Furthermore, there is categorization by Yen et al. (2011) by adopting research of Sia and Soh (2007). Three categorizations from Sia and Soh (2007) are input data, process, and output misfit. Then, an additional category from Yen et al. (2011) is system environment misfit. First, input data misfit is an inability of the ERP system to input various objects or documents into the ERP system database. It includes incompatible data format, poor visibility of data, and poor accuracy of data. This category is a deep structure misfit.
Second, process misfit is an incompatibility between organization and ERP system in the processing procedure. It includes incompatibility of business strategy, incompatibility to model business process, and incompatibility with the organization's structure. This category is a deep structure misfit. Third, output data and interface misfit is an incompatibility between organization and ERP system in the context of information content and presentation of the output. It includes incompatible output format of data, poor quality or accuracy of output, incompatible terms and meanings, irrelevant and complex interface, and no visibility of output's logic and calculation. This category is a surface misfit. Lastly, system environment misfit is an additional category made by Yen et al. (2011). It represents an incompatibility between system usability and IT Infrastructure. It includes missing functionalities of non-transactional, poor quality and performance of the system, and poor usability by the community of target users.
The chosen type of misfit and customization will influence the cost, technical difficulties, and risk. Change in the input data and process misfit requires higher cost, technical difficulties, and risk since these two misfits happen in the core system layer, which integrates with other modules (Yen et al., 2011). Some ERP vendors do not recommend the organization to access or modify the source codes of the system. They will also not provide maintenance support if there is havoc caused by those modifications (Suryanto, 2018). Therefore, in this situation, if it is possible, it is suggested to change the business process rather than the system to accommodate input data and process misfit, unless the benefit of system modification is greater than business process change. On the other side, the other two types of misfits (output data and interface and system environment) have lower cost, technical difficulties, and risk (Yen et al., 2011). Therefore, many system modifications take place in these two categories. This idea is supported by Suryanto (2018) that normally ERP consultants are more willing to modify the system to close the gap in the interface or output level. To summarize this step, the researchers developed a flowchart that can guide the organization to analyze its misfits and help to make decisions, as shown in Figure 5.
ERP implementation strategy is stated as to how the organization develops, utilizes, and integrates organization, system, and culture that lead to competitive advantage (Mahraz, Benabbou, & Berrado, 2018). Some previous researchers have tried to identify the strategy to succeed in ERP implementation. Many of them suggest critical success factors of ERP implementation in general (Al-Mashari et al., 2003;Zhang, Lee, Zhang, & Banerjee, 2003;Leyh, 2012;Ahmad & Cuenca, 2013;Dantes & Hasibuan, 2011;AlQashami & Heba, 2015;Puspitaningrum & Sintiya, 2018;Mahraz et al., 2018). However, modified ERP implementation needs specific critical success factors that should be elaborated. In implementing a modified ERP system, technical factors have more weight as modification requires advanced technical effort. The research constructs and elaborates these factors from a technical perspective. This finding is summarized in Table 2.
In ERP modification minimization, the complexity of modification can cause the organization to over budget and pass the go-live date. The high level of modification is the main cause of ERP implementation failure (Haines, 2009). Therefore, out of the argument from those who believe in ERP modification, they also argue the modification should be kept to a minimum (Westrup & Knight, 2000;Van Beijsterveld & Van Groenendaal, 2016;Wang & Wei, 2014;Suryanto, 2018;Huang et al., 2012).
From Figure 5, the organization is supposed to change to solve the actual misfit rather than perceive misfit. Having rigorous customization request management helps the organization to be more selective in granting modification requests. It can be done by formalizing the customization request procedure, such as having a default change request form to explain the detail of the requested modification and including an important person for the approval. The key point people need to be in the loop for the approval decision at least by including the consultant or expert who will make the modification, supervisor or head of the respective department who request the change, IT manager as the owner of the ERP system, and project manager who responsible in the succession of ERP implementation. Moreover, a paper or document about risk-impact analysis will help top management to decide on requested modification (Suryanto, 2018). The risk-impact analysis should be made not only considering implementation stages but also maintenance and upgrade stages.
A matrix table is developed to measure the cost of maintenance from modification activity. It combines a list of maintenance activities and cost dimensions.  Figure 5 Flow Chart to Analyze Misfits  Maintenance activities happen in the post-go-live phase, such as bug fixes, user support, training, and upgrade. Meanwhile, cost dimensions are divided into three categories: products and services, people, and process. Products and services are the costs for product or services which organization receives that needs to be paid. Then, people are a cost spent by internal information technology personnel on maintenance activities. Meanwhile, the process is an indirect cost resulting from downtime, like training time regarding the modification for the user (Ehsary, 2010). Adopting that matrix table, the researchers develop a matrix table that is specifically used for measuring the cost of modification in each different stage. Table 3 is an example of a matrix with different modification types to distinct different costs for each modification.

Output Data and Interface Modification
List of maintenance activities are adapted to be a list of modification phase, such as implementation, maintenance, and upgrade. Meanwhile, three cost dimensions are used to measure costs of modification in every phase. All cost dimensions in the matrix should be evaluated critically to get a complete view of the total cost of modification. The column 'cost' in the right side of Table 3 is a sign to distinguish the cost range of each modification category, such as 'high' for input data modification, 'medium-high' for process modification, and so on. Structuring a complete view of modification like this will help the organization to avoid the hidden cost of modification, including the cost in the post-implementation stages. Besides measuring the cost of modification, the additional step to plan modification is to schedule every modification.
Scheduling ERP modification wisely will allow the organization to have a shorter duration and cost reduction in the implementation. The methods are done by dividing the modification into two phases (before go-live and after go-live) and minimizing the amount of modification before go-live (Čelar et al., 2011). Minimization customization before go-live certainly will shorten the implementation time and reduce the risk of the implementation. However, it is important to prioritize and implement all crucial modifications prior to the go-live date to ensure that the required modification can be successfully implemented.
In developing an ERP system, ERP expert guidance is an inseparable element if the organization chooses to use an ERP package from an external vendor. Because of the different logic and features that every ERP package software has, it requires specific expertise for each. Experts who can work in the main ERP player, such as SAP, do not necessarily have Oracle ERP expertise. Furthermore, in one ERP software package, the expertise is still divided into several roles such as network administrator, programmer, functional, and change management. It is also divided into several functional modules such as finance, human resource, and operation. Therefore, to shorten the duration of the learning process, the organization usually hires an external consultant for ERP implementation (Westrup & Knight, 2000;Cahyadi & Zeleznikow, 2013).
Although the organization has a high dependency on external experts in ERP implementation, the high cost of consulting services should be considered. According to Westrup and Knight (2000), the consulting cost related to ERP implementation is 1-3 times the ERP software cost itself. Thus, to better allocate resources that the organization has, the organization needs to understand the consultant's characteristics that the organization looks for and in what the implementation stage the consultant is needed the most.
In terms of consultant characteristics, technical skill and knowledge are perceived as the most important traits, followed by a commitment to producing quality work and the ability to manage ERP implementation. It is also revealed that most of the ERP users in the survey rate the highest necessity for the consultant in the configuration and integration stage, followed by the design and planning stage (Metrejean & Stocks, 2011). This result is similar to Lutteri and Russo (2011). The most performed activities done by the consultant are customizing and development. Additionally, the success of ERP implementation is determined by the senior consultant. It is important to utilize this actor for a critical activity like modification in a more focused way (Lutteri & Russo, 2011). Thus, in implementing ERP with high-level modification, the organization should find a consultant with a high level of technical skill and long experience to work on modification. Meanwhile, other less critical activities are handled by the junior consultant. The theory is also supported by Luo and Strong (2004). ERP system experts must perform the high complexity of modification.
Many consulting companies compete to give more competitive prices which benefits organizations to save much consulting budget. However, sometimes, to get lower costs than other competitors, consultants do some deception, such as putting senior-level consultants in the tender process but giving juniorlevel consultants in the implementation process. It will cause a low level of work quality and no synchronization between expectation and reality. Therefore, besides budget consideration, it is essential always to seek a credible consulting firm.
Although the organization relies on the consultant, especially for the modification, relying heavily on external consultants in the long term will consume a significant organizational budget. Therefore, it is necessary to transfer external consultant's knowledge to internal employees. The users' low acceptance in using the new system is due to difficulties in understanding the change between the old and new system (Saide & Mahendrawathi, 2015). The effective knowledge transfer process is an obligatory element not only for the financial aspect but also for the knowledge capacity and ability of the ERP users in using the system.
Next, there is documentation. As ERP vendors do not recommend modification, the organization should handle the maintenance and upgrade by themselves. Managing a large number of ERP modifications is very difficult without proper documentation (Ebersteins & Grabis, 2011). Besides, it is impossible to remember all modifications and their changes. Then, the high level of consultant turnover also makes the follow-up process on the modification very hard. Because there is no proper documentation of modification, if there is a problem, new consultants need to access the source code to understand the modification made by the previous consultants and the potentially impacted areas to avoid another problem. This process is very resourceconsuming. The previous researchers mention that the companies mostly complain about undocumented modifications made by other consultants in the interview. It consequently makes them do tremendous reengineering jobs (Dittrich & Vaucouleur, 2008). The documentation is also necessary for upgrade purposes since all the modifications should be rewritten if there is a system upgrade (Yen et al., 2011).
Every consulting firms have their method in documenting modification. However, the organization must have the ability to read and understand them. The organization can also make their documentation methods and ask the consultant to follow them. A universal method is proposed to standardize the method of documentation with the hope of simplifying it. A spreadsheet can be used to store all the modification registers (Ebersteins & Grabis, 2011). Documentation is one of the knowledge transfer tools. The effectiveness of knowledge transfer is also determined by knowledge management (Saide & Mahendrawathi, 2015).
The organization uses knowledge management to have better communication between top management and employees to optimize the work process. The knowledge about the new system will increase users' acceptance and motivation and reduce the users' requests toward system modification (Rothenberger & Srite, 2009). Furthermore, adopting a learning strategy and successful knowledge transfer from experienced consultants have a critical role in overcoming knowledge barriers and mitigating misfits (Fosser et al., 2008). Knowledge sharing in ERP implementation is not merely communicating about how each module of the ERP software works but also confirms that organizational members understand about underpinning assumptions of the system and the organization environment in the form of tacit knowledge. Tacit knowledge can happen in routine work that employees may not aware of and have difficulties explicitly communicating it. Therefore, effective knowledge transfer happens when an organization can internalize that tacit knowledge and integrate the adopted process with the existing knowledge (Vandaie, 2008). To manage tacit knowledge, it can be done by documenting key findings of proposed solutions given by the consultants of every occurred problem (Saide & Mahendrawathi, 2015). Two knowledge-sharing facilitators determine the success of knowledge-sharing in tacit knowledge: the structure of team interactions (physical workspace and hierarchy of the team) and the team's atmosphere (open communication culture). One example to maintain those facilitators is building a team that focuses on process rather than structure and sharing knowledge as part of the implementation contract (Vandaie, 2008). In the long run, the organization that can acquire external knowledge to internal staff will reduce the cost for external experts and establish the organization's internal helpdesk to manage and support toward ERP life cycle (Lutteri & Russo, 2011).

IV. CONCLUSIONS
Modification is sometimes undeniably needed to optimize the benefit of the ERP system. However, ERP modification can cost the organization a lot, not just in the initial place but also for the maintenance. The literature review research presents a comprehensive analysis of ERP modification and critical success factors. First, the flowchart to analyze ERP modification requests is developed to help the organization to decide to modify the ERP system. It will allow the organization to select which modifications should be executed appropriately. Second, the different type of ERP modification is explained including the cost and risk in each type of modification. Thus, the organization can manage its implementation risk wisely. Third, critical success factors that focus on the technical aspect are presented. In the ERP modification, the technical aspect has more weight compared to the organizational aspect.
Minimizing the number of modifications is believed to be the important success factor in previous researches. However, high-level modification may lead to a higher rate of project failure. The failure can exceed the project budget and duration, or the project can be abandoned completely. The cost of modification matrix is developed in the research to help the company calculate the total cost of modification in the long term. Then, ERP expert guidance is found to be another success factor in ERP modification. Modifying ERP requires a high level of specific technical skill, which commonly organizations do not have the resources internally. The ERP experts' selection criteria and the key method to manage them are explained in the research. After that, documentation is also a success factor as documentation will help the organization to manage the maintenance and upgrade process of the modification. The last key success factor is knowledge management, which will increase users' understanding of the ERP system and eventually reduce users' resistance to change.
Since the research mainly focuses on the technical aspect of ERP modification, organizational or managerial aspects also need to be elaborated. For example, there are change management to address employees' resistance to change, commitment from the board level to avoid project discontinuation, and others. Future research that elaborates on these aspects will complement the literature about the implementation of ERP modification.