(Photo credit Jaynish Chaudhary.) 

Like many industries, the insurance industry has a great deal of work to do to modernize systems to eliminate unnecessary manual interventions and link disparate systems that bog down business processes. However, modernization often comes with a huge price tag. Thus it’s no wonder that the industry is embracing robotic process automation (RPA) as a cost-effective alternative to traditional automation efforts.

By automating various tasks, RPA tools can help optimize your operations. As with any new technology on its way to becoming mainstream, misconceptions are common. Here we debunk the nine most common myths in the market about RPA that can lead your RPA efforts astray.

Myth #1: RPA can be led by business alone

An RPA initiative is no different than any other strategic initiative. You’ll need support from executive leadership to build strong partnership with various other functional groups, such as IT, Risk, Security, Release/Change Management, and Infrastructure. RPA at an enterprise level will touch all functions of your operating model. To ensure that all stakeholders are represented, think through the delivery lifecycle to determine the scope of the partnership.

Myth #2: RPA is a quick solution for every process

While it’s relatively quick to build and deploy bots, RPA is not a quick solution for every challenge. Ease of deployment depends on the complexity of the process and dependencies on other tools such as OCR/ICR for data ingestion. Often, insurers will attempt to take the largest problem they have and try to solve it with RPA. Follow an approach to RPA that will help define a roadmap that will provide the best benefits.

Myth #3: The out-of-the-box RPA “control tower” is sufficient for enterprise initiatives

All RPA tools have a control tower that allows users to drag and drop the built bots onto a server/machine, making deployment to production easier.  However, the complexity of the control and command of the bots grows throughout their lifecycle and as the size of the bot workforce increases. To build for scalethink through the end-to-end lifecycle of the bot (i.e., build, test, release, control, manage, and exception handling). You may need to engage other tools to seamlessly support your organization’s needs regarding exception handling, hung bots, scaling up or down, retrigging the bots, for example.

Myth #4: Traditional (waterfall) delivery process will work for RPA delivery

As RPA solutions are generally built on top of existing applications, the traditional SDLC methodology may not be the best approach for implementation. The RPA solution and the supporting tools are designed to provide rapid development and deployment to production. An agile methodology, coupled with the minimum viable product (MVP) concept, has proven to be the appropriate approach. This approach is well suited for the incredibly short time it takes to develop and deploy bots. If you do not follow an agile methodology, consider revising your model to support the shorter delivery cycles that accompany RPA development.

Myth #5: Existing infrastructure can support RPA deployment

While bots can be deployed quickly to desktops and servers, this becomes challenging when you consider at enterprise scale. Plan to perform a sizing exercise early in the initiative so that you can measure your capacity needs. Traditional infrastructure allocation takes time and money, and early identification helps you navigate your existing infrastructure team SLAs and budget constraints to avoid costly delays.

Myth #6: RPA tools are the only tools needed to automate your processes

 RPA depends on discrete, structured, digital data to automate processes, and you may need the help of other tools to prep the raw data prior to executing the bots. For example, you may need optical character recognition (OCR), intelligent character recognition(ICR) or machine learning tools to scan and parse data from paper documents and then transform the data to a structured digital data set that bots can consume. Identify the additional technology tools you may need to completely automate your processes as part of your macro assessment and include it in your automation roadmap.

Myth #7: RPA can exist independently from process and application changes

Bots are tied to processes and processes to applications. Any change to an application or process may impact the bots that use that application or automate the process. It is critically important to perform an impact analysis if the process or application is scheduled for change. At an enterprise level where an organization has deployed hundreds of bots, it is essential to build bots as a service. The bots-as-a-service approach encourages your organization to reuse existing bots which will reduce the duplication of development efforts across the enterprise and mitigate the impacts of application and process changes on the bots that have been deployed.

Myth #8: RPA can be managed with the existing program and operating structure

Traditionally, operating models are based on existing application capability and the processes currently in practice. However, with the introduction of RPA, the future state of the processes will change depending on the number of tasks that are to be automated, which will lead to changes to the current operating model. Depending on the RPA initiative, existing programs may be impacted in a positive way, as many of the traditional integration efforts can be accelerated using an RPA solution. Many organizations have used this method as a stop gap and realized ROI sooner than waiting to complete the traditional way of integration. Programs like digital initiatives, that rely on backend integration with legacy systems, have been able to successfully deploy RPA tools as they are can mimic the integration at a fraction of the deployment time and cost.

RPA at enterprise level will need a center of excellence (CoE) that will help establish governance, build collaboration between various functional groups, create automation frameworks, provide oversight, and implementation standards. CoEs will help build a platform that is scalable, flexible and resilient. CoEs can be centralized or federated based on what suits the organization. Most organizations tend to choose a hybrid approach where they establish a centralized CoE for governance and federated CoE for implementation. This allows autonomy to business units to plan implementation based on their needs.

Myth #9: You do not have the right people to leverage automation tools

Many people think that they do not have the right personnel on staff to execute RPA initiatives. In fact, what’s needed to configure automations using RPA tools is business process expertise. Every organization has the right subject matter expertise. The key is identifying the right experts to train on RPA tools. Look for business analysts who understand automation—those that can write macros and orchestrate other simple automations. Find them and upskill them to enable success.

Conclusion

The most important thing to realize about RPA is that it is one of many solutions you can leverage, along with OCR, ICR and machine learning. In some cases, RPA may not be the best solution; do not force fit it. Hopefully, clearing up some of the more common misconceptions regarding RPA will ensure that your business can fully benefit from all that this new technology offers.

Editor’s Note: Paul Krauss, FSI Technology Practice Lead, and Dilip Kumar, FSI Director, both of NTT DATA Services, also contributed to this article.