When automation is the wrong answer

We are a software company. Recommending against software costs us revenue, so treat what follows as a position we hold against our own interest, which is roughly the only way to judge whether advice is honest.

One: the process is broken, not slow

A client asked us to automate an approval chain that took eleven days. Watching it, the eleven days were not processing time. They were nine days of a document sitting in an inbox because two managers each believed the other owned the decision.

Automating that would have produced an approval chain that still took eleven days, plus a system to maintain. The fix was a sentence in a policy document naming one owner. It took an afternoon and cost nothing, and the chain now runs in two days.

The tell: when you ask where the time goes and the answer is waiting rather than doing, you have a decision-rights problem wearing a technology costume.

Automating a process nobody has agreed on does not settle the argument. It hard-codes whichever side happened to be in the room when the spec was written.

Two: the volume does not justify it

The arithmetic is not complicated and it is worth doing before the first meeting. Hours per week saved, times a realistic loaded hourly cost, times fifty. Against that: the build, plus running costs, plus somebody’s attention when it breaks — and it will break, because every integration eventually meets a system that changed without telling anyone.

If the payback is longer than about two years, it is usually a bad buy. Not because the number is magic, but because two years is roughly how long it takes for the surrounding process to change enough that the automation needs rewriting anyway.

We would rather run that calculation with you and lose the project than deliver something that never earns its cost back and quietly sours you on the whole idea.

Three: nobody has agreed what the process is

Sometimes discovery finds that three teams do the same task three different ways, and each is certain theirs is the standard one. That is not a software problem yet. Build now and you either force everyone onto one version by fiat — which they will work around — or you build all three and maintain triple the surface forever.

The work that has to come first is a decision, made by a person with the authority to make it. We can facilitate that and write it down. We cannot code around its absence.

What we do instead

In all three cases the output of discovery is a written recommendation that says: here is what we found, here is why software is not the first move, here is what is, and here is what it would be worth automating afterwards. The map is yours whether or not you build with us.

Some of those clients come back a year later with the process fixed and a much smaller, much better-defined build. That is a better project for everyone, including us. Some never come back, and that is a fair price for having told them the truth.

When automation is clearly right

For balance, since this could read as reflexive caution. Automate without much hesitation when the process is stable and understood, when the volume is real and growing, when the work is genuinely repetitive rather than judgement-heavy, and when errors carry a cost somebody can name. Those four together are the strongest signal in this business, and when we see them we will tell you to move quickly.

processdiscoveryconsulting Share thisLinkedInWhatsAppEmail

Copy link If you are weighing up a project and want an outside read on whether it is worth doing at all, that conversation is free and we are not precious about the answer.