Business Processes and Day-to-Day Reality
Why a new tool will not fix an unclear business process
New technology can reduce friction. It cannot replace unclear roles, contradictory rules or decisions nobody has made.
The expectation is understandable: the process works badly, so it needs a better tool. And a new tool does reliably solve one class of problems — rarely the class it fails on.
What a tool can solve
A tool replaces manual work. It moves data without anyone retyping it. It remembers deadlines. It makes states visible that used to sit in mailboxes. It prevents entries that are not permitted.
These improvements are real and measurable. When a process is clear and merely laborious to carry out, a better tool is the right answer.
What a tool cannot solve
A tool makes no decision that the process has not made. It clarifies no responsibility nobody has assigned. It resolves no contradiction between two rules that are both supposed to apply.
And because it cannot, it demands a ruling at exactly those points — otherwise it cannot be configured. That ruling then happens during rollout, under time pressure, often by whoever is setting the tool up.
Process decisions arise as a by-product of tool configuration. They are rarely ill-intentioned and frequently poorly aligned.
The recognisable pattern
A project working on an unclear process shows typical symptoms:
- Requirements clarification takes longer than expected, without anyone being able to say why.
- New special cases keep appearing that nobody mentioned before.
- Different participants describe the same workflow differently — and both descriptions are correct for their area.
- The question “who decides that?” is asked repeatedly and never finally answered.
None of these is a tool problem. All of them become more visible with a new tool, because it enforces a precision the process never needed before.
The right order
The clarification does not have to be complete before building starts. It has to be far enough along that the rulings are made deliberately rather than in passing.
Three things usually suffice: the real workflow is described, including the exceptions that occur in practice. For every decision in the workflow, it is named who makes it. And where rules contradict each other, it is settled which one applies.
After that, the tool question is a good question — and considerably easier to answer.