New Products, Special Delivery
Insurance Networking News, June 2006
To remain competitive in an economy with a demographic of escalating baby boomer prospects, developing and maintaining a constant flow of new product offerings requires agility, expert communication between work groups and technology to support the effort.
Advertisement
"Many companies use PLM for strategic advantage," says Kimberly Harris-Ferrante, research vice president, Financial Services' Insurance Industry Advisory Service, Gartner Inc., Stamford, Conn. "Even though a lot of carriers are involved in do-or-die projects, not all view it as a necessity."
Whether the merits of PLM are appreciated is a matter of perspective. Harris-Ferrante confirms that whether they recognize it or not, most carriers have PLM processes and technology in place: Some use it for internal controls, while others use it to increase speed to market.
"Most have some tools or technology to help with product development," she says, "but a lot of this type of technology is being used more for organizing and keeping a product library-coverage levels, components of a product in development, etc. Using PLM technology in this way is more to help organize the product. Some carriers are using it to assist with pricing and actuarial functions, but not necessarily to get a product to market."
THE BIGGER PICTURE
As Tom Doruska sees it, the challenges inherent in bringing an insurance product to market are shared industrywide, and not all are technology-based.
As vice president, life product development at AmerUs Group, a 110-year-old Des Moines, Iowa, provider of life and annuity products, Doruska is responsible for execution of the product development process. His team coordinates work with functional groups such as legal, compliance, human resources, actuarial, marketing, field, operations and others.
"We tend to look at the bigger [PLM] picture, because being able to provide efficient and continuous product development in light of industrywide regulatory issues, we are challenged, like other companies in our space, with staying on top of the systems and staff required to remain competitive. We know that this level of focus and activity in the industry will continue."
In order to bring a new life product to market in the company's typical six- to nine-month lead time, Doruska's team follows its own strict, four-step PLM process.
Phase one includes evaluation of a rough proof of concept from sales and marketing; phase two includes creation of a pricing model and product specification; phase three involves a two-week window in which corporate IT provides final analysis and system modification review and works with other departments to create the business forms, filing, customer service elements, etc; and phase four involves completion of system building, policy form filing and the marketing that will go into the product's introduction to the marketplace.
"We engage IT early on, while we are still in the midst of discussing product design," he says. "The business analyst, programmer and IT manager work with us on implementation. As early as phase two, we talk about what our system capabilities are, what features would require system improvements, etc. It's truly a back and forth-where our programmers or business analysts suggest alternatives, simplify the administration or development of the product, set a realistic target date, and still meet our market needs and our profitability requirements."
GIVE-AND-TAKE
Creating a give-and-take between IT and product development points to the importance of collaboration-a hallmark of PLM-as well as to the changing roles both groups have in the success of the project, says Harris-Ferrante.
"The premise is that responsibility for creating the product has shifted to the business user," she says. "Some business users don't want that responsibility, and some companies are either not internally ready [to give business users the ability to use PLM software], or believe the software will be too complex for the business user to operate."
To simplify complexities, Harris-Ferrante suggests the use of product configurators; software tools designed to aid users in developing approved product configurations quickly and accurately and with minimal effort.
The goal in product configuration is to store all product and coverage information as business-defined data as opposed to programmed code, notes Philippe Lafreniere, Markham, Ont.-based Camilion Solutions Inc.'s director of product management.
"This allows insurance business users to define and modify insurance product rules and definitions," he says. "All aspects of the product, from its eligibility to its marketing, are managed within the system."
Most companies already have lightweight configurators, notes Harris-Ferrante. "It's really product creation, modeling, testing and overall management," she says, "and a configurator allows you to do that in one central place."
Configurators also address a common dilemma: when IT claims that business users can't articulate what the product should look like and business users claim that IT simply doesn't understand what they need. "The product is iterative, changing over time, or it's a comprehensive product that may be hard to implement," she says. "Both sides point at each other. Product configurators allow the business folks to sit down and in business language create the product without IT's heavy involvement. IT can then go in and make it happen."
SINGLE VERSION OF TRUTH
Harris-Ferrante points out that many policy administration vendors purport to have product configuration tools embedded in their systems, and all offer development tools, which may be adequate for smaller carriers.
"But if you are a big P&C carrier, you can't manage based on one policy management system. You might have up to 15 mini data libraries, which makes the need for a single version of the truth even more important."
For more information on related topics, visit the following channels:
