When is it better not to automate a process?

Do not automate a process if it occurs rarely, will change soon, has no clear rules or no owner, or if the input is so messy that the exceptions become the work. Leave decisions that need human judgement or are legally sensitive with a person. And first check whether there is a simpler solution, such as a standard function of your ERP (the business system for orders, stock and finance), a fixed form or a different submission format. Often the honest advice is not "never" but "not yet": first improve the process where needed, measure or wait.

The example: the same kind of orders, two situations

Whether automating is wise does not depend on the type of work, but on the circumstances. Two versions of the same process show this.

Assumptions: 4 minutes per order, 230 working days per year and 15 minutes of checking per day. Situation 2 uses 10 orders and 40 per cent exceptions. Even if the check in situation 2 takes only 5 minutes, about 73 hours per year are freed up. That does not yet include development, licences and maintenance, and the robot has to be rebuilt in nine months.

In situation 1, automating is wise. In situation 2, it is better to wait for the new ERP and to standardise the orders in the meantime. How to make such a calculation for your own process is explained in when automation pays off for a small business.

Nine signs that it is better not to automate

One sign does not always mean "no". It does mean that you first solve that point or take it into account.

1. The work occurs rarely

An automation costs money to build, and keeps costing money and attention to monitor and maintain. Even with few cases, someone has to check the alerts and the daily overview. With a few cases per week, that rarely outweighs the gain. An exception is work that occurs rarely but is error-prone and has serious consequences. Then an automatic check can make sense.

2. The process or the system will change soon

If a new ERP, a new customer portal or a reorganisation is coming, the screens, the fields or the rules will change. A software robot that operates screens will then have to be rebuilt. An integration often has to be redone too. You then pay twice for the same work.

Use the waiting time well. When you choose the new system, include the requirements for automation: a documented API, an import function and a test environment. Automate afterwards, when the new system runs stably.

3. The rules are not clear

"You can just tell" is not a rule. If two employees handle the same case differently, or if nobody can explain when a price difference is acceptable, software cannot do it either. Write down the rules first and agree on them. This often improves the process already, and automation turns out to be less necessary than expected.

4. The exceptions need interpretation

Many exceptions are not a problem in themselves. If an exception follows a clear rule, such as "if the customer number is missing, search by VAT number", the software can handle it itself. The problem is exceptions that need interpretation case by case: those go to an employee and stay manual work. If a large share of the cases is such an exception, you mainly build exception handling. So first count how often the work deviates, and why. Sometimes you can remove the main cause before you automate.

5. The input is poor

Software does not make messy input better. Scanned orders with handwritten notes, Excel lists with a different layout every week, a customer who appears twice in the ERP, or an item that has a different revision in the ERP than on the released drawing: this leads to many doubtful cases and errors. Improve the input first. Clean up duplicate and conflicting master data (fixed data about customers and items) and give customers a fixed way to submit their data.

6. There is no owner

An automation needs someone who decides on the rules, clears the review queue of exceptions and tests changes. If nobody in the department wants or is able to take that role, the automation stops at the first change, and nobody notices. More on this in why RPA projects fail.

7. The decision needs human judgement

Some decisions belong with a person: assessing whether a customer-specific product can be made, choosing a margin in a quote, accepting a new customer or not, rejecting a job applicant. Software can prepare such decisions: collect data, flag exceptions, make a proposal. You leave the decision itself with an employee. What comes before and after that decision can still run automatically; see human in the loop.

For decisions about people, the law also plays a part. According to the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP), the privacy law GDPR (in Dutch: AVG) gives people the right to a human review of automated decisions with legal or other serious consequences. As examples, the AP mentions refusing a loan or not inviting someone to a job interview. If you are unsure whether a decision falls under this, get legal advice before you automate it.

8. The costs are higher than the return

Calculate with the time that is actually freed up, not with all the hours that the work takes now. Set the costs of development, licences and maintenance against it. If the result is negative, or if the positive result depends on optimistic assumptions, the answer is no. What those costs are is explained in what it costs to automate a business process.

9. There is a simpler solution

Sometimes you solve the problem without new software:

• A standard function. Many ERP packages have an import function, an approval step or a standard integration that nobody uses. Ask your supplier what is already there.
• A form. A web form or Excel template with required fields delivers data in a fixed format. That is often worth more than software that learns to read free-form emails.
• A different submission format. Ask suppliers for an e-invoice instead of a PDF. According to Ondernemersplein, the Dutch government's information site for businesses, a PDF is not an e-invoice. An e-invoice contains codes that let software process it directly. If you supply the Dutch central government, you already have to send e-invoices. The Dutch government wants to make e-invoicing mandatory between Dutch businesses too, expected from 1 July 2030. The rules for this are not final yet.
• Remove the cause. If a process planner retypes a bill of materials (the list of parts of a product) from an engineering Excel list every day, the question is why engineering does not keep that bill of materials in the system itself.

What you do instead

"Not automating" rarely means "doing nothing". The table puts the alternatives side by side.

These approaches do not exclude each other. In situation 2 of the example, the company waits for the new ERP, measures in the meantime how many orders have an exception and why, and gives the largest customers a fixed order form. As a result, the automation is simpler and cheaper after the switch.

Decision framework

Ask these questions internally, in this order. An honest answer to the first questions saves a lot of work on the later ones.

1. What is the problem we want to solve: time, errors, delay or dependence on one person?
2. Can we solve that problem at the source, or with a function we already have?
3. How often does the work occur, and how many cases have an exception? Has that been measured?
4. Will the process and the systems stay as they are for the coming year?
5. Who will be the owner, and who handles the exceptions?
6. What is the net return, after deducting exceptions, checking, building, licences and maintenance?

The factors that weigh most are the volume, the share of exceptions that need interpretation and the stability of the process and the systems. A high volume makes up for a lot. A system that will soon disappear makes up for nothing.

Outside help makes sense if opinions are divided internally, or if nobody has time to measure. An outsider with no stake in the outcome can also advise "don't do it". With the four questions on the services page, you judge for yourself whether a process is suitable: four short questions, without a tool or a calculation. A process analysis goes deeper and ends with advice, and that advice can also be: improve the process first.

Checklist: is your process ready?

Check whether each statement is true for your process. Each statement that is not true is a point to solve first, or a reason to wait.

• The work occurs often enough every week to justify building and maintaining the automation.
• The process and the systems will not change significantly in the coming year.
• The rules are written down, and two employees would handle the same case in the same way.
• The share of exceptions has been measured, and most exceptions follow a fixed rule or are easy to recognise.
• The input arrives digitally and in a recognisable format.
• There is an owner in the department, with a deputy.
• Decisions that need judgement or have legal consequences stay with a person.
• The net return is greater than the costs, even with cautious assumptions.
• There is no simpler solution, such as a standard function, a form or a different submission format.

Not automating has drawbacks too

This article is about the reasons to stop or wait. But manual work also has a price. Typing errors remain possible, the work often depends on one or two people, and as the company grows, the manual work grows with it. So a "no" today is not a "no" forever. Look at the process again when the volume rises, when the new system is running or when the rules are written down. How to start then is explained in the guide automating business processes.

Conclusion

The best automation is sometimes the automation you do not build. A process with little volume, many exceptions that need interpretation or a system that will soon disappear costs more than it delivers. Use such a "no" or "not yet" to make the process simpler first. Then the automation later is smaller, cheaper and more reliable, or it turns out not to be needed.

Sources

• Autoriteit Persoonsgegevens: Right to a human review of decisions (in Dutch)
• Ondernemersplein: Sending an e-invoice to the government (in Dutch)
• Ondernemersplein: E-invoice mandatory for transactions between businesses (in Dutch)