Today’s story will sound familiar to almost every one of you :)
You have finished the project. The processes are working, the customer is happy with the result, and there are no major incidents. For a moment, the world seems like a good place.
But one thing is quietly spoiling this perfect picture.
A workaround!
I am sure you have heard this word many times during your career. A workaround often looks harmless. It solves an immediate problem, keeps the process moving, and helps everyone get through the day.
But every workaround has a hidden cost—and sometimes that cost is much higher than anyone expected.
Today, I want to explain why.
A Simple Example: Processing Customer Discounts
Imagine an order system that cannot handle a specific type of customer discount. This is actually a very common example.
Every Friday, someone exports the affected orders, adjusts the amounts in Excel, and sends the corrected file to finance.
It takes about two hours a week. Nothing dramatic.
But two hours a week adds up to roughly 100 hours a year.
And that is only the regular work. It does not include explaining the process to a colleague, investigating a mistake, or finding someone to cover during a holiday.
Now imagine the number of orders doubles.
The system limitation has become a recurring operational cost.
That does not automatically mean the company should build a new feature. A system change may cost more than the workaround.
But “we can do it manually” is not enough information to make that decision.
What does the workaround really cost?
The most visible cost is the time spent doing it.
Other hidden costs are easier to miss:
Checking and correcting the results.
Waiting for a particular person to become available.
Delaying the next step in the process.
Training someone to cover the task.
Handling errors that reach customers.
Giving up other work that the same person could have done.
A workaround can also create dependency on knowledge that exists only in someone’s head.
“It’s easy, Anna knows how to do it.”
Great. What happens when Anna is away?
10 Questions a Business Analyst Should Ask Before Introducing a Workaround
What problem does the workaround solve?
Who performs it, and how often?
How much time does it take, including checks and corrections?
How often does it fail, and what happens when it does?
Does it delay customers or other teams?
Can someone else perform it when the usual person is unavailable?
What happens if the business volume doubles?
Could we remove or simplify the underlying business requirement?
How does the ongoing cost compare with the cost of changing the system?
If we keep the workaround, when should we review that decision?
The key lesson
Not every workaround needs to be automated.
For a rare exception, a manual process may be the best business choice. For a frequent activity, it may be much more expensive than it appears.
The important thing is to make that choice consciously.
A good business analyst does not ask only whether a process works. They also ask what it takes to keep it working and whether that still makes sense.