Why automating a broken process usually makes it worse
Automation doesn't fix a process. It multiplies it. A good process gets faster and cheaper. A broken one breaks faster, at volume, with nobody watching. Bolting a motor to a wheelbarrow with a flat tire gets you a faster flat. Fix the process by hand until it runs boring, then automate the boring.
Why this matters operationally
A broken manual process fails at human speed, with a human standing right there who knows something's off. The same process automated fails at machine speed, unattended. And worse, everyone now assumes the machine is right. The day you automate something, your team's trust transfers to the system. If the process underneath was broken, you've automated the breakage and retired the person who used to catch it.
The failure modes we've actually seen
The mystery step.Walk any messy process and you'll hit a step nobody can explain. "We've just always done it that way." Automate around it and you've frozen the mystery in place forever. Nobody will ever question it again, because now it's software.
The double-fire.Scheduled automations hide a nasty one: when the record of a decision and the record of an update disagree by even a few seconds, a timer can act twice. Our own rule, learned the careful way: before any scheduled automation goes live, we simulate 3 to 5 consecutive timer ticks and watch what happens. Bursts hide in gaps you can't see on a whiteboard.
The pipe to nowhere.The most common one in shops that call us: leads flowing into a spreadsheet nobody owns. Automating the intake just fills the void faster. The problem was never speed. It was that no one's job was to read the thing.
The archaeology.This year we brought a Jumbotron back to life that was running software older than some of our clients' businesses. Most of the work wasn't code. It was archaeology, figuring out what the system actually did before touching it. Automating around a system nobody understands starts with understanding it. There are no shortcuts, only postponed ones.
The checklist
Before automating any process:
- Can someone walk the whole thing on a whiteboard, including the exceptions? If nobody can, it's not ready.
- Has it run by hand, boring and fire-free, for at least a month?
- Does every step have an owner who would notice if it broke?
- Do you know what "wrong" looks like, and where you'd see it first?
- Honest one: are you automating the process, or automating your way around a decision nobody wants to make?
When to get help
If the true answer is "we want automation because the process is a mess," you don't need an automator yet. You need the mess fixed, and a good implementer will say so. If a vendor quotes you a price before mapping how the work flows today, they're automating blind, and you're paying for it twice.
Our recommendation
Boring first, fast second. Run it by hand until nothing about it surprises you. Then automate it and enjoy a machine that multiplies something worth multiplying.