Most mid-sized companies put their best people on a system implementation, then send them back to their day jobs the week it goes live. The project plan says done. The business has barely started to find out whether the system works.
This applies to an ERP in a plant, a CRM in a sales team, a new close process in finance or a scheduling tool on the floor. The pattern after launch is the same in all of them.
What happens in the first year
Before go-live, the questions are about readiness. Is it configured, tested, trained? After go-live, the questions change:
- Are people following the process that was designed, or the one they invented?
- Where are they exporting to spreadsheets?
- Which steps do they skip because the system makes them slow?
- Is the business seeing the savings or speed the case promised?
Nobody owns those questions by default. The project team has been disbanded, the vendor has moved on, and managers are behind on everything the project pushed aside.
Workflow drift is where the value leaks
Drift rarely comes from a bad decision. It comes from small ones. A supervisor keeps a side spreadsheet because it is faster than the report. A sales rep logs calls in a notes field instead of the required fields. A payables clerk batches coding the old way because the new screen takes three extra clicks.
Each one is reasonable on its own. Six months later the data is unreliable, reports no longer match, and the process you trained is not the process people run. Fixing it then means retraining, and it means arguing with habits that have set.
It also blocks the next upgrade. New features assume the standard process. If every department has its own version, each improvement becomes a separate project.
Training is not adoption
A completed training record tells you someone sat through the session. Adoption is whether they use the system correctly on a busy Tuesday.
The employers who get this right tend to do a few plain things:
- Name a local owner in each team, someone respected who can answer questions at the desk or on the floor.
- Walk the work. Watch how people use the system for an hour rather than reading the dashboard.
- Make it easy to report friction, and answer within days so people keep reporting it.
- Measure use, not attendance: error rates, rework, time to close, data completeness.
Put governance in place before the requests pile up
Every live system collects change requests. Some fix real problems. Others solve one person's irritation and add complexity for everyone else.
A small governance group fixes this. It does not need to be heavy. A monthly 45-minute meeting with an operations lead, a finance lead, the system administrator and someone from the user side is enough to:
- Rank requests by business impact.
- Say no to one-off customizations that break the standard process.
- Keep a record of why decisions were made.
- Schedule upgrades and new features deliberately.
Done well, governance speeds things up, because people stop re-debating the same questions.
Schedule a review at 6 and 18 months
Treat go-live as the start of a review cycle. At about 6 months, check for drift and friction while habits are still soft. At about 18 months, check whether the business case is showing up in the numbers, and decide what to change.
The review should compare what you expected with what you see: fewer hours on reconciliation, faster order entry, cleaner pipeline data, less overtime in the office. If you cannot measure it, you cannot say the project succeeded.
The people question
This phase is where hiring matters most and where it is most often missed. The skills needed after launch differ from those needed to deploy.
- Operations and process roles: someone who owns the process end to end and can enforce the standard.
- Finance and systems analysts: people who can tell when reports and ledgers have stopped agreeing.
- AI and data roles: staff who can clean up what drift has damaged and build reporting you can trust.
- Contract specialists: short-term support to cover the review, retrain teams or clear a backlog without pulling your core staff off their work.
Many employers fill this gap with contract help for 6 to 12 months, then decide whether the ongoing need justifies a permanent hire. That keeps the cost proportionate to the work.
What to do next
Pick one system that went live in the last two years. Ask three users to show you how they really work in it, then compare that with the design. The gap is your list of priorities. Then decide who owns closing it, and whether you have that person on staff.
If you need an analyst, a process owner or contract capacity for the post-launch work, a Traverse recruiter can help you find them.