Topic 5.4 — Enterprise Resource Planning (ERP)

In one sentence: Enterprise Resource Planning is the integrated back-office system — finance, human resources, payroll, procurement, and supply chain — that acts as the organization's system of record for money, people, and stock, and quietly underpins almost every way of working in this book.

Why this matters in health and care#

Digital transformation in health and care gets its attention from clinical systems — the electronic patient record, the shared care record, the patient app. But none of those run without the unglamorous back office beneath them. Staff must be recruited, rostered, and paid; suppliers must be contracted and settled; drugs, devices, and consumables must be ordered and tracked; and every pound must be accounted for against tightly constrained public budgets. ERP is where that happens, and when it fails, the consequences are immediate: unpaid staff, stalled procurement, unreconciled accounts, and a finance function flying blind.

The scale is enormous. NHS Shared Business Services (NHS SBS), a joint venture created in 2004, runs a national Oracle-based finance and procurement platform that processes millions of invoices and handles a very large share of total NHS spend for over a hundred NHS organizations (see Key sources). ERP decisions are therefore not a niche finance concern — they shape workforce management, control of public money, and the data quality that every downstream analysis depends on. For a director, ERP is both a foundational enabler and one of the highest-risk programs an organization will ever attempt.

Core concepts#

What ERP is. A single, integrated enterprise resource planning suite of modules sharing one database and one set of master data, covering the enterprise's core administrative processes: general ledger and financial accounting, accounts payable and receivable, HR and workforce administration, payroll, procurement (purchase-to-pay), inventory and supply chain, and increasingly planning and analytics (FP&A — financial planning and analysis). The point of "integration" is that a purchase order, a goods receipt, and an invoice reconcile automatically because they are the same data, not three copies.

System of record. ERP is the authoritative source for financial and resource data — the ledger that auditors trust and the payroll that staff are paid from. Other systems may hold operational copies, but the ERP is the version of truth for money and, often, for the substantive HR record.

Master data. The shared reference data on which everything else depends: the chart of accounts, cost centers, supplier records, the item catalog, and employee records. Master data is the quiet determinant of ERP success — dirty, duplicated, or inconsistent master data corrupts reporting, breaks reconciliation, and undermines every process built on top.

Common platforms in health and public sector. In the NHS and wider UK public sector the main ERP platforms are Oracle (dominant, largely through NHS SBS and consortia such as NEP), SAP, Unit4 (widely chosen by trusts, universities, and local authorities), and Microsoft Dynamics 365. Local authorities delivering adult social care run the same class of systems for their finance and procurement. The modern direction of travel is cloud ERP (software-as-a-service) rather than on-premise installations.

Shared services. Rather than every organization running its own ERP, many share a common platform and a common back-office operation — the NHS SBS model, and NHS consortia running templated Oracle Cloud instances. Shared services trade some local flexibility for standardization, economies of scale, and a smaller collective implementation and support burden.

Best practices#

1. Treat master data as the foundation, not an afterthought. Cleanse and de-duplicate the chart of accounts, supplier records, item catalog, and employee data before migration, and put ongoing data-governance ownership in place. The most damaging ERP failures trace back to bad master data that no amount of good software can fix; a data-quality workstream is not optional.

2. Adopt the standard; minimize customization. Configure the ERP to the vendor's or consortium's standard template wherever the process is genuinely commodity, and reserve bespoke change for the rare true differentiator. Heavy customization inflates cost, wrecks upgradeability, and re-imports the local mess you were trying to escape — cloud ERP in particular punishes the "make it look like our old system" instinct.

3. Design the integrations deliberately. ERP does not stand alone: it must exchange data with workforce and e-rostering systems, clinical and pharmacy systems (for stock and costing), banking, and analytics. Map every interface, own the data contracts, and test them end to end — payroll fed by a broken rostering feed pays people wrong, and that is a trust-destroying failure.

4. Run ERP replacement as a major program, with change management at its core. An ERP implementation is a business-change program that happens to involve software, not an IT project. Resource it with program discipline (see Topic 5.2 — Program Management) and a genuine change-management effort (see Topic 8.1 — Change Management), because most ERP pain is people and process, not technology.

5. Be honest about ERP program risk. Large ERP implementations have a well-earned reputation for overrunning on time and cost and under-delivering on benefit; the failure literature is extensive and cross-sector. Build in contingency, avoid a big-bang go-live where a phased approach is feasible, and never let an optimistic timeline override readiness — a slipped date is recoverable, a botched payroll or ledger cut-over is not.

6. Protect the go-live and the period after it. Plan data cut-over, parallel running, reconciliation, and hypercare support in detail, and resist pressure to shorten them. The weeks around go-live are when suppliers go unpaid and month-end breaks; a well-staffed stabilization period is the difference between a rough start and a public crisis.

7. Use ERP as the resource-management system of record — and design ways of working around it. Let the ERP be the single source for cost centers, budgets, procurement approvals, and workforce establishment, and align your operating processes to it rather than maintaining shadow spreadsheets. Shadow systems re-introduce the fragmentation ERP exists to remove and quietly rot data quality.

8. Weigh shared services and cloud ERP on their real trade-offs. Shared platforms (NHS SBS, NEP-style consortia) and cloud ERP offer standardization, scale, continuous upgrades, and a lighter local burden, at the cost of some local flexibility and a dependency on the provider. Choose deliberately: for most organizations the standardization gain outweighs the flexibility lost, but the decision should be made with eyes open, not by default.

Questions to discuss with your team#

1. How confident are we — with evidence, not assurance — about the quality of the master data we would carry into a new ERP, and who owns it after go-live? Master data is the quiet determinant of ERP success, yet it is routinely treated as a migration housekeeping task rather than the foundation it is, so this question tests whether the team has looked hard at the chart of accounts, supplier records, item catalog, and employee master or is simply hoping they are clean. In a health and care setting the stakes are concrete: duplicated supplier records break purchase-to-pay reconciliation, an employee master that disagrees with ESR pays people wrong, and an inconsistent chart of accounts corrupts every downstream financial report the board and auditors rely on. The tension worth debating is the pull to migrate wholesale to hit a date versus the months of unglamorous cleansing and de-duplication that good practice demands, and whether anyone senior is willing to fund a data-quality workstream that shows no visible product. A strong answer cites actual counts — how many duplicate suppliers, how many unreconciled employee records — rather than a general sense that "the data is mostly fine". It should also name the person and governance mechanism accountable for master-data quality after go-live, because data that is cleansed once and then left ungoverned simply drifts back to disorder.

2. Where are we genuinely tempted to customize the ERP to preserve a familiar process, and is that difference a real differentiator or just the old mess we are trying to escape? Heavy customization is the classic enterprise ERP trap: it inflates cost, wrecks upgradeability, and re-imports the very local fragmentation the program was meant to remove, and cloud ERP in particular punishes the instinct to "make it look like our old system". This question asks the team to be specific about which processes they will insist on bending the software to fit, and to justify each against a hard test of whether it is a true differentiator or merely comfortable habit. The debate matters because in health and care almost every back-office process — general ledger, procurement approvals, payroll administration — is genuinely commodity, so the honest default should be to adopt the vendor or consortium standard template and change the process, not the software. Concrete angles include listing every requested customization and asking who benefits, what upgrade cost it locks in, and whether a neighboring trust on the same template manages without it. A good answer distinguishes the rare legitimate exception from the many requests driven by change-aversion, and recognizes that adopting the standard is a change-management and leadership problem, not a technical one. It should also confront the long-term cost: every bespoke change is a tax paid at every future cloud release.

3. Have we honestly resourced the human and process side of this ERP change — cut-over, parallel running, hypercare, training, and integration testing — or are we quietly running it as an IT project? The failure literature is unambiguous that most ERP pain is people and process rather than technology, so this question exposes whether the program is genuinely a business-change effort or an IT swap wearing program clothing. The period around go-live is when suppliers go unpaid, month-end breaks, and staff get paid late, and each of those in a public health body is not a rough start but a trust-destroying, potentially newsworthy failure. The tension to debate is the constant pressure to shorten parallel running, thin the hypercare team, and compress the timeline to hit an imposed date, against the reality that a slipped date is recoverable while a botched payroll or ledger cut-over is not. Useful angles include walking through every integration — e-rostering, ESR, pharmacy stock, banking, analytics — and asking which have been end-to-end tested versus assumed, and whether process owners in finance, procurement, and HR have actually been seconded to redesign their workflows. An honest answer shows named change-management, training, and reconciliation resource in the plan rather than a line that says "IT will handle it", and is willing to phase the go-live where a big-bang cut-over adds avoidable risk. It should also acknowledge that readiness, not the calendar, must govern the decision to proceed.

4. On the shared-services and cloud-ERP question, have we weighed the standardization we would gain against the local flexibility we would surrender — and made that call deliberately rather than by default? Shared platforms such as NHS SBS and consortium Oracle Cloud instances, and cloud ERP more broadly, offer real prizes — economies of scale, continuous upgrades, a lighter local implementation and support burden — but they buy those with a genuine loss of local control and a hard dependency on the provider's roadmap and release cadence. This question forces the team to name what flexibility actually matters to them and test whether it is worth the cost of running, patching, and separately supporting their own back office. The tension in a health and care setting is sharpened by the fact that most back-office process is commodity, so the standardization gain usually outweighs the flexibility lost — but "usually" is not "always", and drifting into a shared platform without examining the trade-off is how organizations end up resenting a template they never consciously chose. Concrete angles include asking which local processes the team would fight to keep and why, what happens when the consortium changes the template underneath them, and whether the exit and data-portability terms are understood before signing. A strong answer treats this as a strategic choice made with eyes open, weighing provider dependency and roadmap risk against scale and upgrade relief, rather than either defaulting to the shared option because it is fashionable or clinging to a bespoke platform out of habit.

5. What is our honest plan to stop shadow spreadsheets and local workarounds re-emerging after go-live, so the ERP stays the single system of record rather than one source among many? The whole point of an integrated ERP is to remove the fragmentation that shadow systems create, yet local spreadsheets have a way of surviving a go-live and quietly re-fragmenting the data the program was meant to unify. This question tests whether the team has thought past the cut-over to the durable operating discipline that keeps cost centers, budgets, procurement approvals, and workforce establishment living in the ERP rather than in someone's private workbook. It matters in health and care because a shadow establishment spreadsheet that disagrees with payroll, or an off-system procurement tracker, silently rots the data quality that board reporting and audit depend on, and does so precisely because it is convenient for the person maintaining it. The tension worth surfacing is that shadow systems usually exist for a reason — the ERP process felt slower, or a genuine gap was never closed — so simply banning them fails unless the underlying need is addressed. Useful angles include asking which current spreadsheets would have to die at go-live, why each exists, and what in-system capability or process change would remove the temptation to rebuild it. An honest answer pairs a clear expectation that the ERP is authoritative with a plan to fix the gaps that drive people off-system, and names who will notice and challenge a shadow system when it reappears.

6. Are we being genuinely honest about ERP program risk — the sector's track record of overrun and under-delivery — and have we built our timeline, contingency, and go-live approach around that reality rather than an optimistic plan? Large ERP implementations have a well-earned, cross-sector reputation for overrunning on time and cost and under-delivering on benefit, and this question asks whether the team has internalized that failure literature or is quietly assuming it will be the exception. The stakes in a public health body are unforgiving: a slipped date is recoverable, but a botched payroll or ledger cut-over is a newsworthy, trust-destroying event with parliamentary and press consequences, so optimism that overrides readiness is not courage but recklessness. The tension to debate is the constant pressure — from imposed dates, sunk cost, and the wish to show progress — to compress the timeline, thin contingency, and prefer a big-bang go-live over a phased one that would be safer but slower. Concrete angles include asking what the plan assumes will go right, where the contingency actually sits, whether a phased cut-over is feasible, and what the explicit criteria are for delaying go-live if readiness is not there. A good answer names the specific risks this program carries rather than gesturing at ERP risk in general, builds in real contingency and a defensible phasing decision, and treats a data-driven "not yet" as a legitimate and expected outcome rather than a failure of nerve.

In practice: a health & care example#

An acute NHS trust is running a fifteen-year-old on-premise finance and procurement system that its vendor will soon stop supporting. Reporting takes days, purchase-to-pay is heavily manual, and the workforce establishment lives in a tangle of spreadsheets that never quite agrees with payroll. The trust decides to move to a cloud ERP delivered through a regional NHS consortium's templated Oracle Cloud instance, alongside neighboring providers.

The finance director resists the temptation to treat this as an IT swap. A program is stood up with an executive sponsor, a full-time program manager, and — crucially — a data-quality workstream that spends months cleansing the chart of accounts, de-duplicating twelve thousand supplier records, and reconciling the employee master against ESR (the NHS electronic staff record) before any migration. Process owners in finance, procurement, and HR are seconded to redesign their workflows to the consortium template rather than replicate the old system.

The trust chooses a phased go-live: finance and procurement first, workforce and reporting in a later wave, with parallel running across two month-ends and a well-staffed hypercare team on standby. Integrations to e-rostering, the bank, and the analytics warehouse are mapped and tested end to end. The go-live is not painless — a supplier-payment backlog builds in week one and takes a fortnight to clear — but because reconciliation and hypercare were properly resourced, no staff are paid late and month-end closes on time.

A year on, the trust closes its books in days rather than weeks, procurement approvals are enforced in-system, and the establishment finally reconciles with payroll. The shared consortium platform also means the next upgrade arrives as a routine cloud release rather than another multi-year project.

Sector lenses#

Startup#

A digital-health startup rarely runs a full ERP; it stitches together cloud SaaS tools — a lightweight accounting package, an HR-and-payroll app, a couple of spreadsheets — because a heavyweight integrated suite is disproportionate to a team of thirty. The system-of-record discipline still matters, though: even at seed stage, one clean chart of accounts and a single authoritative payroll source prevent the reconciliation chaos that scares off investors during due diligence. The right move is to keep the stack simple, integrable, and well-governed, and to defer a "real" ERP until scale genuinely demands it. The startup's risk is the mirror image of the enterprise's — not over-customization, but sprawl: a dozen disconnected apps with no master-data owner and no one accountable for the numbers.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, a domiciliary-care agency, or a single-site clinic — carries the full weight of financial, payroll, and procurement duties with almost no dedicated finance or IT capability, so a heavyweight ERP is out of reach but the system-of-record discipline is not optional. The practical answer is a small, well-integrated set of cloud packages — accounting, payroll, and stock — chosen so that one chart of accounts and one authoritative payroll source hold, because a care home that pays staff late or a pharmacy whose stock and ledger disagree faces the same regulatory and cash consequences as a large trust but with no back-office team to absorb them. The temptation to run the business on a founder's spreadsheet is strongest here and most dangerous, since there is rarely anyone to notice when the numbers drift. Where a professional body, franchise, or local network offers a shared or standardized finance platform, adopting it is usually the shrewd move: it buys the standardization and support the organization cannot resource itself. The discipline is to keep the stack simple and governed by whoever owns the money, and to resist bespoke workarounds that only that one person understands.

Enterprise#

A large trust or health-tech firm runs a full integrated ERP as a mission-critical system of record, and replacing it is one of the highest-risk programs it will ever attempt. The enterprise temptation is heavy customization to preserve familiar legacy processes; the discipline is to adopt the standard template, resource a serious data-quality workstream, and run go-live with parallel running and a well-staffed hypercare period. Integrations multiply — e-rostering, ESR, pharmacy stock, banking, analytics — and each is a trust-destroying failure if it silently breaks payroll or month-end reconciliation. Because most of the pain is people and process rather than technology, change management (see Topic 8.1 — Change Management) is where the enterprise program is won or lost. Accountability to a board and auditors makes a botched ledger or payroll cut-over a governance incident, not just an IT setback.

Government#

At national and shared-service scale, ERP is a standardization instrument: NHS Shared Business Services and consortium Oracle Cloud instances exist to give many organizations one templated platform, trading local flexibility for economies of scale and continuous upgrades. Government accountability adds public-procurement scrutiny (competitive frameworks, value-for-money assurance) to every major ERP decision, and a national cut-over failure has parliamentary and press consequences. The center's real leverage is convening — mandating or incentivizing shared platforms so scores of trusts and local authorities do not each run, patch, and separately fail their own back office. The defining tension is between national standardization and local autonomy: push the template too hard and adoption stalls in resentment; too softly and the fragmentation ERP exists to remove quietly persists.

Common failure modes#

• Dirty master data migrated wholesale. Old duplicates and inconsistencies are carried into the new system, corrupting reporting from day one. Fix: cleanse and govern master data before migration, and own it afterwards.
• Customizing to replicate the old system. Bespoke changes made to avoid process change inflate cost and destroy upgradeability. Fix: adopt the standard template; change process, not software.
• ERP run as an IT project. Treating it as a technology swap starves the change, training, and process-redesign effort. Fix: run it as a business-change program with real change management (Topic 8.1).
• Optimistic big-bang go-live. Compressed timelines and a single cut-over turn ordinary problems into public crises. Fix: phase where feasible, and never trade readiness for a date.
• Broken integrations. An untested rostering-to-payroll or procurement-to-ledger feed pays people wrong or breaks reconciliation. Fix: map, own, and end-to-end test every interface.
• Shadow spreadsheets survive. Local workarounds persist alongside the ERP, re-fragmenting the data. Fix: make the ERP the single system of record and retire the shadows.

Maturity model#

Checklist#

• The chart of accounts, supplier, item, and employee master data is cleansed and de-duplicated before migration.
• Ongoing master-data ownership and governance are assigned and funded.
• The implementation is scoped and resourced as a business-change program, not an IT project.
• Customization is minimized; the standard vendor or consortium template is adopted for commodity processes.
• Every integration (rostering, payroll/ESR, clinical/pharmacy, banking, analytics) is mapped, owned, and end-to-end tested.
• Go-live approach (phased vs. big-bang) is chosen on readiness, not on an imposed date.
• Data cut-over, parallel running, reconciliation, and a hypercare period are planned and staffed.
• Change management, training, and process redesign are explicitly resourced (see Topic 8.1).
• Shared-services and cloud-ERP options are evaluated on their real standardization-vs-flexibility trade-offs.
• The ERP is established as the single system of record, and shadow spreadsheets are retired.

Key sources#

• NHS Shared Business Services (NHS SBS) — the national Oracle-based finance and procurement shared service for NHS organisations. https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — scale of the national NHS finance platform. https://www.oracle.com/uk/
• NHS North of England Commissioning / NEP consortium — templated Oracle Cloud ERP for NHS members. https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — ERP for NHS trusts, local authorities, and universities. https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — finance processes ERP underpins. https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with. https://www.electronicstaffrecord.nhs.uk/
• See also Topic 5.2 — Programme Management, Topic 5.3 — Enterprise Project Portfolio Management, and Topic 8.1 — Change Management.

References#

1. Enterprise resource planning — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. System of record — Wikipedia — https://en.wikipedia.org/wiki/System_of_record
3. Master data management — Wikipedia — https://en.wikipedia.org/wiki/Master_data_management
4. Chart of accounts — Wikipedia — https://en.wikipedia.org/wiki/Chart_of_accounts
5. Payroll — Wikipedia — https://en.wikipedia.org/wiki/Payroll
6. Procure-to-pay — Wikipedia — https://en.wikipedia.org/wiki/Procure-to-pay
7. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
8. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Change management — Wikipedia — https://en.wikipedia.org/wiki/Change_management
11. Business process re-engineering — Wikipedia — https://en.wikipedia.org/wiki/Business_process_re-engineering
12. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
13. NHS Shared Business Services — Wikipedia — https://en.wikipedia.org/wiki/NHS_Shared_Business_Services
14. NHS Shared Business Services — the national Oracle-based finance and procurement shared service for NHS organisations — https://www.sbs.nhs.uk/
15. NHS Shared Business Services with Oracle Fusion Cloud Applications — Oracle — https://www.oracle.com/uk/
16. Public sector and healthcare ERP — Unit4 — https://www.unit4.com/industries/public-sector-software
17. Introductory Guide to NHS Finance — HFMA — https://www.hfma.org.uk/
18. NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with — https://www.electronicstaffrecord.nhs.uk/