Why the order matters
Every company with several departments has a list of processes someone would like to see automated: transferring orders into the ERP, checking incoming invoices, maintaining master data across several systems, the weekly report for management. The list is rarely the problem. It gets difficult because everything seems equally urgent, while budget, departmental time and IT capacity are limited.
If you start with the loudest request rather than the most worthwhile process, you often end up with a solution that works technically and changes little in everyday work. The order is therefore the first substantive decision in any automation project. Below we describe how we make it, and what must be settled afterwards so that an automation still runs reliably in its third year.
Three criteria: frequency, cost of errors, manual re-keying
Three questions have proven useful. They can be answered together with the departments concerned and IT, without an extensive study. Look at each process individually, not at whole departments.
The three questions for each process:
- Frequency: how often does the process run, and how many people are involved? A task that comes up daily in several departments carries more weight than a closing routine that takes one afternoon a month.
- Cost of errors: what happens when a value is transferred incorrectly? A transposed digit in a delivery address, a wrong price on an order, an incoming invoice recorded twice. What matters is less how often errors occur than what each one leads to: rework, complaints, credit notes and, at worst, an annoyed customer.
- Manual re-keying: where is data typed from one system into another, copied from an email into an input screen or passed on via an Excel list? Every such break costs time and invites errors.
A process that runs often, where an error is expensive and where data is transferred between systems by hand belongs at the top of the list. If only one of the three criteria applies, a better template or a clear responsibility is often enough.
Typical candidates to start with
Which processes come first depends on the company. Good candidates share one trait: the data already exists in structured form in one system and is entered again in another.
Examples of such processes:
- Orders that are transferred from a web shop, a customer portal or an email into the ERP.
- Master data such as products, prices or customer addresses that is maintained in parallel in several systems.
- Reconciliations between sites or group companies that currently run via exported lists.
- Reports that are compiled by hand from several sources every week.
- Status updates for customers or field staff that someone reads off one system and passes on.
In all these cases the information already exists. Nobody has to decide anything new; it is simply transferred. That is where automation is most reliable, because the rules are clear and the result can be checked. Processes that require human judgement, such as assessing a complaint, do not belong at the start.
Interfaces instead of retyping
Once it is clear which process comes first, the next question is how. In most cases the robust answer is an interface. Instead of a program operating the input screens the way a person would, the systems exchange their data directly: via a documented API, via database access with clearly limited permissions, or via a defined file exchange.
The difference rarely shows on the first day, but at the first update. An interface transfers fields, not screen content. It stays stable when a system’s screens change and can be secured with automated tests that check with every change whether the transfer is still correct.
For a window manufacturer, we look after software that has been in daily use since 2022. It includes a nightly ERP reconciliation across 11 sites, and the software is safeguarded by around 6,000 automated tests. Such a reconciliation only lasts for years if it is clear beforehand which system is authoritative for which field.
Logging and error cases are part of the job
An automation that works in the normal case is only half the work. The other half is what happens when something does not fit: a mandatory field is missing, a product is unknown in the target system, the other side does not respond.
Before building, settle for every automated process:
- Logging: every run is recorded: what was transferred, when and with what result. Questions can be answered without digging through the code.
- Error cases: a record that cannot be processed is not silently skipped but set aside visibly, with an understandable reason.
- Notification: it is defined who is informed of an error and by when a response is needed.
- Retry: a corrected record can be processed again without creating duplicate entries.
These points sound like detail work, but they decide whether the department trusts the automation. If an error slips through unnoticed even once, people go back to checking by hand, and the automation no longer saves anything.
Automate first what runs often, is expensive when it goes wrong and is retyped today.
Responsibility in operation
Every automation needs both a business owner and a technical owner. The business owner decides what is right in an error case, for example whether an order with an unknown product is created, held back or rejected. The technical owner makes sure the process runs, updates are installed and changes to the connected systems are followed up.
If either is missing, the automation lasts until the first connected system changes. That is why operation is part of the project from the outset, not an afterthought. With us, operations and maintenance start at €300 net per month, including hosting, updates, monitoring and a dedicated contact.
We develop with Claude Code, the AI tool from Anthropic. Responsibility still lies with people: no change goes live without automated tests, code review and approval by a human.
Is it worth it, and what does it cost?
A simple comparison shows whether a process pays off: internal hours per month multiplied by the internal hourly rate, plus the cost of current errors. Set against this are implementation and operation. The cost of errors is easily underestimated here, because rework is rarely recorded as a separate item.
Our ranges for implementation, all net: a small line-of-business application costs €10,000 to €30,000, a system for several departments €30,000 to €90,000, and company-wide solutions start at €90,000. The price is driven mainly by the number of processes, the permissions concept and the interfaces.
Before that comes a paid analysis of one to two weeks for €3,000 to €6,000 net. It is credited in full if you commission the project; if it does not produce a usable result, you get the fee back. After that, each stage is built at a fixed price. The analysis answers exactly the questions in this article: which processes first, via which interfaces and with which error cases.
The first step
A list of processes you would like to automate is a good starting point for an initial conversation. In 30 minutes, free of charge, we clarify which of them come first by the three criteria and whether an analysis is worthwhile for you.