Who takes care of evolving the ERP after go-live?

After go-live the system needs three named roles: a business owner per core process who decides what may change, technical support for updates and extensions, and a small body that prioritises change requests. Without those three, evolution falls back on IT, which cannot decide on business questions, and the system stays at the state it had at go-live.

What happens to customisations during updates: customisations and cloud updates

Why a system should grow with you: Never starting over

Why the time after go-live decides

Go-live is the moment the system starts to live. Users discover workflows nobody considered during testing, the business changes, new requirements arise. An ERP that absorbs this movement stays useful. One that freezes becomes, over the years, the old system that was just replaced.

In practice the project organisation ends after go-live and nothing takes its place. The project manager returns to the line, the external consultants leave, and change requests land as tickets with IT. There they are assessed technically, but nobody decides on the business question.

The consequence is a familiar pattern: changes take a long time, business areas build workarounds beside the system, and after three years part of the company works in spreadsheets again. That is not a software problem but a gap in the operating model.

The three roles that must be filled

The first role is the business owner per core process. This person decides whether a requested change serves the process, and carries responsibility for the master data in their area. Without them, every change becomes a negotiation between departments.

The second role is technical support. It installs updates, tests, maintains extensions and keeps contact with the partner. That can be staffed internally or bought in. What matters is that there is a named responsibility and not a collective role alongside other duties.

The third role is a small body that meets every four to six weeks and prioritises change requests. It does not need a large group: the business owners, technical support and one person who decides in case of doubt. This body is the continuation of the steering committee in miniature.

How much capacity is realistic

A sound rule of thumb from practice: plan a budget for ongoing evolution in the order of a small single-digit percentage of the implementation cost per year. That covers updates, smaller extensions and adaptation to changed requirements.

On the internal side the business owners do not need much time, but they need reliable time. Half a day a month per core process is enough in quiet phases, provided it actually happens. Technical support depends on the number of extensions and interfaces.

More important than the exact figure is that this budget exists and does not have to be applied for each time. Where every small item needs an application, maintenance is skipped and the backlog grows quietly.

How to tell that aftercare is missing

There are three reliable signs. The first are new spreadsheets beside the system. When business areas start keeping data outside, the system has stopped reflecting their work and nobody has changed it.

The second sign is a growing list of open change requests without prioritisation. A long list is not a problem, an unsorted one is, because it means nobody decides.

The third sign is the sentence that the system cannot do that. In most cases it can, but nobody has set it up. When that sentence comes up more often, what is missing is not functionality but responsibility.