Why Process Understanding Comes Before Automation

Every organization has two versions of its processes. There is the documented version, which appears in procedure manuals, system configurations, and onboarding material. And there is the operating version, which includes the workarounds, the informal escalations, the spreadsheet that reconciles two systems that were never properly integrated, and the person everyone calls when something unusual happens.

Automation initiatives are usually scoped against the first version and then encounter the second.

Exceptions are the process

In most operational workflows, the straightforward cases consume a minority of the effort. The cost concentrates in the exceptions: incomplete submissions, conflicting records, unusual terms, timing problems, and the cases that require someone to make a judgment call and then explain it.

An automation effort that handles the straightforward cases and routes everything else to a person can therefore reduce volume substantially while reducing effort very little. This is a common and disappointing outcome, and it is entirely predictable if the exception distribution was examined beforehand.

What discovery should actually involve

Useful process discovery is closer to fieldwork than to workshop facilitation. It generally requires:

• Observing the work being performed rather than only discussing it.
• Examining a real sample of recent cases, including the difficult ones.
• Identifying every system the work touches, including the unofficial ones.
• Establishing where information is re-entered, reconciled, or verified by hand.
• Understanding what happens when something goes wrong, and who notices.
• Asking experienced staff which parts of their job they consider avoidable.

The people doing the work usually know exactly where the waste is. They are rarely asked in a setting where the answer is safe to give.

Redesign before tooling

Once the real process is visible, a portion of the identified effort typically turns out to be unnecessary rather than automatable. Duplicate approvals, reports nobody reads, verification steps that compensate for a data quality issue upstream, and handoffs that exist because of a reorganization several years ago.

Removing that work is faster, cheaper, and lower-risk than automating it. It also improves the economics of whatever automation follows, because the remaining process is simpler and its requirements are clearer.

Then decide what technology is for

With a redesigned process in hand, the technology question becomes tractable. Some steps are deterministic and belong in conventional automation. Some require interpretation of unstructured input and are well suited to AI. Some require accountability and should stay with a person, supported by better information.

That allocation is the actual design work. It cannot be done credibly from a capability demonstration, and it cannot be outsourced to a vendor whose incentive is to maximize the footprint of their product.