SGV hosted the EY Round Table on Intelligent Automation this week. The forum featured the Department of Science and Technology’s perspective on the latest global trends presented by the eminent Dr. Carlos Primo David, Executive Director of the country’s Innovation Council. There was also a heavy focus on Robotic Process Automation or RPA.
There’s good news and there’s bad news.
The bad news is that the concerns raised during the Round Table demonstrate that most Philippines-based companies have really just started exploring or, at best, beginning to implement their Robotic Process Automation(RPA) initiatives. This at a time when Bloomberg reports that the old boys club of bond jockeys, derivatives traders and stock pickers in Wall Street are already being steadily replaced by robots, oftentimes with components of predictive analytics, machine learning, and natural language processing. Indeed, there’s a growing consensus that intelligent automation (i.e., automation with some artificial intelligence) may be the next game changer in financial services and the presents a viable foot-in-the door for many emerging fintech companies.
Robots Are Coming for These Wall Street Jobs
Nevertheless, amidst the success of a few companies globally, a whole lot more of RPA programs are stillborn. There has been a lot of hype from technology solutions providers that led to over promises and under delivery. Forrester’s Craig Le Clair notes that the early enthusiasm for RPA has led to ” a tapping of the brakes due to infrastructure, business and operations concerns.” Nonetheless, there have been valuable lessons that first movers are learning from quickly.
The good news is that second movers – like Philippine companies – can also benefit by avoiding the landmines that have recently come to light.
Some limitations of RPA
RPA represents significant, if not revolutionary, process innovation but we need to be aware of its limitations at its core, i.e., without the turbo power of AI. It is easy to be beguiled by the power of AI but when we start off on the journey, it is almost always on projects that require only straightforward RPA minus the bells and whistles.
So what do we need to be aware of on day one?
Robots do not understand data
Robots do not understand the underlying data of a transaction the way that human processors do. It is indeed useful that in many instances, they do not have to – they only need to understand how to execute the process. (In processing an invoice, a robot will not understand that we have bought party favors for the office Halloween get together – which will bring a smile to the human processor. Or that we bought an automated sorting machine that will replace Manong Jose in the Warehousing Department – which will make the human processor skip a heartbeat. The robot will merely systematically sort each invoice according to its amount and product/service category and route it to the authorized approver.)
This raises a key question that needs to be asked before we apply RPA to a process: Does this process require an understanding of data on top of an understanding of process? If the answer is yes, tread carefully.
The typical way that robots manage to navigate a data-rich or information-rich process context is by substituting the need to understand the data with an (often complex) set of decision rules that will guide its processing sequence. The capability required thus is the ability to build those complex rules and to maintain them over time. This can be a big challenge in a dynamic environment and can have significant implications on the size of the RPA support teams required.
Robots are only as good as the underlying process
The innovation that RPA brings into process automation is the ability to reach into any given user interface – effectively allowing software to drive software within procedural or rules-based processes. This means, though, that the robot is only as good as the underlying process. It almost always introduces massive efficiency but does not enhance the process in any other way.
Some companies derive a false sense of security, believing that robots do not commit errors. This is true only in the narrow sense that a robot will execute a process perfectly as designed – even if the design is flawed. If points of failure exist in the process today, the points of failure will remain. The likelihood that errors creeping into a process will remain unchecked increases exponentially unless the point of failure can be mitigated.
There is often an inordinate rush to implement RPAs to resolve growing bottlenecks in operations and to relieve delivery teams from their daily stress points. The haste will unfortunately lead to much waste unless an end-to-end process review review precedes the introduction of RPA. This should be strictly adhered to as part of RPA governance.
Robots are not a panacea
While different RPA software offer a variety of functionalities on top of the core robotics capability, all are designed to take on manual, routine, repetitive and high-volume tasks. This creates a tempting proposition of trying to apply RPA to all tedious, manual work. An old adage says that if your only tool is a hammer, you tend to view all your problems like a nail.
The end-to-end process review should provide a better view of the automation that fits the requirements and is another reason why this step should precede a decision to employ RPA. Some of the likely misapplications of the technology include:
- Downstream manual processing results from upstream data capture errors: Is it better to use digitization technology upstream instead of RPA downstream?
- Non-integrated applications in the process: Is there an ESB that can perform the export, transport and load (ETL) function? Alternatively, do we use an API to connect the systems instead of creating an RPA overlay?
- Downstream data consolidation and reporting from multiple systems: Do we use desktop automation tools such as Open Span instead of an RPA tool?
Organizing for RPA
There has been much speculation lately that BPO jobs are at risk. The consensus within the IBPAP is that the transition from a human workforce to robots is inevitable for much of the lower value work that we handle, although there is little clarity on the possible timelines. The best time to get started, of course, is now. Mary Beth Jameson of RSM Consulting (RT & Co. in the Philippines) provides some guidance for mid-sized companies seeking to get started with RPA on the right foot.
Five guidelines to get started by RSM Consulting
In addition to these guidelines, let me add a few more:
- Getting the most bang for the buck
A process with fully digitized inputs will enable seamless automation and optimize the reduction of manual work. Conversely, if not all the process inputs are digitized beforehand, the upside potential for workforce reduction is limited.
In turn, full digitization requires that the minimum upstream controls should be in place. Otherwise, it represents an enticing invitation to fraudsters to test their mettle.
- Robots on the loose is dangerous
Forrester Research observes that RPA Management and Governance is typically an afterthought even though it should be a primary concern for the enterprise embarking on automation. The company rightly points out that governance should be anticipating the time when human process knowledge has all but disappeared as this knowledge is programmed into a robot.
- Managers shouldn’t play the blame game
Managers should avoid the temptation of forcibly squeezing out the targeted FTE saves for any particular automation initiative – in the process making compromised control points more likely. Be mindful not to take the process owners and the transformation team to task in the instances where the original efficiency targets need to give way to more pragmatic and realistic targets. When we view automation as a program, the over and under-achievement of targets will tend to wash out over time.
One of the biggest mistakes you can make is to prescribe RPA as a panacea for an organization’s problems. The solutions that an organization adopts depends as much on the nature of the problem as the existing strengths of the organization.
Is RPA right for you?
I’d be happy to hear your thoughts.