ERP Governance: Defining Responsibility After Go-Live

2026-09-24

Executive Summary

• ERP does not run itself after go-live — it requires defined roles, processes, and decision rights to maintain quality and value over time.
• Many organizations have detailed implementation plans but no governance plan for what comes after.
• The result: data quality deteriorates, problems go unresolved, and the system gradually becomes something no one wants to own.
• Governance does not need to be complex — but it does need to be explicit about roles, processes, and decisions.

Introduction

→ Explore ERP Readiness Solutions

For broader context on user adoption and its impact on governance, see: ERP User Adoption — Why People Determine Whether ERP Succeeds

For the post-go-live phase, see: ERP Implementation vs. Adoption — Why Go-Live Is Just the Beginning

For the foundational perspective, see: Why ERP Projects Fail

ERP Does Not Run Itself

There is a common implicit assumption in many ERP projects: once the system has gone live and the implementation partner has left, ERP will sustain its own value.

That assumption is wrong.

ERP is a living system — it reflects the organization as it operates. When the organization changes — new products, modified processes, new staff, restructuring — the system needs to be updated accordingly. When data is not maintained correctly, data quality deteriorates over time. When problems arise and no one is accountable for resolving them, they accumulate.

Nothing naturally prevents these things from happening — except governance.

Governance, in the ERP context, is the structure of roles, processes, and decision rights that keeps the system accurately reflecting operational reality after go-live.

Warning Signs of a Governance Gap

These signals typically appear between six and eighteen months after go-live — once the energy of a new project has faded and no structure has replaced it.

Master data quality deteriorates progressively. New products are created outside standard naming conventions, duplicate vendor records accumulate, customer information goes stale. No one is assigned responsibility for maintaining master data quality — and there is no clear process for adding, modifying, or retiring records.

Problems are reported but not resolved systematically. A user encounters an error or an inefficiency, reports it to their manager, the manager escalates to IT, IT lacks the authority or knowledge to resolve it, the issue drifts. No ticket system, no SLA, no accountable final owner.

Change requests are not managed. When operations change and ERP configuration needs to be updated, it is unclear who decides, who implements, and who validates. Some changes are made directly without documentation — and no one knows what state the system is in relative to its original configuration.

User access is not controlled. New employees are granted permissions based on their manager’s verbal request without a defined framework. Employees who leave do not have their accounts deactivated promptly. No one periodically reviews who has access to what in the system.

No one knows how well the system is actually working. There is no regular reporting on data quality, system utilization, or outstanding issues. Leadership has no reliable way to assess whether ERP is serving the business effectively — unless something goes visibly wrong.

Key Roles After Go-Live

Governance does not mean creating a new department. In an SME, the roles below can typically be assigned to existing people — what matters is that they are explicitly defined, not assumed.

ERP System Owner

The person with ultimate business-side responsibility for the ERP system. This does not need to be a technical role — in fact, the ideal System Owner is someone who understands the business deeply and has sufficient authority to make decisions about the system.

Responsibilities:

• Make decisions on significant configuration changes.
• Approve requests for new features or customizations.
• Accountable to leadership for system effectiveness.
• Ensure governance processes are followed.

Master Data Manager

The person responsible for the quality and consistency of foundational data in the system — product catalog, vendor list, customer records, chart of accounts.

In a smaller organization, this role can be assigned to someone in IT or operations who has sufficient business knowledge. The important thing is that there is a specific named person — not “everyone is responsible,” which in practice means no one is.

Key Users / Super Users

Each major department should have at least one Key User — someone who understands the system more deeply than average, serves as the internal first point of contact when colleagues encounter problems, and channels user change requests up to the ERP System Owner.

Key Users do not replace IT support, but they significantly reduce the burden on IT and accelerate resolution of everyday issues.

IT / System Administrator

Responsible for the technical layer: infrastructure, backups, security, user account management, and implementing configuration changes approved by the System Owner. For cloud-hosted ERP, this role may be lighter — but there still needs to be a clearly designated person.

A Lightweight Governance Model for SMEs

Governance is not bureaucracy. For an SME, a practical governance structure can be built around five elements:

Change Management Process. Any request to modify the system — new feature, configuration change, new report — goes through a defined path: who requests it, who assesses the impact, who approves it, who implements it, who validates the result. Not a complex process — but a consistent one. Not “whoever wants to make a change just does it.”

Master Data Governance. Clear rules for creating, modifying, and retiring master data records. Who can request a change, who approves, who executes. A periodic quality review — quarterly, for example — to clean up outdated or duplicate records before they accumulate.

User Access Management. A defined process for granting access to new employees (based on role, not individual requests) and revoking access when employees leave. An annual review of who has what access in the system.

Periodic Health Check. At minimum quarterly, the ERP System Owner reviews: is data being maintained correctly, what are the outstanding issues, at what level is the system actually being used, and are there operational changes that need to be reflected in ERP configuration?

Clear Escalation Path. When a user encounters a problem, they know who to contact, through which channel, and what response time to expect. Not “ask your manager, who asks IT, who asks the implementation partner, who asks back for more information.”

Governance Starts Before Go-Live

One of the most common mistakes: treating governance as something to establish after go-live.

The reality: governance needs to be planned — and partially established — before go-live. At minimum, defining who will be the System Owner, who will be the Master Data Manager, and what the Change Request process will be.

The reason: from the first weeks after go-live, decisions about the system will be made — with or without governance. Without governance, those decisions are made ad hoc, inconsistently, and usually without documentation. Undoing those decisions later is costly and disruptive.

Self-Assessment

• Is there a clearly designated ERP System Owner — someone with decision-making authority over the system who is accountable to leadership?
• Is there a specific named person responsible for master data quality?
• When users encounter a problem with ERP, do they know who to contact and how?
• Is there a defined process for handling configuration change requests?
• When an employee leaves the organization, how and how quickly is their ERP access revoked?
• When was the last time anyone reviewed the quality of data in the ERP system?

If several answers are “unclear” or “we haven’t established that” — those are governance gaps that need to be filled, regardless of how long ago go-live was.

Next in the series: After ERP — How to Actually Use the Data You Now Have

→ Complete the ERP Readiness Assessment

This article is part of a series on ERP readiness for manufacturing SMEs.

Related articles:

• Why ERP Projects Fail — and What the Software Cannot Fix
• ERP Customization: The Line Between Flexibility and Technical Debt
• After ERP: How to Actually Use the Data You Now Have