Consider a finance team that rebuilds reports outside the ERP while operations staff re-enter transactions between systems. Management wants to fund a replacement. Before approving it, the CFO, COO and CIO need to establish whether those failures come from missing software capability, poor process design, unreliable integration or insufficient ownership.
Growth and operational friction justify investigation, not automatic replacement. Fund improvement when the current platform can demonstrably support the required workflows. Advance replacement when material constraints cannot be resolved on acceptable terms. Commission further assessment when the cause, economics or organizational capacity remains uncertain.
The investment gate should produce an evidence-backed choice between those paths, not an implementation proposal with replacement already assumed.
Document workflow failures before specifying a new system
Francesco Perrotta identifies inefficient or complex business processes and difficulty integrating existing applications as triggers for considering ERP change. Treat those triggers as the start of a diagnosis. A complaint such as “the ERP cannot support growth” needs to become a traceable description of what fails, under which conditions and with what business consequence.
Ask finance to walk through a recent close, reconciliation or reporting failure. Ask operations to demonstrate a delayed order, inventory discrepancy or purchasing exception. Record the intended outcome, actual result, manual intervention and downstream impact. Distinguish observed consequences from assumptions: delayed invoicing is not automatically lost revenue, and staff time released is not automatically a cash saving.
For each critical workflow, collect the transaction trail, relevant configuration, support history and the business owner's explanation. Then classify the suspected constraint:
- Software capability: the required business rule or transaction cannot be represented.
- Process design: responsibilities, approvals or handoffs are unclear or unnecessarily complex.
- Integration: information does not arrive, arrives incorrectly or cannot be recovered reliably.
- Organizational readiness: users, data owners or decision-makers cannot sustain the intended way of working.
These are working hypotheses, not final labels. If finance says a report is impossible, ask for the required information and a demonstration of the current reporting route. If operations blames integration, trace the failure across applications. The next funding decision should address the demonstrated constraint, not merely the department reporting it.
Test whether the current ERP can accommodate change
Perrotta argues that an external assessment's value lies in an objective evaluation of business processes and a deeper understanding of the company's context. Put that principle into the assessment brief: require a recommendation that can retain the incumbent, rather than commissioning discovery whose only permitted outcome is replacement.
Choose a business-critical workflow and ask the team to demonstrate how the current installation could support it through process changes, configuration, an available module or a bounded integration. Require evidence against the installed version and relevant commercial terms. “The product supports it” is insufficient if the answer depends on an unapproved upgrade, unavailable interface or untested extension.
Hypothetical evaluation scenario: a warehouse application sends shipment confirmations, but finance still corrects invoices manually. A successful message transfer does not establish that the workflow is resolved. Ask the team to demonstrate the business posting, reconciliation, exception handling and recovery ownership. If the ERP can complete the process once the interface is corrected, that supports investigating targeted improvement. If a mandatory business rule remains unrepresentable, the replacement case becomes stronger.
Test future flexibility as well as current fit. In a digital sovereignty webinar featuring ERP-vendor representatives, the speakers propose stress-testing dependencies against regulatory change, acquisitions and changes in supplier strategy. Their concern is not dependence itself, but dependence that removes the company's ability to act. For this investment decision, ask what happens if a required capability leaves the roadmap, access terms change or the business must meet a new obligation.
Record the contractual, technical and operational response for both the incumbent and a proposed replacement. A new platform should not receive an assumption of flexibility that the existing system must prove. Where the proposed remedy involves a lasting extension, use the separate ERP customization approval worksheet to examine that dependency rather than expanding this investment gate into detailed change approval.
Compare improvement and replacement on equivalent terms
Build scenarios around the same required business outcomes and planning horizon. Include retaining the current installation with targeted improvements, replacing it and, where uncertainty remains material, a bounded assessment before either commitment. If re-implementing the existing product is plausible, price it separately rather than hiding substantial reconstruction inside “optimization.”
For the incumbent baseline, ERP Research's cost categories include licences, hosting, support, internal headcount, customization maintenance and workaround costs. Use those categories to avoid comparing a replacement programme with the current licence invoice alone. Add the proposed improvement work and show which existing costs would actually disappear, remain or increase.
For replacement, request explicit estimates for transition work as well as ongoing operation. Digital Advisory's ERP decision playbook identifies staff backfill, migration rehearsals, temporary integrations, integrator travel and change allowance, and stabilization support beyond proposal hypercare as business-case inputs. Treat them as questions to price for your programme, not as universal charges or benchmarks.
For every claimed benefit, state the mechanism and its owner. If replacement is expected to shorten close, specify which reconciliation or approval step changes, what evidence demonstrates that capability and what finance must do differently. Do not count the same released capacity as both a staffing reduction and additional output unless the operating plan explains the allocation.
Make the recommendation conditional. Improvement is credible when it resolves the important failures with acceptable continuing obligations. Replacement is credible when demonstrated capability or dependency constraints outweigh its transition exposure. Further assessment is appropriate when a specific unresolved question could change that choice. Give that assessment a defined output, owner and decision date rather than an open-ended discovery mandate.
Use a decision worksheet, not a synthetic score
The following worksheet is an editorial decision aid, not a validated scoring model. Complete it for each viable scenario. Keep disagreements visible rather than averaging a critical business constraint into an apparently acceptable total.
| Decision area | Evidence to record | Approval question |
|---|---|---|
| Operational impact | Failed workflows, transaction evidence, current effort and business consequences | Which failures will this option resolve, and which will remain? |
| Capability and dependencies | Workflow demonstrations, installed-version checks, interfaces, support terms and roadmap assumptions | Can the business operate and adapt under the proposed constraints? |
| Comparable economics | Current run costs, change costs, transition effort, continuing support and benefit assumptions | Have we compared equivalent scope without assuming benefits are cash savings? |
| Internal capacity | Named process owners, required participation, competing commitments and backfill decisions | Can the business supply the people and decisions this option requires? |
| Transition exposure | Affected operations, temporary arrangements, recovery responsibilities and unresolved continuity questions | What business exposure are executives accepting by funding this path? |
| Evidence still needed | Open questions, responsible owners and the findings that would change the recommendation | Approve now, approve a bounded investigation or defer? |
Attach source documents to the worksheet rather than filling it with assurances. “Users will participate” should become named responsibilities and an agreed allocation of time. “Integration is feasible” should identify the interface, business outcome and unresolved conditions. “Lower operating cost” should reconcile to a cost baseline and an explicit future operating model.
Assign business owners before approving delivery
Perrotta describes underestimated training as a recurring problem in his experience, linking it to ineffective system use and reduced benefits. At the investment gate, the implication is to budget for business participation and learning, not to conduct a premature go-live review. A technically plausible solution still needs people who can define, test and adopt the intended workflows.
Assign finance accountability for the economic assumptions, operations accountability for workflow outcomes and technology accountability for architecture and dependency evidence. Name a business owner for each material benefit and unresolved process decision. Where these responsibilities cross departments, the executive sponsor should resolve the handoff before delivery is funded.
Keep later decisions distinct. Once the investment path is approved, use ERP implementation partner due diligence to verify who will deliver it. Authorization to enter live operation belongs in a later ERP go-live readiness review. Neither should substitute for deciding whether the investment itself is justified.
Before approving delivery, put the leading improvement and replacement scenarios side by side. Require each owner to identify the unresolved finding most likely to reverse the recommendation, then commission that check before committing the larger budget.
If you need functional or technical support to evaluate those scenarios, discuss your workflows, integration constraints and internal capacity with Digiventi's ERP specialists.
