Your ERP is a system of record. It is not the entire workflow.
Companies often need a missing operational layer, not a costly enterprise software replacement.
COO, CIO, Operations Director
The argument in brief.
The workflow crosses documents, customer messages, supplier conditions, people and systems. An ERP is designed to be authoritative for certain records. It is not always the right interface for every exception, collaboration or approval. Replacing it because the workflow is awkward risks discarding valuable logic while failing to solve the coordination problem.
Put the idea under realistic pressure
Imagine an order with an unavailable part. An assistant can suggest a substitute from approved data, but an authorized employee must confirm it. The exception console writes a reviewed change to the ERP using an idempotent request and records the source document and user decision. If the ERP is temporarily unavailable, the system retains pending state and can reconcile later.
Read the reasoningWhen the recommendation changes
There are cases where the ERP genuinely lacks required data integrity, flexibility or support. Then modernization or replacement may be necessary. The decision should follow documented risk and cost, not frustration with one interface.
Read the reasoningThe reasoning behind the recommendation.
A company buys a sophisticated ERP and still runs the most critical exception process through email. This is not automatically a failure of the ERP. The platform may record orders accurately while the work that turns an unusual request into an approved transaction happens elsewhere.
The decision behind the technology
The workflow crosses documents, customer messages, supplier conditions, people and systems. An ERP is designed to be authoritative for certain records. It is not always the right interface for every exception, collaboration or approval. Replacing it because the workflow is awkward risks discarding valuable logic while failing to solve the coordination problem.
A better way to frame the work
Map the actual transaction first: trigger, evidence, validation, human decision, approved state change, reconciliation and recovery. Identify where the records should live and where the user needs a task-focused view. The missing software might be a small exception-management application with API integration, not a replacement ledger.
Put the idea under realistic pressure
Imagine an order with an unavailable part. An assistant can suggest a substitute from approved data, but an authorized employee must confirm it. The exception console writes a reviewed change to the ERP using an idempotent request and records the source document and user decision. If the ERP is temporarily unavailable, the system retains pending state and can reconcile later.
When the recommendation changes
There are cases where the ERP genuinely lacks required data integrity, flexibility or support. Then modernization or replacement may be necessary. The decision should follow documented risk and cost, not frustration with one interface.
What to decide before moving forward
Choose a recurring workflow, list systems of record, identify the real exception cost, and design one end-to-end slice. Test duplicate events, authorization and reconciliation before scaling.
References and context
Source notes
References supplied with this manuscript. Source scope and limitations are retained; inclusion is not an endorsement of every claim.
- 2026 Middle Market AI Survey RSM
Do not generalize to all middle-market firms; cross-sectional self-report; use survey date.