Do we need to fix our processes before we automate?
No, but you do need to be able to describe them, and that is not the same thing. "Fix the process first" is the most common reason automation gets postponed indefinitely, and it is usually the wrong advice. Waiting for a tidy process means waiting forever, because nobody tidies a process for its own sake.
The distinction that matters: a messy process is fine, because mess is mostly exceptions and exceptions are what we build for. An unsettled process is not, because you would be encoding a shape you are about to abandon.
There is also a side benefit. Writing a process down precisely enough to automate is what forces it to settle. The discipline is the fix, and you get it as a by-product rather than as a separate project.
Messy is fine. Unsettled is not.
These get confused constantly, and they lead to opposite decisions.
| Messy | Unsettled | |
|---|---|---|
| Looks like | Lots of special cases, workarounds, "except when" | The shape of the work changed twice last quarter |
| Underlying rules | Exist, just undocumented | Still being invented |
| Ask two people | Same answer, different words | Genuinely different answers |
| Automate now? | Yes. Mess is scope, not a blocker | No. Wait, or automate only the settled part |
Almost every process we are shown is messy, and that is normal and expected. The mess is the work. The exceptions are usually most of the engineering, which is why an estimate made without watching the real process is reliably wrong. See the exception problem.
Unsettled is different and rarer. If a process has genuinely changed shape twice in the last quarter, it will change again during the build, and you will pay twice: once to encode it and again to change it.
Why "fix it first" stalls projects
The advice sounds prudent, and it fails for three reasons.
- Nobody has time to fix a process for its own sake. Process improvement with no deadline and no deliverable loses to actual work, every week, forever. The project quietly never starts.
- You cannot see the real process from the inside. Tidying is usually done from how people believe the work happens, which is not how it happens. The sticky note on the monitor, the second spreadsheet, the customer handled differently: none of that surfaces in a tidy-up workshop. It surfaces when somebody watches.
- Half the mess is not worth fixing. Some exceptions exist for good reasons and should be preserved. Some exist because the software could not do something in 2019 and nobody revisited it. Automation forces you to tell those apart, one at a time, with a reason attached. Tidying in the abstract does not.
Scoping is process documentation you get for free and that ends in a costed plan. If you were going to pay a consultant to map the process before improving it, you are paying for the same work twice.
What genuinely should be fixed first
Four things, and none of them is "make the process tidy".
- Duplicate and inconsistent records. Three spellings of the same supplier will defeat matching before any clever logic gets involved. This does need addressing, though usually as part of the build rather than before it, and it is quoted visibly rather than buried.
- Nobody who can decide. The single best predictor of a project finishing on time is one named person who can answer "should this edge case route to a human or take the default?" without convening a meeting. If that person does not exist, appoint them before you start.
- Access nobody can authorize. Not a process problem, but the most common cause of delay. Find out who administers each system and who can grant access. Do it during scoping.
- A process about to be replaced. If the underlying software is being swapped within the year, automate against the new one.
Notice what is absent: standardizing, documenting, and getting everyone to work the same way. Those are outcomes of automating, not prerequisites.
A test you can run this week
Ask two people who do the work to describe it separately, in writing, in ten minutes. Then compare.
| Result | What it means | Do this |
|---|---|---|
| Same steps, different wording | Settled and merely undocumented | Automate. This is the normal case. |
| Same steps, different exceptions | Settled, with undocumented branches | Automate. The branches are the scope. |
| Genuinely different steps | Two processes under one name | Decide which is correct first. That decision is yours, not ours, and it takes an afternoon. |
| Neither can describe it | Tacit knowledge in one person's head | Automate, but budget for discovery. This is exactly what watching the work is for. |
Only the third row is a genuine stop, and it is rarer than people fear. The fourth looks alarming and is routine. It is the most common situation in a business under 200 people, and it is the situation scoping exists to handle.
Think your process is too messy to automate?
It probably is not. Tell us what it looks like on a call and we will tell you honestly whether it is messy or unsettled, and if it is unsettled, we will say wait.
You will talk to Fayez or Kareem. Nobody else.