Advice on organizational traps by someone who’s been around the RPA block.

Having worked in a few sizable companies during their Robotic Process Automation (RPA) journeys from inception to maturity, I have not only been in the pit of these RPA traps but also clawed back into the safety perimeter.

This article, therefore, is based on what I’ve seen in organizations that I’ve been attached to and what I have heard from colleagues in the industry. These traps examine the macro level as a holistic organization and do not apply to individual processes or coding practices.

First things first. A quick intro and/or refresher to RPA.

What is Robotic Process Automation (RPA)?

This technology can automate any rule-based process across multiple applications. Once a Deloitte consultant told me to think of RPA as “macros on steroids.” RPA is the behemoth of all automation.

Most RPA vendors are also partnering with Artificial Intelligence (AI) players or building their own AI components to be able to automate end-to-end processes. Soon this technology will have you saying adios to any tedious, repeatable tasks that you’ve been doing at work. Who wants to do these monotonous tasks anyway?

Can startups also implement RPA?

Most definitely. Startups have a multitude of mind-numbing tasks that can be automated from the get-go. A few areas with automatable tasks are vendor management, accounting, purchase order management, refund approvals, and complaint management.

In addition, if a startup has to wade through and process acres and acres of data in multiple applications, RPA will help save valuable time for the team.

Some companies on the offense have dived into the deep end of RPA before their competitors only to find that they need to swim back to the three-meter range. On the other side, risk-averse companies have been lounging and watching the swimmers, making note of the drowned.

Trap #1: Planning to Fail

Most companies start off with a proof of concept to see what RPA can do. But they don’t move out of that stage soon enough although the number of bots increases with time.

Not having the right resourcing strategy

Although RPA is not rocket science, the right resources need to be engaged. These resources will have a keen interest in driving efficiencies for employees, possess a good understanding of business processes & underlying technology, and be very comfortable with ambiguous decision-making and learning as you go.

Additionally, the company will need to decide on the structure of the RPA team, and in-house vs. outsourced composition. How soon should the in-house team be ramped up in numbers as well as in skill level? Should the interviewing strategy change to accommodate to the needs of these new roles?

My recommendation is to have a highly-skilled, core internal team at the beginning and then the team can be ramped up along with planned growth in the number of bots.

If automation is going to be a core functionality of your company — and it should be because there are so many long-term benefits to automation — having a capable and skilled internal team will be beneficial even if you settle for a partially outsourced model because external parties can only do so much.

Not getting technology onboard soon

In most instances, I have seen the business leadership forging ahead with automation because they are not only excited by the capability of automation but are also fed up with the bureaucracies and siloed, slow nature of their technology counterparts.

The danger of this approach arises because automation like all other technologies needs servers, databases, access management, and networks, and these are under the purview of technology teams. Without this ecosystem and support from the techies, automation cannot make significant waves as intended.

This is why it’s critical to bring the technology teams along on your automation journey. At a minimum, they need to be pulled in — sometimes even wrangled — after the proof of concept has proved the capability to the business but before finalizing a vendor. They will assist with narrowing down the right vendor in terms of the long-term technology needs of the company.

Trap #2: Growing Too Fast

Most leaders take the number of bots as a key performance indicator for the RPA function. Although it’s good to announce to the world that we have 100 bots aka digital workers, it’s worth asking whether all 100 bots work fairly seamlessly. Are the promised benefits being delivered to the business process owner?

Although it is tempting to go by the number of bots in production, leaders have to use balanced indicators and couple them with the number of production incidents for each bot or the downtime for each process. This will give a holistic view of the health of bots.

In my experience, attempting to grow too fast is one of the reasons for RPA to fail in companies. Growth should be sustainable and allow for the RPA team to tackle all the moving parts that are inherent in these projects.

Other considerations like ongoing application upgrades, changing business needs, required governance structure, and industry trends beg for a slowing down of growth by allowing teams to think through an optimal long-term strategy for RPA.

Middle managers, who are closer to execution, are responsible to inform and influence their leaders on the need for sustainable growth and the dangers of going big too soon. They can employ past data, cautionary stories, or competitor anecdotes to influence leadership.

Trap #3: Promising a Quick Efficiency Haven

On implementation time

The general industry perception is that a bot can be implemented in 8 weeks or less. This is a quick win, and everyone feels giddy with productivity highs, given that most other technologies take years to implement.

In my humble experience, 8 weeks is doable only for simplistic processes that don’t need complicated logic and are local to one or two applications. Or 8 weeks may be possible for moderately complex processes where the team is 100% dedicated to this one project, which is also a rarity in today’s corporate world.

What about the best coding practices and the security needed in terms of audit trails and access management? And the extensive testing that’s needed to ensure that the bot can not only deliver expected functionality but also handle frequent errors and load. There’s a lot more to developing a bot than the happy path.

After the bot goes live

After the bot is alive and kicking, it hiccups a bit at the beginning and there will be wrinkles that need to be ironed out. Process owners should be educated that the first few months may not be smooth similar to any other technology implementation. Therefore, benefits realization is also generally not immediate.

In addition, when more users start consuming the bot output, ‘new’ production issues may arise in terms of load or specialized data. New users will also provide suggestions that can improve the solution manifold. These will need to be prioritized and implemented to refine the bot and drive user adoption.

Trap #4: Ignoring the Ecosystem

As you can see by now, RPA cannot and does not exist in its own box. RPA works on top of existing applications, servers, and networks. Therefore, any change or issue in the RPA ecosystem can have an adverse impact on the bot.

I have seen bots breaking down in production due to unannounced application changes or monthly windows updates that “should not have impacted the bot”. Bots can also be impacted by slow networks or jarring servers wherein, the bot waits for a certain screen to appear for a while and then times out.

To quote another example, when the security teams implemented multi-factor authentication one bright morning, none of the bots were able to log into their respective systems and/or machines because they did not have phones or emails to retrieve the security code from.

In the development phase, the code should be created as robust as possible so these impacts can be curtailed as much as possible. The changing ecosystem needs to be evaluated periodically and possible risks should be documented with risk owners and reaction steps.

The level of coordination and communication flow required from all parties of the ecosystem is plentiful for the smooth-running of a bot in production.

Trap #5: Forgetting the People

During my decade-long journey in business and technology functions, I have never been in a role that needed more stakeholder management and collaboration than in my RPA roles.

Not only have I had to build genuine partnerships with various teams in technology (windows, security, network, and application teams), but I have also had to manage business stakeholders from analysts executing processes to their directors investing in automation.

This is a tough bunch to please simultaneously.

Although at the heart of RPA, the goal is to enhance employee engagement and customer experience, and thereby, gain a competitive advantage, it is easy to get caught up in the shiny technology that makes everything automatable.

I have seen many leaders lose sight of people who use these bots and people who make these bots come alive. Empathy for bot users and recognition of bot-makers are essential stops on this journey.

Forgetting this web of people is one of the biggest traps of an RPA project. To guard against this, stakeholder management and change management should be baked into the project plan in addition to project development activities. Heightened interaction and collaboration with stakeholders will give rise to gold nuggets of information that hardly bubble up officially.

Empathy should also be a mandatory tool in the project team’s arsenal as most process owners fear the loss of their jobs and do not want to cooperate in automating their tasks. Their concerns need to be addressed by their leaders and the project teams need to understand the ground situation. Empathy maps can also be used to understand the emotions of your stakeholders.

With the spread of Coronavirus-triggered working from home programs, having digital workers to carry out routine tasks seem like a no-brainer. I strongly believe that every company, big or small, needs an RPA strategy now as the bots are surely coming (if they have not already invaded). Without embarking on this journey, your company will lose out to competitors.

Knowing these five traps and taking them seriously will help you plan for what’s coming. Avoiding these traps will let you reap the most long-term benefits in the game of RPA and enable you to plan for success instead of failure.

Thank you for reading. If you have any questions or thoughts, please comment below.