Process automation
Automating business processes: a five-step method
From process mapping to measuring results: how to choose what to automate and with which tools.
In almost every company there are people who spend hours copying data from an Excel file into the ERP, rebuilding the same report every month, forwarding emails from one office to another. Automating these tasks is one of the investments with the clearest return – as long as you start from the process, not from the tool. This is the method I follow.
1. Map the process as it is
The first step is to describe the real process, not the one written in the procedures. You do it by talking to the people who run it every day and noting, for each activity:
- who does it and when (daily, at month end, on request);
- inputs and outputs: where the data comes from and where it ends up;
- systems involved: ERP, CRM, spreadsheets, email, external portals;
- time spent and most frequent errors;
- exceptions: the "special" cases that require a decision.
This phase alone often reveals useless steps, duplicated checks or data entered twice. Before automating a process it pays to simplify it: automating an inefficient process just makes it inefficient faster.
2. Choose what to automate
Not everything should be automated, and not all at once. To prioritize activities I use four criteria:
- frequency: how often it repeats;
- time: how long it takes each time;
- error risk: how costly a mistake is;
- clarity of the rules: how easy it is to describe what must be done.
Frequent, time-consuming, error-prone activities with clear rules are the ideal candidates. Rare activities full of exceptions can wait, or receive only partial support.
3. Pick the right tool
The tool depends on the kind of activity and on the systems involved. In order of preference:
| Approach | When to use it |
|---|---|
| Direct integration via API or database | When systems expose APIs or accessible data: the most robust solution and the cheapest to maintain. |
| Native platform workflows | When the ERP, CRM or LMS (for example Odoo, EspoCRM, Moodle) already offers configurable automations. |
| Scripts and scheduled jobs | For periodic processing: imports, exports, data quality checks, reports in Python, R or T-SQL. |
| RPA (user interface automation) | Only when a system offers no other way in: it is fragile when the interface changes. |
| Artificial Intelligence | When the input is unstructured (emails, documents, free text) or a first judgment is needed that a person will then check. |
In real projects these approaches are combined: an AI agent can read an order received by email and extract its data, while posting it to the ERP goes through an API integration with precise, verifiable rules. I go deeper into this in the article on AI agents for SMEs.
4. Design for exceptions
An automation works well on day one; its value shows on the day something goes wrong. That is why, from the design stage, I plan for:
- readable logs of every run, with what was done and on which data;
- repeatability: re-running a step must not create duplicates;
- clear notifications when a case cannot be handled automatically;
- a work queue for people, where exceptions to be resolved by hand end up;
- traceability, essential in regulated contexts such as finance, insurance and public administration.
5. Measure and improve
Thanks to the initial mapping you know the starting times and errors: after automation you measure them again. Useful indicators are simple – time per case, number of errors, cases handled without manual intervention, waiting times – and should be reviewed periodically. Every automation needs an owner and essential documentation: what it does, which systems it depends on, whom to alert if it stops.
Recurring examples
- Periodic reports assembled by hand from several sources, replaced by a scheduled SQL extraction and processing in Python or R that always produces the same format.
- Master data kept in sync between CRM and ERP, instead of entering the same customer in two systems.
- Incoming requests by email or web form, classified and turned into cases in the management system.
- Data quality checks run every night, with a list of anomalies to review in the morning.
In short
Process first, tool second: map, simplify, choose carefully, design for exceptions and measure.
When automation has to talk to older applications, it is worth tackling the evolution of the existing software as well: I cover this in the article on modernizing a legacy .NET or Java system.