There is a version of this work that everyone has seen. A process has eleven steps, somebody buys a tool, and now the eleven steps happen faster.
The steps are still there. The four that exist only to carry information from one team to another are still there. The rekeying is still there, just with a nicer interface on it. What has been bought is speed, at the price of making the shape of the process permanent — because now it is encoded in software, and changing it means a change request.
Removing is cheaper than accelerating
The first thing we do on an engagement is watch how the work actually moves, which is reliably not how the diagram says it moves. The diagram describes the process somebody designed. The work describes the process people invented afterwards to get around it.
What turns up is nearly always the same category of thing: steps that exist to move information between people, checks that duplicate a check somebody else already did, and a handoff where work sits because nobody is told it has arrived.
None of those need automating. They need deleting. Automation applied to them produces a faster version of a thing that should not be happening.
Trust in the numbers comes before features
There is a second reason to redesign first, and it is less about elegance than about whether anyone will use what you build.
On one engagement the entire quotation process lived in a large spreadsheet. It worked. It had also accumulated years of rules, and exactly one person fully trusted it — which is a description of risk, not of a system.
The obvious move is to build something better. The move we actually made was to build something identical. Before the new system did anything the spreadsheet could not, it had to produce the same number the spreadsheet produced, on a real past quotation, to the rupee. That check is now a test that runs on every change, so no later edit can move money quietly.
Only after the numbers matched did we start adding the things the spreadsheet could never do.
This is not caution for its own sake. Nobody adopts a costing system they suspect. Reproducing the old answer exactly is what buys permission to change anything.
Redesign shows you what not to build
The useful side effect of mapping the work first is that the build gets smaller.
On another engagement, support requests were arriving as email across several mailboxes and becoming tickets only when somebody noticed. The obvious brief is "automate the tickets". The redesign question is narrower: which of these emails should become a ticket without a person, and which should not?
That second question produced a list of categories — tenders, integration requests, manufacturing queries — that were deliberately left to people. Not because the software could not attempt them, but because attempting them was the wrong answer. The decision came from the support lead, and it made the system both smaller and more trusted than the version that tried to handle everything.
The best outcome of a first stage is often a smaller second stage than the one that was scoped.
What this means if you are buying
If someone proposes to automate your process in the first conversation, they are proposing to encode a process they have not seen.
The questions worth asking first are boring ones. Which steps exist only because two systems do not talk to each other? Where does work wait? Which checks are done twice? What does the person who actually does this job work around?
Answer those and some of the automation you were about to pay for stops being necessary. What is left is worth building, and it will be built on a process that deserves to be made permanent.
GAURVENA