ERP Assurance - Frequently Asked Questions

ERP programme assurance is the practice of providing independent oversight of a large-scale ERP transformation — separate from the system integrator (SI) and separate from the internal project team. Its purpose is to give programme sponsors, finance directors, and steering committees an evidence-based view of whether the programme is delivering what it promised, at the pace it promised, and with the governance structures needed to withstand external scrutiny.Assurance is distinct from project management. A project manager works within the programme to drive delivery. An assurance adviser works alongside the programme to provide an honest assessment of it — including where delivery is at risk, where the SI's reporting does not reflect reality, and where governance gaps could cause problems at audit or go-live.The value of assurance is most visible when something goes wrong and an independent view is needed quickly. Its real function is making that conversation unnecessary — by identifying risk early enough to act on it.

Most ERP programme failures share a common root cause: the people accountable for the outcome were not receiving an accurate picture of programme health until it was too late to course-correct. This is not always the result of deliberate concealment. SIs are under pressure to report positively. Internal teams lack the experience to challenge SI claims. And steering committees are often reading RAG reports that reflect sentiment rather than evidence.The most visible recent UK example is Birmingham City Council's Oracle ERP programme, whose costs escalated from an initial £19m towards an estimated £216m by 2026 (Sheffield University's Audit Reform Lab). Independent analysis identifies the Oracle failure as a material factor behind the council's 2023 Section 114 notice — though the council formally cited its ~£700m equal-pay liability as the headline cause.The programme's difficulties were not sudden — they accumulated over years of under-challenged delivery and inadequate governance. Independent assurance breaks this pattern by ensuring that someone without a stake in the SI's success is reading the actual evidence: test results, data migration progress, training completion rates, workaround registers, and change log activity. Assurance does not prevent problems — it ensures that problems are visible, named, and acted on before they become crises.

Assurance adds value at every stage of the ERP lifecycle, but the return on engagement is highest at two specific points.The first is before go-live, during the three to six months when test coverage, data readiness, training completion, and cutover planning converge. This is the period most likely to be compressed under schedule pressure, and the one where gaps in any of these areas cause go-live failures. An independent review at this stage — focused on evidence rather than status reports — surfaces issues while there is still time to resolve them.The second is in the twelve months after go-live, during what is often called the stabilisation period but frequently becomes a period of unmanaged regression risk. As Oracle releases its quarterly updates, configurations change, integrations break, and workarounds accumulate. Without assurance, this period is managed reactively. With it, the quarterly update cycle becomes a governed process with a clear pass/fail threshold and evidence-based sign-off.Engaging assurance at procurement stage — before the SI is selected — is the ideal starting point, but most organisations engage it when a programme is already in difficulty. Both are valid; the earlier the engagement, the lower the intervention cost.

A system integrator's internal quality assurance (QA) function exists to protect the SI's delivery reputation and manage its contractual obligations. It is not independent — it reports into the SI's delivery structure and is incentivised to present delivery positively.Independent ERP assurance sits on the client's side. It has no financial relationship with the SI and no interest in the programme appearing healthier than it is. Its output — findings, recommendations, and risk escalations — goes directly to the programme sponsor or finance director, not through the SI.In practice, this distinction matters most when there is a discrepancy between what the SI is reporting and what the client team is experiencing. An independent adviser can name that discrepancy explicitly and recommend contractual or governance remedies. An SI's own QA function cannot.The 3-in-a-Box governance model — where the client, SI, and an independent adviser operate as three distinct voices in programme governance — is designed specifically to prevent the SI's reporting from going unchallenged. Without the third voice, the client is effectively relying on the SI to mark its own homework.

Five indicators that independent assurance is warranted.First, the programme team's confidence in go-live readiness is based on the SI's own reporting rather than independently verified evidence. If your steering committee cannot point to evidence that key milestones have been validated by someone other than the team delivering them, this is a governance gap.Second, workarounds are accumulating without a managed register. Workarounds sanctioned in month one become audit findings in month twelve. If nobody owns the workaround register and reviews it regularly, the programme is carrying unquantified risk.Third, test coverage is being reported as complete but your internal team has not seen the test results. Pass rates, test scope, and regression coverage should be visible to the client, not just the SI.Fourth, the programme is post-go-live and the quarterly update cycle is being managed reactively — with manual testing, stretched consultant resource, and no formal sign-off threshold.Fifth, the programme has missed milestones and the recovery plan was produced by the same team that missed them. An independent review of a recovery plan is a basic governance step that is frequently skipped.If any of these apply, the cost of independent assurance is a fraction of the cost of the problems it prevents.

In practice, independent ERP assurance involves four recurring activities.Evidence review: examining the actual deliverables the SI is producing — test results, data migration reports, training attendance records, cutover plans — rather than the summary status reports derived from them.Governance review: assessing whether decision rights, escalation paths, and accountability structures are documented and functioning. This includes reviewing the programme board's terms of reference, the change control log, and whether a workaround register is being maintained.Risk identification: naming risks that the programme team may not be surfacing — including risks that the SI has visibility of but is not raising, and risks arising from dependencies outside the SI's scope (legacy decommissioning, third-party integrations, payroll parallel runs).Reporting to the sponsor: producing a direct line of reporting to the programme sponsor or finance director that does not pass through the SI. This is the structural feature that makes assurance genuinely independent.The frequency and intensity of assurance engagement varies by programme size and risk profile. For a post-go-live Oracle Fusion programme, a quarterly assurance review aligned to Oracle's update cycle is a natural cadence.

The 3-in-a-Box model is a programme governance structure that places three distinct parties in the room for key programme decisions: the client organisation, the system integrator, and an independent adviser.The client brings accountability for outcomes, statutory duty (in a public sector context), and funding decisions. The SI brings technical delivery capability and product knowledge. The independent adviser brings an objective view of programme health that is not filtered through either of the other two parties' interests.Without the independent third voice, ERP programme governance defaults to a bilateral relationship between the client and the SI — in which the SI holds most of the technical knowledge and the client has limited ability to challenge delivery claims. This asymmetry is the structural cause of most ERP governance failures. Leadership teams typically undertake one major ERP programme in a decade. System integrators run dozens. That knowledge gap is real, and it needs to be bridged deliberately.The 3-in-a-Box model does not imply an adversarial relationship with the SI. In a well-functioning programme, the independent adviser confirms delivery confidence as readily as they raise risk. The SI benefits from having its delivery independently validated. The client benefits from having governance that will withstand external audit. The programme benefits from having three parties with different perspectives reviewing the same evidence.

Public sector ERP governance carries requirements that do not apply in the same way to private sector programmes. Statutory duty, fiscal scrutiny, external audit, and political accountability mean that governance gaps which might be tolerated in a private organisation become material risks in a council, NHS trust, or central government department.Specific governance requirements for public sector ERP programmes include: a named Senior Responsible Owner (SRO) with documented authority over programme decisions; a decision log covering the last quarter that shows who authorised what and when; a workaround register that is current, reviewed, and owned; test coverage confirmed by evidence rather than SI assertion; and a support model that has been formally confirmed as adequate for the quarterly update cycle.The Section 151 Officer has a specific statutory responsibility for the proper administration of a local authority's financial affairs. Where an ERP programme affects financial systems — as Oracle Fusion implementations almost always do — the S151 Officer's ability to provide that assurance depends on receiving an independent view of programme health. Relying solely on SI reporting does not meet that standard.

Transformation Erosion is the gradual degradation of an ERP programme's intended operating model after go-live — typically caused by the accumulation of workarounds, the drift of process adoption away from the configured system, and the loss of institutional knowledge as the implementation team disperses.The pattern is consistent: a programme goes live having adopted a number of workarounds to meet the go-live date. Each workaround is understood by the people who sanctioned it, but is rarely documented in a way that survives their departure. Over the following twelve months, the workarounds become embedded in operational practice. The configured system is used for some processes and bypassed for others. The gap between how Oracle Fusion was designed to work and how it is actually being used widens — and the business case benefits erode with it.Transformation Erosion is distinct from go-live failure. The system is live. Transactions are processing. But the efficiency gains, the reduced manual effort, and the improved data quality that justified the investment are not being realised — because the operating model that delivers them has drifted.Identifying and reversing Transformation Erosion requires an independent view of how the system is actually being used, compared to how it was configured to be used. Adoption data by function — transactions, not licence use — is the primary evidence base.

The distinction between assurance evidence and a status report is the most important practical question in ERP governance.A status report reflects the programme team's assessment of their own progress. It is produced by the people responsible for delivery, reviewed by the people managing them, and presented to the steering committee in a format designed to communicate confidence. It is not useless — but it is not assurance.Assurance evidence is the underlying material from which a status report is derived: test result logs with pass and fail rates by business process; data migration reconciliation reports showing match rates and exception volumes; training attendance records by role and function; cutover plan with named dependencies and owners; workaround register with dates, sanctions, and review history.An independent adviser reviews this underlying material and derives their own assessment of programme health from it. Where their assessment matches the status report, the programme has genuine confidence to offer its steering committee. Where it does not, the discrepancy is the finding — and it is the finding that is most valuable.Requesting access to underlying evidence as a condition of programme governance is not an adversarial act. It is the minimum standard of oversight that statutory accountability requires. If an SI is unwilling to provide it, that unwillingness is itself a governance finding.

It is never too late to bring in independent assurance, but the nature of the intervention changes significantly depending on programme stage.Pre-implementation assurance focuses on governance design, SI selection scrutiny, and the robustness of the business case. This is the lowest-cost point of entry and the one with the highest return.Mid-implementation assurance focuses on delivery confidence, test coverage, and data readiness. Programmes that engage assurance at this stage often do so because a milestone has been missed or a cost overrun has triggered board-level concern.Post-go-live assurance focuses on the quarterly update cycle, adoption, Transformation Erosion, and the ongoing cost of manual workarounds. This is the stage most often neglected — and the one where the ongoing cost of not having assurance accumulates quietly in programme budgets year after year.Recovery assurance — for programmes that have already failed or stalled — is the highest-intensity engagement and the one most often required quickly. An independent recovery review that can be presented at board level, produced within four weeks, is what SIM works to for a programme in this position.The question is not whether it is too late. The question is what the programme needs now — and whether the organisation has the governance structures to act on what an independent review finds.

SIM Consulting's assurance practice is built on one structural principle: we sit on the client's side. We have no financial relationship with any system integrator and we do not resell ERP software licences. Our only commercial relationship is with the organisation commissioning the assurance — which means our findings, recommendations, and risk escalations go to the programme sponsor without being filtered through the SI's interests.In practice, SIM's assurance engagements are grounded in the 3-in-a-Box governance model — placing an independent voice alongside the client and SI in programme governance, rather than operating as a remote review function. Ramzan Amin brings over 20 years of large-scale ERP delivery experience in UK public sector environments — latterly on Oracle Fusion — including programme directorship of one of the UK's largest local authority Oracle Fusion modernisations. That delivery background means SIM's assurance reviews are conducted by someone who has built and led the type of programme being reviewed — not by an external audit team working from a checklist.For organisations beginning an assurance engagement, SIM's ERP Governance Diagnostic provides a structured starting point: 15 questions that surface the governance positions a programme should be able to confirm before its next major milestone, with results mapped to one of four risk bands. It takes 15 minutes and is available without obligation at simconsultingltd.com.