Posted on January 6, 2015 by Kevin Walma
As insurance carriers are emerging out of the great recession, I’ve seen a definitive movement toward investing in transformational policy administration replacement projects. I am encouraged by the move away from a “do nothing” strategy where carriers continue to maintain and expensive, inflexible and out of date technology. In the same vein, I’m concerned that carriers will ultimately be disappointed because the tried and true selection criteria such as vendor size, install base and architecture may no longer be as relevant or lead to true platform modernization. In fact, it might actually influence carriers to select a solution that settles for only marginal improvement.
Selecting a vendor that is larger does not means less risk because they have more people, more internal structures or may have access to more capital.
While larger organizations may tout employee counts in the hundreds of thousands, in every situation the Insurance system “division” where the folks that actually work on the technology and are available to the customer is far less and usually very segmented. This type of size also translates into more approval levels for contractual, strategic, and investment decisions. This frequently results in more risk and cost, while providing a less nimble and empowered team.
Instead of focusing solely on company size, I recommend that carriers assess whether the company has a plan to scale up to meet their needs. I encourage evaluating the company on the team that ultimately will be partnering with your organization. This solution provider team should bring experience and an approach that can assist in rapid product implementation practices and creative thought processes for solving problems.
Selecting a vendor with a large installed base does not mean that the current version of the application is established, comes with a seasoned implementation team available, or ultimately has less risk.
If the version of the software that another company installed was from many years prior, it likely may share little with the current version being offered. In fact, many of the systems at ‘large’ vendors are the result of an acquisition, where likely the bulk of the resources that make up the ‘depth’ of installs are no longer a part of that team. In some scenarios, a system may have been completely ‘re-written’, which then equates to the same risk of early adoption as a ‘new’ system vendor and essentially nullifies the value of a broad customer base.. This also means that the staff on hand might be more focused on maintenance than experienced in implementation.
I recommend finding out how many customers are on the current version vs. how many are on an older version. These numbers start to provide some insight into how easily the solution is upgraded, the level of customization among the current client base and the maturity of the current solution.
Sometimes the modern “component based” terminology that vendors use is more marketing speak than reality.
All systems have an “architecture”. Regardless of the platform, design, or structure of the application, every vendor is going to view theirs in a positive light. All vendors are responding to RFPs with the pea soup of buzzwords that make it difficult to compare on paper the differences in how this architecture supports all the insurance features. Larger organizations have entire marketing departments skilled at presenting their technology as configurable, flexible and service oriented.
However, It is important to take the time to understand what is actually configurable – perform actual live functions and measure the effectiveness of implementing the change. In today’s environment, Insurance Product development processes can be accomplished without traditional coding and expect that the ‘configuration’ should be performed without proprietary ‘syntax’ or complicated programmer like tasks. Look for common, intuitive techniques for accomplishing business rules, screen edits, and calculations. Ensure that advanced infrastructure techniques including virtualization and high-availability are inherent to the technology stack. The offering should enable either a native or responsive design-based approach to support the proliferation of mobile strategic plans. Verify that web services are exposed as real-time events – not placement of data for later processing. The real benefits of the architecture of the system should be evident in its ability to enable a component based approach to fulfilling scalable SOA orchestrations in a ‘Straight-through-processing” approach. This is key to enabling agent and customer portals with up to date information and the ability to perform self-service transactions.
In today’s current vendor environment, it is absolutely critical to treat information such as vendor size, installed base and technical modernity claims as data points to be explored further, rather than facts that can be evaluated in isolation. Unfortunately, these data points only tell part of the story and are prone to inferences, and can result in sub-optimal system selections.
Don’t let this happen to your team. Following these guidelines will help you to ensure that the system – not just the sales presentation – gives you what your company really needs.
About Kevin Walma:
Kevin is Head of Product Strategy at FAST is focused on strategic product direction, design and architecture. Kevin brings over 18 years of experience in Insurance and Technology. Kevin can be reached at firstname.lastname@example.org.