Automating without producing errors faster
Four observations come up on almost every automation project. Two explain why it's worth it, two explain why it goes wrong.
In this article4 sections
Automating a shaky process means producing errors faster
In most companies, the same operation is done slightly differently depending on who does it, and nobody has ever written it down.
Automating that as it is doesn't freeze a process: it freezes one person's version, with its approximations. The result comes out faster, takes less time, and stays wrong, except that nobody checks it any more.
Hence the order of operations: write down the real sequence, the one people follow, before deciding what gets automated. This step alone often already solves part of the problem, and sometimes you leave with less automation than planned.
Time isn't lost in the tasks, it's lost between them
Nobody notices the ten seconds it takes to fetch an order number from another tool.
But this back-and-forth takes up a serious share of the week: several hours for ordinary office work. It's time that appears on no budget line, never complains, and nobody thinks to measure.
That's also why the clearest gains don't come from the most visible tasks. They come from the joins between them.
Your software doesn't talk to each other, and nobody ever decided that
Each tool was chosen separately, for good reasons, by different people at different times. Across the companies studied, only a small minority of the applications in place are actually connected to each other.
The bridge between two tools is therefore someone, and that someone is the real point of failure: when they're on holiday, the chain stops.
When connecting two tools, it's better to use the interfaces designed for that when they exist, rather than a robot clicking on a screen. A screen changes. An interface doesn't.
An automation that fails silently costs more than no automation
As long as a human does the task, they see straight away when something's off. A machine doesn't: it stops, and the gap is only noticed when a client reports it, sometimes weeks later.
An unmonitored automation doesn't save time, it loses the visibility you had before.
Three things to require on delivery, not three months later:
- A record of what ran, and what failed
- An alert that notifies someone the same day
- What it takes to understand what's running without calling whoever built it
One last reflex, perhaps worth more than the four points put together: put a single flow truly into service, all the way, and watch it run for a few weeks before launching a second. Ten projects opened at once means ten half-done things nobody maintains six months later.
Ce sujet touche à notre expertise Process automation.
We start with a conversation, not a quote.
Voir l'expertiseRead next
