Fix the process before you automate it

A familiar request reaches every operations leader sooner or later: "Can we automate this?" The honest first answer is another question. Which version of "this"? The one in the procedure manual, the one the team in Kigali follows, or the one the team in the regional office follows when the system does not allow what the customer needs?

Automation does not interpret intent. It repeats a sequence exactly, every time, at speed. If the sequence contains an unnecessary approval, a duplicate entry or a workaround that exists because an earlier system was poorly set up, the automated version contains them too. It simply completes them faster and, usually, more expensively to change.

76%

of leaders say their current processes are holding them back (Celonis, 2026)

58%

say their departments do not operate seamlessly together

82%

expect AI to fail to deliver a return if it does not understand how the business runs

What the 2026 evidence shows

In February 2026 Celonis published research based on 1,649 business leaders across supply chain, finance, operations and IT. The ambition was striking: 85% wanted their organisation to become what the report calls an agentic enterprise, with AI agents carrying out work, within three years. The condition of the foundations was less encouraging. Seventy-six per cent said their current processes were holding them back, and 58% of process and operations leaders said their departments did not operate seamlessly together.

The leaders drew the connection themselves. Eighty-two per cent of decision makers said AI would fail to deliver a return on investment if it did not understand how the business runs. The two most-cited barriers to AI success were limited internal expertise (47%) and the difficulty of getting AI to understand business context (45%). Celonis's president Carsten Thoma described organisations as "struggling to translate that ambition into tangible ROI right now".

Why the order of work matters

BCG's May 2026 analysis found that about 70% of corporate transformations still fail and located the cause in the gap between what leaders intend and what people experience. Automation projects are transformations in miniature, and they fail in the same place. The tool is installed, the team is trained, and the work continues to flow the way it always did, now with an extra system to feed.

There is also a cost argument. Every step in a process that is later automated becomes something to maintain: a rule to update when policy changes, an integration to repair when a supplier changes a file format. A step that should not exist is expensive to keep twice, once as work and once as configuration.

A sequence that works

1. Map the process as it really runs

Follow one hundred real cases, not the procedure document. Note where each one waits, who touches it, which fields are re-typed and which decisions have an obvious answer 95% of the time. Do this with the people who do the work. They already know where the process is broken; they have rarely been asked.

2. Remove before you improve

Ask of every step: does a customer or a control actually need this? Approvals added after a single past incident, reports nobody reads and second checks of a first check that is already reliable are common candidates. The cheapest step to run is the one you delete.

3. Standardise what remains

Agree one way of doing the work, one set of inputs and one definition of "done". Variation between people and branches is the single biggest enemy of automation, because every variation becomes an exception to be coded, tested and supported.

4. Automate the stable core, keep a path for exceptions

Automate the high-volume, rule-based majority and design the exception route deliberately: who receives it, how fast, with what information. An automation without a good exception route does not remove work; it moves it to the people least able to see the context.

5. Measure before and after

Record cycle time, error rate and cost per case before the change, using the same definitions afterwards. Without a baseline, the claim that automation "saved time" is an opinion.

Where automation should come first

None of this argues against automating. It argues for choosing well. Work that is already stable, high in volume and rule-based, such as routine data transfers between two systems or standard confirmations, can often be automated with little redesign. The rule of thumb is simple: if the team can explain the process in two minutes and agrees on it, it is a candidate. If the explanation takes twenty minutes and ends with "it depends", start with the process.

• Can the people doing the work describe the process the same way?
• Do we know the cycle time and error rate today?
• Has every step earned its place?
• Is there a named owner who can change the process?
• Do we know what happens to the cases the automation cannot handle?

When three or more answers are "no", the investment belongs in the process first. The technology will still be available in eight weeks, and it will pay for itself more reliably.

This is how we approach operations work at NURBIX: understand how the work actually flows, simplify it, and then choose the technology that fits the simpler process.