Should you automate a business process or fix it first?

A painful process is an obvious candidate for automation. It is also worth establishing why it is painful.

Otherwise, the business can spend money teaching a computer to repeat an avoidable mistake with impressive enthusiasm.

For owners and operational leaders considering software, workflow automation or AI, this article explains how to assess the work before selecting the technology. The objective is a better operational outcome, with a realistic account of implementation, maintenance and risk.

1. What happens when a bad process gets faster

A printer producing the wrong address labels does not become more useful when it doubles its speed.

The team simply runs out of envelopes sooner.

Automation can reproduce the logic, data and assumptions it receives. If those are wrong, increasing speed may extend the problem before anyone notices.

Begin by identifying what the process is meant to achieve and where it fails. Is the burden necessary work, duplicated work, a recurring correction or an unresolved policy choice?

Some processes can improve while being automated. The important point is to make the design decisions deliberately, rather than allowing the existing workaround to become the specification by default.

2. Define the outcome before shopping for a tool

“We need AI” describes a technology preference. “We need complete requests to reach the right specialist without manual copying” describes an operational need.

The second gives you something useful to compare products against.

Set out the result, users, inputs, expected volume and essential constraints. Include the situations in which the system must ask for help or stop.

Define a baseline before implementation: time, errors, customer impact and effort elsewhere. Without one, a demonstration can become the main evidence for investment.

A requirement should explain the problem sufficiently well that different solutions can compete. That may include process simplification, an existing system feature, conventional automation or AI.

3. Separate necessary work from avoidable toil

If someone spends every morning moving information between two systems, automation may help.

If neither system needs that information anymore, there is a cheaper option.

Google’s Site Reliability Engineering literature uses toil to describe recurring operational effort with characteristics including repetition, manual handling and limited lasting improvement. The idea is useful beyond software operations.

Identify whether the task should exist, whether it can be simplified and whether its inputs can arrive correctly at source. Remove unnecessary duplication before designing a faster route through it.

Be careful with controls and judgement. A repetitive-looking task may prevent a consequential error. Understand that purpose and design an equivalent safeguard where the method changes.

4. Examine exceptions before assuming the work is routine

A demonstration processes five immaculate examples. The actual inbox contains an attachment from 2014, three contradictory instructions and a photograph of a form taken on a bus.

This is where the specification becomes interesting.

Assess how consistently inputs arrive, how many variations occur and which cases require interpretation. Look at exceptions, not only the average route.

Deterministic rules can work well where conditions and responses are explicit. Probabilistic AI outputs introduce different testing and oversight needs, especially where an incorrect interpretation affects a customer or decision.

Define acceptable performance for the intended use, including who reviews uncertain outputs and how errors are detected. A process is not ready for unattended operation simply because the typical example looks straightforward.

5. Decide what to eliminate, simplify and automate

A useful design session can end with fewer steps rather than more software.

It may be disappointing for the person who had already named the transformation programme.

Separate decisions about the work from decisions about implementation. Eliminate tasks without a continuing purpose, simplify requirements where possible and connect information so it does not need repeated entry.

Then assess the remaining activities for automation suitability. Volume, stability, exception frequency, data quality and consequences all matter.

Include the people doing the work. They often know which apparently simple steps contain judgement and which complicated rituals exist only because two systems were never connected.

The resulting design should make the service easier to operate, rather than merely moving the same complexity behind a new interface.

6. Count the work required after the system goes live

Automation needs ownership. Someone must notice when a source file changes, permissions expire or the process starts sending polite nonsense.

“Runs automatically” is not an operating model.

Include implementation, testing, integration, support, monitoring and future change in the assessment. Consider failure detection, recovery, access and how the business will continue if the tool is unavailable.

These are lifecycle costs and dependencies. They can outweigh the benefit of automating a low-volume or frequently changing activity.

Assess released capacity separately from cash savings. Saving staff time only produces the intended benefit if the operation can use it, avoid additional expenditure or change its cost base accordingly.

7. Test whether the outcome improves

A faster first step can produce a larger queue at the next one.

The robot may be delighted with its performance. The specialist receiving its output may be less enthusiastic.

Test with representative work and compare the complete outcome. Include errors, returned items, exception handling, customer consequences and downstream effort.

Start with controlled exposure where appropriate, retain a workable recovery route and define who can approve wider use. The evidence should support that decision.

Our article on business backlogs explains why improving one activity does not necessarily improve the operation as a whole.

8. When external support is useful

If the business agrees that a process hurts but cannot agree what should replace it, buying a product can postpone the difficult conversation.

The conversation still arrives during implementation, usually at a less convenient price.

DeaconOps can help define the operational problem, assess the work and design a proportionate improvement. An Operational Diagnostic suits uncertainty about the cause; Improvement Projects support defined change and implementation.

Where specialist technical or security expertise is needed, that requirement should be identified in the scope.

Start a conversation before committing to technology if the desired outcome, exceptions or operating responsibilities remain unclear.

Questions about business automation

Should every manual process be automated?

No. Some tasks should be removed or simplified, while others involve valuable judgement or controls. Suitability depends on the work and its consequences.

Is AI always more capable than a rule-based workflow?

They serve different purposes. Explicit, stable rules may be better handled by conventional automation. AI may help with less structured work but needs appropriate evaluation and oversight.

What should we measure after implementation?

Measure the intended outcome alongside quality, exceptions, maintenance effort and downstream effects. Faster execution of one task is only part of the result.

---

About the author

Dean Cain is the founder of DeaconOps, with more than 15 years’ experience across operational delivery, leadership and regulated environments. Read about the DeaconOps approach.