Automating a broken process makes it faster, not better

Map the process as it is actually performed, not as the policy document describes it. The difference between the two is usually where the delay lives — a written policy says an approval takes one step, but in practice it bounces between three people because the policy never accounted for how work actually flows on a busy day.

The most reliable way to see this gap is to walk one real case end to end with the people who touch it, timing each handoff, rather than relying on a flowchart drawn from memory.

Then question every approval. Many exist because a previous system had no audit trail — a condition that no longer applies once work is digital and every action is already logged automatically. An approval that exists purely to create a paper trail is a candidate for removal, not automation.

A useful test for any approval step: what specifically could go wrong if it were removed, and is that risk still real today, or was it only real under a system that no longer exists?

Only after the process is simplified should integration begin. Automation applied to a clean process needs fewer rules, fails less often, and is far easier to maintain — while automation layered onto a messy process just moves the mess around faster and makes it harder to see.

In practice, this means resisting the temptation to buy or build a connector the moment two systems need to talk. The cheaper first step is almost always removing unnecessary handoffs from the process both systems are trying to serve.

In practice, this means resisting the temptation to buy or build a connector the moment two systems need to talk.

Before automating a workflow, it helps to confirm: the process has been walked end to end with the people who run it, not just diagrammed from a policy document; every approval step has a named reason that still applies today; and there is a way to measure whether the automated version is actually faster, not just busier-looking.

A common example is a purchase-approval workflow that routes every request, regardless of amount, through the same three sign-offs. Mapping the process usually reveals that the third sign-off was added years earlier for a specific large purchase and was never scoped back down — meaning most requests wait on an approval that adds no real oversight.

Simplifying it first — tiering approval by amount, and removing the sign-off that no longer matches actual risk — before automating the routing means the automation only has to enforce rules that make sense, instead of encoding an approval chain nobody can explain.