Process

Work that repeats, in a fixed order, across more than one person or system. A task is one step. A process is everything between the steps, which is also where it goes wrong: the handoff, the wait, the second person opening the same file to check what the first one entered.

Every process exists in three versions, and they do not match. There is the documented one, written in a procedure nobody has opened since it was approved. There is the described one, which is what people say when you ask them how the work is done. And there is the executed one, which is what the logs show actually happened. The distance between them is not a failure of discipline. It is what happens when a process is never designed, only accumulated, one workaround at a time.

The gap has consequences the moment automation comes up, because the version that gets automated is almost always the described one. It is the version you get by asking, and it is the version people believe. It leaves out the cases nobody thinks to mention, which are exactly the cases that break the build.

Michael Hammer made the harder point in 1990: a bad process automated is a bad process running faster. His case was Ford, whose accounts payable department employed over 500 people reconciling orders, deliveries and invoices. The plan was to cut that by a fifth. Mazda ran the same function with five people, so Ford abandoned the plan and deleted the invoice instead, leaving nothing to reconcile. Headcount fell by 75 percent, and no part of that came from doing the old work faster.

Which is why the first question is never how to automate a process. It is whether the process should exist in that shape at all.