When automation pays off

The short version of the calculation reads: time saved against implementation cost. It sounds reasonable and still leads regularly to decisions that turn out to be mistakes two years later. The reason is simple: the short version leaves out two figures, and both work against the company. On the benefit side it omits the difference between the time a workflow costs today and the time that genuinely becomes free after automation. On the cost side it omits the effort that arises after acceptance.

In full, the calculation consists of four items. On the benefit side stand the frequency of the workflow and the net time saved per case. On the cost side stand the one-off implementation including rollout, and the maintenance recurring in every following year. Both benefit figures should be measured rather than estimated. An estimate from the management level tends to be well off the values produced by a two-week tally sheet (project experience) — frequency is usually underestimated and time per case overestimated.

The measuring effort is modest. Two weeks of tally marks at the place where the workflow is actually carried out, plus a stopwatch on five to ten cases, produce sounder figures than any discussion in the meeting room. What matters is that measuring happens with the person who performs the workflow, not with the person who describes it.

The second common source of error is confusing gross and net time. A workflow that takes four minutes today rarely takes zero minutes after automation. A visual check remains, handling of the cases the rule set does not cover remains, and occasional troubleshooting remains. What belongs in the calculation is the difference, not the full previous duration.

On top of that comes the question of whether the time saved ever arrives as capacity. Two minutes spread across fifteen people and a whole day do not add up to a vacant position. They become less pressure, fewer hours of overtime and fewer mistakes — a real benefit, but one that does not show up in staff planning. If the calculation is presented to the management as a saving when it only delivers relief, the next project loses its credibility.

For the hourly rate: gross wages alone are set too low. A full cost rate covering wages, non-wage labour costs, workplace and downtime is appropriate. Official statistics put labour costs per hour worked in the private sector at more than 40 euros (Federal Statistical Office of Germany); for commercial administrative work in a mid-size company, a figure of that order is a defensible basis.

Maintenance is not a minor item, and it is missing from most quotations. The cause is not ill will but market logic: anyone who states maintenance honestly looks more expensive in a direct comparison than a provider who leaves it out. The company notices the gap in the second year, when a system update stops the workflow and nobody is contractually responsible.

Maintenance effort does not arise because the work was done badly. It arises because the environment changes. An automation connects systems that are developed independently of one another, and it encodes rules that the company also keeps developing. Each of these changes can trigger an adjustment.

As a planning figure, an annual maintenance share in the order of ten to twenty per cent of the implementation cost has proven workable (project experience), depending on how many third-party systems are involved and how often they change. If a workflow connects only two stable in-house systems, the figure sits at the lower end; if several external counterparts hang on it, closer to the upper end. Anyone unwilling to budget that amount should not build the automation — running one belongs to ongoing IT operations and not into the spare time of an already fully booked person.

There are workflows where the calculation works out and automation is still the wrong decision. Not every recurring workflow belongs in an automation, and that has little to do with technology. Three areas stand out in practice.

The first area is judgement calls. Goodwill on a complaint, assessing a late payment, deciding whether an order is accepted despite tight capacity — such decisions rest on knowledge that is in no data field. A rule set can imitate them, but it then encodes a snapshot that nobody can justify later. Where a decision has to be explained to customers, to staff or in an audit, the reasoning matters more than the speed.

The second area is workflows with a high share of exceptions. Every exception becomes a rule in the rule set, every rule increases the maintenance effort and the number of places where something can go wrong. Beyond a certain point the automation merely administers exceptions. A workable limit: if more than roughly a quarter of cases have to be reworked by hand, the automated path rarely carries (project experience). In that case the workflow should be simplified first and automated afterwards.

The third area is personal customer contact. Standard messages about dispatch, appointments or receipt confirmation are uncontroversial and expected. As soon as complaints, rejections, price changes or delays are involved, an automatically generated message quickly reads as a defensive posture. Here the automation saves minutes and costs trust built up over years. A usable dividing line: automate the information, not the relationship.

A negative result is a useful result. It prevents spending and directs attention to measures that deliver more in proportion. In many companies the biggest consumers of time lie not in missing technology but in duplicate data entry, inconsistent master data and workflows that out of habit contain steps nobody needs any more.

Before an automation is commissioned, the following alternatives are worth a look. They cost less, take effect sooner and generally need less maintenance. A process analysis first answers the question of which workflow is actually the most expensive — often a different one from the one named first in conversation.

The combination frequently gives the best ratio: simplify first, then measure, then automate the simplified workflow. The sequence is decisive, because an automated complicated workflow remains a complicated workflow — only harder to change.