When a business decides to replace or modernise its operations software, there's almost always a moment where someone says: "While we're at it, let's fix the process too."
It is a reasonable impulse. The old system is being rebuilt anyway, and the team is already going through a change. That can make it feel like the right moment to clean up the inefficiencies that everyone knows exist.
The answer is that process optimisation and software implementation are two different projects, and doing them simultaneously often causes both to fail. Understanding why requires looking at what adoption actually depends on and what threatens it.
What adoption depends on
When a new system is introduced, the people who have to use it are making an implicit calculation. Is this easier than what I was doing before? Does it fit the way I already work? Can I do my job without thinking too hard about the tool?
If the answer is yes, adoption tends to be straightforward. People switch because the new system is genuinely better for them in their day-to-day work. If the answer is no, the new system asks them to think differently, sequence things differently, or describe their work in a new way. Every interaction with the system then creates friction, and friction at scale produces workarounds.
The critical variable here is familiarity. A system that mirrors how people already work requires almost no relearning. A system that changes the workflow requires two things to happen simultaneously: learn the new tool, and learn the new process. That's a larger cognitive burden than most rollouts account for.
Where optimisation goes wrong
Optimisation, in this context, usually means asking people to change the sequence of steps they follow, capture information they weren't capturing before, or describe work at a different level of detail. These are all legitimate improvements on paper. The problem is that they all require relearning.
When a team encounters a new system that also represents a changed workflow, the natural response is to try the system once or twice, find it harder than expected, and retreat to the old way of doing things, or to the minimum viable input that keeps management off their backs. The result is partial adoption, where people are technically using the system but without producing the data quality the system was meant to deliver.
Partial adoption produces incomplete data. Incomplete data produces unreliable reports. The system gets blamed for delivering poor insight, when the actual problem was that it was introduced with too much change at once.
The right sequencing
The principle we follow when building operations platforms is this: the first version of the system mirrors the existing workflow exactly. If the team currently captures five fields, the new system captures five fields in the same order. If they currently follow a three-step process, the new system supports that three-step process.
The goal of the first version is adoption first, with optimisation later. A used system with an imperfect workflow is more valuable than an optimised system with partial adoption because a used system produces complete data, and complete data is the foundation for everything else.
Once the system is embedded and adoption is high, the conditions for optimisation are much better. The team trusts the tool. They've learned it. Changes to the process become small adjustments to something familiar, and because the data is now reliable, you can actually measure whether an optimisation is working.
"Optimise the process after adoption is established. The sequence matters more than the intent."
When to optimise anyway
There are situations where process change during implementation is unavoidable. If the existing workflow is so broken that it can't be digitised as-is, some redesign is necessary before building. If the system is replacing a paper-based process with no digital equivalent, there's no existing workflow to mirror, so the first version is necessarily new.
In these cases, the principle shifts: make the change as small as possible, focus on removing friction rather than adding complexity, and involve the people who will use the system in defining what the new workflow looks like. Ownership of the change dramatically increases the likelihood of adoption.
The decision about whether to optimise now or later is one we make collaboratively with each client. Sometimes the right answer is to optimise a specific step because the current approach is genuinely unworkable. That is a deliberate, scoped decision made with awareness of the adoption risk.
The measure of a good implementation
The question to ask six weeks after a new system goes live is whether people are using the system fully, consistently, and without being reminded.
If the answer is yes, the implementation succeeded, regardless of whether every inefficiency was addressed on day one. The system is producing data. The data is reliable. The foundation is in place to improve from here.
If the answer is no, adoption is partial, people are routing around the system, or the reports still don't reflect reality. In that case, the implementation has a problem that no amount of additional features will fix. The system doesn't fit the team, and the most likely reason is that too much changed at once.
Getting this sequencing right is one of the things that separates a software rollout that sticks from one that quietly reverts to spreadsheets within three months. It's a distinction we take seriously in every project we build.
For a real example of a project where the workflow had to be preserved first, the legacy modernisation case study shows how the right sequencing reduces risk.
Related reading