Robotic Process Automation for a Swiss insurance company

Introduction

This case study discusses a Robotic Process Automation (RPA) implementation at one of our clients, a large insurance company located in Switzerland. It will demonstrate how RPA enabled our client to meet critical business requirements in a competitive business environment and eventually gained a competitive advantage despite using a standard software solution.

Motivations behind RPA

There are many reasons for a company to use RPA, such as:

• Agility
  Utilizing GUI-based scripting, companies move quickly by automating scenarios that would otherwise have taken years to implement in the system or would never have been delivered at all

• Safety
  Since the code of the application is not modified, there is little to no additional risk to run RPA against the target application. RPA does nothing which human users could not have done.

• Interoperability
  With versatile scripting libraries, it is possible to interact with heterogeneous systems and synchronize data using an RPA-enabled orchestrator

• Cost reduction
  RPA teams can work independently from the software vendor; costs can also be reduced due to scripting being easier and lighter than traditional development processes

• Competitive edge
  While utilizing standard solutions, building services relying on RPA can enable unique features which are prohibited by the standard versions of software

• Business focus
  RPA is driven by business users; by removing barriers between business and IT, RPA increases productivity and ensures that automation services match business requirements

While RPA is not intended to be a long-term solution to all automation needs, it is the most effective approach for legacy IT environments, or companies relying heavily on standard software solutions (such as an ERP). This case study will take a look at how we’ve been able to help a client stuck in a slow-paced release cycle and enable new automated workflows in their system.

Challenges

Companies relying heavily on software to deliver critical services are faced with many complications; Non-IT businesses, like banks and insurance firms, typically use standard software solutions rather than building proprietary software. Typically, companies would only use standard software for tasks associated with no particular competitive advantage and posing no sensitivity issue from a business perspective. Food example, a company in need of a spreadsheet solution would utilize Microsoft Office.

However, the core components of the software that enable a business to function should be developed in-house so as to specifically fit the needs of the business; it is effective at protecting your business secrets from your competition, including from your own software provider(s). It is common for a software provider to move into a market segment previously owned by their own customers. For instance, Google Search has moved into the market of travel searching, after having benefited from other flight/hotel search engines via ads and other ranking-related products.

There are several other issues and concerns present in adopting standard software. First, you’re not in control of software releases anymore: your influence regarding the upcoming content is limited or nonexistent, and you can’t decide at which pace updates are rolled out. Standard solution providers tend to think about their own interests first, while potentially ignoring the interests of their clients. There are examples of clients placed under high pressure for not migrating fast enough or sometimes clients stuck in the opposite situation: they are in need of a new set of functionality, which would always be delayed or sometimes simply denied.

There is also the ever present threat of competitive businesses catching up to your current performance, as they have access to the same standard solutions.

These challenges should, for the safety and prosperity of a business, be addressed early in a business’ lifecycle, preferably before making any big moves. Standard solutions are not inherently faulty solutions; these systems make sense and allow their users to differentiate themselves from one another through customization or parameterization. However, our experience indicates that users rarely get the smooth ride they were initially promised. This is the situation in which RPA can be useful.

Client context

At the time of this study, a recent and sudden change to laws governing health insurance options for France-Switzerland border workers had a major impact on the insurance system. Tens of thousands of customer’s data needed to be migrated or inserted into our client’s system within a few weeks.

Our client quickly realized that this task could never be done by hand, with enough efficiency to remain profitable. They turned to their software vendor for help to see if a batch implementation could have been delivered in time but due to the rigidity and slow-paced nature of development and acceptance processes, our client decided to turn to RPA (and Step, our automation platform) instead.

Technical stack

Although the RPA principles described in this case study apply to any software stack, we will briefly describe the software and technical architecture at hand.

Syrius, a standard application

The standard application subject to automation at our client was called Syrius. It was a comprehensive solution for insurance and it was particularly popular in Switzerland.

Architecture overview

Syrius is a distributed application comprising of a data layer, business tier, presentation tier and a Java client (with two implementations in Swing and FX).

A key requirement in order to make RPA possible given this architecture would be to provide a stable solution for simulating user events inside the Java client, passing dynamic inputs to each execution, and then scaling these executions.

Data inputs

The data serving as an input of the information (such as customer information, insurance plan, etc) was received in the form of Excel files. One of the wishes of the client was to make sure that business analysis would be able to work directly with excel spreadsheets and if possible, drop them into a folder as part of the preparation of the automated scenario’s execution.

Solution

In this section, we will first look at an overview of the technical solution retained to automate workflows based on the Java client. Then, we will identify key features that resulted in substantial benefits for the client. We will also see how these benefits relate to the initial motivation factors for RPA which we discussed at the beginning of this article.

Technical implementation

The chosen technical stack to design and execute the automated workflows comprised of Oryon, an out-of-the-box solution for Swing/FX automation and Step, our state-of-the-art automation platform which can be used for the massively concurrent execution of Oryon scripts via a plugin.

Oryon, Automation for Syrius

Our scripting solution for Java clients, called Oryon, features a driver capable of recording and manipulating objects in Java clients and comes with a development studio (IDE) for editing and intuitive script replay. In this particular case, our client used our custom plugin for Syrius, which came out-of-the-box with Oryon. This plugin allows for easier recording and improved stability, as it is aware of information on the specific implementation of the Syrius client.

Orchestration and scalability

In addition to Oryon, Step was retained as an orchestrator and for the parallel execution of the data migration scenarios.

Step is a comprehensive automation platform featuring a controller-agent architecture allowing for high scalability. It also comes with the key advantage of centralized archiving and monitoring. This allowed our client to monitor in real-time that each migration was successful and check the execution history to identify and investigate errors.

The figure above shows what execution results look like in step. Each execution leads to reports containing a status, potential errors, attachments, screenshots, and all the necessary information to diagnose issues and find the involved business objects in the system if needed.

With Step’s agent grid, executions were scaled up to thousands of cases per minute and could have been scaled even higher if more infrastructure had been provisioned, but the throughput reached was deemed enough to solve our client’s problem.

The new automated workflow

The following diagram summarizes the new workflow for users involved in the RPA campaign:

• The first step is the click & play recording of the scenario using the Java client along with a deployed Oryon agent; this step will produce a script as an output
• Once the script is ready, our user will prepare the data which needs to be mutated or inserted. This will be done using Excel spreadsheets. When the data is ready, the file is dropped into a shared folder and will be picked up by the automation orchestrator once the scenario is launched.
• The script is deployed onto the platform via drag & drop. The scenario can now be launched.
• Execution ensues; script executions are distributed across a network of agents and scaled out. Our users can now focus on browsing execution results and potential errors. Performance metrics are also available.

Benefits for the client

RPA benefitted the client, as well as fulfilled the promise of Step, in the following ways:

• Agility‍
  The installation, scripting, and first execution of a basic scenario took less than 3 days. Commissioning VMs to scale the Step agents and preparing of the data to be migrated took longer, but this was dependent on third-party teams

• Safety‍
  The import of the customer data was performed successfully without exposing the target system to new potential bugs.

• Interoperability‍
  Although most of the changes needed to be made in a single system, most of the data came in the form of excel spreadsheets which were used “out-of-the-box” as a source of data in Step

• Cost reduction‍
  The RPA campaign saved both a large number of man-hours, as well as allowing the business to meet critical deadlines

• Competitive edge‍
  In subsequent campaigns, and in using the same chanel to import data, our client was able to provide its customers with new services that competitors could not offer

• Business focus‍
  With easy recording, a simple web interface for result analysis, and Excel spreadsheets as a source of data, business analysts were able to use the solution directly, reducing the need for engineers to support them

Conclusions

Our client was able to solve the sudden problem they were faced with and migrate all of the customer data in time, and they have since kept building new RPA routines on top of the existing stack and use it continuously to offer new services to their own customers. RPA had started as a technical solution to an automation problem but ended up as a key competitive advantage for this insurance. They’ve launched several campaigns with features relying purely on Step and Oryon.

In the long run, it is likely that the legacy software provider will adjust and add some or all of these services to their catalog, but in the meantime, RPA has proven to be a great way to react quickly and efficiently to sudden changes in the business.