10 Best Practices Insurers Should Adopt when Selecting Core Systems
Introduction
Selecting an insurance core system is more than simply finding the solution provider with the most functionality or simplest UI, it is about finding the solution provider that aligns with the priorities and values of your organization. To accomplish this, insurers must create systems selection processes that accurately identify all stakeholders, balance their needs, and differentiate between solution providers. The following best practices can help system selection leaders be more effective, efficient, and successful in selecting the best aligned solution and get the solution delivering value quickly.
Best Practices
1. Ensure your organization is ready for facts before spending time and money to get them
Too often insurers undertake REP projects to create the illusion of thoroughness, when in fact senior leaders know from the start they intend to select the politically expedient solution, the incumbent solution, or their favorite solution. A good RFP process will reveal facts about the best solutions and will help refine organizational priorities. However, each organization has its own decision model that defines how decisions are made. The system selection teams should understand the decision framework that is most often used in making these decisions. It should also be noted that no organization uses a single decision model but will often employ a mix of models. The models are:
Political – Some organizations are very political, with those possessing the most political power choosing for the organization.
Incumbent – The incumbent model heavily favors those solutions that already operate within their organization. In some instances, the incumbent solution is so well entrenched within the organization that IT decisions are deferred to those solution providers for strategic decisions regarding an organization’s IT future.
Competition – This model leans heavily on following competitive trends to see what competitors are doing and mimicking their operational and IT decisions.
Fact – A fact-based decision model relies on facts, observations, tested principles, and objective third parties to make decisions.
Business or IT leaders who are tasked with selecting a new system should consider the last several system selection processes and consider how those decisions were made previously. They might consider doing a quick pie chart (See Figure 1) to visualize their organizations’ decision-making pattern.
Figure 1. Sample Organizational Decision Pattern
Source: Coretech Insight, June 2024
While each decision approach has its merits, a fact-based decision-making approach will serve organizations best over the long run. Facts help organizations balance the current and future needs, reduce the amount of passion and frustration during the selection process, create better organizational buy in, balance various constituencies’ needs, and improve long term competitiveness. That said, insurers should not spend time, effort, and money for facts if they will not be valued or deliver influence over the final decision.
2. Follow a disciplined process
A disciplined process will help insurers include all the possible solution providers first and then select the best solution for their broad set of needs. Here are the most typical and effective steps to follow.
Create a list of organizational goals and objectives - Build the business case for why change to the underlying tools is warranted.
Identify all solution provider alternatives – Solution selection leaders should create a master list of solution providers through Internet searches, industry events, industry peers, LinkedIn groups, industry analysts and publications, and industry websites.
Create a list of “must haves/can’t haves” - Create a list of essential characteristics that can be used to narrow the number of solution providers. Target fewer than fifteen “must haves/can’t haves” questions. Too many questions may indicate a strong bias for the status quo and questions may need to be rethought. If solution providers answer in an unfavorable way, they are immediately disqualified from the RFP. The questions might focus on development languages, the preferred technology stacks, support for critical capabilities, key innovations or integrations, numbers of production customers, etc. It is important at this stage that solution providers cannot ascertain the difference between the “must haves” and “cannot haves” so they will not be tempted to stretch their answers to appear more appealing.
Create a Request for Information (RFI) – Sending a full RFP to more than seven or eight solution providers will create unnecessary work in reviewing all the responses. Instead, create an RFI that will identify the most viable solution providers. Use the “must haves/can’t haves” questions to narrow the list of solution providers that will receive the RFP.
Create a request for proposal (RFP) – The solution providers that were not filtered out of the RFI process should then be invited into the RFP process. Create an RFP reflecting the prioritized and weighted requirements with both functional and strategic questions to differentiate solution alternatives. These questions should highlight the differences related to functional support, implementation skills, innovation, technology, and much more.
Evaluate the RFP data – Once the RFP documents are returned, insurers must evaluate the responses. The evaluation should go beyond a simple functional capabilities assessment to include characteristics such as innovation, speed to market, fit, risk, system agility, deployment competency, and others.
Select the top two to four solutions – After analyzing the data from the solution providers fewer than five should rise to the top.
Design and invite solution providers to participate in a proof of concept (POC) – Create further differentiation between solutions by defining a POC, or detailed demonstration deep dive, which targets the two or three most critical characteristics of the solution. For example, if speed to market is most important, have solution providers show how their solution can get products to market quickly. If innovation is most important, ask the solution provider to demonstrate their most innovative capabilities.
Perform reference checks – Too often insurers perform reference checks after they have already made their decision. When reference checkers are already sold on a solution, they often discount negative feedback about their choice. Reference checks done on site will tend to generate much more nuanced, thoughtful, and comprehensive feedback which will help organizations anticipate and plan for potential implementation problems.
Make a decision and begin planning for the implementation – Based on all the information gathered, insurers should make their decision and initiate planning to coordinate schedules and resources for a successful transition to the new solution.
3. Provide a range of response options that go beyond a simple yes or no
Many RFPs simply allow a yes/no response or may have a text box to complete. These responses are difficult to evaluate accurately. Often, a yes or no is not enough detail, and free text responses can be difficult to interpret. For example, a solution provider may use the response, - “the system can support”, rather than “the system supports.” This nuance obfuscates whether their solution can be configured to meet the requirement or whether coding is required. With insurers increasingly pursuing no code/low code strategy to lower their long-term future upgrade costs, there is great value in understanding whether (and how) features are supported out of the box.
There are two ways to do this. The first is to ask RFP questions with various categories of responses. Table 1 shows a sample of how this could be done, allowing solution providers to include their narrative response in the appropriate category.
Table 1. Sample RFP Question Format #1 (EXAMPLE)
| # | Question | Supported out of the box, current release | Supported out of the box, current release with some configuration | Supported by future release (within the next 9 months) with or without configuration | Code customization is required to support with current release | Function is supported by a separate module that requires additional license | Function is not supported |
|---|---|---|---|---|---|---|---|
| 344 | Does the solution support electronic signature? | Our solution seamlessly integrates with third party providers out of the box | |||||
| 345 | Does the solution support intelligent chat? | Our solution has intelligent chat built in to support customer service and sales requests | Intelligent chat can be enhanced with terminology libraries and organizational specific content if desired |
Source: Coretech Insight, June 2024
Table 2 shows a second approach to answering by instructing the solution provider to respond with a corresponding letter and then add the appropriate narrative description in the response column.
Table 2 - Sample RFP Question Format #2 (EXAMPLE)
Response Types:
A. Supported out of the box, current release
B. Supported out of the box, current release with some configuration
C. Supported by future release (within the next 9 months) with or without configuration
D. Code customization is required to support with current release
E. Function is supported by a separate module that requires an additional license
F. Function is not supported
| # | Question | Response Type Letter | Response |
|---|---|---|---|
| 344 | Does your solution support electronic signature? | F | Our solution seamlessly integrates with third party providers out of the box. |
| 345 | Does your solution support consolidated billing by household and/or individual? | A | Our solution has intelligent chat built in to support customer service and sales requests. Intelligent chat can be enhanced with terminology libraries and organizational specific content if desired. |
Source: Coretech Insight, June 2024
4. Give clear instruction about how the solution provider should answer
Solution providers will often use existing content such as previous RFP responses, marketing material, whitepapers, press releases and other content, in their RFP responses. This makes evaluation of RFP responses exceedingly difficult to analyze and score when these additional documents are simply added to the RFP response. Solution providers need to be told to only include additional content as it relates to specific questions. Furthermore, solution providers should do more than simply link to another document or website, but link to the exact section of the supplemental material as part of their answer. As a best practice, insurers should provide clear and detailed instructions on how solution providers should:
Refer back to previous questions’ answers
Limit the length of responses
Refer to or link to supplemental content
Provide the right balance of:
Why – the value of the capability
What – the scope and details of the capability
How – the method used to create the capability
5. Share goals and priorities
We have seen some insurers choose to keep critical information away from RFP respondents to attempt to prevent solution providers from exaggerating their capabilities and corrupting the results. While this is essential at the RFI stage, the RFP stage is the opportunity for each participant to make their absolute best case for their offerings. Insurers benefit when a solution provider’s best case is closely aligned to the needs of their potential customer, and a well-executed process will sort out any exaggeration.
6. Create differentiating questions for the RFP
The purpose of an RFP is to create differentiation among the respondents and understand which solution will best achieve the short- and long-term objectives. A good approach to creating differentiating questions is to invite the solution provider to provide details about how they meet a requirement rather than just asking if they meet the requirement. More detail that describes the method the solution provider used to create the functionality helps insurers make better judgments about the solution provider’s capabilities and approach.
Furthermore, insurers should ask only those questions that will provide differentiation. Rather than listing everything a solution must do, eliminate the questions that will clearly be handled by all the solution providers. While this is not always easy to anticipate, insurers should be willing and able to make certain assumptions. For example, if a solution provider has over six customers who are using the system for a similar function, it would not be necessary to ask about all the features related to that function. Instead, insurers might only ask about those characteristics that are differentiating about those functions.
7. Avoid being reactionary to what is not working well today
It is common for insurers to focus too much on what is not working with the current system. Instead of finding a holistic solution for the long term, insurers can get overly focused on a solution that does that single function very well. For example, an insurer might be frustrated with their existing solution’s ability to configure workflows. This might even be the core reason for switching solutions. Fixating on workflow might cause the insurer to overlook other critical capabilities. As a result, it is important they design an RFP that does not give too much weight to workflow configuration but rather reflects an organization’s “ideal” state and reflects their holistic needs.
8. Think holistically about the RFP questions and format
A good RFP is more than simply a list of questions for solution providers, it is a comprehensive tool to match a solution provider to the current and future needs of an insurer. Follow these key principles to reduce bias and maximize results.
Clear Guidance - Provide clear instructions, organizational background, pain points, goals, and objectives, etc. to provide the best possible context for solution providers.
Clear Questions – When writing questions, consider all the ways the questions can be read and interpreted and refine them to be as clear as possible.
Establish Weights – Before receiving RFP responses, establish the weights that will be used to evaluate questions and categories.
Balance the RFP – When establishing weights make sure the scoring of the questions will create an accurate, and well-balanced outcome. Create some test responses that reflect typical solution provider responses to see how the scores practically play out in the scoring model.
Evaluation Categories – A well-executed RFP should go beyond functional capabilities and capture critical information about a host of other categories both strategic and practical. These categories will be used to understand the fit of solution providers to the broad set of needs insurers have. As the RFP is developed, certain categories and themes will emerge which should help to define the evaluation categories. These could include the following:
Scalability
Total cost of ownership
Cost benefit analysis
User functionality
Solution configurability and upgradability
Future value of enhancements
Existing partnerships and integrations
Legacy components
Speed to value
Deployment experience
Alignment with existing business
Future looking and innovative
User experience and ease of use
Long term viability
Risk
Others
9. Evaluate responses in a comprehensive way
Too often insurers take a simplistic approach to RFP development and scoring. Instead of scoring comprehensively across a full set of strategic and practical categories, insurers simply create a list of questions and score them when their responses are received. Figure 2 below illustrates this simplistic approach with the decision to go with solution Vendor 5 simply based on the overall functional score. This simplistic approach falls short of the depth of analysis required to thoroughly evaluate the alignment and fit between the insurer and the solution.
Figure 2. Vendor Functional Alignment
Source: Coretech Insight, June 2024
Scoring RFP responses across multiple categories will help align the RFP results to the broader values and enterprise level goals insurers have. This deeper analysis reveals that behind the simplistic evaluation lies significant detail about how each solution can be viewed across the priority categories noted above. This lens approach makes visible the differences between solution providers and helps facilitate important discussions about the best fit to meet organizational priorities. Figure 3 below shows the details behind the initial functional score against 11 additional categories.
Figure 3. Vendor Scoring Across Strategic Categories
Source: Coretech Insight, June 2024
Figure 3 shows how Vendor 5 has the highest average score because it is exceptionally strong in some categories. However, it also very weak in some categories. These weaknesses may be critical to the needs of the organization and may ultimately lead to Vendor 5 being rejected as a viable alternative.
Not only does this lens style approach deliver much more detail about each solution provider, but it also exposes weaknesses in all the solutions. Becoming aware of these weaknesses early gives the implementation planning team the advance notice they need to effectively plan for these weaknesses in the selected solution provider or solution. Implementation teams can marshal additional resources, fill knowledge gaps with third parties, or plan to spend additional time on certain aspects of the project.
10. Get everyone on board with the dream of the new platform
Whenever insurers embark on a system selection process, stakeholders get excited about the concrete ways the solution will help them meet their business objectives. These hopes as shaped in the mind of each stakeholder will help them endure the pain and challenges during the transition. It is important that the solution selection team provide ways to support these hopes with questions in the RFI and RFP that document these objectives. Including questions that reflect stakeholders’ hopes builds consensus and makes discussion and negotiation of these hopes visible to all.
Everyone means everyone. One of the jobs of senior leadership is to ensure that the system selection team is not being overly influenced by a single participant or department. Each department and stakeholder should have a voice, and it is critical for senior leadership to advocate for the whole organization, providing balance to a politically connected or charismatic participant.
It is also vitally important that, as the system selection team begins to plan for implementation, the hopes that helped shape the selection process are supported in the implementation plan. For example, if a manager is counting on shorter training cycles for new employees, something in the first or second phase of the project should ensure that training cycles are being reduced. If stakeholders do not see their hopes realized, they are likely to become disillusioned about the new platform and weaken their support for the transition as the project inevitably becomes more challenging. Practical, measurable value delivered to each stakeholder in each phase will reinforce each stakeholder’s dream and encourage ongoing support and enthusiasm for the new system.
Summary
While formal system selection processes can be expensive and time consuming, they can be instrumental in shaping organizational priorities while finding a longer-term partner to help them. Insurers should follow these simple steps to optimize their process for the selection of their ideal solutions and foster an environment where:
Solution providers will be interested and eager to do business with you.
You obtain better visibility into where the implementation challenges are likely to be going forward.
Insurers can achieve more clarity about the costs and benefits of the chosen solution earlier in the process.
Internal stakeholders have greater confidence that the system selected is the right solution for them and the organization as a whole.
The process drives conversations about how various solutions can facilitate both short- and long-term organizational objectives.
About the Author
Steve Leigh has served the insurance industry for nearly three decades in senior roles with leading companies such as Zurich Insurance, Gartner, and Microsoft. While with Gartner, he authored multiple Magic Quadrants on the life insurance industry. At Microsoft, he focused on creating solutions that enable Fortune 1000 organizations to capitalize on emerging trends and technological advancements. His work at Microsoft also extended beyond insurance to commercial and retail banking.
Email Steve at steve.leigh@coretechinsight.com or contact him via phone at +1 (719) 440-8710
About Coretech Insight
Coretech Insight is an independent advisory firm focused on insurance core technologies. We serve insurers and coretech solution providers who need to grow their business and want to find their ideal customers and tech solution partners. Our experience as insurance coretech customers, industry analysts, and solution providers has given us a unique and grounded perspective. We provide research and professional services that connect leading insurers and coretech solution providers to accomplish great things.
For more information, contact us at info@coretechinsight.com or reach out to us individually via the About Us page
Whether your focus is a tech solution decision or outreach to an ideal customer – or something in between – we’re ready to listen and work with you to understand your needs, apply our insight, and craft practical solutions.