How can a simple spreadsheet-formula error lose billions of dollars? Why did the gene names Mar-05 and Sep-15 disappear from many genetic studies? Why were Brian Test, Avery Blank, and Jeff Sample ignored by different IT systems?[i] What caused the Schiaparelli Mars lander disaster?[ii] The common source was human error in programming and using IT systems. Errors most often arise where delivering functionality takes precedence over code quality and a clean, well-designed solution architecture. A lack of discipline and attention to software quality encourages them
[iii]. RPA (
Robotic Process Automation) is not error-free either, because errors occur wherever software exists.
What are the most common RPA implementation mistakes?
The list is long because mistakes can arise at virtually every implementation stage and their consequences are usually painful.
- Objectives
One of the most common mistakes is defining unsuitable business objectives. Decision-makers and project managers rely too heavily on vendors’ promised benefits. Faith and intuition based on brochures and case studies replace reliable analysis of the company’s situation. Expected KPI (
Key Performance Indicators) values are then missed and disappointment is severe. Deeper reflection may show that excessive expectations caused the failure, although robotization itself was sensible. Other typical errors include underestimating required IT-infrastructure changes and a mismatch with the technology stack. Employee technical awareness and culture, company characteristics, and process structure also matter. RPA objectives must therefore be based on detailed, reliable analysis of the entire organization and its processes. A
PoC implementation concept (
Proof of Concept) is best developed with an experienced technology partner that does not represent a single RPA vendor.
- Processes
Another group of mistakes concerns the
selection of processes for robotization. Processes unsuited to a digital environment, incomplete, obsolete, or based on pre-Fourth-Industrial-Revolution assumptions are unlikely to provide a sound basis for RPA
[iv]. The same applies to unoptimized or insignificant processes. Priorities require care, particularly at the beginning: failure with an overambitious objective may discourage decision-makers for years. A suitable process is standardized and repetitive, prone to human error, high in transaction volume, low in exceptions requiring intervention, requires switching among multiple systems and interfaces, and is resistant to frequent change. Only processes meeting such criteria are likely to produce the expected results.
- Technical analysis
A superficial technical analysis based on one-sided sources can also lead implementation astray. Assessing infrastructure, software, resources, and IT-team experience is as important as examining data quality and sources and the stability of business applications. The analysis must define detailed technical and business assumptions, the entire
implementation concept in time and budget terms, and realistic objectives. An RPA implementation built on fragile, vague assumptions will produce an uncertain result.
- Technology and ROI
Selecting a technology binds an organization to its vendor for years, so the choice requires care and transparent criteria. Costs include not just licenses but maintenance, development, and modification over many years.
ROI estimates (Return on Investment) cannot rely solely on foreign implementations. Robotizing the same
customer-service office process may pay back within months in wealthy Western countries but take years in Poland when labor cost is decisive. Every organization seeking to
optimize its RPA model should continuously assess tools by functionality and revise assumptions according to current needs and implementation cost.
- Implementation-partner selection
Selecting the company that will implement RPA is critical, especially where internal IT teams lack robotization experience. Choosing an unestablished company with little more experience than your own may leave nobody capable of developing functionality and defining future RPA objectives several years later.
- Testing and validation
Testing mistakes are particularly costly. The schedule must allow enough time for comprehensive tests, which may take weeks or months. This is the time to refine the solution and improve ergonomics and effectiveness. Automated-testing tools and code-audit documentation are highly useful and make future robot changes easier and faster.
- Internal communication and management engagement
Communication gaps and indecision first cause schedule overruns and higher costs; stress and tension then reduce implementation quality. RPA strategy must form part of overall business strategy and must not trigger competition for resources or conflict among teams and managers. This requires management support and employee confidence that robotization builds lasting competitive advantage. Internal communication is only one implementation tool, but it is pivotal. Poor procedures cause duplicated work or incorrectly performed tasks through misunderstood objectives. Documentation gaps can later prove costly when discussed and implemented information was never recorded. Such apparently minor errors can frustrate many people and discourage engagement with RPA.
What should be done to avoid RPA implementation mistakes?
The remedy is illustrated by the military saying: the more you sweat in training, the less you bleed in battle. More time spent analyzing, planning, and validating a
Proof of Concept means faster, cheaper implementation. Every decision needs clear criteria, agreement among decision-makers, and communication to every stakeholder. The implementation project is the key document and defines practically every task. Mistakes at this stage can have unpredictable consequences. A leader is necessary, but their working style may either encourage or prevent errors. A good practice is “let others read it.” Authors may not see ambiguities or gaps in their own work. Discussion and rational criticism provide genuine verification. Conversation, shared experience, and creative problem-solving are the cheapest and most effective vaccines against RPA implementation errors.
Which errors and problems can occur in an operational RPA system?
Operational RPA most often reveals errors in scaling and employee involvement in automated processes. Further mistakes arise when robots are modified, for example after changes to application screens. Despite developer and tester effort, every change to working code risks introducing an unknown defect. New integrations with business applications can also cause errors if not tested thoroughly. Whether a robot is attended or unattended, it requires interaction with fallible people, so robot operation may still lead to mistakes.
Who should be responsible for RPA errors?
If an error and its author can be identified precisely, responsibility is straightforward. Planning mistakes and collectively made poor decisions are harder; their consequences also fall on the project manager. If organizational problems affected the entire implementation and management support was absent, the designated board member, as the highest authority in the hierarchy, should bear responsibility. Accountability is therefore complex and delicate, and it is unsurprising that failed implementations sometimes appear to have no culprit. Circumstances may have been unfavorable, and nobody likes admitting mistakes.
RPA and human error—can it be eliminated completely?
Robotic Process Automation is intended primarily to reduce human errors and release employees from repetitive, routine work. RPA-related errors have nevertheless always occurred and always will, because robots are human creations. This is unavoidable and has deep psychological roots in human nature. The heuristics
[v] used in everyday life, often unconsciously, can lead to misinterpretations of reality. We must learn to live with errors, but that does not mean accepting them without action.
[i] Matt Parker, Humble Pi: A Comedy of Maths Errors, Insignis, Kraków, 2021.
[ii] https://kosmonauta.net/2016/10/blad-oprogramowania-w-edm/
[iii] https://www.benchmark.pl/aktualnosci/drobny-blad-w-oprogramowaniu-powazne-konsekwencje.html [iv] https://www.the-future-of-commerce.com/2021/02/23/rpa-pitfalls/ [v] Daniel Kahneman—Thinking, Fast and Slow, Media Rodzina, Poznań, 2012.
