In brief: ERP governance defines who can decide, who owns data and processes, how change is controlled, how risk and compliance are monitored and how benefits are measured. An overhaul should begin with decision rights and accountability, not another technology project.
Many ERP problems are governance problems expressed through the system. Conflicting process requests, inconsistent master data, uncontrolled customisation, weak access controls, slow change decisions and unclear benefits ownership cannot be fixed by configuration alone.
What an ERP governance framework should control
- Strategy and value: which business outcomes the ERP must support and how investment is prioritised.
- Process ownership: who defines the standard process and approves exceptions.
- Data ownership: who is accountable for definitions, quality, access and remediation.
- Architecture and customisation: how integrations, extensions and technical debt are governed.
- Security and compliance: how roles, segregation of duties, privacy and audit evidence are maintained.
- Change and releases: how requests are evaluated, funded, tested and deployed.
- Service and performance: how incidents, adoption, benefits and system health are reviewed.
Start with the decisions the organisation cannot make
A governance overhaul should not begin by drawing committees. Begin by listing recurring decisions that are slow, disputed or made without evidence. Typical examples include:
- Whether a process exception should become a system change.
- Which entity owns a shared customer or supplier record.
- Who pays for an integration used by several functions.
- Whether a security-role change creates segregation-of-duties risk.
- How a global template should accommodate a local legal requirement.
- When an enhancement is valuable enough to enter the release plan.
For each decision, define the accountable owner, contributors, required evidence, approval threshold, escalation route and expected turnaround time.
The core governance roles
Executive sponsor or steering committee
Owns strategic alignment, major investment decisions, cross-functional conflicts and risks that cannot be resolved within the programme or service team.
Business process owners
Define the target process, approve standards and exceptions, own operational measures and confirm that system changes produce the intended business outcome.
Data owners and stewards
Own data definitions, quality rules, access, lifecycle and remediation. Stewards manage day-to-day controls; owners remain accountable for policy and outcomes.
Product or platform owner
Maintains the ERP roadmap, balances demand, coordinates releases and ensures that decisions across modules, integrations and vendors remain coherent.
Architecture and security authorities
Review solution design, integration patterns, extensions, identity, access, privacy and technical risk. Their role is to protect the whole environment rather than one project.
Change and adoption lead
Assesses role impacts, coordinates communications and learning, measures adoption and ensures that process changes are embedded after release.
A practical ERP governance operating model
1. Define principles
Agree a small set of rules that guide trade-offs. Examples include standard before custom, one owner for each critical data domain, local exceptions only where justified, evidence before investment and no release without an operational owner.
2. Establish decision rights
Use a decision-rights matrix rather than a generic responsibility chart. Specify who recommends, who provides evidence, who decides and who must be informed for each decision type.
3. Create demand and change control
Every request should state the problem, affected process, users, expected value, regulatory driver, alternatives, dependencies and acceptance measure. This prevents the backlog from becoming a list of preferences.
4. Govern design and technical debt
Require architecture review for integrations, extensions, security-impacting changes and departures from the standard product. Record the reason, owner, support model and retirement plan for every accepted exception.
5. Build data governance into operations
Define critical data elements, quality rules, owners, issue workflows and monitoring. Data quality should be reviewed as an operating measure, not only during migration.
6. Control releases
Use clear entry and exit criteria for design, build, testing, deployment and stabilisation. A release should not proceed without approved scope, completed testing, business ownership, training readiness, support handover and rollback planning.
7. Review value and service
Governance continues after go-live. Review incidents, recurring root causes, adoption, process performance, data quality, security exceptions, benefits and the roadmap on a regular cadence.
Governance for multinational and multi-entity organisations
Global and regional organisations need an explicit method for balancing standardisation with legitimate local requirements.
- Global core: common chart structures, master-data definitions, security principles, architecture and group reporting.
- Regional layer: shared operating requirements across countries or business units.
- Local exception: legal, tax, language, customer or operational needs that cannot be met by the core.
Every local exception should identify the requirement, evidence, cost, risk, owner and future maintenance responsibility. “The business wants it” is not sufficient justification.
Risk and compliance controls
- Role design and periodic access review.
- Segregation-of-duties analysis and approved mitigating controls.
- Change approval and deployment evidence.
- Configuration, interface and batch-job monitoring.
- Data-retention, privacy and sensitive-data controls.
- Financial reconciliation and close controls.
- Incident, problem and root-cause management.
- Audit evidence ownership and retention.
How governance reduces operating cost
Governance is often treated as overhead, but weak governance creates recurring cost through rework, duplicate solutions, uncontrolled vendors, manual corrections, failed releases and long decision cycles. A strong model reduces cost by:
- preventing low-value customisation;
- prioritising one roadmap across competing functions;
- resolving data and process ownership before build;
- reusing approved patterns;
- reducing production incidents and emergency change;
- making vendor performance and support obligations measurable.
A 90-day governance reset
Days 1–30: diagnose
- Inventory decision forums, owners, policies, backlogs and recurring incidents.
- Interview process, data, finance, risk, technology and operational leaders.
- Identify unresolved decisions and duplicated responsibilities.
- Baseline service, adoption, data and control measures.
Days 31–60: design
- Agree governance principles and scope.
- Define roles, decision rights, forums and escalation routes.
- Design demand, architecture, data, release and benefits processes.
- Create standard templates and evidence requirements.
Days 61–90: activate
- Run the new forums using real decisions.
- Clean and reprioritise the backlog.
- Assign owners to critical data and control gaps.
- Publish measures and review the first cycle for bottlenecks.
Measures that show governance is working
- Decision turnaround time.
- Percentage of changes with a named business owner and benefit measure.
- Number and age of unresolved data-quality issues.
- Customisation and integration technical debt.
- Release success and post-release incident rate.
- User adoption and process performance.
- Access-control exceptions and overdue remediation.
- Benefits delivered against the approved case.
Questions to answer before redesigning governance
- Which decisions require executive authority and which should be delegated?
- Who owns each end-to-end process across functions and entities?
- Who can approve a local exception to the global template?
- How will value be compared across compliance, risk, productivity and growth requests?
- Which evidence is required before a change enters delivery?
- How will governance remain fast enough for the business?
Final recommendation
Design governance around decisions and outcomes, then create only the forums needed to make those decisions well. The objective is not more approval. It is faster, traceable and better-informed ownership of the ERP as a business operating platform.
.png)
%201.avif){kind=avatar}
.png)
.png)
.webp)
