The Customer-Centric Insurance Company: Who is the Customer?

When we talk about Insurance companies moving to a “Customer-Centric” model, we often initiate a dialog around the topic: “Who is the Customer?”.

The point was driven home for me a few years ago in a conversation with my friend and industry veteran Bill Jenkins, co-founder of Agile Insurance Analytics and a former CIO of several insurance companies. Bill mentioned that for many insurance carriers who write business through Independent Agents, they are the Customer versus the Policyholder and the entire business revolves around making it easy for Independent Agents to do business with the carrier. In these insurance carriers, if you talk to any executive in the C-Suite and ask “Who is the Customer”, you’ll get a unanimous answer, “the Independent Agent.”

When we talk about Customer-Centric, however, we encourage a definition of “Customer” that is not absolutely literal. In fact, we recommend looking at any person who “touches” your business, internal or external, and to view them as if they were a Customer. That means expanding the definition of Customer to include, for instance: Independent Agents, Brokers, Producers, Claims Adjustors, Third-party Administrators, Appraisers, Customer Service Representatives, Underwriters, etc. At Return on Intelligence we use the term, Actors, for this expanded list of Customers. Actors is not a perfect term, but it helps to broaden the thinking beyond the traditional notion of Customer.

When businesses expand their definition of Customer, creating this broad list of Actors for their business, the discussion starts to move towards a) what is their expectation and experience of your business, b) how do you measure this, and c) how do you improve their experience over time. Leading edge technologies facilitate the interactions with these multiple Actors, and the result is that everyone who interacts with your business feels a level of personalization and operational efficiency, and over time their perception of your business as Customer-focused, increases. This leads to increased business, longer retention and lower acquisition costs. And that is why “the Customer-Centric Insurance Company” is just “good business”.

Print Friendly, PDF & Email
Tweet about this on TwitterShare on LinkedInShare on Google+Share on TumblrEmail this to someone

The Customer-Centric Insurance Company: Rip & Replace?

Every insurance company has existing technologies that support the business functions of today, such as distribution, customer acquisition and servicing. These technologies may include websites, portals, mobile applications and web-based business applications. When moving towards a Customer-centric model, is it necessary to “rip & replace” existing technology, or is there an alternative approach to implement a solution?

In the majority of cases that we see, we strive to leverage existing infrastructure and to “surround” the existing technology with a platform, and incrementally migrate or retire systems and technologies that don’t fit into the “go forward” technology roadmap. Why? Because our objective is to minimize the disruption to the business, leverage existing technology expenditures, provide a clear migration path to a new Customer-centric architecture while minimizing implementation risk. Platforms are more flexible than custom development or specialized portal solutions because they provide the depth and breadth of functionality to execute a migration to a new Customer-centric environment without demanding that an insurance company “rip & replace” their existing investment.

Print Friendly, PDF & Email
Tweet about this on TwitterShare on LinkedInShare on Google+Share on TumblrEmail this to someone

The Customer-Centric Insurance Company: Build versus Buy

As more and more insurance companies move from a Product-centric to a Customer-centric strategic focus, we’re often asked, is it better to build, i.e. custom develop front office solutions, or should the company buy, i.e. purchase a best of breed platform.

We typically recommend buying a best of breed platform because we see the benefits first hand: solutions tend to be more robust, can be deployed faster, are easier to maintain and scale.

Conversely, we have seen many insurance companies who develop their own applications end up with IT nightmares: data is inconsistent across applications, portals and point solution proliferate and the user experience suffers, IT cannot keep up with the demands of the business users and maintenance costs explode.

In our view, the choice is simple: for leading edge Customer-centric solutions, the choice is to Buy, not Build.

Print Friendly, PDF & Email
Tweet about this on TwitterShare on LinkedInShare on Google+Share on TumblrEmail this to someone

14 Insurance Industry Predictions

Insurance Networking News

Jonathan Kalman, President of Return on Intelligence’s Insurance Solutions Business Unit, offered the following predictions, takeaways and advice at the IASA 2014 Educational Conference and Business Show in Indianapolis last week.

  1. Customer centricity will be the dominant strategy among insurers, and new business processes will need to be designed, implemented and adapted.
  2. Customer expectations will grow exponentially higher, so design from the customer’s perspective and for flexibility.
  3. Risk management methods will shift from operational to financial and transactional, so you’ll need data at your fingertips.
  4. Market volatility will continue unabated, creating pressure on earnings and as well as investment opportunities, so insurers will be under a larger microscope.
  5. Fraudulent behavior will evolve and become more sophisticated, affecting all insurance products.
  6. The pace of industry consolidation and M&A will accelerate, so the ability to consolidate systems and processes quickly will need to become a core competency.
  7. Insurers will use analytics at the center of their business strategies, and those that do will outperform their competitors.
  8. Digital channels will dominate all customer acquisition and servicing.
  9. The window of enjoying enhanced margins on a given insurance product will shorten as new technology emerges.
  10. The pace of disintermediation will increase and accelerate (for example, Google is buying a consolidator) so technology and processes must improve.
  11. New entrants will be emboldened as barriers to entry drop, so watch non-traditional companies trying to come into your space.
  12. Niche markets will continue to offer specialized products – you must be able to compete with products not yet invented.
  13. The “Internet of Things” will open doors to new product offerings, so watch Silicon Valley’s investments carefully to stay ahead of risk management.
  14. Insurers will need top talent, so acquire what you can in an acquisition, and other familiar sources.

Read original article.

Print Friendly, PDF & Email
Tweet about this on TwitterShare on LinkedInShare on Google+Share on TumblrEmail this to someone

The Case for Feature Driven Development

Despite the best efforts of architects, engineers, planners and CIOs there continue to be an uncomfortably high rate of systems development flops and failures.  According to recent research by Oxford University and McKinsey 87% of IT projects with an investment of more than $15 million fail and 23% of IT projects run more than 80% over budget[1].

As recent data in the Insurance Industry from Forrester shows there is little consensus on what to do.  Of the respondents almost half have either no defined approach to systems development or are using waterfall, which was forward thinking in the 1970’s.  Encouragingly, half the industry is trying to control the scope of efforts, keep failures scope-boxed and time-boxed through some version of Agile or Iterative development. There are many versions of either.

Forrester bar chart

In the Insurance industry the challenge tends to be implementing a functionally rich “core systems” solution managing the relationship from policy issuance through claims; similar in scope to an LOS in mortgage or an ERP in manufacturing and distribution. In an attempt to be responsive and modern, nearly all of the insurance solution providers will state that their implementation methodology is based on Agile.  Some are more “pure” Agile than others.  Regardless of their orthodoxy the challenges can consist of the following:

  • Failure to recognize the business users commitment levels required for true agile development.  “Product Owner” means something critical.
  • Missing requirements due to not understanding the entire insurance value chain. An example is defining a unique, strategic distribution channel but not understanding the need and role of CRM in it.
  • Called what occurs with core systems “development” is a challenge. Clients are licensing commercially available solutions that have significant functionality. The task is configuring, feature selection, enhancing with add-ons.  It is not “green fields.”
  • Cost – These implementations are expensive.  It is not unusual for regional players to spend $6m to implement a claims module.  Mortgage originators spend similar amounts on POS and LOS solutions.  As a share of revenue or equity these are substantive efforts.
  • But, due to the perspectives of the teams doing the work and the lack of proper business participation the requirements are not aligned to business and projects all too often fail.

For these reasons we find it imperative to work from an Agile Feature-Driven Development “AFDD” Approach. Key elements include:

  • Stringent alignment of business processes to system requirements.

You need a process driven approach to requirements identification and prioritization.  Inherent to this are dynamic reusable business process models that drive the identification of services, appropriate flexibility and reusability, alignment with enterprise business process management systems, and the identification of tangible benefits and requirement prioritization

  • Focus on the features of the solution – the prioritize requirements are then assess to the base features of the solution.  Gap analysis and development dependencies are identified and estimated
  • Testing of features are driven by the business processes / requirements

We believe there to be 5 main phases of Feature Driven Development, the middle three are most classically “Agile” and the first and last phase are traditional in their structure. In our view, Feature Driven Development requires, it is based on, starting by clearly understanding the business requirements and features for the new solution. The process begins with requirements from a business perspective and develops an executable roadmap and governance for a successful implementation.  Whether your business direction is described in products and markets, Critical Success Factors, or Strategic Vectors and Do-Wells, that direction defines and informs things the business needs to have and do.  Those things drive the roadmap.  This is not an “Agile” process, it has a timeline of its own[2].

SAFe process

In Elaboration and Design those business requirements and feature definitions are extended and verified.  Missing business requirements and features, user experience descriptions, system integration and potential data conversion routines are discovered and documented. This phase takes a good idea and creates a definition of a “whole product.”  The scope of what must be done is clear enough from the Inception Planning that the Elaboration can be properly “sized” and structured. This is an iterative, “agile,” sprint-driven process, time boxed with “product owners” approving the work to be done and the results from each sprint.

Configuration and Construction involves a series of “traditional” Agile sprints, coordinated around the defined features, the “release train,” to deliver what is defined as the business objective.  Since the construction is Feature-based so is the Testing and Acceptance of the solution (feature or full solution) in a control and predictive environment.  This includes user acceptance test and performance test.  Once this phase is complete the system or feature of the system is ready for deployment.

This is an “agile” approach.  It expects that the initial design may mature during the development process.  It also expects that despite best efforts of all parties some of what is built is different from the intended design.  For these reasons we recommend conducting a product pilot test in a control production environment.  During this test resources are assembled to quickly resolve and business or technical issue raised during the pilot period.  Once this has been completed the system is ready for deployment.

For Core Systems efforts we favor Feature Driven Development because it minimizes unconstructive “green fields” thinking in a known space while maximizes the inventive, iterative, differentiation of deployed feature/function that Agile emphasizes. The resulting implementations are more focused on delivering solution features that are aligned to business concepts rather that counting the number of story points that have been delivered. Business people can better understand the project status and can react accordingly.

Jim Anderson
james.anderson@returnonintelligence.com
(610) 247-8092


[1] The Art of Project Portfolio Management by Meskendahl, Jonas, Kock, and Gemunden

[2] There are methods, like Dean Leffingwell’s SAFe, which attempt to use Kanban methods to add Agility in this phase as well

Print Friendly, PDF & Email
Tweet about this on TwitterShare on LinkedInShare on Google+Share on TumblrEmail this to someone

Experience and Best Practices – Keys To Software Implementability

Implementing software into a complex insurance carrier environment can be risky and fraught with impediments that increase cost and timelines. Return On Intelligence, having managed software implementations on a global basis, asked ourselves the question:  Are there any experiences or best practices that if employed can lower the risk of software implementation to ensure a rapid and cost effective implementation?

What we learned after looking at a wide sample of implementations suggests that a foundation for implementation success consists of experience in three categories:

  1. Insurance Knowledge. Broad and deep;
  2. Understanding the data. To be processed and its relationship to the business;
  3. Technical acumen.  Not just with the software product alone, but the conversion and interfaces required.

In addition to these three categories, we found that focusing on a number of best practices increases the chances of a successful core systems implementation project:

  1. Organizational Readiness. Assessing the readiness levels of all participating parties as they relate to planning and timeframes, as well as the required participation of the recipient department or departments;
  2. Governance. Managing overall governance of the software implementation and adherence to agreed priorities;
  3. Accelerators. The proper choice and use of any “implementation accelerators” such as data conversion or testing tools.

Our conclusion is that when undertaking a core systems transformation, the focus on experience and best practices should be required considerations, and may in fact contribute to avoiding protracted and costly software implementations that endanger the progress of the carrier’s strategy at the least, and its profitability at the most.

Jim Janavich

 

 

Print Friendly, PDF & Email
Tweet about this on TwitterShare on LinkedInShare on Google+Share on TumblrEmail this to someone

Telematics Data – Changing The Insurance Underwriting and Actuarial Environment

Telematics and specifically the usage based data it generates, significantly improves the ability to rate and price automobile insurance, by adding a deeper level of granularity to the data commonly used today.

Companies in the forefront of using telematics data, are beginning to understand the value of its many indicators as they relate to policyholder driving behavior, and how that behavior positive or negative, directly affects overall policy administration cost.

This advantage though, also comes with a possible disadvantage – higher volumes of data being added to already burdened processing resources. A single vehicle generates approximately 2.6 MB of data per week.  If 50,000 auto policies are on the books, accumulating that data for a year results in 6.8 TB per year.

Pay How You Drive Data

Given that the use of telematics data from automobiles is on the rise in insurance companies, to be followed by telematics data generated from wireless sensors in personal and commercial use; a solution for processing huge volumes of data quickly is indicated.

Most likely that solution is SAP/HANA based, processes the data and analytics together in main-memory, provides underwriters and actuaries a technological advantage to their business – real-time rating and pricing, a solution that doesn’t exist with traditional methods.

Jim Janavich

Print Friendly, PDF & Email
Tweet about this on TwitterShare on LinkedInShare on Google+Share on TumblrEmail this to someone