Glossary

Process automation

A recurring workflow is taken over by software instead of being carried between systems by people.

What gets automated is rarely the whole process, it is the handovers: order data into inventory management, approvals, notifications, documents.

The benefit appears twice, as saved time and as fewer errors, because retyping disappears.

The second part is usually the larger one and is rarely counted. A transposed digit in a retyped order number does not cost the two minutes of typing, it costs the query, the correction, the late shipment and the call from the customer. Anyone looking at the case economically therefore does not calculate with handling time but with volume times time plus error rate times rework cost.

The third effect is lead time. A transaction that passes through three pairs of hands waits between them. Fifteen minutes of work turn into two days of idle time, and that is what the customer feels, not the working time. So it pays to measure the process once with timestamps before anything gets built.

Clarifying comes before automating. Automate an unclear process and you cast every exception into code, and the exceptions are what makes up the effort. Which special cases really exist, and which of them occur once a year, is answered by the business team in a two hour conversation. Some special cases also disappear on that occasion, because they come from a rule nobody has needed for years.

When building, the most important decision is what happens to the cases that do not run through. They need a visible place, a responsible person and a deadline. Without that return path, failed cases pile up unnoticed until someone asks where an order has gone, and by then there are three hundred of them.

Technically the rule is: every step has to be repeatable without a double effect. Networks fail, target systems do not respond, a transaction gets triggered again. Without idempotency this produces duplicate bookings, and that costs more trust than the automation saves in time.

And finally the workflow needs metrics. How many transactions run through, how many drop out, how long it takes. Without those three numbers nobody knows whether the automation still does its job or has been writing half of everything into an error list for six weeks.

How you notice it

People copy data from one system into the next.
The same procedure runs identically every week.
Errors occur at handovers, not inside the systems.
There are hours or days of waiting between the processing steps.
A spreadsheet serves as intermediate storage between two systems.

Not to be confused with

RPA: Operates user interfaces like a human. Quick to introduce and brittle, because every layout change breaks it. Only sensible where a system has no interface.
Workflow orchestration: The control of multi-step workflows with state, retries and deadlines. The tool with which more demanding automation gets built.
Straight-through processing: The goal, not the means: the share of transactions that runs through without human intervention.
Integration: Connects two systems technically. Automation builds on top of that and models the workflow logic with rules, approvals and exceptions.

When it fits

The workflow happens often and at its core always runs the same way.
The rules can be stated, even if there are exceptions.
Errors occur at handovers, not inside the business systems.
The waiting time between the steps is longer than the working time.

When it does not

As long as the process is unclear in business terms: clarify first, then build.
For rare transactions where handling them is cheaper than maintaining the automation.
When every case needs a judgement: then you automate the groundwork, not the decision.
When one of the systems involved is about to be replaced anyway.

How to approach it

Measure the workflow with timestampsVolume, handling time, waiting time, error rate. Without those numbers the benefit is a claim and the success cannot be proven later.
Ask for the special cases and sort them outTwo hours with the business team. Some exceptions come from a rule nobody needs any more and disappear on that occasion.
Start with a workflow that happens oftenNot with the most complicated one. The first automated workflow has to visibly work, otherwise there will be no second one.
Build the exception path firstWhere cases that do not run through end up, who is responsible, by when. Without that place they pile up unnoticed.
Make every step repeatableIdempotency and retries with growing intervals. Target systems do not respond, and the second attempt must not book twice.
Make three metrics visibleCompletion rate, exceptions, duration. They show whether the automation still does what it is supposed to do.
Measure again after four weeksThe same numbers as at the start. That is the basis for the next workflow, and without evidence there will not be one.

Frequently asked

Where do I start?

With the step that happens often, has clear rules and produces errors today. Not with the most complicated one. The first automated workflow has to work, otherwise there will be no second one, regardless of how good the technology was.

How do you calculate the benefit?

Volume times handling time plus error rate times rework cost, and lead time as a figure of its own. Pure time saving regularly underestimates the case, because the expensive consequences of a transfer error, meaning the query, the correction and the late shipment, are not part of the handling time.

What happens to the cases that do not run through?

They need a visible place, a responsible person and a deadline after which somebody gets reminded. An error list without ownership is not an exception path, it is a filing spot. This is exactly where it is decided whether the automation is still trusted six months later.

Do you need a platform for this?

Rarely for the first workflow. Two interfaces and a scheduled run are often enough. An orchestration platform pays off from the point where workflows become multi-step, hold state across days, need retries and deadlines, and you run three of them instead of one.

What about RPA?

A stopgap when a system has no interface and nothing can be changed about that. It is quick to introduce and breaks with every layout change. Wherever an interface exists or can be built it is the worse choice, because it shifts the effort from building into maintenance.