Your ERP has been live for two years. Users have mastered the basics, but enhancement requests keep piling up without being addressed. The go-live training materials have never been updated. Excel spreadsheets are multiplying alongside the system. And every time someone leaves the company, half the functional knowledge walks out the door with them.
The question many CIOs at mid-market organisations ask themselves is: who is actually responsible for maintaining the business value of the ERP over time?
The honest answer is usually: no one in particular. Or everyone a little, which amounts to the same thing.
An ERP Center of Excellence, or CoE, is the organisational response to this problem. Not another layer of bureaucracy, but an identified team with defined missions: maintaining ERP competencies, structuring enhancement requests, tracking adoption, ensuring data quality. This guide gives you the concrete framework to build this structure, from role definitions through to your first KPIs.
What Is an ERP Center of Excellence and Why Build One?
Definition and Key Differences from a Standard ERP Helpdesk
An ERP CoE is a formalised internal structure that centralises ERP expertise, orchestrates enhancements, and ensures skills are transmitted across the organisation.
It differs from a Level 2 ERP helpdesk on three essential points.
Its scope is proactive, not merely reactive. It doesn’t wait for tickets: it anticipates training needs, identifies underused processes, and proposes improvements.
It owns the ERP functional roadmap. The CoE arbitrates enhancement priorities, negotiates releases with the vendor, and validates configuration changes before they go into production.
It maintains the competency capital. Key users, functional administrators, process owners: the CoE ensures these people exist, are trained, and capable of transferring their knowledge.
Gartner has published a reference framework on “ERP Competence Centers” that positions this structure as the pivot between IT and business units in ensuring post-deployment governance. The logic is straightforward: an ERP is a strategic asset. Without a dedicated team to preserve its value, that asset degrades over time.
3 Warning Signs That It’s Time to Build a CoE
Major upgrades keep being deferred for lack of internal resources. The next major version of your ERP has been available for 18 months, but no one has the bandwidth to test the impact or prepare the migration. The organisation is stuck on an ageing release.
Shadow IT is proliferating around the ERP. Teams have rebuilt Access databases or Excel workbooks to work around features they don’t know how to use, or that were never activated. The real risk isn’t technical: it’s the erosion of trust in the ERP as the system of record.
Initial training has never been updated. Training materials date back to go-live. New joiners learn on the job, pick up bad habits from colleagues, and use only a fraction of available functionality.
What the CoE Is Not
The CoE is not another committee. Its purpose is not to run status meetings: it produces deliverables — training materials, documented processes, dashboards, enhancement pipelines.
It is also not a ticket-triage centre. Level 1 incident resolution stays with the IT helpdesk. The CoE handles complex functional questions and enhancement decisions, not password resets.
The 3 Organisational Models for a CoE
Centralised CoE: All Expertise in a Single Central Team
All ERP competency is consolidated in a single team, typically reporting to IT. The main advantage is consistency of practice, faster skills development, and a single point of contact for the vendor and the implementation partner.
The downside is distance from the business. A central team that doesn’t understand the operational constraints of individual business units risks delivering technically sound enhancements that nobody actually adopts. This model works well in highly standardised organisations, or in groups where subsidiaries share very similar processes.
Federated CoE: BU Champions with Central Coordination
This is the best-fit model for multi-site or multi-entity mid-market organisations. A small central team (Product Owner + ERP Architect) coordinates a network of functional champions within each business unit. These champions are Business Process Owners: they represent their division in enhancement decisions and surface operational requirements.
The value of this model is twofold: consistency is ensured centrally, but business anchoring is maintained through the champions. Training stays close to operational reality. Enhancement requests reflect genuine problems, not needs that have been distorted through several layers of interpretation.
Virtual CoE: Part-Time Subject Matter Experts with Light Coordination
For organisations that don’t yet have the budget or maturity for a formal CoE, the virtual model is a reasonable entry point. A part-time central coordinator runs a network of business experts who dedicate 10 to 20% of their time to ERP topics.
This model is fragile: as soon as the experts are pulled back to their primary responsibilities, the CoE falls to the background. It should be treated as a transitional phase, not a permanent target.
Summary: Which Model for Your Organisation?
| Model | Indicative Headcount | Best Suited For |
|---|---|---|
| Centralised | 3 to 8 dedicated FTEs | Groups with 1,500+ ERP users, standardised processes |
| Federated | 1–2 central FTEs + BU champions at 20–30% | Mid-market organisations with 300–1,500 users, multi-site |
| Virtual | 0.5 FTE central | Early stages or fewer than 300 users |
Building the CoE Team: 5 Essential Roles
For a federated CoE serving 500 active users, here are the five roles to fill.
ERP Product Owner: The Bridge Between Business and System
This is the CoE’s pivotal role. The Product Owner manages the enhancement pipeline (change request backlog), arbitrates priorities with business units, and presents the functional roadmap to executive leadership. Deep ERP knowledge is essential, but the mindset must be primarily business-oriented.
Typical profile: a former senior key user or functional consultant who has been through at least one full deployment, with a natural inclination towards project governance.
Business Process Owner (BPO) by Domain
One BPO per major domain: Finance, Supply Chain, Human Resources. Responsible for process standardisation within their scope and for the alignment between how a process is defined and how the ERP is configured.
In a federated model, the BPO is typically an operational manager who allocates 20 to 30% of their time to these responsibilities. They are the adoption champion within their business unit.
ERP Architect / Technical Lead: Configuration and Integration Ownership
This role owns the technical layer of the ERP: configuration, interfaces, connectors, access management. The ERP Architect handles enhancement requests that touch configuration and integrations with third-party systems (CRM, WMS, payroll). They are the vendor’s primary counterpart for Level 3 support and version management.
Change & Training Manager: Adoption and Continuous Learning
Responsible for the training library, the key user network, and adoption tracking. This role produces materials, organises onboarding sessions for new joiners, and manages upgrade-driven training.
In budget-constrained environments, this role is often merged with a BPO or absorbed by the Product Owner — at the cost of training rigour.
Data Governance Lead: Master Data Quality and Reference Data
Data quality is the single biggest driver of distrust in an ERP. A duplicate customer, an item without a unit of measure, a supplier with no banking details on file: every anomaly reinforces the perception that “the ERP doesn’t work.”
The Data Governance Lead defines master data governance rules (business partners, items, organisational structures), monitors quality indicators, and coordinates data cleansing campaigns.
Reference ratio: field experience consistently points to 1 CoE FTE per 80 to 120 active ERP users. For 500 users, budget 4 to 6 FTEs including the BPOs’ part-time allocation.
The 6 First CoE Missions in the Launch Phase
The first six months of a CoE must produce visible results. These are the missions to prioritise.
Mission 1: Existing State Audit (Active Modules vs. Paid Licences)
Start by inventorying what is actually being used. How many modules are activated? How many users have active profiles? What percentage of the contracted scope is actually in use?
This audit frequently uncovers savings potential from unused licences, and features already available that would address requirements the business has been raising for months.
Mission 2: Customisation Map and Technical Debt Inventory
List all customisations, bespoke developments, and adaptations accumulated since go-live. Classify them: essential, replaceable, to be removed. This map is a prerequisite for any smooth major upgrade. Undocumented customisations are the primary cause of upgrade blockages.
Mission 3: Updated Training Catalogue by Role and Module
Revisit the go-live training materials and assess their obsolescence. Then build a catalogue by functional role: accountant, procurement officer, warehouse operative, planner. Each role should have a documented learning path and an onboarding module for new joiners.
Mission 4: Enhancement Request Management Process
Without a formalised process, enhancement requests arrive by email, by corridor conversation, or directly through the implementation partner. The predictable result: urgent requests from one department get prioritised over structural improvements that would benefit the whole organisation.
Formalise a simple pipeline: standardised request form, monthly prioritisation committee, progress tracking visible to all business units. This process is the clearest signal that the CoE exists and is functioning.
Mission 5: Define 5 ERP Health KPIs
The CoE must be driven by metrics, not impressions. Five KPIs are enough to start:
- Adoption rate by module: percentage of active users vs. licensed users
- Ticket volume by category: Level 1 (access, resets), Level 2 (functional), Level 3 (bug or configuration)
- Resolution SLA: percentage of tickets resolved within agreed timeframes by category
- Training coverage: percentage of users who have completed training in the past 12 months
- Data anomaly rate: percentage of business partners with incomplete records, items without units of measure, orders stuck in error
These KPIs must be generated automatically from the ERP, not compiled manually. If that’s not possible from the start, that itself tells you something about the maturity of your system.
Mission 6: First Half-Year Review with the Executive Committee
At the end of the first six months, the CoE should present an executive summary to leadership: status of the 5 KPIs, top 3 active enhancement projects, licence savings identified in the audit, training plan for the next 6 months.
This is the CoE’s first public showcase to the Executive Committee. It legitimises the function and conditions the following year’s budget.
Budget, Reporting Line, and Funding
Should the CoE Report to IT or to Executive Management?
The answer depends less on the org chart than on the sponsor who will carry the CoE politically. A CoE reporting to IT benefits from technical proximity and natural integration into IT processes (ITSM, change management). The risk is that business units perceive it as an IT tool, not a structure serving their interests.
A CoE reporting to the CEO’s office or to a Transformation Director has cross-functional authority over business units, which makes it easier to enforce process discipline and training requirements. The downside is less technical proximity with IT teams.
In practice, the most effective model places the CoE under IT with an explicit executive sponsor at CEO or CFO level, who opens governance forums and resolves cross-functional blockers.
Estimated Budget (Excluding Headcount)
For a federated CoE serving 500 active users:
- Tooling (ITSM, online learning platform, documentation base): £8,000 to £20,000 per year
- CoE team training and certifications: £5,000 to £12,000 per year
- Vendor events and technology watch: £3,000 to £6,000 per year
Total non-headcount cost typically falls between £15,000 and £38,000 per year. The dominant cost is always headcount, which represents the vast majority of the budget.
Funding Models
Centralised IT budget: the CoE is funded as an IT service. Simple to set up, but the cost is invisible to business units. They consume the service without perceiving its cost, which makes budget defence harder during spending reviews.
Business unit chargeback: the CoE is treated as a shared service. Each business unit pays a share based on user count or enhancement volume. This model makes business units accountable for their ERP usage and creates alignment between requests and actual budget.
Common Pitfalls and Success Factors
Launching the CoE too early. A CoE created three months after go-live, when processes are not yet stable, becomes a crisis management unit by default. Wait until the system is in steady state: typically 12 to 18 months after go-live and the end of the hypercare period.
Mandating the CoE without giving it real authority. A CoE that recommends but doesn’t decide is ineffective. It must have the power to accept or reject enhancement requests, to require training before granting access to a new module, to trigger a data cleansing exercise. Without that authority, it remains another advisory committee.
Neglecting continuous training. Documentation and training materials have a shelf life. Every major ERP upgrade should trigger a catalogue review. A training guide describing screens that were removed 18 months ago creates confusion, not support.
The single most critical success factor: visible executive sponsorship. At the first Executive Committee review, the CEO or CFO should introduce the CoE’s presentation. That signal communicates to every business unit that ERP governance is a strategic priority, not just another IT project. Without it, the CoE will struggle to secure time from BPOs and buy-in from operational leadership.
For more on the operational governance of your ERP, see our weekly ERP steering committee template and our 8-step change management plan. On building the initial project team, our article on key roles and the RACI matrix provides the foundations on which the CoE can build once the ERP is in production.
