BI WITHIN AN INSURANCE ORGANIZATION Kevin Pledge 1 DEMYSTIFYING BUSINESS INTELLIGENCE 

AGENDA BI system installed in-house  Background  Case studies  BI as a business project Actuarial role and benefits from BI 2 

WHY CONSIDER BI? Analysis, Synthesis and Reporting GL Val’n PAS 3 

ARGUMENT FOR BI Typical reasons given for BI:  Consolidate Data  Make information accessible  Enhance with analytics  Integration  Enterprise view of business Concerns:  Security  Breadth of users  Project risk and cost 4 Benefits often intangible 

WHY INTRODUCE SOMETHING NEW? Against:  Reporting available from other systems  Local data extracts available  Would create additional version of data  Users comfortable with existing tools For:  Integration of data  Operational data not structured for analysis  Maximize potential from existing systems 5 

WHERE ARE WE NOW? By definition the Insurance Industry is one of the largest users of data  Early failures  Notable successes  BI in other industries 1980’s 1990’s 2000’s 1997 – IBM, Oracle, Microsoft launch BI products 1990 – Cognos launch first desktop BI tool Niche vendors, fragmented tool sets Emergence of mainstream, web based products 

Data Warehouse / OLAP Server Presentation Server Users Metadata Data Store Integrated Systems e.g. valuation system ETL ETL Source systems 7 BI SYSTEM COMPONENTS 

CASE STUDIES  What triggers projects?  Challenges and lessons learnt 8 

CASE STUDY: SPECIFIC TRIGGERS  Senior management want better information  Actuaries needed improved analytics  Improved data management 9 

BETTER INFORMATION  CEO / Board requests  Format suitable for (non-technical) audience  Verifiable and integrated – need to get everyone on the same page  Need to be able to answers questions not yet anticipated  Budget sometime easier to obtain 10 

IMPROVED ANALYTICS  Improved Financial Reporting • GL drill-down by policy and product dimensions • Integrated financial planning • Source of Earnings  Experience studies 11 

IMPROVED DATA MANAGEMENT  Valuation extract management • Valuation data transformations – consistent • Reproducibility of extracts  Shared data source 12 

ACTUARIAL BUSINESS CASE  Health Insurer writes $1bn premium annually  Rate increases subject to regulator approval may be 6% p.a.  Value of accelerating approval by one month  Additional Revenue = $1bn x 0.06 x 1/12 = $5m p.a. (modifications: not all business receives increase, may not be 6%, one time catch up, etc) 13 

CHALLENGES  Opportunity spotted by COO • Loss ratio by agent • Not credible, but effective  Handling success – report explosion, staff role change  Concern of data availability to all areas 14 

SECURITY  Personal Information, access to sensitive financial information • Modify query based on login credentials • Design in structure of DBs to restrict access  Laptops / transportable data 15 

LESSONS LEARNT  Many non-tangible benefits discovered during the project  Would have done differently: • Definitions / less pre-planning • Accessibility 16 

BI IS NOT AN IT PROJECT!  Business functions cannot be an after thought  Success does not come from a data mapping exercise  Business leadership is critical for success  Application model needs to be designed upfront 17 

DATA MODEL / APPLICATION MODEL  Unique features of insurance need to be recognized in the design • Sale is the start of a relationship • Data is complex Life Health – temporal, P&C large number of attributes  Goal of moving logic upstream • Reduces work • Avoid inconsistencies • Proves system 

Data Warehouse / OLAP Server Presentation Server Users Metadata Data Store Integrated Systems e.g. valuation system ETL ETL Source systems 19 APPLICATION LOGIC  Goal  Move application logic into the system managed by metadata 

DATA MODEL Policy Fact Table Extract Date (FK) Product Code (FK) Jurisdiction (FK) Policy Id Date of Birth Issue Age Issue Date (FK) Sum Assured Annual Premium Reserve Time Dimension (1) Extract Date (PK) Year Quarter Month Product Code Dimension Product Code (PK) Product Name Product Description Product Type Product Fund Product Group Jurisdiction Dimension Jurisdiction (PK) State or province Sales Area Country Time Dimension (2) Issue Date (PK) Issue Year Band Year Quarter Month 

DATA MODEL Policy Fact Table Extract Date (FK) Product Code (FK) Jurisdiction (FK) Policy Id Date of Birth Issue Age Issue Date (FK) Sum Assured Annual Premium Reserve Time Dimension (1) Extract Date (PK) Year Quarter Month Product Code Dimension Product Code (PK) Product Name Product Description Product Type (FK) Jurisdiction Dimension Jurisdiction (PK) State or province Sales Area Country Time Dimension (2) Issue Date (PK) Issue Year band Year Quarter Month Product Type Dimension Product Type (PK) Product Fund Product Group 

APPLICATION MODEL  Need to embed calculated functions  Need to accommodate unique insurance features 22 

GET INVOLVED  Don’t be intimidated by jargon • OLAP (online Analytical Processing), ROLAP, HOLAP, MOLAP, DOLAP, etc • Star schema, normalization, • Data warehouse, data marts, decision support systems  Insurance DW is complex not large 23 

CONCLUSION  BI has been successful in many companies, but despite this business case can be hard to justify  Build logic into the data structure not reports  Insurance is complex and requires business expertise 24