Process mapping for automation: before you buy anything

How are the hours a process really costs measured?

Not by asking. You sit beside the person who runs the process today and watch it while it happens: sitting with the collections manager while she sends out letters, counting the steps, asking what happens when a customer is missing from the system. A spoken estimate is almost always lower than reality, because it counts the action and not what surrounds it.

Four things are measured, and only the first is the one people think of:

• The run time itself. How many minutes one pass through the process takes, start to finish.
• Frequency. How many times a month. A five-minute process that runs forty times costs more than an hour-long process that runs once.
• Setup time. Collecting the files, finding the password, waiting for a report somebody else produces. This is the time that appears in no estimate and usually equals the run time itself.
• The cost of correction. What happens when something comes out wrong, who finds it, and when. A process whose error surfaces a month later is far more expensive than the clock suggests.

At the end of this stage every process has a number, and no system has been touched yet.

The ranking method: how is the starting point decided?

Not by who complains loudest, and not by what is easiest to build. Every measured process passes through five questions, in this order, and a negative answer to one of the early ones stops it before the rest are asked.

1. Can the rules be stated in words? If you cannot explain in plain language when the process does what, there is nothing to automate. This is the first gate and it rejects the most.
2. Is the data reliable? If a field is left empty whenever filling it is inconvenient, there is nothing to cross-check and nothing to alert on. The input is fixed first.
3. Does it repeat enough? A process that runs once or twice a year almost never justifies building and maintaining it.
4. How much does it return? This is where the number from the measurement enters. The return is run time plus setup plus cost of correction, multiplied by frequency.
5. What is left for a person? A process that is entirely judgement does not pass. A process whose preparation repeats and whose final decision is human is an excellent candidate: the material is prepared, a person signs the decision.

You start with one process, the one with the highest return that cleared all five questions. One, not three in parallel. A process that runs and proves itself is also what decides whether there is a second.

When the recommendation is to cancel the process rather than automate it

Automating an unnecessary process does not remove it. It only makes it happen faster, at a standing maintenance cost, and with nobody asking again whether it is needed. Three cases where our recommendation was to cancel:

• A report nobody opens. Before making the production of a report more efficient, you check who reads it and what they do with the numbers. A report nobody opens does not need to be created faster, it needs to stop being created.
• A process that exists to compensate for a fault somewhere else. If a value is typed twice because one field is not synchronised, the fix is in the field. Automating the double entry preserves the fault permanently.
• A process that exists for a reason that no longer applies. This surfaces during the measurement, when it turns out the requirement behind it was withdrawn two years ago and nobody stopped to check. Then the recommendation is to cancel rather than automate.

Some measurements end in the conclusion that the saving does not justify the investment, and that is a legitimate answer. This list is why the first stage is a measurement and not a quote.

What do you get at the end?

Three things, all of them readable without us:

• A map of the processes examined, each with the four measured numbers and the systems it touches.
• A priority order by the five questions, including what was rejected and at exactly which gate. What was rejected matters no less than what passed.
• An estimate of what each process is expected to return, and what building it requires: which permissions, which information, and who needs to be involved.

That document is worth having even if you do not continue with us. It is written so another supplier can work from it, and that is deliberate: a mapping usable only by whoever wrote it is not a mapping, it is a quote in disguise.

Where this sits in business process automation

Business process automation is the broad term, covering everything from a robot filling in forms to a full enterprise platform. Mapping is the stage that precedes all of them, and it is identical in all of them: knowing what the process does today and what it costs, before deciding what to solve it with.

The order is also a priority: measure, simplify, and only then automate. A process that can be simplified does not need automation, it needs simplifying, and that surfaces during mapping rather than after something has been built. What happens after the mapping is set out on the business process automation services page, and an example of a system pair such a mapping leads to is on the CRM to invoicing sync page.

Where to start

Pick one process that repeats and annoys you, and come with three details: who does it, how often, and where the information it consumes comes from. On our side you will be talking to Avishai, Tagula's founder.