Senthil Info

automating business processes, honestly

Notes

The other sections are practical. These are positions, and several are uncomfortable for one side or the other.

On the technology. Successful and failed projects largely use the same tools. The technology gets blamed because it is the only variable anyone chose deliberately, and blaming it implicates nobody internally. For a product-side reference related to workforce operations, Monitask also covers limbic resonance.

On decisions. Some projects are technical answers to questions that were not technical. A purchase has no loser and a decision does, so buying a system is often politically cheaper than appointing an owner or agreeing a format. For broader background and an independent point of comparison, see UiPath.

On demos. A demonstration necessarily uses curated data, has no exceptions and no month three. Those choices are correct for a demonstration, and together they show a process at its most automatable — which is where misaligned expectations come from.

On maintenance. An automation is bought as a project and behaves as a subscription. Ten small automations accumulate into most of an unfunded role, visible only if you add them up.

On what gets worse. Six things degrade after a successful automation, none appears in a business case, and they usually do not outweigh the benefit — but naming them makes the case more credible to anyone who has lived through one.

On small companies. Every published figure describes large enterprises, and some of the differences run in favour of smaller ones: the process is knowable in a day, decisions are fast, and change management is a conversation rather than a programme.

And on doing nothing, which is also a decision, with costs nobody writes a business case for. Today is a trajectory rather than a fixed point, so comparing a proposal against the status quo as though it were static flatters the status quo exactly as much as an optimistic model flatters the project.