Enterprise process automation

The pilot worked. Four months on it is still a pilot, because it now has to meet three regions, a system nobody has permission to change, an audit function asking who approved what, and a process documented five years ago and done differently ever since. Enterprise process automation almost never fails in the demonstration; it fails in that gap.

Why pilots do not become production

The documented process is not the real one. The map says four steps. The team does seven, two of which exist to work around something in the system. Automating the map produces something nobody can use.
Access is the schedule. In a large organisation the technical work is rarely the long pole. Getting a service account, a test environment and a change window is. Any plan that does not name those dates is a plan that will slip.
Nobody owns the exceptions. Automation converts routine work into a smaller stream of harder work. If no team is funded to handle that stream, it silently reverts to the old way.
The audit question comes late. Six months in, someone asks what the system did, when, under which rule, and on whose authority. If the log was not designed in at the start, the honest answer is a rebuild.

What a build that survives looks like

Observation before design: what actually happens, including the workarounds, taken from the systems rather than from a workshop.
One process, end to end, in one region, in production — not five pilots. Something real and finished beats five things that nearly work.
The exception path designed first, with a named team and a service level. It is the part that decides whether this is still running next year.
A complete record from day one: input, rule version, decision, output, who could override and who did.
A monitor whose only job is to notice that the automation stopped, because in a large organisation nobody notices for weeks.

Where it should stop

Any decision about a person — hiring, performance, discipline — stays human, and in the EU that is not only good manners.
Anything committing money above a written limit. It prepares, a person approves, and the limit is per process, not global.
Anything a regulator can ask about, without an explainable basis recorded at the time.
Changing master data in a system of record without a review step. That is how a small error becomes an enterprise-wide one.

Not worth starting yet if

There is no executive owner who can clear an access request. Without that, the project is a queue.
The target system is being replaced within the year. Automate after the migration.
The process is genuinely rare — a few dozen times a year. Write it down properly instead; that alone will fix most of it.

The same patterns, at working scale

Advertising manager — the pattern at working volume: roughly 600 campaigns pulled from separate places, merged and judged every morning, each with a plain verdict on it — pull, join, decide, report, running unattended.
Systems watchdog — the part large organisations skip and pay for: a monitor whose only job is to notice the moment something stops running, and say so the same day.

The questions that decide a programme

Is enterprise process automation the same as RPA?

RPA is one technique — driving a user interface when no proper interface exists. It is legitimate and it is brittle, because it breaks whenever a screen changes. Use it where nothing better is available, and prefer a real interface everywhere else.

Why do so many of these programmes stall?

Because the pilot proved the technology and the production rollout runs into access, exceptions, audit and the gap between the documented process and the real one. None of those are technical problems, and all of them can be planned for.

How do you handle a process that differs by region?

Build the common spine and treat the differences as configuration with named owners. Building five variants is how a programme becomes unmaintainable in its second year.

What size of organisation is this for?

The patterns apply from a few hundred people upwards. Below that the constraint is usually one team's time rather than access and governance, and the honest advice is a smaller, faster build.

Who does this work if it is one person and a set of AI systems?

The delivery is a small number of people using AI systems that do the heavy lifting, which is why one process reaches production faster than a large team gets its access approved. What you do not get is a programme office, and for most first builds that is the point.

The three answers that decide the timeline

Who can clear an access request without a committee. Which team will own the exceptions once the routine work disappears. And whether the target system is being replaced within the year. Those decide whether a first process reaches production in weeks or never, and none of them is technical. Bring them, plus one process and its real volumes, and the free hour will settle whether it is worth starting.

Book that hour →