New Challenges require a New Mindset for Insurance

New Challenges require a New Mindset for Insurance
Celent conducted another successful Peer Networking Event (PNE), this time in Atlanta, Georgia. The event was well attended by insurers from around the area and even had representation from a bank. The PNEs are designed to bring together insurers to discuss topics that they find of interest, either due to immediate concerns or future direction. The structure of the forum allows for open and candid discussions between the participants.

The two topics that were discussed during this PNE were emerging technologies and the architecture concerns to incorporate and integrate these new technologies into the existing environment with which carriers must deal today. Celent provided its perspective and insight into these areas and the group engaged in a lot of interactive dialog. Carriers were interested in what others are doing with respect to telematics, customer sentiment and the use of external data. There was a growing concern expressed about how to deal with the large amounts of varying data and how to incorporate that information into the business decisioning process. For example, one carrier wanted to know if anyone had experience with data aggregators to help deal with the Big Data challenge that is beginning to hit the insurance industry.

Another concern expressed is how to maximize the user experience for policy holders, agents, and CSRs (Customer Service Representatives). The insurers said they face a challenge with their ability to integrate across their systems to provide the level of experience that users have come to expect with Google, Facebook and Amazon. They also discussed the significant advantages available to specialty insurers by leveraging more customer data to better underwrite risks.

There was a high value discussion regarding the need for IT to educate the business on the art of the possible. Regarding emerging technologies, IT needs to better understand the business and take a seat at the table to help drive the business and help them understand what is truly possible; what is still just a concept; and the true impact to the business of the emerging technologies that are so hot in the press.

Celent proposed that in the future insurance IT landscape, all that carriers will own is the architecture and the information. This generated good debate around the role of enterprise architect and the role of the business architect. Only three of the carriers in attendance have a formal, mature business architect practice. Others described their business architects as really business SMEs (subject matter experts). The insurers also observed that IT architects and insurers rarely talk about human capital. Carriers need to develop an IT human capital plan related to IT architecture skills. A central theme of the day was that the role of the insurance IT architect is definitely changing as we move forward.

One carrier presented their EA (Enterprise Architecture) journey. They have been moving away from business siloed architectures to a true enterprise architecture, responsible for the enterprise, not just a single line of business. They created an EA roadmap and established an EA governance group that was quite effective. The surprising aspect of their efforts was the speed (six months) in which they established and matured their EA governance group. Some of the key reasons for this are that the EA governance committee consists of senior executives from IT and business and all projects must go through a practical EA review. The governance process enhances the project deliverables and has not become a bottleneck for project delivery. Their focus is on their value proposition and how they can help drive their company to achieve the business goals.

In the afternoon, another carrier presented their system modernization efforts and the journey that they have come over the last couple of years. As with most carriers, they have a myriad of systems and had a lot of manual processes. They found it took longer than expected to get the first line of business up, but new lines now only take 5-9 months (reduced from 18 months previously). They have rationalized many of their systems and continue moving forward on improving the back end and introducing portals and improved customer experience on the front end. A key lesson learned was to fix underwriting first and then focus on the back end process systems, such as Claims and finance. Other lessons learned included:

o Need 100% commitment from the business

o Change/fix the process, not the system

o Define your requirements based on the new business process

o Decide what you want to do, then pick the tool (not vice versa)

o Define reqs up front before selecting an implementation partner

o Be realistic about data conversion time and effort

o Dedicate a Project Manager from underwriting full time

o Do not convert policy data! Convert policies at time of renewal.

o Allow projects to fail

o Define your requirements well before working with a vendor; otherwise, they cannot understand what you want

The PNE confirmed to all the carriers in the room that they are all struggling with variations of the same issues. It also confirmed that you cannot face these new challenges with the old Insurance mindset or culture and provided practical steps that have been taken to make the needed transitions.

The next PNE is scheduled for October 26, at RSA Canada in Toronto. The two topics for discussion will be Insurance innovation and Big Data in insurance. The event is open to all carriers. Check the Celent site ( soon for event and registration details. Based on the last several PNEs, you won’t want to miss it!

The art of The "Big Picture"

The art of The "Big Picture"
Getting a good Big Picture up front is one of the keys to the success of any project involving new or significant change to Information Systems. The Big Picture comes in two parts: The picture itself and the story that goes with it. First there is the picture, the document that we would call The Big Picture. This document need not be a rigorous diagram, although for those familiar with the Unified Modelling Language, the UML context diagram would be a good start. For those familiar with TOGAF, this would be the Architecture Vision document summarised into a single picture or diagram. The principal systems should be present and should be described in business terms. Where the system is customer facing the key channels to market should be represented and the key points of interaction between humans (staff, customers) and the systems should always be present. Each stakeholders interests should be represented – so, if a key stakeholder looks after a call centre – make sure the call centre is represented. If a key stakeholder is responsible for leads sourced via email – have this in the diagram. Communication between items on the diagram should be represented and some short narrative should be given where the purpose of a system or communication isn’t immediately obvious. If possible any phasing or early deliverables should be highlighted. This probably provides 60% of the value of the Big Picture. The other 40% is derived from the story line surrounding the document. The document is intended as a mnemonic and a tool to drive conversation. It is the conversation around the picture that fills in the gaps. So the Big Picture says “I have covered all the angles,” “Your specific concerns are addressed and you can see them here, here and here” (for each stakeholder) and finally, “here’s the names of everything involved and how they fit together.” The surrounding storyline needs to fill in the gaps. The storyline comes from enterprise architect and needs to describe how it will all work when we’re done, how the solution will address all the stakeholder concerns, how the general case will be addressed in this model and finally how exceptions will be handled. This conversation comes from the discussion of the big picture with key stakeholders and weaves the storyline to their particular concerns. It is typically much harder to capture the conversation in a document. It is formed in the mind of the enterprise architect as they capture the requirements, examine the existing systems and draw on personal experience to build the big picture document. Frequently, they challenge themselves with exception cases to test their model but never get exactly the exception case queried during a presentation. As a result many of the story lines around exception cases are answered on the fly – with a good knowledge of the domain and a good Big Picture this should be relatively easy for the enterprise architect. So the Big Picture is a document which acts as a mnemonic and provides comfort to stakeholders that they are being cared for. The Big Picture is also the storyline that accompanies the document, that sells the concept and brings to life what it means for the stakeholders. Finally a good Big Picture acts as a flag for a project, a reference point to follow. Do you have a project that has no clear end game, no commonly held vision? Or for which your key stakeholders are worried that their particular concerns are not being addressed? Perhaps something as simple as an A0 diagram capturing the salient points of the project for each stakeholder would give all participants the boost in confidence and direction they need.