Robotic Process Automation is software bots operating at the interface level — doing what a person would do, in the same screens, following the same rules. The bot does not change the underlying system. That is both its advantage and its ceiling: fast to deploy, economical next to an integration project, and dependent on every screen staying the way it was.
RPA fits a narrow class of work: high-volume, rule-based, stable processes with digital inputs. Where the rules end and judgement begins, RPA stops — and finding that boundary, process by process, is the whole assessment.
The honest limit: automating a broken process makes it fail faster. Process clarity comes first, which is why RPA sits under process management rather than beside it.
A quick read before you spend a meeting on it. If most of this matches your situation, an automation assessment is worth scoping — if it does not, we will say so.
You have processes running at volume that follow clear rules
People are re-keying the same data between systems
Integration is blocked, too slow or too expensive to justify
You need to know which candidates are worth it before committing
The people who run the process, not only IT
Current volumes and cycle times, even approximate
Sight of the systems involved and how they are accessed
Workshop time with the specialist departments
RPA is genuinely useful where work is high in volume, clear in its rules and stable in its inputs. The trouble is that most of the processes people want to automate are none of those things — they are workarounds for something that was never designed. Automating a workaround makes it permanent. We would rather tell you that before you buy the licences than afterwards.
Four phases, and the first two decide whether the last two are worth starting.
Based on an established RPA strategy we create an action plan with our customers, including prioritisation, goals and their target dates, and a description of the team roles. All affected specialist departments are involved and the project plan is jointly agreed.
Where automation genuinely pays — assessed across the whole company, not one department’s wish list.
What the bots must do, and how the return is measured.
This is where independence earns its keep: we qualify and negotiate with the providers and take no commission from any of them.
Delivery under project control — and the acceptance that proves the case.
WORKED THROUGH WITH YOUR SPECIALIST DEPARTMENTS
Every process assessed, the ones that are not candidates named and the reason given.
Licences, infrastructure, build and the maintenance that follows a screen change.
Including the operating-software strategy the bots will run on.
Who owns a bot, who is told when it stops, what a new one must comply with.
Where RPA sits relative to the systems it operates on, so it is not a shadow layer nobody has mapped.
Sequence, owners and the second process planned before the first one ships.
Hagos eG · B2B wholesale
ProblemA wholesale co-operative managing 45,000 items across 10 branches and 3 warehouses — with a master-data error rate high enough to make every downstream automation unreliable. Master-data quality is exactly the class of problem that decides whether automation is worth attempting.
EngagementThe rule-based maintenance work assessed and automated — with standards, ownership and measurement defined before roll-out, and the error rate tracked after go-live rather than declared fixed.
73%
reduction in master-data error rate · measured
45,000
items under management
10 · 3
branches · warehouses
No licence, commission or build revenue behind the advice. We recommend what fits your processes — including “do not automate this one.”
Honest answers about the boundary to AI, the running costs and the ownership question — what comes up in nearly every first conversation about RPA.
Answers by:
Dr. Harald Dreher
Founder · Dreher Consulting
steered process optimisation for Mittelstand companies — with no licence, commission or build revenue behind the advice.
Profile · Last updated: 25 August 2026
The difference is the boundary between rules and judgement. RPA is rule-based automation: software bots execute defined steps in existing screens, the same way every time. AI begins where the rules end — where interpretation, judgement or prediction is required. Most efficiency gains in administrative processes still come from the rule-based part, which is why the honest assessment starts there: what a bot can carry, and what genuinely needs judgement.
Processes that pass four tests: high volume, clear rules, stable over time, and digital inputs. Typical candidates are re-keying data between systems, invoice matching and standardised master-data maintenance. Most processes that look automatable fail at least one of the four — which is why the assessment produces a shortlist with the rejected candidates named, not a longer list.
The build and the licences are the visible part. The running cost comes from maintenance: a bot works at the interface level, so a changed screen, a release or a permission update can stop it. A serious business case counts licences, infrastructure, build and the maintenance that follows every change to the underlying systems — the total cost of ownership, not the pilot budget.
Where a process is broken, yes. Automating a broken process makes it fail faster and makes the workaround permanent. That is why RPA sits under process optimisation: the process is assessed first, and a candidate that needs fixing is fixed or dropped — not automated as found.
A named owner in the specialist department, backed by governance defined before go-live: who is told when the bot stops, who maintains it when a screen changes, and what any new bot must comply with. A bot without an owner fails silently — the work simply stops being done, and nobody notices until the backlog surfaces.
No. RPA operates at the interface level and leaves the underlying systems unchanged — that is its advantage and its ceiling. Where an integration is blocked, too slow or too expensive to justify, a bot can bridge the gap economically. Where a high-volume connection between systems is needed for the long term, an integration is usually the better answer — and we will say so.
The full initial consultation with Dr Harald Dreher or the senior partner managing the account. Aim: to clarify the decision-making situation — not to recommend a system.
Book the call →Whether taking on the mandate makes sense. If we're not the right people for the job, we'll say so.
Book a short call →Where you stand. Next step — not a sales pitch.
Email us →