After go-live: managing change requests and upgrades
The previous lesson connected your ERP to the rest of your tools so the business works as one system. Once all of that settles, a phase begins that nobody discusses before you buy: change requests. Sales wants a new field on the order, accounting wants a report laid out differently, and the vendor announces a new release. These requests never stop, and a business with no method for handling them ends up with a system full of modifications nobody can explain. This lesson is about managing change after go-live.
Why change needs managing
Every modification you add stays with you for years: it has to be explained to each new employee, retested with every upgrade, and it may collide with a later modification. One change looks trivial; twenty accumulated changes with no rules produce a fragile system everyone is afraid to touch. The goal is not to refuse change, but to make every request pass through a single door that examines it before it gets in.
Three kinds of requests
Before deciding, classify the request. Most of what reaches you falls into one of three buckets:
| Type | Example | Right response |
|---|---|---|
| Training, not a change | Someone says the system has no such report, but it already does | Explain and train; change nothing |
| A process problem | An approval step stalls work because its owner travels often | Fix the process first, then reflect it in the system |
| A genuine system change | A new mandatory field the work or a regulation requires | Put it through the formal request path |
This classification alone saves more than you expect, because a large share of "change requests" are not changes at all: they are training questions, or broken internal processes that need fixing before anyone touches the software.
A concrete example
A small contracting company stabilised its system six months after go-live. Over the next two months, eight change requests arrived. Instead of acting on each one immediately, the operations manager collected them in a single list and reviewed them once, in a short meeting. The outcome: three were misunderstandings, resolved by a half-hour training session; two came from a broken internal procedure, so they fixed the procedure and left the system alone; one was a duplicate of another; and two were real, which the vendor delivered together in a single batch. Instead of eight scattered modifications, they ended with two considered changes and a written record of why each was made.
A simple path for handling requests
- One intake point: a single place where everyone logs requests. A request whispered in the corridor does not exist.
- Describe the problem, not the solution: ask the requester what is blocking them, not what modification they imagine. Many problems have a lighter fix than the one proposed.
- Review on a cycle, not on arrival: a short meeting every two weeks that goes through the accumulated requests together. Acting instantly on each request is what creates the mess.
- Test before you roll out: apply the change in a test environment if you have one, or to a limited group, before it reaches everyone.
- Record the reason for every change: one line is enough — what changed, who asked, why, and when it went live. A year later that line will be the most valuable thing you have.
Vendor upgrades are a separate matter
Alongside your internal requests, your vendor releases periodic upgrades. Do not treat them as technical detail that does not concern you: an upgrade can change a screen your team uses daily, or affect a customisation you asked for earlier. Ask the vendor before each one: what changes on the screens we actually use? Is any custom modification of ours affected? When will it run and how much downtime, if any? And what is the plan if something breaks afterwards? Then pick a date away from a business peak or a regulatory deadline such as a VAT return.
A checklist before approving any change
- Is the problem real, or does it just need training?
- Could a process change solve it instead of a system change?
- How many people benefit, and how often does it occur?
- What is the impact on reports, permissions, and existing integrations?
- Who tests it before the rest of the team sees it, and who documents it?