There is a moment, a few weeks after an ERP goes live, that almost nobody plans for. The project is done. The implementation partner has rolled off to their next client. The internal team that lived and breathed the rollout has gone back to its day job. Everyone is relieved, and rightly so. And then a quiet question surfaces that the whole project somehow never assigned an answer to: who actually owns this thing now? More often than not, the honest answer is nobody, and that is where the trouble starts.
The mistake underneath it is treating an ERP as a product that is finished at go-live. It is not. It is a living system that reflects how your business runs, and businesses change constantly. New products, new suppliers, new rules, new people. An ERP that is not actively owned does not hold steady; it drifts away from the business it was built to serve, a little more every month, until one day it no longer matches how you actually operate.
What "no owner" looks like
The decay is rarely dramatic. It is a slow accumulation of small neglects. Master data is the first to go: without someone maintaining it, duplicate customers appear, prices go stale, product records drift, and the reports built on that data quietly become untrustworthy. Then the workarounds creep back, because nobody is guarding the process, and the disciplined way of working that the rollout established starts to erode into the old habits it replaced.
Meanwhile, change requests pile up. The business needs a new report, a tweak to a workflow, a new tax rule handled, and there is no one whose job it is to make those changes happen. So they either become expensive one-off tickets to the vendor, or they simply do not get done, and the system slowly freezes in place while the business keeps moving. New staff learn the ERP by folklore, picking up half-remembered habits from whoever sits nearest. And gradually people trust it less, and drift back to the spreadsheets it was supposed to replace. None of this is a software failure. It is an ownership failure.
Why IT and the vendor are not the answer
When you ask who owns the ERP, two comfortable answers come up, and both are wrong. The first is IT. But IT keeps the software running, the servers up, the access controlled; that is operations, not ownership. IT does not own whether the ERP still matches how the business sells, buys, and delivers. The second is the vendor or implementation partner. But the vendor bills per change and has no standing view of your daily operation. They are a supplier you call when you already know what you need, not the party responsible for noticing that the system has drifted.
Real ownership is a business responsibility. It belongs to someone inside the operation who understands both how the business works and how the ERP is meant to support it, and who has the time and the authority to keep the two aligned. For most small and mid-sized businesses this is not a full-time job. It is a named responsibility: a portion of a capable person's time, with real authority, backed by a support arrangement with the partner for the genuinely technical work. The key word is named. The failure mode is not that the owner is too junior or too busy. It is that there is no owner at all.
A worked example
A company had a textbook go-live. On time, on budget, well received. Eighteen months later the ERP was half-abandoned. Sales had drifted back onto personal spreadsheets, the finance team did not trust the reports, and the system held stale, half-maintained data. Nothing had broken. What had happened was quieter: no one had owned it. Prices had not been kept up to date, three of the people who understood the configuration had left and taken their knowledge with them, and a backlog of unactioned change requests had convinced everyone that the system just could not do what they needed.
We did not re-implement anything. We established an ownership model: a named internal owner given real time and authority, plus a light support arrangement with us for the harder changes. We cleaned the master data once, properly, and worked through the backlog of changes that had been quietly telling people the system was stuck. Within a couple of months, the ERP was trusted again and back at the centre of the operation. The software had been capable the whole time. It had simply been left with no one to keep it alive.
Decide who owns it before you switch it on
The organisations that get lasting value from an ERP are not the ones with the biggest budgets or the fanciest configuration. They are the ones who treat go-live as a beginning rather than an ending, and who name an owner for the system before it goes live, not after it starts to decay. That owner treats the ERP as a living product with a roadmap: master data kept clean, changes triaged and made, people trained, configuration evolved as the business evolves.
If your ERP is live but slowly drifting, or you are about to go live and have not yet decided who will own it afterwards, that is the gap most worth closing, because it is the difference between a system that keeps paying back and one that quietly fades. Our team provides exactly this kind of ongoing IT management and support, acting as, or working alongside, the owner who keeps your ERP aligned with your business long after go-live. Book a discovery call and we will help you set the ownership up properly.
Frequently asked questions
Who should own an ERP after implementation?
A named internal owner, usually a capable operations person given the time and authority to run the system, supported by the implementation partner for the harder changes. This owner is responsible for master data quality, change requests, training new staff, and keeping the configuration aligned with how the business actually works. It is a mistake to assume IT or the vendor owns it: IT keeps the software running and the vendor bills per change, but neither owns whether the ERP still fits the business.
What happens if no one owns the ERP?
It quietly decays. Master data drifts as duplicates and stale values pile up, workarounds creep back because nobody is guarding the process, and change requests go unactioned so the system freezes while the business moves on. New staff learn it by folklore, trust erodes, and people drift back to spreadsheets. The software is usually fine; what failed is that nobody was responsible for keeping it aligned with the business, so it slowly stopped reflecting reality.
Is ERP ownership a full-time job?
For most small and mid-sized businesses, no. It is a named responsibility rather than a full-time role: a portion of a capable person's time, with clear authority, plus a support arrangement with the partner for the more technical changes. What matters is that the responsibility is explicitly owned by someone, not left to the vague assumption that IT or the vendor will handle it. The size of the role scales with the complexity of the ERP and the pace of change in the business.
What does an ERP owner actually do?
They keep the master data clean, triage and prioritise change requests, decide what is handled internally versus sent to the partner, train new starters, and steward the configuration so it evolves as the business changes rather than drifting out of date. In effect they treat the ERP as a living product with a roadmap, not a project that finished at go-live. That ongoing ownership is what keeps the system trusted and useful long after the implementation team has gone.