Bad processes do not improve when you automate them

Automation repeats the rules it receives. Redesign the operation before you give those rules more speed and scale.

A manual process can hide a surprising amount of repair work. People notice missing fields, remember which customer needs special handling, ask a colleague what a code means and quietly correct a mistake before it reaches the next system.

Automation removes those pauses. That is useful when the process is coherent. When the rules are incomplete, it reproduces the error consistently and sends it further before anyone notices.

The first question should not be “What can we automate?” Ask which result the operation is supposed to produce and why it currently fails.

Map what really happens

The process document is a starting point. The live operation is the source.

Follow several real cases from beginning to end. Record where information arrives, which system owns it, who makes each decision, where people leave the documented path and what happens when the ordinary case breaks.

The workarounds matter. A spreadsheet beside the ERP may contain the only reliable view of promised delivery dates. A Slack message may be the actual approval mechanism. A senior employee may recognise a risky order from context that never enters the system.

Removing those workarounds before understanding them can remove the controls that keep the process safe.

Separate necessary judgment from accumulated friction

Some human involvement exists because the decision carries consequence. Some exists because the software is incomplete.

A finance leader may need to approve an unusual payment because they own the exposure. They should not need to copy the invoice total into another screen before doing so. A warehouse supervisor may need to decide whether damaged stock can be used. They should not have to search three inboxes for the purchase order and inspection photo.

Redesign the flow so software carries collection, validation, calculation and coordination. Bring a person in where authority, relationship or uncertain context matters. This division is more useful than a target such as “80% automation,” which says nothing about whether the remaining 20% is the right work.

Fix the rules before encoding them

An approval step may exist because of a risk that disappeared years ago. Two departments may maintain different versions of the same field. A team may ask for data nobody uses. These are operating decisions, not technical integration problems.

Remove steps that no longer contribute to the result. Name the authoritative source for shared data. Define what counts as a valid transition. Give each exception an owner and a time boundary.

Only then should the team encode the process in workflow software, application code or an agent. The implementation becomes simpler because it no longer has to preserve contradictions.

Test the difficult cases first

The ordinary path proves that a demo works. Exceptions prove that an operation can run.

Use recent cases: a partial delivery, duplicate invoice, missing customer consent, unavailable product, late approval or request in unfamiliar language. Show what the proposed system would do, where it would stop and which evidence a person would receive.

Test permissions and recovery as well as happy-path output. Who can reverse an action? What happens when an API fails after the first system updates? Can an operator see that the workflow is waiting? Does the record explain why the route changed?

These questions determine production readiness. They cannot be added as a decorative governance layer after the flow is live.

Measure the business result

Choose a baseline tied to the operation: time from request to decision, correction rate after handoff, cost per completed case, percentage resolved within a customer promise or amount of senior attention consumed.

Activity measures can help diagnose the system, but a larger number of automated steps is not success. A process can execute flawlessly and still produce the wrong customer or financial result.

The cases in Our Work begin with a complete operation and a measure. That discipline makes the first release smaller, because the team knows which part of the flow has to change. It also makes the result defensible. You can compare what happened before with what happens after, then decide whether the next class of work deserves automation.