Author: Oliwier Szachniewicz • • 5 min read
The short answer
Start with one process that repeats every week, has a clear beginning and end, and whose cost you can already count in hours. Not with a tool, not with a model, not with a list of twenty ideas. The order that works for us is a workshop, a pilot on a narrow slice, and only then a rollout across the company.
Why you do not start with the tool
Most conversations about automation open with the question of which tool to use. That question comes too early. A tool can be swapped out in a week, while a badly chosen process can eat a quarter and return nothing.
Automation does not fix a process, it speeds it up. If a document circulates between four people today because nobody decided who approves it, the automation will simply make it circulate faster. Before anything gets wired in, the process needs an owner, an input and an output.
How to pick the first process
We look for a process that meets four conditions at once:
- it repeats at least a dozen or so times a month, otherwise the saving disappears into noise;
- it has a clear input and output, so it is obvious what triggers it and what the result is;
- it runs on rules, not on the judgement of one particular person;
- someone in the company is willing to own its result after the rollout.
A process that fails the fourth condition is out even when it passes the first three. Automation without an owner usually loses its effectiveness, because one exception after another goes back to manual handling and nobody is responsible for the rules the system runs on.
Measure the baseline before you change anything
Before the first change, write down three numbers: how many times the process runs in a month, how many minutes one pass takes and how many of those passes come back for rework. How long the measurement takes depends on how often the process runs, and the data it gathers is what later lets you judge whether the rollout paid off.
Without those numbers all you have is an impression. An impression is a poor argument in front of a board, especially when you have to defend the budget for the second stage. That is why we calculate the return on cases from your company, not on someone else's benchmarks.
Workshop, pilot, rollout
The workshop ends with a process map with the bottlenecks marked and a list of improvements ordered by potential value. Some of them are an organisational change rather than code, and we describe them that way.
The pilot takes one slice: one document type, one branch, one month. The goal of a pilot is not for it to work. The goal is to surface what does not work, before the cost of the mistake grows to the scale of the whole company.
The rollout extends the pilot to the rest of the organization only once the numbers from the pilot match the assumptions. If they do not match, we go back to the process map instead of stacking more automations on top.
A worked example: document flow at an engineering company
A large Polish engineering and design company in the energy sector had a process where technical documentation travelled by email between designers, quality control and the client. Nobody knew whose desk a given file was sitting on until someone asked outright.
We started with the measurement: how long one pass takes and how many documents come back for rework. The pilot covered a single document type. The automation took over registration, versioning and reminders, while the approval decision stayed with a person, because that decision carries professional liability.
The important stages of the process are logged, which makes controlling and analysing the course of a case easier. We widened the scope only after the pilot, once we could judge how the solution behaved on real documents.
When automation is the wrong call
There are situations where the honest answer is: not now. A process that will change next quarter because the company is replacing the source system. A process that runs three times a year. A process where every case is different and the rule simply does not exist.
In those cases a changed form, one shared template or deleting a step nobody reads will do more. That is a legitimate outcome of a workshop too, and we say so directly instead of selling a rollout that will never pay for itself.
What to do next
Pick one process and work out two numbers: how many times a month it runs and how many minutes one pass takes. With those two numbers a conversation about automation stops being a debate about technology and becomes plain arithmetic.