The Journal of Insurance Operations

Transcription

1 The Journal of Insurance Operations THE DEFINITIVE RESOURCE FOR OPERATIONAL EXCELLENCE IN THE INSURANCE INDUSTRY Not Created Equal: Differences in Configuration Tool Functionality Impacts Insurers By Vivek Gujral On Twenty years ago, configurable systems came into the mainstream of enterprise software, but it was only a decade ago that this concept entered the everyday lexicon of the insurance industry. Today, it is a given that all modern core systems offer some degree of adaptability or configurability, and as Martha Stewart might say, that s a good thing. However, there are many ways the word configurable can be defined depending on where you are sitting within an insurance organization or within the industry at-large. Put simply, configurable means different things to different people, and to a few it s just a buzzword used on marketing materials to attract attention or get them included in the next big request for information (RFI). Configurable systems are definitely not created equal. So, for the purpose of setting a baseline, let s establish some common ground on definitions. For the most part, the industry can undoubtedly agree that when the word configurable is used to describe a system or a tool, the implication should be that for the vast majority of customer-specific requirements, no additional code should need to be written. To be clear, true configurability should not mean there is even light coding involved. Instead, the implementation should incorporate a design tool with which users can manipulate rich sets of pre-built functionality and capabilities to modify everything from the data model and workflow to every aspect of insurance product behavior. Put a different way, the code base across all of the components should be

2 nearly identical, which means regardless of how different customers markets, business models, products and processes may be, there is still no coding necessary. The insurance industry has come to expect the obvious functional areas rates, rules, forms and product definitions are modifiable, but to take full advantage of what true configurability can offer in terms of flexibility and reducing the total cost of ownership (TCO), a design tool that goes beyond just the definition of insurance products is needed. It must extend to all aspects of the insurance enterprise, including processes, organizational structure, and the insurer s ecosystem of suppliers, distribution channels, and customers. Asking the Right Questions In order to determine the true depth of a system s configurability, there are five important questions to ask the vendor in question, including: 1. Is there a common metadata and transactional data model across all functional components? 2. Are these models designed with all of the components in mind? 3. Can a complete representation of the definition of the company s products, rules and workflow be generated using the design tool? 4. Does it have pre-built, insurance product definitions, workflows for standard insurance processes, underwriting rules engine, roles and partners in the insurance process? 5. Can all of these be modified rapidly, without using coding? The answers to these questions can determine whether the vendor makes your short list, and the vendor s ability to realistically deliver these capabilities is tied to how products and workflow are implemented. If they are executed using metadata, then the product definition of products and workflow can be displayed easily, if they are carried out in code, they are not. A corollary of this is impact analysis the vendor should be able to seamlessly demonstrate the impact of changing any aspect of the system. The Power of a Configurable System If you think of configuration in terms of business benefits, then your organization can expect to gain the ability to empower agents and system users, as well as increase the speed of doing business and reduce costs. These results are critical to your business success in today s marketplace. With this in mind, what if you could move beyond core capabilities and subsequently uncover a whole host of cost-effective changes that could be made quickly to improve operations, profitability and reduce costs?

3 For insurers looking to be more nimble and achieve greater speed to market, having a truly configurable system that allows them to manage change across both products and process independently is essential. True configurability can reduce TCO by eliminating expensive professional services during and after the implementation, and by enabling internal users to bring new products to market faster and without involving in-demand IT resources. When insurers move to configurability beyond product, operational efficiencies that were not possible before can be identified more easily, as evidenced in the examples below: With a configurable workflow and business partner management, reinsurers can be brought into the process much earlier, and can collaborate with an insurer s underwriters to construct policies requiring facultative reinsurance. With configurable asynchronous processing, insurers can construct bespoke processes to solicit business from lost prospects early enough in the renewal season that the chances of getting the business are improved dramatically. With configurable presentation, insurers can technology-enable MGA partners to put up program business websites aimed at particular markets. The Advantages of Configuration over Coding A configurable system involves the vendor setting up a meta-model, i.e. something that describes all possible and reasonable behaviors, and making this available for manipulation via tables of metadata. The programmer, or perhaps more accurately the configure, then manipulates values in these tables, to bring about the desired application behavior. This sort of extended forethought and analysis brings about many direct, as well as consequential, advantages over writing code. Most often, these tables are stored as either relational tables or XML of some sort. By itself, this leads to complete transparency about the behavior of the system. In fact, it is possible with some work, to regenerate the requirements against which the system was built by manipulating the model. As a consequence, change management becomes straightforward. By contrast, for change impact analysis, a coded system needs to be inspected by the person who knows the syntax of the code, and it is unusual for business analysts to have such knowledge unless additional training has been conducted at the insurer s expense. A benefit related to transparency is that of self-documentation, because all instructions provided by the business analysts are in tables, and because any self-respecting metadata authoring system tags changes made by development ticket, it is trivial to examine what was done in a particular ticket. Usually, design-patterns are built right into the meta-model. For instance, when building a configurable work-

4 allocation system, one would expect to find both load-balanced and round-robin allocations. This means the insurer in question can make one simple choice and have the system behave in the desired fashion. The learning curve for configurable systems is usually slight as compared to the steep curve inherent to non-configurable or moderately configurable systems. The lesser degree of this learning curve is due largely to the fact that in truly configurable systems, problem and solution domains are clearly defined and documented. If the system in question happens to come even partially pre-populated, a lot of work can be done by simply cutting and pasting metadata. This also allows lower-cost resources to be used, particularly for tightly-scoped areas such as rate maintenance and user interface (UI) design. Coding on the other hand, requires developers to learn the domain, learn an often unfamiliar and bespoke language, and then come up with code from scratch. Release management and parallel development also become substantially easier with a configurable, metadata-driven system. Since all changes involve tagged create/update/delete operations on data, there are a variety of well-tested methods and technologies available for creating deployment scripts that both apply these changes to target environments, and roll them back. Additionally, this makes dependency management, conflict resolution and metadata merging a lot easier than if the changes actually needed to be made to lines of source code. Finally, since tagged metadata comprises the bulk of the business logic, it is easy to tag the source of metadata, whether it is the vendor, ISO or the insurer. This makes upgrades and maintenance much easier, since the metadata from different sources can be kept clearly segregated, and one cannot inadvertently override changes that are specific to the insurer. Configuration Scope The reason rates, rules and forms, those functions that fall under the category of product definition, became the de facto area that most vendors focused on making configurable is because insurance products change more most frequently and drive revenue for an insurer. For a real world example, just think about how often modifications may need to be made to personal auto rates or rules and you have at least part of this answer. In addition, this is also the area that business owners crave control over, so they do not have to rely on IT to make every single system change. Making Product Definition Configurable By taking a closer look at traditional, core product definition aspects, insurers can see what should be configurable and extractable from a configuration. Further, knowing what functions under the product

5 definition umbrella should be configurable gives insurers a baseline from which to begin a conversation with a potential vendor offering a system that is supposedly truly configurable. Coverage Definition Capturing and validating the list of coverages and their associated attributes is the bedrock on which product definition is built. The vendor offering a truly configurable system should be able to provide a baseline document for the lines of business supported. Inputs for this activity are the underwriting and rating manuals for the client products, as well as the standards on which these are based, such as Insurance Services Office (ISO), American Association of Insurance Services (AAIS) and the National Council on Compensation Insurance (NCCI). The output of this step should be a document that explicitly describes the insurer s insurance product, the coverages offered, the insurable assets covered and the specific attributes that are required for describing the asset, for both underwriting and rating. Underwriting Definition The underwriting definition describes rules that govern the appetite of the product for risk. There are several types of underwriting rules that should be defined, including eligibility, referral, coverage exclusion, and subjectivities. Sources of these rules are typically the underwriting guides associated with the product. The output of this step is a document that lists out the various rules, the coverages (if any) with which they are associated, and the usage (eligibility, referral, etc.) of the rule in question. Rating Definition The next aspect of product definition is price. The rating algorithm needs to be specified for each specific coverage offered by the insurer. This may entail starting with a baseline rating algorithm from ISO, AAIS, or NCCI, and describing the differences. Inputs for this activity are the rating manuals for the insurer s products, as well as the standards on which these are based (e.g., ISO). The output of this step should be a document that explicitly describes the insurer s rating algorithm and rates. Transactional/Process Rules The processes involved in the sale and servicing of insurance products involve many rules and regulations. For most insurers, these rules and regulations are documented and stored in a siloed,

6 convoluted situation. For instance, some rules and regulations are typically well-documented, while others are stored in the legacy policy management system, and yet another set is built directly into the process. The lack of a centralized master repository of rules means that an effort must be made to document and capture these rules. The output of this exercise is a set of documented rules, as well as details on where in the insurance process they need to be used. Forms Definition The final step of product definition in nearly every insurance transaction involves the generation of worksheets, applications and other policy contract forms that are eventually provided to the insured and agent or broker. The main effort in this step is to create an inventory of all the forms required for the insurance product being provided. Inputs for this effort include product rating and underwriting guides, state form lists, specifications of existing policy form processing systems and state form filings organized on a product-by-product basis. Beyond Core Configuration As discussed earlier, in order to succeed, insurers must evolve not merely their products, but also their processes, organizational structure, ecosystem of suppliers, mix of distribution channels, target customer segments, and more. Therefore, to provide unfettered, unlimited scope, the design tool should also allow configuration of the above areas and more, such as object model, partner and customer management, security, workflow management, UI and integration. This results in not merely increased revenues, but operational efficiency gains as well. Object Model The single most critical aspect of configuration, above and beyond product, is the ability to modify the object model. This is essential if one is to use the same design and implementation patterns that are used in the product, but extend them to areas not provided by the vendor. For instance, if an insurer wishes to start insuring luggage carriers and their contents as part of an auto product, the ability to add an object to describe, underwrite and price luggage carriers and contents is needed. Further, the insurer will want to do it in a way no different than the vendor would have if this feature had been included out-of-the-box

7 Partner & Role Management & Integration While every insurer performs similar activities, the internal workings of the organizations vary quite substantially, particularly based on the products being sold, as well as the size of their target customers. Additionally, some of these activities may be carried out by individuals who are employees, and others may be outsourced. To further complicate matters, this mix may also change with time, and may not be consistent across all products and markets. Given all this, the ability to configure business partners and roles within these partners, and the ability to expose activities to these partners and roles selectively is essential to fulfilling the process needs of insurers. Providing access to all participants in the insurance process via robust portals results in vast improvements in both productivity and service. Some examples of these portals include: MGA/Broker/Agent Portals which provide roles, authority, workflow, hierarchy, commissions, licenses, and agreements; Customer Portals which are used mainly to make changes, modify workflows, accept payments, originate new business, and via which content can be varied based on customer type, workflow, payments or UI; Reinsurer Portals designed to enable reinsurers particularly for facultative arrangements to examine and price opportunities in the insurer s book or pipeline; and Loss Control and Inspection Portals which enable internal staff or subcontractors to update risk information. Workflow & Process Management Workflows are typically recognized as a combination of many related processes that contribute to the completion of a central task, therefore it stands to reason that workflow and process management go hand in hand. That said, a configuration tool gives insurers the ability to wire up micro and macro workflows thereby linking actions together like pages in the application, system components or call outs to third-party systems. Process automation and management, coupled with the ability to configure an insurer s workflows, can help allocate and adjust tasks across staff to maximize throughput, and maintain service levels. This allows for limitless possibilities for how an insurer transacts business, as well as the ability to automate or partially automate an increasing number of hitherto manual tasks.

8 Presentation Layer Being able to configure the presentation of the application based on user role, business partner type, product, or program allows the insurer to present different faces to the world. By whitelabeling a solution for partner program managers, resellers and channels in this way, insurers can add specificity to products all while adhering to branding policies. Providing configurability at this level means insurers can make changes to the areas above very cost-effectively and quickly, while taking advantage of the configuration approach arosss a wide set of problems in the insurance enterprise. Taking the Risk Out of Configuration-Based Implementations After thoughtful consideration of what complete configurability can mean to the organization, it is equally important to include safeguards for the implementation and long-term maintenance of such a system. Since the possibilities can be limitless, a strong technology and design governance is important. And, while the power to make changes with benefits across the enterprise is crucial, insurers can decide whether a decentralized or centralized maintenance team is the best approach. You can reduce risks when implementing a configurable, metadata-based system based on its: Extensive pre-existing content, which speeds up implementations and lowers costs; High re-usability of metadata for sharing across products, territories and distribution channels; Ability to easily perform an impact analysis of changes to the modifications and the downstream effects; and Robust and comprehensive release management tools for managing the metadata of the system across all environments. Core System Checklist for Evaluating a Configurable System To avoid getting stuck with a system that does not offer true configurability, cannot be upgraded easily and will be expensive and difficult to maintain, you should consider the following checklist. Are the components metadata-driven and leveraging the same transactional data model? Does the system allow for a user to control the data models, workflows, rules, screen, and product lifecycle via a pre-built tool? Can you add new objects to the database directly? Eliminating the so-called walls allows you to maximize key areas of functionality and provides self-sufficient extensibility. Does the system require database administration (DBA) support to make changes?

9 Does the tool include sophisticated release and data management tools to reduce the risk of making unwanted changes or having unexpected impacts? Is there a tool-based, as opposed to a process-based, solution to deal with release management and dependency issues? Benefits of a Highly Configurable System As you might imagine, the more extensive the pre-built tools are the more it extends the ability to maintain and control the system throughout departments in an organization. For example, it provides the business areas with the ability to maintain product areas of the system directly, administrators control over the security features, and the IT group control over complex functions and integrations. This means that a broader group of staff within the insurer s organization can take advantage of having control over areas of the system. Other benefits include the fact that there are no limits as to how the system can be extended. It does not require the costly investments of time, money and effort associated with coding, which can lead to substantial implementation and long-term maintenance costs. Quite obviously, insurers stand to gain significantly with regards to improving service levels, cost controls, operational savings, streamlining enterprise business processes and achieving a more customer-centric view when a configurable system is leveraged to its full potential. Further, a configurable system allows for a faster implementation and greater responsiveness to customers and agents right out of the gate. This is especially true when the system offers repeatable configuration for adding new coverages to a product, modifying underwriting rules or lines of authority. In terms of competitive advantage, the benefit of having a flexible architecture also cannot be overlooked. The flexibility provided through a configurable system allows insurers to make rapid changes to meet customer needs, as opposed to insurers without such capabilities and who are still relying on timeconsuming manual processes that must be maintained by a third-party vendor or IT staff. This means at any given time an insurer utilizing a truly configurable system has more employees focused on largerscale initiatives and core competencies as opposed to configuring aspects of a supposedly configurable system. True configuration can bring value to the entire enterprise, putting the experts in control of their respective areas. Insurers can have real competitive advantage from the flexibility, speed and cost savings of a system that does not inhibit the business goals. Further, giving the business and operations staff the power to modify the system rapidly at all levels allows unprecedented speed, precision in the market and operational efficiency.

10 Vivek Gujral is the CTO for OneShield, Inc. He can be reached for further comment via at