Automation

Typical starting situations

• A case is handled the same way every week and costs the same half hour each time.
• Data is copied by hand from one system into another.
• Deadlines are missed because nothing reminds anyone of them.
• An approval depends on one person who happens to be unavailable.

How we work

First the process is broken down into its triggers, rules and exceptions. The trigger is usually found quickly; the work is in the exceptions — and they decide whether an automation holds up in everyday use or is worked around after two weeks.

Automation then proceeds in stages: first a step runs alongside the existing process, then requires human confirmation, and finally runs independently. At each stage we define where a person takes over. That handover is part of the design, rather than an improvised response to failure.

What can come out of it

Not every engagement covers all of these. What is produced depends on the undertaking and is agreed beforehand.

What matters here

An automation is only as reliable as the data it reacts to. A field that is sometimes filled and sometimes empty becomes an exception — and exceptions are the most expensive part of any automated process.

Second, it must remain traceable what happened and why: without a log, an automation is opaque when something goes wrong, and the trust it has just built is gone with a single incident. Third, whatever runs automatically must also be possible to stop.

Where this ends

Automation removes repetition. If the process itself is still unclear or scattered across several tools, the work belongs in digitalization first — automation without structure only moves the problem.

If the process needs an application of its own rather than connecting existing systems, software development is the field.