Guest Column | June 13, 2021

4 Pitfalls to Avoid When Scaling RPA

By Ivan Kot, Itransition

4 Pitfalls To Avoid When Developing GCP SOPs

There is little doubt about the value of RPA services. When companies embark on the RPA journey, the returns are usually not long in coming. However, without a comprehensive plan for scaling their RPA implementations, companies might fall short of their ROI goals. Let’s discuss the most common pitfalls that hinder RPA scalability and figure out ways of overcoming them.

The ‘Low Hanging Fruit’ Approach

A conventional RPA journey often starts with automating the processes that can bring the highest ROI in the shortest time. This specific approach has proven to be extremely effective as it encourages stakeholder buy-in and lets the company quickly familiarize itself with RPA possibilities. However, without a clear plan, such a method often leads to companies struggling to scale RPA as they continue to look only for these easily automatable processes with the quickest returns.

Unsurprisingly, after one or two years into RPA adoption, organizations can be left with no more processes meeting these criteria. Most importantly, this ‘low hanging fruit’ approach makes it hard for companies to capture RPA’s bottom-line effect as it is at its most effective when it comes to starting RPA implementation, yet is the least effective for scaling.

In most cases, it is best to focus on automating by departments. This can be mathematically explained. By focusing on automating ‘low hanging fruit’ tasks, we can cut 50-70% of the time it takes a department to complete each of such tasks. They, however, usually represent 10-15% of the whole scope of departmental processes.

­Now, if there are hundreds of employees working in a department, such an RPA implementation strategy can contribute to 15% of overall time reduction on average. However, if we automate the majority of tasks that employees are involved in, while cutting as low as 10% of the time spent, RPA can cut 20-30% of total time expenditures in the entire department.

Lack Of Change Management

Unfortunately, for many companies change management is an afterthought. With no change management strategy, though, any technological innovation makes employees anxious. Moreover, the lack of technology understanding often leads to teams struggling to fix simple RPA issues, causing frustration.

Instead of a reactive approach to reskilling and upskilling your workforce, training should be at the core of an RPA strategy. The skillset required for building and maintaining RPA tools can be rarely found in-house. Additionally, justifying the cost of creating a Center of Excellence (CoE) with no definitive long-term plan can be hard.

This is why organizations that have the most success with RPA opt for a hybrid approach. They leverage the business expertise of their existing teams and combine it with the knowledge and resources of an experienced vendor to ensure smooth implementation. Thankfully, most RPA vendors like UiPath offer a comprehensive list of training tools and certifications, allowing organizations to design clear roadmaps for their internal training programs.

By adopting a change management strategy, companies will communicate their serious commitment to automation and facilitate the workforce’s enthusiasm about the technology. Later on, this usually results in each department having a definitive RPA ambassador, aiding in the creation and operation of a dedicated CoE.  

Lack Of IT Readiness

Companies’ reluctance to involve IT can be explained by the lack of technology understanding. One of the most apparent RPA advantages is that it’s non-invasive, meaning that it can interact with legacy systems at the user interface level. Moreover, some RPA bots can be configured using drag-and-drop tools. That’s why IT departments tend to believe that RPA is some kind of a ‘screen scraper’, which doesn’t require any significant support. In practice, this notion has proven to be false time and again.

For example, after one financial institution had automated some of its transaction processing tasks, the sudden bump in transaction output had triggered an IT security system. Also, bots often require access to multiple systems, requiring IT involvement to configure them. And, given that RPA scaling implies automating more complex processes, establishing isolated testing environments (the IT’s job) is an integral part of the implementation. In general, the IT department has a more holistic view of the company’s digital ecosystem, making it far better suited for ensuring that RPA implementation adheres to established security practices.

Lack Of Stakeholder Buy-In And C-Suite Involvement

The same strategic vision shared among all the relevant parts of the organization is essential for scaling RPA successfully. While team managers can see the exact value of RPA implementation, other stakeholders, particularly C-suite, might need additional guidance to understand both tangible and intangible values of RPA. Once secured, executive buy-in will help to overcome potential organizational hurdles, like those arising during cross-functional team setups.

Conclusion

While the short-term benefits of small-scale RPA continue to draw the attention of executives, the real potential of RPA can be realized through enterprise-wide RPA strategies. Relieving only a handful of selected employees from mundane tasks neither contributes to a healthy working environment nor significantly affects the bottom line.

At the same time, organizations can achieve better efficiency and capture significant competitive advantages based on C-suite and IT involvement, a strategic long-term vision, change management practices, and an enterprise-wide approach to RPA implementation.

About The Author

Ivan Kot is Customer Acquisition Director at Itransition, focusing on business development in verticals such as eCommerce, Business Automation, and cutting-edge tools such as blockchain for enterprises. He began his career as a developer, taking different positions in both web and mobile development projects, and eventually shifted focus to project management and team coordination.