- Home
- Capabilities
- Adoption, Support & Scale
Adoption, Change Management & Scale
The part that decides whether any of the rest was worth doing. Go-live is the midpoint of a project, not the end of it.
Why do manufacturing systems fail after go-live?
Because adoption was treated as training rather than as design.
A system that adds time to an operator’s cycle, or asks a supervisor to enter something already written on a board, will be worked around however good the training was. Adoption is decided months earlier, in the design. That is why we treat change management in manufacturing as part of the engineering, not as communication added at the end.
Nobody rejects a system out loud
Rejection looks like the whiteboard staying up next to the terminal. The system is live, the dashboard is green, and the data means nothing. These are the signs we watch for.
The parallel record survives
If the whiteboard, diary or spreadsheet is still being kept a month after go-live, the system has not replaced it. It has been added on top.
Entries cluster at shift end
Events entered in a batch just before handover were not captured as they happened. The timestamps are fiction, and every calculation built on them inherits it.
One reason code dominates
When “Other” or the first item in the list accounts for most stoppages, the list is wrong, the moment of entry is wrong, or both.
What we do to make it stick
Adoption designed in
Entry points are chosen so that capture happens at the moment of the event, in the flow of work. This is a design decision, made before anything is built.
Training on the line
On the real system, in the language people work in. Supervisors first, because they decide whether their shift uses it.
Daily management redesign
The morning meeting changes or the system becomes a parallel activity. We rebuild the routine around what the system shows and remove the reporting it makes redundant.
Benefit tracking
Baselines captured before go-live and measured after, against the numbers in the business case, including an honest report when a benefit did not land.
Managed support and enhancement
Ongoing support and a route for the changes that always follow first use, because the best requests arrive after people start running it.
Multi-site rollout
A playbook built from the first plant: what to standardise, what must stay local and how to avoid rebuilding at every site.
Getting past the first plant
This is where most programmes stop, in what the World Economic Forum calls pilot purgatory. The pilot works, the case is proven, and the second site still takes as long as the first because nothing was built to be repeated.
Standardise
Master data, reason-code lists, integration patterns, the configured baseline and the training package that a local team can run themselves.
Keep local
Shift patterns, routings and approval chains, within a defined list of what each site is allowed to change. Without that list, standards erode by the third site.
Common questions
How long do you stay after go-live?
Through at least one full business cycle: a month-end, an audit and a shutdown, because those are when systems reveal what they cannot do. After that, support is an explicit agreement rather than an assumption, and we would rather you needed less of it over time.
What if adoption is failing?
Usage data tells us early: entries batching, fields left blank, one reason code dominating. The fix is usually a design change rather than more training, and it is our job to make it.
Can you support a system we did not build?
Often, yes, and it is a common way we start. We assess what exists and whether it is worth continuing before committing to support it. Occasionally the honest recommendation is that it is not.
Start with the audit, not the software.
A fixed-scope diagnosis of where your plant loses information, what it costs you and what to fix first. The roadmap is yours to keep, whoever builds it.