What to Consider Before Customizing Your ERP. Include testing, support and future ownership in the decision.
Before approving an ERP customization, ask who will explain it during an operational incident two years from now. That person may need to diagnose a failed transaction, determine whether a recent change is involved, and restore service without the original project team.
If the proposed design has a build estimate but no credible answer to that question, the decision is incomplete. The organization is approving a continuing obligation whose owner has not been established.
A customization decision record should therefore evaluate business value alongside testing, support, release validation, recovery, and retirement. The framework below is a practical review tool. It does not assume that customization is always wrong or that supported configuration is always sufficient. It asks the organization to own the full choice.
A request often arrives as a solution: add a field, recreate a report, change an approval screen, or copy an old calculation. Start by describing the business result and the consequence of failing to achieve it.
For example, a hypothetical manufacturer asks for a custom release screen. The underlying need is to prevent a production order from progressing until the required inspection evidence has been accepted by an authorized role. The screen is one possible response. The decision should begin with the control and operating outcome.
Record who needs the result, which transactions it applies to, and what evidence would demonstrate success. Identify any required policy or specialist interpretation. If the request is motivated by familiarity, investigate the usability concern rather than presenting familiarity alone as a business requirement.
This reframing gives the team permission to compare real alternatives. It also creates acceptance criteria that remain meaningful if the implementation approach changes.
Examine process change, supported configuration, extension, integration, and customization. The terms can be used differently across organizations, so define them for the review and document the actual technical boundaries involved.
Process change may meet the need by altering roles or sequence. Configuration may use supported settings within the application. An extension may add behavior through a defined mechanism. An integration may place a capability in another service or system. Customization may modify or replace behavior beyond the preferred standard design.
These options are not automatically ordered from safe to risky. An apparently simple integration can create difficult ownership and recovery questions. A configuration can enable a poorly controlled process. A narrowly scoped modification may be justified if the alternatives cannot meet a necessary outcome.
For each credible option, test business fit, control implications, supportability, data responsibilities, and the effect of future changes. Exclude an option with a reason supported by evidence. Avoid claiming that a standard feature will work before somebody has demonstrated the relevant scenario.
Identify the business owner who remains accountable for the outcome and the technical or service owner responsible for sustaining it. They may be different people. Both should understand the proposed design and the recurring work it creates.
The service owner should be able to answer:
A support team name alone is not enough. Confirm that the team accepts the scope, has an appropriate access model, and can obtain the required expertise. Where external support is involved, the organization still needs an internal owner for priorities, acceptance, and continuity.
If no team can sustain the change, treat that as a design constraint. It may require a simpler option, a revised support arrangement, or postponement. Do not bury the ownership gap inside a general risk statement while approving the build unchanged.
Separate initial delivery from lifecycle obligations. A build estimate may cover development and initial tests while omitting release checks, support training, monitoring, documentation maintenance, and eventual removal.
Use a lifecycle work list rather than forcing uncertain costs into a single precise number. Identify the task, its trigger, estimated effort where defensible, required skills, and the team that will perform it. Record assumptions so later reviewers can see why the estimate changes.
For the hypothetical release screen, the obligation might include retesting inspection roles whenever access rules change, validating behavior after an application update, and checking that new inspection types cannot bypass the intended approval. These are illustrative responsibilities, not a prescribed technical design.
Compare alternatives using the same time horizon and scope. Counting years of support for one option but only initial delivery for another creates a biased decision. Where evidence is incomplete, give ranges or describe the unresolved work explicitly.
Also consider opportunity cost. Maintaining a special behavior can consume the same specialists needed for broader improvements. The business owner should know what capacity the approved option requires.
A custom behavior should leave enough evidence for an authorized support team to understand what happened. Define which events matter, which identifiers connect the records, and what information can be retained under applicable privacy and retention requirements.
The practical questions are straightforward: did the transaction reach the custom step, which version of the rule applied, what result was produced, and what happened next? The appropriate implementation depends on the system and risk. Avoid recording sensitive data merely because it would make debugging convenient.
Define recovery separately from diagnosis. Can the failed step be safely retried? How will the team identify an already completed action? What happens to partially processed work? Which corrections require business approval? How is the resulting state reconciled?
A manual fallback needs the same care. Describe when it may be used, who authorizes it, what evidence is retained, and how work returns to the normal process. “The team can handle it manually” should prompt a design discussion, not close one.
Use a concise record with links to the detailed design and estimates. Include:
Keep the record accessible after implementation. Connect it to the requirement, approved design, test evidence, and support instructions. If a later team cannot find why the behavior exists, it will struggle to distinguish essential business logic from obsolete complexity.
A decision can be conditional, but its conditions must be executable. For example, detailed design may proceed while final build approval waits for a support owner to accept the operating scope. Say exactly what may continue and what remains blocked.
Before approval, give the proposed service owner a hypothetical failed transaction and the draft operating instructions. Ask them to locate the relevant evidence, identify whether a business or technical decision is needed, and explain the permitted recovery. The exercise should use only access the support role will actually have.
If the answer depends on an undocumented query, a project specialist's memory, or an unapproved ability to change records, the handover has exposed unfinished design. Assign those gaps and verify the revised procedure. The goal is a support arrangement that works under ordinary conditions, including absence of the person who built the customization.
Record when the customization should be reconsidered. A standard capability may later meet the need. A policy may change. The transaction volume may shrink, or the business activity may end. These events can make continued maintenance unnecessary.
Retirement itself requires design. Identify affected data, historical interpretation, open transactions, reports, interfaces, access, and operating instructions. Determine how the business will verify that the replacement or removal preserves the required outcome.
Avoid treating “no longer used” as sufficient proof. Some controls or periodic processes run infrequently. Ask the business owner to confirm the scope and inspect the evidence before removing behavior through an authorized change process.
The strongest customization decision is one the organization can still explain after the project closes. It states why the change exists, who sustains it, how it is tested and recovered, and when it should end. Approving those obligations together gives the business a much clearer view of what it is choosing to own.