Walk through most operations, such as a manufacturing floor, a facilities team, or a logistics office, and you'll find the same pattern underneath the official software: a spreadsheet that someone built six months ago to track what the system can't, a WhatsApp group where field staff report job status, and a printed form that gets filled out and then re-entered somewhere else at the end of the day.
These are workarounds. And the instinct, when you spot them, is usually to treat them as a discipline problem. People aren't using the system properly. Someone needs to enforce the process. The training wasn't good enough.
That instinct is understandable, but it is wrong. The cost of being wrong about this is higher than most managers realise.
Workarounds reveal a mismatch
When a team builds a workaround, they're solving a real problem. The system asked them to do something in a way that didn't fit the job, so they found a different path. The workaround shows a mismatch between the software and the workflow.
This matters because the standard response to workarounds, such as more training, stricter enforcement, or reminders to use the system properly, fails to address the actual problem. The system still fails to fit, so the friction remains and the workarounds continue or go underground.
The more useful question is: what is the system failing to do that the workaround is filling in?
What workarounds actually look like on the ground
They tend to show up in a few consistent forms. A field technician finishes a job and fills out a short, vague note in the system because the form is too slow or too detailed to complete between jobs, and then verbally debriefs to a manager later. A back-office coordinator keeps a personal spreadsheet with the "real" status of open jobs because the system's dashboard doesn't update quickly enough to trust. A manager exports data every Monday morning into a spreadsheet to produce a report that the software can't generate directly.
None of these people are trying to create problems. They're trying to get their work done. The workaround is the rational response to a system that fails to fit the job.
The real cost: incomplete data, unreliable decisions
Here's where the business impact becomes concrete. Every workaround is a leak in the data pipeline. The information that lives in a personal spreadsheet, in a WhatsApp message, or in someone's memory stays outside the system, so it is never captured, aggregated, or reported.
Which means that when management looks at the reports, they're looking at partial information. The system shows what people entered into it. It doesn't show what people routed around it.
Decisions made on incomplete data aren't necessarily wrong, but they're made with less confidence than they should be. A manager who suspects the numbers aren't reliable has to compensate with more checking, more chasing, and more time spent verifying what the system should already be telling them. That's friction too, just at a different level of the organisation.
"A used system with unoptimised workflows produces better outcomes than an optimised system nobody uses."
The adoption metric is the one that matters
There's a temptation, when building or implementing operations software, to optimise the workflow at the same time. The system is being rebuilt anyway, so it can feel like the right moment to fix the inefficiencies too.
The problem is that optimisation means relearning. Relearning creates friction, and friction during a software rollout is exactly the condition that produces new workarounds.
The better measure of a successful implementation is whether the team is actually using the system, fully, consistently, and without routing around it. Adoption is the primary metric. Everything else follows from it.
A system that mirrors how people already work, even if that workflow has inefficiencies, will be used. A system that asks people to change how they work, even if the new way is objectively better, will be worked around.
What to do about it
The starting point is to understand workarounds. Each one is a signal about where the current system fails to fit the team. That signal is valuable because it tells you exactly what the next system needs to do.
Before any software change, whether that's a new platform, a legacy modernisation, or an upgraded tool, the question to ask is: what are people routing around today, and why? The answers to those questions are the real requirements, grounded in how the operation actually runs.
When you build or rebuild around those requirements, you remove the conditions that produced the workarounds. The friction falls away. The system fits, people use it, and the data becomes complete and reliable.
If you're looking at your own operation and recognising this pattern, it may be worth examining whether your current tools are designed around how your team actually works. The difference matters more than it might appear. We build platforms around existing workflows.
For a concrete example of how this shows up in practice, the manufacturing modernisation case study shows what happens when a legacy system is rebuilt around the way people already work.
Related reading