When it comes to banking and finance, robotic process automation or RPA’s star continues to rise.
Recent Australian figures by Gartner show that most large banks will adopt it “in some form by 2023”.
In fact, “the earliest adopters were custom-building RPA functionality [long] before commercial offerings became available,” Gartner notes. “As RPA reached a tipping point in market acceptance in the early part of this decade, many more mainstream adopters began rolling out pilot projects. Even the most conservative banks are expected to begin experimenting with RPA within the next four years.”
The rise of robotic process automation is significantly linked to a desire to target and reduce technical – process – debt.
Internal processes built up over many years, by many people, inherently contain inefficiencies, such as the inclusion of too many steps to reach a conclusion. These steps can be individually reworked, removed or replaced using software bots and other forms of intelligent automation.
Or at least, that’s the theory. In practice, how RPA – and automated intelligence, more broadly – is inserted into an end-to-end process is fast becoming a key determinant of success.
Splitting RPA
Two types of RPA have emerged. First, there’s the type that almost everyone knows and associates with RPA, which automates actions on behalf of a user through a user interface. This usually takes the form of a software bot that steps through a sequence of events to upload a file or go through some logic check before authorising a procedural step as complete. The second type of RPA is an automation that is connected to a process via an application programming interface (API).
In other words, where the automation lives with respect to the process step or portion of the application it is automating can have a significant difference on the outcome.
I often wonder how many companies that adopt RPA are aware of the technical debt they’re potentially taking on through their automation choices.
Technical debt is a concept used to describe code that embeds inefficiency and extra work into internal processes. This can then be hard to unwind or rework, and hence its cost to the organisation continues to compound.
RPA that automates the points and clicks of an end user can create technical debt, because the user interface isn’t static. It is going to be modernised; new menu items will be added, old items removed, it may be refreshed or reorganised. There’s going to be all kinds of changes, and with Agile, iterative development in vogue, changes are occurring at higher frequencies.
When you have a bot looking to click on a certain location under certain conditions, and that location is redefined in the user interface, the automation breaks. Therefore, every change to the application or interface that RPA is directly injected into requires a time and money investment into retesting the automation to ensure it still functions as intended. That gets tiring and expensive quickly.
By comparison, APIs are written to be largely unchanging – something an application can rely on over the course of years and even decades.
Once a company exposes an API, it should be set in concrete. As long as the application exists, the APIs will continue to exist. You may put out new versions of the APIs, but they will need to support backward compatibility. In this scenario, if the application underneath is modernised and upgraded, automations that are written to APIs will continue to work. There is a greater degree of assurance that your automations will not break.
Australian companies are becoming much more aware of the challenges posed by different modes of automation.
Within the next year, I expect it to be front and centre in the automation strategies of finance firms across the country.
Trumped by native
However, it may also be that automation injected directly into an application or via an API has run its course.
I would argue the future of automation lies in the extent to which it can become embedded into core finance applications. That is, automation becomes native to the application, instead of a bolt-on (or bolt-in).
When you embedding AI inside the application, you have the opportunity to take advantage of workflows that might be broader than what a point solution might be able to take advantage of.
Embedded AI also allows the AI/model to take advantage of all data in an application. By contrast, RPA, which sits on the outside of the application looking in, only has access to a limited number of touchpoints in the application and certainly not the whole dataset.
There are considerable advantages to being integrated more deeply – and natively – in the application, and we believe there is growing recognition of this. It’s certainly something that BlackLine is investing in, and we would expect the general market to follow.
Pete Hirsch, chief technology officer, BlackLine
