Before You Automate It, Understand the Process

There is understandable excitement about what automation and AI can do for organisations.

Tasks that once took hours can potentially be completed in minutes. Information can be analysed faster. Routine administration can be reduced. Decisions can be better supported.

But there is a risk.

If we automate a process we don’t really understand, we may simply make a poor process run faster.

Over more than 30 years of working in operational improvement, I have repeatedly seen processes that look straightforward on paper but work very differently in practice.

There is the procedure.

And then there is what actually happens.

The difference between the two is often where some of the most useful improvement opportunities are hiding.

Start by making the work visible

One of the simplest ways to understand a process is to map it with the people who actually do the work.

Not the process somebody thinks happens.

Not the process described in a procedure written several years ago.

The process as it happens today.

Where does the work start?

Who does what?

Where does information come from?

Where does it go next?

Where does work wait?

Where does somebody have to chase for an answer?

Where is information copied from one system or spreadsheet into another?

Where does somebody perform an extra check because experience has taught them not to trust the previous step?

When you put the process in front of the people involved, something interesting usually happens.

The work becomes visible.

The workaround may have become the process

Many operational problems are not dramatic.

They develop gradually.

Someone creates a spreadsheet because the system does not provide the information they need.

Another person starts sending a reminder email because approvals regularly get delayed.

An experienced employee knows which jobs need to be pushed to the front of the queue.

A second check is introduced because errors keep appearing.

Initially, people recognise these things as workarounds.

But if the underlying problem is not fixed, the workaround gradually becomes normal.

Eventually people stop describing it as a problem.

They simply describe it as how the process works.

That matters when we start talking about automation.

If we automate the workaround without understanding why it exists, we may preserve the very problem we should have removed.

Not everything should be automated

A useful process-mapping discussion can help separate different kinds of improvement opportunity.

Some activities should simply be removed.

Some can be simplified.

Some need to be standardised so that people are working in a consistent way.

Some are good candidates for conventional digital automation.

And some may genuinely benefit from AI.

Those are not the same thing.

For example, if somebody spends several hours every week copying information from one system into another, automation may be the answer.

But if the information is being entered twice because nobody has questioned an unnecessary approval step, the better answer may be to remove the step.

Likewise, AI may be able to summarise customer enquiries, analyse maintenance records or help classify information.

But that does not mean AI should be the starting point.

The starting point is the work.

Ask a better question

Instead of asking:

“Where can we use AI?”

I think a better sequence is:

Where is the loss?

Where are we losing time, capacity, quality or management attention?

Where is the risk?

Where are we relying on individual knowledge, inconsistent processes, poor hand-offs or workarounds that could fail?

Where is the opportunity?

What could we remove, simplify, standardise, automate or support differently?

Only then should we ask:

Could technology or AI help here?

That sequence changes the conversation.

Technology becomes a possible countermeasure rather than the objective.

Involve the people closest to the work

There is another important reason to map the process before changing it.

The people doing the work usually know things that are invisible in reports, procedures and system diagrams.

They know which customer requests cause problems.

They know which information routinely arrives incomplete.

They know the spreadsheet nobody talks about.

They know the shortcuts that keep things moving.

They know which part of the process causes frustration every Friday afternoon.

That knowledge matters.

A good process-mapping workshop is therefore not somebody standing at the front of the room drawing a flowchart for everyone else.

It is a structured conversation in which the people who understand the work make the current process visible together.

That shared understanding is often as valuable as the map itself.

From map to improvement

The objective is not to produce a beautiful diagram.

A process map is useful only if it helps us make better decisions.

Once the current state is visible, we can begin asking:

Where is the work waiting?

Where do hand-offs create delay?

Where is information duplicated?

Where does rework occur?

Where are responsibilities unclear?

Which activities genuinely add value?

Which activities exist simply because they have always existed?

What should the process look like in the future?

The output might be a future-state map.

It might be a short list of improvement priorities.

It might be one problem that needs deeper investigation.

Or it might identify a genuine automation or AI opportunity worth testing.

Improvement still needs follow-through

Mapping a process does not improve it by itself.

The real work begins when changes are tested.

That is why I like a simple Plan–Do–Check–Act approach, with deliberate follow-up after implementation.

At 30 days, what is working and what is getting in the way?

At 60 days, is the new process becoming the normal way of working?

At 90 days, have we achieved the result we expected, what still needs adjusting, and what have we learned?

Very few changes are perfect first time.

The important thing is to keep learning and adjusting rather than treating implementation as the finish line.

Understand first. Automate second.

There are enormous opportunities for organisations to use digital tools and AI more effectively.

But the organisations that get the most value from them will not necessarily be the ones using the most technology.

They will be the ones that understand their work well enough to know where technology genuinely adds value.

Before you automate a process, make it visible.

Understand how the work really happens.

Remove what does not need to be there.

Simplify what has become unnecessarily complicated.

Standardise what needs to be consistent.

Then decide what should be automated — and where AI might genuinely help.

Understand the process first. Technology comes second.

---

Richard Steel works with organisations on productivity, process improvement and capability development.

Process Mapping for Improvement is a practical workshop designed to make work visible, identify where performance is being lost and agree what to improve.