Identifying Corporate Escapism and Avoiding RPA Shelfware
Corporate escapism is a phenomenon that takes place in organizations of any size.
Escapism can happen for a variety of reasons. One example is when when leadership experiences the the ‘I-am-almost retired’ syndrome which results in bad short-term decisions that will harm the company in the long-term (Møller Institute, 2017).
Joe DiVanna, who co-authored the previously referenced paper, concludes that some people act as escape artists who deflect decisions to a later date or another group. Other lesser known authors, argue that consulting groups are in fact ‘insurance policies’ for senior management that only take leaders out of the cross-hair if things go wrong, but also serves as a means to ‘justify’ decisions they’ve made but cannot get buy-in at the board level (Have Any of You Snake-oil Salesmen Ever Actually Added Any Value to Your Client’s Organisation?, 2017).
RPA can serve as a shiny new ‘book’ for companies to procure, show off, and feel good about keeping up with the times. In this manner, it can serve as a textbook definition of 'shelfware.'
Automation consultants may also serve as those who help to justify technology licenses and associated project investments. Consultants then do the ‘reading’ of the books up on the shelf to make enterprises look like they are executing on their vision of the future.
When the results go well, leadership is happy to consider themselves as being successful, but when it goes wrong they write the consultants off as bad. In other cases, the technology is written off as not being ready for the market, or the company's industry not being fit for the tech.
Avoiding the RPA shelfware trap
A company that poorly manages its software assets and ends up experiencing application sprawl may be tempted to buy RPA to ‘glue it all together.’
Consider, for example, that some companies use a variety of CRMs (due to siloed departments that emerge because of company growth or acquisitions). Poor enterprise architecture, and a lack of planning, can result in many redundant systems that don’t speak to each other and aren’t properly maintained (Joch, 2020).
Buying additional software, in the form of RPA cannot solve the underlying problems of application sprawl. It's also not going to solve for champions that have left the company (which brought specific software in originally), poor documentation, or a lack of governance.
To avoid RPA shelfware, it should be introduced from an enterprise architecture standpoint and not a ‘business initiative’ standpoint. The business layer operates on the ‘front-end’ of applications and automation operates on the same level.
If enterprise architects decide to pull the plug on systems, bring in new integration solutions, or otherwise change the foundational ‘back-end’ of the enterprise, then RPA benefits will be lost along with the time, money, and reputation that was invested in ‘piece-meal glue.’
I've seen this happen in the middle of projects because the business thought that they didn’t need to involve IT heavily in their consultant-driven implementations. Such a parallel workflow, between the business, consultants, and IT, causes double, or sometimes triple, work efforts and isn't sustainable in the long-term.
The only thing worse than leaving ‘RPA’ duct tape on the shelf is using it for everything…
Applying RPA to all problems is less tempting to companies that dip their 'toe in the water' rather than diving into costly RPA licenses. If companies stopped and noticed that competitors who have succeeded in RPA ‘maxed out’ their opportunities after building anywhere from a dozen to a hundred processes — they'd realize that the growth rate isn't infinite. It’s a classical ‘putting the cart before the horse’ problem.
Avoiding consultancy-based corporate escapism
Another way for the business to avoid RPA shelfware is to refrain from signing contracts for RPA consulting.
Outsourcing enterprise architecture to vendors won’t get you far because you’ll be paying them a premium just to learn about the environment, the gaps, and the solutions that are planned by your company — which often have nothing to do with RPA. Not to mention that your team members already know the ins-and-outs of the software and you're missing out on the benefit of including longstanding employees in the evolution of the enterprise (Fragile to Agile, 2014).
The best way to avoid consultancy-based escapism is to create accountability for strategy and automation projects internally. Companies will get a lot further owning their automation future than outsourcing it. This can be accomplished through:
- Entrusting an IT team with standing up RPA capabilities after getting buy-in
- Establishing a process improvement group within the business to partner on opportunities
- Establishing an RPA governance body
If you want to read more on the dangers of relying on consultants for business strategy, then you may want to refer to "The Trouble with Strategy: The brutal reality of why business strategy doesn't work and what to do about it" by Kim Warren.
Beware of the RPA status quo bias
If executives make decisions based on cost-cutting trends, it won't help the company's bottom line. Nor will bringing in consultants to carry out those decisions. Merely throwing consultants a 'hard-ball' of cash and asking them to turn things around at a company can't be accomplished through IT delivery alone, although they'll sure make it sound like it can.
Before engaging in the tactical aspect of RPA planning and execution, it’s important to understand which way the river is flowing, who the stakeholders are and what their intent is, what the level of interest is, and what the underlying drivers are for exploring automation.
By mapping out the lay of the land it becomes clearer what aspect of the business is bent on innovation, who's skirting responsibility, and who's simply 'throwing pennies in the wishing well.' Having this map in hand can make the difference between getting to see your enterprise objectives come to fruition or getting lost in the mire.
Footnote:
The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'
References:
Fragile to Agile. (2014, February 18). Philosophy. https://www.fragiletoagile.com.au/about/philosophy/ Have any of you snake-oil salesmen ever actually added any value to your client’s organisation? (2017, August 31).
Reddit. https://www.reddit.com/r/consulting/comments/6x8a34/have_any_of_you_snakeoil_salesmen_ever_actually/
Joch, A. (2020, May 6). 4 Secrets for Eliminating Shelfware. Technology Solutions That Drive Business. https://biztechmagazine.com/article/2016/08/4-secrets-eliminating-shelfware
Møller Institute. (2017, October 4). Steering the ship: corporate escapism vs sustained value. https://www.mollerinstitute.com/insights/steering-the-ship-corporate-escapism-vs-sustained-value/