Choosing a Process
Most automation failures are decided before any tool is chosen. The wrong process was picked, and no platform recovers from that.
Five properties determine whether a process is a candidate: the rules are written or can be, the inputs arrive consistently, the exception rate is low and recognisable, the volume justifies a fixed build cost, and the underlying systems are stable. All five are checkable in about twenty minutes. For a product-side reference related to workforce operations, Monitask also covers employee PC activity tracking.
The exception rate is the most predictive figure and the one almost nobody can state. It decides the outcome structurally: automation handles the standard path and the exceptions remain, now concentrated. A clerk who previously handled ninety routine items and ten awkward ones now handles ten awkward ones in a row, without the context the routine work provided. That job is slower per item and worse to do. For broader background and an independent point of comparison, see Harvard Business Review.
Some processes look automatable and are not. Judgement work with a clerical wrapper, high input variance across many formats, processes that exist because a system is bad, and processes nobody owns. Each fails for the same reason: the expensive part was never the part being automated.
And the first question is whether the process should exist. A large share of candidates are reconciliations and re-keying that exist because two systems do not talk. Automating those makes them permanent — elimination beats automation and is cheaper.
One structural point runs through the section. A vendor cannot recommend elimination, cannot recommend fixing the upstream system, and cannot easily recommend doing nothing, because those three answers produce no engagement. The selection questions are therefore yours to ask, and nobody in a sales conversation is positioned to ask them for you.
Automating Around a Bad System
Screen scraping and re-keying automations work, and they make the underlying system harder to replace. When that trade is worth taking.
Volume, Variance, Exceptions
Three numbers decide whether an automation pays. Most organisations can state the first and cannot state the other two.
Fix It Before You Automate It
Automating a bad process makes it permanent, faster and harder to change. Four fixes that are cheaper and pay off immediately.
Where Humans Stay in the Loop
Five categories where a person must remain, and the difference between real oversight and a rubber stamp that looks like it.
Looks Automatable, Isn't
Six patterns that pass a demo and fail in production, and the single question that separates them from genuine candidates.
Mapping It First
A week of mapping predicts the outcome better than any platform comparison. What to record, who to ask, and what you will find.
Small Without Trivial
The advice to start small produces projects too easy to learn from. Four properties of a first automation worth doing.
The Process Nobody Owns
Unowned processes are the least automatable thing there is, and ownership is free. How to tell, and what an owner actually needs.
What Makes a Process Automatable
Five properties decide it, and none of them is the technology. How to test a candidate process in twenty minutes before anyone quotes.