Once upon a time when I was an underwriter, my manager was fond of telling me we didn't sell a product, we sold a promise. And at a high level, he was entirely correct.

But at a more granular level, that promise differs from product to product based on the detail of the contract, whether it's a life, health, or P&C policy. Furthermore, a set of promises that's right for one customer may not be right for another.

Like any product manufacturer, insurers seek to find ways to make their offerings stand out in the marketplace. It's not just the oft-cited speed-to-market goal–it's about delivering the right product at the right time to the right customer.

“Truly being able to respond to market conditions is the missing link” in product development, says Kimberly Harris-Ferrante, vice president and distinguished analyst at Gartner Research.

Helping insurers connect that link is the objective of product configurators. These systems, designed to support the product development life cycle, are not new technology. “Product configurators started in the 1980s,” Harris-Ferrante says. Even so, she remarks the market is not mature and the technology is a “work in progress,” adding that although the deployment of systems among all sectors of insurance has increased in recent years, only a minority of carriers use dedicated product configuration platforms outside their policy admin environment.

Part of the reason for this state of adoption relates to my former manager's comments about the definition of a product in a service sector such as insurance. Product design is an easier concept to define in manufacturing, where the development world has progressed from pen and paper and clay models into tools that let you create, modify, and test product concepts without ever having to leave your computer workstation.

“Product configuration is tougher in the service context such as insurance vs. manufacturing, because it can contain not just product specifications but business rules, legal forms, pricing algorithms, and other information,” says Roy Wildeman, senior analyst at Forrester Research. “Configurators do a good job by capturing both those pricing algorithms as well as eligibility. They then can provide detail of the product architecture and organize and establish integration structure required to make product changes.”

ORDER FROM CHAOS

The purpose of configurators is to centralize product information as well as organize the product development process, which often can be scattered among different systems and areas of responsibility, and that leads to redundant development effort and delays in deployment.

“Configurators are the workbench,” Harris-Ferrante says. “Particularly if there are a number of policy admin systems, carriers benefit from centralizing development. They can see what products are consistent among the systems and replicate current products for other systems and delivery channels. It's about economies of scale and centralized control.”

“One of the real key potential benefits of configurators is allowing business users to manage directly product data rather than maintaining desktop spreadsheets,” Wildeman adds.

Combining centralized control with distributed, user-level product development responsibility is a goal of Liberty Mutual Agency Markets. Liberty is in the midst of rolling out a product development suite based on Accenture's Insurance Configuration Component (ICC) solution. Safeco, which was acquired by Liberty in 2008, had been working with Accenture on deploying the ICC system at the time of the acquisition.

“We wanted to empower the business to view the logic governing the rating and pricing of our products, to make enhancements to that logic, and to test and try different changes. The way to do that in a more efficient process was to eliminate some of the handoffs that existed between business and IT,” says Kurt Schulenburg, director of commercial lines IT program delivery in Liberty Mutual Agency Markets' regional companies group.

Reduced product development costs, gained through product component reusability, is another key benefit sought by insurers. “IT organizations are all facing budgetary pressures–to do more with less. Replicating code changes in different systems and keeping them in sync are all non-value-added activities. There is an opportunity to do product design and changes in a stand-alone application that can take out a lot of those routine and mundane activities,” Wildeman says.

Configurators also enable companies to test the impact of new products and changes to existing products without affecting production systems. “Simulating what changes would do in a test-and-learn environment improves the accuracy of changes that are made,” Schulenburg says.

A dedicated testing environment is one of the biggest benefits of product configurators, Harris-Ferrante claims. “You ensure when you do give a product to IT, the impact of that product is tested. Also, the testing process of most systems produces an XML data stream output that gives IT a much clearer picture of the changes that are being made. You also can leverage the testing environment for product analytics by running data from the warehouse against new products or changes to see what you do or don't want to sell,” she says.

CONSOLIDATION AND
CONFIGURATION

Liberty's product configurator rollout coincides with a legacy migration project, dubbed “ECLPS+” (Enhanced Commercial Lines Policy System), at the company involving the consolidation of four different platforms, including one obtained when the company acquired Safeco.

“We've had some of the same challenges of other companies–hard-coded rules, difficulties testing changes, and difficulties integrating new technology, such as agent interfaces, predictive models, and unique rule-managing systems. We're moving to bring ourselves into the future in one fell swoop, taking the best tracks of both projects to build a new and robust policy admin system and product development suite,” says Tom Troy, executive vice president and COO in Liberty Mutual Agency Markets' regional companies group.

Speed to market is a key objective in both projects. “From a product development standpoint, throughput is essential,” Troy says. “We want to take an excellent product idea and, when it's time to put it in the marketplace, to do so as quickly as possible.”

ICC incorporates a product developers' workbench that provides access to centralized product definitions and includes XML metadata and workflow for configuring products, underwriting rules, rating algorithms, and other development tasks. Liberty now is in the process of integrating the configurator tool with its CGI Ratabase rating engine and its Blaze Rules Engine for underwriting and pricing rules.

The ICC project will have an impact on the conversion effort as both projects move forward. “As we plan to take policy data off the four admin systems and convert it into one, we want to know the impact to agents and customers beforehand,” Schulenburg says. “We'll run those converted policies through the ICC application to make sure premium is in the range of what it should be.”

Consolidation and centralization also will help simplify what is a complex technology landscape at Liberty and make product logic accessible to users outside IT. For instance, to research the impact of a rating change in the current environment, business analysts have to obtain the rating logic from IT, request changes, and repeat the process through various iterations.

“Now, the business side has access to the rating logic within a modeling environment we didn't have before,” Schulenburg explains. “IT is just involved in the final rollout. We've taken multiple IT interactions in a typical change and reduced [them] to one.”

Liberty also expects the product configurator to enable a more seamless development environment. “A lot of companies have done a good job of system integration at the runtime level–when a quote is done or app is issued. However, we would like to integrate at the product development time,” Schulenburg says. “That will allow users to navigate to the products and rating logic they want to change from within a single system while that system also keeps track of versions and change activity.”

The system also enables users to test changes and to replicate accepted components into other products and markets. For instance, users can take a rating, coverage, or underwriting change made or proposed in one state or market and run that change against a book of business in another market to obtain a before-and-after impact analysis.

“We can run our current book of business against both the old and new logic to compare what is going to happen and determine how our agents and policyholders will be affected by a rate change or underwriting rule change. We can run changes against quote data to see how they impact the amount of business we are accepting or rejecting and how that affects our market position,” Troy says.

Although the ability to test proposed changes is an important capability of product configurations, testing is only part of the product development process. At some point, that fully tested product needs to meet the real world.

“There is always the point where you need to define your technical integration,” Wildeman says. “A configurator is a piece of technology–a repository or source of truth for product data–but that does not necessarily drive the entire life cycle. To achieve faster time to market, you need to integrate that catalog with those downstream systems. In many cases, that is easier said than done depending on maturity or the quality of your legacy applications.”

The ability to create a “manifest for deployment” is an essential feature of Liberty's product configurator solution, asserts Schulenburg. “ICC doesn't deploy code into production. However, a business user can determine the changes ready for release and deploy those to a staging environment for rollout into production.”

A robust change management process enabled by the two projects also will help Liberty prepare for additional acquisition opportunities, should they ever arise. “All we need in order to analyze the impact of any potential book transfer is to get data in XML format,” Schulenburg says.

Liberty will know, as well, exactly the information it needs from an acquisition candidate in order to do complete impact analyses. “We will have many more options and capabilities in our conversion strategy,” Troy says.

Wildman does caution companies should not underestimate the work involved with deploying a true configuration workbench. “The tough work of identifying your existing product data and getting that massaged into a central catalog can be very challenging. It can take longer than expected and take a specific skill set to accomplish. Companies should not underestimate–or under-budget–mapping activities of product configuration initiatives. There are migration tools out there, but at the end of the day, it takes a human process manager to make sense of the data,” he says.

Building its policy systems to incorporate IBM's IAA Insurance Framework has provided useful structure to Liberty's project, but there still is a lot of heavy lifting involved. “The biggest issue we had to start with is defining how we organized our logic,” notes Schulenburg. “Over the course of 30 years, we had built in a lot of logic in a lot of different areas. Now, we want to reorganize that into our structured environment. There's a lot of effort involved in defining message models, the hierarchy of products, the way we organize data, and so on.”

CONFIGURATORS AS
COMPONENTS

By the definition laid out thus far, configurators include a central product repository and a library of product templates that can include products from any policy admin system as well as workflow features that enable stakeholders in the product development process to collaborate.

Muddying the waters is, in addition to these stand-alone systems, there are product configurators provided as components in policy admin systems, designed to model only products administered on those platforms. Furthermore, most modern systems tout a “configurable” design that lets business users make many rules-based changes without involving IT.

“What makes [stand-alone] product configurators more powerful is you can do modeling and analysis of products administered on many different systems. You also can pull information from the data warehouse on any product in any system and run it through proposed product changes,” Harris-Ferrante says.

Those cross-platform analyses cannot be easily done from admin-level configurators. “Policy admin systems still are very lightweight for configuration by comparison,” she says.

However, even though they are not truly a cross-platform workbench, configurators as components of admin platforms do provide companies the ability to extract product information into a repository–albeit dedicated to that single system–that is separate from the process and application layers. This strategy may be advantageous and cost-effective for a company that has all products administered on one platform or that does not have a vast product library.

DTRIC Insurance Company is in the process of migrating its multisystem admin environment to DecisionMaker Policy Administration System from Decision Research Corp. (DRC). It completed installation of workers' compensation and personal umbrella in 2008 and recently added general liability. In advance of the migration of remaining lines of business, the company is utilizing a configurable rating engine to enhance the product development process, shorten time to market, and reduce reliance on IT.

“The rating engine is spreadsheet-based and structured very much like rate filings we already make and receive,” says Barney Wong, business analyst manager at DTRIC. “A lot of changes can be done outside programming now, which has helped us roll out changes faster. Also, the business becomes a bigger part of developing changes than before.”

The DRC engine enables DTRIC to replicate tested logic quickly from one product to another and to take changes in rating criteria and translate those changes into front-end modifications required for additional data capture. That not only has helped the company speed product development but also expand market capabilities. For instance, DTRIC recently set up a direct online quoting system for consumers on its Web site to complement its agency-facing capabilities.

“Without the DRC platform, we would have had to connect the online system to a rating engine that was embedded in the legacy system, which was not up to the latest technology and was not XML compliant. That would have been a big task. Having a rating service that is centralized, independent, and easily configurable allowed us to make that connection and bring new capabilities to market quickly,” Wong says.

BACK TO THE FUTURE

Despite the proliferation of the term configuration in today's technology market vernacular, it's unclear whether product configurators as traditionally defined will see more widespread adoption in the industry. Part of the reason is insurers struggle with their own product goals.

“Companies right now are examining their business and asking themselves critical questions,” Harris-Ferrante says. “Am I a product manufacturer or service provider? Do my customers want lots of products that are unique and tailored either through me or through affinity groups? Am I like Nike, with a lot of flavors of tennis shoes? What defines 'innovation' in insurance?”

If a company truly is looking for ways to customize products to individual customers at a much more granular level–to the point of creating a menu of coverages that can be assembled at the point of sale into a complex product–having a centralized catalog of detailed, well-defined, and tested components is essential. However, companies that are hedging their bets on the “service” side of insurance–becoming specialists in a set of predefined products that don't change frequently–may question whether the investment in stand-alone product configurators really is warranted.

“[Product configuration] often has been labeled as a cool product–nice to have, but you're still going to survive without it. You can throw resources at the product and get it done,” Harris-Ferrante says.

Also, configurators are just one part of the product development process. “It's more important you have a well-defined process of collaboration even if working with antiquated technology than it is to work with a new system and have ineffective internal collaboration,” Wildeman maintains. “No product configurator will address all your requirements. It won't define your product development business process, determine who owns various steps in the process, or make sure you have enough resources in the ideation phase so that ideas are scrutinized.”

In fact, the “ideation phase” may well be the most important part of the entire process. “Being in sync with the market is what enables a company to be more relevant and have greater market share,” Wildeman says.

In other words, technology supports but is no substitute for sound product development practices and business strategy. “There are companies that are making only incremental changes to products. There are other companies that see the industry at a turning point, and that changing regulations and a changing marketplace will have dramatic impact on consumer behaviors that require a fundamental rethinking of their insurance products,” Harris-Ferrante says. “The goal is to prepare for whatever way the pendulum swings.”

Special Reports /

Product Configurators Give Edge to Insurers

Related Stories

Recommended For You