Anna Totterdell
Projects Director
Here is a question for the CEO or managing director reading this. Answer honestly - even if only to yourself.
Can you describe, step by step, how a customer order moves through your business from enquiry to delivery to cleared payment? Every handoff. Every system. Every manual intervention. Every exception.
You cannot. Nobody in your leadership team can. And the reason is not that you are bad at your jobs. It is that there are two versions of your business, and the one you can describe is the official version. The one that actually runs the operation lives somewhere else entirely.
The two versions of your business
The official version is documented. It is in the process guides, the system flowcharts, the onboarding decks, and the policies the compliance team reviewed last year. In this version, data flows cleanly between systems. Steps follow each other in logical sequence. Rules are applied consistently. Exceptions are handled according to defined procedures.
The actual version is undocumented. It is in the habits, spreadsheets, email rules, personal checklists and tribal knowledge of the people who execute the processes every day. In this version, someone adds a manual step because the system cannot handle a specific product type. Someone maintains a personal spreadsheet because the report the ERP generates is missing a column a client requires. Someone sends a specific email to a specific colleague every Thursday because an automated handoff fails silently and has to be triggered by hand.
These unofficial steps are workarounds - and in most mid-market businesses they are not exceptions. They are the operation.
Where workarounds come from
Workarounds are not failures of the people who use them. They are evidence of system failures that were never fixed. Someone hit a problem - a system that could not cope with a scenario, an integration that dropped data, a process that did not account for a real-world exception - and instead of escalating for a structural fix, they invented a way around it.
The invention was pragmatic. It was immediate. It worked. And because it worked, nobody reported the underlying problem. The workaround became the process.
They accumulate for a reason. Reporting the problem means explaining it to someone who may not understand the operational context. Getting approval for a structural fix means justifying the time and cost against a problem that is already "solved" locally. Implementing that fix may affect other teams or systems. None of that is easy. Working around it, on the other hand, takes five minutes and affects nobody else today. The workaround wins. Every time.
Worse, workarounds compound. One unofficial step enables the next. The manual correction someone makes in the spreadsheet creates a dependency on the person who knows the correction is needed. The email that replaces a broken handoff creates a shadow ownership of the step. Over a few years, these individual fixes form an entire unofficial layer of operations sitting on top of the systems you paid for - and none of it is visible to anyone who did not build it.
The three costs you are paying
Every workaround charges you rent. Most businesses only notice the first of three costs and underestimate the other two.
The time cost
Every workaround adds a manual step to a process. Each step is small; together they are not. Multiply the minutes across every workaround across every team across a year and you have a significant volume of skilled labour consumed by work that should not need a human. This is the cost leadership teams estimate, usually by a factor of two low.
The risk cost
Every workaround creates a dependency on the person who invented it, and usually on nobody else. When that person is ill, on holiday, promoted or leaves, the workaround stops. The gap it was bridging is suddenly visible, mid-process, in production. The business discovers - unpleasantly - which steps of its operation depended on an individual rather than a system. Audit risk, compliance risk and error blast radius all sit under this heading, and they only surface when it is too late to plan for them.
The scalability cost
A manual fix that takes five minutes when you process ten orders a day takes fifty minutes when you process a hundred. The workaround that was invisible at low volume becomes a bottleneck at high volume - and because it was never formally designed, it cannot be cleanly automated or replaced. This is the cost that shows up later as "growth stalled" or "we added headcount but the backlog got worse." It is the cost that looks like a people problem and is actually a process one.
A three-hour audit you can run this week
You do not need a consultant and you do not need a platform to start. You need three hours and the willingness to hear an uncomfortable answer.
Pick one end-to-end process - order to cash, purchase to pay, customer onboarding, month-end close. Ask the people who execute it, not the managers who describe it, one question: what do you do here that is not in the official process?
Then sit quietly while they answer.
Do not read the process document. Shadow the process instead. Watch a real case move from start to finish. Count the Excel files touched end-to-end. Count the emails that carry data between systems. Count the moments where someone opens a second application to look something up that the first one should have shown them. At every step, ask one more question: who is the single person who, if they were ill tomorrow, would make this step stop?
Document every workaround you find. For each one, capture what it does, why it exists, how long it takes, who knows how to do it, and what happens if it is not done. The list will embarrass you. That is the point. You are building the first honest picture your leadership team has ever seen of how the operation actually runs.
Why this matters for every technology project you commission
This is not a purely operational concern. It is the single largest hidden risk in every technology investment you make.
Every AI pilot, every automation project and every integration programme that touches a process full of workarounds will discover them - mid-delivery, at the worst possible time. The automation breaks because it encounters a step that was not in the process documentation. The AI produces wrong outputs because the data it receives has been manually adjusted before being saved. The integration fails because one of the systems only looked like the source of truth.
Projects then slow down and costs go up while the delivery team quietly documents the workarounds the business never disclosed. This is not the partner's failure. It is yours. You commissioned a project on top of an operation you had not mapped, and the bill includes the mapping you should have done first.
This is why data and systems integration is not a line item you add after choosing your automation tool. It is a prerequisite. Workarounds exist largely because systems do not exchange data reliably; fixing the exchange removes the reason the workaround was invented.
What to do about the five biggest ones
You will find dozens once you look properly. Do not try to fix them all - most of them will dissolve as a side effect of addressing the structural causes. Rank them on the three costs above, pick the five worst, and work through them systematically.
For each, ask why it exists before asking how to remove it. If it exists because two systems do not share data, the answer is integration, not a new rule. If it exists because the system cannot handle a scenario, the answer is configuration or a process redesign that your current IT and process strategy was probably supposed to cover and did not. If it exists because the underlying data is unreliable, the answer is data governance - and applying automation over unreliable data will just produce wrong outputs faster.
Targeted business automation at this layer is unusually high-return, for one reason: workarounds are specific, well-understood by the people who use them, and live in a part of the operation where the business case is obvious. Fixing them gives you measurable time back, eliminates key-person dependency, and removes the exact class of risk that breaks every larger project you might commission afterwards.
The discomfort is the point
Leadership teams often discover this problem in the wrong order. They commission a growth plan, an AI strategy, or an automation roadmap first, and encounter the workarounds later - when they are already committed to a vendor, a budget and a timeline. The sensible sequence is the opposite. Map the operation you actually have. Price the workarounds you have been living with. Then decide what to build on top of it.
If your maturity across data, systems, process, measurement and decisions is uneven, you will see exactly which workarounds are draining you and where the structural fix should start. Run the operational maturity assessment with your leadership team and compare the answers you each give. The gaps between you are where the business actually lives.
You cannot fix what you cannot see. And until you sit down and do the unglamorous, detailed, uncomfortable work of mapping what actually happens in your operation, you are managing a business you have never fully met.
