RPA: Proof of Concept vs Proof of Capacity

While some linguists and historians argue that language serves to bring people together, there are numerous instances where the opposite is evident. Each generation has its own slang that facilitates communication among its members, often creating a barrier with other generations. This phenomenon also occurs within industries, where the same word or acronym may have entirely different meanings depending on the field.

In the RPA (Robotic Process Automation) sector, there are several terms that are deemed essential, with "Proof of Concept," or POC, being one of the most prominent. Although POCs are not unique to RPA, it's uncommon for an RPA project to not initiate with a POC. Strangely, every organization contemplating the adoption of this technology holds an almost fervent belief that commencing with a POC is crucial in order to verify that RPA software is effective. Given the extremely high failure rate of RPA projects perhaps this is justified. But, does an organization need to prove that RPA can create positive business benefits when implemented? Do we need to prove the “concept” of robotic process automation, or do we need to prove its capacity to generate actual benefits?

The idea that RPA needs a Proof of Concept (POC) is clearly absurd. If you’ve ever used the “Out of Office” feature in your email, you’ve validated the concept of RPA. If you’ve turned a PDF into text or Word, you’ve effectively demonstrated RPA. If you’ve utilized a password manager to log into a website automatically, you’ve proven RPA. There is nothing “theoretical” about how this technology operates. Yet, almost every organization insists on having an RPA POC before they fully implement these tools. RPA is not a groundbreaking technology; instead, it represents an innovative approach to delivery. 

So why this fixation on POCs? The answer is risk! More specifically, it’s an irrational, overwhelming, and crippling fear of risk. With concepts like de-shoring, un-shoring, re-shoring, and tiger teams, traditional businesses have tied themselves up to the extent that the risk of taking action becomes significantly greater than the risk of doing nothing. The extent to which contemporary organizations go to avoid taking action is remarkable. Large companies maintain numerous managers, business analysts, and consultants whose primary role is to prevent any wastage of funds. The expenditure associated with ensuring that no money is squandered may be the most significant misuse of resources in human history.

Under the current common approach, Proofs of Concept (POCs) represent a poor investment in terms of time, money, effort, and focus. They are inherently restricted in their duration, scope, effort, and ultimately in their relevance. In their efforts to minimize the risks associated with adopting Robotic Process Automation (RPA), organizations set up POCs in such a way that RPA is unlikely to thrive, at least financially. Furthermore, when a POC does demonstrate financial success, those outcomes rarely transition smoothly into full-scale production. This insular view of RPA’s effectiveness aims to mitigate any potential negative repercussions if RPA underperforms. However, confining RPA within these limitations almost guarantees its failure!

I have heard nearly all the major RPA vendors express concern about this situation. Their clients often purchase one or two bot licenses, create a small proof of concept, run it for a month or two, and then discontinue using the technology. When asked about their decision, clients commonly respond, “We didn’t get the value we anticipated.” Well, naturally you didn’t! You’ve just invested $15,000 in software, $2,000 in hardware, $50,000 in consulting, and $100,000 in a Centre of Excellence framework to replace two full-time data entry clerks who cost $75,000 each annually, including benefits. Your single BOT operates for just four hours a day (intended to replace two full-time employees), and it remains inactive for the rest of the time. Your return on investment is already negative before the bot is even activated, and with ongoing support costs, it only continues to worsen. It's not surprising that many, if not most, proofs of concept are unsuccessful.

With RPA, organizations must conduct a POC, but it shouldn't be done in the current manner. Instead of demonstrating the CONCEPT of RPA, what's required is to validate its CAPACITY. Specifically, can RPA deliver savings and value at scale? The key innovation isn’t in macros, screen scraping, or workflow; it's about effectively managing and governing these technologies organization-wide. You don't realize RPA's most significant value proposition until you've achieved a certain scale. In a Proof of Capacity (POCa), the approach involves automating multiple tasks—five, ten, or even twenty—all simultaneously. This method allows you to test and demonstrate the crucial aspects of RPA, which may include: Resource Allocation, Resource Management, Process Orchestration, Credentials Management, Error Handling, Reporting, Traceability, and Controls, among others. These are the reasons you invest in RPA software, rather than the outdated workflow engine! If you implement bots one by one, you won't reach any meaningful scale, and those essential functions will remain untested. Consequently, you won't realize business value and are unlikely to see a positive ROI. A POC often leads to failure, whereas a POCa is a significant move towards success.

RPA is not just about achieving automation; it’s about realizing automation at scale. The key idea is that digital and human workers can be integrated into a cohesive cybernetic workforce, with each group leveraging its own strengths, talents, and capabilities. Until you demonstrate that this integration is possible, investing your time, resources, and attention may be futile. Unfortunately, few organizations approach RPA with this perspective, leading them to deploy bots similarly to how traditional rocket companies operate. They construct a bot, launch it, discard it, and then restart the process. While these engineers might genuinely believe this is the most cost-effective way to reach their goals, they are often setting themselves up for failure.

Companies do not need to prove that RPA is effective for them. Instead, they must establish whether they can effectively collaborate with RPA. It’s crucial for organizations to assess their ability to utilize the enhanced speed, consistency, and flexibility offered by RPA. Once they achieve scale, RPA has the potential to fundamentally transform the way an organization operates.

The capacity that must be demonstrated, or proven, is can your organization design, deploy and manage a cybernetic workforce: a workforce that is digital where speed, accuracy and volume are required, and organic where interpretation, cognition and judgment are required. As with most organizational design, the challenge isn’t in the tasks, it’s in the handoffs.  Knowing when to engage a human in a transaction, and increasingly which one, will become the greater challenge.  This is a challenge of resource orchestration and harmonization, and is the most difficult part of achieving scale with these technologies.
 
****************
************
*****

Comments

Post a Comment

Popular posts from this blog

Generative AI & Meta-Leaders

In the wake of advances in generative AI and large language models (LLMs), there is excitement about what the technology means for businesses. But we should not forget that this advancement is also posing a catch-22 situation to the traditional leadership. The transformative potential and rapid acceleration of generative AI are creating an imperative for them to act quickly. They should rethink their skillsets and develop new skillsets like – ability to make better sense of data insights, ability to ask better questions, ability to learn from smart mistakes etc. It is true that ChatGPT has taken the world by storm. In just 5 days since its launch in November last year, it gained one million users, a feat that no other popular online services have managed to achieve. But it is not the only generative AI tool, others include Midjourney and Dall-E for images generation, GitHub Copilot for coding, and even conditional generative adversarial networks (cGAN) such as Pix2Pix, developed by ...
Read more

Good automation! Select right process for RPA

Someone said very rightly – “Automation is good, so long as you know exactly where to put the machine.” In all my previous blogs I wrote about BOT failure, ROI Modelling, Cost saving, RPA Governance, CoE, POC, POV etc. But then I realized that before taking a deep dive into any of these subjects, first we need to have a right RPA process identification & prioritization methodology in place. Everybody across the industry agrees that Robotic process automation (RPA) can make a big difference for organizations tormented by repetitive routine processes – the kind that suck up the productivity of people whose time would be better put toward more important work. But many are confused by what seems to be a deceivingly simple question — which are the right processes for RPA? The poor choice of process for initial pilot is the leading root cause for failure to meet customers’ expectations. Robotic Process Automation (RPA) doesn’t suit every process and in majority of cases we don’t have...
Read more

RPA Exception Handling – Be in control

Companies in every major industry are turning to semiautonomous computers (better known as BOTs) to automate large- and small-scale business processes. This technology replaces human intervention in back-office operations, improving operational efficiency, reducing costs and increasing margins. However, organizations cannot employ this technology effectively unless the BOTs are engineered properly. And one of the most important component of this BOT engineering is Exception handling or in simple words right categorization of the errors and then developing solutions around the same to deal with those errors to meet the expectations of the RPA owner. Occasionally, in the course of its work, an RPA BOT definitely encounter a situation it was not programmed to handle – and, in those cases, it will stall. Those cases can be for foreseeable reasons – security or access constraints – or it can be for unforeseeable reasons – like missing or incorrect data. Increasingly, RPA developers are ab...
Read more