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