By Kit Cox, Enate CEO and Founder
For those who are familiar with the RPA industry, you’ve probably seen Gartner has recently released its ‘Magic Quadrant’. An interesting observation Gartner made was that deploying RPA involves building up a lot of technical debt… possibly more than most other technologies.
But, while RPA potentially creates more technical debt than other technologies, don't forget that not all technical debts are created equally.
If we think about 'real' debt, specifically, UK government debt. Government debt exists in perpetuity - it will always be in a budget deficit. The deficit can increase and decrease, but will never be zero.
But this isn't a significant issue. The UK government debt is 'democratised debt': it's paid down by the 60 million people who work in the UK.
Another type of debt most of us are familiar with is a mortgage debt. With my mortgage, I'm the only person that can take ownership of it, meaning it can potentially be more difficult to pay down and stay on top of the debt.
So, if we think about 'technical' debt, it's useful to consider RPA technical debt as a 'democratised' kind of debt. It can be paid down by multiple developers within an organisation making it much more manageable. That's compared to a lots of other technical debt that's monolithic, meaning it will weigh down more on an organisation.
I've had some great comments in response to this when I spoke about this on a video posted to LinkedIn:
Some of the comments:
"Great observation and you’re right on many levels. RPA has been used as the ‘sticking plaster’ to that monolithic core system debt you talk about. Line of business people go to IT and say “Can you get it to do 'this' instead of 'this' now. Our process has changed since we started doing this new thing we now sell?” IT say “Yes, in 18months and for £800k”. RPA just gave the business an opportunity to change their process for a fraction of the cost and time. On the ongoing costs of RPA, it’s the biggest areas people overlook. We call it ‘Run Management’. Very quickly in house CoE’s or RPA development projects get bogged down in maintaining what they have built so the roadmap of what could be done, doesn’t get done and it all stagnates - The ongoing maintenance of the automations isn’t factored in to the excitement of launching the first few. Secondly, because it tends to be launched outside of IT, it’s not part of overall change management, hence why the maintenance debt is higher. IT make a change to SAP, the automation breaks. IT switch authentication software, the automation breaks. The impact to automation is not factored in because IT don’t support the Automation estate."
"There’s a technical debt to agile delivery of automation. Deploying the MVP gets you live but unless you’ve careful planned and designed your build, and especially your exception handling, the operation can spend more time finding and fixing the exceptions than was saved by the automation. One also needs to consider the point of diminishing returns with agile delivery. Should you spend 10 days effort on sprint 4, which might only add 5% saving, or should you use those 10 days on the MVP of a new process? The answer is different for different organisations and processes, but technical debt is an important consideration."
RPA has a broader technical debt definition and it is not linked to the technology, where it's implements or who inherits it. It is linked to the merging of IT & Business and how previously non IT, business rules, are now digitised and require maintenance. Previously this technical debt was retraining staff. That business overhead has now transferred to a technical debt. My question would be what happens in 5 years when the business process knowledge leaves the business and the automation needs to change? That's a tricky debt to try and pay down on.
What are your thoughts and experiences with technical debt? Leave a comment below.
Don't forget that Enate's service orchestration SaaS platform handles RPA exceptions by flipping work back to a human. That means you spend less time hard-coding exceptions and more time automating to create greater value for the business.
Watch my video chat: