Minimizing ERP Modification Cost
Various research found that one of the key success factors of ERP implementation is to minimize the amount of modification. The complexity of modification can cause the organization to over budget and passed the go-live date. Previous research stated that high level of modification is the main cause of ERP implementation failure. Therefore, out of argument who believe in ERP modification, they also argue the modification should be kept as minimum. The organization is supposed to create a change to solve the actual misfit rather than perceive misfit. Having rigorous customization request management help the organization to be more selective in granting modification request. This 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 include an important person for the approval. The key point persons need to be in the loop for the approval decision at least include; consultant or expert who will make the modification, supervisor or head of respective department who request the change, IT manager as the owner of ERP system, and project manager who responsible in the succession of ERP implementation. Proposing a white paper about risk-impact analysis document will help top management to make a decision of requested modification. The risk-impact analysis should be made not only considering implementation stages, but also maintenance and upgrade stages.
Ehsary (2010) developed a matrix table to measure the cost of maintenance from modification activity. It combines list of maintenance activities and cost dimensions. Maintenance activities are activities that happened in post go-live phase, such as; bug fixes, user support, training, and upgrade. While cost dimensions are divided into three categories namely; Product and Services, People, and Process Products and services as a cost for product or services which organization receives an invoice that needs to be paid. People is a cost spent by internal IT personnel on maintenance activities. While process is indirect cost as a result of downtime, for example, training time regarding the modification for the user. Adopting that matrix table, we develop a matrix table that is specifically used for measuring the cost of modification in each different stage.
Table 3 Matrix of Modification Cost
| Modification name & stages | Cost of Dimension | Cost | ||
| Product & Services | People | Process | ||
| Input Data Modification | ||||
| Implementation | $ | $ | $ | High |
| Maintenance | $ | $ | $ | High |
| Upgrade | $ | $ | $ | High |
| Process Modification | ||||
| Implementation | $ | $ | $ | Medium-High |
| Maintenance | $ | $ | $ | Medium-High |
| Upgrade | $ | $ | $ | Medium-High |
| Output Data and Interface Modification | ||||
| Implementation | $ | $ | $ | Low |
| Maintenance | $ | $ | $ | Low |
| Upgrade | $ | $ | $ | Low |
| Environment Modification | ||||
| Implementation | $ | $ | $ | Low |
| Maintenance | $ | $ | $ | Low |
| Upgrade | $ | $ | $ | Low |
Source: Wijaya et al., (2021)
List of maintenance activities are adapted to be a list of modification phase, such as implementation, maintenance, and upgrade. While three cost dimensions are used as it is to measure costs of modification in every phase. To get a complete view of the total cost of modification, all cost dimension in the matrix should be evaluated critically. 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. Based on Celar et al. (2011) research, scheduling ERP modification wisely will allow the organization to have a shorter duration and cost reduction of implementation. One of the methods to do that is by dividing the modification into two phases; before go-live and after go-live, then minimizing the amount of modification before go-live (Celar et al., 2011). Minimization customization before go-live certainly will shorten implementation time and reduce the riskiness of the implementation. However, it is important to prioritize and implement all crucial modifications prior to go-live date to ensure that the required modification can be successfully implemented and the system can work properly. The organization could make this prioritization to be more systematic, for example by using AHP (analytical hierarchy process) method (Parthasarathy and Daneva, 2104; Parhizkar and Comuzzi, 2015; Wei et al., 2015).
Reference:
Wijaya, M. I., Suzanna, & Utomo, D. (2021). Enterprise Resource Planning Modification: A Literature Review. ComTech: Computer, Mathematics and Engineering Applications, 12(1), 33-43. https://doi.org/10.21512/comtech.v12i1.6610
Suryanto, Agustinus Dimas Angga. (2018). Changeability of ERP Systems (Master’s Thesis). Radbound University
Haines, M. N. (2009). Understanding enterprise system customization: An exploration of implementation realities and the key influence factors. Information Systems Management, 26(2), 182–198. doi: 10.1080/10580530902797581
Westrup, C., & Knight, F. (2000). Consultants and enterprise resource planning (ERP) systems. Proceedings of the 8th European Conference on Information Systems.
Ehsary, A.S. (2010). Designing and validating an instrument to measure the degree of customization and cost of use and maintenance for a packaged ERP system (Master’s Thesis). Eindhoven University of Technology.
Celar, Stipe & Mudnic, E. & Gotovac, Sven. (2011). Interrelation between ERP Modification and Modification Scheduling: Four SME Case Studies in Croatia. Strojniski Vestnik.57, 27-30. doi: 10.5545/sv-jme.2010.026