RPA – Proof of Concept (POC) or Proof of Value (POV)? Who cares, just get going! Part 2 of 5

Back to Blog
RPA - Proof of Concept (POC) or Proof of Value (POV)? Who cares, just get going! Part 2 of 5

RPA – Proof of Concept (POC) or Proof of Value (POV)? Who cares, just get going! Part 2 of 5

The main purpose of a Robotic Process Automation (RPA) Proof of Concept (POC) or Proof of Value (POV) should not be used to validate that RPA works – it does. Rest assured any of the top RPA platforms work.

“A proof of concept can sometimes be seen as an unnecessary waste of time, particularly when a technology is already known to the business. Whilst a proof of concept is a long way from production readiness, done right, it can give an organisation concrete knowledge about the capabilities, benefits and challenges with any new tools or technology or partner with which they are unfamiliar.”

Kieran Gilmurray, Global Automation Lead

Do not attempt to use a proof of value to showcase or prove the technology. Use a POC to determine tool and organisations readiness, the vendor and your ability to work together, to educate stakeholders and finalise the right automation team structure for the business and lots more but begin today.

“During the course of the last five years RPA technology proofs of concepts left almost no stone unturned. In 2020, the stage-boundary challenges to a more scaled adoption are centered around proof of organisational-readiness. More specifically, business readiness to achieve a minimum viable level of business process maturity. The emergence of business-focused DigitalOps software platforms, is confirmation of the shift from proving the value of the technology, to ensuring a business is ready to accept a level of process digitisation and automation.”

Rodger Berkley, Automation Founder

Do not attempt a POC when a business is not interested. You are wasting your time.

“Proof Of Concept should not be ‘asking for permission’, or trying to get the attention of people whose focus is elsewhere. That can set the stage for disconnected point projects that are not aligned to strategic goals / business challenges and don’t unlock the end-to-end flow (so probably won’t scale and are more likely to fizzle out). ” 

Richard Jenkinson, EMEA Director

Building an automation team: If an organisation does not possess automation skills then it is best to hire a consultant or consultancy who does. There are a great number of roles to build; starting slowly, building automation muscle and scale fast is a recommended, tried and test approach.

Selecting an automation partner: Potential automation partners will often point to their expertise and present a multitude of reasons why you should work with them, rather than focus on the problems or initial investments that made to be made in terms of process transformation. Not every vendors description matches their promises in real life. A proof of concept is a great test of a vendors true skill.

If a partner can’t get a POC right, what makes you think they will get an enterprise wide program right?

“Be cautious, a vendor may deploy their best team to get your POC created, but then, once you are signed up, they may move their best team onto their next client, leaving your organisation with their less experienced team building your automation program.”

Gavin Price, RPA Jedi

Take time to select the right vendor and make them an integral part of your team. Treat the vendor and their team as if they were an extension of your team. Don’t blame a vendor for your lack of strategy or blame them as ignorant when you have not spend adequate time onboarding them into your organisation. When you integrate the right partner successfully you will have a partnership that endures the trial and tribulations of an automation program.

“The value of a PoC accrues equally to the customer and the vendor because both parties need inputs for their calculated risk equations. Proper automation vendors have a line item in their ‘cost of sales’ ledger to provide some quantity of free PoCs along with free Process Mapping software for projects of interest. Customers should always compete multiple vendors simultaneously and expect at minimum a video showing a basic version of the proposed software in operation. If the customer sees their automation vision reflected in the video, the vendor may offer hands-on access to further customized versions using VDI. If both parties agree to proceed, they enter a phased contract with the PoC software as the starting point. Each step in this process offers Go / NoGo decision points for customer and vendor alike based on their assessment of collaborative fit and technical alignment.”

JD Wilson Jr, RPA Innovator and Founder

Developing frameworks: Whilst robots complete tasks normally undertaken by people, they are not the same as people. The normal enterprise rules that govern people should not be replicated for a robot workforce (e.g. risk, governance, on-boarding, compliance, checking). 

Business Case: Organisations do not have time to complete interesting or pet projects (they never have!) as budgets are slashed and recession bites. Whilst interest in RPA | IA | DA | AI continues to grow, clarity on how to successfully adopt RPA | IA | DA | AI has not kept pace. Organisations implementing Intelligent Automation should be looking to see a 30% reduction in cost across their operations. However, the time taken to achieve return on investment from RPA | IA | DA | AI is one of the industry’s biggest challenges to date. There are great number of questions that need answered before a business case is built.

“Business case is great in principle, but there are a number of considerations: – is it trusted? Does it have proper sign-off (e.g. finance have confirmed the maths) or is it a little self-serving, constructed by the RPA vendor / project leader? Is it realistic? What methods have been used to baseline current ways of working, develop new RPA-enabled solutions and quantify the difference? What’s the size of the prize, but also how heavy is the lift?  Is it achievable? Do HR, Operations etc. agree – and are they willing and able to cut temporary or permanent heads / redeploy people to new tasks and roles?  Are incentives aligned to make it happen (or as in our experience at certain organisations, directors hold back implementing improvement so as to have it ‘in the bag’ if needed next quarter / financial year!)?”

Richard Jenkinson, EMEA Director

“The first step of the RPA and IA journey, is to create a strong business case. The business case should include specific process-candidates for automation followed by all the required metrics (volumes, cases per day, average manual handling time, peaks, forecast volumes, exception rates, etc.). It should be created along with a Partner (consulting company or a smaller boutique) for companies without any internal knowledge, since it is the first and most important step on your journey.”

Konstantinos Vogiatzakis, Global RPA Lead at Babylon Health

It is highly recommended that you engage your CFO, or a member of your finance team, to assist in the validation your RPA | IA business case. That way, you can be more certain of the returns and costs of your entire RPA | IA program.

“The key to a great business case is getting the true financial figures quantified by your CFO. ‘How much are you willing to invest in a Platform/ Vendor / Solution?’; ‘How much are you willing to spend on a great team to deliver the solution?’; ‘What is the ROI and how long will it take to recoup your investment?’.

These are the key questions you need to be able to answer and your CFO is key in helping produce those answers. If you can’t answer these questions then STOP and re-evaluate your program or approach.”

Graham Lee, Pundit and RPA AI/ML Artist

but remember.

“As my CFO used to tell me repeatedly when chasing me for late payers, ‘A Sale is only a sale when the cash is in the bank. It’s essential to have a solid mechanism to track the actual benefits vs. projected, and a counter-measure approach to ensure the promised gains are delivered. And that needs consensus, and aligned incentives and goals.’ 

Richard Jenkinson, EMEA Director

Selecting the right processes for your POV: Not every process is suitable for RPA.

“It is highly recommended that you select a process that will test your theories and don’t automate a very simplistic task that will prove nothing or from which you will learn very little.”

Kieran Gilmurray, Global Automation Lead

RPA Health Warning: Vendors, please note, if you are still telling customers that they can judge the success of your platform by automating a small task in a 3 day POC then that is both fallacious and dangerous.

Author Advice: Don’t automate’tasks’ beyond the POC! Organisations need to optimise, lean, simplify and standardise ‘processes’ end-to-end, before they are automated, to get tangible value from an automation program.

Author Advice: Organisations often get so focused on their POC | POV that they forget to build a pipeline of post POC processes to build upon. When that happens, people can lose interest and momentum can waver. Don’t have one process ready for a POC. Have ten ready.

Process Complexity: A good test for RPA | IA is to pick a real process which has just enough technology and organisational complexity to provide a good test bed of a vendor, the chosen tool(s) and the organisations readiness. For example, an organisation might chose to use RPA plus OCR to automate a portion of invoice processing; or use RPA and NLP to strip content from an email, query an internal application, then populate an internal CRM or finance systems; and then send an email reply.

“Organisations should take on a process that is meaty but no so meaty that the POC will fail spectacularly. Organisation confidence will be won or lost depending on the result of the POV, so it is important you don’t fail. That said, there is a tremendous amount to be learned from a meaty POC that does not quite go to plan. If there is a less risky time to fail, then it is the POC.”

Kieran Gilmurray, Global Automation Lead

Process Readiness: There are many questions to ask before you decide to automate processes. For example, what are the actual processes you are going to automate? Are your processes ready to be automated? Will automation scale to other areas beyond your first business area? Organisations may find that their processes are not immediately suitable for automation. A company’s processes should be simplified and standardised enough to start an RPA | IA journey or they should be re-engineered before the introduction of RPA | IA to gain maximum benefit from automation. By using techniques such as ‘Lean for Digital’ or ‘Design Thinking’ organisations can redesign processes for intelligent automation. 

“The availability of RPA tooling has opened an incredible way to start the discussion of process optimisation. It can monetise the lean way of thinking, and accelerate process execution. But don’t robotise processes just to be part of the hype if you can automate them. Garbage in will create garbage out. Use the ESSAR principle: Eliminate, Simplify, Standardize, Automate (if possible in the main application) and lastly use RPA- robotize.”

Nirmala Chaturi, Senior Manager | Digital Process Excellence

The key thing with any RPA program to rapidly create, deliver and capture value as rapidly as possible. When it comes to RPA strategy the more time spent creating an automation plan, the less time there is to execute it, increasing the risk that the world has moved on and the plan is out of date.

Therefore, implement a POC promptly to help to surface any automation plan’s flaws and identify where to improve. Don’t wait, start now. Make mistakes but learn, and learn fast. Iterate and succeed until you have an automation plan that works. This inevitably involves accepting a level of risk, but enterprises that embrace risk and respond quickly to events as they happen, are more likely to succeed in an uncertain world.

Does your organisation run POC | POVs before implementing new technology and if yes, then what are your organisation’s best practice advice?

#intelligentautomation #bots #rpaworks #digitaltransformation #roboticprocessautomation #rpa #cognitiveautomation #digitaldisruption #digitalworkforce #processautomation #digitalfuture #digitalstrategy

#intelligentautomation #bots #rpaworks #digitaltransformation #roboticprocessautomation #rpa #cognitiveautomation #digitaldisruption #digitalworkforce #processautomation #digitalfuture #digitalstrategy

Other articles: If you like this article then you may find these eight articles of use too.

  1. How to build a business case for Intelligent Automation and Robotic Process Automation
  2. 30 ways to build a pipeline of processes suitable for Robotic Process Automation (RPA) and Intelligent Automation (IA)
  3. I’ve now met 150+ RPA developers but these are the 20 signs of a ‘truly exceptional’ RPA developer!
  4. 8 questions to ask to ensure you select the ‘right’ processes to automate using RPA | IA.
  5. 14 rules for Robotic Process Automation (RPA) and Intelligent Automation (AI) success
  6. The A-Z of Robotic Process Automation, Intelligent Automation and Digital Transformation
  7. The biggest lie told to RPA customers – 50 robots equals success
  8. 40 essential selection criteria to choose an RPA platform

If this could benefit someone else tag them and share this.

Free to reuse: We are a community of RPA and Intelligent Automation experts with years of real world experience. We have stories to tell and the scars to show for it. We share our collective wisdom for free to simply provide as much value as we can to you. Therefore, if you want to post this article on your LinkedIn page then please feel free to do so. The more information we share within the RPA community the more likely businesses are to succeed with this excellent technology.

Further Help: If I can help you in any way please do reach out.

Note: The views expressed above are our views and not those of my employer or the employers of the contributing experts.

Share this post

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Blog