The dos and don’ts of RPA: How to avoid automation spaghetti and generating more technical debt

If I were building a new organisation’s architecture from the ground up, there should be no need for RPA. I would select the right modular Enterprise tools for each process and ensure seamless handovers between the systems. Perhaps I would deploy a single ERP solution which could cater for every process.

I sympathise with enterprise architects who recoil away from RPA as a ‘lesser’ tool, fearful of its lack of structure and control.

But the reality is often somewhat different. Partly because we’re frequently limited by funding or timescales, but more often that organisations inherit systems from mergers and acquisitions, or flawed or siloed decisions have been take in the past.

Perhaps the architectural landscape does not extend to all aspects of the user journey, especially at the initiation of processes which may be voice led or other similarly non structured data.

Perhaps there are gaps between systems that need to be bridged to avoid manual swivel-chair activities.

Perhaps the constant change and upgrading of systems means that there are always some processes which fall by the wayside, the long tail of transformation.

I too, would be reluctant to relinquish control of systems to ‘citizen developers’ and let all hell break loose.

So, when and how should we use RPA?

Firstly, there must be a strong governance framework in place covering standards, tooling, process identification, qualification, methodologies, resources, service management, testing and so on.

Secondly, RPA should not be used as a strategic solution – in that no one bot should be a long term solution for a critical process. Bots should operate for long enough to pay back, but not so long that they become permanent by default, however reliable they may be.

Often, CoEs have substantial FTE savings targets, and this drives a ‘shotgun’ approach to automation; automating anything that moves, but this behaviour is disingenuous. RPA should be used sparingly, and only when appropriate. It can indeed solve significant business problems and bring substantial cost savings, but bots should only ever be tactical, and any organisation is fooling itself if it thinks RPA will deliver a viable alternative to a robust enterprise application.

This is why we see so much disillusionment within the industry, because CxOs have been led to believe that RPA is the silver bullet – it isn’t; but it is a very powerful sticking plaster, or a crutch, and we all need temporary fixes and bridges as our organisations manifest and grow, and there is no shame in admitting this. RPA can help us deal with change, and change is a fact of life.

So, to get back to the original question, does RPA contribute to legacy technical debt? Well, it can do, if it is used without analysing the alternative solutions, or seeing the big picture. Uncontrolled application of RPA can result in automation spaghetti, a mess of loose ends, an architect’s worst nightmare.

?

Conversely, a well governed CoE working hand in hand with enterprise architects can have a highly effective strategic programme deploying tactical bots to bridge gaps in systems and processes until a more permanent solution is found, whereupon the bot is retired.

The overriding principles here must be:

1.?????? Manage RPA delivery in a coordinated and controlled manner through a Centre of Excellence

2.?????? Do not drive shotgun automation behaviour by imposing a challenging financial or FTE target on the CoE, instead use other KPIs measuring quality of delivery

3.?????? Work hand in hand with Continuous Improvement and/or Enterprise Architecture to assess automation opportunities

4.?????? Have a set of criteria that opportunities must meet before being considered for automation, and stick by them

?

RPA can be a valuable tool for improving efficiency and reducing costs, but it should not be seen as a permanent solution or a replacement for proper enterprise architecture. By following the principles outlined in this article, organisations can use RPA wisely and avoid creating legacy technical debt that will haunt them in the future

?