Competition, regulatory compliance and cost cutting still drive life insurance product lifecycle management (PLM).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.
But are carriers taking advantage of the most efficient processes and technology? As some insurance companies evaluate the promise of new PLM technologies, they are discovering the give-and-take that must occur between IT and product development teams.
"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."
However, more carriers of all sizes are coming to the realization that the "if it ain't broke, don't fix it" mentality may impede their ability to consider the larger step to PLM technology.
"There is a primary fear to tackle the large task of taking the rules out of the policy administration system," notes Lafreniere, "which comes out of the idea that you need to implement all at once instead of one step at a time."
The benefits of continually rethinking both PLM technology and its processes, however, often spin forward into the essence of PLM: an approach that allows an insurer to receive continuous product-related feedback, from the technology side as well as the functional user groups who helped develop it.
"There is a lot of activity around state regulatory reporting requirements, time stamps, more hierarchy in the product's development-all of that requires a level of sophistication in which all users should collaborate using the same information," says Harris-Ferrante.
The collaborative approach to development, especially as applied to the complexities of life and annuity development, is not lost on Massachusetts Mutual Life Insurance Co. (Mass Mutual), Springfield, Mass.
The company, which offers a portfolio of products and services, including mutual funds, money management, trust services, retirement planning products, life insurance, annuities, disability income insurance and long-term care insurance, gives a fair amount of credit to collaboration for its six- to nine-month to-market window.
"It's critical," says Robin Parent, project management office business partner and director of product development.
"We have a very large cross-functional life products team from a number of business units-including legal and regulatory-who are all engaged and bring their various perspectives to the table to make sure we are making the product what it needs to be."
Management of this effort doesn't fall to a formal product configurator, but more to a strong process, notes assistant vice president Stefano Martini, who heads up Mass Mutual's life insurance technology group.
"We don't have a formal tool, per se, but there is a fair amount of collaboration with IT early on in the lifecycle to test the viability of the product, perform some early sizing and costing out, and manage other iterations during each phase of the development effort."
Stefano confirms that Mass Mutual is investing significant dollars and effort to upgrade its current systems for its traditional whole life, term and universal variable life products. "With those implementations there will be additional automation that we expect will help in the product development arena," he says.
Both Mass Mutual and AmerUs Group are in the process of upgrading their existing PLM and policy administration-based applications to reflect XML and other standards-based protocols, service-oriented architecture and Web services.
"IT needs to be a strong partner," says AmerUs Group's Doruska, "as do our other functional areas. We are all one team that succeeds or fails together."
Camilion's Lafreniere agrees: "It's critical to provide the functionality necessary to help both IT and business users better do their job, and as a by-product, to provide a single view of the product record, across the extended enterprise. But it's also imperative to address the sea change required, as more and more business users are asked to participate in collaboration and technology use."
THE ROOTS OF PRODUCT CONFIGURATION LIE IN MANUFACTURING
If we agree on the definition-product configurators are rules-based or knowledge-based tools that generate a list of components or assemblies, a product structure and associated documentation-it's easy to understand why long before the insurance industry considered the product configurator a viable instrument to facilitate product development, the manufacturing industry considered it to be one of the most valuable tools in the toolbox.
For good reason. Consider the aerospace industry, in which regulatory compliance is intrinsic not just to a manufacturer's delivery of product, but also to its survival.
At each point during the manufacturing product life cycle management (PLM) cycle, which includes concept, design and development, prototype and pilot, launch and ramp, production, service and support, and finally phase out and retirement, an aerospace manufacturer's quality assurance program must meet the most demanding standards established by the Federal Aviation Administration, the U.S. Department of Defense, all U.S. space agencies, ISO 9001, AS9100 and the requirements of all aircraft manufacturers.
Now consider the Lockheed Martin F-35, aka Joint Strike Fighter, a military aircraft comprising approximately six million components and a host of component options. Every component option the government chooses affects the availability of other options and changes the military aircraft's specifications and price.
So far, three variations of the aircraft have been ordered: a marine version, navy version and air force (dogfighter) version. It takes the sales agent weeks or months working with Lockheed Martin engineers to make sure all the chosen pieces fit together, renegotiating the price at every step.
The technology must produce the list of selected components as well as the structure and topology of the product. In order to perform product configuration efficiently and effectively, the end product must be prepared for it. Currently, military aircraft must be engineered, modularized and assembled from pre-developed components, all of which also must pass a rigorous regulatory qualifying process. Further, sales and production activities must match the opportunities and constraints of configurable products and new requirements for manufacturing and assembly and for planning and scheduling are developing.
DIFFERENT PRODUCTS, SAME LIFECYLE MANAGEMENT
Unlike the physical components of a typical manufactured product, insurance products are considered less tangible, and are most often considered "intellectual property." However, product life cycle management functions the same in both a manufacturing and insurance environment. Both require:
* Support for product lifecycle business processes (IT, labor)
* Platform for building
* Knowledge repository
* Integration of disparate pieces
* Effective change management
* Single enterprise version of the truth
* Access, share and manage product information securely
* Scorecards, formal review
* Governance/accountability to stakeholders
Even from a regulatory reporting and compliance perspective, requirements of both industries are similar. From an insurance product development perspective, compliance means an insurer must only sell products with language and prices that have been approved by regulators and conform to appropriate laws and regulations.
From a manufacturer's perspective, a manufacturing company can only sell products that have been approved by regulators and conform to laws and regulations.
