When customers request changes to a software system, let’s have ERP Systems as a famous example, a fundamental tension often happens between vendor and customer perspectives. In this article, I’ll try to present the view of both sides based on my direct experience in this argument, plus many cases I saw or even contributed to advising. The vendor's position is that such changes should be treated as chargeable change requests that can be refused if risky, and the customer's view is that logical business requirements should be considered standard functionality fixes rather than customizations.
ERP vendors have established business models that rely on revenue streams from both initial implementation and ongoing maintenance. According to Wailgum (2010), vendors typically charge around 22% per year on maintenance contracts, which cover standard support and updates. However, customizations and changes to core functionality typically fall outside this scope and warrant additional charges.
Thiel et al. (2021) emphasize that change requests for ERP systems necessitate substantial resources to be implemented effectively. Their study revealed that "specifying change requests is time-consuming and inefficient," requiring a "detailed description of requirements" and multiple rounds of clarification. This complexity justifies vendors charging for the substantial work involved in properly implementing customer-requested changes.
Furthermore, vendors maintain legitimate rights to refuse change requests that could potentially compromise system integrity. Thiel et al. (2021) note that "unwanted side effects harm the ERP system and require even more costly corrections later," providing a foundation for vendors to reject inadequately specified or potentially harmful modifications. As Panorama Consulting Group (2025) explains, customization introduces substantial risks, including "higher costs, upgrade challenges, and reduced vendor support," giving vendors valid business reasons to refuse certain changes.
This perspective supports the "Software As-Is" View, which holds that "standard" refers to the ERP system as it exists upon delivery. If a client requires a business function not present in the system, or if a desired workflow deviates from the system's default behavior, the answer is straightforward: "That's a customization". Herein is an example:
A specialized logistics company might require a highly specific algorithm for route optimization based on its unique, proprietary regional delivery network. The ERP provides general route planning, but this hyper-specific algorithm isn't part of the core offering. The vendor, adhering to the "as-is" view, would classify the development of this algorithm as a customization.
From the customer's viewpoint, many requested changes represent logical business requirements that should be considered standard functionality rather than customizations. Gujral (2024) notes that customers often seek "tailored" solutions that offer "a closer alignment with specific processes and objectives," viewing these not as optional extras but as essential components of a properly functioning system.
When standard ERP functionality doesn't align with business needs, customers frequently perceive this as a defect in the software rather than a customization opportunity. According to OptiPro ERP (2023), the distinction between configuration and customization is often unclear to customers, who see both as necessary adjustments to make the system work properly for their business. They argue that "the critical difference is the scope of work, time, cost, and training to modify the ERP system based on the business requirements," suggesting that some changes should be considered standard configurations rather than chargeable customizations.
Panorama Consulting Group (2025) acknowledges that there are legitimate scenarios where customizing ERP software is "not only justifiable but essential to maintain competitive advantage," including unique operational models, regulatory requirements, and market differentiation. In these cases, customers reasonably expect vendors to accommodate these needs as part of the standard system functionality rather than treating them as optional extras.
This perspective supports the "Standard Business Practice" View, which argues that an ERP system should, by default, support standard business practices. If the system doesn't offer a straightforward way to process a common real-world scenario, this viewpoint suggests it’s not merely a feature request. Herein is an example:
Imagine a mid-sized retail business implementing an ERP. They discover that while the system handles individual item returns perfectly, it lacks a streamlined process for "exchange orders" where a customer returns one item and immediately purchases another of different value in a single transaction. The customer might see this as a functional gap.
The fundamental conflict arises when what a customer perceives as a logical business requirement (and therefore a bug in the standard system) is viewed by the vendor as a customization requiring additional payment. Gujral (2024) explains that customers often expect ERP systems to align with their "unique needs" and view gaps as deficiencies rather than opportunities for paid customization.
From the vendor's perspective, as Wailgum (2010) notes through his interview with Cahill, vendors view their relationship with customers as a "family" where loyalty is expected, and they should protect the core product from modifications that could compromise its stability for all users. This leads vendors to classify many customer requests as change requests rather than bug fixes.
OptiPro ERP (2023) offers a middle ground, noting that while "most businesses need configuration, some need a combination of customization and configuration," suggesting that vendors and customers must negotiate which changes fall into which category. This negotiation is often where conflict arises, as the line between a bug fix and a change request is subjective and influenced by both technical and business considerations.
The tension between vendor and customer perspectives on ERP change requests reflects different priorities and business models. Vendors have legitimate reasons to charge for and sometimes refuse changes that require significant development effort or pose risks to system integrity. Equally valid is the customer perspective that logical business requirements should be considered standard functionality rather than customizations.
Successful ERP implementations require clear communication and negotiation about which changes constitute bug fixes versus chargeable customizations. Organizations implementing ERP systems should establish detailed agreements about change request processes, including criteria for distinguishing between defects and enhancements, to avoid conflicts during implementation and maintenance phases.
It's all about the what "standard" truly means in the world of Software ERP software. Based on my journey, which included a big diversity in projects size and industries, and navigating both vendor and customer sides, I believe that if these arguments about "standard" versus "customization" are happening frequently, it isn’t a matter of labelling customization as purely "good" or "bad." More likely, it points to an issue in the deal itself, originating from the presales and contracting stages. I faced this challenge several times, and I learned, in a very costive way, that the vendo must make it crystal clear from the preslaes phase, if it’s a standard software or a custom (tailored) solution, and must well define the change management process along with solid examples in the two cases. My final advice to the vendor and customer as well, don’t proceed in the deal if you are not pretty sure of this topic.