Putting the Process Back in RPA

The importance of innovation and strategy can hardly be overstated. However, large successful enterprises thrive on mundane. By efficiently executing the mundane aspects repetitively at scale, large enterprises profitably grow and expand.

Enterprises have accomplished this in three ways.

• One, by training an army of workers to perform well-defined repetitive tasks efficiently.

• Two, by automating wherever possible to remove human workers from these repetitive, routine, (and, boring) tasks – achieving faster turnarounds and tireless scalable operations.

• Three, by eliminating waste from the process, thereby achieving the same or better outcomes with lesser effort, time, or resources.

The first two provide efficiency. The third leads to better effectiveness.

The Quest for Operational Efficiency and Velocity

Enterprises have, from the ancient times (think, Pyramids of Egypt), relied on deploying a large army of cheap labor (and training them relentlessly) to accomplish this. The quest for cost and operational efficiency has led to many stages of evolution: assembly lines, process outsourcing, offshoring, and now, reshoring – based on a combination of large armies and labor arbitrage dynamics. Here, we’re not talking of process effectiveness yet, but plain operational efficiency, i.e. faster and cheaper. But, this approach to efficiency has reached a plateau.

No matter how well human workers are trained and no matter how committed or hardworking these workers are; Eventually, they get tired, they commit basic mistakes and they lose their motivation performing the mundane, boring, dull tasks over and over again. There’s also a limit to replaceability of a human worker by another.

Just as machinery and robots replaced human blue-collar workers in manufacturing, robotic process automation (RPA) has made it possible to replace humans with bots in white-collar tasks. RPA is effective when used in a well-defined set of tasks that are executed at scale. Enterprises are replete with such tasks. For large back-office processes that are full of such tasks - static, well-defined, repetitive, error-prone, subject to audit – RPA is a mainstream option today.

RPA is a mainstream option today, But…

When we say that RPA is a mainstream option today, it also means that enterprises are looking at practical implementations to make it work in real scenarios at scale. Enterprises are slowly learning that RPA is not a panacea for all situations of human inefficiency. RPA projects, just like any other major enterprise initiative, need to be backed by a clear strategy and good governance.

Enterprises must attempt to answer a few questions when it comes to implementing RPA effectively.

A Question of ‘What if…’

Prima facie, many tasks and activities look ripe for RPA. The devil, however, lies in the detail. And, it’s the innumerable ‘what-ifs’ that have the potential to derail most RPA projects.

• What if, the documented and defined tasks are not 100% accurate?

• What if, the workers handle more exceptions than is documented, visible or tracked?

• What if, the screen or form or report being robotized is prone to change every three to six months, due to change in compliance requirements or just plain business dynamics?

• What if, faster execution of a task results in a bottleneck down the line, rendering the whole exercise futile?

Before embarking on a task level automation, it’s critical to answer these what-ifs.

A Question of “A Series of Automated Tasks” v/s “Automated Process”

A fundamental concept needs to be understood and acknowledged. A process is a set of actions and rules that lead to an outcome. RPA seeks to automate a series of actions into a script that can be executed repeatedly and consistently to achieve an end objective. However, a process is larger than simply a set of activities. It includes rules, forms, actions and exception management, all built-in to achieve the desired outcome. Unless we look at the holistic process, we risk creating bottlenecks downstream in the process.

It’s very similar to a situation where a flyover built to smoothen traffic creates a new choking point on the next road crossing. An automated process would mean that not only are the tasks automated with RPA, or rules engines, or straight-through processing), but the overall process is also orchestrated to effectively lead to the intended outcomes.

It doesn’t mean that RPA doesn’t contribute to process efficiency. What needs to be acknowledged is that RPA is much more effective when governed by an overall process that is orchestrated well, simply put a process that is automated and not just tasks.

A Question of Doing Things Right v/s Doing the Right Things

This brings us to a fundamental question of process effectiveness. If you recall, we talked about three ways in which enterprises have approached ‘margins’ and ‘velocity’. RPA contributes to the first two, i.e. deploying an army to perform the repetitive tasks more efficiently and removing humans from the equation as much as possible. That addresses efficiency.

The third was – elimination of waste in the process, which has to do with effectiveness.

This is where it gets tricky. Implementation of RPA can make individual tasks better and more efficient. However, that can change quickly, the moment you go one level up and find out that the real issue was with the task itself and it never needed to be done the way it was being done or was redundant in the first place. Identifying these issues requires a broader process level mindset.

Often, technology leaders tend to perceive process-based transformation efforts as a long-drawn affair. However, a process mindset doesn’t have to be a complete top-down approach. Enterprises don’t have to necessarily start a BPM implementation with the highest level of end-to-end processes. One can implement workflow automation – supported by a good BPM platform - at just one level above the tasks being automated with RPA, for a start. This addresses the effectiveness question, along with efficiency. Process automation also provides multiple other advantages of monitoring, auditability, manageability, and governance.

A Question of Proof-of-Concept (PoC) v/s Pilot v/s Production 

Enterprises often take the route of a proof of concept (PoC) to understand the potential benefits of RPA. They also often take on a pilot approach by implementing a small process with a limited scope and volume to assess the viability in real-life use cases. This is a good approach to take with a new/ unknown technology. RPA has shown benefits for most of the pilots that have been undertaken.

However, enterprises also need to reflect on the kind of problems that can come with scale and volume. While bots provide a level of consistency, repeatability, and scalability, they need to be monitored and managed as well, albeit a little differently from human workers.

Enterprises are realizing that dealing with thousands of bots is harder and more complex than they envisaged. Exceptions of all kinds, technical and functional, kick in. Tasks may need to be prioritized or de-prioritized based on the need. Additional monitoring and intervention mechanisms are needed to ensure smooth operations. Also, most tasks that look highly structured have some bit of unstructuredness that humans can effectively deal with and hide them well within voluminous operations. Additional focus and effort are needed to manage these scenarios, especially at scale.

So, it’s necessary to plan and account for these aspects of RPA when implementing it in production. Hence, RPA implementations often require a broader IT and process management strategy than enterprises realize at the onset.

A Question of ‘Shadow IT’ 

Which brings us to the role of IT in RPA implementations. The underlying promise (as well as the premise) of RPA – fast ROI of task automation without disturbing the IT backbone – is where some of the long-term potential issues arise. Business teams often go ahead and start a pilot and implement RPA in a localized manner, keeping the IT ‘informed’ or ‘consulted’, and avoiding the longer route of assessing the impact on IT infrastructure. This is similar to the “Lotus Notes syndrome’, where scattered and fragmented applications built by functional teams on Lotus Notes, in nooks and corners, became an IT infrastructure issue in the aftermath. RPA implementations can potentially lead to such ‘Shadow IT’ situation in the long-term if not managed well.

As RPA becomes mainstream – meaning, more and more enterprises have reached a stage of real, high volume, large-scale implementations – what differentiates successful ones from others is the consideration of longer-term aspects in early stages. It’s important to balance speed, flexibility and long-term considerations (on both technological architecture as well as process architecture) when implementing RPA.

In Conclusion

To sum up, while enterprises look at RPA for a quick ROI, successful implementation requires that enterprises balance it against broader considerations. And, the most important aspect of doing RPA right is to know where RPA fits in the scheme of things – at the process level as well as the IT infrastructure level.

By Virender Jeet, Senior Vice President (Sales & Marketing / Products) Newgen Software