Process Automation in Practice: Rebuilding One Workflow Step by Step

There is an old warning in operations work: if you automate a mess, you get an automated mess. It sounds obvious, yet many process automation projects do exactly that. A team takes the current workflow, with its extra approvals, duplicate data entry and informal workarounds, and asks software to copy it step by step.

The result is fast and fragile. The automation inherits every oddity of the old process and adds a new one: it fails whenever reality departs from the script. Staff then spend their time catching the failures, and the promised gains shrink.

The better order is to fix first and automate second. That takes longer at the start, but it often removes steps entirely and leaves a simpler process that software can handle reliably. This article follows one familiar process through each stage, from the first map to the switchover: supplier invoices in a midsize company.

Map the process people actually follow

Official process diagrams describe how work should flow. The real process usually has more steps. Invoices arrive by email, by post and through a supplier portal. Some go to accounts payable, some to the person who ordered the goods. A few are approved twice because one manager does not trust the system, and others sit in an inbox during holidays.

The only way to see this is to follow real cases. Sit with the people who handle them, trace a dozen invoices from arrival to payment and note every handoff, delay and workaround. Where systems keep event logs, process mining software can add a wider view. The aim is a map of what happens, not of what the manual says.

While mapping, record a simple baseline. How long does a typical invoice take from arrival to payment? How many need a correction or a reminder? How many are paid late? These figures are rarely exact, but they give the project a starting point. Without them, nobody can say later whether the new process is better.

Remove steps before automating them

With an honest map in hand, question every step. Does this approval change any decision, or does it simply add a signature? Is this data typed in by hand because two systems are not connected? Is this check still needed, or did it start after a single incident years ago?

In many processes, a surprising number of steps exist only to compensate for other problems. Removing them is often the cheapest improvement available, and it shrinks what the automation has to do. In the invoice example, a common fix is to route all invoices through one channel and match them automatically against purchase orders. Only the mismatches then need a person.

Standardize the inputs

Much of the complexity in process automation comes from messy inputs. Free-text emails, scanned documents in many layouts and forms with optional fields all force the software to guess. Every guess is a potential error.

• Use structured forms instead of open emails wherever the sender can be asked to cooperate.
• Define required fields and valid values, so incomplete requests are caught at the start rather than halfway through.
• Agree on standard formats with major suppliers or partners, such as electronic invoices instead of PDF files.
• Keep reference data, such as supplier records and cost centers, clean and owned by a named person.

Each of these measures reduces the number of special cases. The automation can then focus on the common path, which is where it performs best.

Design the exceptions on purpose

No process runs without exceptions. An invoice does not match its order, a field is missing or a supplier changes its bank details. The question is what happens next. In poorly designed automations, the case stops with an error message that only an administrator ever sees.

A well-designed process sends exceptions to a person with enough context to act quickly: what the case is, why it stopped and what the options are. It records the decision, so recurring exceptions become visible and can be fixed at the source. Some cases, such as a change of bank details, should always require human confirmation, because they are a favorite target for fraud.

The quality of a process automation shows less in the cases it handles than in how it hands over the ones it cannot.

Match the technique to each step

Process automation is not one technology. Within a single workflow, different steps may suit different tools. Where systems offer interfaces, direct integration is usually the most stable option. A workflow engine can route tasks, track deadlines and escalate delays. Document capture software can read invoices, with a person checking uncertain fields. Screen-level robots remain a fallback for old systems that offer no other access.

Mixing techniques is normal. What matters is that each step uses the most stable option available and that the whole flow is documented in one place, so that anyone can see which tool handles which part of the case.

Switch over with care

The last stage is often rushed. A new process looks finished in testing, and the team is eager to retire the old one. Yet test data is usually cleaner than real work. Unusual suppliers, month-end peaks and holiday backlogs only show up in live operations.

A safer route is to run the old and new paths in parallel for a few weeks, or to move one group of suppliers or one site at a time. Compare the results case by case. Check that every exception reached a person and that nothing was paid twice. Only then retire the manual path, and keep a written fallback for the day a connected system goes down.

The payoff of this order of work goes beyond a better automation. It produces a process that people understand, that fails visibly and that can change again without a full rebuild. In most organizations, that is worth more than raw speed, and it makes the next automation project easier to start.