Your ERP is live. The project was delivered on time (or almost), users have been trained, and the integrator has handed over the keys. What now? For the majority of organizations, this is precisely when troubles begin.
According to feedback from ERP integrators and field studies, most organizations lack a formal governance process after go-live. The result is predictable: Excel workarounds reappear, secondary modules are progressively abandoned, enhancement requests pile up without prioritization, and the system gradually loses its value proposition.
This guide, structured around six pillars, gives you concrete tools to avoid this erosion and make your ERP an asset that improves over time.
The “go-live and forget” syndrome: why so many ERPs underperform after two years
Warning signs of a drifting ERP
A drifting ERP doesn’t collapse overnight. It degrades progressively, and the signals are often minimized by teams:
- Parallel Excel exports: users extract ERP data to rework it in spreadsheets, indicating the system no longer meets their analysis or reporting needs.
- Business workarounds: processes bypass the ERP (paper purchase orders, email approvals instead of integrated workflows, manual entries in third-party tools).
- Abandoned modules: the CRM or purchasing module, though deployed, is no longer used due to lack of maintenance or training.
- Inconsistent data: customer records are duplicated, displayed stock doesn’t match reality, account reconciliations require manual corrections.
- Constantly rising support tickets: indicating users lack proper reflexes or the system hasn’t evolved with business needs.
These symptoms, taken individually, seem minor. Accumulated over 18 to 24 months, they represent a significant loss of system value.
The classic mistake: dissolving the project team on go-live day
In many organizations, the ERP project team is dismantled as soon as the system is in production. Key users return 100% to their operational roles, the project manager is assigned to another program, and the integrator intervenes only on ad-hoc support tickets.
This is a structural error. The ERP then enters a minimal maintenance phase, without evolution vision or capacity to absorb new business requirements. Unprocessed improvement requests accumulate and generate frustration among users, who end up circumventing the system.
The solution: transform the project team into a permanent governance structure. This is the role of the ERP center of excellence.
Pillar 1: Creating an ERP Center of Excellence (CoE)
Typical CoE composition
The ERP center of excellence isn’t a new department. It’s a cross-functional, lightweight structure that brings together key competencies to drive system evolution:
- Executive sponsor (CFO, CEO, or CIO): carries strategic vision, arbitrates investments, and ensures COMEX connection. Without top-level sponsorship, the CoE lacks decision-making power.
- CoE manager (often the former ERP project manager): coordinates activities, manages the evolution backlog, facilitates steering committees.
- Business key users (2 to 5 depending on company size): representatives from finance, purchasing, supply chain, production. They dedicate 10 to 20% of their time to the CoE, the rest to their operational role.
- IT lead / ERP administrator: manages technical aspects (configurations, interfaces, version upgrades, access rights).
- Integrator / TMA: external partner handling specific developments and major version upgrades, framed by an application maintenance contract.
For a mid-sized company of 200 to 500 employees, the CoE typically mobilizes the equivalent of 1.5 to 2 FTEs (full-time equivalents) distributed across 5 to 8 people.
Roles and responsibilities: who arbitrates enhancement requests?
The CoE operates with a quarterly steering committee and monthly operational committee:
- Quarterly steering committee (sponsor + CoE manager + CIO): validates ERP roadmap, arbitrates investments, aligns ERP with business strategy.
- Monthly operational committee (CoE manager + key users + IT lead): prioritizes evolution backlog, addresses recurring incidents, tracks performance KPIs.
Fundamental rule: all enhancement requests go through the CoE. No “rogue” development requested directly from the integrator by a business director. This point is critical to avoid over-customization, as each customization has a recurring maintenance cost (regression testing with each version upgrade, documentation maintenance, specific skills retention).
Pillar 2: Defining ERP performance KPIs
An ERP without monitoring indicators is like piloting a plane without a dashboard. The CoE must implement KPIs covering two dimensions: technical and business.
Technical KPIs
| Indicator | Recommended target | Measurement frequency |
|---|---|---|
| System availability | > 99.5% | Monthly |
| Average response time (critical transactions) | < 3 seconds | Weekly |
| Application error rate | < 0.5% of transactions | Monthly |
| Number of open support tickets | Downward trend | Monthly |
| Average incident resolution time | < 4 hours (critical), < 2 days (standard) | Monthly |
Business KPIs
Business KPIs are the most important as they measure the real value delivered by the ERP to users:
| Indicator | Concrete example | Target |
|---|---|---|
| Adoption rate | % active users / licensed users | > 85% |
| Monthly accounting closure time | Improved from 12 days to 5 days thanks to ERP | Continuous improvement |
| Automated order rate | Orders placed via ERP workflow vs manual orders | > 90% |
| Single-entry rate | Data entered once vs manual re-entries | > 95% |
| Inventory accuracy | Gap between ERP stock and physical stock | < 2% |
| Supplier invoice processing time | From receipt to payment | Reducing |
ERP dashboard: frequency and audience
The CoE produces a synthetic dashboard, distributed to three audiences:
- COMEX / management (quarterly): 5 key indicators, focus on ROI and strategic alignment. To concretely measure your ERP return on investment, check our dedicated ERP ROI guide.
- Key users and business managers (monthly): detailed business KPIs by module, trends, corrective actions.
- IT team (weekly): technical KPIs, open incidents, TMA workload.
Pillar 3: Managing the evolution backlog
Prioritization process (business impact x effort x urgency)
Not all enhancement requests are equal. The CoE applies a simple prioritization matrix:
- Business impact (1 to 5): how many users are affected? What productivity or reliability gain is expected?
- Implementation effort (1 to 5): how many integrator or administrator days? Specific development needed or simple configuration?
- Urgency (1 to 3): regulatory constraint, operational blocking, or comfort improvement?
Score = Impact x Urgency / Effort gives an objective priority order. High-impact, low-effort requests come first. Heavy customizations with low impact are systematically challenged: can a business process adapt to the ERP standard rather than the reverse?
It’s essential to distinguish three types of maintenance:
- Corrective: bugs, malfunctions, anomalies. Immediate treatment.
- Evolutionary: new features, improvements. Prioritized by the CoE.
- Regulatory: compliance updates (electronic invoicing 2026, CSRD, tax changes). Mandatory, to anticipate in the roadmap.
Release cadence: delivering enhancements every quarter
One classic trap is accumulating requests for 12 to 18 months, then delivering them in a “big bang” that destabilizes users. The CoE must impose a quarterly delivery rhythm:
- Scoping sprint (2 weeks): specification of selected enhancements with key users.
- Development and configuration (4 to 6 weeks): implementation by integrator or internal IT team.
- Business acceptance (2 weeks): testing by key users in pre-production environment.
- Deployment (1 week): production release, user communication, documentation update.
This quarterly rhythm allows regular value delivery, maintains key user engagement, and avoids accumulating unmanageable functional debt.
Pillar 4: Continuous training and new hire onboarding
Annual training plan and living documentation
Initial training at go-live isn’t enough. Processes evolve, new features are deployed each quarter, and users forget procedures they don’t use daily.
The CoE implements a structured annual training plan:
- Quarterly refresh sessions (1 to 2 hours): aligned with releases, covering new features and identified best practices.
- Semi-annual key user workshops (half-day): advanced feature deep-dive, inter-service best practice sharing.
- Living documentation: user guides updated with each release, accessible directly in the ERP (contextual help) or on an internal wiki.
Organizations dedicating 15 to 20% of their post-deployment budget to training and support achieve the best adoption results (Avero Advisors, Guide to ERP Post-Implementation Success). For a complete training methodology, check our ERP user training guide.
Integrating ERP into HR onboarding for new hires
An often overlooked point: new employees arrive with zero ERP knowledge. If onboarding doesn’t include dedicated training, they learn “on the job” with their colleagues’ bad habits.
The CoE works with HR to integrate an ERP module into the integration path:
- D+1 to D+5: access creation, general IS presentation and ERP role.
- D+5 to D+15: targeted training on modules used by the new employee, supervised by their department’s key user.
- D+30: follow-up with key user to identify blockers and consolidate learning.
Pillar 5: Managing version upgrades and patches
Patching policy (security vs functional)
ERP vendors regularly publish updates: security patches, functional fixes, new features. The CoE defines a clear policy:
- Security patches: applied within 30 days maximum after vendor publication. No exceptions.
- Functional fixes: evaluation by IT lead, grouped application in quarterly release unless bug is blocking.
- Major version upgrades: planning 6 to 12 months ahead, with dedicated project including regression testing, data migration, and specific development re-certification.
The TMA contract must explicitly cover these three levels. A well-negotiated contract includes annual person-days for evolutions (often 30 to 60 days depending on scope size), SLA for critical incidents, and version upgrade commitment.
Test and regression environments
No modification should be deployed to production without validation in pre-production environment (often called “acceptance” or “staging”). The CoE maintains at minimum two environments:
- Development/test environment: for configurations, developments, and unit testing.
- Acceptance environment: production mirror, used by key users to validate enhancements before deployment.
Regression testing is critical: each modification, even minor, can have side effects on other modules. The CoE maintains a reference test suite covering critical business processes (end-to-end customer order, purchase-invoice-payment cycle, monthly closure).
Pillar 6: Annual audit and strategic alignment
Annual ERP/IS review with management
Once a year, the CoE organizes a strategic review with general management. The objective: verify the ERP remains aligned with business strategy and identify necessary investments for the next 12 to 24 months.
Typical agenda:
- Past year assessment: key KPIs, delivered enhancements, major incidents, user satisfaction.
- TCO analysis (total cost of ownership): licenses, TMA, infrastructure, training. Is TCO in line with initial business case projections?
- N+1 roadmap: major evolution projects (new module, integration with new SaaS, business process redesign).
- Benchmark: is the current system still competitive compared to market alternatives? Are there warning signals (announced end of support by vendor, obsolete technology)?
- Budget: envelope for evolutions, TMA, and training for the following year.
Anticipating regulatory changes
The European regulatory framework imposes regular adaptations to information systems, and ERP is on the front line:
- Electronic invoicing: EU countries are progressively imposing electronic invoicing between 2026 and 2027 based on company size. ERP must be compatible with regulatory formats (Factur-X, UBL) and dematerialization platforms.
- CSRD (Corporate Sustainability Reporting Directive): extra-financial reporting obligations progressively extend to mid-sized companies. ERP can be a key data source (energy consumption, emissions, waste).
- Tax and social changes: VAT rates, social scales, collective agreements. The vendor or integrator must provide regulatory updates within deadlines.
The CoE integrates these regulatory milestones into its annual roadmap, in coordination with finance and legal departments.
Implementing your governance: where to start?
If your ERP is already in production and you lack a governance structure, it’s not too late. Here’s a 90-day action plan:
- Month 1: appoint a CoE manager, identify volunteer key users, conduct rapid diagnosis (which modules are actually used? what workarounds exist?).
- Month 2: implement priority KPIs (adoption rate, support tickets, availability), build pending evolution backlog, frame TMA contract.
- Month 3: organize first steering committee, validate next quarter’s roadmap, launch first evolution release.
ERP governance isn’t a luxury reserved for large groups. It’s the condition for your investment to continue producing value. A well-governed ERP is an ERP that evolves with your business. An ERP left to itself becomes a constraint.
To establish foundations upstream of deployment, check our ERP change management guide. And to concretely measure what your ERP brings you, our article on ERP project ROI gives you the methodology.
Download our ERP evaluation grid to structure your own governance dashboard with 30 criteria on 100 points.
