Getting It Straight

The benefits of straight-through processing in policyadministration systems include greater efficiencies and lowercosts. Implementing it, however, presents some challenges. Here are12 best practices to help ensure success.

P&C carriers facing challenges to profitability recognizethat cutting costs and streamlining operations and technology areessential steps for succeeding in today's insurance marketplace. Akey area of focus is policy sales and administration, wheremultiple systems and "silos" typically provide limited connectivityand require time-consuming manual intervention.

The most important–and perhaps most challenging–task intended tolower costs and increase consistency of operations isimplementation of new rules-based policy administrationtechnologies that leverage straight-through processing (STP).

By automating key sales and underwriting functions fortransactions such as new business, policy changes, re-newals,reinstatements, and cancellations, STP can help P&C carrierscut operating costs from 40 percent to 65 percent and issuance timeto a day or less. Unfortunately, the available vendor offerings donot meet the needs of many insurers because they are insufficientlyscalable or are architected with older technologies. As with mostbig challenges, there are no quick-fix solutions. Furthermore, manylarge-scale programs exceed budget and schedule and fail to deliverthe value expected.

Here are a dozen best practices that could help yourorganization embark on a successful program to implement a newpolicy sales and administration system:

1. Start by creating the definitions. The first step is todefine the business vision, objectives, and future operating modelof your policy administration and underwriting operations. Keyattributes should include:

o Levels of centralization as well as decentralization.

o Product and process similarities across lines of business andproducts.

o How customized vs. commoditized the insurance products willbe.

o Levels of specialization as opposed to generalization.

o Levels of procedural vs. analytical work being handled.

o Levels of subjectivity vs. objectivity in underwritingdecision-making.

o Frequency of product and rule changes.

These definitions must be confirmed and well communicatedthroughout your organization.

2. Build the road map. Next prepare a road map to the future.Each incremental enhancement/change must be defined in the contextof a longer-range, end-state operating vision. Without thislong-term approach, initiatives could fail to achieve theirindividual objectives while reinforcing a "siloed" operation.

3. Create new roles and business processes. The organizationrisks "paving the cow path" if the focus is merely on automatingthe current manual processes. Therefore, new roles and businessprocesses should be formally developed and rolled out together withnew systems and handled as related projects with "deliverables"that are developed and tested along with the system beforeimplementation. Also, evaluate your existing operational businessmeasures, and update them to reflect the impact of the new system.For example, financial and other performance incentives for agentsshould be designed to accelerate adoption and reinforce behaviorthat is consistent with your new operational goals.

4. Recognize there may be a perceived loss of centralizedcontrol. Traditional policy administration pro-cesses retain allthe control within the centralized P&C operational andunderwriting departments. For some organizations, implementing anSTP solution may require culturally shifting to a "Trust the Agent"approach. For example, collection and retention of photos,authority for discount eligibility and waivers, andreplacement-cost input are all activities for which responsibilitywill shift to the agent under the STP model. Following a "Trust butVerify" approach is most effective, balancing more agent autonomyon the front end with additional audits after the fact.

5. Develop accurate requirements. The temptation is to rely onanalysis of the existing legacy systems to document and understandrequirements for the new policy administration application.However, the challenge of reverse engineering what are often20-plus-year-old batch systems written in older 2GL or 3GLlanguages is huge. Also challenging are the variety and complexityof P&C requirements for multistate, multiproduct policyadministration systems. Often, the best source for developing thenew requirements is the existing manuals governing policy writing,underwriting operations, and training. Given the regulated natureof the insurance industry, most carriers are diligent in keepingthese manuals up to date.

6. Carefully plan and execute a business mobilization program. Astrong focus on training, communication, and organizationalreadiness will be paramount before and during the systemdeployment. Many organizations spend less than two percent of theiroverall program investment on these key activities. In someinstances, new users will blame a well-functioning system for whatin reality is a lack of training, communication, and effectivedeployment. Identifying a business management group to drive thepiloting and rollout of new processes is essential.

7. Employ a block development and implementation strategy. Withthis approach, the overall program is broken down into developmentblocks. Each block comprises a set of functional requirements andcapabilities that have an affinity and can be developed, tested,and demonstrated as an integrated whole to the business sponsors.As testing progresses through each block, a natural regressiontrial of the previously developed blocks takes place. A strongrationale for this approach is it can generate an early benefitsstream for the organization and provide the potential to make theentire program self-funding. In this regard, a particularlyeffective strategy is to build first the new business applicationthat populates the new policy administration database and feeds thelegacy administration system.

8. Utilize frameworks to accelerate the overall developmenteffort. Functional frameworks can be used to accelerate thedefinition of scope, requirements analysis, and design as well asto develop the overall application architecture of the new policyadministration application. Likewise, technical frameworks canprovide a tested and scalable technology architecture designedspecifically to support the needs of a policy administrationsolution.

9. Analyze the user experience early in the program. One of themost challenging aspects of developing a new STP policyadministration application is the expansion of users, includingagents and other channel partners, who now will have access to areal-time application. It is critical to understand their needs andto define key visual concepts and style requirements well beforethe application design and construction phases begin. Given currentlegacy system constraints, there may be a radical change to theirwork environment. User input and involvement early on is criticalto a successful rollout.

10. Plan the overall integration strategy. Policy administrationis a core application. As such, it feeds, and is fed by, many otherapplications. Given the scale of these programs, it is essential toinsulate other legacy systems from significant impacts as a resultof the new application. One of the most significant challenges inthis area is the lack of existing system documentation. Often,legacy applications are batch-oriented. Significant time should begiven to batch-flow analysis and to understanding the entire daily,weekly, monthly, quarterly, and annual batch cycles. Also, a keygoal should be to minimize the impact to legacy systems that arenot being replaced. They must be able to operate in the future asthey do today. However, each legacy interface should be built withthe flexibility to move to a common interface in the future.

11. Avoid the "Tail Wagging the Dog" syndrome. Legacy systemlimitations can constrain potential capabilities of the new policyadministration system. Therefore, the program carefully mustevaluate trade-off decisions that could compromise long-termbenefits.

12. Develop a smart policy conversion strategy. Smoothlyconverting existing policy information to the new policyadministration system is critical. Typically, the new policyadministration application logic works fine for households andpolicies created using the new application. However, it can failwhen exposed to policy information already on the books. Forexample, the existing database likely contains active policies forproducts that are no longer sold by the company but that continueto be renewed. This circumstance can cause such policies to bemarked for nonrenewal by the new application. Another key decisionconcerns the rules for when a policy is eligible for conversion.Often the preference is to allow policies to convert at renewaltime. While this is an opportune moment to move policies to the newapplication, it can drag out the conversion of an agent's book ofbusiness over an entire year, depending on policy term lengths. Apreferable approach is to convert all policies in an agent's bookover the course of a single weekend to allow him or her to moveswiftly and entirely to the new application. This approach alsosupports a more controllable geographic deployment strategy.

Unquestionably, there are significant challenges to implementingnew rules-based policy administration technologies. However, thecost-saving benefits of systems that leverage straight-throughprocessing are enormous. By employing these best practices,insurers can greatly enhance the design, development, andimplementation process and more quickly and cost-effectivelyenhance their operational efficiency, marketplace competitiveness,and business profitability.

William S. Fournell, a vice president in Capgemini's FinancialServices Consulting Practice in North America, has more than 21years' experience serving a wide range of financial institutions,including some of the nation's leading insurance companies. He canbe reached at [email protected].

The content of Inside Track is the responsibility of eachcolumn's author. The views and opinions are those of the author anddo not necessarily represent those of Tech Decisions.