Proof of Concept is not Proof of Capacity

The Robotics Process Industry is known for introducing & adopting several terms in its journey so far like - AI, IA, CoE, CV, CNN, DL, ML, NLP, NLG, iOCR, POV, POC, RNN etc. One term that is quite high in the list is “Proof of Concept”, or POC. POCs are not special to Robotics Process Automation, but very unusual if the RPA project doesn’t start with a POC. In general, a proof of concept (POC) serves as a stimulant for those businesses looking to leverage the RPA technology to improvise their business process outcomes. A POC can be built for one entire process or a small part within the process.

Now a days the most surprising thing is that every company that is planning to use RPA technology believes religiously that they must start the work with a POC so that they can ensure and can see themselves that BOT software is working before full blown deployment. To a large extent this is justified, given the exceedingly high failure rate of the RPA projects. But it is bit difficult to accept, while entering in 2021 in few days’ time that does an organization really need to prove that RPA can create positive business benefits when implemented? Do they really need to prove the “concept” of Robotics Process Automation or do they need to prove its capacity to generate actual benefits?

The opinion that Robotics Process Automation requires a POC, looks to me clearly unreasonable/ illogical.  If someone has used the “Out of Office” function in his/her email, he/she has already proven the concept of RPA. If someone has converted a PDF to a text or word file, he/she has already proven the concept of RPA. If someone has used a password management application to automatically log into the website, he/she has proven the concept of RPA. Honestly speaking there is nothing “conceptual” about how this technology works. But however almost every company demands to have a POC before they begin the extensive deployment. Someone has said very rightly that RPA is not about revolutionizing technology; it is about revolutionizing the delivery. 

The question comes what is the holy charm behind this “Proof of Concept”, that nobody even thinks of deploying RPA technology solution without having this in place? 

Is it fear of Risk? I don’t think so, because most of the large organizations have organized themselves, very consciously to avoid such things at all costs. They have bound themselves after years of cost containment up to the point where the risk of action, surpasses the risk of uncertainty. Then Is it fear of negative impact on return on investment? I am not convinced with this as well, because to avoid such situation, now a day’s large organizations have kept standing armies of managers, business analysts and consultants, whose sole purpose is to ensure that money is not wasted.

If you closely look at the POC’s strategic planning, and typically the way they are implemented, you will find that it is just a waste of time, money, effort, and focus. Someone has very rightly pointed out that by design, they are limited in time, scope, effort and eventually significance. In attempting to minimize the potential risks of adopting RPA, most of the organizations create the conditions in a POC where RPA simply cannot succeed, at least from a financial perspective. And, in those occasions where it does prove to be financially successful, those results almost never translate effectively into production. This inside-a-bubble perspective on RPA’s effectiveness is expected to contain the potentially negative consequences if RPA is found to be in need.  But it is the act of putting RPA in this bubble that pretty much ensures that it won’t work!

The ROI is below the surface before you even turn the BOT on, and with ongoing support it gets more negative by the day.  It’s not surprising that many, if not most, POCs fail.  With RPA, organizations do need to do a POC, but not as currently executed.  Rather than proving the CONCEPT of RPA, they need to prove its CAPACITY.  That is, can RPA, at scale, generate savings and value.  Again, the innovation here is not in macros, screen scraping and workflow, it’s in managing and governing these technologies across the entire organization.  

The other reason that POCs are a waste of time, money and resources is that a POC almost never exercises an entire process or system.  POCs almost always demonstrate the automation of a very small number of tasks.  This is necessarily true, as automating an entire process or system would be far more costly and complex than the typical POC. Most POCs consist of running a BOT on a laptop or desktop, using an actual person’s login credentials, and following a recorded or coded copy of the exact steps that a human user would perform.  It is common that a company’s IT department has little, if any, involvement in this work and so operational and support issues aren’t identified or addressed.

Testing doesn’t exist, other than a sample run or two, made against production data in a production system. Under these circumstances, it’s almost impossible for a POC not to succeed.  After all, it’s simply a macro running a programmed routine! The value of RPA is not in its ability to automate individual tasks; anybody can do that.  The value of RPA is its ability to automate thousands of tasks, in hundreds of processes, performed on millions of transactions, all in a coordinated fashion.

It's not the concept of automation that we are trying to achieve, it’s the concept of automation-at-scale that we are chasing.  Until we exercise and prove that THIS is achievable, we are really wasting our time, money, and focus. Companies don’t need to prove that RPA will work for them.  Rather, they need to prove that they can work with RPA. Companies need to determine if they are able to work with the increased speed, consistency, and flexibility that RPA delivers.  Once at scale, RPA can and will change the very nature of how an organization will work. 

------------------------
------------------
---------

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