Why companies still copy data between systems by hand, despite RPA being available

Start with some concrete numbers seen in many companies. In a typical 50–200-person organisation, manual data shuffling between systems consumes anywhere from a few dozen to a few hundred hours a week. It isn't a number anyone reports consciously – it just diffuses into the daily work.

Sample processes. Finance: 8–12 hours a week entering invoices into the system from PDFs received by email. Sales: 4–6 hours a week re-keying leads from various sources into the CRM. HR: 3–5 hours a week pushing new hire data through 4 systems. Warehouse: 5–8 hours a week reconciling stock between the sales and the warehouse system.

Total: in a 100-person company that's usually 80–150 hours a week of manual re-keying. Times 52 weeks – over 5,000 hours a year. At a loaded rate of 15–20 EUR per hour that's 75,000–100,000 EUR a year going into copying data nobody is reading for its own sake.

What's worst – this cost isn't visible in any report. Nobody hires people just to re-key data. The time is scattered across many people and many tasks. Nobody knows how much the company loses on it until someone measures it.

The most common answer to why aren't you doing RPA is: we don't have time to take it on. It sounds banal, but it's the real top block.

The mechanism is this. The team has 8 hours of routine work every day. Those 8 hours include the re-keying. To plan a robot deployment, you have to stop and think, describe the process, find a consultant, check the budget, talk to leadership. That's 3–5 hours of extra work.

Those 3–5 hours don't exist. Wherever you'd take them from, the daily routine suffers. The manager doesn't have them, they're firefighting. Leadership doesn't have them, they're on sales and finance. The result: the topic keeps getting deferred. After a year, still deferred. After three years, the process is still manual.

The paradox: the team loses dozens of weeks a year on manual work to save itself 3–5 hours today on a conversation about automation. The most expensive paradox in business.

How to break it: someone in leadership has to declare this investment of time a priority. Without that decision, the topic drifts indefinitely. Sometimes the best leadership decision is simply: this quarter two people on the team spend 3 hours a week on automation.

Many companies think RPA exists only for huge corporations. That image is nurtured by classic RPA vendors aiming at enterprises. But it isn't the full market picture.

Classic worries: it must be expensive, I've seen licences at 100k USD. True for UiPath Enterprise. Not true for Power Automate Desktop, which in many M365 bundles is practically free for basic scenarios. The first robot can be deployed for 4,000–7,000 EUR including a consultant.

Second worry: it must be technically complex, we have a small IT team. In practice most simple Power Automate robots are drag-and-drop. A small company can have one person who builds and maintains 3–5 robots. An external specialist helps at the start, then the company runs on its own.

Third worry: robots break all the time, I've heard horror stories. Yes, some robots break – the ones built on unstable systems, poorly maintained, with no owner. A robot on a stable process in an old ERP, planned well – runs for years untouched. It all depends on the process and the way you deploy.

Fourth worry: we'll have to lay off the people whose process gets robotized. Not true for most companies – as we showed in Will RPA replace employees. In a typical company people stay; their work becomes more meaningful. Layoffs are a minority of cases.

Often the block is simply that leadership doesn't know how much time the team loses on manual re-keying. Because nobody reports I keyed in invoices for 4 hours today. Reports sound like I worked on invoices.

Between that 80–150 hours a week and leadership sit several layers of dilution. The employee doesn't report it because it's their everyday work. The manager doesn't measure it because there's no obvious method. The CFO doesn't see it because it doesn't move any KPI. Leadership hears the team is busy but not what with.

The simplest fix: a small exercise. Every person in the department writes down (to a 15-minute granularity) what they did for a week. No judges, no reports – just for themselves. After a week, the team tallies hours by category: meetings, decisions, analysis, customer contact, re-keying data, other.

The result often shocks. 30–50 percent of team time turns out to go into re-keying data and operating systems. In other words the team is working on what it was hired for only half the time.

After such an exercise the decision to automate becomes simple, because leadership sees in black and white what the company actually spends on manual work. And that the alternative – RPA – costs much less.

Many companies tried RPA in the past and it didn't work. They're left with the impression that RPA doesn't work. The reasons for the failure were usually not technological, but organisational.

Classic failure scenario from 5–7 years ago. The company deployed UiPath, built 3 robots, didn't have someone to maintain them, the robots broke, the project was abandoned. The company was left with UiPath licences nobody used and the feeling that RPA doesn't work.

What has changed since. First, tools are simpler. Power Automate today is many times easier to maintain than UiPath was years ago. Second, the understanding of how to deploy RPA successfully is much wider – we know you need an owner, you have to measure the effect, you have to start with a boring pilot. Third, combining RPA with AI and workflow opens up much more than a few years ago.

Conclusion: failures from a few years back are not a good signal about how deployments go today. Many companies with bad past experience come back to the topic with a new approach and new tools – and many succeed.

If your company had a failed RPA project – it's worth coming back to the topic, but with lessons from the previous try. Often the block is emotional thinking we tried, doesn't work, while in reality all you need is different tools and a different approach.

Often RPA is on the agenda for months but nobody takes it on as their own. Everyone sees it, everyone agrees it makes sense, nobody has it as a KPI. The topic circulates but never moves forward.

A simple fix here: one named person responsible for the first project. Not a committee, not the whole team – one person. It can be a department manager, the IT director, somebody from back-office. What matters is that they have it in their quarterly objectives, have the time, have leadership's support.

Without such a person, RPA – like every cross-functional project – bounces between departments. IT says the business team has to describe the process. The business team says IT has to configure it. No one takes the first step. Six months later we're in the same place.

The best deployments we've seen had a clear owner from day one. Usually not a technical specialist – a person who understood the need and had the authority to push the project through. The external consultant brought technical expertise; the owner brought context and decisions.

All five barriers (time, misconceptions, awareness of cost, history, owner) can be overcome, but it takes a deliberate leadership decision. The practical path looks like this.

Step one: measurement. A week in which the team writes down what they're doing. The result goes to leadership with concrete numbers: this many hours a week go into manual processes, this much it costs a year.

Step two: pilot process. One concrete process (ideally boring, repeatable, on a stable system) picked as the first. A manager named as the owner. An external consultant invited for a conversation.

Step three: the pilot. 6–10 weeks of work, 5,000–10,000 EUR, one specific process robotized. Measure: time before and after, errors before and after, team satisfaction.

Step four: learning. After the pilot the team knows how to live with a robot. Who monitors it, who fixes it, how to react to changes. That knowledge is the most valuable outcome of the pilot – more than the time savings.

Step five: scale. After the pilot the next deployments go many times faster. In a year the company has 5–8 robots, each covering a meaningful slice of the work, the team is engaged, leadership sees results in numbers.

Full path from measurement to 5 robots: 9–12 months. Investment: 25–50k EUR. Realistic payback: usually in the first year; further years are pure savings and better work.

Companies still copy data by hand not because RPA is too expensive or too complex. They do it for human and organisational reasons: no time to take it on, misconceptions about RPA, no awareness of how much the company really loses, residue from earlier failed projects, and nobody owning the topic.

Each of these five barriers can be overcome, but it takes a deliberate leadership decision. Without it, the topic drifts for years while the company loses hundreds of hours a year to manual data shuffling.

Practical path: measure the team's time, pick a pilot process, name an owner, deploy the pilot in 6–10 weeks, learn, then scale. The whole loop from decision to 5 robots: 9–12 months.

The most important thing: don't ask is RPA worth it for my company. Ask how many hours a week is my team re-keying data manually. The answer to the second question usually closes the topic. See also RPA in business – which processes to automate and How RPA works in practice.