Automation freezes the process

The problem it solves

A bad manual process survives because people quietly correct it. The invoice comes out wrong and somebody redoes it, the redundant step gets skipped when the day is busy, the missing figure is chased down by phone. That invisible correction is what keeps a lot of operations afloat, and it disappears the day the process is automated.

Once automated, the same process stops being a habit and becomes a rule. It runs faster, it produces more of whatever it was producing, and nobody corrects it any more, because correcting it now means asking someone to change something that has configuration, permissions and a technical owner. What used to be settled in the corridor becomes a request in a queue.

There is a second effect, slower and more expensive. The automated process becomes the company's official description of how it works. New people are trained on it, reports are built on top of it, other things are connected to it. Every month that passes raises the cost of admitting the original design was wrong.

What it covers

The workshop works on a real process from each participating company, before any configuration exists. The first part puts it in writing as it is today, not as it should be, with its steps, its waits, its decisions and the exceptions the person running it resolves from memory.

The second part redesigns it. Steps that exist for a reason that no longer applies are removed, steps split apart to suit somebody nobody now remembers are rejoined, the question of what information enters and when is settled, and the decisions that today rest on judgement become written rules wherever that is possible. This part is uncomfortable: it forces two areas to agree in front of everyone on who does what and with what authority.

The third part defines what has to be fixed before automating and what is deliberately left flexible, because a process still in motion should not be frozen. No tools or vendors are evaluated here. What is delivered is a design that any implementation would have to respect.

What participants learn

• Document a process as it runs today, including its waits and its exceptions.
• Separate the steps that add value from the ones that outlived their reason.
• Turn decisions that rely on whoever is on shift into rules that can be written down.
• Judge whether a process is stable enough to be automated at all.
• Hand over a process design that works as a requirement for whoever implements it.

Agenda

1. 01Mapping the real process: what is done, not what is supposed to be done
2. 02Steps that exist because of a problem already solved
3. 03Waits, handoffs and the points where work changes hands
4. 04Judgement calls: which can be written as rules and which cannot
5. 05Exceptions: designed out, designed in, or deliberately left to a person
6. 06What has to be stable before a design is fixed in place
7. 07The cost of changing an automated process against a manual one
8. 08The design document whoever implements should receive

What the organisation leaves with

• A written map of the current process, with steps, owners, waits and exceptions.
• A target process design, with the decision rules written out.
• A list of what is fixed and what stays flexible, with the reason for each.
• A requirements document that can be handed to any implementer.