Robotic Process Automation (RPA) is a concept that can be traced back to batch scripts and yet tends to suffer from somewhat nebulous perceptions of what it is and can do. In this article, we recap the background and core aspects of RPA, then look at some challenges and common issues before reviewing how RPA can be used as part of a strategic platform architecture.
What is RPA?
RPA creates and deploys software ‘robots’ with the ability to launch and operate other software and can be easily set up to do basic, repetitive tasks across applications. It is designed to be implemented by power users with some assistance from programmers, rather than needing development skills.
The most common type of use case would be a person who every day, like clockwork, uses a software application to carry out a well-defined process with clear steps, producing output consumed elsewhere in the business. RPA replaces the human in this scenario, automating the existing ‘robotic process’ by mimicking the person’s actions in the application user interface through simulated clicks and other approaches.
As a less abstract example, most businesses that deal with data will be familiar with the way that spreadsheets proliferate and have a tendency to become business-critical; Excel macros are a form of RPA, as the spreadsheet is programmed to do repetitive or complicated operations automatically, rather than having users manually manipulate the data each time, with the attendant risk of error.
Traditional RPA is aimed at repetitive and deterministic processes, with standardised inputs and outputs, minimal ambiguity, and clearly defined rules with very few exceptions.
Common challenges
When a business automates mundane, repetitive tasks using RPA, output quality improves, and cost goes down, improving overall performance. People who previously performed the now-automated tasks have the opportunity to increase their value in their current area (e.g., progressing from pulling together management reports to analysing the now-automated reports and providing business insights) or by developing skills in new and innovative areas of growth.
There can, however, be a downside. Once the people who ran and understood the manual workflows have moved on, institutional knowledge of the idiosyncrasies and why specific actions were needed tends to fade. If some rules need changing (e.g., new products are introduced and need accounting differently), it can be hard to determine how to add that into an established RPA workflow without breaking things.
Loss of detailed knowledge can be a particular challenge where multiple processes connect; if the other processes have also been automated, then a company wanting to change one of its business applications can find itself bound up in a web of RPA solutions that due to changes in the organisation, are now brittle, hard to understand and an obstacle to moving forward.
Thinking outside the box(ed application)
We have seen how traditional RPA relies on existing applications to carry out business logic, replacing the user ‘at the keyboard’, transferring data between systems, and implementing simple rules-based decisions to automate a workflow. We have also touched on some common challenges. But could RPA have a more strategic use? Can it be an enabler for business transformation and even provide a more rapid strategic solution, replacing traditional development tools when building a business platform?
We have been working for some time with a fast-growing financial services business that provides OTC derivative and structured product solutions to a global client base. Around 18 months ago, it was clear that the business would soon outgrow its manual processes, and a more scalable approach was required for managing the trading book, mark-to-market valuations, client reporting, and downstream functions. Presented with this challenge, the organisation took an innovative approach based on a hosted (SaaS) trading/analytics platform, with custom logic and workflows built with RPA.
The RPA solution integrates with cloud and internal systems, connects trading applications and market data sources with finance and risk ERP, reconciles trade booking and hedging platforms, and provides visibility of core trading and mark-to-market data. RPA workflows calculate the business’s daily P&L, generate regulatory reports (including EMIR and Dodd-Frank), calculate trading positions and margin calls, and produce daily client statements. This all saves many hours of manual effort, freeing traders from non-revenue generating activities and enabling the business to scale up rapidly, containing the cost of operational teams, whilst investing in expansion, as the business evolves.
What are the key lessons from using RPA to build a strategic platform for a fast-developing business? It turns out that most of them align with good software development practices that should be used for any project.
Pick the right tool for the job
While standard RPA capabilities and ease of development are still important, the most critical part of this project would be data workflows between systems, with complex transformations, calculations and reconciliations needed, and well-structured exception reporting.
The RPA suite we use is well established. It has a high-performance and memory-efficient architecture for data transformation and enrichment, combined with a very flexible reconciliation engine that (crucially) can be embedded within workflows for automated decision making. We also use the reconciliation capabilities for regression testing of workflow changes by comparing before and after database tables and reports.
Plan for the unexpected, maintain documentation, and refactor as you go
Design things flexibly as the business may expand in unanticipated directions. It makes sense to keep processes separate at first as they will likely undergo considerable change, so you need maximum flexibility to quickly make logic changes without worrying about dependencies between processes; however, unconstrained duplication of logic leads to a system that is hard to maintain.
This is where good technical management comes into play. Ensure the processes, decisions, and rules are recorded and updated as things change, then allocate time to refactor as processes mature. Their RPA workflows stabilise, and it becomes clear what functional blocks are repeated. For example, when it became clear that multiple data flows needed similar raw client data, we created a single reusable task to query numerous databases and systems and output a superset of data that could then be sliced, diced, and filtered differently for each process. This also minimises the tendency to replicate similar logic in multiple places, which could get out of step over time.
Lessons can be learned from Agile methodologies and the balance required between speed and maintainability; systems need to be flexible yet performant and able to grow with the business. A long list of manual steps in an RPA tool is easy to write but will anyone understand it when it needs changing in six months?
Reuse rather than rewrite existing business logic
The Market Risk team had developed calculation models using Python that were run manually each day, with specific parameters entered by the user. Since these would be time-consuming and error-prone to recreate, the existing Python code was topped and tailed so it could be integrated into the RPA workflow, with RPA launching the scripts, passing in the required parameters, and acting on the outcome. This gave a quick win as the calculations could be run and produce results much earlier in the day (as a user did not need to be present), while the models did not have to be reimplemented, retested, and signed off.
Be aware of scalability concerns
A lot of manual processes involve desktop apps that are not designed for headless automation. MS Office apps are a common example, like Excel, which tends to beget many customised End User Computing (EUC) applications. Ideally, the automated processes should be server-based, but you may find that a user session needs to be logged in, or you need to turn on Excel UI updates, which slows everything down. As a result, you can end up with long-running activities which are difficult to parallelise.
Consider the ‘intangible’ human benefits that will be lost
It’s very tempting just to automate the happy path, as that’s what people will be used to and will tend to focus on when asked to explain a process. Make a point of drawing out the issues users encounter (especially the rare ones) and create a plan to handle them in the solution. If automating an existing process, take the time to go back to stakeholders and check if there are quick wins by changing things slightly; there is, however, a balance to strike against being led into the necessity for a complete redesign, to reach the full solution. Finally, add defensive strategies; when things are automated, errors can propagate much more quickly as there are no more “eyeballs” to pick up something that looks odd and check before continuing.
Treat the RPA build as a proper integration project
RPA is often considered an interim step, which may lead to a lack of rigour around design. To ensure a more strategic build does not become a millstone, a degree of rigour is required. The RPA team needs to be linked into enterprise change management processes; they need warning if an automated application will be updated or replaced and potentially break the automation, rather than just finding out when users report that something has broken. Design error handling for unexpected changes in systems, and if the solution covers anything bigger than a single application, plan out the design and data flows, what data goes where, formats, interfaces, etc. Use data-driven config where suitable, e.g., reading definitions from a spreadsheet or database, and ensure the broader technology organisation is aware of the dependencies.
Conclusion
RPA as a solution is cost-effective, scalable, and easy to implement. It is designed to interact with existing systems in the same way as human users, without requiring the wholesale replacement of legacy technology and the attendant large-scale investment costs and risks that ensue. The technology has come a long way in recent years; its flexibility and ability to deliver value quickly and incrementally mean it can be considered a key component of a technology strategy or a viable alternative to a new system build in certain scenarios.
Through practical implementation, we have shown that it is possible to create a highly functional and cost-effective solution using RPA, build and implement new business processes and data flows that weave together commercial software, custom-built applications, proprietary calculation packages, and established ERP back-office platforms. The resulting platform supports many operational needs whilst being responsive to the changing needs of a fast-moving financial services business.
Written by: Paul Walsh, Digital Transformation Practice Lead and Head of European Consulting and associate James Gillies
Author
