Pooling Administration

Data Input

Craig Bowlus

Managing Director, Risk Pooling

craig.bowlus@aon.com

Dave Glende

CEO

dave@crossmarkrisk.com

“Nobody goes there anymore …. it’s too

crowded”

Yogi Berra

Carrier / TPA

Internal / External Systems

Self Administered Data

Workflow Integration –

SharePoint | Outlook

BUSINESS INTELLIGENCEDATA INPUTS STREAMLINE PROCESS

BROKER

RISK MANAGEMENT

LOSS CONTROL

ACTUARY

SAFETY

CLAIMS DEPTINCIDENTSCLAIMSEMPLOYEEFLEETEXPOSURE PROPERTYPROGRAM/POLICYINSURER RATINGS

SAFETY SURVEYSLOSS CONTROLRENEWALALLOCATIONTCOR

Pooling Solution

LEGAL

OPERATIONS

Typical Data Flow and Usage

?

?

$

What Valuable Input is Often Missing

Litigation Management Analytics

• Assignment date to closing date• Improve the hierarchy related to “type of loss” • Compliance with budgeting protocols?• Match the output with members, and deal with the

politics

▫ Litigation is Evil, A Proof Litigation requires time and money Time = Money, therefore Litigation = Money x Money = Money ² Money is the root of all evil √Money²=Evil

▫ We have proven that Litigation is Evil

Improve Data Mining on Loss Drivers

• Add “Root Causes” on Police Liability

• Add “Root Causes” on EPL

• Track Special Needs involvement on school claims

• Plaintiff/Applicant Firms

Improve Your Submission to the Markets

• Prove your data mining/loss prevention analytics

• Validate your litigation management protocols

• Reduce your Total Cost of Risk

The Biggest Issues

• Business Issues▫ Data doesn’t meet needs (internal/external)▫ Data is replicated▫ Data is unmanaged▫ Systems are not integrated

• System Issues▫ Data Acquisition▫ Data Replication and Synchronization▫ Application Integration

Exchange SharePoint SQL Server

LMS CRM RMIS Accounting

Single Sign On

Training

Contacts &Communication

RM/Coverage

Financials

Docs

Conferences

Member-facing Components

Typical System ArchitectureCarriers

TPANurse Triage

Other Agencies

Member Staff

Examples

• Member moves to new Agency HQ▫ CRM (Primary/Contact Addresses), RMIS (Schedule,

Location, Recurring Certs)▫ Accounting (Address), Carrier, TPA, Nurse Triage

• Dual use of Risk Management contacts▫ Risk Management Bulletins (CRM)▫ Annual Renewal Questionnaire (RMIS)

• Communication Management▫ Distribution Lists in RMIS not accessible from

Exchange▫ Emails from RMIS not recorded in CRM

Key Principles

#1: You must know where you’re going

in order to get there

Information Architecture

ManagedConsolidated and Complete

AccessibleAudited and Secure

Historical

PoolInformation

Storage

Member QsRM SurveysTPACarriersAccountingClaims/Incidents

Contribution CalcsRisk Management

Claims/TPAsMember Services

CarriersNurse Triage

AccountingOther Agencies

Key Principles

#1: You must know where you’re going

in order to get there

#2: Many feet cause much noise

Exchange SharePoint SQL Server

LMS CRM RMIS Accounting

Single Sign On

Training

Contacts &Communication

RM/Coverage

Financials

Docs

Conferences

Member-facing Components

Typical System ArchitectureCarriers

TPANurse Triage

Other Agencies

Member Staff

Data Synchronization

• Some data is “replicated”▫ Contact info▫ Property, Vehicles, …▫ Loss data

• Can be identical or “similar”• Choices

▫ Avoidance Eliminate duplicate storage Integrate with the “master” data system Don’t use particular features of a system

▫ Sync the data Real-time, nightly/weekly/monthly updates Need method of correlating the records and transforming the data

(if necessary)

• Choose solutions/vendors wisely

Application Integration

• Sharing of processes and process information▫ Contact/Member demographics▫ Locations and Schedules▫ Billing information▫ Contacts and key functional roles▫ Records management

• Examples▫ Email sent/received via RMIS/CRM▫ Invoices generated in RMIS using CRM data▫ Questionnaire publication from RMIS uses Contact data from

CRM• Choices

▫ Can be built-in or custom (depends on vendors/solutions)• Choose solutions/vendors wisely

Example: Pool info in Outlook via CRM

Example: Member Portal

Key Principles

#1: You must know where you’re going

in order to get there

#2: Many feet cause much noise

#3: Broken systems break systems

Choosing an Architecture

• 5-yr Pool Strategy

• Operational Goals

▫ Member-facing

▫ Internal

• Budget guidelines

• Existing and planned systems

• Partner systems

• Leadership: Knowledgeable and available

Choosing a Solution

• Verify that the solution and vendor meets your needs

• Talk with other JPAs or JPA administrators

• See the solutions in action AT A JPA

• Use an outside expert to facilitate/guide the process. Knowledgeable in:

▫ Pools

▫ Available pooling solutions

▫ IT Architecture and solution implementations

Listen, Learn, Deliver

Customer Understanding

InsightInnovation

Available Solutions

• CRM▫ Customized xRM via MS Dynamics CRM, Salesforce, …▫ “Integrated” into RMIS

• RMIS▫ Pool-specific: NavRisk, CHSI Connections, Crossmark▫ RiskConsole, Origami, … (See Dave Tweedy’s List)

• Surveys▫ Survey Gizmo, Survey Monkey, Survey System▫ KeyPoint, FluidSurveys, Snap Surveys▫ http://survey-software-review.toptenreviews.com

• Sync▫ File transfers/exchanges▫ Built-in “connectors” (i.e. Dynamics CRM GP, CVENTCRM,

ExchangeCRM)▫ Integration solutions (Scribe, MS BizTalk Server, MS Workflow)

Vendor Selection

• Vendors should be experts in what they will be doing for your organization▫ Risk Pools are different and unique. ▫ The extent to which the Vendor lacks

experience/knowledge negatively impacts the risk/ability/quality of the solution and services provided.

▫ Mitigations must be put in place to compensate to the degree necessary. “Over-compensation” is wise.

• Vendors must commit to fully engaging in understanding your requirements▫ They must understand your pool so they create the

best solution

Vendor Selection (cont.)

• You should have a person on staff or acting on your behalf who is knowledgeable and capable on IT projects, but who also understands the your business operations.

• Lower cost proposals (i.e. underbidding) should raise caution as to the expectations and ultimate success of the project. Beware of:▫ Cost overruns and unforeseen costs▫ Lower than expected quality▫ Missing deliverables▫ Long term health and stability of vendor

• As risk goes up, scrutiny should also go up:▫ More pre-screening▫ More proof of capabilities and proven success▫ Greater need to see similar system in production and interview

staff using it

Executing for Success

• Allocate sufficient time for your staff▫ Requirements meetings and reviews▫ Testing

• As risk goes up, gates should also go up:▫ Schedules should have:

Smaller deliverables more often Finer grained schedules (each task being no more than 5 days)

▫ Enhanced escalation paths▫ Increased project schedule oversight

• Real Executive oversight on schedule and deliverables▫ Monthly meetings▫ Both teams (vendor/client) present together with

management (vendor/client)

Risks and Red Flags

• No comparable systems in production• Percent of custom work moderate to high

▫ 0-20% - no issue▫ 20%-35% - moderate risk▫ >35% - high risk

• Inexperienced vendor and/or client team (especially for team leads/sr staff for both vendor and client)

• Shallow depth of interaction in extracting requirements▫ Do they ask the right questions▫ Do they understand the terminology▫ How much did they not ask▫ Can they repeat back (in their own words) the requirements (i.e. did they

really understand)• Lack of experience of vendor’s Executive Management in the

industry

Risk and Red Flags (cont.)

• Willingness of vendor’s execs to commit to things without understanding the requirements

• Underbidding the contract in order to gain the business• Inability on the client team to recognize (and then take

action) when vendor doesn’t understand what they are building

• Lack of detailed schedule (no task > 5 days)• Repeatedly late on deliverables• Pattern of disregard for the schedule, meeting times,

follow up• Unexpected amount of rework (both in requirements

reviews and software deliveries)