From November 2009 Resource

Effective Technology Management of Insurance Product Rules, Values, & Calculations

By Todd Haney, Product Manager, HP

"The insurance business is perhaps the purest example of an ‘information-based’ industry – that is, an industry whose sole activity consists of gathering, processing, and distributing information."

 Using technology to process information within the life insurance industry has a long history; indeed, our industry was one of the first to take advantage of computerization capabilities. The long and complex history of insurance products, and the respective technology systems required to support them, has resulted in one of our most important assets—product definitions—being spread throughout the organization. In addition, organizational changes and division of responsibilities for managing our technology systems have created many individual silos of responsibility.

Product-related technology functions include product rules, rates, and values. These functions are typically distributed throughout the enterprise to support presales illustrations and proposals, policy administration life cycle, in-force illustrations, premiums, cash values, reserves, and other processes. When a new product is introduced, the task of managing updates to the numerous technology projects and systems is extremely time consuming and complex. Lack of systems support and automation regarding product definitions has manifested itself as a set of complex manual processes. The complexity level is so high that a significant portion of project costs are dedicated to change control, rework, and testing.

Throughout the years, insurance organizations have tried different strategies to implement the required level of control and governance for the product implementation process. Historically, there has been a lack of technology available to support a centralized process, yet remain flexible enough to handle individual product requirements and the subsequent deployment to multiple technology systems. Introducing a new product will require, at a minimum, updates to presales illustration, administration, and valuation systems. There are a number of implications to this practice:

* Product rules and values are typically duplicated in multiple systems.

* Multiple technology systems are developed, usually in many different technologies.

* Extensive testing is required to ensure all systems provide consistent results.

There is significant duplication of effort and cost associated with developing product rules, values, and calculations within these multiple technology systems. The development, testing, and infrastructure requirements all result in significant duplication of costs and ineffective use of valuable resources.

We can see the scope of the issue when we realize that North American insurers alone spend approximately $300 million annually developing illustration solutions. The most significant cost and exposure is for change control and testing of the various systems. Ensuring that all systems reflect the latest product changes and have been sufficiently tested to ensure consistency is a hidden, but significant, cost.

One large North American insurer maintains two teams to track these activities. One team is responsible for product documentation. The other team is responsible for developing and deploying a master product system that can be used to test all other systems’ compliance to the product rules, values, and calculations.

Some insurers have developed product engines that are developed once and deployed internally as a centralized service. Although this is a sound strategy, it generally has not achieved the desired goals. In most cases, the internal product engines are developed using the same waterfall development and programming techniques as legacy technology systems. Having one application that contains and manages all products with hard-coded programming techniques inevitably produces a complex system that demands the most senior resources to maintain it. Organizational structures within the insurer can also lead to demands that can be difficult to attain with this technology.

Over the last 10 to 15 years, many vendors from the insurance industry have proposed various solutions to managing product definitions. Generic rule engine vendors have attempted to deliver insurance-specific content within their capabilities. This strategy has worked well within the claims processing and underwriting areas; however, it has not been as successful in handling the complex details, variations, and number crunching required for policy rules and values.

In response to this shortfall, the concept of "product configurators" has emerged over the past 10 years. There are a number of solutions on the market today that enable the insurer to configure a product that results in automatically generated programming code that can be deployed and connected to multiple technology systems.

Although these solutions do have certain advantages, they also can have shortcomings. The ability to deploy a single program that is connected to multiple systems can save significant development time, reduce testing, and help ensure consistency; however, in practice there are a number of things to watch out for. As an example, product configurators are generally not extensible, and therefore require amendment by the vendor for any new product features. The requirement to wait for vendor development cycles implies that an insurer may be delayed in bringing product features to market and increases the risk that the requirements will be lost in translation between the business requirements and the technical implementation.

If we review the insurers that have successfully implemented a product engine, we would see that the solution will typically have the following attributes:

* Enable the actuaries to define product rules, calculations, and values independently of technology

* Enable technology to rapidly deploy the products defined by the actuaries

* Enable a managed process that ensures quality through testing

* Reuse product by connecting to multiple systems (illustrations, administration, reserves)

* Reuse previously completed and test product components (features) to create new products

* Create a single repository for collaborative development

These capabilities can result in a reduction to overall product implementation time by greater than 50 percent. Let’s review each capability in greater detail.

* Actuaries normally write product specifications that contain all of the rules, values, and calculations associated with a new product launch. This may be a completely new product to the organization or simply a market enhancement to an existing product. A modeling capability that provides the actuary with the ability to directly define and test all of the product rules, values, and calculations would eliminate the need to write the specifications for technology. Product documentation can be directly generated from the data entered by the actuary.

* Actuaries typically use different terminology than technology personnel. It is critical that any solution contains the capability to map the actuarial model onto the technology model—in other words, to permit the technology personnel to use the actuarial model within technology systems without change, but in the terminology they are used to.

* Because products are constructed from smaller components, it is critical to enable both technology and actuaries to test the individual components and final product. Once developed, test cases are stored with the completed product so they can be reused when changes are made to the product. Subsequent testing time is reduced while ensuring that test coverage is complete.

* Reusing the product within multiple technology systems eliminates the development of multiple solutions. This ensures consistent implementation of the product results.

* The storage of the previously defined and tested product components reduces the development time for a new product. Many attributes of a new product are similar to or reuse previous products.

* A shared repository for all product artifacts provides for a team-based approach while ensuring a high level of governance.

How can these goals be attained with today’s solutions? The concept played out in the late 1990’s with the advent of 4th GL modeling tools. These tools permitted the user to define systems design information in a graphical toolkit that would eventually generate code to be compiled into the system; however, these technologies had many constraints and faded from view. The toolkits had inherent limitations, so the programmers had to make changes to the generated logic. At this point, the toolkit can no longer generate the code because the metadata in the model no longer represents the physical implementation.

Model-driven development is a methodology for using graphical editors to define products in a syntax that is familiar to insurance companies. The resulting models are deployed directly to systems environment in an executable format. The significant advantage to today’s model-driven development tools is the complete separation of the business definition of products from the technical implementation of the systems that support those products. This enables the business to define and control their rules with minimal dependency on what technology has been selected.

ProductXpress from HP is a product modeling design environment that supports insurers in defining and testing all of the rules, values, and calculations associated with an insurance product. The model is separate from the software and provides for automatic upgrades. ProductXpress Designer has many deep capabilities to manage the life cycle of a product, including initial product design, testing, change control, subsequent modification, and deployment. Products are deployed in the form of XML documents that are used by a scalable runtime calculator. The documents are encrypted to protect the insurer’s intellectual property. Product attributes are stored in a shared repository to facilitate team-based collaboration and governance.

ProductXpress Designer is used by many insurers to help improve the product implementation process within technology and actuarial. The capabilities of the design and runtime environments eliminate traditional programming and waterfall development practices. The iterative design, with process support and embedded change control, reduce the time to market—moving technology off of the critical project path.

For information, visit:
www.hp.com/enterprise/insurance

Contact Resource at resource@loma.org