We’re delighted to introduce a blog series, featuring Sandy Kemsley, independent analyst and systems architect, specializing in Digital Process Automation (DPA), Business Process Management (BPM), the social enterprise, enterprise architecture and business intelligence.
Sandy will lend her expertise and commentary on topics such as digital transformation and the cloud, the convergence of process and content, the role of microservices in cloud-based BPM software and more. We hope you enjoy her insights and provide us your comments about these topics on Twitter @skemsley, @alfrescoTransforming Insurance with Cloud BPM
Understand the customer demands and business models for today’s insurance business, and plot a path along the maturity model to technology modernization.
In this blog post, I plan to explore the role BPMS plays in integrating packaged software, custom-built systems, and external services into a seamless process that includes both internal and external participants. What if you need to include customers in your process without having to resort to email or manual reconciliation with an otherwise automated process? What if you need employees and partners to participate in processes regardless of their location, and from any device? What if some of the functions that you want to use, such as machine learning for auto-adjudication, industry comparative analytics on claims, or integration with partner portals, are available primarily in the public cloud?
Let’s consider the case of an established property insurance company that wants to expand into online insurance in order to grab a piece of the market of younger people who are just getting their first apartment. Although there are older consumers in this market, younger consumers are more likely to want to make financial services purchases online, particularly on their mobile devices, instead of dealing with an agent or going to the local branch of their financial institution. The problem is that the insurance company has a lot of non-automated processes, and the automation that does exist is buried in on-premises systems of record (SOR) such as legacy policy administration and claims systems, as well as monolithic on-premises BPMS. They also have a conservative culture, averse to change and mistrustful of new intelligent automation technologies. All interactions with their clients are on paper, usually by postal mail. In other words: slow, inefficient, unwilling and unable to change quickly to respond to the new market demands, and ripe for disruption.
This results in some very different business models and needs for the old and new world of insurance:Old World Insurance New World Insurance Customer service model High-touch agent interaction Customer self-service Use case All insurance needs Straightforward property insurance Process initiator Paper documents Data entered by customer on web or mobile app Transactional processes Manual procedures, with some automation embodied within systems of record Automated processes and decisions with human intervention only for exceptions Customer interactions mid-process Calls and paper mail Web or mobile app
It’s not that easy to just start a new online insurance company from scratch; instead, the company needs to marry their existing reputation and stability with a technology architecture that can better serve the needs of the new market. Changing out policy administration and claims management systems is not an option for the short term, and the company doesn’t want to move those off premise due to perceived problems with data security and sovereignty. How, then, does an existing company modernize their architecture to address the new world needs?
Here’s a maturity model for insurance company technology modernization:
Level 1: Prepare systems of record for automation. Enable/expose API service interfaces to the SORs used for underwriting, policy administration and claims management, so that data can be read and written, and functions invoked within those systems. The ability to do this is dependent on the SOR platform, and may require signification customization or the creation of an integration layer, but is essential to create automated customer-facing processes that interact with the SOR.
Level 2: Prepare SOR for integration and scalability. Move the systems of record into a containerized on-premises/hybrid cloud infrastructure for easier integration with other cloud infrastructure, and simplified administration. Due to the company’s conservative data security and sovereignty policies, these systems will remain on premise but will more easily be able to interact with public cloud infrastructure.
Level 3: Develop customer-facing self-service processes using a cloud-native BPM. Create processes that follow the customer journey, allowing customers to initiate and participate in flows that create policies, update their policy information, and manage claims via the SOR service APIs. Internal tasks that cannot be fully automated will be routed to an internal worker as required. The customer-facing portions of the processes will execute in the public cloud – in a highly secure manner – but very little data needs to be persisted outside the company’s SORs, minimizing data security concerns. I believe in the advantage of cloud-native BPMS deployments, and the benefits they bring in situations where you’re bridging between on-premises legacy systems and public cloud customer interactions.
Level 4: Make processes more automated and intelligent. Incorporate intelligent automation technologies, including machine learning, artificial intelligence and third-party industry analytics, to fully automate the customer-facing processes where possible. For example, most rental or homeowner policies can be issued without employee intervention, and many types of claims can be adjudicated automatically and paid out immediately.
By implementing integration and automation modernizations with a cloud-native BPM, the insurance company can create and deploy customer self-service processes and specialized insurance products faster, providing a significant competitive differentiation. A cloud-native infrastructure also provides elastic scalability for dynamic scaling: for example, in the case of a regional flood or wildfire, the claims process can scale dynamically to handle the increased load, reducing the risk that an anxious customer sees a website or application that won’t load due to traffic.
Although I’ve put the recommendations in this post in the context of an insurance company, there are potential benefits for any organization looking to modernize to a containerized cloud architecture and improve customer-facing processes:
- Applications, both internal and customer-facing, can be assembled from independent services including legacy APIs, BPM microservices and third-party cloud services. This allows them to undergo rapid iteration to match the speed of your business.
- Containerized hybrid cloud applications can be quickly ported from development to test to production environments, whether on premise or in a private or public cloud, with minimal risk of incompatibility.
- Cloud applications can be scaled up (or down) automatically to meet demand, providing better cost efficiency.