Go-live is done, acceptance testing is signed off, the project team is heading back to its home departments and the integrator is moving into “warranty” mode. Six months later, one simple question is still unanswered: who owns the ERP? Who decides to add a field, fix a configuration, or turn down a change request? Who actually knows how accounts payable is configured?
In most projects we see, the answer is “nobody, or rather everybody a little”. That is the perfect breeding ground for drift. This operational guide is for CIOs and CFOs of mid-sized companies and SMBs at the end of an ERP project: how to size, organize and govern the team that stays. It focuses on the day-to-day run (roles, headcount, support levels, rituals). For the strategic side of a center of excellence, see our guide to the ERP Center of Excellence (CoE).
A note on method: the headcount figures below are field-experience estimates, not published statistics. Adapt them to your scope, your number of users and the complexity of your processes.
Why an ERP Degrades Without an Owner
An ERP is not an asset that maintains itself. The business changes, regulations evolve, the vendor ships updates, people move on. Without a clear owner, degradation follows a fairly predictable pattern.
At 3 months: early-life defects pile up in emails and spreadsheets. Users work around the system (“I’ll note it on the side, it’s quicker”). Support goes to whoever knows the system best, usually a former project team member who no longer has the time.
At 6 months: change requests arrive through every door (executives, business units, the integrator). Nobody arbitrates, so everyone gets a bit of what they asked for, with no coherence. The first “temporary” configurations become permanent. Master data (items, business partners, charts of accounts) starts to diverge.
At 12 months: configuration knowledge lives in the heads of two or three people. A version upgrade becomes a source of anxiety. The integrator is called in for questions the company should be able to handle alone, and the time-and-materials bill grows. Adoption indicators erode, often silently, the phenomenon described in our article on the 8 KPIs that reveal silent rejection after go-live.
The cost of this drift rarely shows up in a single budget line: it is spread across lost time, rekeying, slower month-end closes and growing dependence on the service provider. That is why the run must be addressed before go-live, not after.
Three Models: In-House, Hybrid, Outsourced
There is no universal model. The right choice depends on company size, ERP criticality and your ability to hire or train internally.
| Model | Principle | Advantages | Limits | Indicative size threshold* |
|---|---|---|---|---|
| In-house | Dedicated internal team, L1 to L3 support handled internally (excluding the vendor) | Maximum business knowledge, responsiveness, long-term cost control | Hard to recruit, dependence on a few people, ongoing training needs | Mid-sized company with a broad scope and several hundred users |
| Hybrid (internal + AMS) | Steering and L1/L2 in-house; L3 and technical changes given to an integrator under contract | Good cost/skill balance, flexibility, access to scarce expertise | Requires a well-negotiated AMS contract and a strong internal counterpart | The most common case in SMBs and small mid-sized companies |
| Outsourced | Full run handed to a provider, with a minimal internal contact | No hiring, fast ramp-up | Loss of control, high recurring cost, risk of “blind” steering | Small organizations without an IT department, or a standard and stable scope |
*Thresholds are given as guidance, based on field experience rather than a quantified study.
Whatever the model, one principle cannot be delegated: functional ownership of the ERP stays inside the company. You can outsource technical L3, never the decision about what the ERP should do. For contractual details of the hybrid model, see our guide to the ERP maintenance (AMS) contract.
The Essential Roles
Five roles are enough to cover the run of an ERP. In an SMB, one person holds several of them; in a larger company, each can become a full-time position. The time estimates below are orders of magnitude in full-time equivalents (FTEs), to be validated against your context.
Process Product Owner
The company-side “owner” of the ERP. They carry the roadmap, prioritize requests, arbitrate between business units and represent the ERP on the change board. They usually come from finance, operations or IT, but need the authority (or the sponsor’s backing) to say no.
Indicative time (estimate): from 0.2 FTE in an SMB to 1 FTE in a multi-site mid-sized company.
Functional Administrator
They configure, test and document. They handle level 2 requests, manage access rights and prepare upgrade acceptance tests. They hold the “why is it configured this way”. Without them, the configuration becomes a black box.
Indicative time (estimate): 0.5 to 1 FTE in an SMB; 2 to 4 FTEs in a mid-sized company, depending on the number of modules.
Key Users per Domain
One key user per functional domain (finance, purchasing, sales, production, logistics, HR). They know both the business and the tool, answer colleagues’ questions (level 1), escalate qualified defects and test changes. Key users are named before acceptance testing, not after: they are the ones who confirm that the system fits the business, and they must take ownership of the configuration during the project.
Indicative time (estimate): 10 to 20% of their time, or 0.1 to 0.2 FTE each. This time must be written into their objectives and approved by their manager, otherwise it will vanish during peak periods.
Technical and Integrations Lead
They oversee the infrastructure or cloud tenant, interfaces (EDI, banking, e-commerce, payroll), backups, technical authorizations and the vendor relationship for updates. They are the natural counterpart of the AMS provider at level 3.
Indicative time (estimate): 0.2 to 0.5 FTE in an SMB (often carried by the IT manager); 1 to 2 FTEs in a mid-sized company.
Master Data Owner
Often forgotten, yet decisive. They run the creation, modification and cleansing of business partners, items, bills of materials and charts of accounts. They define naming and validation rules. Without them, data quality slowly decays, and trust in reports goes with it.
Indicative time (estimate): 0.2 to 0.5 FTE in an SMB; 1 FTE or more in a mid-sized company with many reference datasets.
For the roles of the project itself and how they fit together, see our guide to project team composition and the RACI matrix: the competence center is the natural continuation of that team, not a structure disconnected from it.
L1, L2, L3 Support Levels
Clear support tiers prevent every question from landing on the same expert. A simple split works well.
| Level | Who | Scope | Examples |
|---|---|---|---|
| L1 | Key users, super-users | Usage questions, data-entry help, reminders of procedures | ”How do I post a credit note?”, “Where do I find this report?” |
| L2 | Functional administrator | Configuration defects, access rights, data corrections, small changes | Missing permission, misconfigured tax rule, stuck workflow |
| L3 | Integrator / vendor (via AMS) or technical lead | Application bugs, custom development, interfaces, performance, version upgrades | Failing bank interface, custom report to fix |
Three operating rules:
- A single entry point: a ticketing tool (even a simple one), not scattered emails. Without traceability, no steering is possible.
- Qualify before escalating: L2 qualifies every ticket (defect, change request, training question) before passing it on. A change request is not a defect and must not consume the maintenance allowance.
- A written boundary with the provider: the AMS contract must specify what falls under L3, response times and escalation procedures. Avoid the grey zone between “support” and “consulting”.
Governance: Change Board and Dashboard
The Monthly Change Board
A meeting of one to one and a half hours each month, with the product owner, functional administrator, technical lead, domain representatives and, depending on the topics, the integrator. The agenda is stable: dashboard review, request backlog, arbitration decisions, update planning.
Arbitration rules to put in writing:
- every request is logged with its requester, the process concerned and the expected benefit;
- requests are prioritized on three criteria: regulatory obligation or business stoppage, measurable business gain, implementation effort;
- vendor standard comes before custom; any custom item must justify its future maintenance cost;
- disagreements between domains go up to the sponsor, who decides.
The Run Dashboard (5 Indicators)
Five indicators are enough to start. Set them yourself, with your own thresholds.
- Volume and age of open tickets, by support level.
- Resolution time by severity (blocking, major, minor).
- Share of change requests delivered in the quarter against the backlog.
- Adoption rate on key processes (for example, the share of orders entered directly in the ERP).
- Master data quality (duplicates, incomplete records).
The run budget must be separate from the project budget, with its own line: support, AMS, licenses and subscriptions, enhancements, ongoing training. Without that separation, the run lives off project leftovers and disappears at the first budget cut.
Building the Competence Center in 90 Days
The plan starts before go-live. The timeline markers below are to be adapted: D+0 is the date you decide to launch the setup, ideally three to four months before production start.
D+0 to D+15: frame. Choose the model (in-house, hybrid, outsourced), appoint the product owner, get the run budget approved by the sponsor. Inventory available skills and gaps.
D+15 to D+30: appoint. Formally name the key users and the functional administrator, with time release approved by their managers. Define the technical lead and the master data owner.
D+30 to D+60: transfer. Knowledge transfer from the integrator to the internal team must be documented: pairing sessions on configuration, an up-to-date specifications file, closing procedures, an interface map, training records. Write it into the integrator’s contract as a deliverable, not as goodwill.
D+60 to D+75: equip. Set up the ticketing tool, the L1/L2/L3 levels, and an AMS contract aligned with this scheme. First version of the dashboard.
D+75 to D+90: run in. First change board, training of the super-user network, end-to-end test of the support chain on real cases. The super-user network also acts as a change-management relay: they explain, reassure and report how the field feels.
5 Common Mistakes When Organizing the Run
Each of these mistakes is common, and its cost often shows up only several months after go-live. Each time, a simple countermeasure exists.
| Mistake | Consequence | Countermeasure |
|---|---|---|
| Disbanding the project team on go-live day | Configuration knowledge lost within months, growing dependence on the integrator | Plan a transition period of several months with named run roles |
| Naming key users after acceptance testing | Tests unrepresentative of the business; key users discover the tool instead of owning it | Appoint them during the design phase and involve them in testing |
| Absorbing the run into the project budget | The run lives off leftovers, then disappears at the first budget cut | Create a run budget line as soon as the project is approved |
| Delegating everything to the integrator, including arbitration | The ERP evolves according to the provider’s priorities, not the company’s | Keep the product owner in-house and write the L2/L3 boundary into the contract |
| Leaving key users’ time to goodwill | Availability evaporates at peak times, tickets go unhandled, no field relays | Write this time into their annual objectives, with managerial approval |
Kick-Off Checklist
- Run model chosen (in-house, hybrid, outsourced) and approved by the sponsor
- Product owner named, with arbitration authority
- Functional administrator and technical lead identified
- Key users named per domain, dedicated time approved by their managers
- Master data owner appointed
- Run budget separate from the project budget
- Integrator-to-internal knowledge transfer written into the contract, with deliverables
- Ticketing tool and L1/L2/L3 levels defined
- AMS contract aligned with the support-level split
- Monthly change board scheduled, arbitration rules written down
- 5-indicator run dashboard initialized
- Super-user network trained as a change-management relay
To take action, download our ERP project checklist and use it to frame the transition to the run. If you would like an outside view, DigitsLane offers an ERP run organization audit. To go further on governance, also read our guide to post-deployment ERP governance.
