Map processes before you automate

Most automation projects start from the wrong question. Instead of asking how this process should work, the owner asks which tool solves it. The result is predictable: technology arrives, faithfully replicates a confused operation, and delivers a faster version of the same mess. The step that avoids that waste is not technical, it is about clarity. It is called process mapping, and it comes before any automation.

The cost of automating a mess

There is a line attributed to Bill Gates that captures the problem with uncomfortable precision. In The Road Ahead (1996) he writes: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency."

Automation does not correct a bad process. It accelerates it. If a process carries rework, redundant steps and badly defined responsibilities, automating it simply makes those problems happen faster and at greater scale. You trade a manual inefficiency for a systematised one, now harder to see because it is hidden inside an automated flow.

Shell, structuring its finance operation for robotic process automation, adopted a blunt principle about this: RPA is not the solution to a badly designed process. Technology joins at the end of the queue, not the beginning.

Automation does not solve a shortage of clarity. It amplifies whatever it finds.

What process mapping is

Process mapping is the exercise of describing, end to end, how work actually happens today. Not how the manual says it should happen, but how it happens in practice, with all the exceptions, waits and informal shortcuts the operation has accumulated over time.

A good process map describes the steps in a flow and connects each one to the people involved, the materials and information needed, and the resulting products or services. In practice, mapping means making six elements visible:

• Inputs. What triggers the process and what it needs to start: an order, a document, a piece of information, an approval.
• Activities. The steps carried out, in the real order they happen.
• Owners. Who does each step. This is where the grey zones appear, the ones where nobody is quite sure who is responsible.
• Outputs. The result delivered at the end, and to whom.
• Bottlenecks. The points where work stalls, waits or piles up.
• Rework. The steps that exist only to correct errors created in earlier steps.

When those six elements become visible, the process stops being an intuition in the owner's head and becomes an object you can examine, question and improve. It is that visibility, not the tool, that makes automation possible.

Notations: from sketch to executable design

There are several ways to represent a process. There is no single right one; there is the one appropriate to each moment. The three most useful for a company in transformation are:

SIPOC provides the frame: it gives a broad view of the process before diving into detail, without yet mapping decision logic. The flowchart communicates well but loses precision when a process has many actors and branches. BPMN, Business Process Model and Notation, is a standard designed to be simple enough for the business team to follow and detailed enough for the technical team to build from. In practice, many projects start with a SIPOC to define scope, use a flowchart to communicate, and move to BPMN when it is time to automate.

One caution is worth stating now: mapping does not mean drawing the entire company in detailed BPMN before touching anything. Mapping every process at once tends to produce diagram repositories nobody reads. You map what you are going to improve, to the depth needed to decide.

The order that changes everything: eliminate, simplify, automate

The map does not exist to look good. It exists to support a decision. And the most important decision a map enables is the order in which you act on the process.

The process improvement field consolidated that order into a simple principle: eliminate, simplify, standardise and only then automate. The central rule is direct: never automate something that could be simplified or, in some cases, removed entirely.

The logic runs as follows.

1. Eliminate. The first question in front of each step is not how do I automate this, it is does this need to exist. A great deal of activity is there through inertia: an approval nobody reads any more, a report nobody uses, a check that duplicates another. What you eliminate, you do not need to simplify or automate. It is the cheapest gain and the most ignored.

2. Simplify. Whatever survived the previous stage needs trimming. Steps combined, exceptions reduced, paths shortened. A simplified process is cheaper to run and far cheaper to automate, because there are fewer rules to encode and fewer exceptions to handle.

3. Automate. Only now does technology enter, and it enters onto clean ground. Shell observes that without prior simplification and standardisation, automations are harder and slower to build, and they do not scale. Automating last is not excessive caution; it is what makes the automation durable.

The process map is what makes that order possible. Without it you cannot see what could be eliminated, you do not know what is duplicated, and you end up automating the waste along with the value. With it, each step in the flow passes through a filter before receiving technology: should this be eliminated, simplified or repeated as it is.

The challenge is not creating more solutions. It is building the right solutions, in the right order.