Providing news, views and unrivaled content for the global sourcing community

 

 

I taught a robot to do my job (and other confessions of an RPA pioneer)

Posted: 04/02/2016 - 03:02

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.

Alsbridge

[EDITOR'S NOTE: In December 2016 Alsbridge was acquired by Information Services Group (ISG). To avoid confusion and for the purposes of historical integrity, Outsource has kept all references to Alsbridge in place, on all content published prior to the date of acquisition.] Alsbridge is a management consulting firm that helps companies improve operations, reduce costs and optimize service provider relationships. With over 300 consultants globally, Alsbridge has worked with over 40% of the Fortune 500 and currently advises over 200 clients a year on over $11b in spend. We apply operational data and market insight to help clients align sourcing strategies to business requirements, negotiate contracts at fair market prices and improve governance and vendor management. Services comprise Sourcing Advisory, Network, Transformation and Cloud, IT Asset Management, Benchmarking, Vendor Management and Governance and Intelligent Process Automation Advisory. Contact us to learn more.

Comments

Submitted by Michael Kern (not verified) on

Rod, great article. I appreciate you taking some of the debatable subjects head on, such as loss of jobs. It won't happen all at once, but it certainly could create attrition with the change averse population. Also, from a business standpoint the value really comes in the alternative --how many new hires would this require as you grow and how much more costly and painful would that be?

Thanks for writing a well articulated article.

Michael Kern

Submitted by Rod Dunlap (not verified) on

Michael,

Indeed change is coming. I have sat with dozens and dozens of claims processors and not once have they complained about losing their job. Instead they are excited that the robots can remove the simple, mundane, repetitive tasks freeing them up to spend more time with the complex claims or more time working with the members.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

About The Author

Rod Dunlap is a business process automation director at Alsbridge with more than 30 years of experience automating repetitive manual activities of white-collar workers. Before joining Alsbridge, Rod led teams that built robotic automation solutions for multiple national and regional insurance plans, saving millions of dollars in administrative expenses while increasing claim payment quality.