Business Processes and Day-to-Day Reality
Workarounds are not the exception — they are part of the real process
What Excel lists, manual coordination and shadow solutions reveal about the weaknesses of a line-of-business application.
In almost every process review there is a moment when someone says: “And then there is this Excel list, but that does not really belong.” It does belong. Without it, the process does not work.
A workaround is a diagnosis
A workaround does not come from carelessness. It comes from someone having to do their job while the intended solution would not let them. Every workaround therefore marks precisely the point where the application and the working reality diverge.
That makes it the most valuable source of information in an assessment. Process documentation describes how it was meant to be. The workarounds describe how it is.
What each workaround reveals
The form of the workaround says something about the cause:
A list alongside the application usually means: a field, a status or a view is missing. The information is needed in the business but not catered for in the system.
An email exchange at a point in the process usually means: a decision is required here that the workflow does not cover. Often it is also unclear who is allowed to make it.
Entering the same data twice usually means: two systems do not know about each other, and nobody has decided which one is authoritative.
A person you call first usually means: there is a rule that is written down nowhere.
Why workarounds are overlooked during replacement
When an application is replaced, the new system is modelled on the old application — not on what happens beside it. The workarounds look like legacy baggage you are finally getting rid of.
After go-live it turns out they had a function. They come back, often in a new form, and the new system has the same problem as the old one — except it is now more expensive and nobody is allowed to question it any more.
How to work with them
The productive approach is neither to forbid them nor to adopt them. It has three steps:
- Collect without judging. As long as workarounds count as misbehaviour, they will not be shown. They are only useful once they are fully on the table.
- Name the intent behind each one. Not “Excel list”, but: which information is held here, and why is it needed?
- Decide what belongs in the target state. Some intents have to go into the solution. Some point to a process weakness better fixed in the process. And some are genuinely obsolete.
Only after that third step is it possible to say what the new solution has to do — and what it deliberately should not.