Trend 4—Robotic Process Automation (RPA)
Introduction
What Is Robotic Process Automation?
Robotic Process Automation (RPA) is using a robotic software programme (or bots) to imitate the processing that a human person would do on their desktop. In effect, the bot is replacing the human person.
How Does RPA Work?
RPA bots are developed by typically a third party RPA platform recording the actions that an end-user would normally follow to complete a process. This would cover recording clicks, drop-down selections, entering text, pressing return, opening folders, copying files, and so on. Once the recordings are made then they can be tested to ensure they cover all scenarios and perfected as required. Once they are working they can be promoted into the production environment for live running.
RPA works best on a business process that is simple, rule-based, uses structured data, and does not change regularly. For example, a bot could be developed to automatically forward e-mails onto a pre-defined distribution list or to automatically copy data from a spreadsheet into a separate file which is then copied into another folder. RPA does struggle with processes that are complex to define (such as processing the death of a customer), processes that have a complex set of steps (such as dealing with customer complaints), or processes that do not have a pre-defined set of rules.
In effect, RPA allows a workflow to be implemented quicker and cheaper. Workflow systems are complex, costly, and take a long time to be fully implemented. They also often require changes to applications or APIs (Application Programme Interfaces) to be built to allow the workflow system to obtain the data it needs.
There are many general key benefits for RPA:
• RPA bots are built on top of the existing operating model and will also mirror the current processes. Therefore, automation can be implemented reasonably quickly and cheaply without the need to enhance technology systems by developing APIs and other major changes.
• RPA bots allow the operating model to be streamlined and made efficient. It allows staff levels to be reduced as bots replace the work they do. These staff can either be lost (and therefore resulting in cost savings) or be redeployed doing other more high-level tasks (such as customer servicing).
• RPA bots can run full time—that is 24 hours per day across 365 days per year. This gives more processing capacity. Staff are unable to work for these long periods.
• Assuming (a) the bots are developed and tested fully and (b) the processes or environment does not change then the error rates will be reduced or even cut to zero. The rules developed will be following consistency at all times. Humans are susceptible to errors and mistakes.
• RPA is good for simple and repetitive tasks (such as copying files) which humans may find boring and laborious to perform. This boredom will mean the human is not 100 percent focused on the task which will result in errors and mistakes.
• RPA allows simpler and easier scalability. If processing volumes need to increase then extra bots and/or processing power can be added quickly and relatively cheaply. Likewise, if processing volumes decrease then bots can be removed just as quickly. If these processes were run by a human team then scaling up would involve a lengthy and possibly costly recruitment process followed by several weeks of on-the-job training, and any scaling down could result in staff redundancies and/ or redeployments.
• While there is an implementation cost (see below) that could take a while to pay back, RPA tends to be cheaper to operate on a day-to-day basis than having a team of humans running the processes.
• By moving the simple and easily codified processes on RPA then it allows firms to release staff to work on “value-added” tasks such as dealing with customer queries, cross-selling, and so on.
• Using RPA provides Business Continuity Processing (BCP) improvements around reducing complexity and cost. If there is a large human team then it will require spare desks, buildings, possible remote connections, and so on to ensure sufficient BCP is in place. If processes are running on RPA then as long as the infrastructure running then is resilient then there is no need for desks, people, remote connections, and so on.
Uses of RPA Within the Financial Services Industry
In effect, any process that can be easily codified can be supported by RPA. Therefore, firms are using RPA in several different areas. For example:
• Bank Reconciliations—A bot is developed to download the required data from the banking system and internal financial systems. This data is then automatically compared (say) using a spreadsheet with any exceptions being highlighted and e-mailed to relevant staff for investigation.
• Client Servicing—A bot can be written that will receive in e-mails and then review the title and/or look for keywords in the body of the e-mail. Depending on a set of rules the e-mail can be forwarded to the relevant team(s) that need to investigate the client request.
• Downloading and directing of data—Bots can be developed that will download data (say market index or prices data), reformat it using a series of spreadsheets, and then copy or e-mail this data into a pre-defined list of recipients.
• Some firms have used bots to perform overnight processing. This could cover triggering certain jobs and then waiting until they are completed, and e-mailing interested people to let them know.
• Also, some firms have used RPA to help automate testing software changes. Bots are developed to replicate standard business processes such as creating clients, amending clients, processing a bank transfer, producing a statement, and so on, and then they are used to create test data, perform tests, and so on. Once the bots are developed then they can be used time after time thus making testing a quicker process.
• Account Opening—This is an essential process but manual and laborious to complete. Therefore, bots have been developed which will receive in a structured request to open an account from a prospect. This request is normally from a mobile/tablet app, website, or structured e-mail. The bot will review the application for completeness, perform all required checks (such as KYC, criminal, or fraud checks), request any further information needed and, once everything is in order, then formally open the account and issue any required documentation to the client. If issues are encountered then the request will be rejected and passed to a human team to investigate.
• Accounting Closing—Similar to the Account Opening above, this is another essential but manual process. Therefore bots have been developed to receive a structured request to close an account. (This request is normally from a mobile/tablet app, website, or a structured e-mail). The bot will perform all required checks and request any missing information. Once everything is satisfactory then the bot will close the account and issue any closing documents. If problems are encountered then the request will be rejected and passed to a human team to investigate.
• Blocking stolen or lost credit, debit and/or payment cards— Once a client discovers that their card is missing or lost then they will start to panic and will demand the card be blocked immediately. Therefore, bots have been developed which will make this process much quicker and more efficient. The bot will receive a structured notification that a credit, debit, or payment card is either lost or stolen. Per the earlier examples, this request is normally from a mobile/tablet app, website, or structured e-mail. The bot will perform any necessary checks to confirm the request is genuine, and if everything is valid then the offending card will be blocked or stopped and the client notified. If difficulties are encountered then the request will be rejected and passed to a human team to investigate.
• Processing trades and/or transfers—Firms have developed bots to help automate trading and transfers. The bot will receive a structured request (from a mobile/tablet app, website, or a structured e-mail) to either process a trade or perform a transfer. The bot will validate the request and if everything is correct, the requested trade or transfer will be executed. If problems are encountered then the request will be rejected and handed to a human team to investigate.
• Providing pre-sales documentation—Firms are requested by prospects to provide brochures and marketing information to prospects. This is an essential process but it is manually intensive and laborious. Therefore, firms have developed bots that will receive in the literature request (from a mobile/tablet app, website, or a structured e-mail), determine what documents are required, send them to the prospect, and then record the request on a sales system so the prospect can be tracked if required.
• Fulfill client documentation requests—Nowadays firms receive a large number of requests for documentation to meet the needs of the auditors, the police, the tax authorities, subpoenas plus many others. These requests normally need to be completed within a matter of days but obtaining the required documents is a complex and laborious process because the required documents are often stored across a variety of folders, application systems, and document repositories. However, firms have developed bots that will receive in the client reference then automatically scan or search all the required folders, software applications, and repositories for documents with minimal manual impact. Once the documents have been found then they can be issued as required.
Challenges of RPA
Do Not Underestimate the Size of the Change Required to Implement RPA Successfully
While developing, testing, and implementing RPA bots sounds simple and RPA is often mentioned as a quick way to implement workflow, it is still a challenging implementation. It should be viewed similar to any major technology implementation and not just something that can be done “part-time.” It impacts all areas of people, organizational structure, processes, technology, and so on. It is not just a technology rollout. Therefore, firms need to be aware that it will take time, there will be problems and firms need to be prepared for the “long run.”
It will involve a large amount of support from all levels of the firms. This covers senior management down to the most junior members of staff.
Have a Clear Business Reason to Implement RPA with Clearly Defined Success Criteria
There are many stories of firms (not just in the Financial Services) implementing new technology for the sake of the technology as opposed to implementing technology to meet some type of business or strategic need. (In the same way as any major change) this means before embarking on an RPA implementation then a firm must have a clear business reason to implement the technology. Please refer to Appendix B for a list of the variables to be discussed when completing a Business Case.
Implement or Roll Out RPA in a Slow Phased Approach
As mentioned earlier an implementation plan needs to be created to implement the RPA platform with the associate bots and integrations.
It is important to remember that RPA is a large implementation which means it can be risky. Therefore, it would be sensible to structure the plan around a phased approach. The initial phase would contain the implementation of the actual core platform but then there should be phases each containing a prioritized set of processes or bots. The prioritization should focus on the processes that are (a) easier to define and therefore code as a bot and (b) the processes that offer the most business benefit. This approach will hopefully ensure the project delivers some immediate benefits which will create goodwill, momentum, and confidence. It will also help with financial payback and allow the firm to learn about RPA which could provide useful lessons for the future.
It is also important to understand what is needed to support the implementation. This could involve staffing such as senior management, operational staff, in-house technology staff, RPA platform vendor staff, technology staff who support the systems being integrated with, legal staff, and compliance staff plus others. Furthermore, if the rollout of RPA involves staff losing their jobs then (a) these staff may need to be involved in the project which (b) will require careful and tactful management.
Finally, it may also be necessary to ensure there is desk space for the team, test environments, shared document folders, e-mail lists, and so on.
Build an RPA Capability Covering Technology, Processes, and People
The actual platform consists of three parts: (a) the technology platform, (b) the new processes and oversight required to monitor RPA, and (c) the new skills that are required to run RPA.
Technology Platform
This is a key decision because if the wrong or inappropriate technology platform is selected then it will cause issues during implementation and day-to-day basis, which will ultimately cause the change to fail.
It is possible to develop an in-house technology platform to develop and run the RPA bots but this could be complex and costly. There are a variety of third packages that could be used and it would seem sensible to use one of these. These platforms range from very functionality-rich (and costly) platforms that offer a wide range of features to simpler platforms that do not offer a massive range of features but are often much cheaper and less complex to operate.
Therefore, some types of formal technology platform vendor selection process must be followed. Please see Appendix A which contains a list of the checks to be performed when selecting a supplier.
New Governance and Oversight Processes
As well as the implementation of the technology, new processes, and governance frameworks will need to be designed and implemented to control the new technology. This will cover four main areas:
• Oversight of the daily processes—Controls need to be in place to ensure the bots work as designed. Any issues or problems need to be identified and trapped immediately. Once identified then the cause needs to be investigated so both (a) any historic activity can be fixed and (b) the bot can be fixed to stop the problem from happening in the future. Any material issues will need escalating to management.
• Oversight of the supplier—The firm will likely be reliant on the supplier in some way. This could cover areas such as hosting the platform, supporting the bots, providing support, providing consultancy, and so on. Therefore, controls and oversight need to be in place to allow the firm to monitor the supplier to ensure they do what they have committed to in the contract. For example, are support calls being responded to per schedule? Are there issues with the hosting? and so on. If there are issues then these need to be escalated to senior management at both the supplier and firm.
• Change control process—Bots will need to be added, updated, or removed. This could cover activity as part of the implementation project or part of business-as-usual running. Therefore, there needs to be a process to ensure changes are made safely to ensure existing bots are not impacted adversely. Depending on the involvement of the supplier (such as hosting the platform) then they may need to be involved as part of this process.
• Policies for the development of bots—Good standards need to be created around the development of bots. This will cover programming standards, integration standards, information security standards, testing standards, version control, and release procedures. Depending on the involvement of the supplier then the supplier may need to be involved as part of this process.
Ensuring the Firm has sufficiently skilled staff to Support RPA once the Project Completes
A dedicated project team will have been formed to implement the initial RPA project. This will have consisted of senior management to provide oversight and steer plus many “on the ground” people who would perform the developments, integrations, and so on required. This group of people would have been sourced from in-house staff, contractors, consultants, and possibly staff from the platform vendor.
Therefore, firms must develop the necessary skills to be able to support the RPA platform once the project closes, because otherwise they will be reliant on external contractors and platform vendor staff. This means that senior management will need to be educated on understanding RPA and its benefits at a general level. Also, more junior staff will need to be trained on RPA, the specific platform selected, the integration with back-end systems as well as the suite of bots developed and rolled out as part of the project. This training can be done by training existing staff but it may also be necessary to recruit new permanent staff with the required skillsets.
Table 8.1 Future challenges of robotic process automation
Case Study
A firm used RPA to improve its Know Your Customer checks.
Originally, the process was very heavily based on slow manual processes. The customer would send in their application electronically and the firm then had to cut-and-paste data from the application form into a web portal (owned by the KYC provider) who would then process the application and then e-mail back their response. These responses would be manually collated and reviewed by the business teams.
RPA was used to automate the process. The customer will still send in the electronic application form but it would be sent to a specific e-mail address where a bot would capture it, extract the required data, and automatically populate the KYC provider’s web portal. When the KYC portal has a response then it would be e-mailed to another specific e-mail address where another bot would capture it, collate the responses, and send them automatically to the business teams for processing.
The implementation of RPA made a “clumsy” process much more robust, quicker, cost-effective, and scalable.
RPA is a very helpful emerging technology that allows firms to implement workflow (with the associated efficiency/control improvements and cost savings) without having to implement full workflow systems and the associated technology rewrites. It also provides benefits to customers and supports the products that firms offer.
However, it is important that while RPA is similar to implementing an enterprise workflow system, it is still a complex implementation and should be treated with the same amount of respect. If RPA is implemented poorly then it will cause problems with processes which (apart from increasing the complexity of the operating model) could cause material errors. Also to allow the cost savings to be made then firms may need to make staff redundant which will require careful and tactful management.
Therefore, firms need to have a clear business reason supported by a clear set of success criteria and a business case to support the implementation. While RPA provides costs savings in the long term, there will be a large up-front spend and implementation effort to implement the platform.
RPA only really works well on processes that can be defined easily and codified. Processes that cannot be codified easily (such as dealing with complex client questions) are not suitable for RPA.
RPA is also reliant on clean, timely, and accurate data. If the data is poor then the processes will not operate as designed which will cause problems.
Firms need to clearly define the operating platform for RPA. Most platforms are provided by third parties. So the vendor has to be carefully selected to ensure it is a strategic vendor that the firm will be able to work with in the future. The hosting of the platform needs to be investigated because both in-house and external (including Cloud) hosting has its own set of advantages and disadvantages. An effort will also be required to integrate the RPA bots with any existing back-end systems to allow the processes to work.
In addition to the technical aspects, firms need to implement oversight over the daily usage of the platform, any suppliers involved, change control processes, and policies to manage the development of bots.
It is also good practice to roll out RPA bots in a phased prioritized approach with the processes that offer maximum benefit being first. This approach will hopefully ensure that the project delivers some immediate benefits which will create goodwill, momentum, confidence, and some initial project payback.
Finally, there are no specific regulations concerning RPA at the moment (apart from the general need for firms to ensure they have a robust operating model). However, if RPA becomes more mainstream (or there are some major issues with RPA) then the regular will no doubt start to look at implementing regulation.