Field Guide No. 03 First Edition · 2026

The ERP Field Guide.

A working reference for the leader accountable for an ERP decision — the modules, the value streams, the integration spine, the master data model, the controls fabric, the roles, the industry dial-ups, and the operating-model commitments the software locks in for the next seven to ten years.

Trevin Nimaladasa

Edition

Vol. III · First Edition · 2026

Reference

Field Guide No. 03 · ERP & Core Systems

Preamble · The operating posture

The Operating-Model Thesis.

ERP is not a software selection. It is a structural commitment to how the business will run for the next seven to ten years — the chart of accounts, the org structure, the master data model, the integration spine, the controls fabric. The software is the smaller decision.

TOGAF Phase B · Business Architecture TOGAF Phase C · Data & Application Architecture PMI Program Management — Governance BABOK SA · Strategy Analysis COBIT APO · Align, Plan & Organise

Every ERP programme that fails — and most do, by their own original business case — fails for the same reason. The decision was framed as software. The reality was an operating-model commitment dressed in software language. By the time the gap appears, the contract is signed, the implementation partner is engaged, and the chart of accounts is already half-built in someone's draft configuration workbook.

ERP is the system of record for how the enterprise actually runs — not how the org chart describes it, not how the policy document phrases it, but how transactions get coded, who can approve what, what closes the month, what feeds the regulator, what counts as inventory, what counts as revenue, and who is on the hook when any of those answers is wrong. Every one of those questions is an operating-model question. The software simply enforces whichever answer the configuration encodes.

A senior leader's job, before any RFP closes, is to make the operating-model commitments explicit — and to verify that they have been made, not assumed. The modules in §01 are not features to be selected; they are organisational commitments that, once configured, are very expensive to reverse. The integration patterns in §03 are not technical preferences; they are architectural commitments about who owns which data class. The controls fabric in §04 is not a compliance afterthought; it is the structural answer to who can do what without supervision.

The system of record is the operating model. Anything else is theatre.— The thesis, in one line

What this guide is

A working reference for the leader accountable for an ERP decision — sponsor, CFO, COO, transformation lead, or programme director. The structure mirrors the practitioner's mental model: thesis first, then the anatomy, then the modules and their value streams, then the integration spine, controls, industry dial-ups, roles, and the programme rhythm. Every module section names what the module actually is, what it commits the business to, the value streams running through it, where it typically goes wrong, and which decisions the leader must own personally — not delegate to the implementation partner.

What this guide is not

It is not a vendor evaluation guide. It is not a CRP or a fit-gap workbook. It is not a checklist for a steering committee deck. It is a field guide — written to be opened during real work, when a real decision is in front of you, and to give you a faster path to the right question than to the right answer. The right question, asked at the right stage, almost always saves more value than the right answer asked too late.

The thesis, continued · What we're actually buying

What ERP Actually Is.

Vendors sell features. Implementation partners sell methodology. The buyer's job is to remember what is actually being purchased — an enterprise commitment to a single source of truth, enforced by software, that the entire operating model will now reference. The illusion stack below names where that commitment usually slips.

Most enterprises buy ERP three times before they actually implement it. The first time, it is sold as a system. The second time, as a project. The third time — usually mid-way through delivery, when the chart of accounts is being re-configured for the fourth time — it becomes clear what was actually being bought. By then the cost of clarity is much higher than it would have been if the conversation had been framed correctly at the start.

The illusion stack

Every ERP programme passes through six stages between concept and value. Each stage produces something tangible — and a corresponding illusion. The senior leader's job is to see the illusion at the moment it forms, before commercial commitments harden around it.

Stage	What it produces	The illusion	What it should mean
Strategy paper	A board-approved direction.	Alignment, before the operating-model trade-offs have been named.	A written declaration of which trade-offs the enterprise has accepted (standardise vs localise; build vs buy; speed vs correctness).
Business case	A funded benefit narrative.	The appearance of value, before any leverage exists.	A named operational change with a measurable outcome, an accountable owner twelve months post go-live, and a defined kill criterion.
RFx	A market test of vendors.	The appearance of choice, before the operating-model commitments have been declared.	Trade-offs declared in writing, accepted by the sponsor in writing, before the market is tested.
Vendor selection	A signed software contract.	The appearance of decision closure.	The smaller half of the decision. The larger half — the implementation partner, the data model, the integration architecture — is still ahead.
Configuration	A live, parameterised system.	The appearance of progress, measured in screens built.	The operating model written in software. Every configuration choice is an organisational policy with a long tail.
Go-live	A cutover and a launch.	The appearance of success, before anything in the operating model has actually changed.	The starting line for value. The original benefits are now testable in operational reality — most are not visible for six to twelve months.

The leverage point

The cheapest moment to fix an ERP programme is between the strategy paper and the business case. The most expensive moment is between configuration and go-live. By the configuration stage, the operating-model commitments have already been encoded — sometimes deliberately, sometimes by accident, almost never with the sponsor in the room. The senior leader's job is to bring the operating-model conversation forward by two stages — so that the configuration step is implementing decisions that have already been made, rather than making them under deadline pressure.

The leader's question

"At which stage of the illusion stack are we right now — and which operating-model commitments have we already made, named or not?"

iii

The system, in layers

Anatomy of a Core System.

An ERP is not one thing. It is five layers, stacked, each enforcing different decisions. The leader who understands the layers can see where a problem actually lives — not where it appears to live on the surface.

The layers below are common to every modern ERP — SAP S/4HANA, Oracle Fusion, Workday, Dynamics 365, NetSuite, Infor, IFS. Vendor marketing tends to collapse the layers into one — “the platform” — because it is easier to sell. The buyer's job is to keep them distinct, because each layer is a different commitment, owned by a different team, breaking in a different way.

Layer 01

The Data Layer

The master data classes — customer, vendor, employee, product, project, cost centre, GL account. The system of record for who and what the business transacts with. Every transaction up the stack reads from here.

Owned by: data governance, finance, HR. Breaks when: multiple sources of truth survive go-live.

Layer 02

The Transaction Layer

The modules themselves — Financials, HCM, SCM, Manufacturing, CRM, EAM, PPM. Where work is recorded, posted, approved, fulfilled. The visible surface of the ERP.

Owned by: process owners (CFO, CHRO, COO). Breaks when: process is mapped to module, instead of module configured to process.

Layer 03

The Workflow & Controls Layer

Approval routing, segregation of duties, role-based access, exception handling, audit trail. The structural answer to who can do what without supervision.

Owned by: risk, audit, security, finance. Breaks when: built late, retrofitted onto an already-live system.

Layer 04

The Integration Layer

Middleware, APIs, scheduled batches, event streams. The connective tissue between ERP and every other system — payroll, banking, sub-ledgers, CRM, BI, regulators.

Owned by: enterprise architecture, integration platform team. Breaks when: treated as plumbing, not as the data contract layer.

Layer 05

The Reporting & Decision Layer

Operational dashboards, financial close packs, regulatory submissions, BI extracts. The outputs the rest of the business actually consumes.

Owned by: finance, BI, business owners. Breaks when: built after the data and transaction layers harden — and inherits whatever shape they took.

Cross-cutting

Change, Security, & Cutover

Not a layer — a discipline that runs through all five. The reason most ERP programmes “technically went live” but didn't compound.

Owned by: programme leadership. Breaks when: handed to a subordinate workstream and never sponsored from the top.

The transaction layer · Twelve modules with value streams

The Modules.

Twelve modules cover the operating surface of most enterprises. Each is a commitment to how a specific organisational function will be run. Each entry names what the module is, the value streams running through it, what it locks in, where it goes wrong, and the leader's question.

SCOPE Concept & Module level. Component & Process detail lives in domain-specific references and vendor documentation.

Finance & People

Financial Accounting

General ledger, accounts payable, accounts receivable, asset management, cash. The financial system of record.

READ

What it is

The module that records, posts, and reports every transaction with a financial dimension. Anchored by the General Ledger and a chart of accounts. Every other module — HCM, SCM, Manufacturing, PPM — ultimately posts here. The financial close, the statutory accounts, the regulator submissions, the board pack: all of them read from this module's outputs.

The operating-model commitment

The chart of accounts is the operating model in numbers. The hierarchy of cost centres is the org structure for financial reporting. The dimensions (project, region, customer, programme) declare which slices of performance the business intends to manage. Once the GL goes live, changing these is expensive, slow, and politically painful — every historical comparison breaks.

Value streams in scope

Value Stream 01 · Record-to-Report

From transaction to financial statement

Source Event→Journal Entry→GL Posting→Trial Balance→Close & Consolidate→Statutory Report

Outcome: A monthly close that produces a defensible set of accounts within the regulator's window. Quality of close depends on every prior step — most close failures live upstream of the close itself.

Value Stream 02 · Procure-to-Pay

From requisition to payment cleared

Requisition→Purchase Order→Goods/Service Receipt→Invoice Receipt→3-Way Match→Approval→Payment

Outcome: Suppliers paid on agreed terms, with audit-grade evidence of authorisation and receipt. The dominant working-capital lever — and the single largest exposure to fraud and SoD violation.

Value Stream 03 · Order-to-Cash

From customer order to cash collected

Sales Order→Fulfilment→Invoice→Receivable→Collection→Revenue Recognition

Outcome: Revenue recognised correctly, cash collected on terms, DSO managed. The lifeblood; failure here is felt immediately.

Value Stream 04 · Acquire-to-Retire (Assets)

From capex approval to disposal

Capex Approval→Acquisition→Capitalise→Depreciate→Revalue/Impair→Dispose

Outcome: Fixed-asset register that reconciles to physical reality and to the GL. Connects directly to EAM in asset-heavy industries.

Value Stream 05 · Cash & Treasury

From cash position to funded operations

Cash Forecast→Position→Funds Transfer→Bank Reconcile

Outcome: Daily cash position the CFO can defend; bank reconciliations that close cleanly. Where treasury sophistication lives — or doesn't.

Components in scope

General Ledger — central repository, chart of accounts hierarchy.
Accounts Payable — invoice receipt, 3-way matching, payment disbursement.
Accounts Receivable — billing, collections, revenue recognition.
Asset Management — capex tracking, depreciation, disposal.
Cash & Treasury — forecasting, positioning, bank reconciliation.
AP Automation — OCR/IDR, invoice scanning, payment files (ABA, EFT).

Where it goes wrong

Chart of accounts designed by finance alone, without involving the operating side — meaning the GL can produce statutory accounts but cannot answer the operational questions the business actually asks. Sub-ledgers configured before the GL hierarchy is settled. Master vendor and customer records duplicated across modules. AP automation bolted on after go-live, instead of being part of the original design. Bank reconciliation treated as a clerical task instead of a control.

Leader's question

"Is the chart of accounts being designed for the operating model we want in five years — or the one we had five years ago?"

Human Capital Management

Payroll, recruitment, benefits, training, compliance. The system of record for the workforce.

READ

What it is

The module that records every employee event with a financial, contractual, or compliance dimension — hire, change, pay, leave, terminate. In modern stacks (Workday, SuccessFactors, Oracle HCM), it also covers performance, learning, and recruiting. The system of record for org structure, position management, and labour cost allocation.

The operating-model commitment

Position management vs employee-centric design is a foundational call — and it bakes in how the org will be reported, costed, and reorganised for the next decade. Pay grade and award interpretation is another. So is the boundary between HR and payroll — many programmes assume they are the same module; they often are not.

Value streams in scope

Value Stream 01 · Hire-to-Retire

From open position to departure

Requisition→Recruit→Hire→Onboard→Manage→Develop→Offboard

Outcome: An employee experience that compounds — and a data trail that supports succession, capability planning, and workforce decisions.

Value Stream 02 · Time-to-Pay

From time recorded to paycheck banked

Time Capture→Award Interpretation→Gross Calc→Deductions→Net Pay→Bank Distribution→Statutory Reporting

Outcome: Every employee paid correctly, on time, every cycle. The most visible failure mode in any HCM programme — and the one with the fastest political consequences.

Value Stream 03 · Performance & Development

From capability gap to capability built

Goal-Setting→Performance Review→Needs Identification→Training→Effectiveness Assessment

Outcome: A workforce capability picture the CHRO can defend at board level — and an investment trail that justifies L&D spend.

Value Stream 04 · Benefits & Compliance

From entitlement to regulator confidence

Enrolment→Eligibility→Administration→Reporting

Outcome: Benefits administered correctly across the workforce; compliance evidence ready when the regulator asks.

Components in scope

Payroll — calculation, deductions, distribution, statutory reporting.
Recruitment & Onboarding — requisition, sourcing, applicant tracking, hire.
Benefits — enrolment, eligibility, administration, reporting.
Training & Development — needs identification, delivery, effectiveness.
Compliance — labour law, EBA terms, incident reporting.
Position Management — the structural skeleton of the workforce.

Where it goes wrong

Award and EBA interpretation logic over-customised into payroll, then frozen — so when the EBA renegotiates, half the system has to change with it. Position management bolted on after a person-centric design, instead of being decided up front. Payroll go-live attempted simultaneously with other modules, instead of being sequenced separately. Cutover scheduled on a pay date.

Leader's question

"Are we configuring HCM for how the business actually pays, promotes, and reports — or for how policy says it should?"

Customer & Revenue

Customer Relationship Management

Sales force automation, customer support, marketing, field service. The customer system of record.

READ

What it is

The module that records every customer-facing interaction — leads, opportunities, orders, service requests, marketing engagement, field visits. Often deployed alongside ERP rather than inside it (Salesforce, Dynamics CE, HubSpot), creating an integration boundary that is one of the most consequential architectural decisions of the programme.

The operating-model commitment

Where the customer master lives — CRM or ERP — sets a directional commitment. CRM-master designs lead with customer experience; ERP-master designs lead with financial integrity. Both can work; the wrong one for the business creates years of reconciliation pain. The same call applies to product master, pricing master, and contract terms.

Value streams in scope

Value Stream 01 · Lead-to-Order

From marketing signal to signed order

Lead Capture→Qualify→Opportunity→Quote/Propose→Negotiate→Close-Won

Outcome: A pipeline the CRO can forecast against, with conversion analytics that drive coaching, not just dashboards.

Value Stream 02 · Service-to-Resolution

From customer issue to satisfied resolution

Case Receipt→Triage→Assignment→Resolution→Confirmation→Feedback Loop

Outcome: CSAT/NPS that the CCO can defend; the patterns in case data become product/process improvements, not just tickets.

Value Stream 03 · Campaign-to-Conversion

From segment to attributable revenue

Audience→Campaign Design→Execution→Engagement Capture→Attribution

Outcome: Marketing spend the CFO can defend, with attribution that doesn't depend on the last touch alone.

Value Stream 04 · Dispatch-to-Done (Field Service)

From service request to completion

Service Request→Technician Dispatch→On-Site Service→Confirmation→Invoice

Outcome: Field operations the COO can plan against — and a feedback loop into asset reliability for EAM.

Components in scope

Sales Force Automation — lead capture, opportunity management, order closure.
Marketing Automation — campaign, targeting, execution, analytics.
Customer Support — ticketing, case management, resolution.
Field Service — dispatch, service provision, confirmation.

Where it goes wrong

Two customer masters survive go-live — one in CRM, one in ERP — and never reconcile. Pricing logic split across both, with neither fully authoritative. Marketing data treated as the same class as transactional customer data, then governed identically (or worse, governed differently and inconsistently). Field service treated as a CRM appendage when it should be a peer module.

Leader's question

"Where does the customer master live, and which other system reads from it — versus owns its own copy?"

Supply Chain Management

Inventory, order processing, procurement, logistics. The flow of goods through the business.

READ

What it is

The module that records, plans, and orchestrates every movement of goods — from supplier to inventory to order to shipment to customer. The most operationally visible module; if it stops, the business stops.

The operating-model commitment

The most consequential SCM commitments are made in master data: the item master, the BOM hierarchy, the location structure, the supplier master. They determine what can be planned, tracked, costed, and optimised. They also determine what is structurally invisible.

Value streams in scope

Value Stream 01 · Plan-to-Replenish

From demand signal to stock available

Demand Forecast→Supply Plan→Reorder Trigger→Procurement→Receipt→Stock Available

Outcome: Service levels held without inventory bloat. The eternal SCM tension — solved by data quality more than by sophisticated planning.

Value Stream 02 · Source-to-Contract

From need to signed supplier

Need→Supplier Discovery→Evaluation→Tender→Award→Contract→Onboarding

Outcome: A supplier base the CPO can defend; spend categories that consolidate over time rather than fragment.

Value Stream 03 · Order-to-Ship

From customer order to shipped goods

Order Receipt→Confirm→Pick→Pack→Ship→Track

Outcome: Reliable fulfilment performance — measurable, defensible to customers, costable per channel.

Value Stream 04 · Plan-to-Deliver (Logistics)

From route plan to customer-acknowledged delivery

Route Planning→Carrier Selection→Transport→Delivery→Returns/Reverse

Outcome: Logistics cost per unit, on-time delivery, and a returns pipeline that doesn't quietly leak margin.

Components in scope

Inventory Management — stock levels, locations, replenishment.
Order Processing — order-to-cash, picking, packing, shipping.
Procurement — vendor evaluation, contract, performance review.
Logistics — route planning, delivery, returns.

Where it goes wrong

Item master defined too narrowly — fields the business will need in three years are missing, and adding them later requires a full data refresh. Supplier master not deduplicated before migration, so spend analysis is permanently distorted. Inventory locations modelled after the warehouse layout instead of the operating decisions that need to be made about stock. Demand forecasting treated as a planning tool when it should be a planning conversation across S&OP.

Leader's question

"Does the item master support the decisions we expect to need in three years — or only the ones we make today?"

iii

Operations & Assets

Manufacturing

Production planning, materials, product lifecycle, quality control. Where physical work meets the system of record.

READ

What it is

The module that plans, schedules, executes, and verifies production. Translates demand signals into work orders, work orders into materials movements, materials movements into finished goods, finished goods into inventory. The most physically grounded module — every transaction has a counterpart in the real world.

The operating-model commitment

BOM design, routing structure, work-centre hierarchy, and costing method (standard, average, FIFO, actual) are the foundational manufacturing commitments. They determine what can be planned, what can be costed, what can be improved. Changing them post go-live often requires re-baselining historical performance.

Value streams in scope

Value Stream 01 · Design-to-Production

From product concept to production-ready BOM

Concept→Design→BOM Setup→Routing→Prototype→Production Release

Outcome: A BOM and routing that match shop-floor reality — and a PLM-to-ERP handover that doesn't lose engineering changes.

Value Stream 02 · Plan-to-Produce

From sales forecast to finished goods

Forecast→MPS→MRP→Work Order Release→Production Execution→FG Receipt

Outcome: A schedule the shop floor actually follows; variance analysis that drives improvement rather than blame.

Value Stream 03 · Quality-to-Confidence

From inspection to customer trust

Inspection Planning→Inspection→Non-Conformance→Corrective Action→Quality Reporting

Outcome: Defect rates that trend down; an audit trail the regulator and the customer both find sufficient.

Components in scope

Production Planning — forecasting, scheduling, work order release.
Materials Management — requisition, PO, receipt, replenishment.
Product Lifecycle Management — concept, design, prototype, launch.
Quality Control — inspection, non-conformance, reporting.

Where it goes wrong

Costing method chosen for ease of implementation rather than operational truth. Multi-level BOMs flattened to a single level for migration speed, destroying the ability to plan at sub-assembly. Work centres modelled to match the shop floor rather than the planning decisions that need to be made. PLM and ERP treated as the same system when they aren't.

Leader's question

"Does the costing method match how we actually decide where to invest — or only how we close the books?"

Enterprise Asset Management

Maintenance, asset lifecycle, work order management, energy. The system of record for physical infrastructure.

READ

What it is

The module that tracks every long-lived physical asset — pumps, trucks, transformers, network elements, buildings, plant — through its lifecycle. Schedules preventive maintenance, records work orders, captures condition data, and triggers replacement planning. In asset-heavy industries (utilities, mining, telco, transport), this module often eclipses Financials in operational importance.

The operating-model commitment

The asset hierarchy is the structural model of the physical business. Functional location vs equipment vs serialised component — each design choice determines what can be reported on, costed against, and predicted. The maintenance strategy (run-to-fail, time-based, condition-based, predictive) is an operating commitment, not a configuration toggle.

Value streams in scope

Value Stream 01 · Plan-to-Maintain

From asset risk to maintenance executed

Asset Hierarchy→Maintenance Strategy→PM Schedule→Work Order→Execute→Close-out

Outcome: Reliability that holds; maintenance spend defensible; failure modes trending down rather than discovered after the fact.

Value Stream 02 · Detect-to-Respond (Condition)

From anomaly signal to intervention

Sensor/Condition Data→Anomaly Detection→Triage→Work Order→Intervention→Feedback Loop

Outcome: A maintenance estate moving from time-based to condition-based, with the data layer mature enough to support it.

Value Stream 03 · Acquire-to-Retire (Physical)

From capex business case to asset disposal

Capex Plan→Procure→Commission→Operate→Renew/Refurbish→Retire

Outcome: An asset base costed end-to-end, with reinvestment decisions linked to performance rather than calendar.

Components in scope

Asset Lifecycle — acquisition, operation, retirement.
Preventive Maintenance — schedule, dispatch, completion.
Work Order Management — request, plan, execute, close.
Energy & Condition — monitoring, anomaly, prediction.

Where it goes wrong

Asset hierarchy migrated as-is from the legacy system, inheriting twenty years of accidental decisions. Maintenance strategy not declared up front, so the system defaults to time-based across the board — even for assets that should be on condition-based. Spare parts master not aligned with the item master in SCM, so the parts shortage in the field has no link to the procurement system. Condition data captured but never connected to work-order triggers.

Leader's question

"Is the maintenance strategy a deliberate choice per asset class — or a default we inherited because nobody decided?"

Programmes, Projects & Data

Project & Portfolio Management

Resource planning, project costing, WBS, billing. The system of record for project-funded work.

READ

What it is

The module that plans, costs, executes, and bills project-based work — common in services firms, capex-heavy enterprises, and any organisation where the unit of investment is “the project” rather than “the product.” In utility, infrastructure, and government settings, PPM is increasingly the system of record for the entire investment portfolio.

The operating-model commitment

PPM commits the enterprise to a single definition of what is a project, a single project hierarchy, and a single source of truth for project actuals. Where actuals come from — finance, time recording, supplier invoices — determines how much faith the organisation can place in project status. The integration to Financials is the consequential one; bad design here leaves PMs reconciling manually for years.

Value streams in scope

Value Stream 01 · Idea-to-Investment (Portfolio)

From candidate idea to funded programme

Idea Capture→Business Case→Prioritise→Fund→Initiate

Outcome: Portfolio choices the board can defend; investments sequenced for capacity, not just ambition.

Value Stream 02 · Plan-to-Deliver (Project)

From project setup to benefit realised

Project Setup→WBS→Resource Plan→Track Actuals→Forecast (ETC/EAC)→Close→Benefits Track

Outcome: A PMO that produces live cost & schedule truth — not month-end snapshots reconciled in spreadsheets.

Value Stream 03 · Resource-to-Utilisation

From capacity to billable/charged effort

Capacity Plan→Resource Request→Allocate→Track Utilisation→Replan

Outcome: A people picture matching the project picture; utilisation actionable rather than rear-view.

Value Stream 04 · Bill-to-Recognise

From billable work to recognised revenue

Billable Identification→Invoice→Payment→Revenue Recognition

Outcome: WIP that closes; revenue recognised cleanly; the link from time-recording to financial reality holds.

Components in scope

Resource Planning — capacity, request, allocation, utilisation.
Project Costing — budget, actuals, variance, forecast.
Work Breakdown Structure — decomposition, dependencies, progress.
Billing — billable identification, invoice generation, revenue.
Portfolio Management — investment prioritisation, sequencing, governance.

Where it goes wrong

Master data dual-managed between PPM and Finance, with reconciliation done in spreadsheets. Forecast methodology not declared (top-down vs bottom-up; ETC vs EAC), so two projects produce non-comparable forecasts. Project hierarchy mirrors the org chart, not the portfolio logic. Benefits tracking dropped after go-live because nobody owns it twelve months out.

Leader's question

"Is PPM the single source of truth for project actuals — or is it a second copy that finance has to reconcile?"

Data & Analytics

Reporting, BI, data warehousing, decision support. The layer that turns transactions into evidence.

READ

What it is

The layer that takes the structured outputs of every other module and assembles them into the views the business uses to decide — operational dashboards, financial close packs, regulatory submissions, executive scorecards, AI-enabled analytics. In modern stacks, this is rarely “a module” — it's a separate architecture (data lake, lakehouse, warehouse, BI layer) bolted onto the ERP.

The operating-model commitment

Where the analytical data lives — and who owns it — sets a directional commitment. ERP-native reporting keeps things simple but constrains analytical depth. A separate warehouse / lakehouse gives flexibility but introduces a second source of truth that has to be governed. The choice is structural; it locks in for years.

Value streams in scope

Value Stream 01 · Source-to-Insight

From transaction to decision-grade insight

Source Capture→Ingest→Cleanse→Model→Visualise→Decide

Outcome: Decisions made on evidence the data team can stand behind, with lineage traceable to source.

Value Stream 02 · Migrate-to-Steady-State

From legacy data to trustworthy ERP data

Profile→Cleanse→Map→Transform→Load→Reconcile→Validate

Outcome: A go-live data set the business can transact against — and a historical estate that doesn't poison future analytics. The one-time discipline that sets the steady-state quality ceiling for a decade.

Value Stream 03 · Govern-to-Trust

From data class to regulator-defensible record

Class Defined→Steward Named→Quality Rules→Monitoring→Remediation

Outcome: A data governance forum that decides — not just discusses; and a data quality picture executives can act on.

Components in scope

Data Models — schemas, lineage, ownership.
Data Warehousing — extraction, transformation, loading.
Business Intelligence — dashboards, visualisation, distribution.
Data Migration — the one-time discipline that sets every steady-state report's quality ceiling.
Data Governance — stewardship, quality, lifecycle, retention.

Where it goes wrong

Data migration treated as a technical activity, sequenced late, executed under deadline pressure — and the historical data the business needs for trend analysis ends up missing or wrong. Reporting requirements gathered after configuration is complete, so the data model has to be reshaped to fit them. AI initiatives launched before the data layer is governed. Stewards named but never given the authority to enforce.

Leader's question

"Will the data layer support the decisions we need to make in five years — or will we be re-platforming again to get AI to work?"

Cross-Cutting · The Disciplines That Decide Success

Integration

Middleware, APIs, events. The contractual layer between ERP and the rest of the estate.

READ

What it is

The architectural layer that connects ERP to every other system in the estate — payroll bureaus, banking, CRM, BI platforms, regulatory submission portals, MES on the shop floor, SCADA on the network, identity providers, the workforce app on someone's phone. Treated as plumbing in most programmes. Treated as a data-contract layer in the mature ones.

The operating-model commitment

The integration architecture is the structural commitment about who owns which data class and where it lives in real time. Direct point-to-point vs middleware vs event-driven streaming — each choice locks in years of operational behaviour. The integration catalogue (or its absence) is the artefact that separates an estate that can be understood from an estate held together by tribal knowledge.

Value streams in scope

Value Stream 01 · Specify-to-Live (Build)

From integration need to monitored production

Need→Contract Design→Build→Test→Deploy→Monitor

Outcome: Every integration in the catalogue, with a named owner, a documented contract, and an alert path. Nothing in the estate that lives only in someone's memory.

Value Stream 02 · Detect-to-Recover (Failure)

From integration failure to resumed flow

Alert→Triage→DLQ Inspection→Recovery Action→Replay→Post-mortem

Outcome: Integration failures recoverable in minutes, not days; learning loops back into design.

Components in scope

Middleware / iPaaS — MuleSoft, Boomi, Workato, Azure LogicApps.
API Management — gateway, throttling, versioning, contracts.
Event Streaming — Kafka, EventHub, Solace, Confluent.
Integration Catalogue — the register that prevents tribal knowledge.
Development Standards — patterns, naming, error handling, retry policy.
Environment Management — dev/test/UAT/prod, promotion gates.

Where it goes wrong

Integrations treated as a technical workstream, not as data contracts. No single catalogue — each integration documented in its own README. Happy path written, failure modes implicit. Direct point-to-point chosen for build speed, leaving an estate that becomes brittle as a third system is added. Middleware deployed but development standards never declared, so each integration is a snowflake.

Leader's question

"Is there a single, current integration catalogue I can be shown — or does each integration live in the memory of the person who built it?"

Security & Identity

RBAC, SoD, Zero Trust, disaster recovery, BCP. The structural answer to risk.

READ

What it is

Not a module in the vendor sense — a discipline that runs across every module. Determines who can do what without supervision, how identity is established, what evidence the auditor sees, and what happens when something is unavailable. Most programmes treat it as a workstream of compliance. Mature ones treat it as core to operating the system at all.

The operating-model commitment

The role design, the SoD matrix, the delegations framework, and the disaster-recovery posture are not technical settings. They are the structural answer to organisational risk appetite — and they encode it for years. Retrofitting controls onto a live system is exponentially more expensive than designing them in.

Value streams in scope

Value Stream 01 · Identity-to-Access

From person to least-privilege access

Identity Source (HR)→Role Assignment→Provisioning→Periodic Review→Deprovisioning

Outcome: Joiners get access fast; leavers lose it faster; access reviews are evidence, not theatre.

Value Stream 02 · Control-to-Evidence

From control objective to audit-ready evidence

Risk Defined→Control Designed→Encoded in System→Operate→Test→Evidence

Outcome: SOX / SOC2 / ISO27001 / regulator findings closed quickly because the evidence sits in the system, not a SharePoint folder.

Value Stream 03 · Detect-to-Continue (BCP/DR)

From disruption to restored service

Detect→Declare→Failover/Workaround→Restore→Post-incident Review

Outcome: RTO/RPO met; the business doesn't stop when an integration partner does; lessons learned land in the next design.

Components in scope

RBAC — role-based access, joiner/mover/leaver discipline.
SoD — segregation of duties across P2P, OTC, H2R.
Zero Trust — identity-anchored access, no implicit network trust.
Audit Trail — who, what, when, where, with what change.
Business Continuity Plan — operating-model continuity in declared disruption.
Disaster Recovery — technical recovery for the platform itself.

Where it goes wrong

Controls retrofitted in the final months pre go-live, when the cost is exponential and the resistance to redesign is highest. SoD designed as a theoretical matrix, never tested against actual user populations. Role design done by the implementation partner alone — meaning the business inherits a model it didn't shape. BCP/DR plans written but never exercised; failover discovered to be untested when the incident occurs.

Leader's question

"If a regulator asks me tomorrow to evidence joiner-mover-leaver and SoD across our top three value streams — can I, in five minutes, or in five weeks?"

PMO & Programme Governance

Scope, schedule, risk, change. The disciplines that decide whether the programme ships.

READ

What it is

Not part of the system — the system around the system. The programme-management discipline that decides whether the ERP gets built at all, on time, on scope, with the controls and change adoption that turn go-live into value. The reason most ERP programmes go over budget is not bad software — it is weak governance.

The operating-model commitment

The PMO encodes how the enterprise will govern any cross-functional transformation — not just this one. The scope discipline, the risk register cadence, the steering committee posture (governance vs status theatre), the decision-rights model — these outlast the programme and become the default for everything that follows.

Value streams in scope

Value Stream 01 · Initiate-to-Gate

From business case to conditional gate approval

Business Case→Scope→Plan→Resource→Gate Submission→Conditional Approval

Outcome: Gates that decide, not gates that congratulate. Each one ends with the conditions the next phase must satisfy.

Value Stream 02 · Track-to-Decide (Status)

From status capture to steering decision

Capture→Validate→RAID→PCG/SteerCo→Decision→Action Log

Outcome: Steering committees that close decisions, not extend them. Every meeting ends with named owners, dates, and decision log entries.

Value Stream 03 · Plan-to-Cutover (Go-Live)

From cutover plan to BAU operation

Cutover Plan→Dry Run→Go/No-Go→Cutover Execution→Hypercare→BAU Handover

Outcome: A go-live that doesn't become an emergency. Hypercare ends because operations is ready, not because the consulting budget ran out.

Components in scope

Scope & Requirements Management — the boundary the contract was signed on.
Schedule & Plan Management — phases, milestones, dependencies.
Risk & Issue Management — RAID with owners and trigger events.
Actions & Decisions Log — the spine of governance.
Vendor & Partner Management — SoW alignment, performance, escalation.
Cutover Toolkit — checklist, dry runs, dress rehearsal, hypercare design.
Test Planning — SIT, UAT, regression, performance, dress rehearsal.

Where it goes wrong

Steering committees become status theatre — long decks, no decisions. Scope drift absorbed as “minor adjustments” until the cumulative cost is enormous. Decisions made in corridors and never logged. Hypercare extended indefinitely because the operating-model handover never happened. Test cycles compressed under time pressure.

Leader's question

"Does each governance meeting end with named decisions and owners — or with a slide that says 'continue current course'?"

Change, People & Adoption

Stakeholders, training, communications, adoption. The discipline that decides whether the programme compounds.

READ

What it is

Not a module — the discipline that decides whether the system actually changes how the business operates. Most ERP programmes go technically live. Most don't compound. The difference is almost entirely about change management designed in as a peer discipline, not as a workstream that hands out training manuals.

The operating-model commitment

The change manager is the BA's pair — not the BA's successor at go-live. The pair work the same decisions: the BA tracks decision integrity in scope and design; the change manager tracks decision integrity in behaviour and adoption. The 30/60/90 day adoption checkpoints encode the commitment that the predicted operating-model change is happening, not just trained for.

Value streams in scope

Value Stream 01 · Awareness-to-Adoption

From announcement to behaviour changed

Awareness→Desire→Knowledge→Ability→Reinforcement

Outcome: Adoption measured in behaviour, not in training completion percentages. (Prosci ADKAR is the common reference model; the value stream holds regardless of which model you use.)

Value Stream 02 · Impact-to-Mitigation

From identified impact to landed change

Impact Assessment→Affected Groups→Mitigation Plan→Execute→Measure→Reinforce

Outcome: Change impact understood before it lands; mitigation rather than apology.

Value Stream 03 · Train-to-Capable

From training need to operational competence

TNA→Design→Deliver→Assess→Reinforce in BAU

Outcome: A workforce that can operate the system without the implementation partner in the room.

Components in scope

Stakeholder Engagement — map, influence, manage, persuade.
Change Impact Assessment — what changes for whom, by when.
Training — role-based, scenario-driven, reinforced post go-live.
Communications — campaign, channels, cadence.
Adoption Measurement — 30/60/90 checkpoints; behaviour-based metrics.
BAU Handover — the operating model post-hypercare.

Where it goes wrong

Change treated as a workstream, not a peer discipline. Training delivered, adoption assumed. Comms heavy on launch, light on reinforcement. Adoption measured in training completion percentages instead of behaviour. The change lead reports to the programme director instead of being paired with the sponsor — meaning bad news doesn't travel up.

Leader's question

"Six months after go-live, what evidence would say the predicted operating-model change actually happened — and is it appearing?"

The data layer · The spine of the system

Master Data & the Spine.

Master data is not a hygiene task. It is the spine the entire system stands on. Five classes do most of the load-bearing — and the discipline of governing them outlasts every module decision above.

Every operating-model commitment described in §01 ultimately lands in master data. The chart of accounts in Financials; the position structure in HCM; the customer master in CRM; the item master in SCM; the asset hierarchy in EAM; the project hierarchy in PPM. If the master data is wrong, every downstream report, control, and integration is wrong. If it is contested between modules, the contest becomes the day-to-day work of operating the business.

The five classes that carry the load

Most enterprises have dozens of master data classes; five do the heavy lifting. Each carries a structural commitment that has to be made — and held — by a named owner with executive authority. Master data without an executive owner drifts within twelve months of go-live.

Class	What it commits	Executive owner	Breaks when
Chart of accounts	How every transaction is coded, sliced, and reported.	CFO	Designed by finance alone, without the operating side.
Org structure & positions	How the workforce is recorded, costed, and reorganised.	CHRO	Position management vs person-centric decided late.
Customer master	Who the business transacts with on the revenue side.	CCO or CRO	Two masters survive go-live (CRM + ERP).
Item / Product master	What the business sells, makes, stocks, or services.	COO or Head of Product	Fields scoped narrowly; new classifications needed within two years.
Vendor master	Who the business transacts with on the supply side.	CFO or CPO	Not deduplicated pre-migration — spend analysis permanently distorted.

The governance question, asked properly

Most master data governance fails because the question is asked wrong. It is asked as “who maintains the records?” — which is an operational task. It should be asked as “who can change the structure?” — which is an executive decision. Adding a new GL account is an operational task; changing the hierarchy is an executive one. The leader's job is to make sure that distinction is encoded into the data governance model from day one.

The connective tissue · How systems talk

The Integration Layer.

Integration is not plumbing. It is the contractual layer between systems — and the layer most enterprises under-design until it breaks something the regulator notices. Three patterns cover most needs; the discipline that makes them work is the same in all three.

Every ERP integration is a data contract between two systems. The contract names what data flows, in which direction, at what frequency, with what idempotency, and with what recovery path when something fails. Most enterprise integration estates have the happy path documented and the failure modes implicit — which is why they break expensively and recover slowly.

The three patterns

Pattern 01

Direct point-to-point

Source system writes directly to target. Simple to build, simple to fail. Justifiable only between two systems that will never need to talk to a third.

Use when: low volume, two systems, no change horizon.

READ

Responsibilities — what this pattern owns

One source, one target — a bilateral data contract, no broker.
Build & maintain the connection — usually a scheduled job or direct API call.
Handle failure modes locally — retry, alert, dead-letter — all within one of the two systems.
Document the contract in both systems' documentation, kept synchronised.

Deliverables per integration

Data contract specification — direction, payload, frequency, volume, trigger, idempotency.
Error handling & retry policy — including dead-letter destination and alert threshold.
Operational runbook — what to do when this integration fails at 2am.
Test cases — happy path AND failure path.
Catalogue entry — in the integration register.

Where it goes wrong

Chosen for build speed, not architectural fit. Two systems become three, then four — and each direct connection multiplies fragility.

Happy path documented, failure modes implicit. The first 3am incident discovers what wasn't written down.

No catalogue entry. The integration lives in someone's head. When they leave, the integration becomes an artefact.

Idempotency not declared. Retry produces duplicates; reconciliation breaks silently.

Strategies that work

Use sparingly and deliberately. Two systems, low volume, no change horizon — fine. Anything else, reach for iPaaS.

Write the failure path before the happy path. What happens when target is unavailable? When payload is malformed?

Idempotency by design. Every payload has a unique key; the target rejects duplicates.

Register in the integration catalogue the day it goes live — not when it breaks.

Pattern 02

Middleware / iPaaS

A central integration platform (MuleSoft, Boomi, Workato, Azure LogicApps) brokers between systems. Higher up-front investment; pays back the moment a third system needs to be added.

Use when: more than two systems, regulatory traceability needed, change horizon longer than three years.

READ

Responsibilities — what this pattern owns

Mediates between source and target — protocol translation, payload transformation, routing.
Centralises error handling, monitoring, retry — one place to look when something fails.
Owns the integration catalogue — every flow registered, owned, monitored.
Enforces standards — naming conventions, API design, security, payload structure.
Provides traceability — every transaction loggable, replayable, auditable.

Deliverables (platform-level)

iPaaS platform stood up — with environments (dev / test / UAT / prod), pipelines, deployment standards.
Integration patterns library — reusable templates for common flows.
Naming & API design standards — REST, payload schemas, error codes.
Monitoring & alerting framework — per integration, with SLA.
Integration catalogue — single source of truth, kept current.
Per-integration deliverables — data contract, runbook, test cases, catalogue entry.

Where it goes wrong

Platform deployed, standards never declared. Each integration is a snowflake; the platform is just a more expensive way to do point-to-point.

Owned by the implementation partner — meaning the standards leave when they do.

Catalogue starts strong, drifts — new integrations registered, retired ones never removed, mappings go stale.

Treated as IT infrastructure — funded as platform cost, but governed nowhere. Strategy moves; iPaaS doesn't.

Strategies that work

Declare standards before building integrations. Naming, error codes, payload structure — written, approved, enforced.

Enterprise architecture owns the platform — partner contributes, doesn't dictate.

Catalogue is the source of truth — quarterly reviewed, retired flows removed, mappings refreshed.

Funded as a product, not infrastructure — with a named owner, backlog, release cadence.

Pattern 03

Event-driven / streaming

Systems publish events to a stream; subscribers consume them as needed. The most flexible pattern; the highest engineering bar to operate.

Use when: real-time decisions, high volume, distributed estate, mature platform team.

READ

Responsibilities — what this pattern owns

Publishes events to a stream (Kafka, Kinesis, Pub/Sub) — producer doesn't know who consumes.
Subscribers consume independently — at their own pace, with their own state.
Event schema is the contract — versioned, evolved with discipline (additive changes, deprecation windows).
Operates at high engineering maturity — observability, replay, schema registry, dead-letter handling.

Deliverables

Event platform — broker, schema registry, monitoring, alerting.
Event catalogue — every published event, its schema, its producer, its known consumers.
Schema evolution policy — additive change rules, deprecation windows, breaking-change governance.
Consumer SLAs — what each subscriber commits to processing, by when.
Replay & recovery playbook — how to recover when a consumer falls behind.

Where it goes wrong

Adopted because it sounds modern, not because the use case justifies it. Operational complexity drowns the engineering team.

Schemas evolved without discipline — breaking changes ship; consumers fail in production.

No schema registry — schemas live in code; nobody can answer "what events do we publish."

Consumer SLAs not declared — when one consumer falls behind, the whole estate is affected.

Strategies that work

Use only when the use case demands it — real-time, high volume, distributed. Otherwise iPaaS.

Schema-first discipline — every event has a versioned schema in a registry before publish.

Backwards-compatible by default — additive changes only; breaking changes are deprecation programmes.

Mature ops — observability, alerting on consumer lag, dead-letter handling, replay tooling.

The estate is hybrid

Most mature enterprises run all three — direct for legacy odds-and-ends, middleware for the system-of-record traffic, streaming for the operational real-time layer. The estate is not a single decision; it is a portfolio. Owned by enterprise architecture. Reviewed annually, not at programme end.

The integrations every ERP estate has

Beyond the pattern choice, there is a catalogue of flows every ERP implementation will need — and most enterprises rediscover painfully when they thought they'd scoped “ten integrations” and ended up building thirty. The list below is the practitioner's baseline: the flows that show up in nearly every estate, what data they carry, the pattern they typically use, and the failure mode specific to each. Use this as a starting catalogue, not an exhaustive one.

Flow	Direction & payload	Typical pattern	Specific failure mode
ERP ↔ Banking	Outbound payment files (ABA, PAIN, BACS, NACHA, SWIFT MT/ISO 20022) — payroll, AP, treasury runs. Inbound bank statements (MT940, CAMT.053) for reconciliation.	iPaaS or direct, with SFTP / host-to-host. Increasingly real-time APIs (Open Banking).	Idempotency on payment files (duplicate run = duplicate payment); reconciliation drift when statement format changes; cutoff windows missed at month-end.
ERP ↔ Payroll-to-Bank	Net pay file per cycle from HCM/payroll → bank. Confirmation back. The flow that cannot fail.	Direct SFTP under heaviest governance, or iPaaS with payroll-specific routing.	EBA / award changes invalidate cycle; bank holidays misaligned; superannuation file mismatched; payroll cycle date collides with cutover.
ERP ↔ CRM (customer master)	Customer create/update bidirectional. Pricing, contracts, credit terms typically ERP-mastered. Marketing data CRM-mastered.	iPaaS with event triggers, or middleware-mediated change capture. Real-time read; near-real-time write.	Two customer masters silently diverge. Pricing in CRM doesn't match ERP. The customer service rep quotes one number; the invoice shows another.
ERP ↔ HCM (workforce master)	Position, employee, cost centre, supervisor hierarchy from HCM. Time, expense, billable allocations from ERP. Often the same vendor across both.	Native vendor connectors where available; iPaaS where not. JML triggers downstream access changes.	Position changes lag behind employee changes; cost-centre re-orgs create orphaned charges; manager hierarchy in HCM doesn't match ERP approver workflow.
ERP ↔ Identity Provider (IdP)	SSO authentication outbound. JML provisioning inbound from HCM, propagated to ERP via SCIM or vendor connector. Role mapping per RBAC model.	SAML / OIDC for SSO; SCIM or vendor JML connector for provisioning.	Leaver retains ERP access for days; role mapping drift; MFA enforcement bypass on legacy authentication paths.
ERP ↔ ITSM (asset, incident, change)	Asset master from ERP/EAM → ITSM CMDB. Incidents and changes raised in ITSM, sometimes triggering ERP transactions (work orders, asset retirements).	iPaaS or vendor connector (ServiceNow ↔ SAP/Workday is well-trodden).	CMDB and EAM asset hierarchies diverge; incidents reference assets that don't exist in ITSM; change records don't carry through to ERP audit trail.
ERP ↔ BI / lakehouse	Outbound: GL balances, sub-ledger detail, master data, transactional fact tables. Inbound: rare; sometimes back-feed of forecasts or reference data.	Scheduled batch extracts (incremental where possible) into Snowflake / Databricks / Fabric / BigQuery. CDC for high-volume tables.	Extracts done without contracts — every report has its own version of the truth. Lineage from dashboard back to source ledger is lost. Reconciliation drift between ERP and reporting layer.
ERP ↔ Document management	Outbound document references (PO PDFs, invoices, contracts). Inbound metadata-only references back, so the ERP record links to the document store.	iPaaS or vendor connector (SharePoint, Box, OpenText). Storage stays in DMS; ERP carries the pointer.	Document store and ERP record diverge; document deleted in DMS but referenced in ERP; retention policies inconsistent between systems.
ERP ↔ Tax authority	Outbound submissions: BAS/GST returns, payroll tax, withholding, e-invoicing where mandated (PEPPOL, SAF-T, SII, GSTIN). Inbound: acknowledgements, audit queries.	Direct via certified gateway, or iPaaS with tax-specific connector (Avalara, Vertex, OneSource).	Tax rules change mid-cycle; jurisdiction logic encoded too rigidly; submission window missed; reconciliation between submitted and recorded amounts breaks.
ERP ↔ Regulator / industry body	Industry-specific submissions: APRA / ASIC / FCA / SEC for finance; AEMO / Ofgem / FERC for energy; TGA / FDA / EMA for life sciences. Inbound directives.	Direct gateway integration (regulators rarely accept iPaaS-mediated traffic). Tightly version-controlled.	Schema changes by regulator with short notice; submission fails on a single record; remediation cost dominates implementation cost of the integration itself.
ERP ↔ Supplier portal / e-procurement	Outbound POs, inbound invoices, supplier master sync. Increasingly via standards (cXML, EDIFACT, PEPPOL).	iPaaS with supplier-network connector (Ariba, Coupa, Tradeshift). Sometimes direct EDI for high-volume suppliers.	Supplier master drift; invoice matching tolerance too tight or too loose; e-invoicing mandate adoption lags supplier readiness.
ERP ↔ Operational systems (OT, SCADA, MES, telematics, IoT)	Production data, asset condition, telematics readings, field-service updates feeding into ERP work orders, asset records, inventory movements.	Event-driven / streaming for high volume; iPaaS for lower frequency. Edge gateway often involved.	Time-series data overwhelms transactional storage; ERP becomes the bottleneck in real-time decisions; OT/IT security boundary breached by integration.

A typical mid-size ERP estate runs 25–60 integrations across these categories. A large enterprise estate runs into the hundreds. Each is a data contract; each is a potential incident; each needs a named owner. The number is less important than the discipline of treating each as a managed asset rather than as plumbing.

The contract every integration must declare

An integration without a declared contract is a future incident with no owner. Every integration in scope should specify, in writing: direction, trigger, payload, frequency, volume, idempotency, error handling, retry policy, dead-letter queue, alert thresholds, and recovery procedure. The integration catalogue — a single register of every integration in the estate — is the artefact that turns this from theory into operational reality.

Leader's question

"Is there a single, current integration catalogue I can be shown — or does each integration live in the memory of the person who built it?"

The controls fabric · Who can do what without supervision

Governance & Controls.

Most ERP programmes treat controls as a compliance afterthought. The mature ones treat controls as the structural layer that determines whether the organisation can be run at scale at all.

The controls fabric — segregation of duties, role-based access, approval routing, audit trail, delegations — answers a single operational question: who can do what without supervision? In a small organisation, the answer is “the people we trust.” In an enterprise, the answer has to be encoded in software because the human supervision model does not scale. The ERP is the place this gets encoded.

The four disciplines

Discipline 01

Segregation of Duties (SoD)

No single role can complete a transaction end-to-end where the value is material. P2P, H2P, OTC — each has standard SoD splits. Violations are structural, not config bugs.

Owned by: internal audit + finance. Designed up front; tested at every release.

READ

Responsibilities — what the discipline owns

Defines the SoD matrix — which task combinations are toxic, per value stream (P2P, OTC, H2P, GL, master data).
Designs roles against the matrix — not after it. Conflict-free by construction where possible.
Tests SoD on the real user population — not just the theoretical model.
Monitors continuously — point-in-time review is not enough. Each user-access change is tested against the matrix.
Documents accepted residual risk — where business size or specialism forces a violation, named accountable accepts and compensating controls are designed.

Deliverables

SoD matrix — per value stream, conflict pairs identified.
Role design pack — roles aligned to the matrix.
SoD test reports — pre-go-live and on every release.
Continuous monitoring tool — integrated with provisioning.
Compensating controls register — for accepted residual risk.
Annual SoD attestation — to internal audit and external auditor.

Where it goes wrong

SoD designed as a theoretical matrix, never tested against the actual user population.

Roles designed first, SoD checked later — meaning conflicts accumulate before discovery.

Point-in-time review only. Between reviews, access drifts; conflicts compound silently.

Compensating controls undocumented — accepted residual risk that nobody can name when the regulator asks.

Strategies that work

Conflict-free by design. Roles built against the matrix from the start.

Continuous monitoring with automated alerts on any access change that creates a conflict.

Quarterly review forum — risk + audit + business owners — where exceptions are inspected, not just totals reported.

Compensating controls written, owned, evidenced — so residual risk is defensible.

Discipline 02

Role-Based Access Control (RBAC)

Access granted by role, not by individual. Roles defined by job family, not by exception. Joiners inherit; leavers are removed automatically. The opposite is access creep, and it always wins given enough time.

Owned by: security + HR. Reviewed quarterly; certified annually.

READ

Responsibilities — what the discipline owns

Defines roles by job family — not by individual exception. Roles describe what the job needs, not what this person inherited.
Drives joiner-mover-leaver from HR system — access provisioning automated, not manual.
Owns periodic access certification — quarterly by manager, annually by business owner.
Manages privileged access separately — break-glass, time-bound, logged, reviewed.
Integrates with the identity provider — single sign-on, MFA, conditional access.

Deliverables

Role catalogue — roles per job family, with the permissions each role carries.
JML automation — HR → access changes within agreed SLA (joiner same-day; leaver same-hour).
Quarterly access review reports — manager certification, with named accountable.
Privileged access register — who has what, when, why, time-bound.
IdP integration design — SSO, MFA, conditional access rules.

Where it goes wrong

Roles defined by exception, not by job family. Each new joiner needs a custom mapping; access creep is inevitable.

JML manual. Leavers retain access for days or weeks; access certification finds them eventually.

Privileged access never reviewed. Break-glass accounts become permanent.

Access certification as a tick-box. Managers approve in bulk without inspecting.

Strategies that work

HR-driven JML automation — every access change traceable to a position event.

Role catalogue published — managers can see what each role grants before assigning.

Privileged access time-bound — every grant expires; renewal requires justification.

Access certification with bite — managers attest individually, sampled by audit.

Discipline 03

Approval & Delegation Framework

The matrix of who can approve what, at which value, under whose delegation. Encoded in workflow, not in policy documents. Updated as delegations change, not as people change roles.

Owned by: CFO + General Counsel. Synced with the delegations register.

READ

Responsibilities — what the discipline owns

Defines the approval matrix — who approves what, at what value, in what category (capex, opex, payment, contract, HR action).
Encodes it in workflow — not in policy documents that nobody reads.
Synchronises with the delegations register — Board → CEO → Exec → Manager — kept current.
Handles delegate-when-away — temporary delegation rules, with explicit consent and audit.
Tests the framework — periodic walkthroughs to confirm what's in workflow matches what's in the register.

Deliverables

Approval matrix — by category, value band, role.
Workflow configuration — encoding the matrix in the ERP.
Delegations register — live, kept synced.
Delegation-when-away protocol — system-supported.
Annual reconciliation — workflow vs register vs reality.

Where it goes wrong

Policy document and workflow diverge. The system approves what policy doesn't permit, or vice versa.

Delegations changed in register, not in workflow — and discovered by exception.

Delegate-when-away handled manually by routing emails — audit trail collapses.

Approval routes bypass-able via finance overrides nobody reviews.

Strategies that work

Workflow is the source of truth. Policy document references the workflow, not the other way around.

Delegations register synced quarterly with workflow — discrepancies reconciled.

Delegate-when-away handled in-system — every delegation logged, time-bound, audited.

Override paths logged and reviewed — exceptions are reported, not buried.

Discipline 04

Audit Trail & Evidence

Every material event is logged: who, what, when, from where, with what change. The audit trail is the regulator's primary evidence — and the auditor's. Retention is a regulatory commitment, not a storage decision.

Owned by: risk + compliance. Tested in dry-run before go-live.

READ

Responsibilities — what the discipline owns

Decides the audit-trail granularity — which events are logged, with which fields, to which retention.
Owns retention policy — driven by regulatory commitments (often 7 years, sometimes longer), not by storage cost.
Makes the trail queryable — auditor must be able to pull evidence by user, by transaction type, by date range, by value band, in minutes not weeks.
Tests the audit trail pre-go-live — dry-run exercise with internal audit to confirm.
Owns the chain of custody — once written, audit-trail data is immutable.

Deliverables

Audit-trail design specification — events, fields, retention.
Query & reporting framework — auditor self-service where appropriate.
Retention & immutability policy — signed by Legal + Compliance.
Pre-go-live dry-run report — auditor's evidence-request walkthrough.
Annual audit-trail attestation — to internal audit and regulator where applicable.

Where it goes wrong

Audit trail is technical logging, not business evidence. Auditor asks for evidence of an approval; the response is a database dump nobody can interpret.

Retention defaulted to storage convenience — too short for regulator, too long for cost.

Trail mutable — entries can be edited or deleted; chain of custody broken.

Never tested before go-live — first real evidence request fails in production.

Strategies that work

Trail designed for the auditor, not the database admin. Events tagged in business language; queryable by audit roles.

Retention set against regulatory commitments, signed by Legal, costed accordingly.

Immutability enforced — once written, audit data cannot be modified.

Pre-go-live dry-run with internal audit. The first real evidence request is the second time the system has been exercised.

Where controls go wrong

Almost always: they are built late. Controls retrofitted onto a system that is already live are exponentially more expensive than controls designed in. The same is true of the data layer; controls and master data are the two areas where front-loading the investment pays back most reliably, and where most programmes economise — and regret it within two years.

Context · What changes by sector

Industry Dial-ups.

The thesis and the anatomy are universal. The dial-ups are not. Ten sectors below — each names which modules dominate, which controls intensify, which integration patterns are mandatory, and where the operating-model commitments hide.

Utilities & Water

Asset-heavy, regulated, customer-facing, capex-intensive.

READ

Modules that dominate

EAM is the operational centre, often eclipsing Financials. PPM carries the capex portfolio — the regulator-watched investment story. CRM-billing carries the customer accounts. Financials, HCM, SCM remain peers.

Controls that intensify

Regulator submission integrity (price submissions, performance reports, safety reports). Field crew safety controls. Capex governance under economic regulation.

Integration patterns mandatory

SCADA / OT integration. GIS integration for spatial asset data. Field workforce / mobile integration. Regulator submission portals. Smart meter platforms.

SCADAGISAMIRegulator

Where it hides

The line between operational tech (OT) and information tech (IT). What lives in the EAM versus the OT historian. The model for distinguishing “regulated” vs “non-regulated” activity inside the chart of accounts.

Financial Services

Regulated, audit-intensive, customer-data-rich, integration-heavy.

READ

Modules that dominate

CRM (customer master, KYC, suitability), Financials (general ledger, reconciliation, regulatory reporting), HCM (compliance training, conflicts management). Manufacturing/SCM/EAM rarely present.

Controls that intensify

SoD for trade life cycle. KYC/AML evidence. Reg reporting accuracy (APRA / ASIC / Basel III). Records retention and trade reconstruction. Conduct & conflicts controls.

Integration patterns mandatory

Real-time event streams for trade and balance. Market data feeds. Regulatory submission platforms. Identity providers (B2C and B2B).

Event-drivenReal-timeMarket dataReg portals

Where it hides

The boundary between ERP and the trading/banking platforms. ERP rarely is the system of record for financial product transactions — but is the system of record for the firm's own books. Confusion between the two is endemic and expensive.

Government & Public Sector

Procurement-heavy, citizen-facing, transparency-driven, governance-intensive.

READ

Modules that dominate

Financials with strong fund-accounting / appropriation tracking. SCM with procurement-policy intensity. HCM under public-sector EBA complexity. PPM for capex portfolios under parliamentary scrutiny.

Controls that intensify

Procurement probity controls. Appropriation-line accounting. FOI / records retention. Conflict of interest declarations. Auditor-general reporting.

Integration patterns mandatory

Whole-of-government identity (myGov-style). Whole-of-government procurement platforms. Treasury / consolidated-reporting platforms. Citizen-facing portals.

WoG IdentityWoG ProcureTreasury

Where it hides

Appropriation logic does not map naturally to commercial GL structures. The chart of accounts has to carry both — and one of them usually wins, leaving the other as a workaround. Whichever wins, the loser stays a problem for a decade.

Manufacturing & Industrial

BOM-driven, capex-heavy, supply-chain-intensive, quality-regulated.

READ

Modules that dominate

Manufacturing (BOM, routing, MES integration), SCM (procurement, inventory, logistics), EAM (plant maintenance), Financials with strong cost-accounting. CRM presence depends on B2B vs B2C.

Controls that intensify

Quality compliance (ISO9001, automotive IATF, food HACCP/FSMA). Engineering change control. Costing accuracy (standard vs actual). Inventory accuracy targets.

Integration patterns mandatory

MES integration. PLM-to-ERP for engineering changes. WMS for warehouse execution. Supplier portal / EDI for procurement. Quality systems integration.

MESPLMWMSEDI

Where it hides

Costing method choice (standard vs actual vs hybrid) is the long-tail decision. Multi-level BOM management is rarely strong out of the box; most enterprises end up with PLM as the BOM master and ERP as the costing master.

Healthcare & Aged Care

Workforce-intensive, regulator-intensive, person-data-sensitive, billing-complex.

READ

Modules that dominate

HCM with intense rostering / award complexity. Financials with funding-source accounting. SCM for medical / consumable inventory. PPM for capex (clinical facilities).

Controls that intensify

Patient / resident data confidentiality. Clinical-credentialling controls. Medication chain of custody. Funding-source accuracy (NDIS, Medicare, private). Aged-care subsidy compliance.

Integration patterns mandatory

Clinical / EMR systems. Rostering / workforce scheduling. Medication management. Funder claim platforms. Identity (clinician credentialling).

EMRRosterPharmacyFunder

Where it hides

The boundary between clinical and corporate systems is contested — patient data lives in EMR but feeds funder claims that live in ERP. Mistakes leak both ways: under-claimed revenue, or privacy breach.

Professional Services & Consulting

People-as-product, project-funded, billing-driven, lightweight on physical assets.

READ

Modules that dominate

PPM is centre-stage — time recording, project profitability, resource utilisation, WIP. CRM for opportunity-to-billing. HCM for the workforce P&L. Financials carries revenue recognition complexity.

Controls that intensify

Time-recording integrity (utilisation, billability). Revenue recognition under IFRS 15. Independence and conflict of interest. Client-deliverable confidentiality.

Integration patterns mandatory

Time-recording tools. Expense management. Document and collaboration platforms. Client portals. AI-augmented productivity tooling — increasingly material to billable hours.

TimeExpenseDocsPortals

Where it hides

Resource utilisation reporting is rarely the same number in two systems. The PPM-to-Financials link for WIP and revenue recognition is the long-running pain point. Whoever owns “the utilisation number” effectively runs the firm.

Retail & Wholesale

Margin-thin, channel-multi, inventory-fast, customer-data-rich.

READ

Modules that dominate

SCM (inventory, replenishment, planning), CRM (loyalty, segmentation, channel), Financials (margin, gross profit, channel profitability). HCM with rostering complexity in retail.

Controls that intensify

Inventory shrinkage / loss prevention. Channel revenue recognition. POS reconciliation. PCI-DSS for payment data. Promotional spend control.

Integration patterns mandatory

POS integration. E-commerce platform integration. Payments platforms. Loyalty programmes. Marketplace integrations (Amazon, eBay, etc.). WMS for distribution.

POSe-commPaymentsMarketplacesWMS

Where it hides

Channel profitability is rarely the same in two reports. Returns / reverse logistics quietly erode reported margin. The product master commonly has different attributes in different channels — and nobody owns reconciliation.

Aerospace & Defence

Program-cost accounting, configuration management, classified-environment delivery, regulator-and-government-as-customer.

READ

Modules that dominate

PPM at the deepest level — multi-year programs, contract-cost reporting, EAC/ETC discipline. Manufacturing with serialised configuration management (every component traceable through its lifecycle). Financials with government cost accounting standards (CAS in the US; equivalent regimes elsewhere). EAM for in-service fleet support.

Controls that intensify

ITAR / EAR export controls — data residency, user clearance, vendor citizenship all become system-level constraints. Configuration management discipline (which exact part with which exact revision flew on which exact aircraft). DCAA / NAO / equivalent audit posture continuous, not annual. Segregation of duties extends to clearance-level segregation.

Integration patterns mandatory

PLM / CAD systems (Teamcenter, Windchill, ENOVIA) deeply integrated with manufacturing and supply chain. Customer collaboration platforms with government agencies. Classified-environment instances of the ERP often required (air-gapped or sovereign-cloud deployments). Supplier networks subject to export-control validation.

PLMMESITARCASEAM

Where it hides

Configuration management drift — the as-designed, as-built, and as-maintained records diverge silently over time. Program cost allocations that satisfy CAS but obscure operational truth. Classified ERP environments that fall behind their unclassified counterparts because patching is harder, then become the most vulnerable systems in the estate. Multi-tier supplier compliance gaps that surface during audit.

Oil & Gas

Joint venture accounting, lease/well master data, HSE-integrated operations, commodity-price exposure, capital intensity.

READ

Modules that dominate

Financials with full Joint Venture Accounting — operating-partner-as-customer / non-operating-partner-as-supplier dynamics across the same well, with cash calls, billing statements, audit rights. EAM at extreme depth for upstream and downstream assets. PPM for capital projects measured in years and billions. SCM for offshore / remote-site logistics. Production accounting and allocation as its own sub-discipline.

Controls that intensify

Health, safety, environment integrated into every transaction (work order can't be released without competent-person sign-off; chemical inventory triggers regulatory thresholds). Production allocation across multiple lease holders — every barrel attributed correctly or someone gets sued. Royalty calculations to government, traditional owners, mineral rights holders. SOX / equivalent regimes for upstream/downstream public companies.

Integration patterns mandatory

SCADA / production-monitoring systems from the wellhead and refinery. Joint Venture partner systems (often legacy, often inflexible). Commodity trading and risk management (CTRM) platforms. Regulator and government royalty submission gateways. Aviation / marine logistics for offshore operations. Hydrocarbon accounting and product allocation engines.

SCADACTRMJVRoyaltyHSE

Where it hides

Joint venture accounting complexity is consistently under-estimated at implementation. Lease/well master data hierarchy carries decades of historical accidents. Production allocation methodologies vary by basin, by partner, by contract — and there is no single source of truth. The hand-off between SCADA-measured volumes and ERP-recorded volumes is where the most expensive reconciliation drift lives.

Mining & Resources

Ore-body master data, FIFO workforce, royalty regimes, fleet-and-fixed-plant maintenance, environmental obligations.

READ

Modules that dominate

EAM at extreme depth for haul-truck fleets, draglines, conveyor systems, processing plant — assets worth millions, with maintenance regimes measured in operating hours and cycles. SCM for explosives, fuel, tyres, reagents — supply chain into remote sites is its own discipline. HCM with FIFO rosters, fatigue management, and cross-border workforce rules. Financials with royalty calculations, depletion accounting, and rehabilitation provisions.

Controls that intensify

Mine plan reconciliation — what was scheduled, what was actually mined, what was processed, what was sold. Royalties to state, federal, traditional owners (in jurisdictions where applicable), with rates that vary by commodity, by grade, by tonnage band. Environmental and rehabilitation obligations capitalised and tracked across asset life. Permit and licence compliance — operations can be stopped by a single document expiring.

Integration patterns mandatory

Fleet Management Systems (Modular Mining, Wenco) feeding production volumes and equipment utilisation. Mine planning tools (Vulcan, Surpac) for ore-body model and short-term schedule. Laboratory information management systems (LIMS) for grade and assay. Weighbridge and shipment systems for product despatch. Regulator and royalty-authority gateways.

FMSLIMSMine PlanWeighbridgeRoyalty

Where it hides

Reconciliation between mine plan, production, processing, and sales has a chain of variances; each variance is a financial impact and a regulatory disclosure. Equipment maintenance regimes treated as IT-system data when they are operating-model decisions about asset life and risk. FIFO roster complexity collides with payroll cycle assumptions designed for office workforces. Rehabilitation provisions estimated once and never revisited until they're due.

Who owns what · The decision-rights map

Roles & Decision Rights.

An ERP programme involves more named accountabilities than any other transformation. The map below names eighteen — what each is for, what they own, and where they go wrong.

Every role below corresponds to a class of decision the programme will encounter. “The steering committee” is not a role — it is an escalation point. A role is a named person, accountable for a class of decision, who can be cited when the decision was made and re-cited when the decision needs to be re-opened.

SPONSOR

The Executive Sponsor

READ

Usually CEO, CFO, COO, or business-unit MD

Owns the business case and its kill criteria. The person who declares whether the programme keeps going, scales back, or stops. Accountable for the benefit twelve months post go-live — not just for go-live itself.

OwnsThe investment thesis, the operating-model commitments, the benefit twelve months out.

Responsibilities

Decides the operating-model commitments — chart of accounts shape, master data ownership, integration architecture, controls fabric, post go-live model. In writing.
Chairs the steering committee / PCG — every meeting, present, prepared, with the authority to close decisions in the room.
Holds the kill criterion — declares scale-back or stop if the criterion fires. The only person who can.
Re-confirms the benefit owner — at every executive change, at every benefits review, at every contract renewal.
Defends the programme externally — to the board, to the regulator, to the public if it's that kind of programme.
Holds the Programme Director accountable — and protects them from political weather they shouldn't be navigating alone.

Deliverables

Signed business case & decision pack — including kill criteria and benefit owner twelve months out.
Signed operating-model commitments — the five compounding decisions (§13) explicitly owned.
Approved gate submissions — at each of the six phases.
Quarterly benefits review attestation — through to year five.
Executive briefings — to ELT, board, regulator on a defined cadence.
Closure attestation — formal sign-off when the benefit owner takes over BAU.

CFO

The Chief Financial Officer

READ

Often co-sponsor on finance-led programmes

Owns the chart of accounts, the controls fabric, the cash position post go-live, and the regulatory reporting integrity. Has approval rights over capex and significant scope decisions.

OwnsCoA, financial controls, treasury integrity, regulatory reporting.

Responsibilities

Designs the chart of accounts — with the operating side in the room, not finance alone. The structural commitment to how the business will be costed and reported for the next decade.
Owns the financial controls fabric — SoD across P2P, OTC, H2P; approval routing; delegations; reconciliation discipline.
Approves the financial design — sub-ledger architecture, posting logic, period-end close mechanics, multi-entity / multi-currency / multi-tax positions.
Guards the regulatory reporting integrity — statutory submissions, tax, audit. The line that cannot fail.
Owns the capex and budget decisions — including kill criteria on cost overruns.
Co-chairs PCG with the Sponsor on finance-led programmes; voting member otherwise.

Deliverables

Approved chart of accounts & cost-centre hierarchy with traceability to the operating model.
Financial controls matrix — controls per value stream, with owner, frequency, evidence location.
Regulatory reporting blueprint — every statutory output, with source data, calculation, sign-off path.
Period-end close playbook — sequence, ownership, exception handling.
Capex / budget oversight reports — at PCG cadence.
Year-end audit liaison pack — what the platform produces; reconciliations; sub-ledger ties.

CHRO

The Chief Human Resources Officer

READ

Lead voice on HCM-anchored programmes

Owns the org structure, the position management model, the EBA interpretation logic, and the workforce data integrity. Accountable that payroll lands every cycle from go-live forward.

OwnsOrg structure, position management, payroll integrity, EBA logic.

Responsibilities

Decides position management vs employee-centric design — the foundational HCM call. ADR-worthy (§11).
Owns the org structure model — reporting lines, position hierarchy, location structure, cost-centre alignment with finance.
Approves the award & EBA interpretation logic — including custom rules that survive into payroll configuration.
Holds the payroll integrity line — payroll cannot fail. Every cycle. From day one of go-live.
Co-owns workforce change with the Change Manager — adoption, capability, super-user network sponsorship.
Liaises with EBA partners — union, legal, industry body — on workforce implications.

Deliverables

Approved position management model — with explicit choice rationale and ADR.
Org structure design pack — reporting hierarchy, position catalogue, classification map.
EBA / award interpretation specification — the rules payroll will encode, signed by HR Policy.
Workforce data integrity sign-off — pre-cutover, per data class.
Payroll parallel-run sign-off — for every pay cycle category before go-live.
Workforce communications plan — co-owned with Change.

COO

The Chief Operating Officer

READ

Lead voice on operations-heavy programmes

Owns the operating model end to end — the value streams that cross the modules, the BAU readiness, and the operational continuity through cutover. Frequently underweight in early stages, overweight at hypercare.

OwnsOperating model, value-stream integrity, BAU readiness.

Responsibilities

Owns the operating-model commitments across all value streams — how work will flow, who will do what, what stops or simplifies.
Sponsors business owners — the named people on the operating side accountable for each module's outcomes.
Holds BAU readiness — when the implementation partner steps down, the COO's organisation is the one taking over.
Owns operational continuity through cutover — including the calendar collision avoidance (pay cycles, month-end, regulator windows).
Co-sponsors the Product Owner network post go-live with the Sponsor / CIO.
Holds the line on customisation — operationally, every customisation has a cost to operate. The COO's instinct should be configure, not customise.

Deliverables

Approved value-stream design per module — Plan-to-Replenish, Order-to-Cash, Hire-to-Retire, etc.
BAU operating model document — named owners per module, support model, governance forums post go-live.
Cutover operational readiness pack — go/no-go evidence from the operating side.
Super-user network sponsorship — air cover from the COO's office.
Post go-live operating-model attestation — confirms the COO's organisation has taken over.
Continuous improvement priority list — what the operating side wants from the platform's next twelve months.

PROG-DIR

The Programme Director

READ

Reports to sponsor

Owns delivery — schedule, scope, budget, risk, vendor performance, decision rhythm. Runs the steering committee. The person who knows what is true today, not what the deck claims.

OwnsDelivery, governance, vendor performance, programme decisions.

Responsibilities

Runs the programme end-to-end — schedule, scope, budget, risk, vendor performance, decision integrity.
Manages the implementation partner relationship day-to-day — SoW health, named-people retention, change-request rigour.
Holds the gate cadence — pre-gate reviews, gate submissions, post-gate conditions tracked.
Owns the bad-news protocol — when RAG status downgrades, the Sponsor knows within 48 hours without filter.
Sponsors the PMO and the working forum rhythm.
Owns the cutover go/no-go — with the Sponsor signing off the decision, but the Programme Director presenting the evidence.

Deliverables

Integrated programme plan — schedule, dependencies, milestones, critical path.
RAID register — risks, assumptions, issues, decisions; with named owners and trigger events.
PCG / SteerCo papers — weekly cadence, with decisions, not just status.
Gate submission packs — for each of the six phases.
Vendor performance reports — against SoW, with change requests logged.
Cutover go/no-go evidence pack — per pre-defined criteria.
BAU handover plan — explicit transition to Product Owners.

PMO

The PMO Lead

READ

Reports to programme director

Owns the governance machinery — RAID, decisions log, schedule, status reporting, gate submissions. The integrity of what the steering committee sees. The discipline that prevents status theatre.

OwnsRAID, decision log, governance integrity, status quality.

Responsibilities

Maintains the integrated plan across workstreams — keeps schedule, dependencies, and critical path live.
Owns the RAID register — entries dated, owned, trigger-tested. Drives the weekly review cadence.
Owns the decisions log — every binding decision, who made it, with rationale; links to ADRs (§11).
Produces status reporting against pre-defined criteria, not vibes. The integrity of what reaches the steering committee.
Coordinates gate submissions — assembles evidence, sequences reviews, tracks gate conditions post-approval.
Manages programme financials — budget tracking, forecast, change-request value.

Deliverables

Integrated programme schedule — live, with dependencies, baseline vs current.
RAID register — owned, dated, with trigger events; never stale.
Decisions log — every binding decision, traceable.
Weekly status report — per pre-defined criteria, not optimism.
Gate submission pack — evidence per phase entry/exit criteria.
Programme financial reports — budget, forecast, variance, CR value.
Lessons learned register — running, not retrospective only.

BA-LEAD

The Business Analysis Lead

READ

Senior BA; the practice keeper

Owns the requirements register, the decision integrity through delivery, and the link from operational outcome back to scope. The fence between problem and solution. The discipline of saying “we shouldn't build this” when the evidence supports it.

OwnsRequirements integrity, decision traceability, problem-vs-solution fence.

Responsibilities

Owns the BA practice on the programme — see the parallel MVBA Field Guide for the full disciplines.
Holds the problem-vs-solution fence — pushes back on premature solutioning; insists the problem is sharp before the requirement is written.
Owns the requirements register and traceability — every requirement traced to a decision, to a test, to an outcome.
Drives the SME engagement model — ensures SMEs are released full-time, contributing meaningfully, not absorbed by their day jobs.
Pairs with the Change Manager — design integrity in, behaviour integrity out. Same decisions, different observation points.
Drafts ADRs (§11) for the structural decisions the practice surfaces.

Deliverables

Requirements register — live, classified, owned, traceable, with acceptance criteria.
Process / value-stream maps — current state and target state, per module.
Decision pack — the structural commitments the programme is being built to enable.
Assumptions / constraints / open-questions register — live, with trigger events.
Traceability matrix — requirement → test → outcome, end to end.
ADR drafts for major structural decisions.
SME engagement plan — named people, days per week, escalation if availability slips.

DATA-LEAD

The Data Migration & Governance Lead

READ

Often under-named, structurally critical

Owns the migration discipline — profile, cleanse, map, transform, load, reconcile, validate — and the steady-state data governance forum. The role most commonly under-resourced relative to its consequence.

OwnsMigration integrity, steward model, steady-state data quality.

Responsibilities

Owns the data migration discipline end-to-end — profile, cleanse, map, transform, load, reconcile, validate.
Names the master data stewards — per data class, with executive backing, with stop-the-cutover authority.
Drives the cleansing playbook — what gets fixed in source, what in transit, what is left behind out-of-scope.
Owns the mock load programme — at least three iterations, with defect curves trending to zero.
Stands up the steady-state data governance forum — who can change structure vs records, escalation paths.
Ensures historical data retention policy is decided, signed, defensible at audit.

Deliverables

Data migration strategy & plan — scope, sequencing, target volumes, retention.
Source-to-target mapping — per class, field-level, with transformation rules.
Data profiling report — quality issues identified before build, not during.
Mock load reports — Mock 1/2/3 with defect counts and trends.
Reconciliation reports — control totals, record counts, balance ties, source to target.
Master data steward charter — per class, with named exec backing.
Data governance forum charter — for steady state.
Cutover data sign-off pack — per data class, signed by the steward.

CHANGE

The Change Manager

READ

Paired with BA Lead; not handover at go-live

Owns stakeholder engagement, impact assessment, training, adoption measurement. Works the same decisions as the BA — design integrity vs adoption integrity. Reports to the sponsor, ideally, not to delivery.

OwnsBehaviour change, adoption, BAU readiness in the workforce.

Responsibilities

Owns the change strategy and approach — ADKAR or equivalent, applied to the actual operating-model change, not generic.
Drives stakeholder engagement and impact assessment — per role, per business unit, per geography.
Designs and runs the super-user network — selection, training, cadence, air cover.
Owns role-based training design with the Trainers — and adoption measurement after.
Measures behaviour, not just training completion — adoption is the metric that matters.
Pairs with BA Lead at every design forum — design integrity in, behaviour integrity out, same decisions.
Reports to Sponsor ideally — not to Programme Director — so bad news on adoption gets up the line.

Deliverables

Change strategy & impact assessment — by role, business unit, geography.
Stakeholder engagement plan — segmented, with named owners and engagement cadence.
Super-user charter & network roster — who, where, how trained, with what air cover.
Communications plan — broadcast and feedback channels, not just announcements.
Role-based training plan & collateral — co-owned with Trainers.
Adoption measurement framework — behaviour-based, with baseline and target per role.
30/60/90 day adoption checkpoint reports — fed into benefits realisation (§10).

ARCH

The Enterprise Architect

READ

Often shared with the integration platform team

Owns the application architecture, the integration patterns, the master-data master plan, and the technology standards. The guardian of the estate's coherence beyond this programme — the role that survives multiple transformations.

OwnsArchitecture coherence, integration estate, technology standards.

Responsibilities

Defines the application architecture — which system masters which capability; what stays, what goes, what gets folded into the ERP.
Owns the integration architecture — patterns (direct / iPaaS / event-driven), standards, data contracts.
Owns the master-data master plan — which system is authoritative for each class, and the rules of the road for downstream propagation.
Sets and enforces technology standards — naming conventions, API design, security baselines, error handling.
Holds the line against architectural debt — every customisation, every direct point-to-point, every "just this once" gets reviewed.
Authors and reviews ADRs (§11) — particularly Class 02 (integration) and Class 05 (operating model).

Deliverables

Target-state application architecture — current, in-flight, target, with transition map.
Integration architecture & pattern catalogue — see §03.
Master-data master plan — per class, with system of record and propagation rules.
Technology standards document — APIs, naming, security, error handling.
ADR register — owned by the architect, contributed to by all.
Architecture review board minutes — quarterly cadence minimum.

SECURITY

The Security & Risk Lead

READ

Often joint risk + cyber + audit

Owns the controls fabric, the SoD matrix, the access model, the audit-trail design, the BCP/DR posture. Engaged early or retrofitted late — the difference is order-of-magnitude in cost and risk.

OwnsControls, access, audit trail, business-continuity posture.

Responsibilities

Owns the controls fabric design — SoD, RBAC, approval routing, delegations — designed in, not retrofitted.
Owns the SoD matrix — live, tested, monitored continuously, not point-in-time.
Designs the access model — joiner-mover-leaver via HR-driven RBAC where possible.
Owns audit-trail granularity — what is logged, how long retained, how is it searchable for audit and incident response.
Owns BCP/DR posture — RTO/RPO targets, failover testing cadence, evidence of recoverability.
Liaises with internal audit and external auditors — early, continuously, not at year-end only.

Deliverables

Risk & control matrix — per value stream, with control objective, activity, owner, frequency, evidence.
SoD matrix — live, with monitoring tool integration.
Access & identity blueprint — RBAC model, IdP integration, JML automation.
Audit-trail design specification — fields logged, retention, query model.
BCP/DR plan — with RTO/RPO commitments and failover test evidence.
Penetration test & security review reports — pre go-live and annually thereafter.
Findings & remediation register — every audit finding with owner and closure evidence.

PARTNER

The Implementation Partner

READ

SI consultancy; managed under SoW

Owns delivery of the configured system per the agreed scope. Provides methodology, accelerators, deep product knowledge. Doesn't own the business outcome — that stays with the sponsor, COO, and BAs. The most common failure mode is confusing the two.

OwnsConfigured system per SoW. Not the operating model.

Responsibilities

Delivers the configured system against the SoW — functional design, technical design, build, configuration, integration, test support.
Brings methodology and accelerators — proven approaches that compress time without compromising operating-model integrity.
Provides deep product knowledge — vendor-certified consultants, named in the SoW, retained through the engagement.
Co-runs the test cycles — SIT primarily with partner; UAT primarily with business; defect triage joint.
Supports cutover and warranty hypercare — to defined exit, not indefinitely.
Does NOT own — the operating-model commitments, the business outcome, the benefit twelve months out. Those stay with the enterprise.

Deliverables (per SoW)

Functional and technical design pack — per module, traceable to scope.
Configuration workbooks — the parameter sets encoding the design.
RICEFW deliverables — built, tested, documented, with traceability.
Test pack contribution — SIT scripts, UAT support, defect resolution.
Cutover support pack — partner role in the runbook.
Knowledge transfer pack — to enterprise BAU team, signed off before warranty starts.
Warranty hypercare support — per the contract, with defined exit date.

The Project Manager

READ

Workstream-level delivery lead; reports to Programme Director

Not the same as the Programme Director. The PM runs a defined workstream — a module, a phase, an integration set — within the larger programme. Owns the day-to-day plan, the cross-team dependencies, the burn-down, the standup rhythm. The person who actually closes the work, not just reports on it. Usually one PM per major workstream; a programme of any size has several.

OwnsWorkstream plan, dependencies, daily delivery, escalations to Programme Director.

Responsibilities

Runs a defined workstream — module, phase, integration set — to its scope, budget, schedule.
Owns the day-to-day plan — sprint or wave-level depending on methodology; burn-down visible.
Drives the standup rhythm — daily within the team; weekly with cross-workstream PMs.
Manages cross-team dependencies — escalates blockers to the Programme Director within agreed SLA.
Owns workstream risk and issue management — fed into the programme-level RAID.
Closes the work — not "reports against it." Acceptance criteria evidenced, not asserted.

Deliverables

Workstream plan — with dependencies and milestones traceable to the programme plan.
Sprint / wave reports — burn-down, velocity, scope changes.
Workstream risk & issue log — fed up to programme RAID.
Acceptance evidence — per deliverable, against pre-defined criteria.
Workstream financials — actual vs forecast, fed into programme financials.
Cross-workstream dependency register — co-owned with peer PMs.

SME

The Subject Matter Experts

READ

The domain truth-holders; embedded across modules

Not a role with one name — a function with many. The SMEs are the operating experts whose knowledge of the current state, the policy realities, the customer commitments, and the workarounds is the source of operating-model truth. Without them, the BA writes requirements against a phantom. The programme's biggest under-investment is almost always SME time; the most consistent failure mode is letting SMEs participate part-time on top of their day job and discovering at UAT that they were never actually in the room.

OwnsDomain truth, current-state reality, policy interpretation, design validation.

Responsibilities

Hold the domain truth — current-state operations, policy interpretation, customer commitments, regulatory realities.
Validate the design — does the proposed design reflect operating reality, or someone's PowerPoint of operating reality?
Anchor the requirements — alongside BAs; SMEs say what is, BAs say what needs to be different.
Lead UAT execution — the test design is anchored on real operating scenarios SMEs supply.
Sponsor the super-user network in their domain — SMEs often become first super users.
Surface the unsexy realities — the workarounds, the exceptions, the once-a-quarter event that the system has to handle.

Deliverables

Current-state process documentation — co-authored with BAs, signed by SME.
Policy & rules interpretation document — how the business actually applies the rules, not just what the manual says.
Design validation sign-off — per module / value stream, signed by named SME.
UAT scenarios — real operating cases, including exceptions and edge cases.
UAT execution & defect reporting — SME-led, not BA-led.
Post-go-live operational feedback — fed into continuous improvement.

TEST-LEAD

The Test Lead

READ

Independent of build; owns the evidence the system works

Owns test strategy, test plan, defect management, and the evidence that supports go-live go/no-go. Critically: independent of build — the test lead is not the same person who configured the system. Tests are designed against scope and acceptance criteria, executed against pre-defined exit criteria, and the test lead has the authority to delay go-live on evidence. Underweight in most programmes; under-resourced in nearly all.

OwnsTest strategy, defect lifecycle, go-live evidence.

Responsibilities

Owns the test strategy — covering SIT, UAT, performance, regression, security, dress rehearsal.
Independent of build — does not report into the build team; has authority to delay go-live on evidence.
Defines test exit criteria — written and agreed before testing starts, not at the end.
Owns the defect lifecycle — log, triage, severity, root-cause categorisation, fix, retest, close.
Produces the go/no-go evidence pack — defect curves, exit criteria met, residual risk named.
Owns regression test maintenance — automated where possible, kept current across releases.

Deliverables

Test strategy — covering all test types and exit criteria.
Test plan & schedule — cycles, environments, data, named testers.
Test scripts — for SIT (partner-led), UAT (SME-led, partner-supported), regression, performance.
Defect log — with severity model, ageing, root-cause categorisation.
Cycle reports — at end of each test cycle, with defect curves and exit-criteria status.
Go/no-go evidence pack — per pre-defined criteria, signed.
Regression test pack — handed to BAU; automated where supported.

PRODUCT-OWN

The Product Owner

READ

Post go-live; the person who keeps the platform compounding

The role that replaces the Programme Director after hypercare ends. Owns the continuous-improvement backlog, the release cadence, the product roadmap, and the operating-model improvements the platform is meant to deliver. Usually one per module in a federated model, or one overall in a centralised one. The single most consequential role for whether the programme actually pays back — and the role most commonly under-named at go-live.

OwnsPost go-live product, backlog, roadmap, operating-model improvements.

Responsibilities

Owns the platform as a product — not as a project that finished — for the operating-model outcomes it was funded to deliver.
Maintains the continuous-improvement backlog — prioritised against operating-model outcomes, not feature requests.
Owns release cadence — aligned to vendor release calendar, business calendar, and benefit pulse.
Owns the 12-month roadmap — rolling, visible to executive, tied to benefits register.
Sponsors AI / automation pipeline — sequencing capability adoption to data-layer readiness.
Co-manages vendor relationship with the named relationship owner — closest to product reality.

Deliverables

Product operating model document — team, backlog, cadence, capacity.
Continuous-improvement backlog — prioritised against benefit outcomes.
Release plan — 12-month rolling, aligned to vendor & business calendars.
Value-stream metric reports — per stream from §01, against benefits register.
Vendor roadmap impact assessments — per release.
AI / automation pipeline — candidates, sequencing, value cases.
Quarterly product review reports — to Sponsor and benefit owners.

SUPER-USER

The Trainers & Super Users

READ

The bridge between change management and the workforce

Trainers design and deliver the role-based training. Super users are the workforce members embedded in business units who run their team's adoption — answer the day-one questions, escalate the right issues, reinforce the new behaviours, feed real signals back to the product owner. Treat them as a network, not a list of names. The strongest predictor of post go-live adoption is whether the super-user network was named early, trained deeply, and given air cover from leadership.

OwnsWorkforce capability, day-one adoption, ongoing reinforcement.

Responsibilities — Trainers

Design role-based training — tied to specific tasks, not feature tours.
Deliver training — multiple formats: virtual, classroom, e-learning, just-in-time.
Maintain training collateral — kept current with releases, not frozen at go-live.
Train the super users first — train-the-trainer cascade.

Responsibilities — Super Users

Be the first line of help in their business unit — day-one onwards.
Reinforce the new behaviours — peer-to-peer, more credible than central comms.
Escalate issues with context — distinguishing "system not working" from "team needs more training" from "design didn't anticipate this."
Feed real signals back — to product owner, change manager, BA lead. Closes the loop continuous improvement depends on.

Deliverables

Training needs analysis — by role, by capability.
Training collateral — courses, quick-reference guides, video walkthroughs, simulations.
Training delivery records — completion, comprehension where assessed.
Super-user charter — what the role is, what it isn't, what air cover comes with it.
Super-user feedback log — issues raised, themes, ideas — fed to product owner.
Adoption reinforcement plan — beyond go-live; co-owned with Change.

VENDOR-AE

The Vendor Account Executive

READ

Software vendor's relationship lead; often the most underestimated stakeholder

The software vendor's relationship owner — not the implementation partner. Manages the licence relationship, the roadmap conversation, escalation into the vendor's product organisation, executive briefings. Materially shapes how the vendor treats you over a decade. Underestimated because the noise is on the SI side; the leverage is on the vendor side. Worth investing in the relationship explicitly, not letting it default to the partner.

OwnsVendor relationship, roadmap visibility, escalation path into product org.

Responsibilities (vendor-side; enterprise manages the relationship)

Acts as the vendor's primary contact for the customer relationship — separate from technical support, separate from the partner.
Owns commercial conversation — licence growth, renewals, repricing, exit terms.
Surfaces roadmap visibility — releases in flight, deprecations coming, capabilities the customer should consider.
Escalates into vendor product organisation — when support or partner channels can't resolve.
Coordinates executive engagement — vendor leadership in front of enterprise leadership on a defined cadence.

What the enterprise should expect (and ask for)

Monthly relationship check-ins — open issues, support patterns of consequence, upcoming releases.
Quarterly business reviews — joint forum with vendor solution architect; adoption, value, friction.
Annual executive review — vendor account leadership ↔ enterprise sponsor + CIO.
Pre-renewal roadmap workshop — 12 months before contract expires.
Escalation pathway documented — into product organisation, with named contacts and SLAs.
Reference-customer status — traded deliberately for early access, roadmap weight, executive lines.

The decision-rights matrix the programme should produce

On every ERP programme, the leader should be able to point to a single matrix that names — for each decision class — who is accountable, who is consulted, who is informed, and the escalation path. Without it, “the steering committee” absorbs accountability that should sit with a person. Below is the minimum set.

Decision class	Accountable	Consulted	Escalation
Investment & scope	Sponsor	CFO, COO, Programme Director	Board / ELT
Operating-model commitments	COO / CFO / CHRO (by domain)	BA Lead, Arch, Sponsor	Sponsor
Chart of accounts	CFO	COO, Tax, Audit, Sponsor	Sponsor
Position / org model	CHRO	COO, Payroll, EBA partner	Sponsor
Master data ownership	Data Lead	CFO, COO, CHRO	Sponsor
Integration architecture	Enterprise Architect	Programme Director, Security	Sponsor
Controls & access	Security & Risk Lead	CFO, Audit, BA Lead	Sponsor
Cutover go/no-go	Programme Director	Sponsor, COO, all module leads	Sponsor
Test & UAT acceptance	Test Lead	BA Lead, SMEs, Business Owners	Programme Director
Training & adoption	Change Manager	COO, Super Users, BA Lead	Sponsor
Benefits ownership post go-live	Business owner per benefit	Sponsor, CFO	Sponsor
Post go-live product ownership	Product Owner (per module)	COO, business owners, vendor	Sponsor

Sequence · How an ERP programme actually runs

The Programme Rhythm.

Six phases. Each one with a job, a decision the phase must answer, and a failure mode the leader should watch for. The phases compound — skipping or compressing one always shows up two phases later.

01Discover

Operating-model thesis & business case

Before the RFx · The commitments are named in writing and the kill criterion is declared

READ

Before the RFx. The operating-model commitments are named in writing and signed by the sponsor. The business case identifies measurable operational changes and a benefit owner twelve months out. The kill criterion is declared. See §08-01 for the artefacts.

Common pitfalls

Discovery compressed because the business case timeline is short. The team mistakes pace for clarity.

Operating-model thesis assumed, never written. Everyone agrees in a meeting; nobody agrees in writing.

Vendors invited too early. Discovery output ends up belonging to whoever might bid.

Kill criterion missing. The programme can be paused, but never stopped.

Strategies that work

Buy time before the budget cycle. Run an early operating-model thesis sprint that ends before the funding submission, not after it.

Separate the writing from the consensus. The thesis is written by one accountable owner; consensus is gathered against the draft, not in place of it.

Pre-mortem on the value case. Assume the benefit failed twelve months out — ask why. Most failure modes are visible at discovery if you look.

Name a benefit owner now, even if provisional. Trades comfort for clarity.

What success looks like

A signed decision pack the sponsor can defend at the board. The operating-model commitment in one paragraph anyone in the executive could repeat. A measurable outcome with a date and an owner. A kill criterion in writing. Trade-offs accepted explicitly. The conversation about software hasn't started yet — and that's the point.

The decision this phase must answer

Do we have an operating-model commitment worth funding? Yes / No / Not yet.

Failure modeThe business case is signed before the operating-model thesis is articulated.

02Select

Software & partner selection

Two procurements, not one · Reference-check the people, not the firm

READ

RFx for software. Separate RFx (or selection) for the implementation partner — different vendors, different evaluation criteria. Operating-model trade-offs informed the requirements; the requirements informed the RFx. Reference-check the partner's people, not just their methodology. See §08-02 for the artefacts.

Common pitfalls

Software + partner bundled into one decision. Hands too much leverage to whoever wins.

Demo scripts written by the vendor. Every product passes its own demo.

References checked against the firm, not the named people on your engagement.

Commercials negotiated before evaluation closes. The panel's recommendation becomes a formality.

Exit clause stays in the boilerplate, never tested for actual exercisability.

Strategies that work

Two procurements, two timelines. Software vendor first; implementation partner second, with the software now anchored.

Demo scripts built from your value streams. The vendor demos in your data, on your scenarios — including the ugly ones.

Reference the named partner team. Talk to clients whose engagement included the same people who will be on yours.

Evaluation panel decides, then negotiates. Commercials open after the panel's written recommendation, not before.

Test the exit. Ask the vendor what an exit would actually look like and price it.

What success looks like

Two signed contracts — software and partner — that the sponsor can defend independently. Evaluation rationale written down and survives later interrogation. Named partner people committed in the SoW, with replacement clauses if they leave. Exit terms genuinely exercisable. A TCO model that holds up over seven to ten years, not just at signature.

The decision this phase must answer

Which software, which partner, which model of engagement.

Failure modeSelecting software and partner as a single bundle. Letting the vendor name the success criteria.

03Design

Functional & technical design

Commitments become configuration · Controls designed in, not bolted on

READ

Operating-model commitments translated into configuration decisions. Chart of accounts designed. Position management decided. Integration patterns chosen. Controls designed in (not later). Master data masters named. Reporting requirements gathered in parallel with configuration, not after it. See §08-03 for the artefacts.

Common pitfalls

Design decisions made under build pressure, with the partner driving and the business catching up.

SMEs participate part-time on top of their day job; UAT exposes the gap.

RICEFW backlog grows because nobody is empowered to say no.

Controls designed last, retrofitted onto a build that didn't account for them.

Reporting requirements gathered after configuration hardens — the data model has to be reshaped.

The sponsor isn't in the room when operating-model calls get made.

Strategies that work

SMEs full-time, with backfill. If the SME can't be released, the operating-model truth isn't yet considered essential — fix that before design starts.

Customisation has to be earned. Default position: configure, don't customise. Every RICEFW item has a written justification with a named approver.

Controls and reporting on the design team from week one, not as a later workstream.

Sponsor review on the five compounding decisions (§13) before design sign-off — chart of accounts, master data, integration architecture, controls, post-go-live model.

Pre-mortem at design sign-off. Assume go-live failed at month 6. What in this design caused it?

What success looks like

A design pack the sponsor recognises as the operating-model commitment they signed in §07-01. SMEs whose names appear repeatedly because they were actually present. A RICEFW register where every customisation can be defended. Controls and reporting fully integrated, not bolted on. The five compounding decisions explicitly closed before build pressure mounts.

The decision this phase must answer

Is the design what the sponsor committed to? Re-test before build.

Failure modeDesign decisions made under build pressure; the sponsor not in the room when the operating-model calls happen.

04Build & Test

Configuration, build, integration, test

Independent test lead with go-live authority · Three mock loads, two dress rehearsals

READ

The system is built. Integration contracts are coded. Tests are run — SIT, UAT, performance, regression, dress rehearsal. Data migration is dry-run more than once. Cutover toolkit is exercised. Change-management lands the awareness and training campaigns in parallel. See §08-03 to §08-05 for the artefacts.

Common pitfalls

Test cycles compressed when the build slips. Testing is treated as the buffer.

Tests run by the same people who built the system. No independent verification.

UAT becomes a tick-box because the business doesn't yet trust the system enough to refuse sign-off.

Data migration sequenced too late, into a window that can't absorb a setback.

Dress rehearsal skipped. Cutover is the first time the runbook is exercised end to end.

Defect register grows because new items are added faster than old ones close — but go-live is pushed regardless.

Strategies that work

Independent Test Lead with go-live authority. The test lead can delay go-live on evidence.

Exit criteria written before testing starts. Defects below severity 2 below a defined threshold; severity 1s at zero.

SMEs and super users drive UAT, not the BA team. The business owns the trust decision.

Three mock data loads. Mock 1 finds the surprises, Mock 2 stress-tests recovery, Mock 3 validates cutover-grade quality.

Two dress rehearsals. One to find the gaps, one to confirm the gaps are closed.

Cutover go/no-go criteria written six weeks before, not in the final week.

What success looks like

A defect curve that is genuinely trending toward zero — not flat with an end-date target. UAT sign-off given by business owners who could defend it under audit. Three mock loads complete, reconciliations cleanly tied. Two dress rehearsals complete, the runbook polished by real practice. Go/no-go criteria evidenced item-by-item, named accountable per gate. The cutover decision feels like a confirmation, not a hope.

The decision this phase must answer

Are we ready to cut over? Go / No-go, evidenced, with rollback criteria pre-named.

Failure modeCompressed test cycles. Data migration sequenced too late. Cutover plan never dress-rehearsed.

05Deploy

Cutover & hypercare

Structured hypercare · BAU takes over before the partner steps down

READ

The system goes live. Hypercare is a structured 4–12 week phase, not an open-ended consulting fee. Issues are triaged against a defined severity model. Adoption measurement begins immediately. The BAU operating model is taking over while the implementation partner is still in the room. See §08-05 and §08-06 for the artefacts.

Common pitfalls

Cutover sequenced into a pay cycle, month-end, or regulator window. The first crisis isn't even a programme failure — it's an avoidable calendar collision.

Command centre staffed by junior team members who can't escalate or make decisions in the moment.

Rollback plan exists on paper, never tested. Discovering that the rollback doesn't work during the cutover is not a useful moment.

Hypercare extended indefinitely. The implementation partner becomes BAU support by default.

Super-user network underprepared; day-one questions overwhelm the help desk.

Strategies that work

Cutover calendar mapped against the business calendar at week 1 of the programme, not week 1 of cutover planning.

Command centre led by a senior named owner with explicit authority to declare incidents and stop the cutover.

Rollback rehearsed in mock cutover. Test the rollback before relying on it.

Hypercare with hard exit criteria, not "until things stabilise." Defined entry, defined exit, defined extension protocol.

Super-user network active from week 1 of go-live, with daily debriefs feeding the command centre.

Adoption measurement starts day one, not after the partner leaves.

What success looks like

A cutover that's a non-event for most of the business. Issues triaged inside the severity model, closed at a rate that supports the planned hypercare end-date. Super users handling 70%+ of frontline questions by week three. Adoption signals visibly tracking, not just training-completion percentages. The implementation partner stepping down on a date the operating model already has someone in the seat for.

The decision this phase must answer

Has the operating model genuinely taken over from the programme team?

Failure modeHypercare extended indefinitely because BAU isn't ready. The implementation partner becomes BAU support by default.

06Realise

Benefits realisation & learning loops

Programme closes when the benefit owner takes over, not at go-live

READ

30 / 60 / 90 / 180 / 365-day adoption checkpoints. Predicted operational changes verified or named as unrealised. Benefits register revisited; benefit owners stay accountable. Learning loops feed the next decision pack and the practice library. Programme officially closes when the benefits owner takes over — not at go-live. See §10 for the full discipline.

Common pitfalls

Programme closes at go-live; the benefits register goes into a drawer.

Nobody is accountable twelve months out. The benefit owner moved roles, retired, or never existed.

Adoption measured as training completion, not behaviour change.

Lessons learned never opened again. Same mistakes show up at the next programme.

The product operating model never stands up. Continuous improvement is treated as someone's side responsibility.

Strategies that work

Programme closes when the benefit owner takes over, not at go-live. Two distinct events.

Benefit owner named in writing, with a defined accountability — present at every quarterly review until the benefit is realised or formally retired.

Behaviour-based adoption measures: are people doing the new work, in the new way? Training completion is a leading indicator, not the metric.

Lessons learned reviewed at the start of the next programme, not just filed.

Product operating model stood up before hypercare ends, with named Product Owners (§06) per module.

What success looks like

Twelve months post go-live, the sponsor can point to specific operational changes that have measurably happened — cycle times reduced, error rates down, manual work eliminated, decisions made faster — against the predictions made in §07-01. The benefits register is live, not archived. The product team is the natural home for the platform. The next programme's decision pack quotes lessons from this one. The operating model has compounded; the press release was a long time ago.

The decision this phase must answer

Did the operating-model change actually happen? What did we learn about how decisions hold or drift in this organisation?

Failure modeProgramme closes at go-live; benefits register goes into a drawer; nobody is accountable twelve months out.

From idea to steady state · The ten stages in practice

The Lifecycle in Practice.

§07 is the rhythm at a glance. This section is the rhythm in detail — what each stage actually produces, the artefacts that get signed, where it goes wrong, and the leader's question. Ten stages, each expanding to the practitioner depth a leader needs to govern the work without doing it personally.

PMI Program Management · Lifecycle PRINCE2 Stage gates TOGAF ADM Phases A–H ITIL 4 Service Value Chain · Improve BABOK SA · SE — Strategy & Solution Evaluation

Needs Analysis & Discovery

Operating-model thesis, business case, decision pack. Before the RFx.

READ

What this stage is for

The stage where the enterprise decides whether it has an operating-model commitment worth funding — and names it in writing. The least technical stage in the lifecycle, and the one most consistently underweight. The cheapest moment to fix an ERP programme; the most expensive moment to skip.

The two parallel tracks

Discovery has two simultaneous tracks. The operating-model track answers what we want the business to look like in three years and which structural commitments are required to get there. The solution-context track answers what the current state is, where it breaks, what is contested, what is treated as immovable. Both tracks have to land together — operating-model ambition without current-state honesty produces business cases that don't survive contact with reality.

Workflow

The discovery flow

From uneasy intuition to funded operating-model commitment

Trigger / Intuition→ Current-State Map→ Operating-Model Thesis→ Options & Trade-offs→ Business Case→ Decision Pack→ Sponsor Sign-off

Outcome: A signed decision pack that names the operating-model commitment, the measurable outcome twelve months post go-live, the benefit owner, the kill criterion, and the trade-offs the enterprise has accepted in writing.

Artefacts the stage must produce

Operating-model thesis — what the business will look like and how transactions will flow in three years.
Current-state assessment — what is in place today; what works; what is contested; what is held together by spreadsheets.
Pain points and value pool — evidence-based, not anecdote-based; quantified at category level not unit level.
High-level capability and process map — which value streams the new platform will touch.
Options analysis — at least three: do nothing, minimal viable, structural fix. Compared by leverage, not elegance.
Business case & decision pack — sponsor-owned, with kill criteria and a benefit owner twelve months out.
Stakeholder & decision-rights map — see §06.
Initial assumptions, constraints, open questions register — dated and owned.

The decisions this stage must answer

Is this an operating-model commitment we're prepared to make?
What measurable change will we be on the hook for, twelve months post go-live?
What kill criterion would cause us to stop or scale back?
Which trade-offs are we accepting in writing — speed vs correctness, standardise vs localise, build vs buy, local benefit vs enterprise reuse?
Who is the benefit owner — not the project sponsor, the benefit owner?

Where it goes wrong

Discovery compressed because the business case timeline is short. Operating-model thesis assumed rather than written. Pain points drawn from the loudest voices rather than the evidence. Vendors invited to "help with discovery" — and the discovery output now belongs to whoever might bid. The decision pack lacks a kill criterion and a benefit owner. The team rushes to selection because senior stakeholders are uncomfortable with ambiguity.

Leader's question

"Have we written the operating-model commitment down, signed by the sponsor — or are we about to test the market against an assumption nobody has owned?"

Vendor Selection

RFx, evaluation, scripted demos, reference checks, partner selection. The contracts get signed.

READ

What this stage is for

To test the market against operating-model commitments that have already been made — not to make them in front of vendors. The stage where the buyer's job is to maintain the distinction between which software and which implementation partner, because the second decision is structurally larger than the first.

Two procurements, not one

The software vendor and the implementation partner are different decisions with different evaluation criteria. Software RFx tests product fit, roadmap, total cost of ownership, regional support. Partner RFx tests delivery capability, methodology, named people, prior reference relevance, post go-live presence. Running both as one bundle hands too much leverage to whoever wins it.

Workflow

The selection flow

From signed decision pack to signed contracts (software + partner)

RFI / Long-list→ RFP→ Scripted Demo→ Reference Checks→ Commercials→ Negotiation→ Contract Sign

Outcome: Two signed contracts (software + partner), evaluated against the operating-model commitments. Trade-offs accepted by the sponsor in writing before contract signature.

Artefacts the stage must produce

Vendor long-list and rationale for inclusion / exclusion.
RFx documents — separated for software and partner where the procurement model permits.
Evaluation framework — weighted criteria, scoring rubric, evaluator panel composition. Approved before responses are read.
Scripted demo scenarios — drawn from real value streams, not vendor sandboxes.
Reference check pack — questions targeted at the partner's people assigned to your engagement, not just the firm's case studies.
Total cost of ownership model — software, partner, internal cost, run cost over 7–10 years.
Signed software contract — with the licence model, the data ownership clause, the regional hosting commitment, the regulatory undertaking, the exit terms.
Signed partner statement of work — with named people, deliverables, acceptance criteria, change-request process, the warranty window post go-live.

The decisions this stage must answer

Which software fits the operating-model commitments we made in §08-01?
Which implementation partner can deliver against those commitments — with named people, not just methodology slides?
How will we hold both vendors accountable if reality drifts from the contract?
What is the exit strategy, and is it actually exercisable?

Where it goes wrong

Selection collapsed into one decision (software + partner bundled). Demo scripts written by the vendor. Reference checks performed against the firm, not the people. Commercial terms negotiated before the evaluation panel's recommendation is final. The exit clause stays in the boilerplate. The decision rationale is never written down, so the post-mortem in three years has nothing to interrogate.

Leader's question

"Have I reference-checked the actual partner people who will be on this engagement — not the firm's case studies, but the names that will appear on the org chart in week three?"

Implementation

Design, configuration, build, integration, test. The longest and most expensive stage.

READ

What this stage is for

To translate the operating-model commitments into a configured system — and to do that in a way that the configuration is implementing decisions that have already been made, not making them under deadline pressure. The stage that consumes most of the budget and most of the political attention; the stage where the gap between design intent and as-built reality opens up if leadership steps back.

Three sub-stages, sequenced

Implementation isn't monolithic. It runs as three overlapping sub-stages — Design (functional and technical decisions before build pressure mounts), Build & Configure (the chart of accounts, position model, integration patterns, controls, reports get encoded), and Test (SIT, UAT, performance, regression, dress rehearsal). Compressing or skipping any of the three always shows up at cutover. Test cycles being cut is the most reliable predictor of a go-live emergency.

Workflow

Sub-stage 1 · Design

From operating-model commitments to signed-off design

Conference Room Pilots→ Fit-Gap Analysis→ Process & Data Design→ Integration Design→ Controls Design→ Design Sign-off

Outcome: A design pack the sponsor recognises as the operating-model commitment they signed. Anything that drifted, named explicitly.

Sub-stage 2 · Build & Configure

From signed design to configured system

Configuration→ RICEFW Build→ Integration Build→ Reports / Forms→ Iteration Demos→ Build Complete

Outcome: A system that does what the design said. RICEFW (Reports, Interfaces, Conversions, Extensions, Forms, Workflows) catalogued and traceable; standards held; customisation explicitly justified per item, not absorbed.

Sub-stage 3 · Test

From built system to cutover-ready

SIT→ UAT→ Performance / Volume→ Regression→ Dress Rehearsal→ Go/No-Go Evidence

Outcome: Defect curves trending toward zero on the things that matter; exit criteria defined and met; the cutover go/no-go has evidence, not opinion.

Artefacts the stage must produce

Functional design specifications — by module, by process, by integration. Traceable to scope.
Technical design specifications — for integrations, extensions, conversions, reports.
RICEFW register — every customisation item with justification, owner, status, dependency.
Configuration workbooks — the parameter sets that encode the operating-model commitments.
Test strategy and plan — covering SIT, UAT, performance, regression, security, dress rehearsal. Exit criteria defined before testing starts.
Test scripts and data sets — covering happy path and exception paths; positive and negative.
Defect log — with severity model, ageing, root-cause categorisation, ownership.
Design-to-build traceability — every built item maps back to a signed design item; every scope item maps to a test.

The decisions this stage must answer

Is the design the operating-model commitment the sponsor signed? If it has drifted, has the drift been re-decided or has it been absorbed silently?
Are we customising because we should, or because saying no was harder than saying yes?
Are test exit criteria evidenced, or is “tests passed” a hand-wave at a status report?
Is the defect curve flattening or rising as we approach cutover?

Where it goes wrong

Design decisions made under build pressure, with the implementation partner driving and the business catching up. RICEFW backlog grows because nobody is empowered to say no — every “just this one” quietly compounds. Tests are run by the same people who built the system. Dress rehearsal is skipped because the schedule is tight. UAT sign-off becomes a tick-box exercise because the business doesn't yet trust the system enough to refuse.

Leader's question

"If the implementation partner left tomorrow, could our own people describe — accurately — what has been built, why it was built that way, and which decisions are still open?"

Data Migration

Profile, cleanse, map, transform, load, reconcile, validate. The discipline that sets the steady-state quality ceiling.

READ

What this stage is for

To produce a go-live data set the business can transact against — and a historical estate that doesn't poison every future report and AI initiative for the next decade. Treated as a technical activity in most programmes; treated as the most consequential workstream in mature ones. Quality of post go-live operations correlates with quality of data migration more than with any other single factor.

The seven activities

Migration is a sequence — profile, cleanse, map, transform, load, reconcile, validate — and each step builds on the last. Skipping profile means you discover data quality issues during load, when fixing them is at maximum cost. Skipping reconcile means go-live happens with a data set the business can't tie back to source. Treat as a discipline, not a task list.

Workflow

The migration discipline

From legacy data to trustworthy steady-state record

Profile→ Cleanse→ Map→ Transform→ Load (Mock 1, 2, 3)→ Reconcile→ Validate

Outcome: A go-live data set the business signs off; reconciliations that tie target to source; mock loads that have been run at least three times before the real cutover.

Artefacts the stage must produce

Data migration strategy — scope, approach, sequencing, target volumes per class, retention policy for historical data.
Source-to-target mapping — per data class, field by field, with transformation rules and validation rules.
Data profiling report — quality issues identified before the migration is built, not during it.
Cleansing playbook — what the business is fixing in source, what the migration is fixing in transit, what is being left behind as out-of-scope.
Mock load reports — at least three iterations, with defect counts trending toward zero.
Reconciliation reports — control totals, record counts, balance ties between source and target.
Cutover data plan — sequencing, dependencies, freeze windows, fallback positions.
Business sign-off — per data class, by the named master data owner.

The decisions this stage must answer

What is the retention policy for historical data — what comes in, what stays in the archive, what gets retired? (The structural decision; revisited in §08-10 Legacy Decommissioning.)
Who owns each data class on day one of go-live — and who can stop the cutover if their class isn't ready?
What is the reconciliation tolerance, and where does the auditor want to see it?
How many mock loads have we run, and is the defect curve flattening?

Where it goes wrong

Migration sequenced late, into a window that cannot absorb a setback. Profiling never done, so issues surface in mock loads — at higher cost. Cleansing performed in transit, not in source — meaning the legacy system stays dirty and the new system goes live with workarounds. Mock loads run once. Reconciliation done at high aggregate level only, missing record-level drift. Master data owners not named, so nobody can sign off go-live.

Leader's question

"Can each named master data owner show me a reconciliation between source and target that they personally trust — and would defend at audit?"

Cutover

Dress rehearsal, go/no-go, cutover execution, command centre, rollback. The most visible 72 hours.

READ

What this stage is for

To take the legacy system out of service, the new system into service, and the business across the line — without operational disruption, missed payroll, missed payment runs, missed regulator submissions, or master data corruption. The most visible stage; the stage where two years of preparation are tested in a window measured in hours.

The cutover toolkit

Cutover is not an event. It is a structured runbook — every step named, sequenced, dependency-mapped, time-boxed, owned. Rehearsed at least twice in mock-prod conditions before the real cutover. The toolkit that turns “go-live” from theatre into operational confidence is the same toolkit on every successful programme: a runbook, a command centre, a comms plan, a decision register, a rollback position. The leader's role is to make sure each exists, has been tested, and has a named owner.

Workflow

Cutover, end to end

From final readiness check to system live in BAU

Dress Rehearsal→ Final Go/No-Go→ Legacy Freeze→ Cutover Runbook→ Smoke Tests→ Business Ready→ Live

Outcome: A controlled handover from legacy to new, with rollback positions named at each gate and a command centre operating until the business confirms BAU is functioning.

Artefacts the stage must produce

Cutover runbook — every task, named owner, predecessor, duration, status, gate.
Dress rehearsal reports — at least two; with defects logged and retested.
Go/no-go criteria — written, evidenced, signed off at each gate by the named accountable (per the §06 matrix).
Rollback plan — what gets rolled back, what doesn't, when the rollback decision must be made, who can make it.
Command centre operating model — physical or virtual location, escalation paths, severity model, communication cadence.
Cutover communications plan — to staff, to customers, to suppliers, to regulators where applicable.
Hypercare entry criteria — what defines “live in BAU” and what hands the system over to hypercare (see §08-06).

The decisions this stage must answer

Are we go or no-go? Evidenced, by named accountable, against pre-written criteria.
If we rollback, at what point is rollback no longer technically or operationally feasible?
Who owns the command centre? Who can declare incidents? Who can sign off resumption?
Have we sequenced cutover to avoid a pay cycle, a month-end close, a regulator submission window?

Where it goes wrong

Dress rehearsal skipped because the schedule is tight. Go/no-go criteria written the week of cutover. Command centre staffed by junior programme team members who can't escalate. Rollback plan exists on paper but has never been tested. Cutover scheduled the same weekend as a board meeting, a pay date, or a regulator submission. The decision to proceed is made under social pressure rather than evidenced criteria.

Leader's question

"If at hour 36 of cutover the data reconciliations fail, do we have a rollback position — and are we prepared to take it?"

Hypercare & Stabilisation

Triage, fix, train, reinforce. The structured weeks where BAU takes over from delivery.

READ

What this stage is for

To stabilise the system in real production conditions and hand it cleanly to the BAU operating model — within a structured window, not as an open-ended consulting fee. Hypercare is where most ERP programmes quietly lose value: the technical handover happens, the operating-model handover doesn't, and the implementation partner ends up running BAU support because nobody else is ready to.

The structured window

Hypercare is a 4–12 week phase with clear entry and exit criteria — not "until the dust settles." Entry: cutover complete, smoke tests passed, business operating. Exit: severity-1 defects closed, severity-2 backlog manageable, BAU support model staffed and operating, adoption trending where it should be. If exit criteria aren't met, hypercare gets formally extended — with the cost and ownership made visible — rather than drifting.

Workflow

Hypercare in motion

From live system to BAU operating model

Issue Detect→ Triage→ Fix / Workaround→ Communicate→ Reinforce Adoption→ BAU Handover

Outcome: System stabilised in production conditions; BAU support team operating; adoption measurable; the implementation partner stepping down on a defined date.

Artefacts the stage must produce

Hypercare operating model — roles, shifts, escalation, severity model, SLA per severity.
Defect & issue register — with severity, root cause, fix path, owner, status.
Daily standups / war-room cadence — visible to programme leadership and BAU leadership both.
30/60/90 day adoption checkpoints — see §06 (Change Manager role) and §10 Benefits Realisation.
BAU handover checklist — per module, per role; signed off by the BAU owner.
Hypercare exit pack — exit criteria evidenced; outstanding items handed to continuous improvement (§08-08).
Lessons learned register — feeds the next decision pack and the practice library.

The decisions this stage must answer

Is BAU staffed and capable of running the system without the implementation partner?
Are adoption signals tracking — or is training compliance high but behaviour change low?
Are severity-1 issues being closed at a rate that supports a defined exit date — or is the curve flat?
What handover is happening between hypercare and continuous improvement, and who owns the open items?

Where it goes wrong

Hypercare extended indefinitely because BAU isn't ready. The implementation partner becomes BAU support by default — convenient, expensive, and structurally wrong. Exit criteria never written. The defect register grows because new items are added faster than old ones close. Adoption measurement treated as training compliance. Lessons learned register never opened.

Leader's question

"On what date does the implementation partner step down — and which person on our payroll is ready to take over the same accountability that day?"

Lifecycle Management (LCM)

Patches, releases, upgrades, vendor roadmap. The discipline of staying current.

READ

What this stage is for

To keep the platform current, secure, supported, and aligned with the vendor's product roadmap — without re-running an implementation every time a major release ships. The discipline most programmes underestimate at selection (when SaaS / cloud is sold as “always current”) and discover the hard way the first time a regulator-mandated patch lands during month-end close.

SaaS vs on-premise: different disciplines, same accountability

Cloud / SaaS platforms force a cadence — quarterly or biannual releases the vendor controls. On-premise / private-cloud platforms let the enterprise choose when to upgrade, which tempts deferral until support windows close and the upgrade becomes a forced project. In both cases the accountability is the same: the enterprise stays on a supported version, with regression confidence, without disrupting BAU. Different mechanics; same operating commitment.

Workflow

The LCM cadence

From vendor release notice to release live in production

Release Notice→ Impact Assessment→ Test in Sandbox→ Regression→ User Acceptance→ Production Deploy→ Monitor

Outcome: The platform stays current. Releases land without disrupting BAU. New capabilities are evaluated and adopted on a deliberate rhythm — not absorbed by accident or ignored by default.

Artefacts the stage must produce

Release calendar — vendor releases mapped against business calendar (month-end, year-end, payroll cycles, regulator windows).
Release impact assessment template — per release, naming impacted modules, customisations affected, integrations affected, controls affected.
Regression test pack — automated where possible, maintained release-on-release.
Customisation register — see §08-03; the inheritance from implementation that decides how much regression each release needs.
Vendor roadmap watch — features that are coming, features that are deprecating, features the enterprise should evaluate.
Environment management plan — sandbox, dev, test, UAT, prod; refresh cadence; data masking; promotion gates.
Release decision log — what was adopted, what was deferred, what was opted out of.

The decisions this stage must answer

Are we on a supported version, or are we drifting toward a forced upgrade?
Which features in the vendor roadmap should we evaluate proactively — and which can we defer?
How does our customisation footprint affect our LCM cost — and is it trending up or down?
Who owns the release calendar, and who arbitrates when a release window conflicts with a business calendar event?

Where it goes wrong

Release management treated as the implementation partner's residual responsibility — meaning nobody is in the seat when the partner moves on. Customisation footprint grows post go-live, so every release becomes harder. Sandbox environments not refreshed, so testing happens on stale data. Regression pack maintained only when a release breaks — by which point the gap has compounded. Vendor roadmap not tracked, so the enterprise discovers deprecation when support drops.

Leader's question

"What version are we on, when is its support window closing, and who on our payroll is accountable for not letting that date sneak up on us?"

Continuous Improvement

Backlog, prioritisation, value-stream tuning, AI capability adoption. The compounding stage.

READ

What this stage is for

To compound the operating-model thesis — to make the system better, year over year, against the value streams the implementation was supposed to enable. The stage where the difference between programmes that paid back and programmes that didn't becomes visible. Most programmes end formally at hypercare. The ones that compound treat hypercare as start, not end.

The product operating model

Continuous improvement requires the ERP to be treated as a product, not a project that finished. A product team — with a product owner, backlog, release cadence, capacity, value-stream alignment — replaces the programme team. Backlog priority is set against operating-model outcomes, not feature requests. AI capability adoption is folded in as a deliberate stream, not a side experiment.

Workflow

The improvement loop

From operating signal to realised improvement

Operating Signal→ Diagnose→ Backlog Candidate→ Prioritise→ Design & Build→ Release→ Measure Outcome

Outcome: A platform that compounds. Improvements measured against operating-model outcomes — cycle time reduced, error rate down, manual effort eliminated, decisions made faster, AI deployed where it actually moves a value-stream metric.

Artefacts the stage must produce

Product operating model — named product owner per module, backlog, release cadence, team capacity, escalation path.
Continuous improvement backlog — prioritised against operating-model outcomes, not feature requests.
Value-stream metrics — per stream from §01, with baseline, target, current. Reviewed at executive cadence.
Benefits realisation tracker — original benefit register, current actuals, variance, named benefit owner per line.
AI & automation pipeline — candidate workflows, automation candidates, agentic candidates; sequenced for data-readiness, not for novelty.
Roadmap — 12-month rolling, with releases, dependencies, vendor roadmap alignment.
Demand intake process — how new requests get evaluated against the existing backlog and the operating-model thesis.

The decisions this stage must answer

What operating-model outcome are we trying to move, and which backlog items would actually move it?
What gets in the backlog — and what gets refused on the grounds that it's not aligned with the thesis?
Are we measuring the value streams from §01, or are we measuring activity?
Where is AI ready to deploy on this platform — and where is the data layer not yet mature enough?

Where it goes wrong

Programme closes at hypercare; product operating model never stands up; the platform freezes. Backlog becomes a queue of feature requests rather than an instrument of the operating-model thesis. Benefits tracker goes into a drawer; nobody is named twelve months out. AI initiatives launched ahead of data-layer maturity, then quietly abandoned. The vendor's new releases ship into a platform that has stopped evolving — and the gap between the configured system and the product's current capability grows year over year.

Leader's question

"What in our operating model has measurably improved in the twelve months since go-live — and would that improvement stand up to the original business case?"

Audit & Assurance

Internal audit, external audit, regulator engagement. The discipline that confirms the controls hold.

READ

What this stage is for

To confirm — to internal audit, external audit, the auditor general (where applicable), and the regulator — that the operating-model commitments encoded in the system are operating as designed; that controls hold under live conditions; that the audit trail supports forensic reconstruction; that risk is at the appetite the enterprise committed to. Not a stage in sequence; a discipline that runs across all stages and intensifies post go-live.

Three audit horizons

Audit isn't one conversation. It runs on three horizons. Implementation assurance happens during the programme — checking that controls are designed in, master data integrity is sufficient, cutover plans are evidenced. Post-implementation review happens 6–12 months after go-live — checking that the benefits case is being realised, the controls operate, lessons are being learned. Steady-state audit is the ongoing rhythm — internal audit cycle, external audit cycle, SOX / SOC2 / ISO27001 / regulator-specific cycles. Each horizon has different artefacts, different stakeholders, different consequences.

Workflow

The assurance loop

From control objective to audit opinion

Risk & Control Universe→ Control Design→ Encoded in System→ Operate→ Test (Walkthrough / Sample)→ Evidence→ Opinion

Outcome: Clean audit opinions; regulator confidence; findings closed quickly because the evidence sits in the system, not a SharePoint folder; lessons feeding back into design.

Artefacts the stage must produce

Risk & control matrix — per value stream from §01, with control objective, control activity, owner, frequency, evidence location.
SoD matrix — live, tested, monitored — see §04 Governance & Controls.
Audit trail extracts — on demand; against the auditor's sample selection.
Post-implementation review report — 6–12 months after go-live; covering benefits, controls, lessons.
Internal audit plan — rolling, risk-based, covering the platform within an enterprise plan.
External audit liaison pack — how the platform produces statutory accounts; reconciliations; sub-ledger ties; year-end procedures.
Regulator engagement record — submissions made, findings issued, remediation status.
Findings & remediation register — every audit finding with owner, target date, evidence of closure.

The decisions this stage must answer

Can we evidence — quickly — that the controls in the design pack are operating in production?
Do we know which findings are open, who owns each, and when each will close?
Has the post-implementation review actually happened — or has it been deferred until the next one is overdue?
Are we treating the regulator as a stakeholder of the platform, or as someone we'd rather not engage until we have to?

Where it goes wrong

Controls evidenced manually because the audit trail isn't query-able. SoD breaches accumulate because monitoring is point-in-time, not continuous. PIR scoped narrowly (or skipped) because the programme has closed and nobody owns it. Findings re-issued year over year because remediation slips. The regulator finds something internal audit didn't, and the conversation shifts from technical to existential.

Leader's question

"If the regulator walked in tomorrow and asked for evidence of three specific controls across three specific value streams — could I answer in days, or would I need months?"

Legacy Decommissioning

Parallel run, sunset, archive, final shutdown. The stage that confirms the new platform is actually live — by turning off the old one.

READ

What this stage is for

To formally retire the legacy systems the new ERP replaced — and to do it in a way that preserves the historical record, satisfies regulatory retention commitments, captures the licence and infrastructure savings the business case promised, and removes the security and operational liability the legacy system represents. The stage most programmes treat as someone else's problem. The stage where the value case quietly leaks if nobody owns it.

Why this stage exists at all

Most ERP business cases assume legacy savings. Most enterprises never realise them. The new system goes live, the legacy stays running “just in case,” and a year later the licences are still being paid, the infrastructure is still consuming budget, the security patches are still being applied, and the person whose job is to keep it running is still on the payroll. The new platform isn't really live until the old one is dark — and that requires a stage with its own discipline, its own owner, and its own kill date.

The four sub-phases, sequenced

Decommissioning runs as four overlapping sub-phases: Parallel Run (both systems live, legacy in shadow or limited mode), Sunset Planning (kill date set, retention strategy decided, archive format defined), Archive & Freeze (historical data extracted and validated, legacy goes read-only), Final Decommission & Evidence (system off, licences cancelled, certificate of destruction lodged). Each has different owners, different artefacts, different risks. Compressing them or skipping the second one is the most consistent failure mode.

Workflow

The decommissioning discipline

From parallel-running legacy to dark system with evidence

Parallel Run→ Sunset Plan→ Retention Decision→ Archive Build→ Legacy Read-only→ Decommission→ Evidence Lodged

Outcome: Legacy system formally dark; historical data archived in a queryable form that satisfies regulatory retention; licences cancelled; infrastructure released; integrations retired; the savings line item in the business case actually realised.

The historical-data retention decision

Inside this stage sits the structural decision most programmes punt on: what happens to the historical estate. Three options, each with different implications. Bring forward into the new ERP — typically only the most recent 1–3 years of transactional data, plus the master records still in use. Higher migration cost; lower archive cost; data available natively in the new platform. Archive in a queryable form — older transactional records, supporting documents, audit trails — held in an archive store (often cheaper, often vendor-provided) accessible by audit, finance, legal on demand. Lower migration cost; ongoing archive cost; data available but not native. Retire — data the retention policy no longer requires. Zero ongoing cost; gone. The decision is per data class, per record type, per regulatory commitment — and it has to be written, signed, defensible at audit.

Artefacts the stage must produce

Decommissioning plan — per legacy system, with kill date, sub-phase milestones, named accountable, dependencies, risks.
Retention policy — per data class, with the regulatory commitment that drives it (tax, audit, contractual, statutory) and the retention horizon. Signed by Legal, Compliance, and the data owner.
Archive specification — what format, what storage, what query mechanism, what access controls. Built for the auditor, not the database admin.
Archive validation report — evidence that the archive is complete, queryable, and matches source. Tested with sample evidence requests before legacy is decommissioned.
Integration retirement schedule — every legacy-connected integration mapped to a retirement date and a replacement (or formal sunset). See §03.
Licence & infrastructure release plan — what gets cancelled, when, with the saved cost line item tied to the business case.
Certificate of destruction — where data sovereignty, regulatory regime, or contractual commitment requires it. Issued by the disposal partner, lodged with Legal.
Final evidence pack — decommissioning certified complete, savings realised, audit position documented. Lodged with the benefits register (§10).

The decisions this stage must answer

What is the kill date — and who on our payroll is accountable for hitting it?
What retention horizon applies per data class, per regulatory regime — and who signed it?
What archive format will still be queryable in seven, ten, or fifteen years — beyond the lifespan of the vendor who built it?
Which integrations are retired, which are rerouted to the new platform, and which silently fail because nobody mapped them?
What licence and infrastructure savings are actually realised — versus carried forward in the business case but never collected?

Where it goes wrong

Legacy left running indefinitely “just in case” — with no kill date, no owner, no escalation path. The savings in the business case never materialise.

Retention policy defaulted to storage convenience — too short for the regulator, too long for cost, defensible to neither.

Archive format chosen by IT, optimised for storage. First evidence request from the auditor takes weeks because nobody can query it.

Integration stubs left in place — they fail silently, and the failure is discovered when a quarterly report comes up empty.

Licence renewals auto-process; nobody questions them. The legacy vendor invoice arrives every year and gets paid.

Historical data unfindable after archive — the format works in principle, but no one has actually queried it since the day it was built.

The auditor asks for a record, the new ERP doesn't have it, the archive can't surface it in time, and the conversation shifts from technical to existential.

Strategies that work

Kill date written before cutover, not after — with a named accountable whose performance review includes hitting it.

Retention policy signed by Legal & Compliance, per data class, against named regulatory commitments. Not a default, a decision.

Archive designed for the auditor. Queryable by audit roles, in business language, with retention metadata. Tested with sample evidence requests before legacy is decommissioned.

Integration retirement on a schedule — part of the decommissioning plan, signed at the same gate as the kill date.

Licence and infrastructure savings tied to the benefits register (§10) — with a named benefit owner who attests to realisation quarterly.

Archive validation as a discipline — every six months a sample evidence request is run against the archive to confirm it still works.

Certificate of destruction for data subject to sovereignty or contractual commitments. Lodged with Legal; surfaced at audit.

What success looks like

Eighteen months post go-live, the legacy system is dark. The licences are cancelled and the saving sits in the benefits register as realised. The infrastructure has been released. The integrations are retired. The historical data lives in an archive that the auditor has used at least once and confirmed works. The certificate of destruction is on file for the data classes that required it. The person who used to keep the legacy running is doing something else productive. The new platform is genuinely the system of record — not the new system of record alongside the old one.

Leader's question

"Have we set a kill date for the legacy system — and is there someone on our payroll whose performance review includes hitting it?"

After signature · The relationship that runs for a decade

Vendor & Partner Management.

Selection (§07-02 / §08-02) gets the signatures. The decade that follows gets the value — or doesn't. This section is the discipline of managing the software vendor and the implementation partner after the contracts are signed, when the formal procurement levers are gone and the relationship becomes the lever.

ITIL 4 Supplier Management practice ISO/IEC 19770 IT Asset & Software Management PMI Procurement Management COBIT APO10 · Managed Vendors

The software vendor relationship runs for ten years. The implementation partner relationship runs for the engagement, then transitions into a different kind of relationship — support, augmentation, the occasional release. Both have to be managed deliberately. Both fail in remarkably similar ways when they aren't: nobody is in the seat, the formal cadence lapses, and the enterprise discovers six months later that decisions have been drifting in someone else's interest.

Two relationships, two operating models

The vendor and the partner sit in different relationships to the enterprise. The vendor sells a product with a roadmap that moves on its own timeline. The partner sells a service that delivered against a defined scope. Managing both well means recognising they need different rhythms, different forums, different owners — and that the temptation to collapse them into "the providers" is the most reliable way to lose value from both.

The Software Vendor Relationship

Owned by the Vendor Account Executive on their side; by a named relationship owner on yours. A ten-year conversation.

READ

What this relationship is for

To keep the platform supported, current, and aligned to the enterprise's operating model — and to make sure the enterprise is a customer the vendor invests in rather than tolerates. A well-managed vendor relationship gets you faster access to product roadmap influence, sooner heads-up on deprecations, better escalation pathways when something breaks, and more weight in licence renegotiation when the contract reopens.

The cadence

Monthly — relationship owner ↔ Vendor AE. Open issues, support tickets of consequence, upcoming releases, escalations.
Quarterly — Business Review. Joint forum: relationship owner, product owner per module, vendor AE, vendor solution architect. Roadmap, adoption, value realised, friction points.
Annually — Executive Review. Sponsor + CIO ↔ vendor account leadership. Strategic direction, contract posture, escalation paths reviewed.
Pre-renewal — 12 months before contract renewal, the relationship gets renegotiated, not the contract. The contract follows.

Common pitfalls

Where it goes wrong

Vendor AE changes; the relationship resets and nobody on the enterprise side notices for six months. Support tickets routed through the implementation partner, so the vendor has no direct view of the customer's actual experience. Product roadmap conversations skipped because "we'll deal with it at renewal" — by which time the influence window has closed. The enterprise discovers a major roadmap shift (deprecation, repricing, acquisition) from a press release, not the AE.

Strategies that work

Named relationship owner on your side, distinct from the implementation partner. Usually CIO, head of enterprise apps, or COO depending on programme size.
Direct support channel. Tickets that matter get raised by your team, not via the partner — even if the partner provides the support service.
Roadmap influence ladder, used deliberately: customer advisory board → user group → product council, in that order, with executive sponsorship where it matters.
Reference-customer status traded for early access, roadmap weight, and direct executive lines. Worth more than discount.
Annual relationship health assessment — internal, written, honest. Reviewed against the strategic direction the platform is serving.

Leader's question

"If our Vendor AE changes tomorrow, would we hear it from them in the same week — or discover it three months later when an unfamiliar name appears on an email?"

The Implementation Partner Relationship

Active during the engagement; structurally different afterwards. Don't let the partner become BAU support by accident.

READ

What this relationship is for

To deliver the engagement against the SoW — and to transition cleanly to whatever the relationship looks like after go-live. Mature programmes treat the SoW as defining a finite engagement with a defined end-state. The most common failure is the partner relationship drifting into open-ended managed-service territory because nobody designed the transition.

The cadence during the engagement

Weekly — Programme Director ↔ Partner Engagement Lead. Delivery progress, risks, scope changes, named-people changes, financial position.
Fortnightly — Steering committee. Sponsor + Programme Director + Partner Engagement Lead + Partner Account Director. Decisions made, decisions deferred, scope reality, contractual posture.
Quarterly — Executive sponsor review. Sponsor ↔ Partner managing partner / account director. Health of the relationship, beyond delivery mechanics.
At every gate (§07) — formal acceptance against gate criteria. The decision packs the gate, not the slide.

The cadence after the engagement

Warranty window (usually 30–90 days post go-live) — defects covered under the SoW, handled at SoW SLA.
Transitional support (usually 3–12 months) — capacity for product owner backfill, hypercare augmentation, named-people retention. Priced and time-boxed, not open-ended.
Steady-state engagement — selective, deliberate, per release or per project. The default position is the enterprise runs the platform.

Common pitfalls

Where it goes wrong

Hypercare extends silently, then permanently. The partner becomes the platform support team by default — convenient, expensive, structurally wrong. SoW change requests accumulate because the change-request process is treated as friction rather than as the relationship's primary lever. Named people in the SoW quietly substituted with juniors during delivery. The partner's account director only appears when there's escalation noise — never during steady state, never building the relationship for the next engagement.

Strategies that work

SoW change-request rigour. Every CR has a written justification, a sponsor signature, and lands in a register the steering committee sees. The CR process is healthy when it slows things down — not when nothing changes.
Named-people retention clauses — the partner cannot substitute named people without enterprise approval. If a substitution happens, the relevant work pauses until the replacement is reviewed.
Defined transition plan from hypercare to BAU, with the partner exit date written and a backfill plan in the operating model.
Annual partner relationship review — even post-engagement. The partner who delivered yesterday's transformation is often the partner who'll be evaluated for tomorrow's.
Reference-flow discipline. Don't agree to be a reference site unless the relationship has actually been good. References are the partner's currency — use yours deliberately.

Leader's question

"Has the partner exit date been written down — and does the operating model already have a named person ready to take each accountability the partner is currently holding?"

The Business Relationship with the Programme

The internal relationship the programme has with its own enterprise. Owned by the Programme Director on the delivery side; by the Sponsor and business owners on the enterprise side.

READ

What this relationship is for

The other two relationships sit between the enterprise and external providers. This one sits between the programme and the enterprise that is funding it, absorbing the change, and inheriting the platform. It is the relationship most consistently underweight in vendor-management discussions — because the parties are all internal, the relationship gets treated as automatic. It isn't. The same disciplines (named owners, cadence that doesn't lapse, formal forums, escalation paths) apply, and the same failure modes appear when they don't.

The three internal stakeholder groups

Executive sponsorship — Sponsor, CFO, CHRO, COO, board. The decision-makers on operating-model commitments. The funders and the final accountable line.
Business owners & SMEs — the operating-side leaders whose teams will use the system, whose processes are changing, whose decisions are being encoded. The source of operating-model truth.
The workforce — the people who will operate the platform daily. Reached through the super-user network and via the change-management function, not directly.

The cadence

Weekly — Programme Director ↔ Sponsor. Open issues, decisions pending, scope reality, escalations. The relationship that holds the rest together.
Fortnightly — Programme working forum with business owners. Operating decisions per workstream, SME availability, design sign-offs, UAT progression.
Monthly — Programme Control Group / Steering Committee. Cross-business owners + Sponsor + CFO + Programme Director. Gate decisions, risk position, budget reality.
Quarterly — Executive review. Sponsor reports to ELT / board. The benefit case re-tested against delivery progress.
Continuously — Super-user network engagement. Daily during hypercare; monthly thereafter. The workforce voice that doesn't otherwise reach the programme.

Where it goes wrong

Sponsorship cadence lapses. The weekly with the Sponsor becomes fortnightly, then monthly, then ad-hoc. By the time something needs the Sponsor's authority, the relationship has gone cold.

Business owners disengage when the programme stops asking them difficult questions. The design pack lands at sign-off without their fingerprints — and UAT becomes the moment the truth shows up.

SMEs participate part-time. The most consistent under-investment in any ERP programme — and the most reliable predictor of UAT pain.

The workforce is informed, not engaged. Comms heavy on broadcast, light on signal back. Adoption arrives as a surprise to the programme team.

Bad news doesn't travel up. The Programme Director shields the Sponsor from the picture until the picture is too late to change.

Strategies that work

Sponsor cadence held in the diary as protected time. Cancellation requires the Sponsor's own escalation, not the Programme Director's accommodation.

SMEs released full-time with backfill funded from the programme budget. If the programme can't afford the SME, the programme can't afford the truth.

Business owners present at design sign-off in person, with named accountability for the design they sign. UAT is then a confirmation, not a discovery.

Super-user network active from week 1 of design, not week 1 of go-live. Their voice feeds the design forum, not just the training plan.

Bad-news protocol. The Programme Director commits, in writing, that any RAG status downgrade reaches the Sponsor within 48 hours — without filter.

The internal-relationship health signals

Sponsor attendance at PCG — 100% is the only acceptable number. Anything else is a red flag.
SME hours actually delivered vs planned — measured every fortnight. Under-delivery is escalated, not absorbed.
Business owner sign-offs against accountability — are sign-offs evidenced, or are they ticking a box?
Super-user engagement — measurable: meeting attendance, design contributions made, issues raised.
Escalation freshness — how long between an issue arising and the Sponsor hearing about it? If the answer is "weeks," the relationship is broken.

Leader's question

"If the Sponsor were asked today what the three biggest risks to this programme are, would the Sponsor's list match the Programme Director's list — or have we been telling different stories upward?"

Plus —

The Joint Operating Rhythm

An overlay across the three relationships above. When the parties are in the same room — and when they aren't. The forums that govern interactions between vendor, partner, and the enterprise.

READ

What this is for

To make sure decisions that affect multiple relationships are made deliberately — not in serial corridors where one party hears the news later and adjusts position accordingly. Joint forums are valuable; they're also where coalition behaviour can quietly form against any party not in the room. Run them with that in mind.

When to run them jointly

Major release planning — vendor announces a release; partner advises on impact; business owners weigh adoption; enterprise decides.
Architecture & integration decisions — where the partner's recommendation is shaped by vendor's roadmap and constrained by business reality.
Production incidents of consequence — vendor + partner + enterprise in the same incident bridge, with a single named incident commander on the enterprise side.
Renewal-adjacent conversations — joint roadmap workshop, 12–18 months pre-renewal. Surfaces interdependencies and gives the enterprise leverage in all negotiations.

When to run them separately

Partner performance conversations — never with the vendor in the room.
Vendor roadmap influence — partner's voice can amplify or distort. The enterprise needs its own direct view.
Commercial negotiations — always separately. Always.
Internal escalations — bad news between programme and Sponsor stays in the room. Not in front of partners or vendors.
Escalations against either external party — pick the right room.

The vendor-partner-business triangle

In healthy programmes, four parties operate with clear edges. The enterprise sets direction. The vendor provides product and roadmap. The partner delivers and supports. The business — through the Sponsor, business owners, SMEs, and the workforce — defines the operating-model commitment and absorbs the change. When any edge collapses — usually the enterprise's, by absence — the others start making decisions on its behalf. The single best protection is named ownership on the enterprise side for each relationship, and a forum cadence where that ownership is exercised visibly.

Leader's question

"In the last quarter, how many decisions about our platform were made by the vendor-partner pair, with the business hearing about them afterwards?"

The five disciplines of vendor & partner management

Five practices that distinguish enterprises whose vendor relationships compound from enterprises whose vendor relationships drift. Each one is cheap; the absence of each is expensive.

Discipline 01

Named relationship owners

One named person on the enterprise side for the vendor relationship, one for the partner. Not "the CIO's office." A person, in the seat, with the relationship as a non-trivial part of their role.

Replaced if the person changes; reviewed at every executive transition.

Discipline 02

Cadence that doesn't lapse

Monthly, quarterly, annually — held in the diary, not optional. Cadence health is a leading indicator of relationship health. The first cancelled quarterly is a signal, not a scheduling issue.

Reviewed annually as part of the relationship health assessment.

Discipline 03

SoW & contract discipline

Change requests treated as the relationship's primary lever — written, justified, signed off, registered. Contract clauses tested for actual exercisability, not just compliance.

Owned by Programme Director during engagement; Product Owner thereafter.

Discipline 04

Pre-renewal rhythm

Vendor renewal posture set 12 months before the contract expires, not 3. Joint roadmap workshop, internal alternative analysis, reference-flow review, executive sponsor briefing.

Owned by relationship owner; sponsored by CIO / CFO.

Discipline 05

Transition planning, post-engagement

Partner exit date written. Backfill plan named. Knowledge transfer in writing, not in heads. The default position is the enterprise runs the platform, with selective augmentation, not the partner runs it indefinitely.

Owned by Programme Director, signed off by Sponsor at gate 06.

Cross-cutting

Coalition awareness

Vendor and partner have a relationship with each other that predates and outlasts the enterprise's engagement. Healthy under most conditions; coalition-like under pressure. Worth naming, watching, and managing — never assuming.

Owned by the enterprise relationship owners, jointly.

The thread that pulls everything together · What the programme was actually for

Benefits Realisation.

Every ERP business case promises benefits. Most programmes can't say, twelve months after go-live, whether those benefits actually landed. This section is the thread — what good benefits realisation looks like, where it fails, and how the practitioner keeps the predicted operating-model change alive long after the press release.

MoP Management of Portfolios — Benefits MSP Managing Successful Programmes — BRM PMI Benefits Realisation Management framework APM Body of Knowledge — Benefits

A benefit, properly defined, is a measurable change in operational reality that someone is accountable for. Anything else is a forecast. The hardest part of ERP isn't writing the business case — it's keeping the predicted change visible through delivery, through cutover, through hypercare, through year one, and through to the moment someone can defend it at audit or stop claiming it at all.

The benefits chain — five links

Benefits realisation is a chain. Break any link and the value quietly disappears. Most programmes break the chain at the same two or three points; mature ones name the chain at discovery and protect it through every subsequent stage.

Link	What it is	What breaks it	Where it's defended
01 · Operating-model change	The specific change in how work is done — process simplified, decision faster, manual effort removed, control automated.	Stated in capability terms ("better reporting"), not behaviour terms.	§07-01 Discover · §08-01 Needs Analysis
02 · Measurable outcome	The quantified result — cycle time, FTE, error rate, dollars, risk reduction. With a baseline, a target, and a date.	Targets set against the business case for funding, not against operational truth. No baseline.	§07-01 Business case · §10 Benefits register
03 · Named benefit owner	The person accountable twelve months out — not the sponsor, not the BA, not the partner. A line owner with the operational accountability.	Owner is the role, not the person. The person moves on. The role is reorganised. Accountability evaporates.	§06 Roles · §10 Benefits register
04 · Tracking discipline	The cadence and instrument — quarterly review, dashboard, executive forum — that keeps the benefit visible until it lands.	The dashboard is built; the forum is scheduled; attendance drops; nobody objects.	§07-06 Realise · §08-08 Continuous Improvement
05 · Closure	The formal moment the benefit is declared realised, partly realised, or retired. Written, evidenced, defensible at audit.	Benefits left open indefinitely. Or quietly retired at the next programme to free up the books.	§08-09 Audit & Assurance

The benefits register — what it actually needs to be

The benefits register isn't a list. It is a live document with structure. Each entry should answer the five-link chain explicitly, with dates, owners, and evidence. Most benefits registers are written once for the business case and never updated; the practitioner's job is to make the register live for the full lifecycle, not just the funding moment.

Field	What it captures
Benefit ID & statement	One line — the operating-model change in behaviour terms, not capability terms.
Value stream	Which of the §01 value streams this benefit belongs to. Ties benefits to operational reality.
Baseline	Current-state measurement with method and date. Without it, no benefit can be claimed.
Target	The specific change — quantified, with the date by which it's expected to land.
Measure	How the benefit will be measured — the metric, the source, the cadence.
Benefit owner	A named person with line accountability. Reviewed if the person changes role.
Dependencies	Other benefits, capabilities, or operating-model changes this depends on.
Status	Predicted · Tracking · Realised · Partly realised · Not realised · Retired. Updated quarterly.
Evidence	Where the proof lives — dashboard, report, audit trail, signed attestation.
Kill criterion	What evidence would say this benefit is not happening and should be retired or escalated.

The cadence that keeps benefits alive

Benefits don't track themselves. The cadence below is the minimum rhythm that prevents drift between predicted and realised value.

Day 0–90

30 / 60 / 90-day checkpoints

Three structured reviews after go-live, each answering the same three questions: Is the new behaviour happening? Is the old behaviour stopping? Is the predicted operational change visible? Anything else is theatre.

Owner: Change Manager + Benefit owners, reviewed with Sponsor.

Quarter 1–4

Quarterly benefits review

Every benefit, every quarter, until status is Realised, Partly Realised, or Retired. Status changes require evidence. Forum has executive standing — not a working group, not optional.

Owner: Sponsor (chair) + Benefit owners + CFO + Product Owner.

Year 1 anniversary

Twelve-month post-implementation review

The formal moment the original predictions are tested against operational reality. The output goes to the board (if the original case did), to internal audit (always), and back into the practice library so the next decision pack learns from it.

Owner: Sponsor, supported by internal audit and the Product Owner.

Years 2–5

Annual benefit attestation

Each benefit owner attests annually that the benefit is still being realised, or formally retires it. Connects to the audit cycle (§08-09) so that benefits left "claimed" indefinitely get pressure-tested.

Owner: Each Benefit owner; reviewed by internal audit.

Common pitfalls — and what to do instead

Benefits realisation fails in remarkably consistent ways. The patterns below are the ones a senior practitioner sees again and again — and the most reliable counter-moves.

Pitfall 01

Benefits stated as capabilities, not behaviours

"Better reporting" or "improved visibility" — capability statements that cannot be tested operationally. They survive the business case and die quietly afterwards because nothing actually has to change for them to be claimed.

Counter: Force a behaviour statement. "Cycle time for the monthly close drops from 12 to 7 days, measured by [X], by [date]."

Pitfall 02

No baseline measurement

The benefit case quotes targets but no current-state baseline. After go-live, the team realises they don't know what "before" looked like — and the variance argument starts.

Counter: No benefit enters the register without a baseline measurement, source, and date.

Pitfall 03

Benefit owner is a role, not a person

"The Head of Operations" is named. Then the head of operations leaves. The benefit becomes orphaned and nobody quite owns it.

Counter: Named person + named successor + re-confirmation when either changes.

Pitfall 04

Benefits tracked at the programme, retired at BAU

Programme tracks them through hypercare. Programme closes. BAU never picks them up. The benefits register goes into a drawer.

Counter: Programme closure is conditional on a signed handover of the benefits register to the Product Owner / Benefit owner forum.

Pitfall 05

Realisation conflated with adoption

Training completion is reported as benefit realisation. Adoption is a leading indicator, not the benefit itself. The system is in use — but is the predicted operational change actually happening?

Counter: Adoption metrics and benefit metrics tracked separately. Adoption is necessary; benefits are sufficient.

Pitfall 06

Benefits compounded in next programme's case

The next transformation's business case claims uplift over a baseline that already includes unrealised benefits from this one. The same dollar value gets sold twice.

Counter: Annual benefit attestation tied to internal audit. Unrealised benefits formally retired before being re-counted.

What benefits realisation actually looks like when it works

The practice that makes decisions survive · How architecture choices stop evaporating

The ADR Discipline.

An Architecture Decision Record is a one- to two-page document that captures a structural choice the programme made, the context that drove it, the alternatives considered, and the consequences accepted. Cheap to write; transformational at scale. The single practice that turns the five compounding decisions in §13 into decisions that actually compound.

TOGAF ADM · Phase B/C/D outputs arc42 ADR template Nygard "Documenting Architecture Decisions" — original ADR pattern ISO/IEC/IEEE 42010 Architecture description

Most ERP programmes make several hundred architecture decisions. Most enterprises can't tell you which decisions were made, by whom, on what evidence, with what alternatives considered, or with what consequences accepted. The decisions are encoded in configuration, baked into integrations, and embedded in master data — but the reasoning has evaporated into Slack threads and steering decks. Two years later, somebody asks "why did we do it this way?" and nobody can answer. Three years later, the decision quietly gets reversed without anybody realising it was a decision in the first place.

The ADR pattern is the practice that prevents this. Originated by Michael Nygard in 2011 as a lightweight pattern for software architecture, it has become the working discipline of mature programmes — and it transfers directly to ERP. Each ADR is one or two pages. Each captures a structural choice. Together, they form the architecture's institutional memory.

What an ADR contains

A useful ADR has nine fields. Anything less and the document becomes ambiguous a year later; anything more and the discipline collapses under its own weight. The point is to be writable in 30–60 minutes by the person closest to the decision — not to be a heavyweight architecture artefact.

Field	What it captures
ADR number & title	Sequential ID and a one-line title. ADR-001, ADR-002, never reused. Title states the decision in active form: "Position management vs employee-centric design," not "Discussion of HCM model."
Status	Proposed · Accepted · Deprecated · Superseded by ADR-NNN. The status changes; the ADR doesn't get rewritten. Superseded ADRs stay in the register with their successor linked.
Date & decision-makers	When the decision was accepted and who made it. Names, not roles — “Sponsor + CFO + Enterprise Architect, 14 March 2026.”
Context	The situation that forced the decision. What were we trying to achieve? What constraints were binding? Why now? Two paragraphs; readable by someone who joined the programme yesterday.
Decision	The choice made, stated unambiguously. Active voice. "We will use position management as the structural model for the workforce, with employees attached to positions rather than positions attached to employees."
Alternatives considered	What else was on the table. Each alternative with one or two lines of why-not. Not exhaustive — material alternatives only. "Employee-centric design" with a paragraph of trade-offs.
Consequences	What this decision commits the enterprise to. Both positive (what it enables) and negative (what it forecloses). Includes downstream implications for other modules, master data, integrations, controls.
Evidence & references	What informed the decision. Workshop notes, vendor advice, regulatory references, prior ADRs, market research. Links, not summaries.
Review trigger	What would cause the decision to be re-opened. Examples: "If EBA renegotiation changes the position definition," "If the vendor deprecates position-based licensing." Without this, deprecation drifts silently.

Which decisions actually need an ADR

Not every decision. The discipline collapses if every working-group conversation produces an ADR. The right test: would a senior practitioner joining the programme in two years need to understand why we did this, not just what? If yes, ADR. If no, working notes.

Class 01

Structural data decisions

Chart of accounts hierarchy. Position vs employee model. Customer master ownership (ERP vs CRM). Item master attribute set. Asset hierarchy level (functional location vs equipment vs serialised). Project hierarchy logic.

Example: "ADR-014 · Position management as workforce structural model"

Class 02

Integration architecture decisions

Direct vs middleware vs streaming patterns. Real-time vs scheduled batch. Master-data-master location. Idempotency posture. Error-handling and retry policy. Choice of integration platform.

Example: "ADR-027 · MuleSoft as the integration platform for ERP ↔ enterprise estate"

Class 03

Controls & security decisions

Role design model. SoD matrix structure. Identity-provider integration. Audit-trail granularity. Delegation framework. Privileged access model. BCP/DR posture.

Example: "ADR-041 · Joiner-mover-leaver via HR-driven RBAC"

Class 04

Customisation decisions

Every RICEFW item that survives the "configure don't customise" default. Each customisation is an ADR with its justification, alternatives, and the long-tail consequences for LCM cost.

Example: "ADR-056 · Custom rostering workflow for nursing classification override"

Class 05

Operating-model decisions

Boundary between modules and adjacent systems. Where transactions originate. Reporting layer location. Post-go-live product team structure. Centralised vs federated governance.

Example: "ADR-073 · Reporting and analytics via separate lakehouse, not ERP-native"

Class 06

Trade-off & constraint decisions

Where speed was chosen over correctness; where local was chosen over enterprise; where build was chosen over buy. The decisions sometimes left implicit — and most consequential when surfaced.

Example: "ADR-088 · Accept Q3 close on legacy system to enable phased cutover"

The ADR lifecycle — how decisions stay live

An ADR isn't a one-off artefact. It moves through states; it gets superseded by new ADRs; it earns its keep only if the register is treated as live. The lifecycle below is the rhythm that keeps it alive.

Stage 01

Proposed

Draft written by the person closest to the decision. Reviewed in a working forum. Alternatives explored explicitly — most poor ADRs are made better by forcing a second alternative.

Usually drafted by: BA Lead, Architect, or workstream lead.

Stage 02

Accepted

The decision is made. Status changes; decision-makers named with date. Anything that needed the decision now references the ADR by number. The ADR enters the register.

Accepted by: named decision-makers per §06 decision-rights matrix.

Stage 03

Reviewed at trigger

The review trigger fires (regulator change, vendor deprecation, business model shift). The ADR is re-opened — either confirmed or superseded. Confirmed ADRs get a new "reviewed on" date; superseded ADRs link to their successor.

Owned by: Architect; reviewed at quarterly ADR forum.

Stage 04

Superseded

A new ADR replaces an old one. The old ADR stays in the register with status "Superseded by ADR-NNN." History is preserved; the institutional memory is intact. Both the original reasoning and the reason for change survive.

Owned by: whoever drafted the superseding ADR; signed off by the original decision-makers where possible.

Common pitfalls — and what to do instead

The ADR discipline fails in three predictable ways. Each has a reliable counter-move.

Pitfall 01

ADRs written retrospectively

Decisions are made under pressure; ADRs get "caught up on" three months later. By then the alternatives considered are reconstructed, not remembered. The discipline becomes archaeology.

Counter: ADR written before the decision is accepted, not after. If there's no draft, the decision isn't ready.

Pitfall 02

ADR register becomes a graveyard

ADRs are written, accepted, and never reopened. Triggers fire silently because nobody reviews them. The register exists; it doesn't operate.

Counter: Quarterly ADR review forum. Standing item: which triggers have fired since the last review?

Pitfall 03

Every meeting produces an ADR

The discipline collapses under its own weight. Working-group decisions get the same treatment as architecture decisions. Nobody can find the consequential ones in the noise.

Counter: A clear test for what earns an ADR — would a senior practitioner in two years need to understand why? Else, working notes.

Pitfall 04

ADRs sit in the partner's system, not yours

Implementation partner uses ADRs internally; the enterprise never sees the register or owns it. When the partner leaves, the institutional memory goes with them.

Counter: ADR register owned by the enterprise from day one — partner contributes, doesn't own.

ADRs and the five compounding decisions

The five decisions named in §13 — chart of accounts, master data ownership, integration architecture, controls fabric, post-go-live operating model — are exactly the decisions that should have ADRs. The five-decision checklist tells the leader which decisions to own. The ADR discipline is how those decisions get recorded so they survive the leader, the programme, the implementation partner, and the next transformation.

The discipline beneath the hype · Three layers, one readiness gate

AI & the ERP.

AI shows up in ERP programmes at three completely different layers — and most leaders blur them into one conversation. This section separates them, names what the practitioner uses AI for during delivery, what the vendor ships embedded in the product, what the enterprise can build on top, and the data-readiness gate that determines whether any of it actually works. The honest version, not the demo version.

NIST AI Risk Management Framework ISO/IEC 42001 AI Management Systems EU AI Act · High-risk system obligations OECD AI Principles Vendor frameworks · Workday Illuminate, SAP Joule, Oracle AI, Microsoft Copilot, ServiceNow Now Assist

Most ERP conversations about AI compress three separate decisions into one. The vendor demo shows an agent answering a question; the implementation partner offers an AI-augmented build; the CFO asks what AI does for the business case. These are three different decisions with different timelines, different governance, different risks. The single most useful thing a senior leader can do is to keep them separate — and to apply the same readiness gate to all three: is the data layer governed enough to make AI a value-add rather than an automated way to produce confident nonsense?

The three layers, separated

The framework below is the practitioner's map of where AI actually lives in an ERP programme. Each layer has different actors, different artefacts, different evidence, and different failure modes. Treating them as the same conversation is why most enterprise AI initiatives launched in 2023–25 quietly stalled in 2026.

AI in the Practitioner's Craft

What the BA, PM, architect, change manager actually use AI for during delivery. The most immediate, lowest-risk, highest-adopted layer.

READ

What this layer is

The AI tools that practitioners use to do their jobs faster and more rigorously — drafting requirements documents, summarising stakeholder interviews, analysing process maps, accelerating test-case generation, writing cleaner status reports. Not embedded in the ERP. Not built on top of the platform. Just the working surface of the programme team. The least controversial layer; the layer where the value is most immediate; the layer where most enterprises are already, often without realising it.

What practitioners actually use AI for

Requirements drafting & refinement — first-draft user stories from interview transcripts, acceptance-criteria expansion, gap analysis between scope and design.
Stakeholder interview synthesis — converting hours of recorded conversation into structured notes, themes, decisions, open questions.
Process modelling acceleration — generating swimlane drafts from narrative descriptions; converting BPMN to plain English for review forums.
Test-case generation — happy path + edge cases + exception scenarios from a single design document.
RAID register triage — categorising new risks, linking to historical patterns, identifying duplicates.
Communications drafting — first-draft executive updates, change-management collateral, stakeholder briefings.
ADR drafting — first pass on context, alternatives, consequences from a working-group transcript.
Code & integration support — for the technical workstreams, the same value the wider engineering world is now demonstrating.

Where it goes wrong

AI drafts treated as final. The whole point of using AI for first-draft work is the practitioner reviews, corrects, and owns the output. When the practitioner doesn't, the AI's confident nonsense ends up in the design pack.

Tools chosen by individuals, not policy. Some BAs use one tool, some another. Sensitive material (org structure, EBA detail, financial design) leaks into consumer-grade tools.

No audit trail. AI-generated artefacts presented without indication of origin. The reasoning behind a decision can't be reconstructed because the “reasoning” was an LLM completion.

Adoption uneven. Some practitioners are using AI hard; others aren't using it at all. Output quality varies for reasons the leader can't see.

Strategies that work

Enterprise AI tools, not consumer ones. Pick the tooling with the right data residency, retention, IP posture for your environment. Pay for it.

AI use is declared, not hidden. Practitioners note where AI was used — the draft, the synthesis, the analysis — and the practitioner owns the final output.

Reusable prompt patterns. Like accelerators in a methodology: prompts for requirements drafting, interview synthesis, test-case generation. Maintained by the BA Lead.

AI fluency as a team capability. Treat it as a learnable practice, not innate talent. Pair sessions, examples, retrospectives.

Sensitive-content guardrails. Org structure, EBA detail, named individuals — clear policy on what can and can't be fed into which tool.

What this layer does NOT cover

Not AI making decisions. Only AI assisting practitioners who make decisions.
Not AI in production system outputs. Only AI in programme-team artefacts.
Not autonomous agents. Only practitioner-driven, human-reviewed work.

Leader's question

"Have I given the programme team enterprise-grade AI tools, declared the use policy, and named someone accountable for fluency — or am I assuming each practitioner is figuring it out alone?"

AI Embedded in the ERP Product

What the vendor ships. Workday Illuminate, SAP Joule, Oracle AI Agents, Microsoft Copilot in Dynamics, ServiceNow Now Assist, Salesforce Agentforce. The leader's decision is when and how, not whether.

READ

What this layer is

The AI capabilities the software vendor builds into the platform itself — increasingly the front door of every major ERP product. Conversational interfaces over the data, generative summaries of records, anomaly detection in transactions, recommendation engines for actions, embedded agents that draft requests or surface insights. The leader's decision here is not whether to have AI (the vendor decides that) but when to turn it on, how to govern it, what to integrate it with, and what to opt out of.

The taxonomy of vendor-embedded AI

Assistive AI — drafting, summarising, suggesting. The user reviews and accepts or modifies. Low autonomy; high oversight.
Predictive AI — forecasting, anomaly detection, classification. Provides signals; the user (or workflow) acts on them.
Generative AI — produces content, reports, descriptions, code. Output is consumed directly by users or downstream systems.
Agentic AI — autonomous task execution. Agent takes an objective, plans steps, calls tools, may write to the system. High autonomy; governance is the principal cost.

Each kind has different evidence requirements, different audit posture, different controls. The mistake is treating them as one capability.

The adoption decisions per release

Which features to enable — by module, by user group, by use case. Not blanket on/off.
What to feed it — which data classes it can read; which it can't.
Who has access — role-based, not blanket. SoD applies to AI access too.
What controls apply — approval routing for AI-suggested actions, audit-trail capture of AI involvement, human-in-the-loop where the regulator expects it.
How to measure value — adoption ≠ benefit. What operational metric is meant to move?
What to opt out of — vendor's customer data use for training; cross-tenant model improvement; future feature defaults.

Where it goes wrong

Adoption by default. Vendor turns features on; nobody at the enterprise notices until they fire in front of a user, customer, or auditor.

Demo-driven adoption. Feature looks impressive in the sales pitch; rolled out without value-case, without governance, without measurement.

SoD ignored on AI. Embedded agent can perform actions a human in the same role couldn't, because nobody mapped agent capabilities into the SoD matrix.

Audit trail missing. AI made a suggestion; user accepted; the record shows the user, not the AI involvement. The regulator can't tell what was AI-influenced.

Customer-data posture not understood. Vendor uses tenant data for cross-customer model improvement; enterprise discovers this in the contract too late.

Strategies that work

AI release governance — every vendor release with AI features goes through the §08-07 LCM cadence with an AI assessment: what's enabled, who, why, with what controls.

SoD matrix extended to AI capabilities. Embedded agents are roles too. They have access, they can act, they belong in the matrix.

AI provenance in audit trail. Every AI-involved action logged with the model, version, prompt or trigger, suggestion, user decision.

Opt-out posture defined. Customer-data use, training, cross-tenant — enterprise position written and renewed at every contract review.

Value-case per feature. Adoption requires a named owner, baseline metric, target outcome, review cadence.

Human-in-the-loop where regulator expects it. Decisions with material customer impact, regulatory exposure, or workforce consequence retain explicit human accountability.

What to ask the vendor — at every quarterly business review

What AI capabilities are in the current release? What's coming in the next two?
What's the default-on vs default-off posture? Has it changed?
What data is used for what — training, fine-tuning, cross-tenant, customer-specific?
What is the model lineage — vendor-built, third-party, open-source? What is the upgrade path?
What evidence do you provide for audit — bias testing, accuracy thresholds, retraining cadence?
What is the opt-out posture for each feature?
What is the customer-data deletion path if we exit?

Leader's question

"For the AI features the vendor has enabled in our tenant — do I know what's on, who can use what, and how each one would survive a regulator asking for evidence of human accountability?"

AI Built on Top of the ERP Estate

What the enterprise builds itself. Agentic workflows over the platform, automation in the integration layer, intelligence in the reporting / lakehouse stack. The build-vs-buy decision, the readiness question.

READ

What this layer is

The AI capabilities the enterprise builds itself — sitting on top of the ERP, integrating across multiple systems, often delivered through agentic platforms (LangChain, custom orchestration, Claude / GPT / Gemini APIs, agentic SDKs), data platforms (Databricks, Snowflake, Microsoft Fabric, Google BigQuery), or specialist tooling. This is the most ambitious layer; the layer with the highest variance in outcomes; the layer most consistently launched before the data layer is ready to support it.

Common use cases (the genuinely valuable ones)

Cross-system intelligence — answering questions that require data from ERP + CRM + ITSM + asset management simultaneously. The lakehouse + agent combination.
Workflow automation — agents that take routine business processes (invoice triage, customer onboarding, exception handling) and execute them end-to-end with defined escalation.
Decision support — agents that gather context, analyse, recommend; human decides. Distinct from agentic execution.
Customer-facing intelligence — answering customer queries against the operating data, with controls.
Workforce productivity layers — domain-specific copilots for finance, HR, operations, built over the enterprise data estate.

The build-vs-buy question, sharpened

Most "AI use cases" can be solved one of four ways: wait for the vendor (Layer 02), buy a specialist product, build a thin layer on top, build a substantial agentic system. The build-vs-buy question is more nuanced than it looks. The decision usually turns on three factors: data dependency (does the use case need data the vendor doesn't have access to?), vendor roadmap (is the vendor 6–18 months from shipping this?), and operating-model differentiation (is this a place where the enterprise's specific operating model creates value that an off-the-shelf solution would erase?). When all three favour building, build. Otherwise, wait or buy.

Where it goes wrong

Built ahead of data readiness. Agents launched on a data estate where the master data isn't governed, the integration layer is fragile, the lineage isn't traceable. Output is plausible nonsense.

Pilot proliferation. Dozens of small experiments running, none owned, none scaled, none retired. The enterprise has an "AI portfolio" of orphans.

Built where the vendor would ship in 12 months. Enterprise engineering effort spent recreating capabilities the vendor will release at a fraction of the cost.

Agentic systems without controls. Agent calls system APIs without the SoD, audit, approval routing that a human user would face. Discovered when the agent makes a mistake at scale.

Treated as a project, not a product. Launched, declared a success, abandoned. Six months later nobody owns it; twelve months later the model has drifted.

Strategies that work

Data readiness gate, applied seriously. Before any agentic system is built on a value stream, the master data for that stream is governed (§02), the integration layer is contract-managed (§03), the audit trail is mature (§04).

Portfolio discipline. Every AI initiative has a named owner, value case, kill criterion. The portfolio is reviewed quarterly; orphans are retired.

Build only what compounds. Three filters: depends on differentiated data, not coming from the vendor, ties to a measurable operating-model outcome. If any of those fails, wait or buy.

Agents go through the same controls as users. SoD applies, audit trail captures, approval routing fires. Build the controls into the agent, not around it.

Product operating model from day one. Each AI capability has a Product Owner (§06), a backlog, a release cadence. Not a project that ends; a product that compounds — see §08-08 Continuous Improvement.

Model governance discipline. Model registry, version control, drift monitoring, retraining cadence, evaluation gates. Treat the model with the same seriousness as the integration layer.

Leader's question

"For each AI initiative built on top of our estate — can I name the owner, the operating-model outcome it's tied to, the kill criterion, and the date by which the value case must be evidenced or the initiative retired?"

The data-readiness gate

Across all three layers, one question determines whether AI is a value-add or an expensive way to produce confident nonsense: is the data layer governed enough to support it? Most enterprise AI initiatives launched in 2023–25 launched ahead of this gate, and quietly stalled when they ran into it. The discipline that keeps a senior leader honest is to apply the gate explicitly before sponsoring AI work — at any of the three layers.

The honest signs you are NOT ready

Master data ownership is contested. Customer master lives in CRM and ERP without reconciliation. Item master has 30% duplicates. Asset hierarchy was migrated as-is.

Reporting is built on extracts, not contracts. Every team has their version of "the truth." The lakehouse contains everything and trusts nothing.

Integration estate is undocumented. No catalogue. Every integration lives in someone's head.

Audit trail is technical logging, not business evidence. Auditor asks for proof; the answer is a database dump.

Data steward roles are named but not empowered. Stewards exist on paper; the operating reality is that nobody can stop bad data being created.

The honest signs you ARE ready

Master data masters are named, single, and respected. One customer master. One item master. One position model. Conflicts go to the data governance forum.

Reporting comes from contracts, not exports. The lakehouse is fed by integration contracts (§03); lineage is traceable; freshness is measurable.

Integration catalogue is live. Every flow registered, owned, monitored. Failure modes are documented, not implicit.

Audit trail tells a business story. “Who approved this and when” is answerable in minutes, not weeks. AI provenance is part of it.

Data stewards have authority. Stop-the-cutover authority during programmes. Stop-the-feature authority in steady state.

What never to delegate — the practitioner's stance

Across all three layers, there are decisions an AI must never make on the enterprise's behalf. The list is short, but it has to be explicit, because the temptation in every programme is to delegate one more thing.

What stays human	Why
The operating-model commitments	Chart of accounts, master data ownership, integration architecture, controls fabric, post go-live model. The five decisions of §13. AI can help analyse; humans must decide. If a decision compounds for a decade, the accountability is human.
Acceptance of design	The sponsor recognising the design as what they committed to is a human moment. AI can compare, summarise, flag drift. The signature is human.
Go / no-go decisions	Cutover, release, rollback, kill. AI can evidence; humans decide. Particularly anything affecting payroll, regulatory submission, or customer-facing operations.
Material customer or workforce decisions	Pricing changes, terminations, escalations, dispute resolutions. Human-in-the-loop is not a slogan; it is the legal and ethical floor.
Final accountability for outcomes	The benefit owner is human, named, present at every review. AI can help measure; it cannot be accountable.
Decisions where the regulator expects human judgment	EU AI Act high-risk categorisations, financial advice, medical decisions, employment screening. Where the law requires human accountability, AI is a tool and human is the decision-maker — without exception.

The leader's stance

Three things from the senior leader, repeated until the team internalises them.

Stance 01

Separate the three layers

Insist that AI conversations explicitly name which layer is being discussed. Craft, embedded, or built. The conflation of the three is where most enterprise AI strategies fail before they start.

Reviewed at: every quarterly business review with the vendor; every AI initiative kick-off.

Stance 02

Apply the data-readiness gate

Before sponsoring AI work at any layer, demand evidence the data layer can support it. If the answer is "we'll fix the data later," the AI work is premature.

Owned by: the Sponsor + the Architect; gate held against the §02 master data section.

Stance 03

Name what stays human

The list above isn't theoretical. The senior leader names — explicitly, in writing — what decisions stay with humans, and audit-tests adherence. The list grows over time; it never shrinks.

Owned by: the Sponsor + General Counsel + CFO; reviewed annually.

Cross-cutting

AI provenance in the record

Every AI-influenced decision is recorded as such. The model, the prompt or trigger, the output, the human decision. ADR-style discipline (§11) applied to AI use, so that two years later the reasoning is reconstructable.

Owned by: the Architect + Risk; integrated with the audit-trail design (§04).

The leader's checklist · Five that pay back for a decade

Five Decisions That Compound.

Most ERP decisions are reversible. A few are not. The senior leader's job is to know which is which — to spend disproportionate time on the few that compound, structurally, for the next ten years, and to make sure each one is recorded as an ADR (§11) so the reasoning survives.

The decisions below are the ones the senior leader must own personally — not delegate to the implementation partner, not absorb into a workstream lead's remit. Each one has a long tail; each one is expensive to reverse; each one materially shapes what the next decade of operations will feel like. Each card below names the choice being made, the diagnostics that narrow the answer, where the supporting material lives in the rest of this guide, and the signals that tell you whether the decision is being owned at the right level or quietly drifting away.

The chart of accounts & cost-centre hierarchy

The operating model in numbers. Owned by CFO; reviewed by COO; approved by the sponsor.

READ

The choice

How the business will measure itself for the next decade. Specifically: the segment dimensions (entity, function, region, product, project, customer); the account-number structure and depth; the cost-centre hierarchy and its alignment with the position hierarchy; the mapping rules that translate operations into ledger postings.

What the right answer depends on

What operating model are we building toward — not the one we have today? CoA built for the past calcifies the future.
What dimensions does the board, the regulator, and the CFO actually need to see? Anything else is decoration that creates downstream work.
How will mergers, acquisitions, divestments, and re-organisations be absorbed? A rigid hierarchy locks future structure; a flexible one risks no structure at all.
What's the relationship between cost centres and positions (§06 / CHRO)? If they don't reconcile, payroll allocations will never tie to operations.

Where the supporting material lives

§01 Modules (Financial Accounting), §02 Master Data & the Spine, §04 Governance & Controls, §06 Roles (CFO), §08-03 Implementation Design, §11 ADR Class 01 (structural data decisions).

Signals you're owning it well

CFO has personally walked the design pack with the COO and the sponsor. Mapping rules are evidenced against actual transactions, not theoretical ones. There is an ADR with named decision-makers, alternatives considered, and a review trigger. The board can read its own dashboard from the CoA without translation.

Signals it's drifting

The implementation partner is presenting the CoA design. Finance team are the only ones in the room. The structure is "what the system suggests." Future-state operating-model considerations weren't in the design conversation. The reporting team is being told to make the data work because the CoA was already decided.

Compounds forA decade.

Reverses withA full historical re-baselining of every reporting period.

The master data ownership model

Who owns each class. Who can change structure. What the data governance forum's remit is.

READ

The choice

For each master data class — customer, vendor, item, GL, position, asset, project, location — three decisions: who is the named accountable owner; who has authority to change structure versus authority to change records; what the data governance forum looks like, who chairs it, and what its escalation path is.

What the right answer depends on

Which data class is most contested today? The customer master in organisations where sales and finance fight; the item master where supply chain and engineering fight; the position master where HR and finance fight.
Is the master data forum sponsored at the executive level, or buried in a working group? Forums without executive sponsorship don't make decisions; they minute disagreements.
What's the post-go-live cadence? Steady-state data governance is more consequential than implementation-phase data governance, and almost always underfunded.
What integrations does the master data master serve? See §03 — every master that feeds another system inherits the discipline of integration contracts.

Where the supporting material lives

§02 Master Data & the Spine (the five classes; ownership model), §06 Roles (Data Migration & Governance Lead), §08-04 Data Migration, §08-10 Legacy Decommissioning (retention decision), §11 ADR Class 01.

Signals you're owning it well

Each data class has a named master data steward whose role description includes the accountability. The forum meets to monthly cadence with executive sponsorship. Structure changes go through ADRs. Records changes go through workflow. Integration contracts (§03) reference master data ownership explicitly. The auditor knows who to call about each class.

Signals it's drifting

"Master data is managed by the team that uses it." Multiple systems claim authority for the same class. The data governance forum doesn't have a sponsor. Records and structure changes go through the same path. Implementation phase governance assumed to continue into BAU without funding. The migration team is being asked to make policy decisions.

Compounds forEvery downstream report and every AI initiative built on the data (§12).

Reverses withAn entire governance redesign — and the political weather that comes with it.

The integration architecture

Direct vs middleware vs streaming. Which traffic goes which way. The integration platform team.

READ

The choice

Three patterns (§03): direct point-to-point, middleware/iPaaS, event-driven streaming. The decision is not which one to use — it's the policy for which traffic uses which, the standards every integration must declare, the platform team that owns the estate, and the catalogue that keeps it accountable.

What the right answer depends on

How many systems are in the estate today, and how many will be in five years? Direct point-to-point survives two-system estates; an iPaaS pays back the moment a third arrives.
What regulatory traceability is required? Some regimes (financial services, healthcare, defence) require integration traceability that direct connections can't provide.
Is real-time genuinely needed, or is "real-time" a stand-in for "we haven't designed the cadence"? Real-time is expensive; scheduled is cheap. Most cases don't need real-time.
Who owns the integration platform after the implementation partner leaves? If no enterprise team can run it, the partner becomes a permanent fixture.

Where the supporting material lives

§03 The Integration Layer (three patterns + common ERP flows catalogue), §06 Roles (Enterprise Architect), §08-03 Implementation Design, §08-07 Lifecycle Management, §11 ADR Class 02 (integration architecture decisions).

Signals you're owning it well

The enterprise architect owns the pattern policy in writing. Every integration has a data contract (§03) before build. An iPaaS or equivalent is stood up with an enterprise-side owner, not partner-owned by default. Standards are declared and enforced. The catalogue is current and reviewed quarterly. New integration requests go through a written architecture decision, not a chat.

Signals it's drifting

Each integration is its own snowflake. The implementation partner is making pattern choices on the fly. There is no integration catalogue, or it's six months out of date. "We'll standardise after go-live" is the current plan. Real-time is the default rather than the exception. The platform team is funded as infrastructure, not as a product (§08-08).

Compounds forEvery system added to the estate over the next decade.

Reverses withA multi-year re-platforming exercise of the integration estate.

The controls fabric, designed in

SoD, RBAC, delegations, audit trail. In the original design, not bolted on.

READ

The choice

Whether controls are a design input from week one — present in the role design, the workflow, the audit trail granularity, the segregation of duties matrix — or whether they are retrofitted after the system works. Same target state; an order of magnitude difference in cost, risk, and credibility with the auditor.

What the right answer depends on

Who has named accountability for the SoD matrix? If it's the implementation partner or "we'll get to it," the matrix won't exist when needed.
Is the audit trail being designed for the database admin or for the auditor? A trail nobody can query under time pressure has failed at its job.
How is RBAC being driven? By HR data through joiner-mover-leaver automation, or by individual requests after the fact?
What's the dry-run plan? Auditors should walk the controls before go-live, not discover them at year-end.

Where the supporting material lives

§04 Governance & Controls (the four disciplines), §06 Roles (Security & Risk Lead), §08-03 Implementation Design, §08-09 Audit & Assurance, §11 ADR Class 03 (controls & security decisions).

Signals you're owning it well

Risk + internal audit are in the design forum from week one. The SoD matrix is built against the role design, not after it. JML is automated through HR. The audit trail has been demonstrated to internal audit with sample queries before go-live. There is a dry-run with the external auditor in the months before cutover. Controls are written into ADRs (§11).

Signals it's drifting

Risk and audit aren't in the design forum. Controls are scheduled "for hypercare." The SoD matrix is generic, copied from another implementation. Access is granted by individual request. The audit trail logs everything but indexes nothing. The first audit will be the first real test of the controls fabric.

Compounds forEvery audit, every regulator interaction, every incident response.

Reverses withSignificant operational disruption and a controls remediation programme.

The post-go-live operating model

Who owns each module after the partner leaves. The product team. The benefits owner twelve months out.

READ

The choice

What "live" actually means after the implementation partner steps down. Specifically: the named Product Owner per module, the team that supports the platform in BAU, the release cadence, the continuous-improvement backlog, the legacy decommissioning kill date (§08-10), and the named benefit owner twelve months out who is accountable for the operating-model change.

What the right answer depends on

Who, by name, will own each module the day after hypercare ends? A role title isn't a name. A name is a name.
Is the team funded as a product or as infrastructure? Product teams have a backlog, cadence, and roadmap. Infrastructure teams have tickets.
What does the benefits register look like twelve months out, and who attests to each line? If nobody is attesting, nothing is being measured.
Is the legacy decommissioning plan in place, with a kill date and a named accountable? If the legacy stays running, the business case never closes.

Where the supporting material lives

§06 Roles (Product Owner, Sponsor, COO), §08-06 Hypercare & Stabilisation, §08-07 Lifecycle Management, §08-08 Continuous Improvement, §08-10 Legacy Decommissioning, §10 Benefits Realisation, §11 ADR Class 05 (operating-model decisions).

Signals you're owning it well

Each module has a named Product Owner before cutover. The BAU operating model is documented, funded, and staffed before hypercare ends. The benefits register has named accountables who attest quarterly. The legacy kill date is in someone's performance review. The implementation partner has a defined exit date that the operating model is ready for.

Signals it's drifting

"We'll figure out support after go-live." Product Owners are role titles, not names. The implementation partner is quietly being retained for "transitional support" with no exit date. The benefits register goes into a drawer the week after the press release. The legacy system is still running eighteen months later, with the licence renewal not even questioned.

Compounds forWhether the programme actually pays back — which is the only question that matters.

Reverses withAnother transformation in five years to fix what this one was meant to deliver.

The governing principle: the discipline of saying no

Cross-cutting

Every customisation is a future tax on every release

Every successful ERP programme is more notable for what it didn't customise than what it did. Every failed one is recognisable by the volume of bespoke work that survived “just this once.” The five decisions above all share a common shape: each one is easier to compromise on in the moment, and each compromise generates a tax that's collected at every subsequent release, every audit, every transformation conversation.

The senior leader's discipline is not just to make the five decisions well. It is to protect them through the political weather of delivery — when the implementation partner says “it would be simpler to,” when a workstream lead says “the business is asking for,” when the timeline says “we don't have time to,” when the vendor says “our standard practice is.” The structural decision is being attacked. The structural answer is to record the attempt as an ADR (§11), name the consequence, and either accept the variation deliberately or hold the line.

Compounds for: every upgrade, every patch, every audit. The cheapest decision and the most contested.