Tag Archives: insurance

Insurance case management: SoluSoft and OpenText

It’s the last session of the last morning at OpenText Enterprise World 2017 — so might be my last post from here if I skip out on the one session that I have bookmarked for late this afternoon — and I’m sitting in on Mike Kremer of OpenText and Kiran Thakrar of SoluSoft showing SoluSoft’s Active Client Management for Insurance, built on OpenText’s Process Suite and case management. SoluSoft originally built this capability on earlier OpenText products (Global 360) but have moved to the new low-code platform. Their app can be used out of the box, or can be configured to suit a particular environment.

The goal of Active Client Management for Insurance is to provide a 360 view of the client, including data from a variety of sources (typically systems of record for policy administration or claims), content from any repository, open tasks and pending actions, checklists and ad hoc notes. It includes the entire customer lifecycle, from onboarding and underwriting, through policy administration and claims; basically, it’s user work management and CRM in one.

The solution is built on the core of Process Suite, using the full entity modeling AppWorks-style low-code development. It also includes process intelligence for analytics, Capture Center for document capture, and Streamserve for customer communication management. Above all of these OpenText building blocks, SoluSoft has built a client management solution accelerator that (I believe) they can use for a variety of vertical applications; below the OpenText layer is a service bus integration to line of business systems. For insurance, they’ve created a number of business processes and request types corresponding to different parts of the business, such as processing a new application, amending a policy, or initiating a claim; each of these can be configured for the specific customer’s terminology, or disabled if they don’t require specific functions. It’s not completely clear, however, how much of the functionality of other insurance systems might be replaced by this rather than augmented: clearly, the core policy administration system stays as the system of record, but an underwriting or claims system workflow might be replaced by this functionality. Having done this a few times with clients that use systems such as Guidewire, I have to say that this is a non-trivial architectural exercise to decide what parts of the flow happen where, and how to properly interact with other systems.

At the heart is a generic capture-driven workflow: scan, capture, index, data entry, process, approve, review, fulfill. The names of these can be aliased for different vertical applications — their example is that “processing” becomes “underwriting” — and steps can be skipped for a specific request type. Actions that can be performed at any of these work steps are configured using checklists. Ad hoc processes can be attached to steps in this master flow, either a single-step task or a more complex flow, and be executed before, after or in parallel to the pre-defined work step. Ad hoc processes can be created at runtime, and secondary request processes created for certain case types. The ability to make any of these configuration changes is restricted by role security. Relationships between clients, policies, brokers, claims, etc. are managed using folders for customers, policies and advisers, driven by entity modeling in Process Suite (AppWorks Low Code); this ability to establish relationships between all of these types of entities is critical for providing the complete view of the customer. They also have integrated iHub analytics for showing case statistics and workload analysis, as well as more complex analysis of risk or profitability for specific customer groups or policy types.

 

Although SoluSoft built some of this in custom code. a lot of the application is built directly in the OpenText low code development environment provided by Process Suite. This means that it’s fast to configure or even do some basic customizations, with the caveats that I mentioned earlier about deciding on where some parts of the workflow might happen when you have existing LOB systems that already do that. It also provides them with native mobile support through AppWorks, rather than having to build a separate mobile application.

We saw the version focused on insurance, but they also have flavors for pensions, financial services, government, healthcare and education. However, it appears that there is an existing legacy of the Global 360-based application, and it’s not clear how long it will take for this new AppWorks version to make its way into the market.

Case management in insurance

Case Management In InsuranceI recently wrote a paper on how case management technology can be used in insurance claims processing, sponsored by DST (but not about their products specifically). From the paper overview:

Claims processing is a core business capability within every insurance company, yet it is
often one of the most inefficient and risky processes. From the initial communication that
launches the claim to the final resolution, the end-to-end claims process is complex and
strictly regulated, requiring highly-skilled claims examiners to perform many of the
activities to adjudicate the claim.

Managing a manual, paper-intensive claims processing operation is a delicate balance
between risk and efficiency, with most organizations choosing to decrease risk at the cost
of lower operational efficiency. For example, skilled examiners may perform rote tasks to
avoid the risk of handing off work to less-experienced colleagues; or manual tracking and
logging of claims activities may have to be done by each worker to ensure a proper audit
trail.

A Dynamic Case Management (DCM) system provides an integrated and automated
claims processing environment that can improve claim resolution time and customer
satisfaction, while improving compliance and efficiency.

You can download it from DST’s site (registration required).

West Bend Insurance does BPM

I attended a webinar today, sponsored by Lombardi, featuring Stacie Kenney, a senior business process analyst at West Bend Mutual Insurance, discussing how they used BPM to allow them to tap into new insurance markets. West Bend has been around since 1894 and have a strong customer base in P&C insurance in the Midwest, but you can imagine the legacy processes and systems that build up over 115 years of operation.

They’ve seen significant growth in the past five years, and wanted to get a bigger piece of the small commercial policies market. However, they couldn’t do small commercial policies cost-effectively with their old business processes because the application process is time-consuming for the agents, and the commissions are small relative to the amount of time spent on the application. The underwriters spent a lot of time re-entering data on a variety of systems, including their mainframe policy administration system, a standalone and inflexible workflow system, and Word and Excel forms. They looked at BPM to provide a more agile solution that could more easily adapt to change through rule and process changes, make the referral process during process fast and easy, and provide visibility into operations. She didn’t give a lot of detail on what they actually did, although it was focused on the quoting and underwriting processes, with a focus on reducing the quote-to-issue time from days or weeks down to just minutes or hours.

They use both Blueprint (for process discovery and modeling) and Teamworks (for full process design and execution), and Kenney talked about what they liked about both products. She likes Teamworks because it allowed her, as a non-technical business analyst, to design the actual screens that they would be using, not just sketch a mock-up that would have to be coded by developers. She likes Blueprint for the ability to keep all process documentation in one place, including using it for what-if scenarios by modeling multiple versions of the same process to allow people to see them. Iterative process development was key for them, with playbacks every 4-6 weeks to ensure that the business was fully engaged, and that there was the opportunity to include their feedback all through the development cycle. They did less formal playbacks weekly, and targeted 3-4 month delivery cycles with at least 3 playbacks during that time. Quite an impressive move to an agile-like development cycle, from an organization that had a fairly traditional development methodology prior to that.

They used an architect and a couple of developers from Lombardi’s professional services to get them started and mentor their team; she noted that while anyone could use Blueprint, you do need some developers on the Teamworks side. One of the biggest challenges that they had was getting their heads wrapped around BPM: not just the tools and technology, but BPM as a new way of doing business. She believes (and I agree) that process analysis should be a core competency of any trained business analyst, but there’s some transition to move away from an application development mindset to more of a process focus in order to become a true business process analyst in the context of BPM. BPM shouldn’t be part of an application development project, especially one that has more of a waterfall methodology, since it will tend to lose momentum and you’ll tend to lose the agility benefits that BPM brings.

The BPM project for Small Commercial business was just the start for West Bend, and having it as a showcase project means that other areas are coming to them to request BPM in their areas. IT is also using BPM internally for their “Road to Excellence” program, which is focused on consolidating the functional silos of resources and tools within IT. They are using Blueprint as a collaborative tool to model their IT processes, redesigning 14 processes in 4 weeks; implementation is underway, and they expect to implement their IT processes in BPM by March.

Much of what they experienced isn’t unique to Lombardi, although Blueprint provides some extra benefits over many other BPM vendors through a more collaborative modeling environment and a process documentation repository. However, the BPM philosophy and agile methods that they used can be used with pretty much any BPM product: that’s more an issue of corporate culture than the specific product, as long as it provide model-driven process development.

The original registration page for the webinar is here, and they’ll have a replay available soon.