Insurance Systems Architecture

This post starts a longer series looking at the key systems components normally present within a life insurance organisation. Subsequent posts will look in more detail at each component.

The systems components have been split into Core (systems that run the main operations of the business), and Infrastructure (not always discrete systems but underpin the operations).

Core
Policy Administration – responsible for capturing new business, recording underwriting information and decisions, issuing policies, quoting and implementing policy endorsements, calculating premiums, collecting premiums, managing debtors, maturities/expiries. Many companies accrue multiple administration systems as new products are created, and so these can often be referred to a Product Administration systems.

Claims Management – sometimes part of the Policy Administration system, responsible for capturing, underwriting, and paying claims. May include collection of reinsurance, and tracking/payment of investigation costs.

Agency Commission & Competency – management of distributors, usually focused on tied agency forces and IFAs/Brokers. Sometimes also includes calculation of commission for bancassurance, although this tends to be simpler than for other channels.

Reinsurance – treaty and facultative, reinsurance borderaux, sometimes premium payment and claims recovery.

Annuity Management – performs calculations of annuity amounts and generates scheduled payments. Does not always include tax calculations, which change frequently and therefore require significant maintenance overhead. Sometimes a company will use a payroll-style system for tax components. For companies that sell annuities as separate products, an Annuity system will be considered a Policy Administration system.

Billing / Payments – sometimes a separate system the consolidates/splits banking files across multiple policy/product administration systems.

Servicing Call Centre – ranges from basic enquiry screen with notes facility, through to CTI and full “CRM” systems.

Sales Force Automation / Agency Support – tools for agents/distributors to use, including needs analysis, quotations/illustrations, electronic forms, e-submission of new applications (depending on signature and compliance requirements), …

Investment Management – companies will need some sort of tool to manage their investment portfolios, even if the bulk of the work is outsourced to an investment arm or another company.

Direct Marketing and Lead Management - for companies that sell through a Direct Marketing channel, a campaign planning/monitoring system is needed. In addition, a system to manage (deduplicate, track, etc) leads through the sales and conversion process.

Infrastructure

Data Warehouse – often further separated into Marketing data warehouse (true warehousing for analysis) and Operational Data Stores (for operational reporting).

Imaging & Workflow – ranges from simple diary system to full-fledged integrating document management and business process management. Many would argue that for larger organisations this is a core component for the business.

Financials – what is normally known as ERP, but in the case of financial services organisations is often reduced to General Ledger, possibly plus Accounts Payable and for larger organisations Asset Management, etc.

Banking Interfaces – interfacing information to and from the banking systems and the administration systems.

Automatic Underwriting – a rules/engine or equivalent that is usually integrated through workflow to assess new business cases and arrive at an underwriting decision.

Corporate Website – the company's corporate presence on the internet. For companies that operate a direct sales channel, this will usually include some sales functionality.

Human Resources – normal HR and payroll systems, although often outsourced.

Quotation Engines – performs quotations for New Business and alterations/endorsements. Often separated out with the intention of reducing maintenance overhead across multiple systems.

Premium Calculation Engine – sometimes separated out into a discrete system that is then called from within New Business, Policy Administration, Quotation/Illustration systems, etc.

Of course there are many more. In some mid-sized organisations the number of systems is in the hundreds (although this is often a result of patching “holes” in the core components!).

Roles of PMO organisations

A Project Management Office (PMO) is not an uncommon feature of middle to larger insurance organisations. The PMO is often associated with primarily IT projects, perhaps because of a history of poor execution on the part of IT, or due to the significant size of the a programme that the business intends to complete. In other situations, the PMO will be spread across both business and IT - for example to establish a Shared Services function. In any of these situations, the nature of the PMO tends to be either to coordinate and report, or to take full ownership of driving the change programme. Which is better? It depends - on the stakeholders both within and outside of the PMO team.

The Coordinating PMO
The coordination model has PMO collecting status information from individual project managers, and creating management reports.

In order to do this effectively the PMO will normally implement some level of standards (templates, procedures) that make their life easier by ensuring consistent information.

PMO will gather information from each individual project manager, maintain centralised folders or repositories of plans, reports, milestone charts, and issues lists.

However the PMO will not normally be proactive in taking decisions about individual projects, instead escalating to stakeholders.

Business case preparation is usually left to the stakeholders or staff outside of PMO. In fact the PMO staff will often lack a good understanding of the business domain.

In one example organisation, the PMO team did not have any staff with any significant level of understanding of Financial Services, or IT. As a result they were unable to contribute to creation of business cases, not knowing what needed to be considered or how the project would benefit the business. The PMO function became a convenience for the rest of the business - a team that would write the status reports, manage the files, and other project administration tasks.

The Directing PMO

In a directing model, PMO has a much higher level of accountability for delivery of the programme results. The objectives of the PMO are defined in terms of the business benefits, and responsibility is shared with the business leaders. The PMO leader (Programme Director?) takes a much more active role in the change programme. He/she sets strategies, timelines, and pushes responsibilities onto the business members.

Which is Best?
If the business is characterised by strong leadership, then PMO will naturally play a more supportive role, taking away much of the administration while the business owner retains control of the direction of the programme.

If the business team does not have strong leadership, then PMO has the option and probably the responsibility to step into the vacuum to drive the direction and exection of the programme.

IT's Job Description

What is the job description of the IT department in an insurance company?

In the author's experience IT organisations fall into one of two molds:
- Quiet and Reactive
- Loud and Aggressive

Quiet/Reactive
Reactive IT teams take the approach that their job is generally to wait on the business to explain what they want. And whatever the business asks for is what they will be given - often even if it is clearly not the correct thing to do.

This results in an ad-hoc sprawl of systems, with little thought given to systems architecture at a business level. In one recent example I worked with a company that had over discrete 250 applications. This in a company with a total of 270 staff. In part this was a result of serial migrations between core policy administration systems. Every time a migration was carried out, the company decided that they had made the wrong system selection choice. This led to further development of the system being halted while a new system was selected. But because business does not stop while system projects are completed, the company ended up instituting a myriad of piecemeal solutions to each small processing requirement or requirement. And because the IT team did not "own" the overall architecture, this sprawl was allowed to grow to an unmanageable and expensive level.

Reactive teams also wait for the business to define requirements for new products and features. This often leads to a significant level of dissatisfaction or distrust between business departments (Operations, Sales, Marketing, etc) and IT. Business teams are not experts in defining what they need in the language or level of detail needed by IT. When an IT team does not take an active role in extracting detailed requirements, the business frequently ends up with a sub-optimal result and is understandably unhappy. And who will they blame?

Aggressive/Loud
Loud teams tend to take a more proactive approach, and if the team has the right combination of technical expertise and knowledge, can be very successful. However this needs to be carefully balanced. In one company, the IT team would attempt to take complete control as soon as a business unit had enunciated a general requirement. Because of the aggressive personalities involved, IT often attempted to tell the business what they could and could not do. Naturally this led to a certain level of resentment, and a general view that IT was always difficult to deal with.

The advantage over the reactive approach is that the end result (after the difficult negotiations) usually ends up working as agreed. But by that stage the damage to the relationship has already been done.

IT's Job Description
What approach should IT take? How can we summarise the notion that IT is a fundamental part of the operation and at the same time incorporate a more proactive or aspirational aspect?

A straw-man job description for the IT department should comprise two key points:

1. Keep the lights on
2. Build growth / revenue for the organisation

IT's first responsibility is to keep things running smoothly. This is the BAU part of the job - make sure the servers are running, the network is up, security is in place, and the applications working correctly.

The second part is to recognise that there is value that IT can add to the business. IT can be proactive in defining requirements for a change, but this needs to be backed up by a mindset that understands the impact (restriction or enhancement) on revenue.

Any new initiative triggered by IT must be described in terms of the growth or revenue that it will bring to the organisation. Otherwise how would anyone in the business understand what is being proposed, and why would they approve it?

Much of the nature of the IT department's mindset will come down to the approach taken by the CIO. And to one level or another, CIOs generally follow the two stereotypes described above. For more on this, refer to CIO Magazine's article where CIOs are classified as either builder or maintainer.

Project Methodologies

Project methodologies traditionally get a lot of air time with consultants and IT groups. However it can often turn into a discussion that is actually more focused on the SDLC (software development lifecycle). In many situations the SDLC becomes a proxy for project management, and this is usually when the organisation does not have either project management or IT as part of it's competencies.

Project methodologies are varied, from the Project Management Institute's PMBOK (truly a body of knowledge rather than a methodology per se) and PRINCE2, to custom methodologies developed in-house. And of course consulting organisations (Deloitte, Accenture, Abeam, etc) will jump at the chance to implement their "proven" methodologies - for a fee. Project methodology should focus on managing a project from start to finish, delivering a unique business result.

An SDLC should instead focus on specific tasks and deliverables required to meet a business need through the use of IT. IT requires a combination of discipline and flexibility or adaptability in order to deliver successfully.

In organisations that don't understand the objective of a project management methodology, the IT department is often seen as the defacto project management function, since that's where the investment of time and money into "projects" is most obvious. And in these situations, the project management function often becomes simple coordination of meetings around the SDLC. As a result the business becomes alienated by the lack of transparency and a significant gap in understanding between what the users want and what they get.

Project management needs to be given attention separately to the IT function, and then linked into both Operations and IT.

The role of business analysts

A topic that's been on the table over the past couple of weeks is the definition of a Business Analyst, and their role and responsibilities within the company.

In IT vendors this is fairly straightforward. The Business Analyst (BA) is the link between the users (the business) and the System Analysts or Designers (depending on the company you come from). They need to understand the business area (e.g. life insurance, pensions, A&H), be familiar with the terminology and the operational processes (clerical procedures), and be able to translate this into language the techies understand.

The BA also needs to know what, how, and when to challenge what the users say. When they do this well they are often called a Consultant, Business Consultant, or Functional Consultant.

In insurance companies, the term Business Analyst often appears to be translated into "documenter" or something similar. A number of BAs I've seen are not contributing actively to the improvement of this business, but rather just producing paper on behalf of others who cannot do it themselves.

However there are many, many situations where the insurance company would benefit from a challenging mind. The natural trend is to accumulate additional process steps and the complications and inefficiencies that result. A challenging mind in the BA would improve things no end.

Of course the balancing factor is the relative ease with which an external BA can challenge compared with an internal BA who needs to maintain a long-term relationship with the business users. The BAs who can achieve this are the golden geese - hold on to them!

Sleek MacBook

Nothing at all to do with financial services, but all the buzz in the office today has been around the new MacBook Air as described here on MacWorld. I will be looking out for it to arrive in the Apple store in Ginza.

The promise of SOA

Apparently Accenture has rejoined the school of "state-the-obvious" and realised that Service Oriented Architecture (SOA) is not delivering on the hype.

The industry continues to focus on a single technology at a time, without considering the wider architectural context. On it's own the SOA paradigm moves one step towards and answer, but without considering the components in a business context, it is a futile exercise that does little more than line the pockets of the consultants.

Interestingly the Computerworld article refers to the CIOs that tell Accenture that they need to work more closely with the business. So true. SOA needs to be viewed as an enabler rather than an end in itself. IT must get back to focusing on business relevance. It is interesting to note the number of articles (like this one from Harvey Nash) that point to the reducing influence of the CIO in corporations.

Let's go back to the basics and focus on the endgame instead of technology for the sake of technology.

Introduction

From time to time there are interesting articles published, both in print and online. This blog focuses on issues relevant to the role of IT in the financial services industry, specifically Life Insurance.