In 2009, I was a Director in the Project Management Office at Blue Cross/Blue Shield North Carolina, when we launched an initiative to build a Robotic Process Automation (RPA) application that mimicked the functions of human claims examiner. Overseeing a team of eight software engineers, analysts and testers, we developed a robotic engine and, over the next 18 months, systematically expanded the application’s capabilities. Our team’s efforts focused on automating the review and resolution of common claims issues, and routing exceptions that required specialised knowledge or research to human workers.
The results: savings of $11 million by the end of 2010, and a reduction in claims processing staff from 425 to about 300. Prior to the initiative, BCBSNC had projected a need to expand to 600 examiners by the end of 2010, but the automated system absorbed the additional workload with fewer staff. The workers who remained spent more time reviewing complex cases and less time doing routine paper-shuffling.
My experience in a pioneering RPA project (so pioneering it wasn’t even called RPA at the time) lent some valuable insights into the basic issues involved in automating business processes and managing organisational change. In addition to being closely involved in building the technology from the ground up, I’ve seen first-hand how RPA impacts jobs and employment prospects of knowledge workers.
Our initial area of focus at BCBSNC was the review of duplicate claims; that is, determining if two claims filed for identical procedures or services are legitimate or duplicates resulting from an administrative error. It’s a common issue – approximately 12 per cent of health care claims are reviewed for potential duplication. As an example, consider a patient who breaks his leg. He typically gets an X-ray at the ER to confirm a break, and then requires a second X-ray to determine how to set the cast. By reviewing criteria such as the date, time, location and provider of the procedure, the insurer can determine whether or not the two claims are in fact unique or duplicate claims for the same X-ray.
By writing a set of logical rules aligned to the review criteria, we built a robot that automated the work of the approximately 25 people at BCBSNC who focused on reviewing duplicate claims. Subsequently, we built additional sets of business rules to resolve common issues around other areas of claims processing, such as authorisation, diagnosis and billing. Over the course of the next 18 months, we built robots that had taken on a workload that would have required approximately 300 human claims processing specialists.
The robots we assembled had the capability to process about three out of four claims sent their way. The ones they couldn’t resolve didn’t lend themselves to specific if/then rules of logic and required human intervention. For example, if someone suffered an injury while riding in a friend’s car, the question of whose insurance would be liable for the injury required a human to research the policies of the respective companies involved. Or, if a claim was accompanied by a doctor’s letter stating why a particular treatment was required, a human had to review that letter against the insurer’s coverage standards.
From a technology standpoint, we could have gone further and built robots with increasingly sophisticated logic rules that could process even complex claims without human intervention. However, that wouldn’t have made sense from a business standpoint. Specifically, it’s more cost-effective to have a human specialist spend two hours resolving an unusual exception that arises three or four times a month than it is to have a team of programmers spend two days configuring a system that can automate the resolution of that exception.
That said, one of the keys to any effective RPA initiative is to continually push the envelope of automation by identifying functions that – while not necessarily routine on a daily basis – are repeatable enough that automating them will yield a return on investment.
Once the robots were in place at BCBSNC, the roles of the 300 human claims processing specialists who remained changed dramatically. Because the routine functions had been automated, the specialists now spent more time focused on exceptions – on claims that required research, inquiry or business knowledge to resolve. This shift drove a fundamental change in the organisation’s approach to managing the claims processing team. Rather than focusing on “productivity” in terms of claims processed per hour, we were now looking to apply metrics to gauge the effectiveness of human staff and of the RPA application. As such, a high claims processed per hour rate could indicate that the robots were leaving money on the table by sending automate-able claims to the human specialist.
Another consideration: we typically think of RPA as making peoples’ jobs “easier,” in this case the opposite was actually true, in the sense that the remaining claims processors now spent more time working on problematic claims requiring skills and knowledge and less on mindless paper-shuffling. During the early implementations of RPA at BCBSNC, the VP of Claims complained that we were sending her too many hard claims. In fact, her team had always received the same number of difficult claims, but they were no longer being offset by the easy or routine claims.
Which brings us to the elephant in the room: does RPA destroy jobs? Or does it create new jobs and enrich our work lives by eliminating drudgery? The bad news first: if your job consists of doing the same task over and over again, no matter how complicated or sophisticated that task is, chances are a robot will replace you before too long. So too if you can describe your job functions in specific and unambiguous detail. From a business standpoint, moreover, the reality is that if RPA did not present an opportunity to do more work with fewer people, and in doing so save money, businesses wouldn’t be interested. And while many RPA case studies these days talk about “redeployment” of resources rather than layoffs, there’s no denying that at some point in the service delivery chain people will be removed from the equation.
In the case of BCBSNC, while the reduction in total staff was accomplished through attrition, the RPA initiative precluded the hiring of approximately 300 additional staff, as well as investment in associated infrastructure that had been anticipated. Many of the claims processing specialists who remained at BCBSNC, meanwhile, embraced the challenge to acquire new skills and expertise and successfully assumed new roles. As for me personally, I was essentially made redundant and took early retirement. After consulting at numerous insurance companies for several years, I recently joined the RPA Advisory practice at Alsbridge, which focuses on helping Fortune 1000 enterprises take advantage of RPA technology.
In other words, we adapt. In this regard, RPA can be seen as analogous to the fundamental transformations that have redefined major economic sectors such as automobile manufacturing, textiles and agriculture over the past century. We’d be naïve to expect that the changes driven by RPA will be any less painful or disruptive, but we might be equally naïve to think that there’s a whole lot we can do to stop them.