An enterprise customization is a claim on future attention. Someone will have to test it when the platform changes, explain it when employees move on, and decide whether its original purpose still justifies its cost. That obligation can be entirely worthwhile. The problem is approving the initial build while leaving the continuing obligation unowned.
The right balance starts with the business variation being requested. Some differences express genuine competitive advantage or an unavoidable operating constraint. Others preserve habits that developed around a previous system. Treating every difference as strategic produces unnecessary complexity. Treating every difference as waste can remove capabilities customers actually value.
A disciplined decision therefore compares the value of a particular variation with the full cost of sustaining it. It also asks where the variation should live. A supported configuration, a separate extension and a modification to core behavior are materially different commitments, even when their screens look similar.
Start with the outcome behind the request
“Keep our current approval screen” describes a preferred implementation. It says little about the business requirement. Ask what the screen enables: faster exception handling, a particular segregation of duties, or perhaps visibility that the new standard workflow already provides differently.
Requestors should describe the customer, employee or control outcome at risk if the company adopts the standard process. Require a recent example. Then test the proposed standard using that example and an awkward exception. This moves the discussion away from familiarity without dismissing the expertise of people who do the work.
A process can be important without being differentiating. Paying suppliers correctly is essential, but a distinctive button layout is unlikely to create commercial advantage. Conversely, an unusual allocation method may be central to a company’s service promise. Importance establishes the need for a reliable outcome; differentiation helps explain why an unusual method might deserve protection.
Legal or contractual requirements need their own evidence. Record the actual obligation, relevant jurisdiction or contract, and the qualified owner who has validated the interpretation. “Compliance requires it” should not be accepted as an unexamined reason to reproduce a legacy workflow. Several designs may satisfy the same obligation.
Distinguish the layers of variation
Configuration uses supported settings to change behavior within the product’s intended operating model. It can still be complex and requires testing, but its maintenance boundaries are usually clearer than an undocumented alteration.
An extension adds a capability through supported interfaces or an explicit extension mechanism. It can isolate specialized logic, but it also introduces dependencies, data movement, monitoring and support needs. Moving code outside the core does not make its cost disappear.
A core modification changes behavior on which the vendor or other modules rely. Depending on the platform, that may complicate upgrades, support or compatibility. The evaluation should establish the actual consequences for the specific product and contract rather than assuming every customization has the same technical risk.
There is also a fourth option: change the business process. Replacing an unusual approval sequence with a supported one may be cheaper and more reliable. But the cost of training, changed responsibilities and any lost operational capability belongs in the comparison. “Standard” is not a synonym for costless.
The strongest designs often combine a stable common process with a narrowly bounded exception. The challenge is defining a boundary that the organization can operate and explain.
Make the ongoing obligation visible
For a proposed variation, ask for an ownership record alongside the build estimate. It should name the business sponsor, technical maintainer, test owner and person authorized to retire it. Define the interfaces it depends on and the circumstances that require review.
Estimate annual effort for regression testing, defect handling, access review, documentation and platform changes. Include the opportunity cost of specialists who cannot work on something else while maintaining the variation. Distinguish a likely recurring cost from uncertain disruption scenarios.
GAO’s 2020 Cost Estimating and Assessment Guide calls for documented assumptions, sensitivity analysis and updates using actual costs. Applying that discipline here means testing what happens if release frequency increases or the original developer is unavailable. This is an application of estimating practice, not a universal pricing rule for custom software.
NIST’s Guide for Security-Focused Configuration Management, published in 2011 and updated in 2019, treats configuration management as an ongoing means of supporting business functionality while managing security and organizational risk. Its federal-system focus differs from commercial ERP selection, but it reinforces why changes require continuing governance rather than a one-time approval.
A hypothetical manufacturer separates three requests
Imagine a manufacturer implementing a common enterprise platform across two plants. Its managers request three variations: a bespoke purchase-approval sequence, a customer-specific packaging calculation and a historical report layout. The company and figures in this example are hypothetical.
The purchasing request preserves five approval steps inherited from an older organizational structure. Interviews show that two approvals do not change decisions and one duplicates a control performed elsewhere. The standard workflow can preserve the necessary authority limits and segregation of duties with fewer steps. Leadership accepts the standard process after control owners validate it and supervisors test urgent purchases.
The packaging calculation is different. Several customers order products in combinations that require a particular carton selection and labeling sequence. The team demonstrates that the standard packing logic cannot produce the required outcome without repeated manual intervention. It compares a supported extension with changing the customer offering. Commercial leadership confirms that the packaging service remains part of the intended proposition.
The proposed extension would cost $48,000 to build and $12,000 annually to maintain. A manual alternative would consume an estimated 1,500 hours per year at a loaded rate of $32 per hour, or $48,000 of capacity value. On those assumptions, the extension offers $36,000 in annual value after maintenance, giving a simple undiscounted payback of approximately sixteen months. The case must still establish that the released capacity has a useful destination. It is not automatically a payroll reduction.
The team also tests a downside case. If only 750 hours are eliminated, annual capacity value falls to $24,000 and net value to $12,000; simple payback becomes four years. That sensitivity changes the approval. The company first builds a limited prototype using representative orders and measures actual handling time before funding the full extension.
The historical report layout has little operational justification. Users want it because a longstanding monthly meeting is organized around its columns. Rather than recreate it indefinitely, the finance lead pilots a standard report and changes the meeting agenda. A temporary export is permitted for two reporting cycles with an explicit retirement date.
One program has made three different choices: standardize, test an extension and allow a time-limited bridge. The decisions follow different evidence, not a blanket preference for or against customization.
Use a variation record rather than a popularity contest
A practical decision record can be short. The following questions form a working heuristic, not an accredited framework or a validated scoring model.
- What business outcome requires the variation, and what evidence demonstrates the gap?
- What happens if the company adopts the standard process instead?
- Which supported configuration or extension options have been tested?
- What does the variation cost to build, operate, test and eventually remove?
- Who owns its business value, controls and technical maintenance?
- What event would trigger redesign or retirement?
Include dissenting views and assumptions. A decision supported by four managers and opposed by one knowledgeable operator may still contain a serious flaw. Voting is a poor substitute for testing the operator’s concrete concern.
Use mandatory constraints as gates. A design that cannot satisfy an essential control should not win because it scores well on usability and cost. For discretionary trade-offs, qualitative comparison can be more honest than assigning arbitrary decimal scores. The point is to make the reason for the decision inspectable.
Approve the smallest variation that addresses the demonstrated requirement. If a request affects only one customer segment, avoid changing every order’s processing path unless the broader design is simpler and demonstrably safe. Narrow scope reduces the number of assumptions that must remain true.
Give exceptions an expiry mechanism
Temporary customizations tend to become permanent when retirement depends on someone remembering why they exist. Record the removal trigger at approval: the end of a transition, availability of a supported capability, termination of a contract, or disappearance of the business benefit.
Review the inventory of variations at release planning and budget time. Ask which are actually used, which duplicate new standard functionality and which no longer have an owner. Usage alone does not prove value, but non-use is a strong reason to investigate.
Retirement also requires care. A seldom-used control or annual process may be important. Trace dependencies, preserve necessary records and test the replacement before switching it off. Removing a customization should be a controlled business change rather than a code-cleaning exercise.
For continuing variations, refresh documentation around decisions and boundaries. A large technical specification is less useful than a maintainable explanation of purpose, dependencies, failure behavior and acceptance tests. New support staff need to understand what must remain true, not just which files were changed.
Standardization can go too far
Central teams can mistake consistency for operational quality. A process designed around one division may impose extra effort on another with different products, volumes or service commitments. If the standard creates persistent workarounds, the organization should investigate the standard rather than treating every workaround as resistance.
There is also a legitimate experimentation case. A new business model may need a temporary capability before leadership knows whether it deserves enterprise-wide investment. A bounded experiment with isolated data, controlled permissions and a clear exit can be more sensible than delaying learning until the enterprise template catches up.
The counterweight is transparency. Experiments need owners, spending boundaries and a review date. Local teams should not quietly turn a trial into critical infrastructure while central teams continue to classify it as optional.
The balance will change over time. A variation that was commercially valuable can become routine. A standard process that once fit the company can become a constraint. Strong governance allows those judgments to change without treating either standardization or customization as an ideology.
The final decision should be explainable in one sentence: this variation earns its continuing cost because it produces this outcome, and this person will verify that it still does. If the organization cannot complete that sentence, the build request is not ready for approval.
