Whether its cognitive automation or RPA tools they’re trying to implement, a large percentage of services buyers are stuck in a sort of robotic limbo. As we launched our new automation council “FORA” at HfS, Phil brought up a huge challenge, “Why aren’t those [anticipated] 40% cost savings happening each time someone slams in some software and hopes it somehow eliminates manual labor because they can access a bot library? In fact, why are a third of RPA pilots just left hanging with no result?”
Why are PoCs entering robotic “limbo” or failing, and what is working out there?
Here’s what I heard from two automation practitioners in large financial services organizations:
PoCs that don’t begin with the right kind of buy-in have a longer time to value
The VP at a financial services company considered using Watson technology to help their sales force be better informed when first interacting with potential customers. They designed a PoC that would allow a sales person to ask questions like, “Who are this customer’s competitors?” Watson could take this natural language query and apply it to the company’s own and external data sets and come back with a synopsis of facts to make it easy to identify trends. However, after the PoC, it became apparent that various stakeholders like the operational heads of the lines of business didn’t understand the breadth or relevance of the technology. Was Watson overkill for their needs? After the PoC ran, these executives asked, “Isn’t this what Google does? Why do you need to invest in this solution?”
With the Head of Sales behind the project, the organization found it easy enough to get started but then got waylaid on the way to the finish line. The team had to backtrack to explain how the fundamental cognitive technology can help achieve more meaningful and timely answers to the questions the sales team could ask. The stakeholders didn’t understand the difference that data mining could bring – versus manual searches for each company or trend. The solution would bring more relevant and actionable data to sales teams that could impact closure rates and revenues. After a rather lengthy “limbo” in educating all parties, the VP involved the top performing account managers and used their ideas to design the front-end user interface. This helped the team build a relevant solution that leverages the capabilities of Watson and build internal acceptability, which accelerated the path to live deployment. The team is now expanding its user base and exploring ways to leverage more Watson APIs in the solution.
PoCs could get dismissed as hypothetical technology proofs with no grounding in reality
Peter Quinn, Managing Director of Automation at SEI Investments Co. started the RPA journey in their organization’s securities processing function late last year. He took a position not to do PoCs, feeling that they are too easy for skeptics to shoot down, and only prove hypothetical scenarios while exhausting time and resources. Instead, his team decided to run production pilots, a hybrid of PoCs, pilots, and production phases. With this format, the solution is designed with more rigor than a PoC, and is deployed in a live production environment with real transactions taking place.
Peter stresses the importance of demonstrating to the larger organization the efficacy and effectiveness of the bots deployed since they are working in a live environment. He shares, “I wanted to do things that weren’t trivial, like RPA tools that just gather information and create reports. When those processes work with 98% accuracy, that could be considered as acceptable. But when they are moving client securities or money, no margin of error is acceptable. We are running functions that are core to the financial operations of the bank rather than something that’s low in criticality. When they work, the results speak for themselves – we are seeing greater accuracy from the lack of manual errors.” The implementation challenges that this team faced with the production pilots were related to other aspects of their technology landscape that needed to be fixed, such as conflicts with how the environments were configured. It could have gotten “stuck in limbo” because to really build automation as part of the core processing backbone, they had to work through a lot of unanticipated factors. It didn’t however because they had relevant business and technical stakeholders involved and a general spirit of collaboration. SEI is now armed with “real-life proof” and is undertaking several more process automation.
Testing and sharing as you go help ensure you are solving the right problem and updating it as needed, as well as adjusting the technology solution.
What is common in these practitioner experiences is the importance of building stakeholder buy-in. You need to have them involved in defining what problem to solve as well as testing the solution and being ready to make quick adjustments to address what else in the infrastructure or environment is impacted as RPA is rolled out. The problem you are trying to solve, the complexity, and the level of stakeholder involvement are all necessary factors to consider. It can influence the type of approach you take and help identify the issues you need to tackle upfront before even getting started with automation tools, as well as adjust quickly along the way.
The Bottomline: Don’t feel obligated to jump into automation PoCs only to be left in limbo down the road. Iron out the ‘whats’ and the ‘whys’ before getting into the ‘hows’.
There’s more than one way to kick-start your intelligent automation journey. Find the one that works for your organization’s culture and political structure—do you need to educate or provide examples or both?
Posted in : Robotic Process Automation
