When automation isn’t enough
Why some business processes need to be rethought before technology can help
Many companies start their digitalisation journey with automation. RPA bots are meant to take over repetitive tasks, Intelligent Document Processing is meant to break down the mountains of paperwork, and Agentic AI promises to steer entire workflows on its own. The tools are there. Expectations are high. And yet, projects fail – not because the technology breaks, but because the underlying process was never designed for automation in the first place. It grew, rather than being planned. It is full of exceptions, undocumented decisions, and informal workarounds that only work because experienced staff know them by heart. The decisive question isn’t: Which tool solves the problem? It’s: Is the process itself the problem?
The automation paradox
If you automate a bad process, you get a bad process running at high speed. The insight sounds trivial, but in practice it is ignored surprisingly often. Companies invest in RPA licences, build bot teams, and launch pilot projects without first asking a basic question: does the process we want to automate actually work cleanly?
The analogy is close to hand: if you want to polish your car, you apply the polish to the paintwork – not on top of a layer of dirt. But that is exactly what happens when companies overlay an inefficient, inconsistent, or simply outdated process with technology. The bot then reliably executes what previously ran badly by hand. The errors aren’t eliminated; they are scaled.
The mistake has a structural cause. In many organisations, automation is treated as an IT project. The business unit flags a process, IT builds a bot, and success is measured in hours saved. What gets missed is a critical look at the process itself. Nobody asks: Why does this process have seven steps? Do we really need three approval stages? Why is the same piece of information transferred manually three times?
Experience shows: what works badly in analogue form will not work better digitally. That insight – formulated, among others, by the German ECM provider d-velop – applies to every form of automation. Whether RPA, IDP, or Agentic AI: the technology can only ever be as good as the process underneath it. A process built on workarounds, exceptions, and implicit knowledge is not healed by automation. It is cemented in place.
Where RPA, IDP, and Agentic AI hit their limits
Not every business process can be automated. That is not a weakness of the technology – it is a property of certain processes. It pays to know the typical limits before starting an automation project.
RPA works excellently with rule-based, repetitive tasks that have clear inputs and outputs. As soon as a process contains many exceptions, the bot becomes complex, fragile, and expensive to maintain. A procurement process in which every third order requires a special approval is not a good RPA candidate.
Intelligent Document Processing (IDP) fails when input formats are too heterogeneous, or when the relevant information isn’t available in a structured form. A handwritten note in the margin of an invoice, a free-text field in an email, a verbal commitment that was never documented: these are all boundaries at which even advanced AI models cannot operate reliably.
Agentic AI – AI agents that independently make decisions and execute actions – hits its limits where decisions rest on experience, intuition, or context-dependent judgement. When an experienced case worker reviewing a loan application says, “This doesn’t feel right,” what stands behind that is decades of pattern recognition that cannot easily be translated into rules or training data.
The common thread of these limits: they do not lie in the software, but in the process. Processes with undocumented decision steps, missing interfaces between systems, a high share of human judgement, or workflows passed on only verbally are simply not “bot-ready”. Before automating here, the process itself must be changed.
Business process analysis as the first step
The first step isn’t tool selection. The first step is understanding the as-is process – and not the process as described in the manual, but the process as it is actually lived.
A thorough business process analysis systematically uncovers where the documented target process diverges from the real as-is process. In almost every company, there are workflows that only work because individual employees know steps by heart that aren’t written down anywhere. There are decisions that are officially taken on the basis of defined criteria, but in practice rest on experience and gut feeling. And there are handovers between departments that run through informal channels: a phone call, a quick email, a Post-it on the monitor.
These hidden structures are the real reason why automation projects fail. A bot can only execute what is explicitly defined. If essential process steps remain implicit, the bot won’t carry them out, and the process collapses.
Business process analysis therefore means more than drawing flowcharts. It means talking to the people who run the process every day. It means evaluating data instead of making assumptions. It means measuring the actual cycle times, error rates, and rework loops – not the planned ones. Only when the as-is process is fully transparent can you judge which parts can be automated, which parts need to be simplified, and which parts can perhaps be dropped entirely.
Data instead of gut feeling: that is the core of a serious business process analysis.
| “A process that causes problems in analogue form will also cause problems as a digital process.” // Adapted from d-velop / Digitale Exzellenz |
Zero-based process design: thinking from a blank sheet
When the business process analysis shows that a process is fundamentally broken, incremental improvement isn’t enough. What you need then is a more radical approach: zero-based process design.
The principle comes from strategy consulting. McKinsey has popularised it under the term “zero-based design“. The core question is: if we were setting this process up entirely from scratch today – with no legacy, no historically grown structures, no “we’ve always done it this way” – what would it look like?
The question is uncomfortable because it puts everything up for debate. But that is precisely where its value lies. McKinsey recommends setting up a dedicated Centre of Excellence for zero-based design, one that works cross-functionally and doesn’t optimise processes within existing departmental boundaries, but thinks back from the outcome.
A concrete example: a mid-sized company has an approval process for capital expenditure requests that runs through seven steps, involves three departments, and on average takes 14 days. The business process analysis shows that four of the seven steps are pure hand-offs that add no substantive value. A zero-based redesign reduces the process to three steps: application, technical review, approval. Cycle time drops to three days. And only this simplified process is sensibly automatable, because it now runs cleanly, linearly, and without exceptions.
The mistake many companies make: they try to automate the existing seven-step process, instead of first reducing it to three steps. The result is an expensive bot executing a process that shouldn’t exist in that form.
The right sequence: analyse, optimise, digitise, automate
From these considerations, a clear framework for action emerges – a four-stage model that sets the right sequence.
Stage 1: Analyse. Capture the as-is process in full, identify the gaps between target and reality, quantify weak points and bottlenecks. No assumptions, no estimates – only data.
Stage 2: Optimise. Simplify the process, eliminate unnecessary steps, clarify responsibilities, make decision criteria explicit. If needed: carry out a zero-based redesign.
Stage 3: Digitise. Migrate the optimised process into digital systems. Build interfaces, structure the data, eliminate media breaks. This step is a precondition for automation, but it is not the same thing as automation.
Stage 4: Automate. Only now do RPA, IDP, Agentic AI, or other automation tools come into play. They work on a process that has been analysed, optimised, and digitised.
The sequence is decisive. Start at stage 4 and you automate chaos. Start at stage 3 and you digitise a bad process. Start at stage 2 and you optimise blind. The German software vendor SoftProject stresses this staged approach in its methodology, and d-velop also argues that digitisation without prior process optimisation leads into a dead end. This model isn’t a theoretical construct. It is the experience from hundreds of failed and successful automation projects, distilled into four steps.
Hyperautomation: when one tool isn’t enough
Even after a successful process redesign, many processes remain too complex for a single automation tool. This is where the concept of hyperautomation comes in.
Gartner defines hyperautomation as the orchestrated use of multiple technologies: artificial intelligence, RPA, business process management, low-code platforms, and other tools that together automate processes end-to-end. The decisive difference from classical automation: it is no longer about “which tool do we use?” but about “which target operating model do we want to reach?”
The numbers back up the approach. According to Gartner, companies that combine hyperautomation with redesigned processes can reduce their operating costs by up to 30 per cent. Industry studies report up to 42 per cent faster process execution. That isn’t down to any single tool, but to orchestration: RPA takes care of the repetitive steps, AI makes decisions on unstructured data, BPM steers the overall flow, and low-code platforms allow business units to make simple adjustments themselves.
Low-code and no-code in particular play an important role as a bridge between IT and the business. They allow staff without programming skills to implement process adjustments themselves, without having to wait on the IT department. That reduces backlogs and accelerates the continuous improvement that follows the initial process redesign.
Change management: the underestimated factor
Process redesign and automation change more than systems. They change ways of working, responsibilities, and routines. And this is exactly where many projects fail – not on the technology, but on people.
Digitisation that is imposed purely top-down creates resistance. Employees who aren’t involved experience new processes as a loss of control, not as an improvement. The Berlin technology provider sprylab describes change management as the single most underestimated factor in digitisation projects.
The solution lies in inclusion. Business units should not just be users of the new process – they should be co-designers. They know the weaknesses of the as-is process better than any external consultant. They know which workarounds exist, and why. And they know which changes to daily working life can realistically be made stick.
If you bring people in early, you don’t just get better processes – you get acceptance. And acceptance is the precondition for a newly designed, automated process actually being lived, rather than being quietly replaced by old habits within a few weeks.
Conclusion: technology follows the process
The answer to manual business processes that resist automation rarely lies in better technology. It lies in better processes. Analyse first, then optimise, then digitise, then automate. That sequence isn’t up for negotiation.
Zero-based process design, thorough business process analysis, hyperautomation, and consistent change management aren’t competing approaches. They are building blocks of a single overall concept – one that deploys technology where it has the most leverage, and changes processes where technology alone isn’t enough.
Companies that go down this path don’t just automate faster. They automate the right things. And they avoid the most expensive of all bad investments: a bot that keeps a bad process running.
Lunatec accompanies companies in the DACH region and the Gulf on exactly this path – from business process analysis, through process redesign, to the implementation and scaling of automation.
LUNATEC
Lunatec, headquartered in Frankfurt with offices in Dubai, is a UiPath Diamond Partner and Microsoft Partner. We accompany companies in the DACH region and the Gulf in the analysis, optimisation, and automation of business processes – from business process analysis, through process redesign, to the implementation and scaled automation of work with RPA, IDP, and Agentic AI.
lunatec.de · Frankfurt · Dubai · Process Identification · Strategy Assessment