Which Local Processes Should Your ERP Keep? Keep differences that serve a clear business need.
A local process can protect a real business need or preserve a habit whose original purpose has disappeared. The steps may look equally important to the people performing them. An ERP design team needs a way to tell the difference without assuming that either uniformity or local preference is inherently correct.
Evaluate the outcome the variation protects, the evidence that it is needed, and the cost of keeping it operational. Then choose a disposition: retain, configure, redesign, or retire.
This article proposes a process-variant review card and a decision path for that choice. The method is intended for operating-model design. It does not decide legal, accounting, or regulatory requirements, which require review by the appropriate accountable specialists.
“Region B works differently” is too vague to evaluate. Identify the specific event, step, rule, data element, approval, or timing requirement that differs from the proposed common process.
A variant might involve a delivery confirmation before billing, an additional quality release, a different replenishment calendar, or a separate approval threshold. Several differences can coexist in one location without sharing the same rationale. Assess them individually before deciding whether the location needs a separate process.
Describe the current variant and the proposed common approach using the same business event. This makes the difference observable. If one description covers normal orders and the other covers emergency orders, the comparison will mislead the reviewers.
Record who uses the variant, how often the relevant situation arises if verified data exists, and which downstream teams depend on it. Where frequency is unknown, say so and assign a short evidence-gathering task. A confident anecdote is a useful lead, not a complete business case.
The strongest test of a variant is the consequence of removing it. Ask the owner to describe a realistic transaction that would become unsafe, noncompliant, unserviceable, or commercially unacceptable under the common process.
Separate four kinds of explanation:
These categories organize the inquiry; they do not automatically decide it. A genuine external obligation may require a different output without requiring the current sequence of steps. A preference may reveal a usability problem that deserves attention even if the local workflow should change.
Ask for evidence at the right level. A claimed reporting obligation needs the specific requirement and accountable interpretation. A warehouse constraint needs an operational demonstration. A commercial requirement needs the approved commitment and the customers or transactions to which it applies.
Do not begin by asking whether the current steps can be reproduced. Ask whether the common process can achieve the required result with acceptable controls, workload, and timing.
In a hypothetical distribution business, one location insists on a separate dispatch approval because shipments leave through a shared loading area. The underlying need is to prevent release of the wrong goods. The review should test whether the common confirmation process provides adequate identification and release control in that physical setting. If it does, preserving the extra approval may add work without preserving a distinct benefit.
The opposite result is also possible. If the shared loading arrangement creates an unaddressed risk, removing the local step without an alternative would be a poor design decision. The evidence should determine which conclusion applies.
Use realistic scenarios and involve the people who will operate the result. A design that succeeds only with an expert narrating every step has not yet demonstrated practical fit.
Retain means the distinct operating behavior is justified and approved. It needs a named owner, defined scope, controls, test coverage, and a review condition. Retention should not imply that every detail of the current implementation survives unchanged.
Configure means the shared process can meet the outcome through supported settings or parameters without a separate operating design. Confirm the configuration's actual behavior, limits, and downstream effects rather than assuming that a configurable feature is automatically suitable.
Redesign means the need is real, but the present method is a poor way to meet it. The team develops another workflow or control, then tests whether it protects the outcome with acceptable effort and risk. This may include changing responsibilities or resolving a physical constraint.
Retire means the variation no longer protects a justified outcome, or its need is adequately met by the accepted common process. Retirement requires transition work: update instructions, remove obsolete access or forms as authorized, train affected people, and check that parallel workarounds have not persisted.
The four outcomes are practical labels, not a ranking of virtue. A well-governed retained variant can be a better decision than a common design that fails the operation. The objective is justified variation with visible consequences.
Review the recurring work created by each option. Include testing, training, support, reporting, controls, integration behavior, release validation, and any specialist knowledge required. Identify which teams bear that work and whether they have capacity.
Some costs can be estimated numerically. Others are better expressed as concrete obligations until evidence improves. “Every change to dispatch requires an additional location-specific scenario and local sign-off” can be more honest and actionable than a speculative lifetime cost.
Look for interactions. Two individually simple variants may conflict when a transaction crosses locations. A different approval sequence may affect a common report or a shared service team. Ask who must understand the variation to process, support, or reconcile the work correctly.
Also assess the cost of removing the variant. Standardization can shift work to another team, introduce manual exceptions, or reduce a service capability. The review should compare whole-process consequences rather than crediting one team for reducing its own complexity.
Use one card for each material difference. Keep evidence accessible and give unresolved claims an owner.
Require the decision to identify both a business owner and the party responsible for maintaining the implementation. A regional leader may sponsor the need while a shared service team operates the exception. Both need to understand what has been approved.
A conditional approval can keep design moving while a narrow uncertainty is resolved. State the condition, evidence owner, deadline, and work that may proceed in the meantime. Do not approve an unlimited exception “pending further review.”
For the hypothetical dispatch variation, a limited approval might allow the additional release step for the first location while an operational test evaluates the common alternative. The condition should identify who can authorize retirement, which evidence they need, and what happens if the test is inconclusive.
If the variant protects a mandatory obligation, do not use an expiry date to remove protection automatically. The review date should force a decision, with a defined continuity arrangement if the review is late. Expiring an administrative approval is different from deciding that the business need has disappeared.
A variant approved for one operating condition may become unnecessary or inadequate later. Relevant triggers include a facility change, revised policy, new service commitment, shared-service consolidation, or a release that changes the common process's capabilities.
Keep the review connected to those events. Ask whether the original evidence remains true, whether the variant still performs as intended, and whether a simpler accepted option now exists. Conversely, check whether the variation has expanded beyond its approved scope.
At the end of a review cycle, the organization should be able to explain why each surviving difference exists and who sustains it. That is the useful result of standardization work: a common operating model whose exceptions have reasons, boundaries, and owners that remain visible after the implementation team leaves.