In an effort to reduce internal IT costs, more insurers are considering buying packaged software-as opposed to building customized applications.However, many executives in the industry-those evaluating packaged software solutions-may not be familiar with vendors and products that are available. Therefore, they may have difficulty assessing them.
"I've spoken with a lot of people who get frustrated with vague vendor presentations that don't tell them what they need to know or may not be the right solution for them-or even close to the right solution," says Matthew Josefowicz, senior analyst at Celent Communications Inc., a financial services research and advisory firm, based in Boston.
As a result, Celent developed 20 questions for insurance executives to ask technology vendors. According to Josefowicz, insurers should ask these questions as early in the evaluation process as possible.
"If an insurance company is on a fishing expedition to try to learn more about a certain market space, and it's looking for a high-level presentation, there's no need to hit the vendor with all these questions early on," he says. "But if the insurer has a good idea of what it wants to accomplish with a particular technology, then these questions can save a lot of time and aggravation."
How will this product solve my specific business problem?
Before you can ask a vendor meaningful questions, you must have a clear idea mapped out of what you want to achieve. By telling vendors your goals up front, they can focus their meetings on the most relevant areas. If a vendor can't provide a customized presentation addressing your specific problems, it's likely the company doesn't have the correct solution for you.
Will this product support my future plans?
If your company is planning to launch new products, add new distribution channels, add new enterprisewide IT systems, or adopt enterprisewide standards, such as ACORD XML, vendors should be able to provide a clear roadmap of how they will support those future plans.
Which insurance products does your solution support?
In many cases, vendors may not be fully aware of the requirements of specific insurance products or lines of business. Make sure the vendor understands what your needs are-and that the system supports those needs or can be modified to support them. Beware of vendors that do not understand the complexities of different insurance products.
Can we see a functionality specification sheet, free of marketing language?
Insist on a full specification sheet (three to 10 pages) that lists the specific functions of the vendor's system. The list should sort functionality by each user type, such as agent, policyholder, customer service representative, business analyst-as well as by each functional area, such as reporting, new business transactions, customer information queries, document composition options.
How will you integrate with my current systems?
Integration is the most costly and painful part of any new technology purchase. Understand the vendor's integration method and make sure the vendor provides a clear integration roadmap. Three common integration methods are: open API, EAI platform, and XML-based Web services.
What kind of IT skills will my team need to support your system?
The product you're considering should use technologies, platforms, databases and programming languages that your IT team understands and uses. If it doesn't, consider the cost of training your staff or of adding new staff as part of the total cost of ownership.
Do you offer an ASP or outsourcing model?
Many vendors offer both licensed and outsourced or ASP solutions. If you're willing to consider outsourcing or an application service provider option, play close attention to service-level agreements and contractual guarantees.
Do you support ACORD XML standards?
XML enables disparate systems to talk to each other, but they can't understand each other unless they use a common vocabulary. ACORD XML standards maintain a common vocabulary of data and transaction types to enable insurers to reduce the difficulty and expense of data interchange. Even if you're not using any kind of XML, leave the door open by selecting a system that is ACORD XML-compatible.
What is the total cost of ownership for your system?
Total cost of ownership should include all expenses associated with launching and running a new technology, including base license, additional component license fees, per-transaction fees, per-policy-of-other-volume fees, additional seat licenses, additional CPU licenses, installation and customization fees, testing/quality assurance fees, maintenance fees, per-incident support fees, additional software and hardware costs, and IT and user training costs.
How does ROI on your product compare with other products in your class?
The return on investment figures that vendors usually present compare the results of using a new system against not using it. Look for ways in which the product you're considering is superior to other products in its class. For example, does it have more features or better performance or scalability? Is it less expensive? Is training better or are development and integration cycle times shorter so results are achieved sooner?
What kind of resources does your company have?
Find out how stable the company is, how much cash it has in the bank, and if it will be around to support the product in the future. This is especially critical when dealing with smaller, lesser known companies, but make sure that even large, stable firms are committed to the product long-term. Also, find out if the vendor has a large enough implementation and support team-even if it lands a large new client.
What's your support organization like?
Ask for details on the vendor's support staff. How many people are there? What are their credentials? What are response times? Is support always available? Is there more support during implementation and testing? Are there per-incident fees beyond standard maintenance? What service is considered support, and what service is considered a modification? Make sure support levels are guaranteed in your contract.
How will your strategic partnerships affect me?
Many strategic partnerships are insignificant to potential buyers, but if a vendor has a partnership with a well-known systems integrator, it may be able to provide better integration and support services. Understand the nature of any vendor partnerships, and whether or not you will be required to form an independent relationship to benefit.
Can we talk to your current clients?
Many insurance companies won't provide references for vendors, but if a large number of clients are willing to talk to you-that's a good sign. When you talk to a customer, ask specific questions, such as: What business problem did you engage this vendor to solve? What IT skills did your team need to support the system? Was the TCO what you expected? Did the vendor meet your timeline?
What is a typical implementation timeline like?
Make sure the vendor provides a clear road map with time estimates for each step. It should provide a structure that covers requirements gathering, customization, deployment, integration, testing, staged rollout and training.
What is your project management methodology?
Most insurance companies do not have well-developed project management methodologies for technology projects, which leaves this critical function to the vendor. Scrutinize the vendor's methodology to ensure you understand how the company will manage the project-and what will be required from your own IT and business staffs.
How do you ensure technology transfer?
Make sure the vendor has provisions for transferring technology, such as detailed system documentation, formal training sessions, dedicated technology transfer resources, and specified availability of experts both during the project and after it is completed.
What kind of training support can you give us?
Training is a critical part of implementing a new system, so view it as part of the overall investment rather than as an additional cost. Most vendors consider training to be the buyer's responsibility. Then, buyers blame the vendor when the system isn't adopted by users. Training should be as hands-on as possible, with users shown not only how to use the system's features, but how those features help them do their jobs better.
What contractual guarantees do I have for timelines and service levels?
Contracts typically guarantee such items as: staged implementation timelines, maximum implementation costs, maximum cost overruns, minimum performance levels, scalability per CPU (maximum number of users, concurrent users, etc.), maximum response time for service requests, and maximum cost for service. Contracts also should include the buyer's responsibilities, such as response time to vendor requests for information, and provisions to guard against scope creep and feature creep.
What is your approach to keeping your goals aligned with mine?
Discuss incentives with your vendors. If possible, build incentives or penalties into the contract for meeting or surpassing incremental milestones or goals, or link incentives to adoption rates, cost savings or other performance goals.
Questions from "20 Questions to Ask Insurance Technology Vendors: A Guide for Insurance Executives," from Celent Communications Inc., Boston.
