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. The symptoms arrive quickly: a spreadsheet running alongside for the cases the system does not cover, manual fixes after the process has supposedly finished, and a list of pending changes that grows faster than anyone can work through it.

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, and the organization ends up adapting itself to its own mistake instead of correcting it.

What it covers

The workshop deals with the work that happens before any tool, because it is the only moment when changing a process is still cheap. Changing a manual process costs a conversation; changing an automated one costs a request, a test, an implementation window and sometimes a contract. That is why it 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. Where it is not, that gets said. Every exception is given one of three destinations: designed out, designed in, or deliberately left with a named person. This part is uncomfortable: it forces two areas to agree in front of everyone on who does what and with what authority.

The method is practiced rather than described. Each participant works on their own map and puts the same question to every step, what would break if it disappeared tomorrow, which is the quickest way to separate what adds value from what survives on inertia. New rules are tested against recent cases the participant remembers, and a rule that fails the first real case is rewritten on the spot.

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. The result is a design that any implementation would have to respect: the current and target processes in writing, the decision rules spelled out, the reason behind everything fixed or flexible, and a requirements document that can be put in the hands of whoever builds it. That design belongs to the operation, not to whoever ends up implementing it, which is the principle behind ALUD's work in Operations.

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. 07Testing the design with one ordinary case and two difficult ones
8. 08The cost of changing an automated process against a manual one
9. 09The design document whoever implements should receive

What the organization 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.