Practical insights for operational improvement and transformation delivery.

Automation is often framed as a shortcut to efficiency. In reality, it is a multiplier. If the underlying process is clear, well-owned, and governed properly, automation can improve throughput, consistency, and visibility. If the underlying process is confused, full of workarounds, and dependent on tacit knowledge, automation usually hardens the problem.

Why process quality matters first

Most organisations do not suffer from a lack of tools. They suffer from unclear process design. That usually shows up in familiar ways:

• handoffs that rely on email or memory
• approval paths that are not consistently followed
• exceptions that only a few experienced people know how to handle
• duplicated checks that no one can explain
• unclear ownership when something goes wrong

When these conditions exist, automating the workflow may increase speed, but it does not improve control. It simply makes the same weaknesses harder to see and more expensive to unwind later.

The real role of automation

Good automation does three things well:

• removes unnecessary manual effort
• improves consistency in repeatable tasks
• increases visibility into what is happening and where work is getting stuck

That only works when the process has already been clarified to a reasonable level. Teams need to know what the workflow is supposed to do, who owns it, what the exceptions are, and what success actually looks like.

What to examine before automating

Before any automation initiative moves ahead, four questions matter:

1. Is the process itself worth preserving?

Some workflows should be redesigned before they are automated. If the current way of working is fragmented or outdated, automation should not be used to preserve it.

2. Are ownership and decision rights clear?

If no one clearly owns a process, automation will not solve the accountability gap. It often makes it worse because the workflow appears more formal than it really is.

3. Are the exception paths understood?

Many workflows look straightforward until edge cases appear. The automation design must account for real operational exceptions, not only the ideal path.

4. Is the intervention proportionate?

Not every process needs the same treatment. Some problems need better workflow design. Others may need RPA, low-code enablement, decision support, or no automation at all.

A better sequence

For most organisations, the stronger sequence is:

1. understand the current workflow
2. simplify or redesign the process where needed
3. clarify controls, ownership, and exception handling
4. choose the right automation intervention
5. support implementation with delivery discipline

That is slower than jumping straight to tooling. It is also far more likely to produce an outcome that lasts.

The QIESI view

QIESI's position is straightforward: automation should support a better operating model, not disguise a weak one. The highest-value work often starts before the technology decision, when leaders need clarity on how work should flow, what needs to change, and where automation can genuinely improve performance.

Enterprise teams often use BPM, RPA, and AI in the same conversation. That makes sense, because all three can influence how work gets done. It also creates confusion, because they solve different kinds of problems.

BPM: design the work properly

Business Process Management is about understanding, improving, and governing how work flows through the organisation. It focuses on questions such as:

• What is the process meant to achieve?
• Where are the bottlenecks and delays?
• Who owns each decision and handoff?
• Which controls matter?
• Where is the process breaking down?

BPM is the discipline that gives structure to operational change. It helps teams move from intuition and workaround culture to a clearer operating model.

RPA: automate structured repeatable work

Robotic Process Automation is useful when tasks are:

• rule-based
• repetitive
• stable enough to script reliably
• spread across systems that do not integrate cleanly

RPA is effective in the right situations, but it is not the same thing as process redesign. It automates specific actions. It does not by itself decide whether the process should exist in its current form.

AI: support judgment, classification, and decision quality

AI is useful where work involves interpretation, pattern recognition, prediction, summarisation, or dynamic decision support. In operations, that may include:

• triaging requests
• classifying documents
• summarising cases
• suggesting next-best actions
• identifying risk or anomalies

AI is not a replacement for BPM or RPA. It complements them when parts of the workflow require reasoning or judgment that goes beyond scripted logic.

Where the combination makes sense

In a mature transformation approach, the disciplines work together.

BPM defines and improves the process

This gives teams clarity on what the workflow is meant to do, where value is created, and what needs fixing.

RPA handles stable, repeatable execution steps

This removes friction from structured work that does not require meaningful judgment.

AI supports variable or knowledge-heavy parts of the workflow

This is where classification, recommendations, document interpretation, and decision support become relevant.

Why the distinction matters commercially

When these disciplines are confused, organisations make poor investment decisions. They buy tools before defining the process problem. They deploy automation where the real issue is process design. Or they use AI as a label for work that simply needs better workflow structure.

Leaders need a clearer way of thinking:

• BPM is about the operating design
• RPA is about structured task automation
• AI is about augmenting or improving judgment and analysis

The practical takeaway

These disciplines are strongest when they are sequenced intentionally. Teams should begin by understanding the process, then decide where workflow redesign, automation, or AI-enabled support are actually appropriate. That is the path to better decisions and more dependable execution.

AI in operations is often discussed in terms of speed, productivity, and transformation potential. Those benefits may be real. They are not sufficient as a deployment model. If an AI capability is going to influence work, decisions, or customer outcomes, governance has to be designed into the operating model from the start.

The wrong starting question

Many organisations begin with: "Where can we use AI?"

That question is too broad to be useful. A better starting point is:

What decisions or activities would be influenced, and what controls are needed if the model is wrong, incomplete, or misused?

That shift changes the quality of the conversation immediately.

Five governance questions leaders should ask

1. What is the AI actually allowed to do?

There is a major difference between:

• generating suggestions for a human to review
• classifying work for triage
• recommending actions
• triggering downstream execution automatically

The level of autonomy matters. Governance should match it.

2. Who remains accountable for the outcome?

AI does not remove accountability. Someone still owns the process, the risk, and the operational consequences. That accountability must be explicit.

3. What is the human oversight model?

Human-in-the-loop is often mentioned casually, but it needs definition. Leaders should clarify:

• when human review is required
• who performs that review
• what thresholds trigger escalation
• which cases are too sensitive for unattended execution

4. How will decisions be monitored and audited?

Operational AI cannot become a black box. Teams need visibility into:

• what inputs were used
• what output was produced
• whether human overrides happened
• where errors, drift, or inconsistency are appearing

5. What happens when the model is wrong?

All operational systems need failure handling. AI-enabled workflows are no different. Recovery paths, exception handling, and fallback decisions need to be designed deliberately.

Why this matters for agentic automation

The governance challenge becomes sharper when organisations move toward more autonomous workflows. Agentic systems are appealing because they promise adaptation and initiative. They also increase the need for boundaries, escalation logic, and operational controls.

Without a clear governance model, agentic automation can create decision ambiguity rather than decision quality.

A more credible way forward

AI in operations should be treated as part of an operating design question, not only as a technology rollout. The organisations that benefit most are usually those that:

• define clear process boundaries
• separate judgment support from full autonomy
• build in oversight and auditability
• treat implementation as a governance and delivery challenge, not just a product choice

That is the difference between experimentation and responsible operational adoption.

Transformation programmes rarely fail because leaders lack ambition. They stall because the organisation cannot turn intent into coordinated execution. The strategy deck is approved, the themes sound right, and the target state is broadly understood. Then progress slows, ownership fragments, and delivery confidence begins to erode.

Where the stall usually begins

The most common breakdowns are not mysterious. They tend to show up in predictable forms:

• too many initiatives launched at once
• weak sequencing across interdependent workstreams
• unclear decision rights between business and technology teams
• insufficient delivery governance
• unrealistic expectations around change absorption

These are not minor project-management issues. They are operating model issues.

Strategy is not yet execution

A transformation strategy can define direction, ambition, and themes. It does not automatically answer:

• what changes first
• what dependencies matter most
• which capabilities need to be built internally
• how work will be governed across functions
• how progress and risk will be measured

Without those answers, teams often continue to move, but not in a coherent way.

Three patterns that create drag

1. Priority inflation

If everything is urgent, almost nothing is truly prioritised. Programmes stall when organisations keep adding initiatives without reducing scope elsewhere.

2. Ownership gaps

Transformation work often spans business, operations, data, technology, and governance. If ownership is dispersed without clear authority, delivery slows and escalations become political.

3. Delivery structure that is too light for the complexity

Large change programmes need more than enthusiasm and status meetings. They need practical governance, sequencing, risk visibility, and enough implementation discipline to keep work moving.

A better way to think about transformation

Transformation should be treated as a portfolio of coordinated decisions and delivery movements, not as a slogan. That means:

• sequencing deliberately
• clarifying sponsorship and ownership
• linking initiatives to operating outcomes
• designing governance that fits the level of complexity
• managing implementation capacity honestly

Why this matters commercially

Most organisations do not need more transformation language. They need clearer execution structure. That is especially true when automation, AI, process redesign, and operating model change are all happening in parallel.

The work becomes more credible when leaders can answer a simple question: how will this actually get delivered in a way the organisation can absorb?

That is where transformation either becomes real or remains theoretical.