RPA, or robotic process automation, is a program that does on screen what a person would do: it opens a system, enters data, clicks “save”, downloads a file, sends an e-mail. It does not change the systems it connects; it pretends to be a user. That is why it works quickly where integration through an interface is impossible or too expensive, and why it can be a trap: a robot clicking on a screen breaks with every change to the screen. Below: where RPA makes sense in manufacturing and where it is better to do something else.
Where a robot makes sense
- A legacy system without an interface. An ERP or a warehouse program with no API, whose vendor no longer exists or charges for every request. The robot enters there what a person enters today.
- External portals. Customer, carrier and government portals: downloading orders, sending delivery notifications, fetching documents. There is no way to connect to them other than through a browser.
- Recurring reports from several sources. Every morning the robot logs into three systems, downloads the summaries and combines them into one file, which a person used to put together.
- Temporary processes. Data migration, a transition period before the proper integration. The robot works for a few months and disappears.
The common feature: the process is fully defined (the same steps, the same fields) and the input is predictable.
What a robot should not do
- Make decisions. A robot that “assesses” whether an invoice matches the order, or that chooses a supplier, oversteps its role. Decisions belong to rules in the system or to a person; the robot executes.
- Replace an integration that is possible. If both systems have an API, a robot clicking on their screens is more expensive to maintain and slower. An interface survives a change in the look of the screen; a robot does not.
- Work on data nobody checks. A robot retypes errors just as efficiently as correct data. If the input comes from a customer's e-mail, a confirmation step is needed.
- Be the only place where the process exists. When knowledge of the process lives only in the robot's script, the company stops understanding its own process.
- Handle exceptions. A robot should do the typical case and put exceptions in a queue for a person. A robot with fifty “if” branches cannot be maintained.
Examples from the shop floor and the office
Good:
- retyping orders from a customer portal into the ERP, with a queue of items the robot could not match to an item code,
- sending shipment confirmations to a carrier portal from data in the WMS,
- taking the attendance list from the time and attendance system and entering it into an old payroll program,
- a daily downtime summary from the MES in a file for the production manager.
Bad:
- a robot “checking quality” from photos,
- a robot that changes order dates in the ERP according to its own rule,
- a robot retyping production reports from paper cards (collect the report digitally first, and then there is nothing to retype).
How to deploy a robot painlessly
- Describe the process step by step, with screens. If it cannot be described, it cannot be robotised.
- Separate out the exceptions. What the robot should do when a field is empty, when the item code does not exist, when the system does not respond. Always: put it in the queue with a reason; never: guess.
- Plan a work log. Every run, every item, every exception recorded; without it, nobody knows what the robot did overnight.
- Appoint an owner. A person on the company side who reviews the exception queue and reports screen changes.
- Plan the end. Write down what has to happen for the robot to no longer be needed (integration through an interface, a new system), and when you will check this.
What to calculate
The number of items retyped per day, minutes per item, the number of retyping errors per month: collect these three numbers before and after deployment. Add the maintenance cost: how many times a year the screen of the system the robot logs into changes, and how many hours a fix costs. A robot that needs fixing every month can cost more than an integration.
Checklist
- The process fully described, with screens and fields.
- Checked whether there is an interface that could replace the robot.
- Exceptions go to a queue for a person, with a reason.
- A robot work log and an owner on the company side.
- Before and after measures: items, minutes, errors, robot fixes.
- A written condition under which the robot is no longer needed.
At ErgoFlow, RPA is one of the tools, not the goal: we propose a robot where there is no interface or integration is not cost-effective, with an exception queue and a log, and where there is an interface, we build an integration. More on the Automation page; we describe reading documents before retyping on the AI page.
This article is for information only. A robot's cost-effectiveness depends on the number of items, the availability of interfaces and how often the systems change; we compare it with an integration after an audit.
