One of the most consequential decisions in any ERP implementation is how to handle the gaps between what the standard system does and what the organization needs. The options are to change the organization’s processes to match the standard, to configure the system using its built-in tools, or to build custom code. Each choice carries implications for implementation cost, system complexity, maintainability, and the organization’s ability to upgrade in the future. Getting these decisions right requires analytical discipline that most projects apply too late and too informally.
The Real Cost of Customization
The cost of a customization is not the development cost — it is the total cost of ownership over the system’s lifetime. A customization built today needs to be maintained as the business changes, retested with every system upgrade, and potentially rebuilt when the platform changes significantly. The organizations that discovered this most painfully were the ones that heavily customized SAP R/3 in the 1990s and faced migration costs that dwarfed the original implementation when they needed to move to S/4HANA. The customizations that seemed justified at the time became the primary obstacle to staying current with the platform.
This does not mean that customization is always wrong — it means that the decision to customize should include a realistic assessment of the long-term maintenance obligation, not just the short-term development cost.
Configuration: Power and Limits
Modern ERP platforms offer extensive configuration capability — workflow rules, approval hierarchies, calculation methods, reporting templates, field-level validations, and organizational structures — that can adapt the system to a wide range of business requirements without custom code. The discipline of configuration is working within these parameters wherever possible and preserving the system’s upgradeability by minimizing what sits outside the platform’s standard architecture.
The limits of configuration become clear when the business requirement involves logic that the platform’s configuration options simply cannot express. When that point is reached honestly — rather than as the default response of a development team that prefers to build — customization is the appropriate response.
The Decision Criteria That Hold Over Time
The decision criteria I apply are three questions. First: is this a genuine business differentiator, or is it a familiar process that happens to differ from the standard? Processes that are truly distinctive create competitive value and warrant investment in customization. Processes that are merely familiar should be adapted to the standard. Second: will the standard approach, with appropriate process change, produce an acceptable outcome for the business? Often, the resistance to standard processes is about familiarity rather than genuine business need. Third: what is the total cost of ownership of this customization over the expected system lifetime? If the answer to this question has not been estimated, the decision has not been fully evaluated.