Document the process before you automate it

Automating a process nobody has written down doesn't fix it. It locks in one version and runs it faster.

whiteboard-graphic

Most automation projects fail in a quiet way. The automation works. It does exactly what it was built to do. The problem is that what it was built to do was never written down, so nobody can say whether it's right.

We learned this the hard way. On one long engagement, we automated processes as fast as we could find them. The automations ran, but every few weeks one would do something technically correct and practically wrong, because the process it was based on lived in someone's head and had changed since. We spent more time chasing those surprises than we saved.

Why the order matters

A process you can't describe is a process you can't check. When it lives only in people's heads, three things happen. Different people do it differently. Exceptions get handled from memory. And the one person who knows the edge cases becomes the bottleneck.

Automating that process doesn't fix any of it. It locks in one version, usually the version described by whoever was in the meeting, and runs it faster.

What documenting actually means

It doesn't mean a binder nobody reads. It means a short, plain description of how the work gets done today:

  • What starts it
  • Who touches it, in order
  • What information moves at each step, and where it lives
  • The exceptions, and what people do when they hit one
  • What done looks like

If you can't fill that in, you've found the real problem, and it isn't a software problem yet.

The stated process and the real process

When you write it down, you'll notice the official process and the real one are different. People skip steps that don't matter and add steps nobody asked for, usually for good reasons. Watch the work being done instead of asking how it's supposed to be done. The gap between the two is where most of the useful automation ideas come from.

Then automate

Once the process is on paper, automation gets easier and safer. You can see which steps are pure data movement and can go away entirely. You can see which ones need judgment and should stay human. And when something goes wrong later, you have something to check the system against.

The written process also becomes your training material. New people learn it from the page instead of from the one person who knows.

A simple test

Before automating anything, ask the person who does the work to explain it in five minutes, out loud, while someone writes it down. If they can, you're ready. If they keep saying "it depends," write down what it depends on first.

It feels slower at the start, and it saves time every week after.

Keep reading

Opinion

Delivered means used

A system nobody uses is worth nothing. Most projects define done as delivered. We define it as used.

Patrick Flanagan, 2 min read