An ERP steering committee can approve every design document and still leave the business unprepared for the system it has bought. The missing decisions are often ordinary: who may override a customer credit hold, which warehouse owns a disputed stock balance, when a purchasing exception needs commercial approval, and who will stop a local workaround after launch.
Those decisions determine how work moves and who carries its consequences. Software gives them operational force. Treating them as configuration questions delegates business policy to whoever happens to be answering the implementation team’s questions.
For a CEO or CIO, the practical implication is clear: fund and govern an ERP program around changes to the operating model. Maintain rigorous technical delivery, but make business decisions, operational readiness, and benefit ownership explicit conditions for progress. An implementation that reproduces an unresolved organization can make that organization’s problems more consistent and harder to escape.
The real unit of change is a business commitment
A department usually describes its own activities accurately. Finance needs postings, procurement needs purchase orders, and operations needs stock movements. The difficulty lies in commitments that span them. A customer order becomes a promise about availability, price, credit, delivery, invoicing, and resolution when something goes wrong.
No single screen contains that promise. Its integrity depends on coordinated rules and timely evidence across the entire transaction. If sales can promise an unapproved delivery date while operations remains accountable for delivery performance, a better order-entry screen does little to correct the underlying conflict.
This is why process redesign deserves attention before detailed configuration. The US Government Accountability Office’s reengineering guide connects customer needs and performance problems with strategic goals, organizational change, risk, and implementation of new processes. It is public-sector guidance rather than evidence that a particular ERP method guarantees success, but its scope is instructive: technology decisions sit within a wider business change. GAO, Business Process Reengineering Assessment Guide.
Start by choosing a small number of commitments whose failure matters commercially: fulfilling a confirmed order, paying an approved supplier invoice, closing a legal entity’s accounts, or placing replenishment stock where it is needed. Describe success from the recipient’s perspective. Then work backward to the decisions, information, controls, and roles needed to keep that commitment.
Diagnose what the software cannot decide
Before approving a future-state process, examine three kinds of unresolved choice.
First, identify policy disagreements. Two branches may use different discount approvals because their economics differ, or because nobody has challenged a historical practice. The implementation team cannot tell which explanation is correct from the workflow alone. A commercial owner must determine the justified variation and document its boundary.
Second, identify authority gaps. A process owner may be accountable for cycle time without authority to change another department’s queue. Naming that person on a project chart will not resolve the problem. Specify which decisions the owner can make, which require a peer agreement, and where the executive sponsor must arbitrate.
Third, identify capacity assumptions. A new control can be sound in principle but impossible to operate at peak volume. If the design sends every price exception to one finance manager, test the arrival pattern, approval time, absence cover, and escalation route. A training plan cannot compensate for an approval queue that has insufficient capacity.
Document these choices in a decision register with an owner, deadline, evidence, affected processes, and consequence of delay. A decision that remains open should remain visible as a business risk. It should not quietly become a technical assumption buried in configuration notes.
Use a commitment-to-control chain
The following is a working heuristic for structuring ERP decisions, not an industry standard or a maturity certification. For each priority business commitment, connect five elements: outcome, decision, owner, control, and evidence.
The outcome describes the useful business result. “Reduce manual activity” is too loose. “Release approved replenishment orders before the supplier’s daily cutoff” gives the team a recognizable operational target. Establish the current situation before setting an improvement goal.
The decision identifies the judgment that changes the transaction’s state. For replenishment, this might be whether suggested quantities can be released automatically or must await review. Separate the normal decision from exceptions involving uncertain demand, minimum order quantities, or supplier constraints.
The owner has authority to maintain the rule and resolve disagreements. Assign an operational deputy so the process does not become dependent on one person’s availability. Technical support owns system faults; it should not become the default owner of disputed purchasing policy.
The control prevents or detects an unacceptable result. Controls may include approval limits, duplicate checks, segregation of duties, or reconciliation. State whether a control blocks work or alerts someone after the event. A warning nobody owns is an observation, not an effective response mechanism.
The evidence demonstrates that the commitment was met and the control worked. Specify the originating record, timestamp, exception reason, and report owner. Decide how late-arriving information and reversals will be treated. This avoids a benefits discussion in which each department brings a different definition of success.
The chain exposes missing links early. An outcome without an owner is an aspiration. A control without evidence is difficult to evaluate. Evidence that nobody uses can become expensive reporting overhead. Configuration should implement a coherent chain rather than an isolated collection of requested features.
A distributor redesigns its credit-release decision
Consider a hypothetical industrial distributor with three branches. Sales staff accept orders locally, a central finance team manages credit, and warehouse teams release goods. Customer balances are reconciled overnight. Sales sometimes asks warehouse supervisors to ship urgent orders before a credit decision is recorded.
The ERP team’s first proposal is to automate credit holds and route exceptions to finance. That sounds reasonable, but it leaves important questions unanswered. Does finance need a current balance or an independently confirmed payment? Can a branch manager authorize a small exposure increase? What happens when a customer has a disputed invoice but no wider payment concern?
The business instead maps its delivery commitment and agrees separate release paths. Orders within an approved limit and with sufficiently current balance information follow the normal route. A disputed invoice creates a case that a named credit analyst reviews. A request to exceed the limit requires a commercial approver within an explicit authority boundary. Missing or stale balance data produces a different exception from a genuine credit breach.
These distinctions matter. If all holds enter one queue, the urgent data problem looks like a slow credit decision. If all overrides share one reason code, management cannot tell whether the policy is too restrictive or whether staff are bypassing it.
The hypothetical pilot uses a defined set of customers, including accounts with split deliveries and credit notes. For each held order, the team records when the hold began, why it occurred, who accepted the exception, and whether shipment happened before recorded approval. The design also covers an approver’s absence and a balance-feed failure.
No improvement is assumed in advance. Faster release is valuable only if unauthorized exposure, customer disputes, or rework do not increase. The pilot therefore compares release time alongside unauthorized releases, aging exceptions, and time spent resolving incorrect holds. The business may discover that the largest bottleneck is payment matching rather than approval. That finding should change the program’s priorities before a wider rollout.
Fund the transition as real operating work
ERP budgets often show a project team and a training allocation while assuming that operational experts can contribute indefinitely alongside their normal jobs. The plan then relies on the very people whose knowledge is hardest to replace.
Create a capacity plan by role and period. Distinguish design participation, data correction, scenario testing, training preparation, cutover support, and early-life operational cover. A warehouse supervisor who attends design workshops may also be needed for stock verification and peak-season operations. Counting that person once in each separate plan conceals the collision.
Budget for backfill where needed, and let business managers choose what work will pause. Treat data stewardship as an ongoing responsibility. If item attributes drive replenishment or customer classifications drive approval routes, somebody must maintain those attributes after the consultants leave.
The same discipline applies to benefits. Each expected gain needs an owner and a mechanism. Time saved becomes economic value only when the business uses the released capacity, avoids a future cost, improves service, or removes a constraint. Do not add hypothetical labor savings to a business case while assuming every existing activity and staffing pattern will continue unchanged.
Make readiness a business decision
A successful technical test does not prove that the organization can operate. Readiness should include completed business scenarios, reliable opening data, trained deputies, support capacity, and clear decisions about temporary limitations.
Test ordinary transactions and awkward ones: partial receipts, returned goods after invoicing, a changed tax treatment, a departed approver, an order cancelled after picking. Select scenarios from the business’s actual risk profile rather than using an arbitrary large test count as reassurance.
Continuity planning also belongs in the business conversation. NIST’s contingency-planning guidance connects information-system recovery with organizational resilience and the system life cycle. For an ERP program, the useful implication is to decide which operations must continue during a disruption and how they will be restored and reconciled. This application is a recommendation, not a claim of NIST certification. NIST SP 800-34 Revision 1.
A manual shipping fallback, for example, needs authorized users, numbered records, a boundary on duration or volume, and a method for entering transactions without duplication when service returns. “We will use spreadsheets” is not enough. Equally, rollback can become impractical once external payments or physical deliveries have occurred. Identify that boundary before cutover.
Transformation needs limits
Not every ERP replacement should become an enterprise-wide redesign. An unsupported system may require a tightly scoped replacement before an ambitious operating-model change is feasible. Regulatory deadlines, acquisition commitments, or fragile infrastructure can make a conservative first release rational.
In that situation, distinguish deliberate continuity from accidental replication. Record which processes will remain, why they remain, the temporary cost or risk, and when the decision will be revisited. Avoid pretending that every legacy behavior is strategic differentiation.
A wider transformation also has a change-capacity limit. Attempting new pricing policy, a new distribution model, and a new ERP simultaneously may make it impossible to identify the cause of problems. Sequence changes when the business needs a stable comparison or cannot support multiple transitions. The objective is a sustainable operating improvement, not the largest possible change agenda.
What the buyer should require
Ask implementation partners to explain how they surface unresolved business decisions, not just how they configure modules. Request evidence of scenario-based testing, decision traceability, operational handover, and a clear division between policy ownership and technical delivery. In commercial proposals, examine who performs data correction, who supplies business experts, and what assumptions determine the schedule.
Ask the internal sponsor four questions before the next funding decision: Which business commitment will improve? Who can change the rules that govern it? What evidence will demonstrate improvement? What must the organization stop doing to make the new process work?
If those answers are missing, more detailed configuration will create an appearance of progress while increasing the cost of later decisions. A well-governed ERP program makes those choices early enough to influence the system, then keeps measuring them after launch. That is how enterprise software becomes a durable change in the way the business operates.
